From isis-wg-bounces@ietf.org Sat Apr 01 04:51:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPcl6-00051b-T9; Sat, 01 Apr 2006 04:51:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPcl5-00051N-86 for isis-wg@ietf.org; Sat, 01 Apr 2006 04:51:03 -0500 Received: from rrcs-66-91-145-219.west.biz.rr.com ([66.91.145.219] helo=apollo.adtech-inc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPcl3-00074i-Tq for isis-wg@ietf.org; Sat, 01 Apr 2006 04:51:03 -0500 Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id <1HT4GNQB>; Fri, 31 Mar 2006 23:51:54 -1000 Message-ID: <3D7BA5153B91EB4EBCF4CEDFE6263EA2051383E3@apollo.adtech-inc.com> From: "Kandula, Ramesh" To: "'isis-wg@ietf.org'" Date: Fri, 31 Mar 2006 23:51:51 -1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 1.4 (+) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [Isis-wg] Hello Storm? X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Hi all Can someone explain why the following scenario does not happen? Suppose two IS-IS routers (RTR1 and RT2) on a P2P link restart ~at the same time. 1. The RTR1 comes up first and sends a hello with RR=1, RA=0, state=Init (P2P 3-way) 2. Then RTR2 comes up and as soon as it comes up it sends a hello with RR=1, RA=0, state=Init (RTR2 didn't see RTR1's hello) 3. When RTR1 sees RTR2's hello, it notices it doesn't have an adjacency in the Up state with RTR2, so it processes the hello normally. This causes RTR1's state to go to Up (Should RTR1 care whether it has received Restart Ack?). It sends a hello with RR=1, RA=1, state=Up (though not immediately) 4. When RTR2 sees RTR1's hello, it does the same as step 3. But now it sends a hello immediately with RR=1, RA=1, state=Up. 5. When RTR1 sees this, it does the same as step 4. RR=1, RA=0, state=Init 1. ----------------------------------> RR=1, RA=0, state=Init 2.<-------------------------------- RR=1, RA=1, state=Up 3. ---------------------------------> RR=1, RA=1, state=Up 4.<--------------------------------- RR=1, RA=1, state=Up 5. -----------------------------------> . Do these two routers keep sending hello's like this until T1 timer is cancelled (due to expiry or otherwise)? It was mentioned in the earlier posts that routers restarting around the same time is very unlikely. Assuming that it can happen what is prevening the hello storm descirbed above? Thanks ramesh _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sun Apr 02 01:36:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPwBb-0003KJ-Fu; Sun, 02 Apr 2006 01:35:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPwAJ-0002XY-Ci for isis-wg@ietf.org; Sun, 02 Apr 2006 01:34:23 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPvxc-0006Nk-VW for isis-wg@ietf.org; Sun, 02 Apr 2006 01:21:20 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 01 Apr 2006 22:21:16 -0800 X-IronPort-AV: i="4.03,154,1141632000"; d="scan'208"; a="1790925192:sNHT358011352" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k326LF1j023911 for ; Sat, 1 Apr 2006 22:21:15 -0800 (PST) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 1 Apr 2006 22:21:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 1 Apr 2006 22:21:14 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Simplified Extension of LSP Space for IS-IS Draft Thread-Index: AcY4jsylaZA9x+o7SLykjJEp5lCGRAAGJ/3AB115jyA= From: "Les Ginsberg \(ginsberg\)" To: X-OriginalArrivalTime: 02 Apr 2006 06:21:15.0735 (UTC) FILETIME=[A580A670:01C6561D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Isis-wg] Simplified Extension of LSP Space for IS-IS Draft X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Folks - The draft describing the alternative to RFC 3786 is now available. http://www.ietf.org/internet-drafts/draft-ginsberg-isis-extlsp-00.txt Les _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Apr 06 05:01:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRQMA-00014T-02; Thu, 06 Apr 2006 05:00:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRQM7-00014O-Fk for isis-wg@ietf.org; Thu, 06 Apr 2006 05:00:43 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRQM6-0007aD-6n for isis-wg@ietf.org; Thu, 06 Apr 2006 05:00:43 -0400 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by kremlin.juniper.net with ESMTP; 06 Apr 2006 02:00:42 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,92,1144047600"; d="scan'208"; a="538138960:sNHT24109588" Received: from [172.26.200.148] ([172.26.200.148]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 02:00:40 -0700 Message-ID: <4434D8B5.9010906@juniper.net> Date: Thu, 06 Apr 2006 11:00:37 +0200 From: Hannes Gredler User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Les Ginsberg (ginsberg)" Subject: Re: [Isis-wg] Simplified Extension of LSP Space for IS-IS Draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Apr 2006 09:00:40.0947 (UTC) FILETIME=[94772C30:01C65958] X-Spam-Score: 0.6 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Nischal Sheth , "isis-wg@ietf.org" , stefano previdi , mshand@cisco.com X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org les, i have read through your draft and do think that there may be a simpler fix to all of the fragment scalability problems. basic idea is to introduce a kind of connector-TLV where you can link arbitrary information to a diffent sysid in an additive fashion. unlike the IS ALias TLV it does not work at the SPF level but rather at the TLV parser level inside a router which extracts information and adds it to the internal representation of the LSDB. --- for example lets assume that a node has two sysids 1921.6800.1001 (main sysid) 1720.1600.1001 (leaf sysid) in the main LSP we announce all SPF relevant information. in the leaf LSP we announce all non-SPF relevant information ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ /* occurence of a connector TLV links all TLV / subTLV information found in that fragment in an additive fashion. so we may repeat the extd-IS reach attribute with different subTLV content. */ a receiving router should add all information found in a fragment containing the connector TLV in an additive fashion upon installation in the local representation of the LSDB. for subTLV information the higher-level TLV information serves as key. (in our example sysid is the key for any subTLVs linked) what needs to be taken care is security/purging related stuff if some external node wants to link information. what do you think ? /hannes Les Ginsberg (ginsberg) wrote: > Folks - > > The draft describing the alternative to RFC 3786 is now available. > > http://www.ietf.org/internet-drafts/draft-ginsberg-isis-extlsp-00.txt > > Les _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Apr 07 01:36:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRjdo-00087z-0D; Fri, 07 Apr 2006 01:36:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRjdh-00082L-Lo for isis-wg@ietf.org; Fri, 07 Apr 2006 01:36:09 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRjdX-00065I-7o for isis-wg@ietf.org; Fri, 07 Apr 2006 01:36:04 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 06 Apr 2006 22:35:59 -0700 X-IronPort-AV: i="4.04,94,1144047600"; d="scan'208"; a="267259332:sNHT36177924" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k375ZwYg010174; Thu, 6 Apr 2006 22:35:58 -0700 (PDT) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Apr 2006 22:35:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] Simplified Extension of LSP Space for IS-IS Draft Date: Thu, 6 Apr 2006 22:35:56 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] Simplified Extension of LSP Space for IS-IS Draft Thread-Index: AcZZWJsA8jYNaegOSRSc3Z5chDzxnQAqMgQg From: "Les Ginsberg \(ginsberg\)" To: "Hannes Gredler" X-OriginalArrivalTime: 07 Apr 2006 05:35:58.0256 (UTC) FILETIME=[25D30300:01C65A05] X-Spam-Score: 0.6 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: Nischal Sheth , isis-wg@ietf.org, "Stefano Previdi \(sprevidi\)" , "Mike Shand \(mshand\)" X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Hannes - > -----Original Message----- > From: Hannes Gredler [mailto:hannes@juniper.net] > Sent: Thursday, April 06, 2006 2:01 AM > To: Les Ginsberg (ginsberg) > Cc: Mike Shand (mshand); Stefano Previdi (sprevidi); Nischal Sheth; isis- > wg@ietf.org > Subject: Re: [Isis-wg] Simplified Extension of LSP Space for IS-IS Draft >=20 > les, >=20 > i have read through your draft and do think that there may > be a simpler fix to all of the fragment scalability problems. >=20 > basic idea is to introduce a kind of connector-TLV > where you can link arbitrary information to a diffent sysid > in an additive fashion. unlike the IS ALias TLV it does not > work at the SPF level but rather at the TLV parser level > inside a router which extracts information and adds it > to the internal representation of the LSDB. I do not see how your connector-TLV differs from the Alias TLV. I would also point out that the comment that the Alias TLV "work at the SPF level" is not valid. Section 4.2.1 of the draft says: "Information which is directly utilized in the SPF calculation MUST=20 NOT appear in an Extended LSP." >=20 > --- >=20 > for example lets assume that a node has two sysids >=20 > 1921.6800.1001 (main sysid) > 1720.1600.1001 (leaf sysid) >=20 > in the main LSP we announce all SPF relevant information. >=20 > > > > > > > > > > >=20 > in the leaf LSP we announce all non-SPF relevant information >=20 > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Why metric 0 here? Wouldn't max-metric be safer and more consistent with RFC 3784? > > >=20 > /* occurence of a connector TLV links all TLV / subTLV > information found in that fragment in an additive fashion. > so we may repeat the extd-IS reach attribute with different subTLV > content. > */ >=20 > > > > > > >=20 > >=20 > a receiving router should add all information found in a fragment > containing the connector TLV in an additive fashion upon installation in > the > local representation of the LSDB. for subTLV information the higher-level > TLV information serves as key. (in our example sysid is the key for any > subTLVs > linked) >=20 > what needs to be taken care is security/purging related stuff if some > external node > wants to link information. >=20 > what do you think ? As far as I can tell, the only difference between what the draft proposes and your proposal is that in your proposal we would not have to define a new TLV (call it "22a") to announce the TE sub-TLV information normally associated with TLV 22. Whether this is better or not is arguable - but at most I see this as not much more than a cosmetic difference. Treating the same TLV in two different ways based on whether it is found in an extended LSP vs an original LSP is possible - but it has a risk in that it IS a neighbor reachability TLV - although it is not intended to be used in the same way as a neighbor reachability TLV. So long as no system ever advertises a neighbor to the "leaf sysid" (which should not happen), this should not cause a problem because the 2-way connectivity check will prevent even legacy systems from mistakenly using this in their SPF - and the use of maxmetric further protects against misuse.=20 But I don't see that your proposal differs in any significant way from the draft. Les >=20 > /hannes >=20 >=20 > Les Ginsberg (ginsberg) wrote: > > Folks - > > > > The draft describing the alternative to RFC 3786 is now available. > > > > http://www.ietf.org/internet-drafts/draft-ginsberg-isis-extlsp-00.txt > > > > Les _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Apr 10 04:43:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSrzq-0004Bg-A5; Mon, 10 Apr 2006 04:43:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSrzh-00049D-Hf for isis-wg@ietf.org; Mon, 10 Apr 2006 04:43:33 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSrpZ-0006v2-EA for isis-wg@ietf.org; Mon, 10 Apr 2006 04:33:07 -0400 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by kremlin.juniper.net with ESMTP; 10 Apr 2006 01:33:04 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,106,1144047600"; d="scan'208"; a="538894750:sNHT26221628" Received: from [172.26.200.154] ([172.26.200.154]) by alpha.jnpr.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 01:33:03 -0700 Message-ID: <443A1837.30800@juniper.net> Date: Mon, 10 Apr 2006 10:32:55 +0200 From: Hannes Gredler User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050815) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Les Ginsberg (ginsberg)" Subject: Re: [Isis-wg] Simplified Extension of LSP Space for IS-IS Draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Apr 2006 08:33:04.0297 (UTC) FILETIME=[62AD7190:01C65C79] X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: Nischal Sheth , isis-wg@ietf.org, "Stefano Previdi \(sprevidi\)" , "Mike Shand \(mshand\)" X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org hi les, Les Ginsberg (ginsberg) wrote: > [ ... ] your explanation around use of the Alias TLV makes sense. i'll understand now what you had in mind. > [ ... ] > As far as I can tell, the only difference between what the draft > proposes and your proposal is that in your proposal we would not have to > define a new TLV (call it "22a") to announce the TE sub-TLV information > normally associated with TLV 22. Whether this is better or not is > arguable - but at most I see this as not much more than a cosmetic > difference. > > Treating the same TLV in two different ways based on whether it is found > in an extended LSP vs an original LSP is possible - but it has a risk in > that it IS a neighbor reachability TLV - although it is not intended to > be used in the same way as a neighbor reachability TLV. So long as no > system ever advertises a neighbor to the "leaf sysid" (which should not > happen), this should not cause a problem because the 2-way connectivity > check will prevent even legacy systems from mistakenly using this in > their SPF - and the use of maxmetric further protects against misuse. > > But I don't see that your proposal differs in any significant way from > the draft. you mean other that there *is* a proposed solution for the 'increase subTLV space for TE' problem ;-) you left the definition of such a TLV outside of the scope of your document, which is a bummer if the talk is now about scaling reachability information further, IMO we should not loose the opportunity and spot on there. so what about rephrasing draft 6.3 as: 6.3 Moving TE Information to Extended LSPs One of the major sources of non-SPF related additional information in LSPs is the Traffic Engineering (TE) information carried in the extended IS reachability TLV (22) as defined in RFC 3784 and RFC 4205. The restrictions defined in this document prohibit the presence of TLV 22 in Extended LSPs. In the event that there is a need to advertise TE information in Extended LSPs, it would be necessary to define a new TLV to carry the TE information. Utilization of a new TLV for TE information would provide additional benefits which include: . Elimination of the need for redundant IS neighbor TLVs to be processed as part of the SPF. . Easier support for a set of TE information associated with a single link which exceeds the 255 byte TLV limit by allowing the interpretation of multiple TLVs to be considered additive rather than mutually exclusive. Such an extension would require all routers on which the TE information is processed to support the new TLV as well as the extensions defined in this document. 6.4 sub-TLV Connector TLV (connector) The proposed Connector TLV allows extension-capable ISs to link arbitrary subTLV information to existing IS reachability or IP reachability information. Type 25 Length # of octets in the value field (1 to 255) Value No. of octets +-----------------------+ | Connected TLV | 1 +-----------------------+ | Connector Key length | 1 +-----------------------+ | Connector Key | variable length +-----------------------+ | Sub-TLV length | 1 +-----------------------+ | Sub-TLVs (optional) | 0 to 254 +-----------------------+ Connected TLV TLV number where the subTLV information should be attached to. possible Connected TLV numbers can be 22,222,135,236,237 Connector Key length Key length of the Connector Key. Connector Key Key information where the subTLV information should be attached to. Sub-TLVs length Total length of all sub-TLVs. Sub-TLVs A series of tuples with the same format described in 4.4 Example 1: link a single admin group subTLV #3 to extd IS reach TLV #22 Connected Key = 22 Connector Key length = 7 (IS-reach Neigbor length) Connector Key = 1921.6801.0001.00 Sub-TLV total length 6 Sub-TLV Type 3 Sub-TLV length 4 Sub-TLV Value 0x00000000 Example 2: link a swithing Cap descr subTLV #21 to MT IS reach TLV #222 Connected Key = 222 Connector Key length = 2+7 (MT length + IS-reach Neigbor length) Connector Key = Topology 2, 1921.6801.0001.00 Sub-TLV total length 41 Sub-TLV Type 21 Sub-TLV length 39 Sub-TLV Value { xxxx } Example 3: link a 64-bit admin-tag subTLV #2 to IP6 reach TLV #226 Connected Key = 226 Connector Key length = 4 (variable length encoding of IP6 prefix) Connector Key = 2000:1234/32 Sub-TLV total length 10 Sub-TLV Type 2 Sub-TLV length 8 Sub-TLV Value 0x0000000000000001 -- /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Apr 11 02:46:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTCdk-0007fQ-Cb; Tue, 11 Apr 2006 02:46:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTCdj-0007fC-57 for isis-wg@ietf.org; Tue, 11 Apr 2006 02:46:15 -0400 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTCdg-00038C-GA for isis-wg@ietf.org; Tue, 11 Apr 2006 02:46:15 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 10 Apr 2006 23:46:10 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3B6kAGv028208; Mon, 10 Apr 2006 23:46:10 -0700 (PDT) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Apr 2006 23:46:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] Simplified Extension of LSP Space for IS-IS Draft Date: Mon, 10 Apr 2006 23:46:08 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] Simplified Extension of LSP Space for IS-IS Draft Thread-Index: AcZceXdyQFIyLxKYRu+bcgarXkfCHQAtkaBQ From: "Les Ginsberg \(ginsberg\)" To: "Hannes Gredler" X-OriginalArrivalTime: 11 Apr 2006 06:46:10.0682 (UTC) FILETIME=[9E4735A0:01C65D33] X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Cc: Nischal Sheth , isis-wg@ietf.org, "Stefano Previdi \(sprevidi\)" , "Mike Shand \(mshand\)" X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Hannes - > -----Original Message----- > From: Hannes Gredler [mailto:hannes@juniper.net] > Sent: Monday, April 10, 2006 1:33 AM > To: Les Ginsberg (ginsberg) > Cc: Mike Shand (mshand); Stefano Previdi (sprevidi); Nischal Sheth; isis- > wg@ietf.org > Subject: Re: [Isis-wg] Simplified Extension of LSP Space for IS-IS Draft >=20 > hi les, >=20 > Les Ginsberg (ginsberg) wrote: > > [ ... ] >=20 > your explanation around use of the Alias TLV makes sense. > i'll understand now what you had in mind. >=20 > > [ ... ] > > As far as I can tell, the only difference between what the draft > > proposes and your proposal is that in your proposal we would not have to > > define a new TLV (call it "22a") to announce the TE sub-TLV information > > normally associated with TLV 22. Whether this is better or not is > > arguable - but at most I see this as not much more than a cosmetic > > difference. > > > > Treating the same TLV in two different ways based on whether it is found > > in an extended LSP vs an original LSP is possible - but it has a risk in > > that it IS a neighbor reachability TLV - although it is not intended to > > be used in the same way as a neighbor reachability TLV. So long as no > > system ever advertises a neighbor to the "leaf sysid" (which should not > > happen), this should not cause a problem because the 2-way connectivity > > check will prevent even legacy systems from mistakenly using this in > > their SPF - and the use of maxmetric further protects against misuse. > > > > But I don't see that your proposal differs in any significant way from > > the draft. >=20 > you mean other that there *is* a proposed solution for the > 'increase subTLV space for TE' problem ;-) >=20 > you left the definition of such a TLV outside of the scope of your > document, > which is a bummer if the talk is now about scaling reachability > information > further, IMO we should not loose the opportunity and spot on there. >=20 I do not disagree. The first version of the draft focused on the definition of the solution framework. I did not want to distract from that by defining "TLV 22a". But, if the framework defined is accepted - and the consensus of the group is that we should also include definition of "TLV 22a" in this draft (whatever form that may take) - I have no problem with that. > so what about rephrasing draft 6.3 as: >=20 >=20 > 6.3 Moving TE Information to Extended LSPs >=20 > One of the major sources of non-SPF related additional information > in LSPs is the Traffic Engineering (TE) information carried in the > extended IS reachability TLV (22) as defined in RFC 3784 and RFC > 4205. The restrictions defined in this document prohibit the > presence of TLV 22 in Extended LSPs. In the event that there is a > need to advertise TE information in Extended LSPs, it would be > necessary to define a new TLV to carry the TE information. >=20 > Utilization of a new TLV for TE information would provide additional > benefits which include: >=20 > . Elimination of the need for redundant IS neighbor TLVs to be > processed as part of the SPF. >=20 > . Easier support for a set of TE information associated with a > single link which exceeds the 255 byte TLV limit by allowing > the interpretation of multiple TLVs to be considered additive > rather than mutually exclusive. >=20 > Such an extension would require all routers on which the TE > information is processed to support the new TLV as well as the > extensions defined in this document. >=20 > 6.4 sub-TLV Connector TLV (connector) >=20 > The proposed Connector TLV allows extension-capable ISs to link > arbitrary subTLV information to existing IS reachability or IP > reachability information. >=20 > Type 25 > Length # of octets in the value field (1 to 255) > Value >=20 > No. of octets > +-----------------------+ > | Connected TLV | 1 > +-----------------------+ > | Connector Key length | 1 > +-----------------------+ > | Connector Key | variable length > +-----------------------+ > | Sub-TLV length | 1 > +-----------------------+ > | Sub-TLVs (optional) | 0 to 254 > +-----------------------+ >=20 >=20 > Connected TLV >=20 > TLV number where the subTLV information should be > attached to. > possible Connected TLV numbers can be 22,222,135,236,237 >=20 > Connector Key length >=20 > Key length of the Connector Key. >=20 > Connector Key >=20 > Key information where the subTLV information should be > attached to. >=20 > Sub-TLVs length >=20 > Total length of all sub-TLVs. >=20 > Sub-TLVs >=20 > A series of tuples with the same format described in 4.4 >=20 >=20 >=20 > Example 1: link a single admin group subTLV #3 to extd IS > reach TLV #22 >=20 > Connected Key =3D 22 > Connector Key length =3D 7 (IS-reach Neigbor length) > Connector Key =3D 1921.6801.0001.00 > Sub-TLV total length 6 > Sub-TLV Type 3 > Sub-TLV length 4 > Sub-TLV Value 0x00000000 >=20 > Example 2: link a swithing Cap descr subTLV #21 to MT IS reach > TLV #222 >=20 > Connected Key =3D 222 > Connector Key length =3D 2+7 (MT length + IS-reach Neigbor > length) > Connector Key =3D Topology 2, 1921.6801.0001.00 > Sub-TLV total length 41 > Sub-TLV Type 21 > Sub-TLV length 39 > Sub-TLV Value { xxxx } >=20 > Example 3: link a 64-bit admin-tag subTLV #2 to IP6 reach TLV > #226 >=20 > Connected Key =3D 226 > Connector Key length =3D 4 (variable length encoding of = IP6 > prefix) > Connector Key =3D 2000:1234/32 > Sub-TLV total length 10 > Sub-TLV Type 2 > Sub-TLV length 8 > Sub-TLV Value 0x0000000000000001 > I am not so sure I like this. Essentially what you are defining is a generic TLV aliasing capability i.e. assigning a single TLV which can be used to contain any other TLV which would otherwise be illegal to send in an extended LSP. If I thought this was a generic capability we needed (i.e. there were a lot of TLVs I couldn't send in extended LSPs that I needed to do so to get the non-routing sub-TLVs advertised) - then I might be inclined to look at your solution. But, I don't expect that. And, you end up with two versions of the same TLV - one standalone and one embedded in your connector TLV - with subtle format differences - which doesn't seem like a win for the parsing logic. I take the point however, that it is conceivable that the issues associated with TLV 22 could arise with TLV 222 (MT IS neighbor) as well. As for TLV 226, I suspect that we may have to open the door for Prefix advertisements to be allowed in extended LSPs. Considering an MT world where IPV4, IPv6, multicast are all separate topologies - and the possibility of that in combination with L1-L2 leaking without judicious summarization and/or domain wide prefix distribution - I am wondering if we can get away without allowing this. On this last point I invite other comments - as the initial version of the draft prohibits even leaf node info in extended LSPs for reasons of simplicity. Les >=20 >=20 > -- >=20 > /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Apr 11 16:50:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTPoY-00082r-FH; Tue, 11 Apr 2006 16:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTPoX-0007xy-Ej for isis-wg@ietf.org; Tue, 11 Apr 2006 16:50:17 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTPoW-0002My-TT for isis-wg@ietf.org; Tue, 11 Apr 2006 16:50:17 -0400 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by kremlin.juniper.net with ESMTP; 11 Apr 2006 13:50:16 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,112,1144047600"; d="scan'208"; a="539272237:sNHT395371794" Received: from [172.26.200.154] ([172.26.200.154]) by alpha.jnpr.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 13:50:14 -0700 Message-ID: <443C167D.1030500@juniper.net> Date: Tue, 11 Apr 2006 22:50:05 +0200 From: Hannes Gredler User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050815) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Les Ginsberg (ginsberg)" Subject: Re: [Isis-wg] Simplified Extension of LSP Space for IS-IS Draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Apr 2006 20:50:15.0237 (UTC) FILETIME=[88C90750:01C65DA9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: Nischal Sheth , isis-wg@ietf.org, "Stefano Previdi \(sprevidi\)" , "Mike Shand \(mshand\)" X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org hi les, see answers / clarifications inline; Les Ginsberg (ginsberg) wrote: [ ... ] > I do not disagree. The first version of the draft focused on the > definition of the solution framework. I did not want to distract from > that by defining "TLV 22a". > > But, if the framework defined is accepted - and the consensus of the > group is that we should also include definition of "TLV 22a" in this > draft (whatever form that may take) - I have no problem with that. i guess for clarity we first need to define what the problem is ;-) is it a. scaling subTLV information of TLV22 further (= TLV 22a) b. scaling subTLV information of any parent TLV further (generic subTLV connector) > >>so what about rephrasing draft 6.3 as: >> >> >>6.3 Moving TE Information to Extended LSPs >> >> One of the major sources of non-SPF related additional information >> in LSPs is the Traffic Engineering (TE) information carried in the >> extended IS reachability TLV (22) as defined in RFC 3784 and RFC >> 4205. The restrictions defined in this document prohibit the >> presence of TLV 22 in Extended LSPs. In the event that there is a >> need to advertise TE information in Extended LSPs, it would be >> necessary to define a new TLV to carry the TE information. >> >> Utilization of a new TLV for TE information would provide > > additional > >> benefits which include: >> >> . Elimination of the need for redundant IS neighbor TLVs to be >> processed as part of the SPF. >> >> . Easier support for a set of TE information associated with a >> single link which exceeds the 255 byte TLV limit by allowing >> the interpretation of multiple TLVs to be considered additive >> rather than mutually exclusive. >> >> Such an extension would require all routers on which the TE >> information is processed to support the new TLV as well as the >> extensions defined in this document. >> >> 6.4 sub-TLV Connector TLV (connector) >> >> The proposed Connector TLV allows extension-capable ISs to link >> arbitrary subTLV information to existing IS reachability or IP >> reachability information. >> >> Type 25 >> Length # of octets in the value field (1 to 255) >> Value >> >> No. of octets >> +-----------------------+ >> | Connected TLV | 1 >> +-----------------------+ >> | Connector Key length | 1 >> +-----------------------+ >> | Connector Key | variable length >> +-----------------------+ >> | Sub-TLV length | 1 >> +-----------------------+ >> | Sub-TLVs (optional) | 0 to 254 >> +-----------------------+ >> >> >> Connected TLV >> >> TLV number where the subTLV information should be >>attached to. >> possible Connected TLV numbers can be > > 22,222,135,236,237 > >> Connector Key length >> >> Key length of the Connector Key. >> >> Connector Key >> >> Key information where the subTLV information should > > be > >>attached to. >> >> Sub-TLVs length >> >> Total length of all sub-TLVs. >> >> Sub-TLVs >> >> A series of tuples with the same format described in > > 4.4 > >> >> >> Example 1: link a single admin group subTLV #3 to extd IS >>reach TLV #22 >> >> Connected Key = 22 >> Connector Key length = 7 (IS-reach Neigbor length) >> Connector Key = 1921.6801.0001.00 >> Sub-TLV total length 6 >> Sub-TLV Type 3 >> Sub-TLV length 4 >> Sub-TLV Value 0x00000000 >> >> Example 2: link a swithing Cap descr subTLV #21 to MT IS > > reach > >>TLV #222 >> >> Connected Key = 222 >> Connector Key length = 2+7 (MT length + IS-reach Neigbor >>length) >> Connector Key = Topology 2, 1921.6801.0001.00 >> Sub-TLV total length 41 >> Sub-TLV Type 21 >> Sub-TLV length 39 >> Sub-TLV Value { xxxx } >> >> Example 3: link a 64-bit admin-tag subTLV #2 to IP6 reach > > TLV > >>#226 >> >> Connected Key = 226 >> Connector Key length = 4 (variable length encoding of IP6 >>prefix) >> Connector Key = 2000:1234/32 >> Sub-TLV total length 10 >> Sub-TLV Type 2 >> Sub-TLV length 8 >> Sub-TLV Value 0x0000000000000001 >> > > > I am not so sure I like this. Essentially what you are defining is a > generic TLV aliasing capability i.e. assigning a single TLV which can be > used to contain any other TLV which would otherwise be illegal to send > in an extended LSP. If I thought this was a generic capability we needed > (i.e. there were a lot of TLVs I couldn't send in extended LSPs that I > needed to do so to get the non-routing sub-TLVs advertised) - then I > might be inclined to look at your solution. But, I don't expect that. well, thats the idea - key non SPF relevant subTLV information carried in extended fragments to SPF relevant (MT)IS/IP reach TLV carried in non-extended fragments (see Example 1) > And, you end up with two versions of the same TLV - one standalone and > one embedded in your connector TLV with subtle format differences - i have no intententions to double-define all the extistent TLVs for extended fragments - for simplicy reasons i'd like to have one generic container that can hold subTLVs of all kind. furthermore the header of that container should be flexible enough to attach the 'connected' subTLV information to any kind of 'connected' parent TLV, hence the key-length and key fields; this warrants scalability for present and future TLVs (capability subTLVs come into mind) > which doesn't seem like a win for the parsing logic. i don't think that the extra parsing and data insertion logic, would hurt to much given the benefit over overcoming an architectural deficit (8bit length field) that each of the newer TLVs suffers. > I take the point however, that it is conceivable that the issues > associated with TLV 22 could arise with TLV 222 (MT IS neighbor) as > well. that was the main idea - have a generic (and extensible) way of attaching subTLV information to any kind of parent TLV. note that example 3 was only given for illustrating the idea ( btw i don't expect an V6 prefix to carry more 64-Bit tags that fit into a single subTLV). > As for TLV 226, I suspect that we may have to open the door for Prefix > advertisements to be allowed in extended LSPs. Considering an MT world > where IPV4, IPv6, multicast are all separate topologies - and the > possibility of that in combination with L1-L2 leaking without judicious > summarization and/or domain wide prefix distribution - I am wondering if > we can get away without allowing this. On this last point I invite other > comments - as the initial version of the draft prohibits even leaf node > info in extended LSPs for reasons of simplicity. i'd treat 226 like than any other leaf (non-SPF relevant) information. tx, /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Apr 18 23:00:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW2vJ-0007LK-UK; Tue, 18 Apr 2006 23:00:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW2vI-0007LC-F7 for isis-wg@ietf.org; Tue, 18 Apr 2006 23:00:08 -0400 Received: from web25408.mail.ukl.yahoo.com ([217.12.10.142]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FW2vH-0007la-1j for isis-wg@ietf.org; Tue, 18 Apr 2006 23:00:08 -0400 Received: (qmail 10261 invoked by uid 60001); 19 Apr 2006 03:00:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=EtlNpolMQ2Z3OCAaNL1F++qKK/yn0cw7vToz3DA3uVmmr7nC8fTzUy0hDwHLOzlzDEf2YpKUSEWMCWAA0DY7yEK1SzVkwB4hChspI4mCu0oQRAcVnQepa+PH1ImJYRwIitzjKv7EfGfAgKhOUb88guaXMVAkOfg1cEFwTIAgrqc= ; Message-ID: <20060419030000.10255.qmail@web25408.mail.ukl.yahoo.com> Date: Wed, 19 Apr 2006 03:00:00 +0000 (GMT) From: Manav Bhatia To: isis-wg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.9 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Manav Bhatia List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Hi, We have written a draft on extending ISIS to use HMAC-SHA authentication. Would appreciate if we can get some feedback from the WG. The mechanism proposed in the draft is backward compatible and would work with the existing ISIS implementations. Cheers, Manav ----- Forwarded Message ---- From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Sent: Wednesday, April 19, 2006 4:20:01 AM Subject: I-D ACTION:draft-bhatia-manral-isis-hmac-sha-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IS-IS HMAC SHA Cryptographic Authentication Author(s) : M. Bhatia, V. Manral Filename : draft-bhatia-manral-isis-hmac-sha-00.txt Pages : 8 Date : 2006-4-18 This document proposes an extension to IS-IS [ISO] [RFC1195] to allow the use of HMAC SHA authentication algorithm in addition to the already documented authentication schemes described in the base specification and RFC 3567. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bhatia-manral-isis-hmac-sha-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. [clipped] _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Apr 19 14:05:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWH2k-0001N3-Bu; Wed, 19 Apr 2006 14:04:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWH2j-0001My-TQ for isis-wg@ietf.org; Wed, 19 Apr 2006 14:04:45 -0400 Received: from webmail-outgoing2.us4.outblaze.com ([205.158.62.67] helo=webmail-outgoing.us4.outblaze.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWH2h-0007av-IB for isis-wg@ietf.org; Wed, 19 Apr 2006 14:04:45 -0400 Received: from unknown (unknown [192.168.9.180]) by webmail-outgoing.us4.outblaze.com (Postfix) with QMQP id F078A1800E50 for ; Wed, 19 Apr 2006 18:04:42 +0000 (GMT) X-OB-Received: from unknown (208.36.123.33) by wfilter.us4.outblaze.com; 19 Apr 2006 17:39:10 -0000 Received: by ws7-4.us4.outblaze.com (Postfix, from userid 1001) id 8B35DCA0B2; Wed, 19 Apr 2006 18:04:28 +0000 (GMT) Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 From: "Sofia Ray" To: isis-wg@ietf.org Date: Wed, 19 Apr 2006 13:04:28 -0500 Subject: Re: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication Received: from [202.144.106.189] by ws7-4.us4.outblaze.com with http for sofia.ray@lycos.com; Wed, 19 Apr 2006 13:04:28 -0500 X-Originating-Ip: 202.144.106.189 X-Originating-Server: ws7-4.us4.outblaze.com Message-Id: <20060419180428.8B35DCA0B2@ws7-4.us4.outblaze.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Manav, Whats wrong with the authentication scheme detailed in 3567? Yours, Sofia ----- Original Message ---- From: Manav Bhatia To: isis-wg@ietf.org Sent: Wednesday, 19 April, 2006 8:30:00 AM Subject: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication Hi, We have written a draft on extending ISIS to use HMAC-SHA authentication. W= ould appreciate if we can get some feedback from the WG. The mechanism prop= osed in the draft is backward compatible and would work with the existing I= SIS implementations. Cheers, Manav ----- Forwarded Message ---- From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Sent: Wednesday, April 19, 2006 4:20:01 AM Subject: I-D ACTION:draft-bhatia-manral-isis-hmac-sha-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : IS-IS HMAC SHA Cryptographic Authentication Author(s) : M. Bhatia, V. Manral Filename : draft-bhatia-manral-isis-hmac-sha-00.txt Pages : 8 Date : 2006-4-18 This document proposes an extension to IS-IS [ISO] [RFC1195] to allow the u= se of HMAC SHA authentication algorithm in addition to the already document= ed authentication schemes described in the base specification and RFC 3567. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bhatia-manral-isis-hmac-sha-00.txt --=20 _______________________________________________ Search for businesses by name, location, or phone number. -Lycos Yellow Pa= ges http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.as= p?SRC=3Dlycos10 _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Apr 19 14:17:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWHFQ-0004ad-53; Wed, 19 Apr 2006 14:17:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWHFO-0004aY-Tf for isis-wg@ietf.org; Wed, 19 Apr 2006 14:17:50 -0400 Received: from iceblock01.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FWHFO-0008LA-Fi for isis-wg@ietf.org; Wed, 19 Apr 2006 14:17:50 -0400 Received: (qmail 30043 invoked from network); 19 Apr 2006 18:14:34 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on iceblock01 X-Spam-Level: X-Spam-Status: No, score=-104.3 required=6.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.0 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 19 Apr 2006 18:14:33 -0000 Received: from LIPC ([192.168.1.141]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Apr 2006 11:17:26 -0700 From: "Tony Li" To: "'Sofia Ray'" , Subject: RE: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication Date: Wed, 19 Apr 2006 11:17:34 -0700 Message-ID: <006d01c663dd$87e23930$4b7d14ac@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20060419180428.8B35DCA0B2@ws7-4.us4.outblaze.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZj29PbJA/iTaOAT92RJ6uB2XNZ1wAATF/Q X-OriginalArrivalTime: 19 Apr 2006 18:17:26.0710 (UTC) FILETIME=[8338D560:01C663DD] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Sofia, While I know of no substantive risks to the use of MD5 today as used in 3567, history suggests that someday, there will be. Thus, having other algorithms available is only prudent and I strongly support that goal. Regards, Tony > -----Original Message----- > From: Sofia Ray [mailto:sofia.ray@lycos.com] > Sent: Wednesday, April 19, 2006 11:04 AM > To: isis-wg@ietf.org > Subject: Re: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication > > Manav, > > Whats wrong with the authentication scheme detailed in 3567? > > Yours, > Sofia > > ----- Original Message ---- > From: Manav Bhatia > To: isis-wg@ietf.org > Sent: Wednesday, 19 April, 2006 8:30:00 AM > Subject: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication > > > Hi, > > We have written a draft on extending ISIS to use HMAC-SHA > authentication. Would appreciate if we can get some feedback > from the WG. The mechanism proposed in the draft is backward > compatible and would work with the existing ISIS implementations. > > Cheers, > Manav > > ----- Forwarded Message ---- > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Sent: Wednesday, April 19, 2006 4:20:01 AM > Subject: I-D ACTION:draft-bhatia-manral-isis-hmac-sha-00.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > Title : IS-IS HMAC SHA Cryptographic Authentication > Author(s) : M. Bhatia, V. Manral > Filename : draft-bhatia-manral-isis-hmac-sha-00.txt > Pages : 8 > Date : 2006-4-18 > > This document proposes an extension to IS-IS [ISO] [RFC1195] > to allow the use of HMAC SHA authentication algorithm in > addition to the already documented authentication schemes > described in the base specification and RFC 3567. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bhatia-manral-isis-h > mac-sha-00.txt > > > > -- > _______________________________________________ > > Search for businesses by name, location, or phone number. > -Lycos Yellow Pages > > http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.c > om/default.asp?SRC=lycos10 > > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Apr 19 16:16:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWJ5q-0005Uk-BB; Wed, 19 Apr 2006 16:16:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWJ5o-0005US-MC for isis-wg@ietf.org; Wed, 19 Apr 2006 16:16:04 -0400 Received: from iceblock01.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FWJ5o-0005e2-6J for isis-wg@ietf.org; Wed, 19 Apr 2006 16:16:04 -0400 Received: (qmail 7786 invoked from network); 19 Apr 2006 20:12:59 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on iceblock01 X-Spam-Level: X-Spam-Status: No, score=-104.3 required=6.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.0 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 19 Apr 2006 20:12:53 -0000 Received: from LIPC ([192.168.1.141]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Apr 2006 13:15:47 -0700 From: "Tony Li" To: "'Hannes Gredler'" , Subject: RE: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication Date: Wed, 19 Apr 2006 13:15:54 -0700 Message-ID: <009801c663ee$0fb8bf90$4b7d14ac@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4446972F.6040408@juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZj7CYkkgPoCKT1RNulB63yK70NIgAAHVzw X-OriginalArrivalTime: 19 Apr 2006 20:15:47.0013 (UTC) FILETIME=[0B551750:01C663EE] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Hannes, I'm of the opinion that key rollover and algorithm rollover do not require actual additional protocol specification and that transmitting multiple TLVs is not necessary. For any form of rollover to work, a receiver must be prepared to accept multiple different combinations of password and algorithm. It does not seem like a substantial effort for the receiver to try all of the possibilities that it is configured for. Given this, one way to do smooth rollover is to go around and configure all nodes with the new password and/or algorithm. Once that's completed and in production, then nodes can be set to transmit the new password and/or algorithm. While 802.11's WEP is hardly a good example of this for security purposes, most implementations provide a fine example of how the UI for this would work: one key is used for transmit, while a list of keys is accepted. Regards, Tony P.s. Yes, I'm well aware that implementations do not currently support this behavior and will have to change. Including Juniper's. Sorry. ;-) > -----Original Message----- > From: Hannes Gredler [mailto:hannes@juniper.net] > Sent: Wednesday, April 19, 2006 1:02 PM > To: tony.li@tony.li > Cc: 'Sofia Ray'; isis-wg@ietf.org > Subject: Re: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication > > furthermore, it would be also time to think about authentication-type > migration support. i.e. discuss about authentication-type > [simple->md5->sha] > and key rollover schemes and nail down the necessary behaviour > (multiple instances of TLV #10). > > the prevailing method for both authentication-type and key rollover > (= disabling authentication check during the transition window) > is not really smooth. > > /hannes > > Tony Li wrote: > > Sofia, > > > > While I know of no substantive risks to the use of MD5 > today as used in > > 3567, history suggests that someday, there will be. Thus, > having other > > algorithms available is only prudent and I strongly support > that goal. > > > > Regards, > > Tony > > > > > >>-----Original Message----- > >>From: Sofia Ray [mailto:sofia.ray@lycos.com] > >>Sent: Wednesday, April 19, 2006 11:04 AM > >>To: isis-wg@ietf.org > >>Subject: Re: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication > >> > >>Manav, > >> > >>Whats wrong with the authentication scheme detailed in 3567? > >> > >>Yours, > >>Sofia > >> > >>----- Original Message ---- > >>From: Manav Bhatia > >>To: isis-wg@ietf.org > >>Sent: Wednesday, 19 April, 2006 8:30:00 AM > >>Subject: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication > >> > >> > >>Hi, > >> > >>We have written a draft on extending ISIS to use HMAC-SHA > >>authentication. Would appreciate if we can get some feedback > >>from the WG. The mechanism proposed in the draft is backward > >>compatible and would work with the existing ISIS implementations. > >> > >>Cheers, > >>Manav > >> > >>----- Forwarded Message ---- > >>From: Internet-Drafts@ietf.org > >>To: i-d-announce@ietf.org > >>Sent: Wednesday, April 19, 2006 4:20:01 AM > >>Subject: I-D ACTION:draft-bhatia-manral-isis-hmac-sha-00.txt > >> > >>A New Internet-Draft is available from the on-line > >>Internet-Drafts directories. > >> > >> Title : IS-IS HMAC SHA Cryptographic Authentication > >> Author(s) : M. Bhatia, V. Manral > >> Filename : draft-bhatia-manral-isis-hmac-sha-00.txt > >> Pages : 8 > >> Date : 2006-4-18 > >> > >>This document proposes an extension to IS-IS [ISO] [RFC1195] > >>to allow the use of HMAC SHA authentication algorithm in > >>addition to the already documented authentication schemes > >>described in the base specification and RFC 3567. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-bhatia-manral-isis-h > >>mac-sha-00.txt > >> > >> > >> > >>-- > >>_______________________________________________ > >> > >>Search for businesses by name, location, or phone number. > >>-Lycos Yellow Pages > >> > >>http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.c > >>om/default.asp?SRC=lycos10 > >> > >> > >>_______________________________________________ > >>Isis-wg mailing list > >>Isis-wg@ietf.org > >>https://www1.ietf.org/mailman/listinfo/isis-wg > >> > > > > > > > > > > _______________________________________________ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www1.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Apr 19 16:58:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWJks-0002cG-GT; Wed, 19 Apr 2006 16:58:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWJkr-0002c6-OT for isis-wg@ietf.org; Wed, 19 Apr 2006 16:58:29 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWJ37-0005KZ-Kr for isis-wg@ietf.org; Wed, 19 Apr 2006 16:13:17 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FWIsP-0000XR-1y for isis-wg@ietf.org; Wed, 19 Apr 2006 16:02:15 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 19 Apr 2006 13:02:01 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,136,1144047600"; d="scan'208"; a="541036073:sNHT25542824" Received: from [172.26.200.193] ([172.26.200.193]) by beta.jnpr.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Apr 2006 13:01:59 -0700 Message-ID: <4446972F.6040408@juniper.net> Date: Wed, 19 Apr 2006 22:01:51 +0200 From: Hannes Gredler User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050815) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tony.li@tony.li Subject: Re: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication References: <006d01c663dd$87e23930$4b7d14ac@tropos.com> In-Reply-To: <006d01c663dd$87e23930$4b7d14ac@tropos.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Apr 2006 20:01:59.0945 (UTC) FILETIME=[1E5C8790:01C663EC] X-Spam-Score: -2.6 (--) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org furthermore, it would be also time to think about authentication-type migration support. i.e. discuss about authentication-type [simple->md5->sha] and key rollover schemes and nail down the necessary behaviour (multiple instances of TLV #10). the prevailing method for both authentication-type and key rollover (= disabling authentication check during the transition window) is not really smooth. /hannes Tony Li wrote: > Sofia, > > While I know of no substantive risks to the use of MD5 today as used in > 3567, history suggests that someday, there will be. Thus, having other > algorithms available is only prudent and I strongly support that goal. > > Regards, > Tony > > >>-----Original Message----- >>From: Sofia Ray [mailto:sofia.ray@lycos.com] >>Sent: Wednesday, April 19, 2006 11:04 AM >>To: isis-wg@ietf.org >>Subject: Re: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication >> >>Manav, >> >>Whats wrong with the authentication scheme detailed in 3567? >> >>Yours, >>Sofia >> >>----- Original Message ---- >>From: Manav Bhatia >>To: isis-wg@ietf.org >>Sent: Wednesday, 19 April, 2006 8:30:00 AM >>Subject: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication >> >> >>Hi, >> >>We have written a draft on extending ISIS to use HMAC-SHA >>authentication. Would appreciate if we can get some feedback >>from the WG. The mechanism proposed in the draft is backward >>compatible and would work with the existing ISIS implementations. >> >>Cheers, >>Manav >> >>----- Forwarded Message ---- >>From: Internet-Drafts@ietf.org >>To: i-d-announce@ietf.org >>Sent: Wednesday, April 19, 2006 4:20:01 AM >>Subject: I-D ACTION:draft-bhatia-manral-isis-hmac-sha-00.txt >> >>A New Internet-Draft is available from the on-line >>Internet-Drafts directories. >> >> Title : IS-IS HMAC SHA Cryptographic Authentication >> Author(s) : M. Bhatia, V. Manral >> Filename : draft-bhatia-manral-isis-hmac-sha-00.txt >> Pages : 8 >> Date : 2006-4-18 >> >>This document proposes an extension to IS-IS [ISO] [RFC1195] >>to allow the use of HMAC SHA authentication algorithm in >>addition to the already documented authentication schemes >>described in the base specification and RFC 3567. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-bhatia-manral-isis-h >>mac-sha-00.txt >> >> >> >>-- >>_______________________________________________ >> >>Search for businesses by name, location, or phone number. >>-Lycos Yellow Pages >> >>http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.c >>om/default.asp?SRC=lycos10 >> >> >>_______________________________________________ >>Isis-wg mailing list >>Isis-wg@ietf.org >>https://www1.ietf.org/mailman/listinfo/isis-wg >> > > > > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Apr 19 20:39:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWNC9-0000O9-Vo; Wed, 19 Apr 2006 20:38:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWNC7-0000J9-Ds; Wed, 19 Apr 2006 20:38:51 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWNC6-0001xQ-2M; Wed, 19 Apr 2006 20:38:51 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k3K0cnwG019173; Wed, 19 Apr 2006 17:38:49 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k3K0cnvq019172; Wed, 19 Apr 2006 17:38:49 -0700 Date: Wed, 19 Apr 2006 17:38:49 -0700 Message-Id: <200604200038.k3K0cnvq019172@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: isis-wg@ietf.org, rfc-editor@rfc-editor.org Subject: [Isis-wg] RFC 4444 on Management Information Base for Intermediate System to Intermediate System (IS-IS) X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4444 Title: Management Information Base for Intermediate System to Intermediate System (IS-IS) Author: J. Parker, Ed. Status: Standards Track Date: April 2006 Mailbox: jeffp@middlebury.edu Pages: 103 Characters: 181968 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-isis-wg-mib-26.txt URL: http://www.rfc-editor.org/rfc/rfc4444.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this document describes a MIB for the Intermediate System to Intermediate System (IS-IS) Routing protocol when it is used to construct routing tables for IP networks. [STANDARDS TRACK] This document is a product of the IS-IS for IP Internets Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Apr 19 23:13:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWPbR-0004SR-Kf; Wed, 19 Apr 2006 23:13:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWPbP-0004SG-Po for isis-wg@ietf.org; Wed, 19 Apr 2006 23:13:07 -0400 Received: from web25407.mail.ukl.yahoo.com ([217.12.10.141]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FWPbO-000264-99 for isis-wg@ietf.org; Wed, 19 Apr 2006 23:13:07 -0400 Received: (qmail 56137 invoked by uid 60001); 20 Apr 2006 03:13:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=RuRrqMGlBV1tdXbsbyk7KIAGQ+Q78Fx0q/KjI92m+MIqtdrEh9adJJrDPyodm+9BMJQxRqbYGn9KN8d/3smL05sJ9CxtglXCOQbKFqPAI83qiiM4oRDmDv6wMGJkqEML9DM6BZO1gZ/PlFfWmFt5azzyal8JTHawmanMW3+Hg+c= ; Message-ID: <20060420031300.56131.qmail@web25407.mail.ukl.yahoo.com> Date: Thu, 20 Apr 2006 03:13:00 +0000 (GMT) From: Manav Bhatia Subject: Re: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication To: tony.li@tony.li, Hannes Gredler In-Reply-To: <009801c663ee$0fb8bf90$4b7d14ac@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.9 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Manav Bhatia List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org I would agree with Tony and i dont think advertising multiple instances of TLV 10 is required. OTOH, i see a potential problem with including multiple TLVs as that can lead to a simple Dos attack wherein the sender puts multiple TLVs and the receiving router gets overwhelmed processing each one of those. The idea of including multiple TLVs was discussed when we were writing this draft and it was rejected because of the reason stated above. If you notice we send the Key ID in the TLV 10. Doing this can help us during Key rollover wherein we can have multiple keys configured and the receiver only needs to verify the packet with the key associated with the given Key ID. Not doing this can be CPU intensive for the receiving router during the Key rollover when multiple keys are configured and random packets are sent in. Cheers, Manav ----- Original Message ---- From: Tony Li To: Hannes Gredler ; tony.li@tony.li Cc: isis-wg@ietf.org Sent: Thursday, 20 April, 2006 1:45:54 AM Subject: RE: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication Hannes, I'm of the opinion that key rollover and algorithm rollover do not require actual additional protocol specification and that transmitting multiple TLVs is not necessary. For any form of rollover to work, a receiver must be prepared to accept multiple different combinations of password and algorithm. It does not seem like a substantial effort for the receiver to try all of the possibilities that it is configured for. Given this, one way to do smooth rollover is to go around and configure all nodes with the new password and/or algorithm. Once that's completed and in production, then nodes can be set to transmit the new password and/or algorithm. While 802.11's WEP is hardly a good example of this for security purposes, most implementations provide a fine example of how the UI for this would work: one key is used for transmit, while a list of keys is accepted. Regards, Tony P.s. Yes, I'm well aware that implementations do not currently support this behavior and will have to change. Including Juniper's. Sorry. ;-) > -----Original Message----- > From: Hannes Gredler [mailto:hannes@juniper.net] > Sent: Wednesday, April 19, 2006 1:02 PM > To: tony.li@tony.li > Cc: 'Sofia Ray'; isis-wg@ietf.org > Subject: Re: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication > > furthermore, it would be also time to think about authentication-type > migration support. i.e. discuss about authentication-type > [simple->md5->sha] > and key rollover schemes and nail down the necessary behaviour > (multiple instances of TLV #10). > > the prevailing method for both authentication-type and key rollover > (= disabling authentication check during the transition window) > is not really smooth. > > /hannes > > Tony Li wrote: > > Sofia, > > > > While I know of no substantive risks to the use of MD5 > today as used in > > 3567, history suggests that someday, there will be. Thus, > having other > > algorithms available is only prudent and I strongly support > that goal. > > > > Regards, > > Tony > > > > > >>-----Original Message----- > >>From: Sofia Ray [mailto:sofia.ray@lycos.com] > >>Sent: Wednesday, April 19, 2006 11:04 AM > >>To: isis-wg@ietf.org > >>Subject: Re: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication > >> > >>Manav, > >> > >>Whats wrong with the authentication scheme detailed in 3567? > >> > >>Yours, > >>Sofia > >> > >>----- Original Message ---- > >>From: Manav Bhatia > >>To: isis-wg@ietf.org > >>Sent: Wednesday, 19 April, 2006 8:30:00 AM > >>Subject: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication > >> > >> > >>Hi, > >> > >>We have written a draft on extending ISIS to use HMAC-SHA > >>authentication. Would appreciate if we can get some feedback > >>from the WG. The mechanism proposed in the draft is backward > >>compatible and would work with the existing ISIS implementations. > >> > >>Cheers, > >>Manav > >> > >>----- Forwarded Message ---- > >>From: Internet-Drafts@ietf.org > >>To: i-d-announce@ietf.org > >>Sent: Wednesday, April 19, 2006 4:20:01 AM > >>Subject: I-D ACTION:draft-bhatia-manral-isis-hmac-sha-00.txt > >> > >>A New Internet-Draft is available from the on-line > >>Internet-Drafts directories. > >> > >> Title : IS-IS HMAC SHA Cryptographic Authentication > >> Author(s) : M. Bhatia, V. Manral > >> Filename : draft-bhatia-manral-isis-hmac-sha-00.txt > >> Pages : 8 > >> Date : 2006-4-18 > >> > >>This document proposes an extension to IS-IS [ISO] [RFC1195] > >>to allow the use of HMAC SHA authentication algorithm in > >>addition to the already documented authentication schemes > >>described in the base specification and RFC 3567. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-bhatia-manral-isis-h > >>mac-sha-00.txt > >> > >> > >> > >>-- > >>_______________________________________________ > >> > >>Search for businesses by name, location, or phone number. > >>-Lycos Yellow Pages > >> > >>http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.c > >>om/default.asp?SRC=lycos10 > >> > >> > >>_______________________________________________ > >>Isis-wg mailing list > >>Isis-wg@ietf.org > >>https://www1.ietf.org/mailman/listinfo/isis-wg > >> > > > > > > > > > > _______________________________________________ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www1.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Apr 20 02:50:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWSz3-0006S0-Tv; Thu, 20 Apr 2006 02:49:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWSz2-0006Rv-5G for isis-wg@ietf.org; Thu, 20 Apr 2006 02:49:44 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWSyy-0003gh-AL for isis-wg@ietf.org; Thu, 20 Apr 2006 02:49:43 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 20 Apr 2006 08:49:40 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3K6ncUE014304; Thu, 20 Apr 2006 08:49:38 +0200 (MEST) Received: from mshand-wxp.cisco.com (ams3-vpn-dhcp4195.cisco.com [10.61.80.98]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id HAA14102; Thu, 20 Apr 2006 07:49:37 +0100 (BST) Message-Id: <7.0.1.0.0.20060420074715.03c42cc8@cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 20 Apr 2006 07:49:35 +0100 To: tony.li@tony.li From: mike shand Subject: RE: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication In-Reply-To: <009801c663ee$0fb8bf90$4b7d14ac@tropos.com> References: <4446972F.6040408@juniper.net> <009801c663ee$0fb8bf90$4b7d14ac@tropos.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: 'Hannes Gredler' , tony.li@tony.li, isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org At 21:15 19/04/2006, Tony Li wrote: > >Hannes, > >I'm of the opinion that key rollover and algorithm rollover do not >require actual additional protocol specification and that transmitting >multiple TLVs is not necessary. For any form of rollover to work, a >receiver must be prepared to accept multiple different combinations of >password and algorithm. It does not seem like a substantial effort for >the receiver to try all of the possibilities that it is configured for. Absolutely. That was the way it was designed to work in the original form with non-cryptographic passwords (multiple receive passwords could be specified to allow migration), and I don't see why the same principle shouldn't apply to algorithm migration. Mike >Given this, one way to do smooth rollover is to go around and configure >all nodes with the new password and/or algorithm. Once that's completed >and in production, then nodes can be set to transmit the new password >and/or algorithm. > >While 802.11's WEP is hardly a good example of this for security >purposes, most implementations provide a fine example of how the UI for >this would work: one key is used for transmit, while a list of keys is >accepted. > >Regards, >Tony > >P.s. Yes, I'm well aware that implementations do not currently support >this behavior and will have to change. Including Juniper's. Sorry. >;-) > > > > -----Original Message----- > > From: Hannes Gredler [mailto:hannes@juniper.net] > > Sent: Wednesday, April 19, 2006 1:02 PM > > To: tony.li@tony.li > > Cc: 'Sofia Ray'; isis-wg@ietf.org > > Subject: Re: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication > > > > furthermore, it would be also time to think about authentication-type > > migration support. i.e. discuss about authentication-type > > [simple->md5->sha] > > and key rollover schemes and nail down the necessary behaviour > > (multiple instances of TLV #10). > > > > the prevailing method for both authentication-type and key rollover > > (= disabling authentication check during the transition window) > > is not really smooth. > > > > /hannes > > > > Tony Li wrote: > > > Sofia, > > > > > > While I know of no substantive risks to the use of MD5 > > today as used in > > > 3567, history suggests that someday, there will be. Thus, > > having other > > > algorithms available is only prudent and I strongly support > > that goal. > > > > > > Regards, > > > Tony > > > > > > > > >>-----Original Message----- > > >>From: Sofia Ray [mailto:sofia.ray@lycos.com] > > >>Sent: Wednesday, April 19, 2006 11:04 AM > > >>To: isis-wg@ietf.org > > >>Subject: Re: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication > > >> > > >>Manav, > > >> > > >>Whats wrong with the authentication scheme detailed in 3567? > > >> > > >>Yours, > > >>Sofia > > >> > > >>----- Original Message ---- > > >>From: Manav Bhatia > > >>To: isis-wg@ietf.org > > >>Sent: Wednesday, 19 April, 2006 8:30:00 AM > > >>Subject: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication > > >> > > >> > > >>Hi, > > >> > > >>We have written a draft on extending ISIS to use HMAC-SHA > > >>authentication. Would appreciate if we can get some feedback > > >>from the WG. The mechanism proposed in the draft is backward > > >>compatible and would work with the existing ISIS implementations. > > >> > > >>Cheers, > > >>Manav > > >> > > >>----- Forwarded Message ---- > > >>From: Internet-Drafts@ietf.org > > >>To: i-d-announce@ietf.org > > >>Sent: Wednesday, April 19, 2006 4:20:01 AM > > >>Subject: I-D ACTION:draft-bhatia-manral-isis-hmac-sha-00.txt > > >> > > >>A New Internet-Draft is available from the on-line > > >>Internet-Drafts directories. > > >> > > >> Title : IS-IS HMAC SHA Cryptographic Authentication > > >> Author(s) : M. Bhatia, V. Manral > > >> Filename : draft-bhatia-manral-isis-hmac-sha-00.txt > > >> Pages : 8 > > >> Date : 2006-4-18 > > >> > > >>This document proposes an extension to IS-IS [ISO] [RFC1195] > > >>to allow the use of HMAC SHA authentication algorithm in > > >>addition to the already documented authentication schemes > > >>described in the base specification and RFC 3567. > > >> > > >>A URL for this Internet-Draft is: > > >>http://www.ietf.org/internet-drafts/draft-bhatia-manral-isis-h > > >>mac-sha-00.txt > > >> > > >> > > >> > > >>-- > > >>_______________________________________________ > > >> > > >>Search for businesses by name, location, or phone number. > > >>-Lycos Yellow Pages > > >> > > >>http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.c > > >>om/default.asp?SRC=lycos10 > > >> > > >> > > >>_______________________________________________ > > >>Isis-wg mailing list > > >>Isis-wg@ietf.org > > >>https://www1.ietf.org/mailman/listinfo/isis-wg > > >> > > > > > > > > > > > > > > > _______________________________________________ > > > Isis-wg mailing list > > > Isis-wg@ietf.org > > > https://www1.ietf.org/mailman/listinfo/isis-wg > > > > > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Apr 20 03:27:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWTZq-0008WN-Cx; Thu, 20 Apr 2006 03:27:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWTZf-0008NT-49 for isis-wg@ietf.org; Thu, 20 Apr 2006 03:27:35 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWTNL-0004wl-5J for isis-wg@ietf.org; Thu, 20 Apr 2006 03:14:54 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by borg.juniper.net with ESMTP; 20 Apr 2006 00:14:51 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,138,1144047600"; d="scan'208"; a="544672248:sNHT25416548" Received: from [172.26.200.193] ([172.26.200.193]) by beta.jnpr.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 00:10:44 -0700 Message-ID: <444733EC.8070001@juniper.net> Date: Thu, 20 Apr 2006 09:10:36 +0200 From: Hannes Gredler User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050815) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tony.li@tony.li Subject: Re: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication References: <009801c663ee$0fb8bf90$4b7d14ac@tropos.com> In-Reply-To: <009801c663ee$0fb8bf90$4b7d14ac@tropos.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Apr 2006 07:10:45.0620 (UTC) FILETIME=[8B20A340:01C66449] X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org tony, your suggested form of key rollover (all receivers can authenticate against the new transmit-key) is certainly a working model, however it is not the most convenient model from a network operator perspective. lets assume we start to configure the network with new authentication keys. There is a time window (until all routers have the new authentication key) where the routers holding the new key are using that key and other routers have not yet got the new key and hence nothing to verify against. so what you require is some form of coordination i.e. to have all nodes hold off using the new transmit key up until the network is fully transitioned (i have seen implementations who achieve that with time/date based transmit key-selection) -> this requires some form of coordination (timestamp / key lifetime etc.) back to the original idea - multiple instances of TLV #10 don't require time-based transmit key selection, since the PDU contains everybody's key of taste, which would IMO be more migration friendly. BTW the "protocol extension" that i have in mind to make this work is rather straightforward: clear all instances of TLV #10 to zero before computing the digest of a single TLV #10 and doing of course the same on reception. /hannes Tony Li wrote: > > Hannes, > > I'm of the opinion that key rollover and algorithm rollover do not > require actual additional protocol specification and that transmitting > multiple TLVs is not necessary. For any form of rollover to work, a > receiver must be prepared to accept multiple different combinations of > password and algorithm. It does not seem like a substantial effort for > the receiver to try all of the possibilities that it is configured for. > > Given this, one way to do smooth rollover is to go around and configure > all nodes with the new password and/or algorithm. Once that's completed > and in production, then nodes can be set to transmit the new password > and/or algorithm. > > While 802.11's WEP is hardly a good example of this for security > purposes, most implementations provide a fine example of how the UI for > this would work: one key is used for transmit, while a list of keys is > accepted. > > Regards, > Tony > > P.s. Yes, I'm well aware that implementations do not currently support > this behavior and will have to change. Including Juniper's. Sorry. > ;-) > > > >>-----Original Message----- >>From: Hannes Gredler [mailto:hannes@juniper.net] >>Sent: Wednesday, April 19, 2006 1:02 PM >>To: tony.li@tony.li >>Cc: 'Sofia Ray'; isis-wg@ietf.org >>Subject: Re: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication >> >>furthermore, it would be also time to think about authentication-type >>migration support. i.e. discuss about authentication-type >>[simple->md5->sha] >>and key rollover schemes and nail down the necessary behaviour >>(multiple instances of TLV #10). >> >>the prevailing method for both authentication-type and key rollover >>(= disabling authentication check during the transition window) >>is not really smooth. >> >>/hannes >> >>Tony Li wrote: >> >>>Sofia, >>> >>>While I know of no substantive risks to the use of MD5 >> >>today as used in >> >>>3567, history suggests that someday, there will be. Thus, >> >>having other >> >>>algorithms available is only prudent and I strongly support >> >>that goal. >> >>>Regards, >>>Tony >>> >>> >>> >>>>-----Original Message----- >>>>From: Sofia Ray [mailto:sofia.ray@lycos.com] >>>>Sent: Wednesday, April 19, 2006 11:04 AM >>>>To: isis-wg@ietf.org >>>>Subject: Re: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication >>>> >>>>Manav, >>>> >>>>Whats wrong with the authentication scheme detailed in 3567? >>>> >>>>Yours, >>>>Sofia >>>> >>>>----- Original Message ---- >>>>From: Manav Bhatia >>>>To: isis-wg@ietf.org >>>>Sent: Wednesday, 19 April, 2006 8:30:00 AM >>>>Subject: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication >>>> >>>> >>>>Hi, >>>> >>>>We have written a draft on extending ISIS to use HMAC-SHA >>>>authentication. Would appreciate if we can get some feedback >>> >>>>from the WG. The mechanism proposed in the draft is backward >>> >>>>compatible and would work with the existing ISIS implementations. >>>> >>>>Cheers, >>>>Manav >>>> >>>>----- Forwarded Message ---- >>>>From: Internet-Drafts@ietf.org >>>>To: i-d-announce@ietf.org >>>>Sent: Wednesday, April 19, 2006 4:20:01 AM >>>>Subject: I-D ACTION:draft-bhatia-manral-isis-hmac-sha-00.txt >>>> >>>>A New Internet-Draft is available from the on-line >>>>Internet-Drafts directories. >>>> >>>> Title : IS-IS HMAC SHA Cryptographic Authentication >>>> Author(s) : M. Bhatia, V. Manral >>>> Filename : draft-bhatia-manral-isis-hmac-sha-00.txt >>>> Pages : 8 >>>> Date : 2006-4-18 >>>> >>>>This document proposes an extension to IS-IS [ISO] [RFC1195] >>>>to allow the use of HMAC SHA authentication algorithm in >>>>addition to the already documented authentication schemes >>>>described in the base specification and RFC 3567. >>>> >>>>A URL for this Internet-Draft is: >>>>http://www.ietf.org/internet-drafts/draft-bhatia-manral-isis-h >>>>mac-sha-00.txt >>>> >>>> >>>> >>>>-- >>>>_______________________________________________ >>>> >>>>Search for businesses by name, location, or phone number. >>>>-Lycos Yellow Pages >>>> >>>>http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.c >>>>om/default.asp?SRC=lycos10 >>>> >>>> >>>>_______________________________________________ >>>>Isis-wg mailing list >>>>Isis-wg@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/isis-wg >>>> >>> >>> >>> >>> >>>_______________________________________________ >>>Isis-wg mailing list >>>Isis-wg@ietf.org >>>https://www1.ietf.org/mailman/listinfo/isis-wg >> > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Apr 20 13:09:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWceo-0007uM-TF; Thu, 20 Apr 2006 13:09:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWceo-0007uH-2A for isis-wg@ietf.org; Thu, 20 Apr 2006 13:09:30 -0400 Received: from webmail.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FWcem-0002l4-OG for isis-wg@ietf.org; Thu, 20 Apr 2006 13:09:30 -0400 Received: (qmail 3788 invoked from network); 20 Apr 2006 17:06:21 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on iceblock01 X-Spam-Level: X-Spam-Status: No, score=-104.3 required=6.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.0 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 20 Apr 2006 17:06:20 -0000 Received: from LIPC ([192.168.1.141]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 10:09:17 -0700 From: "Tony Li" To: "'Hannes Gredler'" , Subject: RE: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication Date: Thu, 20 Apr 2006 10:09:22 -0700 Message-ID: <004e01c6649d$2b61ca70$8d01a8c0@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <444733EC.8070001@juniper.net> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZkS6pao1t5jtJoT6+GSt1vEVJj+AAUN3gw X-OriginalArrivalTime: 20 Apr 2006 17:09:17.0232 (UTC) FILETIME=[281DC300:01C6649D] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Hannes, > There is a time window (until all routers have the new > authentication key) where the routers holding the new key are > using that key and other routers have not yet got the new key > and hence nothing to verify against. > > so what you require is some form of coordination i.e. > to have all nodes hold off using the new transmit key > up until the network is fully transitioned > (i have seen implementations who achieve that with > time/date based transmit key-selection) -> this requires > some form of coordination (timestamp / key lifetime etc.) Nothing more sophisticated than uniform configuration is required. The first configuration pass installs the new key and enables it for reception. The second configuration pass switches to using the new key for transmission. Those who want to be pedantic can include a third pass to remove the old key. Given the widespread deployment of homegrown tools for consistent, distributed router configuration, I don't see this as a significant hurdle. Tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Apr 20 18:50:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWhyX-00041n-4S; Thu, 20 Apr 2006 18:50:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWhyM-0003uP-Qv; Thu, 20 Apr 2006 18:50:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWhyM-0003Ig-71; Thu, 20 Apr 2006 18:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k3KMo1vP011170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Apr 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FWhyL-0003tR-Qk; Thu, 20 Apr 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 20 Apr 2006 18:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-igp-p2p-over-lan-06.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Point-to-point operation over LAN in link-state routing protocols Author(s) : N. Shen, et al. Filename : draft-ietf-isis-igp-p2p-over-lan-06.txt Pages : 10 Date : 2006-4-20 The two predominant circuit types used by link state routing protocols are point-to-point and broadcast. It is important to identify the correct circuit type when forming adjacencies, flooding link state database packets, and representing the circuit topologically. This document describes a simple mechanism to treat the broadcast network as a point-to-point connection from the standpoint of IP routing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-igp-p2p-over-lan-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-igp-p2p-over-lan-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-igp-p2p-over-lan-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-20153241.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-igp-p2p-over-lan-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-igp-p2p-over-lan-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-20153241.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --NextPart-- From isis-wg-bounces@ietf.org Fri Apr 21 21:17:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX6kk-0005Vm-HE; Fri, 21 Apr 2006 21:17:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX6kj-0005Vh-13 for isis-wg@ietf.org; Fri, 21 Apr 2006 21:17:37 -0400 Received: from mail.ipinfusion.com ([65.223.109.2] helo=gateway.ipinfusion.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX6kh-0004U9-Kx for isis-wg@ietf.org; Fri, 21 Apr 2006 21:17:37 -0400 Received: from [10.10.3.72] (vishwas.eng.ipinfusion.com [10.10.3.72]) by gateway.ipinfusion.com (8.11.6/8.11.6) with ESMTP id k3M1H7826412 for ; Fri, 21 Apr 2006 18:17:07 -0700 Message-ID: <4449861F.1070608@ipinfusion.com> Date: Fri, 21 Apr 2006 18:25:51 -0700 From: Vishwas Manral Organization: IPInfusion User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: isis-wg@ietf.org Subject: RE: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vishwas@ipinfusion.com List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Hi Hannes, I mostly agree with Tony here, except for a very corner case where we can amplify a DoS because we have multiple keys to choose between at the receiver during Key Rollover. The point that you bring is an intersting point about KeyRollover. A simple way to do it is to also have the Key-Id (opaque value) sent by the sender. The sender when doing a key rollover will use a different Key ID(which is shared with the receiver). As the receiver will have the key with the same Key-ID it can use that key for calculating the Hash. We will not have to compute the hash with multiple keys which are valid in such a case. The Key lifetime by itself is a very implementation thing(with no effect for interoperability). On another note, as we may now have multiple authentication algorithms to support for any protocol, should we also have an RFC like 4305 for IPsec? That way we do not need to change an RFC which tells about how to use an algorithm(HMAC-SHA1) with IS-IS, but still change the status of algorithm support (e.g. MUST to MAY etc). I am currently the author of the bis version for the RFC and the discussion regarding the same can be seen in the archives. http://www1.ietf.org/mail-archive/web/ipsec/current/index.html Thanks, Vishwas =================================================================== Tony Li wrote: Hannes, > There is a time window (until all routers have the new > authentication key) where the routers holding the new key are > using that key and other routers have not yet got the new key > and hence nothing to verify against. > > so what you require is some form of coordination i.e. > to have all nodes hold off using the new transmit key > up until the network is fully transitioned > (i have seen implementations who achieve that with > time/date based transmit key-selection) -> this requires > some form of coordination (timestamp / key lifetime etc.) Nothing more sophisticated than uniform configuration is required. The first configuration pass installs the new key and enables it for reception. The second configuration pass switches to using the new key for transmission. Those who want to be pedantic can include a third pass to remove the old key. Given the widespread deployment of homegrown tools for consistent, distributed router configuration, I don't see this as a significant hurdle. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg