From uma.chunduri@ericsson.com Sun Apr 1 06:21:12 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC12B21F93BE; Sun, 1 Apr 2012 06:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eV+jnZQxOBLZ; Sun, 1 Apr 2012 06:21:11 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 53EA421F8C04; Sun, 1 Apr 2012 06:21:08 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q31DL2JK027845; Sun, 1 Apr 2012 08:21:04 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sun, 1 Apr 2012 09:21:01 -0400 From: Uma Chunduri To: "Les Ginsberg (ginsberg)" , "Bhatia, Manav (Manav)" , "Naiming Shen (naiming)" Date: Sun, 1 Apr 2012 09:20:59 -0400 Thread-Topic: [karp] [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00 Thread-Index: AcyVD3r+AHoMB7E2R0+4FJMQgKrozAAACfDQHh1xsYAAGkt94AAFMrTQAAJooMAAEcn4IAAkpaZwAAF6EGAARrMx8A== Message-ID: References: <4F31FB49-B9B2-492E-BC9E-A32986E4BCF0@cisco.com><4EA9D09A.6070206@googlemail.com> <7C 362EEF9C7896468B36C9B79200D8350D02E41D5D@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Mike Shand , "isis-wg@ietf.org" , "karp@ietf.org" Subject: Re: [karp] [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 13:21:12 -0000 Hi Les, You raised a good point on partial deployments. Please see my response in-l= ine [Uma].=20 --=20 Uma C.=20 =3D=3D=3D Consider this simple example: R1----R2----R3 R1 does NOT support the extension, but R2 and R3 do support the extension. All routers have an LSP originated by R3 - call it R3.00-00 Seq #10 ESSN # = 50 An attacker has an old LSP from a previous incarnation of R3. Call it R3.00= -00 Seq #20 ESSN # 40.=20 The attacker injects this replayed LSP into the network at R1. As the seque= nce # is greater than the copy=20 in the local database R1 accepts the replayed LSP and then floods it to R2.= R2 however rejects the replayed=20 LSP because it has an older ESSN #. LSPDB is now inconsistent between R1 an= d R2/R3. This condition will=20 persist until R3 generates a new LSP with sequence # > 20 or until the repl= ayed LSP on R1 ages out. [Uma]: I am glad you see the problem. As you have been saying this is tempo= rary problem (which is quite true), why do you think=20 this situation would come down to R1 aging out. Are you saying new L= SP from originator would never be flooded in this LAN segment? I am missing some thing here. I think there are similar constraints as regards the use of the extension i= n IIHs and SNPs - though in that case it=20 is only necessary to upgrade all routers on a particular link - and probabl= y support enabling the extension on a=20 per link basis.Note that if not all ISs on a LAN segment support the extens= ion, then a replay attack could result=20 in an inconsistent set of neighbors and multiple DISs might be elected, ren= dering the LAN unreliable for forwarding. [Uma]: You are so correct here. But, you have to see if no body supports th= is extension situation is still ugly not only=20 in this LAN segment (of course it's worst here) but in the overall n= etwork. There may be ways to protect against the perils of partial deployment - whi= ch it would be good if the draft addressed -=20 but I do think full deployment is required for the feature to be enabled. [Uma]: We have few thoughts on how to avoid being here (and at what cost).= We will update the doc with partial deployment section and also=20 discuss with you too. Thx. Les > -----Original Message----- > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > Sent: Friday, March 30, 2012 7:40 PM > To: Uma Chunduri; Les Ginsberg (ginsberg); Naiming Shen (naiming) > Cc: Mike Shand; isis-wg@ietf.org; karp@ietf.org > Subject: RE: [karp] [Isis-wg] Question regardingdraft-chunduri-isis-extended- > sequence-no-tlv-00 >=20 > Hi Uma, >=20 > > [Uma]: I would only say, just because we have an in-built recovery,=20 > > you can't assume a mechanism which mitigates this threat in first=20 > > place has low ROI. And coming to the solution, this optional TLV=20 > > introduce neither complexity nor introduce significant overhead in=20 > > processing. So I didn't quite understand your claim of "low" ROI. >=20 > Well it does introduce an additional burden on the vendors to implement and > test this feature. It also places a huge burden on operators to see the > impact of deploying this feature. There is no flag day where all routers are > upgraded with the new image and you might have to deal with cases where there > is a mix of routers that support and don't support this feature. You will > have to define some mechanism on how this needs to work. I don't say its > unachievable - I am trying to tell you what Les could possibly be alluding to > when he mentions "low" ROI. >=20 > Cheers, Manav From ginsberg@cisco.com Sun Apr 1 09:55:47 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B5821F8B37; Sun, 1 Apr 2012 09:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-1Vnx-kZV+a; Sun, 1 Apr 2012 09:55:46 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 46FE121F8B33; Sun, 1 Apr 2012 09:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ginsberg@cisco.com; l=5655; q=dns/txt; s=iport; t=1333299346; x=1334508946; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=6mwKNPkVW7qRK6pFcaeKxj8NOGA/ylb2M+KcBBf/il0=; b=b71l4e5YGqoeZhEEikE6vQbqS/rHzjc9Y2YxyEdzHSVQFWu7X684kDBF sysnamvoutFhdlj3wpL7R2IAIxuD7A2SC/9vKb6coB9DW8eBRXZmhdh7/ 2wkMaFFaun4BIY5oHBRVlXhkVS5jeDTDztI3b1ZoCn0x4w06aAWRyXB/8 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFOHeE+rRDoJ/2dsb2JhbABEuH6BB4IJAQEBAwESAR0KPwwEAgEIEQQBAQsGFwEGAUUJCAIEARIIEweHYgQBmy2eCIsahR9jBIhYm1CBaIMHgTQCFQ X-IronPort-AV: E=Sophos;i="4.75,353,1330905600"; d="scan'208";a="38588304" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 01 Apr 2012 16:55:46 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q31GtjR3013675; Sun, 1 Apr 2012 16:55:45 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 09:55:45 -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 Date: Sun, 1 Apr 2012 09:55:44 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [karp] [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00 Thread-Index: AcyVD3r+AHoMB7E2R0+4FJMQgKrozAAACfDQHh1xsYAAGkt94AAFMrTQAAJooMAAEcn4IAAkpaZwAAF6EGAARrMx8AAHbW2Q References: <4F31FB49-B9B2-492E-BC9E-A32986E4BCF0@cisco.com><4EA9D09A.6070206@googlemail.com> <7C 362EEF9C7896 468B36C9B79200D8350D02E41D5D@INBANSXCHMBSA1.in.alcatel-lucent.com> From: "Les Ginsberg (ginsberg)" To: "Uma Chunduri" , "Bhatia, Manav (Manav)" , "Naiming Shen (naiming)" X-OriginalArrivalTime: 01 Apr 2012 16:55:45.0619 (UTC) FILETIME=[47FE3230:01CD1028] Cc: Mike Shand , isis-wg@ietf.org, karp@ietf.org Subject: Re: [karp] [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 16:55:47 -0000 Uma - > -----Original Message----- > From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] > Sent: Sunday, April 01, 2012 6:21 AM > To: Les Ginsberg (ginsberg); Bhatia, Manav (Manav); Naiming Shen (naiming) > Cc: Mike Shand; isis-wg@ietf.org; karp@ietf.org > Subject: RE: [karp] [Isis-wg] Question regardingdraft-chunduri-isis-extended- > sequence-no-tlv-00 >=20 > Hi Les, >=20 > You raised a good point on partial deployments. Please see my response in- > line [Uma]. >=20 >=20 > -- > Uma C. >=20 >=20 > =3D=3D=3D > Consider this simple example: > R1----R2----R3 > R1 does NOT support the extension, but R2 and R3 do support the extension. > All routers have an LSP originated by R3 - call it R3.00-00 Seq #10 ESSN # 50 > An attacker has an old LSP from a previous incarnation of R3. Call it R3.00- > 00 Seq #20 ESSN # 40. > The attacker injects this replayed LSP into the network at R1. As the > sequence # is greater than the copy > in the local database R1 accepts the replayed LSP and then floods it to R2. > R2 however rejects the replayed > LSP because it has an older ESSN #. LSPDB is now inconsistent between R1 and > R2/R3. This condition will > persist until R3 generates a new LSP with sequence # > 20 or until the > replayed LSP on R1 ages out. >=20 > [Uma]: I am glad you see the problem. As you have been saying this is > temporary problem (which is quite true), why do you think > this situation would come down to R1 aging out. Are you saying new LSP > from originator would never be flooded in this > LAN segment? I am missing some thing here. As the replayed LSP is owned by R3, R3 is the only IS which can generate a new version. In this example topology, R3 will never see the replayed LSP because all of its neighbors will reject it without flooding it. Therefore the legacy systems will continue to use the replayed LSP until it either ages out or R3 - for other reasons - generates a version with sequence # >20. Aging could take as long as 18 hours (depending on the lifetime in the replayed LSP) - and since it is postulated that the attacker could have stored many old LSPs, when Seq #20 ages out the attacker could send a replayed LSP with Seq #21 (or greater), so the duration of this inconsistent state is indeterminate. While the example topology is simple, it is easy to imagine an equivalent topology that is more realistic. All that is necessary is for there to be partial deployment while the owner of the replayed LSP has neighbors all of which support the extension. I have assumed in this example that if the replayed LSP actually reached the originator (R3 in this case) that it would generate a new version even though the ESSN # indicates the LSP is stale. But it may be that you intend for the originating system to ignore the replayed LSP in this case as well (just like R2 does in this case), which would mean it is even easier to create the pathological state - simply the presence of one legacy system anywhere in the topology would be sufficient. Les >=20 > I think there are similar constraints as regards the use of the extension in > IIHs and SNPs - though in that case it > is only necessary to upgrade all routers on a particular link - and probably > support enabling the extension on a > per link basis.Note that if not all ISs on a LAN segment support the > extension, then a replay attack could result > in an inconsistent set of neighbors and multiple DISs might be elected, > rendering the LAN unreliable for forwarding. >=20 > [Uma]: You are so correct here. But, you have to see if no body supports this > extension situation is still ugly not only > in this LAN segment (of course it's worst here) but in the overall > network. >=20 > There may be ways to protect against the perils of partial deployment - which > it would be good if the draft addressed - > but I do think full deployment is required for the feature to be enabled. > [Uma]: We have few thoughts on how to avoid being here (and at what cost). > We will update the doc with partial deployment section and also > discuss with you too. Thx. >=20 >=20 > Les >=20 > > -----Original Message----- > > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > > Sent: Friday, March 30, 2012 7:40 PM > > To: Uma Chunduri; Les Ginsberg (ginsberg); Naiming Shen (naiming) > > Cc: Mike Shand; isis-wg@ietf.org; karp@ietf.org > > Subject: RE: [karp] [Isis-wg] Question > regardingdraft-chunduri-isis-extended- > > sequence-no-tlv-00 > > > > Hi Uma, > > > > > [Uma]: I would only say, just because we have an in-built recovery, > > > you can't assume a mechanism which mitigates this threat in first > > > place has low ROI. And coming to the solution, this optional TLV > > > introduce neither complexity nor introduce significant overhead in > > > processing. So I didn't quite understand your claim of "low" ROI. > > > > Well it does introduce an additional burden on the vendors to > implement and > > test this feature. It also places a huge burden on operators to see > the > > impact of deploying this feature. There is no flag day where all > routers are > > upgraded with the new image and you might have to deal with cases > where there > > is a mix of routers that support and don't support this feature. You > will > > have to define some mechanism on how this needs to work. I don't say > its > > unachievable - I am trying to tell you what Les could possibly be > alluding to > > when he mentions "low" ROI. > > > > Cheers, Manav From ginsberg@cisco.com Sun Apr 1 23:33:33 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F9A11E8074; Sun, 1 Apr 2012 23:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8Agn0hfrUxt; Sun, 1 Apr 2012 23:33:33 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3234A11E8073; Sun, 1 Apr 2012 23:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ginsberg@cisco.com; l=2657; q=dns/txt; s=iport; t=1333348413; x=1334558013; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=k18G/omHZBgWstlVdbbI6m+7FUwg11angDvB4dxjYLA=; b=jkzxI5mcyJK4GA9l6wltt5IF6sMPTCNSQO9siE3EcDkma95/QWfY70XM JYFN3StXX6Phu3plcSO71eh+QT63+9KYL/dKGV/VT9umVPKHWkpbV7iE/ x1bqd9EvC4WEzhnHuAW3T51s+JAawzsPhmIhNewrjQgz8pW8bJpsoTzSm U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMdHeU+rRDoI/2dsb2JhbABDuQyBB4IKAQEEEgEdCj8QAgEqBhgGAVYCBAEaGodmAaATljSLCoUvYwSIWIJikQOHa4FogweBNA X-IronPort-AV: E=Sophos;i="4.75,355,1330905600"; d="scan'208";a="38548631" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 02 Apr 2012 06:33:32 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q326XWIZ007540; Mon, 2 Apr 2012 06:33:32 GMT 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.4675); Sun, 1 Apr 2012 23:33:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: BbnL DdRj DijF GkKH Jyy6 MkVx V+KY ZPsV hHFh hZPx jghX rbOH x2Dg 2LXx 23aJ 3mbf; 5; aQBtAGMALgBzAGgAYQBuAGQAQABnAG8AbwBnAGwAZQBtAGEAaQBsAC4AYwBvAG0AOwBpAHMAaQBzAC0AdwBnAEAAaQBlAHQAZgAuAG8AcgBnADsAawBhAHIAcABAAGkAZQB0AGYALgBvAHIAZwA7AG0AYQBuAGEAdgAuAGIAaABhAHQAaQBhAEAAYQBsAGMAYQB0AGUAbAAtAGwAdQBjAGUAbgB0AC4AYwBvAG0AOwB1AG0AYQAuAGMAaAB1AG4AZAB1AHIAaQBAAGUAcgBpAGMAcwBzAG8AbgAuAGMAbwBtAA==; Sosha1_v1; 7; {13DAF29E-E018-42C9-938B-C8E53B7F7C92}; ZwBpAG4AcwBiAGUAcgBnAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Mon, 02 Apr 2012 06:33:24 GMT; ZAByAGEAZgB0AC0AYwBoAHUAbgBkAHUAcgBpAC0AaQBzAGkAcwAtAGUAeAB0AGUAbgBkAGUAZAAtAHMAZQBxAHUAZQBuAGMAZQAtAG4AbwAtAHQAbAB2ACAALQAgAG8AdABoAGUAcgAgAGMAbwBtAG0AZQBuAHQAcwA= MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {13DAF29E-E018-42C9-938B-C8E53B7F7C92} Content-class: urn:content-classes:message Date: Sun, 1 Apr 2012 23:33:24 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-chunduri-isis-extended-sequence-no-tlv - other comments Thread-Index: AcyVD3r+AHoMB7E2R0+4FJMQgKrozAAACfDQHh1xsYAAGkt94AAFMrTQAAJooMAAEcn4IAAkpaZwAAF6EGAARrMx8AAHbW2QABsjBQA= References: <4F31FB49-B9B2-492E-BC9E-A32986E4BCF0@cisco.com><4EA9D09A.6070206@googlemail.com> <7C 362EEF9C7896 468B36C9B79200D8350D02E41D5D@INBANSXCHMBSA1.in.alcatel-lucent.com> From: "Les Ginsberg (ginsberg)" To: "Uma Chunduri" , "Bhatia, Manav (Manav)" , "Naiming Shen (naiming)" X-OriginalArrivalTime: 02 Apr 2012 06:33:32.0580 (UTC) FILETIME=[862E4640:01CD109A] Cc: Mike Shand , isis-wg@ietf.org, karp@ietf.org Subject: [karp] draft-chunduri-isis-extended-sequence-no-tlv - other comments X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 06:33:34 -0000 In a previous thread we have discussed the use of the proposed extension in LSPs. Here are the remainder of my comments on the draft: In regards to SNPs, the presence of replayed SNPs will cause unnecessary reflooding of LSPs but will not actually cause any change in the LSPDB of any router. The unnecessary flooding would be limited to the link on which the replayed SNPs appear. Because no actual LSPDB changes would occur as a result of replayed SNPs, this is the one usage which could be enabled in the presence of partial deployment. In regards to IIHs, replayed IIHs could cause adjacency flapping which could be very disruptive. The danger lies when not all systems on a link support the extension - which on multi-access links can lead to multiple DISs being elected and violations of the assumption of transitivity. For this reason, enablement cannot be safely done in the presence of legacy systems. Given the discussion in the draft about enhancements to provide routing protocols with a group key management protocol in the future, it is prudent to look at the value add of extended sequence #s in the presence of a group key management protocol. The cost of having router vendors and their customers implement, deploy, and support extended sequence #s must be weighed against the benefits. As discussed in an earlier thread, IS-IS already has a reliable mechanism to recover from replayed LSPs. I see no significant value in using this extension in LSPs - and there is significant risk of introducing prolonged inconsistency in the LSPDB of routers in the network if any legacy systems exist in the network or are introduced after the extension has been enabled. The negative consequences of having a legacy system are significant because, unlike authentication, extended sequence #s are always optional and the absence of the same do not prevent adjacency formation and LSP exchange.=20 At this point the only significant potential value I see is in IIHs - and in the presence of a group key management protocol this would be limited to the period between key rollovers. Once the set of neighbors on a link is stable, there would be no opportunity to introduce disruption with replayed IIHs even if the authentication key is not changed, so the potential value add is limited to periods of instability without key rollover. If the draft is to go forward, I would like to see the use in LSPs removed from the draft and a more complete discussion of the benefits/consequences of using extended sequence numbers in IIHs/SNPs in the presence of a group key management protocol.=20 Les From d3e3e3@gmail.com Thu Apr 5 12:03:08 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEFD321F869E; Thu, 5 Apr 2012 12:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.274 X-Spam-Level: X-Spam-Status: No, score=-104.274 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTdoPRysKTDF; Thu, 5 Apr 2012 12:03:08 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D566D21F866D; Thu, 5 Apr 2012 12:03:06 -0700 (PDT) Received: by lagj5 with SMTP id j5so556387lag.31 for ; Thu, 05 Apr 2012 12:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=LjzlakvS0zxSw6VFufHqmN/GHahTRT13+ARUWALQeu4=; b=ZQ3bIlbk7sFQy32Eeag3Wj0p3y2UUCfrnkV84yHiulN7lN4usWX9+YiW9LoXpfkVha Djvf/gkYuSP+1g2QxUsh3mMbbayQSbm6g/F81Wk3PtrAkCeW8OcfksvcOD3+IwdMxGY4 3D495dfHcFEE3WWqe0gBGZfzKMqFp5vn3P/yCzNkQBfp805etBjR0I174tUaNdZ3fjDy +ygq93HjZDermGkWjh5cFmjOOrKATZ4rhfH+4i3YzqiSKZcaD0XC6g7/BTVgXvPBvwpr DtkLG425ixWXnbDqXdleikU0U45OXO7eQZMi6/lDJPaJ84Q9QMyaSXmuS5r/ET0s84ZC GAOw== Received: by 10.152.131.66 with SMTP id ok2mr4731021lab.10.1333652585239; Thu, 05 Apr 2012 12:03:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.162 with HTTP; Thu, 5 Apr 2012 12:02:44 -0700 (PDT) In-Reply-To: References: <4F31FB49-B9B2-492E-BC9E-A32986E4BCF0@cisco.com> <4EA9D09A.6070206@googlemail.com> From: Donald Eastlake Date: Thu, 5 Apr 2012 15:02:44 -0400 Message-ID: To: isis-wg@ietf.org, "Les Ginsberg (ginsberg)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 05 Apr 2012 12:57:11 -0700 Cc: Mike Shand , "Naiming Shen \(naiming\)" , karp@ietf.org Subject: Re: [karp] [Isis-wg] draft-chunduri-isis-extended-sequence-no-tlv - other comments X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 19:03:08 -0000 I have a concern about replayed IIHs within TRILL where it is reasonable to believe that such a change could be universally deployed or nearly so. I would like to see such a TLV available for at least that purpose. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Mon, Apr 2, 2012 at 2:33 AM, Les Ginsberg (ginsberg) wrote: > In a previous thread we have discussed the use of the proposed extension > in LSPs. > > Here are the remainder of my comments on the draft: > > In regards to SNPs, the presence of replayed SNPs will cause unnecessary > reflooding of LSPs but will not actually cause any change in the LSPDB > of any router. The unnecessary flooding would be limited to the link on > which the replayed SNPs appear. Because no actual LSPDB changes would > occur as a result of replayed SNPs, this is the one usage which could be > enabled in the presence of partial deployment. > > In regards to IIHs, replayed IIHs could cause adjacency flapping which > could be very disruptive. The danger lies when not all systems on a link > support the extension - which on multi-access links can lead to multiple > DISs being elected and violations of the assumption of transitivity. For > this reason, enablement cannot be safely done in the presence of legacy > systems. > > Given the discussion in the draft about enhancements to provide routing > protocols with a group key management protocol in the future, it is > prudent to look at the value add of extended sequence #s in the presence > of a group key management protocol. The cost of having router vendors > and their customers implement, deploy, and support extended sequence #s > must be weighed against the benefits. > > As discussed in an earlier thread, IS-IS already has a reliable > mechanism to recover from replayed LSPs. I see no significant value in > using this extension in LSPs - and there is significant risk of > introducing prolonged inconsistency in the LSPDB of routers in the > network if any legacy systems exist in the network or are introduced > after the extension has been enabled. The negative consequences of > having a legacy system are significant because, unlike authentication, > extended sequence #s are always optional and the absence of the same do > not prevent adjacency formation and LSP exchange. > > At this point the only significant potential value I see is in IIHs - > and in the presence of a group key management protocol this would be > limited to the period between key rollovers. Once the set of neighbors > on a link is stable, there would be no opportunity to introduce > disruption with replayed IIHs even if the authentication key is not > changed, so the potential value add is limited to periods of instability > without key rollover. > > If the draft is to go forward, I would like to see the use in LSPs > removed from the draft and a more complete discussion of the > benefits/consequences of using extended sequence numbers in IIHs/SNPs in > the presence of a group key management protocol. > > =A0 Les > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From bew@cisco.com Fri Apr 6 12:25:15 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FCF21F84D5 for ; Fri, 6 Apr 2012 12:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-QrQgLkDjlc for ; Fri, 6 Apr 2012 12:25:15 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1D821F84D3 for ; Fri, 6 Apr 2012 12:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=279; q=dns/txt; s=iport; t=1333740315; x=1334949915; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=75+sOsDU+3UQJWRZI9VnVxSfNTmj2OqFFTuH8DWaR6M=; b=JKO4oWl89Pz0JUkAm39tEZY3qRTq7AomG5eBqqe6sGWYCoUnxNvVP8nM A5fwOzUHyXEkGDCCp6oE6UxiuZ08qfArz7qUBMBMWayKwMu9nG4agxC3v hq9STV/CxDadzh7YD2YoeO9s2XUS1xnE2uu3dtpGse03i2cYyvl1PXHob U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUFAHlCf0+rRDoG/2dsb2JhbABFgye1e4EHgiIBJ4IQCRmHawELmTqBJ59mjSyCQWMEiFqNEo5NgWmDBw X-IronPort-AV: E=Sophos;i="4.75,381,1330905600"; d="scan'208";a="36837381" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 06 Apr 2012 19:25:15 +0000 Received: from dhcp-128-107-147-33.cisco.com (dhcp-128-107-147-33.cisco.com [128.107.147.33]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q36JPEUC009097 for ; Fri, 6 Apr 2012 19:25:14 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Apr 2012 12:25:15 -0700 Message-Id: To: karp@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [karp] IETF83 KARP WG minutes X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 19:25:15 -0000 Greetings, The KARP WG minutes have been posted. Many thanks to Richard Graveman = for providing them. Corrections may be sent to the list or to the chairs = . Joel & Brian= From touch@isi.edu Fri Apr 6 13:16:18 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80F111E809B for ; Fri, 6 Apr 2012 13:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.577 X-Spam-Level: X-Spam-Status: No, score=-103.577 tagged_above=-999 required=5 tests=[AWL=-0.978, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvPTxtl-BVdM for ; Fri, 6 Apr 2012 13:16:18 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 128E411E8098 for ; Fri, 6 Apr 2012 13:16:18 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q36KG8e3015371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Apr 2012 13:16:08 -0700 (PDT) Message-ID: <4F7F4F08.5070409@isi.edu> Date: Fri, 06 Apr 2012 13:16:08 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Tero Kivinen References: <4F74C93F.5050501@isi.edu> <20341.27199.128277.705512@fireball.kivinen.iki.fi> <4F75ADF6.1020208@isi.edu> In-Reply-To: <4F75ADF6.1020208@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Sam Hartman , karp@ietf.org Subject: Re: [karp] Comments on draft-ietf-karp-crypto-tables X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 20:16:19 -0000 Hi, all, I had an extended discussion with Sam Hartman yesterday, and wanted to convey the results of that: On 3/30/2012 5:58 AM, Joe Touch wrote: > Hi, Tero, > > See below. Perhaps we can resolve this by explaining the Gatekeeper as > the coordinator of the interpretation of keying info between a variety > of protocols, not just TCP-AO and IKEv2 -- which is fine with me. This is consistent with the phonecall I had. When we talk about "the Gatekeeper", I keep referring to that term as I introduced it in the TCP-AO KMP doc. However, I don't care/mind if that is more generally a translator between various protocols to exchange key/configuration material and various protocols to secure routing information. It's also fine for this new, more general Gatekeeper to have its own tables of key/configuration material - AFAICT, this is what is meant by "keytables". IMO, however, it's not necessary that the security protocols directly consult those keytables - IMO, it's the responsibility of the Gatekeeper to install/manage/maintain that material and convey it to the security protocols. The TCP-AO KMP doc focuses on ways to use the Gatekeeper to integrate IKEv2 with new registry entries and/or message types with TCP-AO. If it turns out that it's preferable to modify IKEv2 to be more specific about a new class of exchanges focused on routing protocols, that's fine to me. I hope that helps. I'm glad to provide continued feedback on the possible more general use of the Gatekeeper to integrate key management across multiple protocols, although I expect someone else would lead that. Joe From bew@cisco.com Fri Apr 6 15:58:03 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37F721F855B for ; Fri, 6 Apr 2012 15:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.486 X-Spam-Level: X-Spam-Status: No, score=-110.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qffyBYmOap0S for ; Fri, 6 Apr 2012 15:58:02 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 62A0221F8559 for ; Fri, 6 Apr 2012 15:58:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=1048; q=dns/txt; s=iport; t=1333753082; x=1334962682; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=KdyBRfhM8N8sN+WO98d8UKkfgx5/vaTVmo+K9QH9IkM=; b=YebN/vnPWN9/HIuBX+Z3NE7c8GpnnGH8dRAee0sYuDCjFmjsA3AmmQKK mUxkslHTNRXUZNuxyKnXL0zpd/IZFrRAk3Ek5Cqkk2qHPJSPzRPSSExqQ 2lsXu+hLj+u+hJbQMlgVPBm8GVHDN7y2LkdriksRD5aCMLFfUT4ewxur0 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAONzf0+rRDoJ/2dsb2JhbABBA7kkgQeCIgEnghAih2sBmUKBJ59MjScFgkFjBIhajRKOTYFpgweBPA X-IronPort-AV: E=Sophos;i="4.75,383,1330905600"; d="scan'208";a="39440953" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 06 Apr 2012 22:58:02 +0000 Received: from dhcp-128-107-147-33.cisco.com (dhcp-128-107-147-33.cisco.com [128.107.147.33]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q36Mw2ud026109 for ; Fri, 6 Apr 2012 22:58:02 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Apr 2012 15:58:02 -0700 Message-Id: <66F1DE8F-0B63-4832-8B4C-FECC066A0BE3@cisco.com> To: karp@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [karp] Requirement 22 of draft-ietf-karp-threats-reqs-04 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 22:58:03 -0000 (Speaking as a WG member.) A second paragraph was added in this version to Requirement 22. While = it's a valiant effort to try to give examples where a circular = dependency does and does not exist, both examples are convoluted. = Understanding the nuances of the examples, and whether or not in all = cases of each example that the bad one is bad and the good one is good, = is laborious. Also it's also not clear to me that the added MUST is = necessary. Wouldn't it be sufficient to add this as one reason for the = dire warnings already communicated in the previous paragraph?=20 I would suggest removing this paragraph completely, and adding something = like the following sentence before the last sentence in the previous = paragraph: "Relying on external systems may result in a circular = dependency between routing and the security mechanisms such that routing = cannot be started." Brian --=20 Brian Weis Security Standards and Technology, SRTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From bew@cisco.com Fri Apr 6 16:02:52 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19ACB11E80AB for ; Fri, 6 Apr 2012 16:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.429 X-Spam-Level: X-Spam-Status: No, score=-110.429 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksJItiBZD3EC for ; Fri, 6 Apr 2012 16:02:51 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8929D11E80A0 for ; Fri, 6 Apr 2012 16:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=637; q=dns/txt; s=iport; t=1333753371; x=1334962971; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=fvLbNRKf/RxGS5oqmnNBmRcX75z24vM0mYnuCsilRPI=; b=TLeijFXsM3eIq/valwIypT7xaIgnzthnDuN5Tlygl310c2o+D1BMK/f7 IZkH1U0zFclKBBr8tPMs1Z5IXTQD6TbJB83tg/T5RItG6tzXQN/Cw6aOy AdjHOHuKJfDVJOvaB8fRaiZ2a2YyI51LeDh+by3hJToXeQgWXwUIEHE6Y 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAOt0f0+rRDoH/2dsb2JhbABBA7kkgQeCIgEnghAih2sBmUWBJ59MjScFgkFjBIhajRKOTYFpgweBPA X-IronPort-AV: E=Sophos;i="4.75,383,1330905600"; d="scan'208";a="36861894" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 06 Apr 2012 23:02:51 +0000 Received: from dhcp-128-107-147-33.cisco.com (dhcp-128-107-147-33.cisco.com [128.107.147.33]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q36N2p8e029020 for ; Fri, 6 Apr 2012 23:02:51 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Apr 2012 16:02:51 -0700 Message-Id: <6A3737B2-5B3C-421A-A61C-64AFB74B2F30@cisco.com> To: karp@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [karp] Security Considerations text added to draft-ietf-karp-threats-reqs-04 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 23:02:52 -0000 (Speaking as a WG member.) The text added to the Security Considerations document describes issues = inherent in using a group key, and then adds a requirement that design = teams need to make choices about stopping a BYZANTINE actor. The general = guidance is good, but because Section 3.3 clearly states that threats = from a BYZANTINE actor are out of scope it seems wrong to require design = teams to defend against them. I suggest that the last sentence in this = paragraph be removed. Brian --=20 Brian Weis Security Standards and Technology, SRTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From hartmans@mit.edu Mon Apr 9 11:38:05 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F9121F87C8 for ; Mon, 9 Apr 2012 11:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.506 X-Spam-Level: X-Spam-Status: No, score=-103.506 tagged_above=-999 required=5 tests=[AWL=-1.468, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjlKDjQ6virO for ; Mon, 9 Apr 2012 11:38:05 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 679A421F87C0 for ; Mon, 9 Apr 2012 11:38:05 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 04B6E207D4; Mon, 9 Apr 2012 14:37:06 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C219D4766; Mon, 9 Apr 2012 14:37:44 -0400 (EDT) From: Sam Hartman To: Brian Weis References: <6A3737B2-5B3C-421A-A61C-64AFB74B2F30@cisco.com> Date: Mon, 09 Apr 2012 14:37:44 -0400 In-Reply-To: <6A3737B2-5B3C-421A-A61C-64AFB74B2F30@cisco.com> (Brian Weis's message of "Fri, 6 Apr 2012 16:02:51 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: karp@ietf.org Subject: Re: [karp] Security Considerations text added to draft-ietf-karp-threats-reqs-04 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 18:38:05 -0000 I'd like to support Brian's concerns with this text and with requirement 22. From uma.chunduri@ericsson.com Tue Apr 24 17:27:04 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D4A21F860F for ; Tue, 24 Apr 2012 17:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHOaqLo8H3tq for ; Tue, 24 Apr 2012 17:27:03 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0191021F860D for ; Tue, 24 Apr 2012 17:27:02 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3P0R1eU007948 for ; Tue, 24 Apr 2012 19:27:02 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.6]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 24 Apr 2012 20:26:55 -0400 From: Uma Chunduri To: "karp@ietf.org" Date: Tue, 24 Apr 2012 20:26:54 -0400 Thread-Topic: Q's on karp-crypto-tables Thread-Index: Ac0ieh3MZC4Vdbu6R8epa2dG69Q/wQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D1D8138DDF34B34B8BC68A11262D10792241F1DFD8EUSAACMS0701e_" MIME-Version: 1.0 Subject: [karp] Q's on karp-crypto-tables X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 00:27:04 -0000 --_000_D1D8138DDF34B34B8BC68A11262D10792241F1DFD8EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, I understand the spirit of the http://datatracker.ietf.org/doc/draft-ietf-k= arp-crypto-key-table/?include_text=3D1 WG document. I saw the presentation on the same at IETF83, but still have the following = specific questions and comments. Questions/Comments: --------------------------------- 1. Text in Abstract and Section-1 assumes this conceptual database if for s= ecurity protocols such as TCP-AO with a following exception in Section-1 "In other instances, security protocols will directly use the long-= lived key from the database." AFAICT, KARP is interested in security protocol TCP-AO to protect all T= CP based pair wise routing protocols (BGP, LDP, MSDP, PCEP). I am interested to know what other security protocols relevant to KAR= P use long-lived keys. 2. From the fields in conceptual database and the description it's very cl= ear that this is a common table not only for security protocols like TCP-AO= but also for routing protocols which use group keys (notably OSPF, ISIS etc..). But, a. For one set of routing protocols which use security protocols lik= e TCP-AO, for E.g., 'interfaces' field is not relevant as key selection is = not done per interface level. Similarly for group keying routing protocols KDF, KDF inputs are= not relevant. b. For lifetime there are 4 fields defined, which seems more relevant= to OSPF. But this can be specified in seconds as well as number of bytes s= ecured with that key. I don't see any requirement for routing protocols to specify key = lifetime in terms of number of bytes secured and also don't see all routing= protocols as well as security protocols use the same lifetime format either. I am not worried about few extra fields which are relevant to one set= of protocols and not at all relevant to other set. But, I am not sure why = we have to club routing protocols which use group keying, use different transpor= ts (L2, L3, L4) and do security by themselves need to be clubbed with a s= ecurity protocol like TCP-AO which is specifically designed to protect TCP ba= sed pair wise routing protocols (BGP, LDP etc..). If separation for a set = of routing protocols with common characteristics is provided, more speci= fic and more relevant fields to the routing protocols can be added to the = table. 3. Section-3 specifies Key Selection and as mentioned earlier this is not = applicable to security protocols like TCP-AO as key selection happens by co= nsulting it's internal tables. How ever, a routing protocol which secures it's routin= g packet by itself can consult this table. In summary- IMO, as we have various types of routing protocols it's better = to define conceptual key table specific to that set. Set1: BGP, LDP, PCEP, and MSDP (Pair wise TCP based which use security prot= ocol like TCP-AO) Set 2: OSPF, IS-IS, RIP (group keying, different transports and security i= s provided by themselves) - OSPFv3 ( Originally defined with IPSec based on the new dra= ft/RFC it's similar to OSPFv2) - RSVP-TE (I would say still come under group key category) Set3: Multicast routing protocols like PIM -- Uma C. --_000_D1D8138DDF34B34B8BC68A11262D10792241F1DFD8EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear All,
 
I saw the presentation on the same at IETF83, but still have the follo= wing specific questions and comments.
 
Questions/Comments:
---------------------------------
 
1. Text in Abstract and Section-1 assumes this conceptual database if = for security protocols such as TCP-AO with a following exception in Section= -1
 
   &nbs= p;     "In o= ther instances, security protocols will directly use the long-lived key fro= m the database."
    AFAICT, KARP is interested in security protoc= ol TCP-AO to protect all TCP based pair wise routing   protocols = (BGP, LDP, MSDP, PCEP).
    I am interested to know what other security p= rotocols relevant to   KARP use long-lived keys.
2.  From the fields in conceptual database and the descript= ion it's very clear that this is a common table not only for security proto= cols like TCP-AO but also for routing
     protocols which use group keys (notably= OSPF, ISIS etc..).  But,
       a. For one set of routing p= rotocols which use security protocols like TCP-AO, for E.g., 'interfaces' f= ield is not relevant as key selection is not done per interface level.
           Sim= ilarly for group keying routing protocols KDF, KDF inputs are not relevant.=
      b. For lifetime there are 4 field= s defined, which seems more relevant to OSPF. But this can be specified in = seconds as well as number of bytes secured with that key.
          I don't s= ee any requirement for routing protocols to specify key lifetime in terms o= f number of bytes secured and also don't see all routing protocols as well = as
          security = protocols use the same  lifetime format either.
      I am not worried about few extra = fields which are relevant to one set of protocols and not at all relevant t= o other set. But, I am not sure why we have to
      club routing protocols which use = group keying, use different transports (L2, L3, L4)  and do security b= y themselves  need to be clubbed with a security
      protocol like TCP-AO which is spe= cifically designed to protect TCP based pair wise routing protocols (BGP, L= DP etc..).  If separation for a set of
      routing protocols with common cha= racteristics is provided, more specific and more relevant fields to the rou= ting protocols can be added  to the table.
3.  Section-3 specifies Key Selection and as mentioned earl= ier this is not applicable to security protocols like TCP-AO as key selecti= on happens by consulting it's
    internal tables. How ever, a routing protocol= which secures it's routing packet by itself can consult this table.=
 
In summary- IMO, as we have various types of routing protocols i= t's better to define conceptual key table specific to that set.
Set1: BGP, LDP, PCEP, and MSDP (Pair wise TCP based which use se= curity protocol like TCP-AO)
Set 2: OSPF, IS-IS, RIP  (group keying, different transport= s and security is provided by themselves)
          &nbs= p;   - OSPFv3 ( Originally defined with IPSec based on the new dr= aft/RFC it’s similar to OSPFv2)
          &nbs= p;   - RSVP-TE (I would say still come under group key category)<= /font>
Set3:  Multicast routing protocols like PIM
--
Uma C.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 --_000_D1D8138DDF34B34B8BC68A11262D10792241F1DFD8EUSAACMS0701e_-- From uma.chunduri@ericsson.com Tue Apr 24 17:30:55 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE9121E8050 for ; Tue, 24 Apr 2012 17:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AII+13+o0GDb for ; Tue, 24 Apr 2012 17:30:54 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 84B1D21E804A for ; Tue, 24 Apr 2012 17:30:54 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3P0UpDp008311; Tue, 24 Apr 2012 19:30:53 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.6]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 24 Apr 2012 20:30:50 -0400 From: Uma Chunduri To: Joe Touch , Tero Kivinen Date: Tue, 24 Apr 2012 20:30:49 -0400 Thread-Topic: [karp] Comments on draft-ietf-karp-crypto-tables Thread-Index: Ac0UMiOD/D4zuwSnTXGCxlLTrDpaOwOQ5UqA Message-ID: References: <4F74C93F.5050501@isi.edu> <20341.27199.128277.705512@fireball.kivinen.iki.fi> <4F75ADF6.1020208@isi.edu> <4F7F4F08.5070409@isi.edu> In-Reply-To: <4F7F4F08.5070409@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Sam Hartman , "karp@ietf.org" Subject: Re: [karp] Comments on draft-ietf-karp-crypto-tables X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 00:30:55 -0000 Hi Joe, I need more clarity on the discussion you folks had, in particular on new e= xchanges required by IKEv2 below. =3D=3D=3D=3D When we talk about "the Gatekeeper", I keep referring to that term as I i= ntroduced it=20 in the TCP-AO KMP doc. However, I don't care/mind if that is mo= re generally a translator=20 between various protocols to exchange key/configuration materia= l and various protocols to=20 secure routing information. [Uma]: Sure. It's also fine for this new, more general Gatekeeper to have its own tabl= es of=20 key/configuration material - AFAICT, this is what is meant by "= keytables".=20 [Uma]: I see Keytables as defined in (http://datatracker.ietf.org/doc/draft= -ietf-karp-crypto-key-table/?include_text=3D1), defines=20 a. place holder for negotiated Keys and parameters (either throu= gh KMP or manually) b. Provides a key selection mechanism Configuration (relevant to both AO and KMP) to help negotiation with= KMPs, SA management and key triggers are done by Gatekeeper.=20 Currently, http://datatracker.ietf.org/doc/draft-chunduri-karp-using= -ikev2-with-tcp-ao/ doesn't refer key-tables as it specifies=20 even "a." as integral part of Gatekeeper and doesn't talk about "b."= as it is not needed. So to be compliant with keytables draft, negotiated keys and associa= tes parameters should be abstracted from the Gatekeeper (please se my specific comments on key tables draft). Thi= s is TBD. IMO, however, it's not necessary that the security protocols directly cons= ult those keytables - IMO, it's the responsibility=20 of the Gatekeeper to install/manage/maintain that material and convey= it to the security protocols. [Uma]: Sure.=20 The TCP-AO KMP doc focuses on ways to use the Gatekeeper to integrate IKEv= 2 with new registry entries and/or message=20 types with TCP-AO. If it turns out that it's preferable to modify IKE= v2 to be more specific about a new class of exchanges=20 focused on routing protocols, that's fine to me. [Uma]: IKEv2 today defines IKE_SA_INIT, IKE_AUTH and CREATE_CHILD_SA exchan= ge. I really don't see any need for defining new=20 class of exchanges TCP based routing protocol SA apart from changes = in SA payload=20 (in IKE_AUTH and to re-key with CREATE_CHILD_SA). I would like to hea= r why Sam thinks new exchanges are required. -- Uma C.= From mjethanandani@gmail.com Tue Apr 24 20:43:20 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6682221E8012 for ; Tue, 24 Apr 2012 20:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLbyKLYGFXi1 for ; Tue, 24 Apr 2012 20:43:19 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 70BCE11E8074 for ; Tue, 24 Apr 2012 20:43:19 -0700 (PDT) Received: by dady13 with SMTP id y13so2489369dad.27 for ; Tue, 24 Apr 2012 20:43:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=Ok+V9BF/+kziIg20pes+kCcN/nZlOl4iWM4UTi5Sm6Q=; b=ptl1nG5ALk1EPzbNgGVPXV0hZ/9+DoNey/UtjErydGrvtqcfM9A7Fl5mozwLRDMLdG JxWAVZ8jS+k7kxVqE8KBb7lEkjZndU+lAxvrYtBePFu1/gaQ2Gnla9+HBJx9EJQ7v1NI grQv/fGRTgtrSPRASdMvIy34KFJ2xQQFqLswUwAamFqMs7xR342kOUcYVU8sWLxoel0m kdO6eapzov8lf1OQF5dX4YelQv7oHmoUuygJNHAn2CaDMryTrix2UeUBoM5FYCacKlCc Y26jiRenW0B77ocr4LIhVrARSIydjgAQDUIGzO6BcBAVhUFlhqyItAK3Jq4juqWZJ28I DtFQ== Received: by 10.68.75.45 with SMTP id z13mr3851574pbv.100.1335325399018; Tue, 24 Apr 2012 20:43:19 -0700 (PDT) Received: from [192.168.1.123] (c-24-6-173-225.hsd1.ca.comcast.net. [24.6.173.225]) by mx.google.com with ESMTPS id la9sm19259799pbc.1.2012.04.24.20.43.16 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Apr 2012 20:43:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-121-535909857 From: Mahesh Jethanandani In-Reply-To: Date: Tue, 24 Apr 2012 20:43:15 -0700 Message-Id: References: To: Uma Chunduri X-Mailer: Apple Mail (2.1084) Cc: "karp@ietf.org" Subject: Re: [karp] Q's on karp-crypto-tables X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 03:43:20 -0000 --Apple-Mail-121-535909857 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 24, 2012, at 5:26 PM, Uma Chunduri wrote: > Dear All, > =20 > I understand the spirit of the = http://datatracker.ietf.org/doc/draft-ietf-karp-crypto-key-table/?include_= text=3D1 WG document. > I saw the presentation on the same at IETF83, but still have the = following specific questions and comments. > =20 > Questions/Comments: > --------------------------------- > =20 > 1. Text in Abstract and Section-1 assumes this conceptual database if = for security protocols such as TCP-AO with a following exception in = Section-1 > =20 > "In other instances, security protocols will directly use the = long-lived key from the database." > AFAICT, KARP is interested in security protocol TCP-AO to protect = all TCP based pair wise routing protocols (BGP, LDP, MSDP, PCEP). > I am interested to know what other security protocols relevant to = KARP use long-lived keys. > 2. =46rom the fields in conceptual database and the description it's = very clear that this is a common table not only for security protocols = like TCP-AO but also for routing > protocols which use group keys (notably OSPF, ISIS etc..). But, > a. For one set of routing protocols which use security = protocols like TCP-AO, for E.g., 'interfaces' field is not relevant as = key selection is not done per interface level. > Similarly for group keying routing protocols KDF, KDF = inputs are not relevant. > b. For lifetime there are 4 fields defined, which seems more = relevant to OSPF. But this can be specified in seconds as well as number = of bytes secured with that key. > I don't see any requirement for routing protocols to specify = key lifetime in terms of number of bytes secured and also don't see all = routing protocols as well as > security protocols use the same lifetime format either. How else would one determine it is time for a key rollover? > I am not worried about few extra fields which are relevant to = one set of protocols and not at all relevant to other set. But, I am not = sure why we have to > club routing protocols which use group keying, use different = transports (L2, L3, L4) and do security by themselves need to be = clubbed with a security > protocol like TCP-AO which is specifically designed to protect = TCP based pair wise routing protocols (BGP, LDP etc..). If separation = for a set of > routing protocols with common characteristics is provided, more = specific and more relevant fields to the routing protocols can be added = to the table. > 3. Section-3 specifies Key Selection and as mentioned earlier this is = not applicable to security protocols like TCP-AO as key selection = happens by consulting it's > internal tables. How ever, a routing protocol which secures it's = routing packet by itself can consult this table. > =20 > In summary- IMO, as we have various types of routing protocols it's = better to define conceptual key table specific to that set. > Set1: BGP, LDP, PCEP, and MSDP (Pair wise TCP based which use security = protocol like TCP-AO) > Set 2: OSPF, IS-IS, RIP (group keying, different transports and = security is provided by themselves) > - OSPFv3 ( Originally defined with IPSec based on the = new draft/RFC it=92s similar to OSPFv2) > - RSVP-TE (I would say still come under group key = category) > Set3: Multicast routing protocols like PIM > -- > Uma C. > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail-121-535909857 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Apr 24, 2012, at 5:26 PM, Uma = Chunduri wrote:

Dear = All,
 
I = saw the presentation on the same at IETF83, but still have the following = specific questions and = comments.
 
Questions/Comments:
-------= --------------------------
 
1. Text in = Abstract and Section-1 assumes this conceptual database if for security = protocols such as TCP-AO with a following exception in = Section-1
 
 "In other instances, security protocols will directly use the = long-lived key from the database."
    AFAICT, KARP is interested in security = protocol TCP-AO to protect all TCP based pair wise routing   = protocols (BGP, LDP, MSDP, PCEP).
    I am interested to know what other = security protocols relevant to   KARP use long-lived = keys.
2.  =46rom the fields in = conceptual database and the description it's very clear that this is a = common table not only for security protocols like TCP-AO but also for = routing
     protocols = which use group keys (notably OSPF, ISIS etc..).  = But,
       = a. For one set of routing protocols which use security protocols like = TCP-AO, for E.g., 'interfaces' field is not relevant as key selection is = not done per interface level.
           = Similarly for group keying routing protocols KDF, KDF inputs are not = relevant.
      b. For = lifetime there are 4 fields defined, which seems more relevant to OSPF. = But this can be specified in seconds as well as number of bytes secured = with that key.
          I = don't see any requirement for routing protocols to specify key lifetime = in terms of number of bytes secured and also don't see all routing = protocols as well as
          = security protocols use the same  lifetime format = either.

How = else would one determine it is time for a key = rollover?

      I am not worried about few = extra fields which are relevant to one set of protocols and not at all = relevant to other set. But, I am not sure why we have = to
      club = routing protocols which use group keying, use different transports (L2, = L3, L4)  and do security by themselves  need to be clubbed = with a security
      protocol like TCP-AO which is = specifically designed to protect TCP based pair wise routing protocols = (BGP, LDP etc..).  If separation for a set of
      routing protocols with common = characteristics is provided, more specific and more relevant fields to = the routing protocols can be added  to the table.
3.  Section-3 specifies Key Selection and as mentioned = earlier this is not applicable to security protocols like TCP-AO as key = selection happens by consulting it's
    internal tables. How ever, a routing = protocol which secures it's routing packet by itself can consult this = table.
 
In summary- IMO, as we have various types of routing = protocols it's better to define conceptual key table specific to that = set.
Set1: BGP, LDP, PCEP, and MSDP (Pair = wise TCP based which use security protocol like TCP-AO)
Set 2: OSPF, IS-IS, RIP  (group keying, different = transports and security is provided by themselves)
          &n= bsp;   - OSPFv3 ( Originally defined with IPSec based on the = new draft/RFC it=92s similar to OSPFv2)
          &n= bsp;   - RSVP-TE (I would say still come under group key = category)
Set3:  Multicast routing = protocols like PIM
--
Uma C.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
____________________= ___________________________
karp mailing list
karp@ietf.org
https://www.ietf.org/m= ailman/listinfo/karp

Mahesh = Jethanandani
<= div>


= --Apple-Mail-121-535909857-- From uma.chunduri@ericsson.com Wed Apr 25 10:09:05 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5769221F86BD for ; Wed, 25 Apr 2012 10:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILXCa3uUTsq9 for ; Wed, 25 Apr 2012 10:09:02 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id EFEB921F8675 for ; Wed, 25 Apr 2012 10:09:01 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3PH8p7t002507; Wed, 25 Apr 2012 12:08:58 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.6]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 25 Apr 2012 13:08:56 -0400 From: Uma Chunduri To: Mahesh Jethanandani Date: Wed, 25 Apr 2012 13:08:54 -0400 Thread-Topic: [karp] Q's on karp-crypto-tables Thread-Index: Ac0ilZB/TY9FqsYpRnae6HBz9T2W1gAbmkWQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D1D8138DDF34B34B8BC68A11262D107922422224D3EUSAACMS0701e_" MIME-Version: 1.0 Cc: "karp@ietf.org" Subject: Re: [karp] Q's on karp-crypto-tables X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 17:09:05 -0000 --_000_D1D8138DDF34B34B8BC68A11262D107922422224D3EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 24, 2012, at 5:26 PM, Uma Chunduri wrote: Dear All, I understand the spirit of the http://datatracker.ietf.org/doc/draft-ietf-k= arp-crypto-key-table/?include_text=3D1 WG document. I saw the presentation on the same at IETF83, but still have the following = specific questions and comments. Questions/Comments: --------------------------------- 1. Text in Abstract and Section-1 assumes this conceptual database if for s= ecurity protocols such as TCP-AO with a following exception in Section-1 "In other instances, security protocols will directly use the long= -lived key from the database." AFAICT, KARP is interested in security protocol TCP-AO to protect all T= CP based pair wise routing protocols (BGP, LDP, MSDP, PCEP). I am interested to know what other security protocols relevant to KAR= P use long-lived keys. 2. From the fields in conceptual database and the description it's very cl= ear that this is a common table not only for security protocols like TCP-AO= but also for routing protocols which use group keys (notably OSPF, ISIS etc..). But, a. For one set of routing protocols which use security protocols lik= e TCP-AO, for E.g., 'interfaces' field is not relevant as key selection is = not done per interface level. Similarly for group keying routing protocols KDF, KDF inputs are= not relevant. b. For lifetime there are 4 fields defined, which seems more relevant= to OSPF. But this can be specified in seconds as well as number of bytes s= ecured with that key. I don't see any requirement for routing protocols to specify key = lifetime in terms of number of bytes secured and also don't see all routing= protocols as well as security protocols use the same lifetime format either. How else would one determine it is time for a key rollover? [Uma]: Just by one config option with lifetime in "secs". For all TCP based= pair wise routing protocols which is IKEv2 this can be the best option. Key rollover decision made locally at either end with out neces= sarily having co-ordinated out of band config agreement for this. IKEv2 doesn't negotiate lifetimes. AO is capable of co-oridinate= d key changes with out impacting single TCP segment. By having the 4 fields in the keytable and enforcing in all type= s (sets) of routing protocols we may not utilizing the full potential of what security protocol and KMP we use for some= RPs. I am not worried about few extra fields which are relevant to one set= of protocols and not at all relevant to other set. But, I am not sure why = we have to club routing protocols which use group keying, use different transpor= ts (L2, L3, L4) and do security by themselves need to be clubbed with a s= ecurity protocol like TCP-AO which is specifically designed to protect TCP ba= sed pair wise routing protocols (BGP, LDP etc..). If separation for a set = of routing protocols with common characteristics is provided, more speci= fic and more relevant fields to the routing protocols can be added to the = table. 3. Section-3 specifies Key Selection and as mentioned earlier this is not = applicable to security protocols like TCP-AO as key selection happens by co= nsulting it's internal tables. How ever, a routing protocol which secures it's routin= g packet by itself can consult this table. In summary- IMO, as we have various types of routing protocols it's better = to define conceptual key table specific to that set. Set1: BGP, LDP, PCEP, and MSDP (Pair wise TCP based which use security prot= ocol like TCP-AO) Set 2: OSPF, IS-IS, RIP (group keying, different transports and security i= s provided by themselves) - OSPFv3 ( Originally defined with IPSec based on the new dra= ft/RFC it's similar to OSPFv2) - RSVP-TE (I would say still come under group key category) Set3: Multicast routing protocols like PIM -- Uma C. _______________________________________________ karp mailing list karp@ietf.org https://www.ietf.org/mailman/listinfo/karp Mahesh Jethanandani mjethanandani@gmail.com --_000_D1D8138DDF34B34B8BC68A11262D107922422224D3EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <= BASE=20 href=3D"x-msg://726/">
 
On Apr 24, 2012, at 5:26 PM, Uma Chunduri wrote:

Dear All,
 
I understand the spirit of the http://datatracker.ietf.org/doc/draft-ietf-karp-crypto= -key-table/?include_text=3D1 WG document.
I saw the presentation on the same at IETF83, but still have the=20 following specific questions and comments.
 
Questions/Comments:
---------------------------------
 
1. Text in Abstract and Section-1 assumes this conceptual database i= f for=20 security protocols such as TCP-AO with a following exception in=20 Section-1
 
    &nb= sp;    "In other instances, security protocols w= ill=20 directly use the long-lived key from the database."
    AFAICT, KARP is interested = in=20 security protocol TCP-AO to protect all TCP based pair wise=20 routing   protocols (BGP, LDP, MSDP, PCEP).
    I am interested to know wha= t other=20 security protocols relevant to   KARP use long-lived=20 keys.
2.  From the fields in conceptual databas= e and=20 the description it's very clear that this is a common table not only for= =20 security protocols like TCP-AO but also for routing
     protocols which use g= roup=20 keys (notably OSPF, ISIS etc..).  But,
       a. For on= e set=20 of routing protocols which use security protocols like TCP-AO, for E.g.,= =20 'interfaces' field is not relevant as key selection is not done per inter= face=20 level.
       &nbs= p;  =20 Similarly for group keying routing protocols KDF, KDF inputs are not=20 relevant.
      b. For lifetime= there=20 are 4 fields defined, which seems more relevant to OSPF. But this can be= =20 specified in seconds as well as number of bytes secured with that=20 key.
       &nbs= p; =20 I don't see any requirement for routing protocols to specify key lifetime= in=20 terms of number of bytes secured and also don't see all routing protocols= as=20 well as
       &nbs= p; =20 security protocols use the same  lifetime format=20 either.

How else would one determine it is time for a key rollover? 
[Uma]: Just by one config option with lifetime in=20 "secs". For all TCP based pair wise routing protocols which is IKEv2 t= his=20 can be the best option. 
           K= ey=20 rollover decision made locally at either end  with out= =20 necessarily having co-ordinated out of band config agreement for=20 this.
           I= KEv2=20 doesn't negotiate lifetimes. AO is capable of co-oridinated key change= s=20 with out impacting single TCP segment.
           B= y=20 having the 4 fields in the keytable and enforcing in all types (sets) of ro= uting=20 protocols we may not utilizing the
           f= ull=20 potential of what security protocol and KMP we use for some=20 RPs.
          &n= bsp;        

      I am not worrie= d about=20 few extra fields which are relevant to one set of protocols and not at al= l=20 relevant to other set. But, I am not sure why we have to
      club routing pr= otocols=20 which use group keying, use different transports (L2, L3, L4)  and d= o=20 security by themselves  need to be clubbed with a security
      protocol like T= CP-AO=20 which is specifically designed to protect TCP based pair wise routing=20 protocols (BGP, LDP etc..).  If separation for a set of
      routing protoco= ls with=20 common characteristics is provided, more specific and more relevant field= s to=20 the routing protocols can be added  to the table.
3.  Section-3 specifies Key Selection and= as=20 mentioned earlier this is not applicable to security protocols like TCP-A= O as=20 key selection happens by consulting it's
    internal tables. How ever, = a=20 routing protocol which secures it's routing packet by itself can consult = this=20 table.
 
In summary- IMO, as we have various types of r= outing=20 protocols it's better to define conceptual key table specific to that=20 set.
Set1: BGP, LDP, PCEP, and MSDP (Pair wise TCP = based=20 which use security protocol like TCP-AO)
Set 2: OSPF, IS-IS, RIP  (group keying,=20 different transports and security is provided by themselves)
       &nbs= p;     =20 - OSPFv3 ( Originally defined with IPSec based on the new draft/RFC it= 217;s=20 similar to OSPFv2)
       &nbs= p;     =20 - RSVP-TE (I would say still come under group key category)
Set3:  Multicast routing protocols like=20 PIM
--
Uma C.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
_______________________________________________karp=20 mailing list
karp@ietf.org
https://www.ietf.org/= mailman/listinfo/karp

Mahesh Jethanandani


--_000_D1D8138DDF34B34B8BC68A11262D107922422224D3EUSAACMS0701e_-- From touch@isi.edu Wed Apr 25 15:38:45 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978A811E808C for ; Wed, 25 Apr 2012 15:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.564 X-Spam-Level: X-Spam-Status: No, score=-105.564 tagged_above=-999 required=5 tests=[AWL=1.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fmw1j9T+CZXU for ; Wed, 25 Apr 2012 15:38:44 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id AAA9421F8534 for ; Wed, 25 Apr 2012 15:37:48 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q3PMau3L007630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Apr 2012 15:36:56 -0700 (PDT) Message-ID: <4F987C88.3020008@isi.edu> Date: Wed, 25 Apr 2012 15:36:56 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: Uma Chunduri References: <4F74C93F.5050501@isi.edu> <20341.27199.128277.705512@fireball.kivinen.iki.fi> <4F75ADF6.1020208@isi.edu> <4F7F4F08.5070409@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Sam Hartman , Tero Kivinen , "karp@ietf.org" Subject: Re: [karp] Comments on draft-ietf-karp-crypto-tables X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 22:38:45 -0000 Hi, Uma, On 4/24/2012 5:30 PM, Uma Chunduri wrote: > Hi Joe, > I need more clarity on the discussion you folks had, in particular on new exchanges required by IKEv2 below. > > ==== > When we talk about "the Gatekeeper", I keep referring to that term as I introduced it > in the TCP-AO KMP doc. However, I don't care/mind if that is more generally a translator > between various protocols to exchange key/configuration material and various protocols to > secure routing information. > [Uma]: Sure. > > It's also fine for this new, more general Gatekeeper to have its own tables of > key/configuration material - AFAICT, this is what is meant by "keytables". > > [Uma]: I see Keytables as defined in (http://datatracker.ietf.org/doc/draft-ietf-karp-crypto-key-table/?include_text=1), > defines > a. place holder for negotiated Keys and parameters (either through KMP or manually) > b. Provides a key selection mechanism > Configuration (relevant to both AO and KMP) to help negotiation with KMPs, SA management and key triggers are done by Gatekeeper. > Currently, http://datatracker.ietf.org/doc/draft-chunduri-karp-using-ikev2-with-tcp-ao/ doesn't refer key-tables as it specifies > even "a." as integral part of Gatekeeper and doesn't talk about "b." as it is not needed. > So to be compliant with keytables draft, negotiated keys and associates parameters should be abstracted from the > Gatekeeper (please se my specific comments on key tables draft). This is TBD. Agreed. > IMO, however, it's not necessary that the security protocols directly consult those keytables - IMO, it's the responsibility > of the Gatekeeper to install/manage/maintain that material and convey it to the security protocols. > > [Uma]: Sure. > > The TCP-AO KMP doc focuses on ways to use the Gatekeeper to integrate IKEv2 with new registry entries and/or message > types with TCP-AO. If it turns out that it's preferable to modify IKEv2 to be more specific about a new class of exchanges > focused on routing protocols, that's fine to me. > > [Uma]: IKEv2 today defines IKE_SA_INIT, IKE_AUTH and CREATE_CHILD_SA exchange. I really don't see any need for defining new > class of exchanges TCP based routing protocol SA apart from changes in SA payload > (in IKE_AUTH and to re-key with CREATE_CHILD_SA). I would like to hear why Sam thinks new exchanges are required. FYI, when I talked about new message types I was thinking more about SA payload changes or extensions. I don't know why another class of exchanges is useful, but AFAICT that decision is independent of this architecture. Joe From touch@isi.edu Wed Apr 25 16:52:12 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D5111E8096 for ; Wed, 25 Apr 2012 16:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.593 X-Spam-Level: X-Spam-Status: No, score=-105.593 tagged_above=-999 required=5 tests=[AWL=1.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEMNU1PLDFPq for ; Wed, 25 Apr 2012 16:52:09 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id A61DE11E8076 for ; Wed, 25 Apr 2012 16:52:09 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q3PNohiH019347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Apr 2012 16:50:43 -0700 (PDT) Message-ID: <4F988DD3.9020407@isi.edu> Date: Wed, 25 Apr 2012 16:50:43 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: Mahesh Jethanandani References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "karp@ietf.org" Subject: Re: [karp] Q's on karp-crypto-tables X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 23:52:12 -0000 On 4/24/2012 8:43 PM, Mahesh Jethanandani wrote: > > On Apr 24, 2012, at 5:26 PM, Uma Chunduri wrote: ... >> I don't see any requirement for routing protocols to specify key >> lifetime in terms of number of bytes secured and also don't see all >> routing protocols as well as >> security protocols use the same lifetime format either. > > How else would one determine it is time for a key rollover? Time or byte-based key rollover isn't necessarily required by all protocols. Some protocols have replay counter fields that require bytecount key rollover, but if the replay counter is large enough (e.g., 64 bits), that seems unnecessary. Keys in TCP-AO, e.g., don't have a time-based or byte-based rollover; they are changed as needed (e.g., you can externally change them every day or week to reduce the impact of potential key exposure, or you can change them when you terminate an employee or have other reason to believe there is a need). Joe From internet-drafts@ietf.org Wed Apr 25 22:04:55 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055BA21F88EE; Wed, 25 Apr 2012 22:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPYxspufT2GN; Wed, 25 Apr 2012 22:04:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD93921F8777; Wed, 25 Apr 2012 22:04:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.01p1 Message-ID: <20120426050453.31747.35720.idtracker@ietfa.amsl.com> Date: Wed, 25 Apr 2012 22:04:53 -0700 Cc: karp@ietf.org Subject: [karp] I-D Action: draft-ietf-karp-ops-model-02.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 05:04:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Keying and Authentication for Routing= Protocols Working Group of the IETF. Title : Operations Model for Router Keying Author(s) : Sam Hartman Dacheng Zhang Filename : draft-ietf-karp-ops-model-02.txt Pages : 23 Date : 2012-04-25 Developing an operational and management model for routing protocol security that works across protocols will be critical to the success of routing protocol security efforts. This document discusses issues and begins to consider development of these models. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-karp-ops-model-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-karp-ops-model-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-karp-ops-model/ From hartmans@mit.edu Thu Apr 26 06:39:52 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4ECB21F883F for ; Thu, 26 Apr 2012 06:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.875 X-Spam-Level: X-Spam-Status: No, score=-102.875 tagged_above=-999 required=5 tests=[AWL=-0.610, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwQJixbUeXk2 for ; Thu, 26 Apr 2012 06:39:52 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 570D721F883D for ; Thu, 26 Apr 2012 06:39:52 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id B21B2201CB; Thu, 26 Apr 2012 09:35:23 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 91A1B4768; Thu, 26 Apr 2012 09:39:47 -0400 (EDT) From: Sam Hartman To: Uma Chunduri References: <4F74C93F.5050501@isi.edu> <20341.27199.128277.705512@fireball.kivinen.iki.fi> <4F75ADF6.1020208@isi.edu> <4F7F4F08.5070409@isi.edu> Date: Thu, 26 Apr 2012 09:39:47 -0400 In-Reply-To: (Uma Chunduri's message of "Tue, 24 Apr 2012 20:30:49 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "karp@ietf.org" , Sam Hartman , Tero Kivinen Subject: Re: [karp] Comments on draft-ietf-karp-crypto-tables X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 13:39:53 -0000 After my discussion with Joe, I agree that security protocols need not directly consult the key tables. I think we can reflect that in the next version. From uma.chunduri@ericsson.com Thu Apr 26 10:44:11 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E2B21F86EF for ; Thu, 26 Apr 2012 10:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.297 X-Spam-Level: X-Spam-Status: No, score=-6.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aX0zG07+2n1o for ; Thu, 26 Apr 2012 10:44:11 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0561A21F86FE for ; Thu, 26 Apr 2012 10:44:10 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3QHhXY0032450; Thu, 26 Apr 2012 12:44:06 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.6]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 26 Apr 2012 13:43:36 -0400 From: Uma Chunduri To: Sam Hartman Date: Thu, 26 Apr 2012 13:43:35 -0400 Thread-Topic: [karp] Comments on draft-ietf-karp-crypto-tables Thread-Index: Ac0jshCSjuP0pOFfTyy+iRfT5of/zgAIEW2g Message-ID: References: <4F74C93F.5050501@isi.edu> <20341.27199.128277.705512@fireball.kivinen.iki.fi> <4F75ADF6.1020208@isi.edu> <4F7F4F08.5070409@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "karp@ietf.org" , Tero Kivinen Subject: Re: [karp] Comments on draft-ietf-karp-crypto-tables X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 17:44:11 -0000 =20 After my discussion with Joe, I agree that security protocols need not dir= ectly=20 consult the key tables. I think we can reflect that in the next versi= on. Thx. As I detailed in the other thread, in the similar lines, it's logical = to separate the key tables for RPs=20 which use security protocols and don't use security protocols to secure th= e packets/PDUs. This is important as the=20 properties and characteristics of these 2 categories are vastly different.= IMO, this separation allows=20 1. to relate and refer the key tables easily by other protocol/KMP drafts = and also 2. allows other RPs which don't use sec. protocols to consult key tables t= o secure the PDUs. =09 -- Uma C.