From iesg-secretary@ietf.org Wed Oct 3 10:48:43 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 B629121F84FD; Wed, 3 Oct 2012 10:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JT6xRJ6PMOO; Wed, 3 Oct 2012 10:48:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514B821F84B6; Wed, 3 Oct 2012 10:48:43 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121003174843.21226.13609.idtracker@ietfa.amsl.com> Date: Wed, 03 Oct 2012 10:48:43 -0700 Cc: karp@ietf.org Subject: [karp] Last Call: (Analysis of OSPF Security According to KARP Design Guide) to Informational RFC X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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, 03 Oct 2012 17:48:43 -0000 The IESG has received a request from the Keying and Authentication for Routing Protocols WG (karp) to consider the following document: - 'Analysis of OSPF Security According to KARP Design Guide' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-10-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in section 4.2 of RFC6518. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-karp-ospf-analysis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-karp-ospf-analysis/ballot/ No IPR declarations have been submitted directly on this I-D. From uma.chunduri@ericsson.com Fri Oct 5 11:48:35 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 F034F21F8438 for ; Fri, 5 Oct 2012 11:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RF162WDvS7iy for ; Fri, 5 Oct 2012 11:48:34 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7289221F842B for ; Fri, 5 Oct 2012 11:48:34 -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 q95Img7e014666 for ; Fri, 5 Oct 2012 13:48:43 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.204]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 5 Oct 2012 14:48:27 -0400 From: Uma Chunduri To: "karp@ietf.org" Date: Fri, 5 Oct 2012 14:48:26 -0400 Thread-Topic: New Version Notification for draft-chunduri-karp-is-is-gap-analysis-02.txt Thread-Index: Ac2jI4EKhKTrtbiIQ0WT1FkwbAsIoAAATrBg Message-ID: 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 Subject: [karp] New Version Notification for draft-chunduri-karp-is-is-gap-analysis-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: Fri, 05 Oct 2012 18:48:35 -0000 =20 Dear KarpWG, We have updated the IS-IS Gap analysis document and this version contain u= pdates for=20 - Comments we got from Sam Hartman and Manav Bhatia (when we presented la= st two times) - review comments we got from Naiming Shen and=20 - few early Comments from Joel Halpern=20 We request you to review and provide your feedback further. Uma, Albert and Wenhu -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Friday, October 05, 2012 11:02 AM To: Uma Chunduri A new version of I-D, draft-chunduri-karp-is-is-gap-analysis-02.txt has been successfully submitted by Uma Chunduri and posted to the IETF repo= sitory. Filename: draft-chunduri-karp-is-is-gap-analysis Revision: 02 Title: KARP IS-IS security gap analysis Creation date: 2012-10-05 WG ID: Individual Submission Number of pages: 12 Abstract: This document analyzes the threats applicable for Intermediate system to Intermediate system (IS-IS) routing protocol and security gaps according to the KARP Design Guide. This document also provides specific requirements to address the gaps with both manual and auto key management protocols. = =20 The IETF Secretariat From uma.chunduri@ericsson.com Fri Oct 5 11:53:19 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 0D23D21F87F7 for ; Fri, 5 Oct 2012 11:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nUeU2mfgflw for ; Fri, 5 Oct 2012 11:53:18 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8284E21F87AB for ; Fri, 5 Oct 2012 11:53:18 -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 q95IqSHc015615 for ; Fri, 5 Oct 2012 13:53:27 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.204]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 5 Oct 2012 14:53:11 -0400 From: Uma Chunduri To: "karp@ietf.org" Date: Fri, 5 Oct 2012 14:53:10 -0400 Thread-Topic: New Version Notification for draft-chunduri-karp-kmp-router-fingerprints-01.txt Thread-Index: Ac2jH6/lWWzZVlQDSYqrEjCo2C8f3gABHk8A Message-ID: 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 Subject: [karp] New Version Notification for draft-chunduri-karp-kmp-router-fingerprints-01.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: Fri, 05 Oct 2012 18:53:19 -0000 Dear WG, We have updated the KARP-Fingerprint authentication document by taking care= specific=20 comments we got when we presented this draft last IETF.=20 We would be thankful for further comments and feedback on this. Uma and Albert -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Friday, October 05, 2012 10:34 AM To: Uma Chunduri A new version of I-D, draft-chunduri-karp-kmp-router-fingerprints-01.txt has been successfully submitted by Uma Chunduri and posted to the IETF repo= sitory. Filename: draft-chunduri-karp-kmp-router-fingerprints Revision: 01 Title: KARP KMP: Simplified Peer Authentication Creation date: 2012-10-05 WG ID: Individual Submission Number of pages: 10 Abstract: This document describes the usage of Router Fingerprint Authentication (RFA) with public keys as a potential peer authentication method with KARP Key Management Protocol (KMP). The advantage of RFA is, neither it requires out-of-band, mutually agreeable symmetric keys nor a full PKI based system (trust anchor or CA certificates) for mutual authentication of the peers with KARP KMP deployments. Usage of Router Fingerprints give a significant operational improvement from symmetric key based systems and yet provide a secure authentication technique. = =20 The IETF Secretariat From ginsberg@cisco.com Sun Oct 7 13:46:10 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 059C621F870E; Sun, 7 Oct 2012 13:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzhEpg+HIDpf; Sun, 7 Oct 2012 13:46:09 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 076D121F86E5; Sun, 7 Oct 2012 13:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2830; q=dns/txt; s=iport; t=1349642769; x=1350852369; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=PyGDe4a8SP1H3t+brvo5hDQVj245b3P0+oaSTIgJQWk=; b=fGBcJ6Q6cFhyYfXL6bP/oLQ6ZuNvgig3rpVK69GOtSfOOrRJsl6PXv/j IGTnLk+o9/8Io3Mk1VsxyMbkMb/vpzF55Nl3HUYbuTzKVReT7YbOEBw8k m3h0IWmV9m/yDPM+gmPTV6AfSJ52TGf/0JUMtojAJbhwUocv3j/DZajZ0 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJTpcVCtJXG+/2dsb2JhbABFvyGBCIIgAQEBBAEBAQ8BJzQXBAIBCBEEAQELFAkHJwsUCAEIAgQBEggBGYdjC5kDnneLTxqFFmADlwCKEYMfgWmCbYFjNA X-IronPort-AV: E=Sophos;i="4.80,548,1344211200"; d="scan'208";a="129191458" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 07 Oct 2012 20:46:08 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q97Kk8ZB002967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 7 Oct 2012 20:46:08 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.001; Sun, 7 Oct 2012 15:46:08 -0500 From: "Les Ginsberg (ginsberg)" To: "isis-wg@ietf.org" , "karp@ietf.org" Thread-Topic: [Isis-wg] FW: I-D Action: draft-chunduri-karp-is-is-gap-analysis-02.txt Thread-Index: AQH0YYvFe90q5LpjwaYD4fWye8XnA5dej//QgAJEdcA= Date: Sun, 7 Oct 2012 20:46:08 +0000 Message-ID: References: <20121005180149.3032.42028.idtracker@ietfa.amsl.com> <125001cda3a9$a0e69940$e2b3cbc0$@olddog.co.uk> In-Reply-To: <125001cda3a9$a0e69940$e2b3cbc0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.144.60] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19250.001 x-tm-as-result: No--42.426500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [karp] [Isis-wg] FW: I-D Action: draft-chunduri-karp-is-is-gap-analysis-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: Sun, 07 Oct 2012 20:46:10 -0000 The draft fails to mention (Section 2.3.1(2)) that the mechanisms defined i= n the IS-IS base specification (ISO 10589) provide for efficient recovery f= rom all LSP replay attacks - including inter-session replay.=20 This is particularly disappointing in that this point has been discussed at= some length in the context of draft-chunduri-isis-extended-sequence-no-tl= v. Please see: http://www.ietf.org/mail-archive/web/isis-wg/current/msg03023.html Les > -----Original Message----- > From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On Behal= f Of > Adrian Farrel > Sent: Saturday, October 06, 2012 3:02 AM > To: isis-wg@ietf.org > Subject: [Isis-wg] FW: I-D Action: draft-chunduri-karp-is-is-gap-analysis= - > 02.txt >=20 > Heads up >=20 > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.o= rg] > > On Behalf Of internet-drafts@ietf.org > > Sent: 05 October 2012 19:02 > > To: i-d-announce@ietf.org > > Subject: I-D Action: draft-chunduri-karp-is-is-gap-analysis-02.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : KARP IS-IS security gap analysis > > Author(s) : Uma Chunduri > > Albert Tian > > Wenhu Lu > > Filename : draft-chunduri-karp-is-is-gap-analysis-02.txt > > Pages : 12 > > Date : 2012-10-05 > > > > Abstract: > > This document analyzes the threats applicable for Intermediate syste= m > > to Intermediate system (IS-IS) routing protocol and security gaps > > according to the KARP Design Guide. This document also provides > > specific requirements to address the gaps with both manual and auto > > key management protocols. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-chunduri-karp-is-is-gap-analysis > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-chunduri-karp-is-is-gap-analysis-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-chunduri-karp-is-is-gap-analys= is-02 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From uma.chunduri@ericsson.com Mon Oct 8 13:12:44 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 D9C0321F87FC; Mon, 8 Oct 2012 13:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkgCm1AVaN1M; Mon, 8 Oct 2012 13:12:44 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC4421F8702; Mon, 8 Oct 2012 13:12:44 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q98KBZWQ013534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Oct 2012 15:12:43 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.44]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 8 Oct 2012 16:12:23 -0400 From: Uma Chunduri To: "Les Ginsberg (ginsberg)" , "isis-wg@ietf.org" , "karp@ietf.org" Date: Mon, 8 Oct 2012 16:12:22 -0400 Thread-Topic: [karp] [Isis-wg] FW: I-D Action: draft-chunduri-karp-is-is-gap-analysis-02.txt Thread-Index: AQH0YYvFe90q5LpjwaYD4fWye8XnA5dej//QgAJEdcCAAYOT4A== Message-ID: References: <20121005180149.3032.42028.idtracker@ietfa.amsl.com> <125001cda3a9$a0e69940$e2b3cbc0$@olddog.co.uk> 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 Subject: Re: [karp] [Isis-wg] FW: I-D Action: draft-chunduri-karp-is-is-gap-analysis-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: Mon, 08 Oct 2012 20:12:45 -0000 Les, Your point is valid and it is relevant to mention the what ever current rec= overy mechanism we have in the face of the attack.=20 This is precisely one of the goals of the document and we will take this c= omment. --=20 Uma C.=20 PS: The link you mentioned below is regarding the partial deployment issue = you pointed out (with ESN TLV draft) and you know=20 we are working with you on that as we speak. -----Original Message----- From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf Of Les= Ginsberg (ginsberg) Sent: Sunday, October 07, 2012 1:46 PM To: isis-wg@ietf.org; karp@ietf.org Subject: Re: [karp] [Isis-wg] FW: I-D Action: draft-chunduri-karp-is-is-gap= -analysis-02.txt The draft fails to mention (Section 2.3.1(2)) that the mechanisms defined i= n the IS-IS base specification (ISO 10589) provide for efficient recovery f= rom all LSP replay attacks - including inter-session replay.=20 This is particularly disappointing in that this point has been discussed at= some length in the context of draft-chunduri-isis-extended-sequence-no-tl= v. Please see: http://www.ietf.org/mail-archive/web/isis-wg/current/msg03023.html Les > -----Original Message----- > From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On=20 > Behalf Of Adrian Farrel > Sent: Saturday, October 06, 2012 3:02 AM > To: isis-wg@ietf.org > Subject: [Isis-wg] FW: I-D Action:=20 > draft-chunduri-karp-is-is-gap-analysis- > 02.txt >=20 > Heads up >=20 > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org=20 > > [mailto:i-d-announce-bounces@ietf.org] > > On Behalf Of internet-drafts@ietf.org > > Sent: 05 October 2012 19:02 > > To: i-d-announce@ietf.org > > Subject: I-D Action: draft-chunduri-karp-is-is-gap-analysis-02.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : KARP IS-IS security gap analysis > > Author(s) : Uma Chunduri > > Albert Tian > > Wenhu Lu > > Filename : draft-chunduri-karp-is-is-gap-analysis-02.txt > > Pages : 12 > > Date : 2012-10-05 > > > > Abstract: > > This document analyzes the threats applicable for Intermediate syste= m > > to Intermediate system (IS-IS) routing protocol and security gaps > > according to the KARP Design Guide. This document also provides > > specific requirements to address the gaps with both manual and auto > > key management protocols. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-chunduri-karp-is-is-gap-analy > > sis > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-chunduri-karp-is-is-gap-analysis-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-chunduri-karp-is-is-gap-analy > > sis-02 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg _______________________________________________ karp mailing list karp@ietf.org https://www.ietf.org/mailman/listinfo/karp From turners@ieca.com Mon Oct 8 13:23:25 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 0CBD521F84C8 for ; Mon, 8 Oct 2012 13:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.106 X-Spam-Level: X-Spam-Status: No, score=-102.106 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OX+FseHuTwJ8 for ; Mon, 8 Oct 2012 13:23:24 -0700 (PDT) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [69.56.144.10]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC8321F81FE for ; Mon, 8 Oct 2012 13:23:24 -0700 (PDT) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id CF2E935210D36; Mon, 8 Oct 2012 15:23:26 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway13.websitewelcome.com (Postfix) with ESMTP id C1FA435210D11 for ; Mon, 8 Oct 2012 15:23:26 -0500 (CDT) Received: from [198.180.150.230] (port=49639 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TLJrH-0004dE-QA; Mon, 08 Oct 2012 15:23:23 -0500 Message-ID: <5073363A.6080301@ieca.com> Date: Mon, 08 Oct 2012 15:23:22 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Uma Chunduri References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [198.180.150.230]:49639 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "karp@ietf.org" Subject: Re: [karp] New Version Notification for draft-chunduri-karp-is-is-gap-analysis-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: Mon, 08 Oct 2012 20:23:25 -0000 The IESG recently reviewed IS-IS multi-instance (https://datatracker.ietf.org/doc/draft-ietf-isis-mi/). Should this draft address that draft? spt On 10/5/12 1:48 PM, Uma Chunduri wrote: > > Dear KarpWG, > > We have updated the IS-IS Gap analysis document and this version contain updates for > - Comments we got from Sam Hartman and Manav Bhatia (when we presented last two times) > - review comments we got from Naiming Shen and > - few early Comments from Joel Halpern > > We request you to review and provide your feedback further. > > Uma, Albert and Wenhu > > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, October 05, 2012 11:02 AM > To: Uma Chunduri > > A new version of I-D, draft-chunduri-karp-is-is-gap-analysis-02.txt > has been successfully submitted by Uma Chunduri and posted to the IETF repository. > > Filename: draft-chunduri-karp-is-is-gap-analysis > Revision: 02 > Title: KARP IS-IS security gap analysis > Creation date: 2012-10-05 > WG ID: Individual Submission > Number of pages: 12 > > Abstract: > This document analyzes the threats applicable for Intermediate system > to Intermediate system (IS-IS) routing protocol and security gaps > according to the KARP Design Guide. This document also provides > specific requirements to address the gaps with both manual and auto > key management protocols. > > > > > The IETF Secretariat > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From uma.chunduri@ericsson.com Tue Oct 9 16:00:32 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 3865821F84A7 for ; Tue, 9 Oct 2012 16:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JRZ0klErsGR for ; Tue, 9 Oct 2012 16:00:31 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id B83EB21F84D7 for ; Tue, 9 Oct 2012 16:00:31 -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 q99N1HCo014696; Tue, 9 Oct 2012 18:01:18 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.44]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 9 Oct 2012 19:00:24 -0400 From: Uma Chunduri To: Sean Turner Date: Tue, 9 Oct 2012 19:00:22 -0400 Thread-Topic: [karp] New Version Notification for draft-chunduri-karp-is-is-gap-analysis-02.txt Thread-Index: Ac2lkstMFfiTelHcSeSWzrh3QLXpQQA3UkWQ Message-ID: References: <5073363A.6080301@ieca.com> In-Reply-To: <5073363A.6080301@ieca.com> 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" Subject: Re: [karp] New Version Notification for draft-chunduri-karp-is-is-gap-analysis-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: Tue, 09 Oct 2012 23:00:32 -0000 Hi Sean, >>> The IESG recently reviewed IS-IS multi-instance (https://datatracker.ie= tf.org/doc/draft-ietf-isis-mi/). =20 >>> Should this draft address that draft? The short answer is - I don't know [yet].=20 The problem is, this document doesn't specify more about or very abstract o= n how this technology can be used/deployed.=20 I have gone through this and in touch with one of the authors for specific = questions I have. Regardless, I would expect the security considerations of the MI draft should enumerate any particular= s differences it may have specific to MI and=20 the karp draft should derive any new requirements including say for e.g., = group keying. -- Uma C. From uma.chunduri@ericsson.com Tue Oct 9 16:35:50 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 CEE7611E80E2; Tue, 9 Oct 2012 16:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2BbClS75-To; Tue, 9 Oct 2012 16:35:50 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3B911E80D5; Tue, 9 Oct 2012 16:35:50 -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 q99NaUvp018410; Tue, 9 Oct 2012 18:36:32 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.44]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 9 Oct 2012 19:35:43 -0400 From: Uma Chunduri To: "Les Ginsberg (ginsberg)" , "Bhatia, Manav (Manav)" , "Naiming Shen (naiming)" Date: Tue, 9 Oct 2012 19:35:42 -0400 Thread-Topic: draft-chunduri-isis-extended-sequence-no-tlv - other comments Thread-Index: AcyVD3r+AHoMB7E2R0+4FJMQgKrozAAACfDQHh1xsYAAGkt94AAFMrTQAAJooMAAEcn4IAAkpaZwAAF6EGAARrMx8AAHbW2QABsjBQAleEa6QA== Message-ID: References: <4F31FB49-B9B2-492E-BC9E-A32986E4BCF0@cisco.com><4EA9D09A.6070206@googlemail.com> <7C 362EEF9C7896 468B36C9B79200D8350D02E41D5D@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: multipart/alternative; boundary="_000_D1D8138DDF34B34B8BC68A11262D10792B6128E36AEUSAACMS0701e_" MIME-Version: 1.0 Cc: Mike Shand , "isis-wg@ietf.org" , "karp@ietf.org" Subject: Re: [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: Tue, 09 Oct 2012 23:35:51 -0000 --_000_D1D8138DDF34B34B8BC68A11262D10792B6128E36AEUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Les, Replies in-line [Uma]: Here are the remainder of my comments on the draft: In regards to SNPs, the presence of replayed SNPs will cause unnecessary re= flooding 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 res= ult of replayed SNPs, this is the one usage which could be enabled in the p= resence of partial deployment. In regards to IIHs, replayed IIHs could cause adjacency flapping which coul= d be very disruptive. The danger lies when not all systems on a link suppor= t the extension - which on multi-access links can lead to multiple DISs bei= ng elected and violations of the assumption of transitivity. For this reaso= n, enablement cannot be safely done in the presence of legacy systems. [Uma]: draft-chunduri-isis-extended-sequence-no-tlv-02.txt has been update= d (section 5) to cover the partial deployment cases. This addressees not on= ly IIH but all PDUs. There is no flag day requirement here. Given the discussion in the draft about enhancements to provide routing pro= tocols 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 k= ey management protocol. The cost of having router vendors and their custome= rs implement, deploy, and support extended sequence #s must be weighed agai= nst the benefits. [Uma]: You talked about the cost above. When an operator deploys any key m= anagement protocol in general, the advantages it brings in are far more big= ger than the mitigation of replay attacks. But, the cost could be prohibi= tive if any key management protocol including group key management is deplo= yed only for the purpose of replay protection. Just for this reason a manu= al key mechanism to effectively eliminate the issue with replay attack is a= lways useful. This is clearly discussed in Section 1 of the document. It's = also worth mentioning here, neither such a group keying RFC which can deri= ve keys for a group IGPs look for exist yet nor a smooth mechanism for int= egration yet defined. As discussed in an earlier thread, IS-IS already has a reliable mechanism t= o recover from replayed LSPs. [Uma]: We discussed in length on this and reliable recovery comes only afte= r the replay is successful and the certain damage it brings in all over. We take this opportunity acknowledge for providing early feedback on the so= lution for partial deployment issue. -- Uma C. --_000_D1D8138DDF34B34B8BC68A11262D10792B6128E36AEUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Les,
 
Replies in-line [Uma]:
 
 
Here are the remainder of my comments on the draft:
=
In=20 regards to SNPs, the presence of replayed SNPs will cause unnecessary reflo= oding=20 of LSPs but will not actually cause any change in the LSPDB of any router. = The=20 unnecessary flooding would be limited to the link on which the replayed SNP= s=20 appear. Because no actual LSPDB changes would occur as a result of replayed= =20 SNPs, this is the one usage which could be enabled in the presence of parti= al=20 deployment.

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

[Uma]: =20 draft-chunduri-isis-extended-sequence-no-tlv-02.txt has been updated (secti= on 5)=20 to cover the partial deployment cases. This addressees not only IIH but all= =20 PDUs. There is no flag day requirement here.

Given the discus= sion=20 in the draft about enhancements to provide routing protocols with a group k= ey=20 management protocol in the future, it is prudent to look at the value add o= f=20 extended sequence #s in the presence of a group key management protocol. Th= e=20 cost of having router vendors and their customers implement, deploy, and su= pport=20 extended sequence #s must be weighed against the benefits.

[Uma]: You talked about the cost ab= ove. When=20 an operator deploys any  key management protocol in general, the advan= tages=20 it brings in are far more bigger than the mitigation of  replay=20 attacks.  But, the cost could be prohibitive if any key management pro= tocol=20 including group key management is deployed only  = ;for=20 the purpose of replay protection. Just for this reason a manual key mechani= sm to=20 effectively eliminate the issue with replay attack is always useful. This i= s=20 clearly discussed in Section 1 of the document. It's also worth mentio= ning=20 here,  neither such a group keying RFC which can derive keys for = a=20 group IGPs look for  exist yet nor a smooth mechanism for integration = yet=20 defined.

As discussed in an earlier thread, IS-IS already has a reliable mechanis= m to=20 recover from replayed LSPs.

[Uma]: We discussed in length on this and reliable= =20 recovery comes only after the replay is successful and the certain dam= age=20 it brings in all over.


We take this opportunity acknowledge for provi= ding=20 early feedback on the solution for partial deployment issue.

--

Uma C.

 

 

 

 --_000_D1D8138DDF34B34B8BC68A11262D10792B6128E36AEUSAACMS0701e_-- From ginsberg@cisco.com Wed Oct 10 21:16:43 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 5C9F521F8608; Wed, 10 Oct 2012 21:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.478 X-Spam-Level: X-Spam-Status: No, score=-10.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvplKEt57ggF; Wed, 10 Oct 2012 21:16:40 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E377521F860B; Wed, 10 Oct 2012 21:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15597; q=dns/txt; s=iport; t=1349929000; x=1351138600; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=L/+W5s7NMa41LnhutboGXtanTC/yzJvASrSaqX3v9hU=; b=fDVTNtog4nzuB+rDSjo7P4JFBZOprzL5O6Ky0ahdkWHkOEgtyZvQ4gI5 mcgCr8sCDQdI3LdrimC2j34N0AED0FxNY3KvC28ZNv8h/4tEMPHlL/Jv1 XyZtgCHADj6djgPlgz4t6XTgwvecu0tjyQOrjVyRjxQc7jZ7ml5vsUPEb 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAK1HdlCtJV2Y/2dsb2JhbABEgku8cIEIgiABAQEEEgEaTBACAQgRBAEBCx0HMhQJCAIEAQ0FCBMHh2KYU6Abi0cUhSxgA4s9kH+HdYFrgm2BWj0 X-IronPort-AV: E=Sophos;i="4.80,569,1344211200"; d="scan'208,217";a="127415918" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 11 Oct 2012 04:16:39 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9B4GdCZ004028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Oct 2012 04:16:39 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Wed, 10 Oct 2012 23:16:38 -0500 From: "Les Ginsberg (ginsberg)" To: Uma Chunduri , "Bhatia, Manav (Manav)" , "Naiming Shen (naiming)" Thread-Topic: draft-chunduri-isis-extended-sequence-no-tlv - other comments Thread-Index: AcyVD3r+AHoMB7E2R0+4FJMQgKrozAAACfDQHh1xsYAAGkt94AAFMrTQAAJooMAAEcn4IAAkpaZwAAF6EGAARrMx8AAHbW2QABsjBQAleEa6QAA8ENiA Date: Thu, 11 Oct 2012 04:16:37 +0000 Message-ID: References: <4F31FB49-B9B2-492E-BC9E-A32986E4BCF0@cisco.com><4EA9D09A.6070206@googlemail.com> <7C 362EEF9C7896 468B36C9B79200D8350D02E41D5D@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.127.197] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19258.000 x-tm-as-result: No--36.989500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_F3ADE4747C9E124B89F0ED2180CC814F11840654xmbalnx02ciscoc_" MIME-Version: 1.0 Cc: Mike Shand , "isis-wg@ietf.org" , "karp@ietf.org" Subject: Re: [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: Thu, 11 Oct 2012 04:16:43 -0000 --_000_F3ADE4747C9E124B89F0ED2180CC814F11840654xmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Uma - In regards to the new Section 5 on deployment considerations, I think your = presentation is a bit misleading. It suggests that if you follow the steps = outlined (enable send only, then enable verify) that you are guaranteed a h= itless transition. But this is only the case if there is no replay attack o= ccurring during the transition. I think you need to emphasize that for the = appropriate scope (link for IIHs, SNPs - area/domain for LSPs) that the tra= nsition to "verify" needs to be made as close to atomically as possible so = as to avoid inconsistencies which can occur if a replay attack occurs durin= g the transition window. In regards to the usefulness of the extension in LSPs I think your presenta= tion is less than candid. You say in Section 2 that LSPs are vulnerable to = inter-session replay attack - but, as we have previously discussed at lengt= h, the inter-session LSP replay attack scenarios are highly unlikely and th= e same base protocol mechanisms which protect LSPs against intra-session re= plays also allow the protocol to quickly recover from inter-session attacks= . This differs markedly from the case for IIHs and SNPs where no replay pro= tection is available at present. The value add of Extended Sequence # in LSPs is about as close to nil as on= e can get. I would much prefer if the use of Extended Sequence #s in LSPs w= as removed from the draft (with explanation as to why). If you are unwillin= g to do that at least be fair in your presentation. You have a good use cas= e argument for IIHs and SNPs - but the case for LSPs is quite weak and it w= ould be good to be candid about that so vendors/customers can understand th= e value proposition . Les From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] Sent: Tuesday, October 09, 2012 4:36 PM To: Les Ginsberg (ginsberg); Bhatia, Manav (Manav); Naiming Shen (naiming) Cc: Mike Shand; isis-wg@ietf.org; karp@ietf.org Subject: RE: draft-chunduri-isis-extended-sequence-no-tlv - other comments Les, Replies in-line [Uma]: Here are the remainder of my comments on the draft: In regards to SNPs, the presence of replayed SNPs will cause unnecessary re= flooding 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 res= ult of replayed SNPs, this is the one usage which could be enabled in the p= resence of partial deployment. In regards to IIHs, replayed IIHs could cause adjacency flapping which coul= d be very disruptive. The danger lies when not all systems on a link suppor= t the extension - which on multi-access links can lead to multiple DISs bei= ng elected and violations of the assumption of transitivity. For this reaso= n, enablement cannot be safely done in the presence of legacy systems. [Uma]: draft-chunduri-isis-extended-sequence-no-tlv-02.txt has been update= d (section 5) to cover the partial deployment cases. This addressees not on= ly IIH but all PDUs. There is no flag day requirement here. Given the discussion in the draft about enhancements to provide routing pro= tocols 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 k= ey management protocol. The cost of having router vendors and their custome= rs implement, deploy, and support extended sequence #s must be weighed agai= nst the benefits. [Uma]: You talked about the cost above. When an operator deploys any key m= anagement protocol in general, the advantages it brings in are far more big= ger than the mitigation of replay attacks. But, the cost could be prohibi= tive if any key management protocol including group key management is deplo= yed only for the purpose of replay protection. Just for this reason a manu= al key mechanism to effectively eliminate the issue with replay attack is a= lways useful. This is clearly discussed in Section 1 of the document. It's = also worth mentioning here, neither such a group keying RFC which can deri= ve keys for a group IGPs look for exist yet nor a smooth mechanism for int= egration yet defined. As discussed in an earlier thread, IS-IS already has a reliable mechanism t= o recover from replayed LSPs. [Uma]: We discussed in length on this and reliable recovery comes only afte= r the replay is successful and the certain damage it brings in all over. We take this opportunity acknowledge for providing early feedback on the so= lution for partial deployment issue. -- Uma C. --_000_F3ADE4747C9E124B89F0ED2180CC814F11840654xmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Uma –

 <= /p>

In regards to the new Sec= tion 5 on deployment considerations, I think your presentation is a bit mis= leading. It suggests that if you follow the steps outlined (enable send only, then enable verify) that you are guaranteed a hitless t= ransition. But this is only the case if there is no replay attack occurring= during the transition. I think you need to emphasize that for the appropri= ate scope (link for IIHs, SNPs – area/domain for LSPs) that the transition to “verify” needs to= be made as close to atomically as possible so as to avoid inconsistencies = which can occur if a replay attack occurs during the transition window.

 <= /p>

In regards to the usefuln= ess of the extension in LSPs I think your presentation is less than candid.= You say in Section 2 that LSPs are vulnerable to inter-session replay attack – but, as we have previously discussed at length, the inter-session LSP replay attack scenarios are highly unlikely and the s= ame base protocol mechanisms which protect LSPs against intra-session repla= ys also allow the protocol to quickly recover from inter-session attacks. T= his differs markedly from the case for IIHs and SNPs where no replay protection is available at present.=

 <= /p>

The value add of Extended= Sequence # in LSPs is about as close to nil as one can get. I would much p= refer if the use of Extended Sequence #s in LSPs was removed from the draft (with explanation as to why). If you are unwilling to do th= at at least be fair in your presentation. You have a good use case argument= for IIHs and SNPs – but the case for LSPs is quite weak and it would= be good to be candid about that so vendors/customers can understand the value proposition .

 <= /p>

   Les

 <= /p>

 <= /p>

From: Uma Chun= duri [mailto:uma.chunduri@ericsson.com]
Sent: Tuesday, October 09, 2012 4:36 PM
To: Les Ginsberg (ginsberg); Bhatia, Manav (Manav); Naiming Shen (na= iming)
Cc: Mike Shand; isis-wg@ietf.org; karp@ietf.org
Subject: RE: draft-chunduri-isis-extended-sequence-no-tlv - other co= mments

 

Les,

 

Replies in-line [Uma]:<= o:p>

 

 

Here are the remain= der of my comments on the draft:

In regards to SNPs, the presence of replayed SNPs will cause unnecessary re= flooding 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 coul= d be very disruptive. The danger lies when not all systems on a link suppor= t the extension - which on multi-access links can lead to multiple DISs bei= ng elected and violations of the assumption of transitivity. For this reason, enablement cannot be safely d= one in the presence of legacy systems.

[Uma]:  draft-chunduri-isis-extended-sequen= ce-no-tlv-02.txt has been updated (section 5) to cover the partial deployme= nt cases. This addressees not only IIH but all PDUs. There is no flag day r= equirement here.

Given the discussion in the draft about enhancements to provide routing pro= tocols 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 k= ey management protocol. The cost of having router vendors and their customers implement, deploy, and suppor= t extended sequence #s must be weighed against the benefits.

[Uma]: You talked about the = cost above. When an operator deploys any  key management protocol in g= eneral, the advantages it brings in are far more bigger than the mitigation= of  replay attacks.  But, the cost could be prohibitive if any key management protocol including group key manageme= nt is deployed only  for the purpose of replay p= rotection. Just for this reason a manual key mechanism to effectively elimi= nate the issue with replay attack is always useful. This is clearly discussed in Section 1 of the document. It's = also worth mentioning here,  neither such a group keying RFC whic= h can derive keys for a group IGPs look for  exist yet nor a smooth me= chanism for integration yet defined.

As discussed in an earlier thread, IS-I= S already has a reliable mechanism to recover from replayed LSPs.

[Uma]: We discussed in lengt= h on this and reliable recovery comes only after the replay is successful a= nd the certain damage it brings in all over.


We take this opportunity acknowledge for providi= ng early feedback on the solution for partial deployment issue.=

--

Uma C.

 

 

 

--_000_F3ADE4747C9E124B89F0ED2180CC814F11840654xmbalnx02ciscoc_-- From turners@ieca.com Thu Oct 11 18:22:58 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 4B7AC1F0417 for ; Thu, 11 Oct 2012 18:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.15 X-Spam-Level: X-Spam-Status: No, score=-102.15 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gc0d3fyDI1vP for ; Thu, 11 Oct 2012 18:22:57 -0700 (PDT) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [67.18.72.134]) by ietfa.amsl.com (Postfix) with ESMTP id D053E1F040A for ; Thu, 11 Oct 2012 18:22:57 -0700 (PDT) Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id 6F9E1E8726CAB; Thu, 11 Oct 2012 20:23:01 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway12.websitewelcome.com (Postfix) with ESMTP id 61A6AE8726C6B for ; Thu, 11 Oct 2012 20:23:01 -0500 (CDT) Received: from [198.180.150.230] (port=56069 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TMTxp-00046l-30; Thu, 11 Oct 2012 20:22:57 -0500 Message-ID: <50773A2A.5050400@ieca.com> Date: Thu, 11 Oct 2012 16:29:14 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Uma Chunduri References: <5073363A.6080301@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [198.180.150.230]:56069 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 9 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "karp@ietf.org" Subject: Re: [karp] New Version Notification for draft-chunduri-karp-is-is-gap-analysis-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: Fri, 12 Oct 2012 01:22:58 -0000 Uma, Great. I just wanted to make sure the dots were connected. Cheers, spt On 10/9/12 6:00 PM, Uma Chunduri wrote: > Hi Sean, > >>>> The IESG recently reviewed IS-IS multi-instance (https://datatracker.ietf.org/doc/draft-ietf-isis-mi/). >>>> Should this draft address that draft? > > The short answer is - I don't know [yet]. > > The problem is, this document doesn't specify more about or very abstract on how this technology can be used/deployed. > > I have gone through this and in touch with one of the authors for specific questions I have. Regardless, I would expect > the security considerations of the MI draft should enumerate any particulars differences it may have specific to MI and > the karp draft should derive any new requirements including say for e.g., group keying. > > -- > Uma C. > > > > From russw@riw.us Wed Oct 17 14:01:54 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 6326021F8578; Wed, 17 Oct 2012 14:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWXVXG1xvtpc; Wed, 17 Oct 2012 14:01:48 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 03EC021F846A; Wed, 17 Oct 2012 14:01:48 -0700 (PDT) Received: from rrcs-24-199-145-66.midsouth.biz.rr.com ([24.199.145.66] helo=[192.168.3.130]) by da31.namelessnet.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TOakN-0005oj-30; Wed, 17 Oct 2012 14:01:47 -0700 Message-ID: <507F1CC1.7070301@riw.us> Date: Wed, 17 Oct 2012 17:01:53 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtg-ads@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: rtg-dir@ietf.org, karp@ietf.org, draft-ietf-karp-ospf-analysis.all@tools.ietf.org Subject: [karp] RtgDir review: draft-ietf-karp-ospf-analysis-05 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, 17 Oct 2012 21:01:54 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-karp-ospf-analysis-05 Reviewer: Russ White Review Date: 17 October 2012 IETF LC End Date: Intended Status: Informational Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: This draft is well written and formatted, and serves a useful need within the intersection of security and routing protocols. In general, the draft is ready for publication, but I did have one or two questions or areas where things might be clarified in order to make the final result more readable. Major Issues: None Minor Issues: The OSPFv2 replay mechanism does not handle packet priorities as described. If packets are processed out-of-order, then if the sequence number increases, packets processed later will be discarded. I'm not certain I understand this --packet processing priority within the ospf process, or for inbound queue processing? Or for processing packets in the order in which they are recieved? It might be useful to explain which one is being discussed. == There is another serious problem with the OSPFv3 security: rather than being integrated into OSPF, it is based on IPsec. In practice, this has lead to deployment problems. I assume this means in terms of deployment difficulty --I'd just like to make certain the WG agreed with this assessment overall (while I tend to agree, I remember there being some pushback on this type of statement in the past). Nits: Single space after periods throughout == Russ From internet-drafts@ietf.org Thu Oct 18 10:46:24 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 01D0821F866D; Thu, 18 Oct 2012 10:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rUj6DHewVoi; Thu, 18 Oct 2012 10:46:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4AA21F86C3; Thu, 18 Oct 2012 10:46:23 -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.34 Message-ID: <20121018174623.5805.52615.idtracker@ietfa.amsl.com> Date: Thu, 18 Oct 2012 10:46:23 -0700 Cc: karp@ietf.org Subject: [karp] I-D Action: draft-ietf-karp-routing-tcp-analysis-05.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, 18 Oct 2012 17:46:24 -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 Pro= tocols Working Group of the IETF. Title : Analysis of BGP, LDP, PCEP and MSDP Issues According to = KARP Design Guide Author(s) : Mahesh Jethanandani Keyur Patel Lianshu Zheng Filename : draft-ietf-karp-routing-tcp-analysis-05.txt Pages : 18 Date : 2012-10-18 Abstract: This document analyzes Border Gateway Protocol (BGP) [RFC4271], Label Distribution Protocol (LDP) [RFC5036], Path Computation Element Protocol (PCEP) [RFC5440] and Multicast Source Distribution Protocol (MSDP) [RFC3618] according to guidelines set forth in section 4.2 of Keying and Authentication for Routing Protocols Design Guidelines [RFC6518]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-karp-routing-tcp-analysis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-karp-routing-tcp-analysis-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-karp-routing-tcp-analysis-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bew@cisco.com Mon Oct 22 13:52:21 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 960C41F0C49 for ; Mon, 22 Oct 2012 13:52:21 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ki+lRX9to2y for ; Mon, 22 Oct 2012 13:52:21 -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 1890B1F041C for ; Mon, 22 Oct 2012 13:52:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=391; q=dns/txt; s=iport; t=1350939141; x=1352148741; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=/oKYVlAKWTDqtkpV0/6KmLO2BvD52nCqlEFSmtACbRQ=; b=Vylq9cRSkp28nxkQrojdB0/46ZcMT4Ff6om7WTXXBLaf6Ruu9ohinV2A doN7fUAMiSH3ao95mRkhXNNt5upWNbU61OmOqFUlu4nIfaGpA+ToSyGFH 59DqSFxBLzTJ1idYkvLMrwFaT9tiAAzGt//Xrnv/phfvTrsjSpc/lR3VG M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFABuxhVCrRDoI/2dsb2JhbABFhU27YoEIgjkBCh2CECKHYQGaeYEroBePK4JDYAOIWo0Xjk6Ba4MPgUM X-IronPort-AV: E=Sophos;i="4.80,631,1344211200"; d="scan'208";a="59439388" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 22 Oct 2012 20:52:19 +0000 Received: from dhcp-128-107-151-34.cisco.com (dhcp-128-107-151-34.cisco.com [128.107.151.34]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9MKqJH2005812 for ; Mon, 22 Oct 2012 20:52:19 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Oct 2012 13:52:27 -0700 Message-Id: To: karp@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [karp] Call for IETF 84 agenda items (KARP) 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, 22 Oct 2012 20:52:21 -0000 The KARP WG will be meeting 9AM Monday morning in Atlanta. If you have a = topic for the meeting please email the chairs = (karp-chairs@tools.ietf.org). Since this is the first meeting slot of = the week, be prepared to provide your slides to the chairs no later than = Friday afternoon of the prior week so that they can make the agenda = available earlier. Thanks, Brian & Joel= From internet-drafts@ietf.org Mon Oct 22 15:50:44 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 8B64F1F0C5C; Mon, 22 Oct 2012 15:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fp6EeBOE0mm; Mon, 22 Oct 2012 15:50:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F9D21F847C; Mon, 22 Oct 2012 15:50:43 -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.34 Message-ID: <20121022225043.25241.45532.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 15:50:43 -0700 Cc: karp@ietf.org Subject: [karp] I-D Action: draft-ietf-karp-crypto-key-table-04.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: Mon, 22 Oct 2012 22:50:44 -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 Pro= tocols Working Group of the IETF. Title : Database of Long-Lived Symmetric Cryptographic Keys Author(s) : Russell Housley Tim Polk Sam Hartman Dacheng Zhang Filename : draft-ietf-karp-crypto-key-table-04.txt Pages : 12 Date : 2012-10-22 Abstract: This document specifies the information contained in a conceptual database of long-lived cryptographic keys used by many different security protocols. The database is designed to support both manual and automated key management. In addition to describing the schema for the database, this document describes the operations that can be performed on the database as well as the requirements for the security protocols that wish to use the database. In many typical scenarios, the security protocols do not directly use the long-lived key, but rather a key derivation function is used to derive a short- lived key from a long-lived key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-karp-crypto-key-table There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-karp-crypto-key-table-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-karp-crypto-key-table-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 22 15:52:16 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 CFBD211E810B; Mon, 22 Oct 2012 15:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWE8EqX7QCLP; Mon, 22 Oct 2012 15:52:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FEB11E8104; Mon, 22 Oct 2012 15:52:14 -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.34 Message-ID: <20121022225214.28411.34418.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 15:52:14 -0700 Cc: karp@ietf.org Subject: [karp] I-D Action: draft-ietf-karp-ops-model-04.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: Mon, 22 Oct 2012 22:52:16 -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 Pro= tocols Working Group of the IETF. Title : Operations Model for Router Keying Author(s) : Sam Hartman Dacheng Zhang Filename : draft-ietf-karp-ops-model-04.txt Pages : 23 Date : 2012-10-22 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-karp-ops-model There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-karp-ops-model-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-karp-ops-model-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Mon Oct 22 15:56:13 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 9FF0E11E80DF; Mon, 22 Oct 2012 15:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiA7ynwGTlM5; Mon, 22 Oct 2012 15:56:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112BF11E80FC; Mon, 22 Oct 2012 15:56:13 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022225613.7257.74928.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 15:56:13 -0700 Cc: karp@ietf.org Subject: [karp] Last Call: (Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design Guide) to Informational RFC X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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, 22 Oct 2012 22:56:13 -0000 The IESG has received a request from the Keying and Authentication for Routing Protocols WG (karp) to consider the following document: - 'Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design Guide' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-11-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document analyzes Border Gateway Protocol (BGP) [RFC4271], Label Distribution Protocol (LDP) [RFC5036], Path Computation Element Protocol (PCEP) [RFC5440] and Multicast Source Distribution Protocol (MSDP) [RFC3618] according to guidelines set forth in section 4.2 of Keying and Authentication for Routing Protocols Design Guidelines [RFC6518]. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-karp-routing-tcp-analysis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-karp-routing-tcp-analysis/ballot/ No IPR declarations have been submitted directly on this I-D. From uma.chunduri@ericsson.com Mon Oct 22 17:08:28 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 8E7B01F0429 for ; Mon, 22 Oct 2012 17:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-6p-4jV0r4A for ; Mon, 22 Oct 2012 17:08:28 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id D817321F89D4 for ; Mon, 22 Oct 2012 17:08:27 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q9N08Q42028375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Oct 2012 19:08:27 -0500 Received: from EUSAAHC005.ericsson.se (147.117.188.87) by eusaamw0711.eamcs.ericsson.se (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 22 Oct 2012 20:08:26 -0400 Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 20:08:25 -0400 From: Uma Chunduri To: "karp@ietf.org" Thread-Topic: [karp] I-D Action: draft-ietf-karp-crypto-key-table-04.txt Thread-Index: AQHNsKfEDHS8NN8Q9UOhREQbxLpkv5fF/fmg Date: Tue, 23 Oct 2012 00:08:25 +0000 Message-ID: <1B502206DFA0C544B7A6046915200863011C81@EUSAAMB105.ericsson.se> References: <20121022225043.25241.45532.idtracker@ietfa.amsl.com> In-Reply-To: <20121022225043.25241.45532.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [karp] I-D Action: draft-ietf-karp-crypto-key-table-04.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: Tue, 23 Oct 2012 00:08:28 -0000 Dear Authors, I looked at the latest version of this draft. Most of my comments have been= addressed except the 4 fields to represent the key life time (and separate tables for group and = pair wise keys). SendNotBefore, SendNotAfter, RcvNotBefore, RcvNotAfter We discussed on this and there was a discussion on simplified operations an= d use 2 key life times too (but no conclusion) http://www.ietf.org/mail-archive/web/karp/current/msg00934.html For pair wise keys as rekey is a local decision at both ends (any of the pe= er can initiate) and KMP doesn't negotiate lifetimes, IMO, we should have operationally simplified version of the key life time. Q: If these are applicable to all protocols, how these 4 life times should tra= nslate input user parameters?=20 I am not sure this simplifies operations any way and should be defined sepa= rately for Group keys and pair-wise keys. =20 Rest of the document looks good. --=20 Uma C.=20 -----Original Message----- From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Monday, October 22, 2012 3:51 PM To: i-d-announce@ietf.org Cc: karp@ietf.org Subject: [karp] I-D Action: draft-ietf-karp-crypto-key-table-04.txt 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 Pro= tocols Working Group of the IETF. Title : Database of Long-Lived Symmetric Cryptographic Keys Author(s) : Russell Housley Tim Polk Sam Hartman Dacheng Zhang Filename : draft-ietf-karp-crypto-key-table-04.txt Pages : 12 Date : 2012-10-22 Abstract: This document specifies the information contained in a conceptual database of long-lived cryptographic keys used by many different security protocols. The database is designed to support both manual and automated key management. In addition to describing the schema for the database, this document describes the operations that can be performed on the database as well as the requirements for the security protocols that wish to use the database. In many typical scenarios, the security protocols do not directly use the long-lived key, but rather a key derivation function is used to derive a short- lived key from a long-lived key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-karp-crypto-key-table There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-karp-crypto-key-table-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-karp-crypto-key-table-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ karp mailing list karp@ietf.org https://www.ietf.org/mailman/listinfo/karp From housley@vigilsec.com Mon Oct 22 17:14:27 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 D135721F84C9 for ; Mon, 22 Oct 2012 17:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.614 X-Spam-Level: X-Spam-Status: No, score=-102.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2asuNbzYLPqj for ; Mon, 22 Oct 2012 17:14:27 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 518B321F8482 for ; Mon, 22 Oct 2012 17:14:27 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 691F09A4001; Mon, 22 Oct 2012 20:14:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id O05on2JNwpbg; Mon, 22 Oct 2012 20:14:26 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-37-162.washdc.fios.verizon.net [96.255.37.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id B538F9A4002; Mon, 22 Oct 2012 20:14:26 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <1B502206DFA0C544B7A6046915200863011C81@EUSAAMB105.ericsson.se> Date: Mon, 22 Oct 2012 20:14:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4C84D429-416F-4A63-9C83-DA16EF243026@vigilsec.com> References: <20121022225043.25241.45532.idtracker@ietfa.amsl.com> <1B502206DFA0C544B7A6046915200863011C81@EUSAAMB105.ericsson.se> To: Uma Chunduri X-Mailer: Apple Mail (2.1085) Cc: "karp@ietf.org" Subject: Re: [karp] I-D Action: draft-ietf-karp-crypto-key-table-04.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: Tue, 23 Oct 2012 00:14:28 -0000 Uma: I'd like to discuss one of your comments. =20 > I am not sure this simplifies operations any way and should be defined = separately for Group keys and pair-wise keys. I have worked through the use of pairwise keys (used in just one = direction or both directions) as well as multicast keys. The current = table supports all of these cases. I do not understand why you want = two separate tables. Clearly, you are thinking about this differently = than I am. Can you explain how two tables will make implementation = easier? Russ From uma.chunduri@ericsson.com Mon Oct 22 17:15:30 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 E6F9D21F84C9 for ; Mon, 22 Oct 2012 17:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DhhV9A8z6XB for ; Mon, 22 Oct 2012 17:15:30 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5D74721F8482 for ; Mon, 22 Oct 2012 17:15:30 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q9N0FSVQ028732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Oct 2012 19:15:28 -0500 Received: from EUSAAHC005.ericsson.se (147.117.188.87) by eusaamw0711.eamcs.ericsson.se (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 22 Oct 2012 20:15:27 -0400 Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 20:15:27 -0400 From: Uma Chunduri To: "karp@ietf.org" Thread-Topic: New Version Notification for draft-chunduri-karp-is-is-gap-analysis-03.txt Thread-Index: AQHNsI/ZqwZkt8rEJkSchWilmnHt95fGBHzw Date: Tue, 23 Oct 2012 00:15:26 +0000 Message-ID: <1B502206DFA0C544B7A6046915200863011CA5@EUSAAMB105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Les Ginsberg \(ginsberg\)" Subject: [karp] FW: New Version Notification for draft-chunduri-karp-is-is-gap-analysis-03.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: Tue, 23 Oct 2012 00:15:31 -0000 Dear KARP WG, This version addresses the comments from Sean Turner and Les Ginsberg: - Sean's comments on analysis of https://datatracker.ietf.org/doc/dr= aft-ietf-isis-mi/?include_text=3D1 draft (we tried our best here!) - Les's comments on lack of description of current IS-IS recovery me= chanisms for inter session replay attack for LSPs Your comments are welcome. --=20 Uma C.=20 -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, October 22, 2012 1:00 PM To: Uma Chunduri Cc: Albert Tian; Wenhu Lu Subject: New Version Notification for draft-chunduri-karp-is-is-gap-analysi= s-03.txt A new version of I-D, draft-chunduri-karp-is-is-gap-analysis-03.txt has been successfully submitted by Uma Chunduri and posted to the IETF repo= sitory. Filename: draft-chunduri-karp-is-is-gap-analysis Revision: 03 Title: KARP IS-IS security gap analysis Creation date: 2012-10-22 WG ID: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-chunduri-karp-is= -is-gap-analysis-03.txt Status: http://datatracker.ietf.org/doc/draft-chunduri-karp-is-is-= gap-analysis Htmlized: http://tools.ietf.org/html/draft-chunduri-karp-is-is-gap-a= nalysis-03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-chunduri-karp-is-= is-gap-analysis-03 Abstract: This document analyzes the threats applicable for Intermediate system to Intermediate system (IS-IS) routing protocol and security gaps according to the KARP Design Guide. This document also provides specific requirements to address the gaps with both manual and auto key management protocols. = =20 The IETF Secretariat From uma.chunduri@ericsson.com Mon Oct 22 17:46: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 DE0301F0429 for ; Mon, 22 Oct 2012 17:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oj2xo3sDxqfz for ; Mon, 22 Oct 2012 17:46:47 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6372E21F8906 for ; Mon, 22 Oct 2012 17:46:47 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q9N0kk6U029962 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Oct 2012 19:46:46 -0500 Received: from EUSAAHC003.ericsson.se (147.117.188.81) by eusaamw0712.eamcs.ericsson.se (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 22 Oct 2012 20:46:45 -0400 Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 20:46:45 -0400 From: Uma Chunduri To: Russ Housley Thread-Topic: [karp] I-D Action: draft-ietf-karp-crypto-key-table-04.txt Thread-Index: AQHNsKfEDHS8NN8Q9UOhREQbxLpkv5fF/fmggABKfYD//77RwA== Date: Tue, 23 Oct 2012 00:46:45 +0000 Message-ID: <1B502206DFA0C544B7A6046915200863011CD1@EUSAAMB105.ericsson.se> References: <20121022225043.25241.45532.idtracker@ietfa.amsl.com> <1B502206DFA0C544B7A6046915200863011C81@EUSAAMB105.ericsson.se> <4C84D429-416F-4A63-9C83-DA16EF243026@vigilsec.com> In-Reply-To: <4C84D429-416F-4A63-9C83-DA16EF243026@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "karp@ietf.org" Subject: Re: [karp] I-D Action: draft-ietf-karp-crypto-key-table-04.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: Tue, 23 Oct 2012 00:46:48 -0000 Hello Russ,=20 >>>>> I have worked through the use of pairwise keys (used in just one dir= ection or both directions) >>>>> as well as multicast keys. The current table supports all of these = cases. I do not understand >>>>> why you want two separate tables. Clearly, you are thinking about t= his differently than I am. =20 >>>>> Can you explain how two tables will make implementation easier? [Uma]: Let's focus on only from the key life time perspective. Some IGPs d= o require life times in the=20 specified format to make key transition easier. But, I don't see h= ow to fit these 4 parameters for pair wise keys. For e.g. for TCP based pair-wise keys, when new= master key is negotiated by=20 KMP, TCP-AO makes coordinated key transition with the peer. Not at = all based on the key table=20 time entries specified. In that sense the entries defined today use= ful and enable protocols=20 e.g., group-key RPs, who don't have a defined way of key transition= and more over do security=20 by themselves (make sense there). Now, I stepped back to think on how to use for pair-wise protocols = and not able to connect the=20 dots here. Do you see these are operator inputs or KMP negotiated a= nd how one would use these entries? =20 =20 --=20 Uma C.=20 From mjethanandani@gmail.com Mon Oct 22 17:53:34 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 090821F0C5F for ; Mon, 22 Oct 2012 17:53:34 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7hmHyItukge for ; Mon, 22 Oct 2012 17:53:27 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D3F851F0C51 for ; Mon, 22 Oct 2012 17:53:26 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3987128vcb.31 for ; Mon, 22 Oct 2012 17:53:25 -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=TllP8XDWQroWi3chMH0Vsenu6O7cMBNps6LDX9Nwpoo=; b=04WK+pkE0rSnhG0/sJFpnaoszRjn6CoK1hT0oAxmM5d8117gXHV8pFjd32qAsnaFos D+V2I5/xJd5PfPH4Gw+4qWv2qsUeJwzlL55mf2LoIvhkZ6ExycDR/Y2Hmju0P/wDOQte pP2/wBoExT5BEF+2q9oDzhfS4c+fD8j1m5g3mXOdp/TQqjFzvn1vXg+kPM7O2ijuN4H7 DP90HMA+yrAxhX3Z8nnnAskhIUHMiYQAQadWOnO9e+QawRrSj5A/2zneg3BwnR5XA4lc rHhWAlC/Xh9aqN2vefXDzaB8TX0gEuUwTXEWBTfUGIl5bzXD5IUjzLMRFxEjY/S8l9FI 9xVw== Received: by 10.52.30.167 with SMTP id t7mr14507992vdh.56.1350953605007; Mon, 22 Oct 2012 17:53:25 -0700 (PDT) Received: from txw-scook-01.ciena.com (c-24-6-180-144.hsd1.ca.comcast.net. [24.6.180.144]) by mx.google.com with ESMTPS id o13sm11706411vde.21.2012.10.22.17.53.23 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Oct 2012 17:53:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-32--1015754726 From: Mahesh Jethanandani In-Reply-To: Date: Mon, 22 Oct 2012 17:53:19 -0700 Message-Id: <65FC6345-CDEB-4DC3-8490-2DBAE94E7493@gmail.com> References: To: Brian Weis X-Mailer: Apple Mail (2.1085) Cc: karp@ietf.org Subject: Re: [karp] Call for IETF 84 agenda items (KARP) 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: Tue, 23 Oct 2012 00:53:35 -0000 --Apple-Mail-32--1015754726 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Request a 10 min. slot to talk about BFD Analysis draft. On Oct 22, 2012, at 1:52 PM, Brian Weis wrote: > The KARP WG will be meeting 9AM Monday morning in Atlanta. If you have = a topic for the meeting please email the chairs = (karp-chairs@tools.ietf.org). Since this is the first meeting slot of = the week, be prepared to provide your slides to the chairs no later than = Friday afternoon of the prior week so that they can make the agenda = available earlier. >=20 > Thanks, > Brian & Joel > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail-32--1015754726 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Request a 10 min. slot to talk about BFD Analysis draft.

On Oct 22, 2012, at 1:52 PM, Brian Weis wrote:

The KARP WG will be meeting 9AM Monday morning in Atlanta. If you have a topic for the meeting please email the chairs (karp-chairs@tools.ietf.org). Since this is the first meeting slot of the week, be prepared to provide your slides to the chairs no later than Friday afternoon of the prior week so that they can make the agenda available earlier.

Thanks,
Brian & Joel
_______________________________________________
karp mailing list
karp@ietf.org
https://www.ietf.org/mailman/listinfo/karp

Mahesh Jethanandani



--Apple-Mail-32--1015754726-- From housley@vigilsec.com Tue Oct 23 15:32:53 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 B6DC81F0C8E for ; Tue, 23 Oct 2012 15:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlNp3pysXgxd for ; Tue, 23 Oct 2012 15:32:53 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id A9F8B1F0C3A for ; Tue, 23 Oct 2012 15:32:46 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id E82959A4003; Tue, 23 Oct 2012 18:32:52 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id YkILKdCMSY7K; Tue, 23 Oct 2012 18:32:44 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-37-162.washdc.fios.verizon.net [96.255.37.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 314BF9A4001; Tue, 23 Oct 2012 18:32:51 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <1B502206DFA0C544B7A6046915200863011CD1@EUSAAMB105.ericsson.se> Date: Tue, 23 Oct 2012 18:32:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0A63E924-E20D-4C94-89C2-508724EC975A@vigilsec.com> References: <20121022225043.25241.45532.idtracker@ietfa.amsl.com> <1B502206DFA0C544B7A6046915200863011C81@EUSAAMB105.ericsson.se> <4C84D429-416F-4A63-9C83-DA16EF243026@vigilsec.com> <1B502206DFA0C544B7A6046915200863011CD1@EUSAAMB105.ericsson.se> To: Uma Chunduri X-Mailer: Apple Mail (2.1085) Cc: "karp@ietf.org" Subject: Re: [karp] I-D Action: draft-ietf-karp-crypto-key-table-04.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: Tue, 23 Oct 2012 22:32:53 -0000 Uma: >>>>>> I have worked through the use of pairwise keys (used in just one = direction or both directions) >>>>>> as well as multicast keys. The current table supports all of = these cases. I do not understand >>>>>> why you want two separate tables. Clearly, you are thinking = about this differently than I am. =20 >>>>>> Can you explain how two tables will make implementation easier? >=20 > [Uma]: Let's focus on only from the key life time perspective. Some = IGPs do require life times in the=20 > specified format to make key transition easier. But, I don't = see how to fit these 4 parameters > for pair wise keys. For e.g. for TCP based pair-wise keys, when = new master key is negotiated by=20 > KMP, TCP-AO makes coordinated key transition with the peer. Not = at all based on the key table=20 > time entries specified. In that sense the entries defined today = useful and enable protocols=20 > e.g., group-key RPs, who don't have a defined way of key = transition and more over do security=20 > by themselves (make sense there). >=20 > Now, I stepped back to think on how to use for pair-wise = protocols and not able to connect the=20 > dots here. Do you see these are operator inputs or KMP = negotiated and how one would use these entries? You will note that earlier drafts only had notBefore and notAfter. The = additional one were added because some IGPs need them. I see no way to move forward and address both comments. Russ= From bew@cisco.com Thu Oct 25 16:24:54 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 983D421F8522 for ; Thu, 25 Oct 2012 16:24:54 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzAp7DU2Jv56 for ; Thu, 25 Oct 2012 16:24:54 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0094821F84F2 for ; Thu, 25 Oct 2012 16:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2267; q=dns/txt; s=iport; t=1351207493; x=1352417093; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=oaGNQ44aYEvU2YJWIULT/sJ86GT7TN5DbY8VGOwdfQA=; b=Lx2BbRqtAghVrBXCsjJcmUQrhSgCa74azaKCNARRZWy9Y3I7FquSTsp5 U6fU8S0156jCV7cICfpH5gSpCl9/UDDrQ5UUFAXpadjtSL4izi2slKzDV XHVE6O6TfuvsBn1b6xJi/4lI6v2tkYOTPa1TA4eHvH2OKnH09Q2pzoF5T g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANjIiVCrRDoI/2dsb2JhbABBA8I5gQiCHgEBAQMBAQEBDwEnNAsFCwtGJzAGExkJh1wFDJ1soBoEi2GDRIJIYQOIXI0ajlKBa4MPgUQX X-IronPort-AV: E=Sophos;i="4.80,650,1344211200"; d="scan'208";a="59197343" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 25 Oct 2012 23:24:53 +0000 Received: from stealth-10-32-244-214.cisco.com (stealth-10-32-244-214.cisco.com [10.32.244.214]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9PNOrk9032338; Thu, 25 Oct 2012 23:24:53 GMT Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: <0A63E924-E20D-4C94-89C2-508724EC975A@vigilsec.com> Date: Thu, 25 Oct 2012 16:24:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <380B8A70-0910-43B6-980A-8CCAD8731DDC@cisco.com> References: <20121022225043.25241.45532.idtracker@ietfa.amsl.com> <1B502206DFA0C544B7A6046915200863011C81@EUSAAMB105.ericsson.se> <4C84D429-416F-4A63-9C83-DA16EF243026@vigilsec.com> <1B502206DFA0C544B7A6046915200863011CD1@EUSAAMB105.ericsson.se> <0A63E924-E20D-4C94-89C2-508724EC975A@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.1283) Cc: "karp@ietf.org" Subject: Re: [karp] I-D Action: draft-ietf-karp-crypto-key-table-04.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, 25 Oct 2012 23:24:54 -0000 Hi Russ, On Oct 23, 2012, at 3:32 PM, Russ Housley wrote: > Uma: >=20 >>>>>>> I have worked through the use of pairwise keys (used in just one = direction or both directions) >>>>>>> as well as multicast keys. The current table supports all of = these cases. I do not understand >>>>>>> why you want two separate tables. Clearly, you are thinking = about this differently than I am. =20 >>>>>>> Can you explain how two tables will make implementation easier? >>=20 >> [Uma]: Let's focus on only from the key life time perspective. Some = IGPs do require life times in the=20 >> specified format to make key transition easier. But, I don't = see how to fit these 4 parameters >> for pair wise keys. For e.g. for TCP based pair-wise keys, when = new master key is negotiated by=20 >> KMP, TCP-AO makes coordinated key transition with the peer. Not = at all based on the key table=20 >> time entries specified. In that sense the entries defined today = useful and enable protocols=20 >> e.g., group-key RPs, who don't have a defined way of key = transition and more over do security=20 >> by themselves (make sense there). >>=20 >> Now, I stepped back to think on how to use for pair-wise = protocols and not able to connect the=20 >> dots here. Do you see these are operator inputs or KMP = negotiated and how one would use these entries? >=20 > You will note that earlier drafts only had notBefore and notAfter. = The additional one were added because some IGPs need them. >=20 > I see no way to move forward and address both comments. The draft appears to be silent as to whether fields in the key table are = required, but my belief is that not all fields are required to be used = for all keys. As such, if a KMP for TCP-AO adds a row to the key table, = and some fields in that row are not required, then it simply does not = need to specify their use. Is that not correct? Thanks, Brian > Russ > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp --=20 Brian Weis Security Standards and Technology, SRG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From jmh@joelhalpern.com Thu Oct 25 17:23:21 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 F140621F8608 for ; Thu, 25 Oct 2012 17:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.16 X-Spam-Level: X-Spam-Status: No, score=-102.16 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egHHvfqOjF+r for ; Thu, 25 Oct 2012 17:23:21 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8E58321F848A for ; Thu, 25 Oct 2012 17:23:21 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id CD5D1559BFF for ; Thu, 25 Oct 2012 17:23:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id ABB281C08E7; Thu, 25 Oct 2012 17:23:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-71-161-51-221.clppva.btas.verizon.net [71.161.51.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id D8FC31C0851; Thu, 25 Oct 2012 17:23:18 -0700 (PDT) Message-ID: <5089D7F0.4030806@joelhalpern.com> Date: Thu, 25 Oct 2012 20:23:12 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Brian Weis References: <20121022225043.25241.45532.idtracker@ietfa.amsl.com> <1B502206DFA0C544B7A6046915200863011C81@EUSAAMB105.ericsson.se> <4C84D429-416F-4A63-9C83-DA16EF243026@vigilsec.com> <1B502206DFA0C544B7A6046915200863011CD1@EUSAAMB105.ericsson.se> <0A63E924-E20D-4C94-89C2-508724EC975A@vigilsec.com> <380B8A70-0910-43B6-980A-8CCAD8731DDC@cisco.com> In-Reply-To: <380B8A70-0910-43B6-980A-8CCAD8731DDC@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "karp@ietf.org" Subject: Re: [karp] I-D Action: draft-ietf-karp-crypto-key-table-04.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: Fri, 26 Oct 2012 00:23:22 -0000 Should we be clearer somewhere that inapplicable fields may be omitted? (it is a conceptual table, I think we can allow conceptually optional elements.) Yours, Joel On 10/25/2012 7:24 PM, Brian Weis wrote: > Hi Russ, > > On Oct 23, 2012, at 3:32 PM, Russ Housley wrote: > >> Uma: >> >>>>>>>> I have worked through the use of pairwise keys (used in just one direction or both directions) >>>>>>>> as well as multicast keys. The current table supports all of these cases. I do not understand >>>>>>>> why you want two separate tables. Clearly, you are thinking about this differently than I am. >>>>>>>> Can you explain how two tables will make implementation easier? >>> >>> [Uma]: Let's focus on only from the key life time perspective. Some IGPs do require life times in the >>> specified format to make key transition easier. But, I don't see how to fit these 4 parameters >>> for pair wise keys. For e.g. for TCP based pair-wise keys, when new master key is negotiated by >>> KMP, TCP-AO makes coordinated key transition with the peer. Not at all based on the key table >>> time entries specified. In that sense the entries defined today useful and enable protocols >>> e.g., group-key RPs, who don't have a defined way of key transition and more over do security >>> by themselves (make sense there). >>> >>> Now, I stepped back to think on how to use for pair-wise protocols and not able to connect the >>> dots here. Do you see these are operator inputs or KMP negotiated and how one would use these entries? >> >> You will note that earlier drafts only had notBefore and notAfter. The additional one were added because some IGPs need them. >> >> I see no way to move forward and address both comments. > > The draft appears to be silent as to whether fields in the key table are required, but my belief is that not all fields are required to be used for all keys. As such, if a KMP for TCP-AO adds a row to the key table, and some fields in that row are not required, then it simply does not need to specify their use. Is that not correct? > > Thanks, > Brian > >> Russ >> _______________________________________________ >> karp mailing list >> karp@ietf.org >> https://www.ietf.org/mailman/listinfo/karp > > From housley@vigilsec.com Fri Oct 26 12:29: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 6A62D21F8632 for ; Fri, 26 Oct 2012 12:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lyLSrNvoztP for ; Fri, 26 Oct 2012 12:29:54 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id C926421F862B for ; Fri, 26 Oct 2012 12:29:54 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 0D1A69A4005; Fri, 26 Oct 2012 15:30:01 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id rWsK9jqgpjG0; Fri, 26 Oct 2012 15:29:50 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-37-162.washdc.fios.verizon.net [96.255.37.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 439CC9A4007; Fri, 26 Oct 2012 15:29:59 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <380B8A70-0910-43B6-980A-8CCAD8731DDC@cisco.com> Date: Fri, 26 Oct 2012 15:29:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <953219CE-9AC8-4C99-A069-9C65BC35B16F@vigilsec.com> References: <20121022225043.25241.45532.idtracker@ietfa.amsl.com> <1B502206DFA0C544B7A6046915200863011C81@EUSAAMB105.ericsson.se> <4C84D429-416F-4A63-9C83-DA16EF243026@vigilsec.com> <1B502206DFA0C544B7A6046915200863011CD1@EUSAAMB105.ericsson.se> <0A63E924-E20D-4C94-89C2-508724EC975A@vigilsec.com> <380B8A70-0910-43B6-980A-8CCAD8731DDC@cisco.com> To: Brian Weis X-Mailer: Apple Mail (2.1085) Cc: "karp@ietf.org" Subject: Re: [karp] I-D Action: draft-ietf-karp-crypto-key-table-04.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: Fri, 26 Oct 2012 19:29:55 -0000 Brian: >>>>>>>> I have worked through the use of pairwise keys (used in just = one direction or both directions) >>>>>>>> as well as multicast keys. The current table supports all of = these cases. I do not understand >>>>>>>> why you want two separate tables. Clearly, you are thinking = about this differently than I am. =20 >>>>>>>> Can you explain how two tables will make implementation easier? >>>=20 >>> [Uma]: Let's focus on only from the key life time perspective. Some = IGPs do require life times in the=20 >>> specified format to make key transition easier. But, I don't = see how to fit these 4 parameters >>> for pair wise keys. For e.g. for TCP based pair-wise keys, when = new master key is negotiated by=20 >>> KMP, TCP-AO makes coordinated key transition with the peer. Not = at all based on the key table=20 >>> time entries specified. In that sense the entries defined today = useful and enable protocols=20 >>> e.g., group-key RPs, who don't have a defined way of key = transition and more over do security=20 >>> by themselves (make sense there). >>>=20 >>> Now, I stepped back to think on how to use for pair-wise = protocols and not able to connect the=20 >>> dots here. Do you see these are operator inputs or KMP = negotiated and how one would use these entries? >>=20 >> You will note that earlier drafts only had notBefore and notAfter. = The additional one were added because some IGPs need them. >>=20 >> I see no way to move forward and address both comments. >=20 > The draft appears to be silent as to whether fields in the key table = are required, but my belief is that not all fields are required to be = used for all keys. As such, if a KMP for TCP-AO adds a row to the key = table, and some fields in that row are not required, then it simply does = not need to specify their use. Is that not correct? One only needs to support the fields needed to accommodate the protocols = that draw from the table. That said, adding additional protocols to a = system may lead to support for other fields if they are not included = from the beginning. Russ From bew@cisco.com Fri Oct 26 14:11:10 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 16EEB21F860A for ; Fri, 26 Oct 2012 14:11:10 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InVQabgwo0Yq for ; Fri, 26 Oct 2012 14:11:09 -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 5BA7821F8607 for ; Fri, 26 Oct 2012 14:11:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2604; q=dns/txt; s=iport; t=1351285869; x=1352495469; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=kAtDao9IWTTSilvVcrxzAxeF9DBDnBmARmKZSQXWLcU=; b=ezjUiMwsyjOhEAUy01bM2rpHZgaG0N4PXNqRUMC/8T3/9WguTkcvgRby Ss1XP4hL5TeKYfVYHxkzsqVqGdsUNm5uksx1v/RGHZw5anU64lgiadtCI /Bm3fbfwiK3Pt6V9tyzVZI1o3Z8q0agAQkSR1G2eShBvcD7E94Qvw+bj7 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMb7ilCrRDoG/2dsb2JhbABBA8JWgQiCHgEBAQMBEgEnPwULC0ZXBhMZCYdeBZxOoAuLcQqDO4JIYQOIWY0ajlOBa4MPgUQX X-IronPort-AV: E=Sophos;i="4.80,656,1344211200"; d="scan'208";a="62325776" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 26 Oct 2012 21:11:08 +0000 Received: from stealth-10-32-244-214.cisco.com (stealth-10-32-244-214.cisco.com [10.32.244.214]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9QLB7aH010728; Fri, 26 Oct 2012 21:11:07 GMT Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: <953219CE-9AC8-4C99-A069-9C65BC35B16F@vigilsec.com> Date: Fri, 26 Oct 2012 14:11:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121022225043.25241.45532.idtracker@ietfa.amsl.com> <1B502206DFA0C544B7A6046915200863011C81@EUSAAMB105.ericsson.se> <4C84D429-416F-4A63-9C83-DA16EF243026@vigilsec.com> <1B502206DFA0C544B7A6046915200863011CD1@EUSAAMB105.ericsson.se> <0A63E924-E20D-4C94-89C2-508724EC975A@vigilsec.com> <380B8A70-0910-43B6-980A-8CCAD8731DDC@cisco.com> <953219CE-9AC8-4C99-A069-9C65BC35B16F@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.1283) Cc: "karp@ietf.org" Subject: Re: [karp] I-D Action: draft-ietf-karp-crypto-key-table-04.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: Fri, 26 Oct 2012 21:11:10 -0000 Hi Russ, On Oct 26, 2012, at 12:29 PM, Russ Housley wrote: > Brian: >=20 >>>>>>>>> I have worked through the use of pairwise keys (used in just = one direction or both directions) >>>>>>>>> as well as multicast keys. The current table supports all of = these cases. I do not understand >>>>>>>>> why you want two separate tables. Clearly, you are thinking = about this differently than I am. =20 >>>>>>>>> Can you explain how two tables will make implementation = easier? >>>>=20 >>>> [Uma]: Let's focus on only from the key life time perspective. = Some IGPs do require life times in the=20 >>>> specified format to make key transition easier. But, I don't = see how to fit these 4 parameters >>>> for pair wise keys. For e.g. for TCP based pair-wise keys, when = new master key is negotiated by=20 >>>> KMP, TCP-AO makes coordinated key transition with the peer. Not = at all based on the key table=20 >>>> time entries specified. In that sense the entries defined today = useful and enable protocols=20 >>>> e.g., group-key RPs, who don't have a defined way of key = transition and more over do security=20 >>>> by themselves (make sense there). >>>>=20 >>>> Now, I stepped back to think on how to use for pair-wise = protocols and not able to connect the=20 >>>> dots here. Do you see these are operator inputs or KMP = negotiated and how one would use these entries? >>>=20 >>> You will note that earlier drafts only had notBefore and notAfter. = The additional one were added because some IGPs need them. >>>=20 >>> I see no way to move forward and address both comments. >>=20 >> The draft appears to be silent as to whether fields in the key table = are required, but my belief is that not all fields are required to be = used for all keys. As such, if a KMP for TCP-AO adds a row to the key = table, and some fields in that row are not required, then it simply does = not need to specify their use. Is that not correct? >=20 > One only needs to support the fields needed to accommodate the = protocols that draw from the table. That said, adding additional = protocols to a system may lead to support for other fields if they are = not included from the beginning. This sounds reasonable to me. But to Joel's point, I think it would be a = good idea to discuss this briefly in the I-D. I believe it would address = Uma's concern. Thanks, Brian =20 >=20 > Russ >=20 --=20 Brian Weis Security Standards and Technology, SRG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From housley@vigilsec.com Fri Oct 26 20:52:44 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 01FA921F86A9 for ; Fri, 26 Oct 2012 20:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcdoA4ssfMtI for ; Fri, 26 Oct 2012 20:52:43 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2F821F8698 for ; Fri, 26 Oct 2012 20:52:43 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 89A9D9A4005; Fri, 26 Oct 2012 23:52:52 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id AFuTsMQGJcMf; Fri, 26 Oct 2012 23:52:41 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-37-162.washdc.fios.verizon.net [96.255.37.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 849319A4001; Fri, 26 Oct 2012 23:52:51 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <5089D7F0.4030806@joelhalpern.com> Date: Fri, 26 Oct 2012 23:52:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5EA64BEF-6900-4555-8C79-C26DA0DF342C@vigilsec.com> References: <20121022225043.25241.45532.idtracker@ietfa.amsl.com> <1B502206DFA0C544B7A6046915200863011C81@EUSAAMB105.ericsson.se> <4C84D429-416F-4A63-9C83-DA16EF243026@vigilsec.com> <1B502206DFA0C544B7A6046915200863011CD1@EUSAAMB105.ericsson.se> <0A63E924-E20D-4C94-89C2-508724EC975A@vigilsec.com> <380B8A70-0910-43B6-980A-8CCAD8731DDC@cisco.com> <5089D7F0.4030806@joelhalpern.com> To: Joel M. Halpern X-Mailer: Apple Mail (2.1085) Cc: "karp@ietf.org" Subject: Re: [karp] I-D Action: draft-ietf-karp-crypto-key-table-04.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: Sat, 27 Oct 2012 03:52:44 -0000 Can we handle this as a WG Last Call comment? On Oct 25, 2012, at 8:23 PM, Joel M. Halpern wrote: > Should we be clearer somewhere that inapplicable fields may be = omitted? (it is a conceptual table, I think we can allow conceptually = optional elements.) > Yours, > Joel >=20 > On 10/25/2012 7:24 PM, Brian Weis wrote: >> Hi Russ, >>=20 >> On Oct 23, 2012, at 3:32 PM, Russ Housley wrote: >>=20 >>> Uma: >>>=20 >>>>>>>>> I have worked through the use of pairwise keys (used in just = one direction or both directions) >>>>>>>>> as well as multicast keys. The current table supports all of = these cases. I do not understand >>>>>>>>> why you want two separate tables. Clearly, you are thinking = about this differently than I am. >>>>>>>>> Can you explain how two tables will make implementation = easier? >>>>=20 >>>> [Uma]: Let's focus on only from the key life time perspective. = Some IGPs do require life times in the >>>> specified format to make key transition easier. But, I don't = see how to fit these 4 parameters >>>> for pair wise keys. For e.g. for TCP based pair-wise keys, = when new master key is negotiated by >>>> KMP, TCP-AO makes coordinated key transition with the peer. = Not at all based on the key table >>>> time entries specified. In that sense the entries defined = today useful and enable protocols >>>> e.g., group-key RPs, who don't have a defined way of key = transition and more over do security >>>> by themselves (make sense there). >>>>=20 >>>> Now, I stepped back to think on how to use for pair-wise = protocols and not able to connect the >>>> dots here. Do you see these are operator inputs or KMP = negotiated and how one would use these entries? >>>=20 >>> You will note that earlier drafts only had notBefore and notAfter. = The additional one were added because some IGPs need them. >>>=20 >>> I see no way to move forward and address both comments. >>=20 >> The draft appears to be silent as to whether fields in the key table = are required, but my belief is that not all fields are required to be = used for all keys. As such, if a KMP for TCP-AO adds a row to the key = table, and some fields in that row are not required, then it simply does = not need to specify their use. Is that not correct? >>=20 >> Thanks, >> Brian >>=20 >>> Russ >>> _______________________________________________ >>> karp mailing list >>> karp@ietf.org >>> https://www.ietf.org/mailman/listinfo/karp >>=20 >>=20 From jmh.direct@joelhalpern.com Fri Oct 26 21:13: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 222D121F86A3 for ; Fri, 26 Oct 2012 21:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.315 X-Spam-Level: X-Spam-Status: No, score=-2.315 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Boxiic-aQAOC for ; Fri, 26 Oct 2012 21:13:11 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id B327421F86AE for ; Fri, 26 Oct 2012 21:13:10 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 34ED8559E25 for ; Fri, 26 Oct 2012 21:13:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id E609518031B; Fri, 26 Oct 2012 21:13:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-71-161-51-221.clppva.btas.verizon.net [71.161.51.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 124571BD901F; Fri, 26 Oct 2012 21:13:06 -0700 (PDT) Message-ID: <508B5F4B.8050304@joelhalpern.com> Date: Sat, 27 Oct 2012 00:12:59 -0400 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Russ Housley References: <20121022225043.25241.45532.idtracker@ietfa.amsl.com> <1B502206DFA0C544B7A6046915200863011C81@EUSAAMB105.ericsson.se> <4C84D429-416F-4A63-9C83-DA16EF243026@vigilsec.com> <1B502206DFA0C544B7A6046915200863011CD1@EUSAAMB105.ericsson.se> <0A63E924-E20D-4C94-89C2-508724EC975A@vigilsec.com> <380B8A70-0910-43B6-980A-8CCAD8731DDC@cisco.com> <5089D7F0.4030806@joelhalpern.com> <5EA64BEF-6900-4555-8C79-C26DA0DF342C@vigilsec.com> In-Reply-To: <5EA64BEF-6900-4555-8C79-C26DA0DF342C@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 26 Oct 2012 21:17:58 -0700 Cc: "karp@ietf.org" Subject: Re: [karp] I-D Action: draft-ietf-karp-crypto-key-table-04.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: Sat, 27 Oct 2012 04:13:12 -0000 I can live with that. Let me make sure I can persuade Uma (whose comment started this) to go along. I expect I can do so Monday. If so, we can start the WG last call then as far as I am concerned. Yours, Joel On 10/26/2012 11:52 PM, Russ Housley wrote: > Can we handle this as a WG Last Call comment? > > > On Oct 25, 2012, at 8:23 PM, Joel M. Halpern wrote: > >> Should we be clearer somewhere that inapplicable fields may be omitted? (it is a conceptual table, I think we can allow conceptually optional elements.) >> Yours, >> Joel >> >> On 10/25/2012 7:24 PM, Brian Weis wrote: >>> Hi Russ, >>> >>> On Oct 23, 2012, at 3:32 PM, Russ Housley wrote: >>> >>>> Uma: >>>> >>>>>>>>>> I have worked through the use of pairwise keys (used in just one direction or both directions) >>>>>>>>>> as well as multicast keys. The current table supports all of these cases. I do not understand >>>>>>>>>> why you want two separate tables. Clearly, you are thinking about this differently than I am. >>>>>>>>>> Can you explain how two tables will make implementation easier? >>>>> >>>>> [Uma]: Let's focus on only from the key life time perspective. Some IGPs do require life times in the >>>>> specified format to make key transition easier. But, I don't see how to fit these 4 parameters >>>>> for pair wise keys. For e.g. for TCP based pair-wise keys, when new master key is negotiated by >>>>> KMP, TCP-AO makes coordinated key transition with the peer. Not at all based on the key table >>>>> time entries specified. In that sense the entries defined today useful and enable protocols >>>>> e.g., group-key RPs, who don't have a defined way of key transition and more over do security >>>>> by themselves (make sense there). >>>>> >>>>> Now, I stepped back to think on how to use for pair-wise protocols and not able to connect the >>>>> dots here. Do you see these are operator inputs or KMP negotiated and how one would use these entries? >>>> >>>> You will note that earlier drafts only had notBefore and notAfter. The additional one were added because some IGPs need them. >>>> >>>> I see no way to move forward and address both comments. >>> >>> The draft appears to be silent as to whether fields in the key table are required, but my belief is that not all fields are required to be used for all keys. As such, if a KMP for TCP-AO adds a row to the key table, and some fields in that row are not required, then it simply does not need to specify their use. Is that not correct? >>> >>> Thanks, >>> Brian >>> >>>> Russ >>>> _______________________________________________ >>>> karp mailing list >>>> karp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/karp >>> >>> > From bew@cisco.com Mon Oct 29 13:31:56 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 D8FAC21F86E5 for ; Mon, 29 Oct 2012 13:31:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7a4VUPBPVhZ for ; Mon, 29 Oct 2012 13:31:56 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 410A021F86E2 for ; Mon, 29 Oct 2012 13:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=397; q=dns/txt; s=iport; t=1351542716; x=1352752316; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=ZwqFNzwnqUpbxYCbhIexiRrKvsdy1fVmJzjZ8+373As=; b=hi6I+As18LT8TQGl1Fu0LYT4FORIpEh3QizjFtQ4g2QgG9B8rh7HabRx 5AbQseCGNSnmXFieTFCbA6H/4FIgxxIg6hMGUBln73GgAkTkHYbvFCt2R PmLk6uwhOocMSWg8GsXEjulyzvIPN1fF+Vlgd0o463yA/kMUIW33nIRc5 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFALjmjlCrRDoJ/2dsb2JhbABEhVG9MYEIgjcBJ4Iyh2MMmkuBLJ97i3WDOYJDYQOIWY0bgRqNPYFrgw+BRA X-IronPort-AV: E=Sophos;i="4.80,673,1344211200"; d="scan'208";a="59511286" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 29 Oct 2012 20:31:56 +0000 Received: from stealth-10-32-244-211.cisco.com (stealth-10-32-244-211.cisco.com [10.32.244.211]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9TKVtlM016303 for ; Mon, 29 Oct 2012 20:31:56 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Oct 2012 13:31:55 -0700 Message-Id: <2F9EF617-2481-4176-B09F-21755093F0B1@cisco.com> To: karp@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [karp] WG LC: draft-ietf-karp-crypto-key-table-04 to Standards Track 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, 29 Oct 2012 20:31:57 -0000 This begins a two week WG last call to determine if folks will support = the chairs to submit to our AD for publication as an Standards Track RFC. Please send comments of support, or raising issues or concerns, to the = WG email list by 5pm PDT on 12-November-2012. Thank you, Joel M. Halpern and Brian Weis co-chairs From jmh@joelhalpern.com Wed Oct 31 20:32:54 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 E73A321F8564; Wed, 31 Oct 2012 20:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VwqVV4nsgct; Wed, 31 Oct 2012 20:32:54 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1852321F8485; Wed, 31 Oct 2012 20:32:54 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 572D155883E; Wed, 31 Oct 2012 20:32:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 3FFD71C5BC2; Wed, 31 Oct 2012 20:32:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-71-161-52-6.clppva.btas.verizon.net [71.161.52.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 523501C5B96; Wed, 31 Oct 2012 20:32:45 -0700 (PDT) Message-ID: <5091ED52.9080705@joelhalpern.com> Date: Wed, 31 Oct 2012 23:32:34 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "lisp@ietf.org" , "karp@ietf.org" References: <20121101031318.29487.88368.idtracker@ietfa.amsl.com> In-Reply-To: <20121101031318.29487.88368.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121101031318.29487.88368.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [karp] Fwd: Help the NomCom: Community Feedback 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, 01 Nov 2012 03:32:55 -0000 Please provide input to help the nomcom. Thank you, Joel -------- Original Message -------- Subject: Help the NomCom: Community Feedback Date: Wed, 31 Oct 2012 20:13:18 -0700 From: NomCom Chair To: Working Group Chairs The IETF Nominations Committee (NomCom) continues to seek input from the IETF Community. The NomCom would greatly appreciate any help you could provide in making members of your working group aware of ways in which they can provide valuable feedback to the NomCom. In order to ensure that your input is received in time to be useful, the NomCom needs to receive community feedback on or before Sunday, November 4. The final list of candidates (as per RFC 5680) that the NomCom is considering for open positions can be found at: https://www.ietf.org/group/nomcom/2012/input/ The NomCom will be holding office hours during IETF 85, Monday- Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes comments on specific individuals, as well as general feedback related to any of the positions that NomCom is considering. Note: A list of leadership positions that the NomCom is considering can be found at: https://www.ietf.org/group/nomcom/2012/ If the NomCom office hours are inconvenient for you or if you cannot attend IETF 85, the NomCom is happy to take community input via email to nomcom12@ietf.org. Additionally, the NomCom is happy to arrange a meeting outside of office hours, just send us email and we can set something up. Comments on specific candidates can also be provided to the NomCom via the web feedback tool: https://www.ietf.org/group/nomcom/2012/input/ Thank you for your help, - Matt Lepinski nomcom-chair@ietf.org