headers
Uma Chunduri | 1 Apr 2012 15:20
Picon
Favicon

Re: [karp] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00

Hi Les,

You raised a good point on partial deployments. Please see my response in-line [Uma]. 

-- 
Uma C. 

===
Consider this simple example:
   R1----R2----R3
R1 does NOT support the extension, but R2 and R3 do support the extension.
All routers have an LSP originated by R3 - call it R3.00-00 Seq #10 ESSN # 50
An attacker has an old LSP from a previous incarnation of R3. Call it R3.00-00 Seq #20 ESSN # 40. 
The attacker injects this replayed LSP into the network at R1. As the sequence # is greater than the copy 
in the local database R1 accepts the replayed LSP and then floods it to R2. R2 however rejects the replayed 
LSP because it has an older ESSN #. LSPDB is now inconsistent between R1 and R2/R3. This condition will 
persist until R3 generates a new LSP with sequence # > 20 or until the replayed LSP on R1 ages out.

[Uma]: I am glad you see the problem. As you have been saying this is temporary problem (which is quite true),
why do you think 
       this situation would come down to R1 aging out. Are you saying new LSP from originator would never be flooded
in this
       LAN segment? I am missing some thing here.

I think there are similar constraints as regards the use of the extension in IIHs and SNPs - though in that
case it 
is only necessary to upgrade all routers on a particular link - and probably support enabling the extension
on a 
per link basis.Note that if not all ISs on a LAN segment support the extension, then a replay attack could
result
(Continue reading)

Permalink | Reply | 6 comments |
headers
Les Ginsberg (ginsberg | 1 Apr 2012 18:55
Picon
Favicon

Re: [karp] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00

Uma -

> -----Original Message-----
> From: Uma Chunduri [mailto:uma.chunduri <at> ericsson.com]
> Sent: Sunday, April 01, 2012 6:21 AM
> To: Les Ginsberg (ginsberg); Bhatia, Manav (Manav); Naiming Shen
(naiming)
> Cc: Mike Shand; isis-wg <at> ietf.org; karp <at> ietf.org
> Subject: RE: [karp] [Isis-wg] Question
regardingdraft-chunduri-isis-extended-
> sequence-no-tlv-00
> 
> Hi Les,
> 
> You raised a good point on partial deployments. Please see my response
in-
> line [Uma].
> 
> 
> --
> Uma C.
> 
> 
> ===
> Consider this simple example:
>    R1----R2----R3
> R1 does NOT support the extension, but R2 and R3 do support the
extension.
> All routers have an LSP originated by R3 - call it R3.00-00 Seq #10
ESSN # 50
(Continue reading)

Permalink | Reply | 5 comments |
headers
Les Ginsberg (ginsberg | 2 Apr 2012 08:33
Picon
Favicon

draft-chunduri-isis-extended-sequence-no-tlv - other comments

In a previous thread we have discussed the use of the proposed extension
in LSPs.

Here are the remainder of my comments on the draft:

In regards to SNPs, the presence of replayed SNPs will cause unnecessary
reflooding of LSPs but will not actually cause any change in the LSPDB
of any router. The unnecessary flooding would be limited to the link on
which the replayed SNPs appear. Because no actual LSPDB changes would
occur as a result of replayed SNPs, this is the one usage which could be
enabled in the presence of partial deployment.

In regards to IIHs, replayed IIHs could cause adjacency flapping which
could be very disruptive. The danger lies when not all systems on a link
support the extension - which on multi-access links can lead to multiple
DISs being elected and violations of the assumption of transitivity. For
this reason, enablement cannot be safely done in the presence of legacy
systems.

Given the discussion in the draft about enhancements to provide routing
protocols with a group key management protocol in the future, it is
prudent to look at the value add of extended sequence #s in the presence
of a group key management protocol. The cost of having router vendors
and their customers implement, deploy, and support extended sequence #s
must be weighed against the benefits.

As discussed in an earlier thread, IS-IS already has a reliable
mechanism to recover from replayed LSPs. I see no significant value in
using this extension in LSPs - and there is significant risk of
introducing prolonged inconsistency in the LSPDB of routers in the
(Continue reading)

Permalink | Reply | 4 comments |
headers
Donald Eastlake | 5 Apr 2012 21:02
Picon

Re: draft-chunduri-isis-extended-sequence-no-tlv - other comments

I have a concern about replayed IIHs within TRILL where it is
reasonable to believe that such a change could be universally deployed
or nearly so. I would like to see such a TLV available for at least
that purpose.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3 <at> gmail.com

On Mon, Apr 2, 2012 at 2:33 AM, Les Ginsberg (ginsberg)
<ginsberg <at> cisco.com> wrote:
> In a previous thread we have discussed the use of the proposed extension
> in LSPs.
>
> Here are the remainder of my comments on the draft:
>
> In regards to SNPs, the presence of replayed SNPs will cause unnecessary
> reflooding of LSPs but will not actually cause any change in the LSPDB
> of any router. The unnecessary flooding would be limited to the link on
> which the replayed SNPs appear. Because no actual LSPDB changes would
> occur as a result of replayed SNPs, this is the one usage which could be
> enabled in the presence of partial deployment.
>
> In regards to IIHs, replayed IIHs could cause adjacency flapping which
> could be very disruptive. The danger lies when not all systems on a link
> support the extension - which on multi-access links can lead to multiple
> DISs being elected and violations of the assumption of transitivity. For
(Continue reading)

Permalink | Reply | 0 comments |
headers
rfc-editor | 21 Apr 2012 01:00
Favicon

RFC 6329 on IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging


A new Request for Comments is now available in online RFC libraries.

        
        RFC 6329

        Title:      IS-IS Extensions Supporting IEEE 802.1aq 
                    Shortest Path Bridging 
        Author:     D. Fedyk, Ed.,
                    P. Ashwood-Smith, Ed.,
                    D. Allan, A. Bragg,
                    P. Unbehagen
        Status:     Standards Track
        Stream:     IETF
        Date:       April 2012
        Mailbox:    Donald.Fedyk <at> alcatel-lucent.com, 
                    Peter.AshwoodSmith <at> huawei.com, 
                    david.i.allan <at> ericsson.com,
  nbragg <at> ciena.com, 
                    unbehagen <at> avaya.com
        Pages:      37
        Characters: 88465
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-isis-ieee-aq-05.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6329.txt

802.1aq Shortest Path Bridging (SPB) has been standardized by the IEEE
as the next step in the evolution of the various spanning tree and
(Continue reading)

Permalink | Reply | 0 comments |
headers
RFC Editor | 21 Apr 2012 01:02
Favicon

Please Disregard -- Re: RFC 6329 on IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging

Greetings All,

Please disregard this announcement.  A corrected announcement will be
sent shortly.

Thank you,
RFC Editor

On Fri, Apr 20, 2012 at 04:00:55PM -0700, RFC Editor wrote:
> 
> A new Request for Comments is now available in online RFC libraries.
> 
>         
>         RFC 6329
> 
>         Title:      IS-IS Extensions Supporting IEEE 802.1aq 
>                     Shortest Path Bridging 
>         Author:     D. Fedyk, Ed.,
>                     P. Ashwood-Smith, Ed.,
>                     D. Allan, A. Bragg,
>                     P. Unbehagen
>         Status:     Standards Track
>         Stream:     IETF
>         Date:       April 2012
>         Mailbox:    Donald.Fedyk <at> alcatel-lucent.com, 
>                     Peter.AshwoodSmith <at> huawei.com, 
>                     david.i.allan <at> ericsson.com,
>   nbragg <at> ciena.com, 
>                     unbehagen <at> avaya.com
>         Pages:      37
(Continue reading)

Permalink | Reply | 0 comments |
headers
rfc-editor | 21 Apr 2012 01:17
Favicon

RFC 6329 on IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging


A new Request for Comments is now available in online RFC libraries.

        
        RFC 6329

        Title:      IS-IS Extensions Supporting IEEE 802.1aq 
                    Shortest Path Bridging 
        Author:     D. Fedyk, Ed.,
                    P. Ashwood-Smith, Ed.,
                    D. Allan, A. Bragg,
                    P. Unbehagen
        Status:     Standards Track
        Stream:     IETF
        Date:       April 2012
        Mailbox:    Donald.Fedyk <at> alcatel-lucent.com, 
                    Peter.AshwoodSmith <at> huawei.com, 
                    david.i.allan <at> ericsson.com,
                    nbragg <at> ciena.com, 
                    unbehagen <at> avaya.com
        Pages:      37
        Characters: 88465
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-isis-ieee-aq-05.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6329.txt

802.1aq Shortest Path Bridging (SPB) has been standardized by the IEEE
as the next step in the evolution of the various spanning tree and
(Continue reading)

Permalink | Reply | 0 comments |

Gmane