From kent@bbn.com Wed Nov 2 01:58:09 2011 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 535A011E80F5 for ; Wed, 2 Nov 2011 01:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.431 X-Spam-Level: X-Spam-Status: No, score=-106.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vs9wcFhsqDG0 for ; Wed, 2 Nov 2011 01:58:08 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id C15CA11E80D3 for ; Wed, 2 Nov 2011 01:58:08 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:54302 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RLWe7-0000mE-I8; Wed, 02 Nov 2011 04:58:07 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4E9104B8.30701@joelhalpern.com> References: <4E9104B8.30701@joelhalpern.com> Date: Wed, 2 Nov 2011 04:57:39 -0400 To: "Joel M. Halpern" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "karp@ietf.org" Subject: Re: [karp] Fwd: Re: Russ Housley's Discuss on draft-ietf-karp-design-guide-05: (with DISCUSS and COMMENT) 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, 02 Nov 2011 08:58:09 -0000 At 10:19 PM -0400 10/8/11, Joel M. Halpern wrote: >Russ Housley raised a discuss as to whether the design guidelines >document should address the "common framework" for applying security >to routing protocols that is called for in our charter. > >there are multiple opinions on this. > >Russ asked what the WG's opinion is, which seems an appropriate question. > >So, folks, comments? > >Thank you, >Joel Sorry I missed this when you posted it to the list. I agree that we ought to be addressing the "common framework" as part of the design guidelines. Steve From hartmans@mit.edu Thu Nov 3 14:18:36 2011 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 474101F0CBB for ; Thu, 3 Nov 2011 14:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.021 X-Spam-Level: X-Spam-Status: No, score=-103.021 tagged_above=-999 required=5 tests=[AWL=-0.756, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlXahKlOfz7f for ; Thu, 3 Nov 2011 14:18:35 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5CED41F0CB6 for ; Thu, 3 Nov 2011 14:18:32 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id BB7EA202C9; Thu, 3 Nov 2011 17:19:23 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3FCD6435A; Thu, 3 Nov 2011 17:18:26 -0400 (EDT) From: Sam Hartman To: "Joel M. Halpern" References: <4E9104B8.30701@joelhalpern.com> Date: Thu, 03 Nov 2011 17:18:26 -0400 In-Reply-To: <4E9104B8.30701@joelhalpern.com> (Joel M. Halpern's message of "Sat, 08 Oct 2011 22:19:36 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "karp@ietf.org" Subject: Re: [karp] Fwd: Re: Russ Housley's Discuss on draft-ietf-karp-design-guide-05: (with DISCUSS and COMMENT) 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, 03 Nov 2011 21:18:36 -0000 >>>>> "Joel" == Joel M Halpern writes: Joel> Russ Housley raised a discuss as to whether the design Joel> guidelines document should address the "common framework" for Joel> applying security to routing protocols that is called for in Joel> our charter. Joel> there are multiple opinions on this. Joel> Russ asked what the WG's opinion is, which seems an Joel> appropriate question. Joel> So, folks, comments? I think that the design guide does address common elements that cross routing protocol boundaries. I also believe that the process would not be served by delaying the design guide in order to add significant text about a common approach. If Russ believes this is just an issue of following process and is overall happy with the progress we're making, I'd urge him to consider whether the DISCUSS position is likely to improve the output of the WG or just delay focusing on actually improving routing protocols and getting automated key management. If Russ believes the approach we're considering for the protocols we've actually looked at is somehow flawed, or that we're missing common elements, then perhaps we should give him as much time as he needs to present his concerns in IETF 82 so we can understand them. From hartmans@mit.edu Thu Nov 3 14:22:26 2011 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 84D101F0CCF for ; Thu, 3 Nov 2011 14:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.005 X-Spam-Level: X-Spam-Status: No, score=-103.005 tagged_above=-999 required=5 tests=[AWL=-0.740, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAS4FJ5u+HTs for ; Thu, 3 Nov 2011 14:22:26 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 226BF1F0CC7 for ; Thu, 3 Nov 2011 14:22:26 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id CCF4D202D8; Thu, 3 Nov 2011 17:23:19 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4129B435A; Thu, 3 Nov 2011 17:22:23 -0400 (EDT) From: Sam Hartman To: Russ White References: <4E824E27.2000209@riw.us> Date: Thu, 03 Nov 2011 17:22:23 -0400 In-Reply-To: <4E824E27.2000209@riw.us> (Russ White's message of "Tue, 27 Sep 2011 18:28:55 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: karp@ietf.org Subject: Re: [karp] KARP-KMP for pair wise routing protocols (traffic selectors) 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, 03 Nov 2011 21:22:26 -0000 >>>>> "Russ" == Russ White writes: Russ> For what it's worth, I will agree with Sam here. At some point Russ> in the future you might want to be able to have multiple Russ> sessions running between the same pair of peers, and have them Russ> authenticated separately. Russ, as part of designing a KMP proposal we've tried to come up with a situation where an operator would like to do this. So far we've failed. We can easily come up with reasons to have multiple sessions between two peers. So far though, we've been unable to come up with reasons why you'd want to use different authentication for these two sessions. Can you help us with use cases? From michael_barnes@usa.net Thu Nov 3 17:26:12 2011 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 33E171F0C59 for ; Thu, 3 Nov 2011 17:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZmTEs3tenko for ; Thu, 3 Nov 2011 17:26:11 -0700 (PDT) Received: from cmsout01.mbox.net (cmsout01.mbox.net [165.212.64.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC811F0C3D for ; Thu, 3 Nov 2011 17:26:11 -0700 (PDT) Received: from cmsout01.mbox.net (cmsout01-lo [127.0.0.1]) by cmsout01.mbox.net (Postfix) with ESMTP id 65CD02AC9D1; Fri, 4 Nov 2011 00:26:05 +0000 (GMT) X-USANET-Received: from cmsout01.mbox.net [127.0.0.1] by cmsout01.mbox.net via mtad (C8.MAIN.3.72B) with ESMTP id 348PkDaAc5888M01; Fri, 04 Nov 2011 00:26:02 -0000 X-USANET-Routed: 3 gwsout-vs Q:bmvirus Received: from cmsapps04.cms.usa.net [165.212.11.133] by cmsout01.mbox.net via smtad (C8.MAIN.3.72B) with ESMTP id XID352PkDaAc5201X01; Fri, 04 Nov 2011 00:26:02 -0000 X-USANET-Source: 165.212.11.133 IN michael_barnes@usa.net cmsapps04.cms.usa.net X-USANET-MsgId: XID352PkDaAc5201X01 Received: from web03.cms.usa.net [165.212.8.203] by cmsapps04.cms.usa.net (ESMTP/michael_barnes@usa.net) via mtad (C8.MAIN.3.72B) with ESMTP id 383PkDaAc9568M40; Fri, 04 Nov 2011 00:26:02 -0000 X-USANET-Auth: 165.212.8.203 AUTO michael_barnes@usa.net web03.cms.usa.net Received: from 198.144.206.23 [198.144.206.23] by web03.cms.usa.net (USANET web-mailer C8.MAIN.3.77G); Fri, 04 Nov 2011 00:26:02 -0000 Date: Thu, 03 Nov 2011 17:26:02 -0700 From: "Michael Barnes" To: Sam Hartman , Russ White X-Mailer: USANET web-mailer (C8.MAIN.3.77G) Mime-Version: 1.0 Message-ID: <760PkDaZc8512S03.1320366362@web03.cms.usa.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Z-USANET-MsgId: XID383PkDaAc9568X40 Cc: karp@ietf.org Subject: Re: [karp] KARP-KMP for pair wise routing protocols (traffic selectors) 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, 04 Nov 2011 00:26:12 -0000 ------ Original Message ------ Received: Thu, 03 Nov 2011 02:22:36 PM PDT From: Sam Hartman To: Russ White Cc: karp@ietf.org Subject: Re: [karp] KARP-KMP for pair wise routing protocols (traffic selectors) > >>>>> "Russ" =3D=3D Russ White writes: > = > Russ> For what it's worth, I will agree with Sam here. At some poin= t > Russ> in the future you might want to be able to have multiple > Russ> sessions running between the same pair of peers, and have the= m > Russ> authenticated separately. = > = > = > Russ, as part of designing a KMP proposal we've tried to come up with a= > situation where an operator would like to do this. So far we've failed= =2E > We can easily come up with reasons to have multiple sessions between tw= o > peers. So far though, we've been unable to come up with reasons why > you'd want to use different authentication for these two sessions. > Can you help us with use cases? How about in a public data center? You may have separate control plane instances with different admins, needing independent security, but runnin= g on the same wire. -M From hartmans@mit.edu Sat Nov 5 17:27:38 2011 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 689F911E8080 for ; Sat, 5 Nov 2011 17:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.989 X-Spam-Level: X-Spam-Status: No, score=-102.989 tagged_above=-999 required=5 tests=[AWL=-0.724, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aPo-8iz86jW for ; Sat, 5 Nov 2011 17:27:38 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 062EB11E807F for ; Sat, 5 Nov 2011 17:27:36 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 594CF20179; Sat, 5 Nov 2011 20:28:15 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9AE72435A; Sat, 5 Nov 2011 20:27:16 -0400 (EDT) From: Sam Hartman To: "Michael Barnes" References: <760PkDaZc8512S03.1320366362@web03.cms.usa.net> Date: Sat, 05 Nov 2011 20:27:16 -0400 In-Reply-To: <760PkDaZc8512S03.1320366362@web03.cms.usa.net> (Michael Barnes's message of "Thu, 03 Nov 2011 17:26:02 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , karp@ietf.org Subject: Re: [karp] KARP-KMP for pair wise routing protocols (traffic selectors) 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, 06 Nov 2011 00:27:38 -0000 >>>>> "Michael" == Michael Barnes writes: Michael> How about in a public data center? You may have separate Michael> control plane instances with different admins, needing Michael> independent security, but running on the same wire. More detail would be appreciated on this. From manav.bhatia@alcatel-lucent.com Sat Nov 5 18:49:28 2011 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 4351121F84E5 for ; Sat, 5 Nov 2011 18:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.732 X-Spam-Level: X-Spam-Status: No, score=-6.732 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgUBAaiGMiom for ; Sat, 5 Nov 2011 18:49:27 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id B4A5621F84DF for ; Sat, 5 Nov 2011 18:49:27 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id pA61nMRL014592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 Nov 2011 20:49:25 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pA61nK1N018416 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 6 Nov 2011 07:19:21 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Sun, 6 Nov 2011 07:19:20 +0530 From: "Bhatia, Manav (Manav)" To: Sam Hartman , Russ White Date: Sun, 6 Nov 2011 07:18:45 +0530 Thread-Topic: [karp] KARP-KMP for pair wise routing protocols (traffic selectors) Thread-Index: AcyabrL2/pwuNSLTSH6rbcryYmu9AwBtBHqQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350D00FD5918@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4E824E27.2000209@riw.us> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "karp@ietf.org" Subject: Re: [karp] KARP-KMP for pair wise routing protocols (traffic selectors) 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, 06 Nov 2011 01:49:28 -0000 Hi Sam, I'm thinking aloud here. Consider the following topology: S1a -- B -- C -- S2a | | S2b S1b S1a and S1b are two routers belonging to the same site S1, and S2a and S2b = are two routers belonging to a different site S2.=20 B and C are backbone routers running multiple routing instances (ISIS, for = example) to connect sites S1 and S2. The idea is to use multiple instances = of ISIS to segregate traffic within a large network. Routes from instance S= 1 are not placed in the instance S2. In this case we will have two ISIS routing instances running between B and = C (actually 3, as there will be a default instance also running). Given that S1 and S2 are two different administrative domains there is noth= ing that precludes them from having different security policies. In which c= ase you could, at least theoretically, have S1 use one auth algo and S2 use= some other. This could also happen if for example, S1b doesn't support a p= articular authentication algo that other routers in the larger network supp= ort. In such a case, the routers in site S1 could fall back to the lowest a= uth algo that all routers in that site support, while routers in the other = sites could use a stronger algorithm. Cheers, Manav > Russ, as part of designing a KMP proposal we've tried to come=20 > up with a situation where an operator would like to do this. =20 > So far we've failed. > We can easily come up with reasons to have multiple sessions=20 > between two peers. So far though, we've been unable to come=20 > up with reasons why you'd want to use different=20 > authentication for these two sessions. > Can you help us with use cases? > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > = From hartmans@mit.edu Sun Nov 6 07:41:58 2011 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 265CF21F84BC for ; Sun, 6 Nov 2011 07:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.974 X-Spam-Level: X-Spam-Status: No, score=-102.974 tagged_above=-999 required=5 tests=[AWL=-0.709, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MArKd0-jRrd2 for ; Sun, 6 Nov 2011 07:41:57 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id A2F0421F84A8 for ; Sun, 6 Nov 2011 07:41:56 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 315FB20274; Sun, 6 Nov 2011 10:42:35 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 07578435A; Sun, 6 Nov 2011 10:41:36 -0500 (EST) From: Sam Hartman To: "Bhatia\, Manav \(Manav\)" References: <4E824E27.2000209@riw.us> <7C362EEF9C7896468B36C9B79200D8350D00FD5918@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Sun, 06 Nov 2011 10:41:35 -0500 In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D00FD5918@INBANSXCHMBSA1.in.alcatel-lucent.com> (Manav Bhatia's message of "Sun, 6 Nov 2011 07:18:45 +0530") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , "karp@ietf.org" Subject: Re: [karp] KARP-KMP for pair wise routing protocols (traffic selectors) 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, 06 Nov 2011 15:41:58 -0000 >>>>> "Bhatia," == Bhatia, Manav (Manav) writes: Bhatia,> Given that S1 and S2 are two different administrative Bhatia,> domains there is nothing that precludes them from having Bhatia,> different security policies. In which case you could, at Bhatia,> least theoretically, have S1 use one auth algo and S2 use Bhatia,> some other. This could also happen if for example, S1b Bhatia,> doesn't support a particular authentication algo that other Bhatia,> routers in the larger network support. In such a case, the Bhatia,> routers in site S1 could fall back to the lowest auth algo Bhatia,> that all routers in that site support, while routers in the Bhatia,> other sites could use a stronger algorithm. That's a good point. Note that the RKMP work we're doing is focusing on unicast associations, so not IS-IS. (Even in point-to-point mode, IS-IS does area-wide or domain-wide keying, so it would need a group security association.) You're absolutely right that two peers can participate in groups with different parameters, and that the name of a group would need to distinguish multiple instances especially for something like IS-IS. We haven't found an example where the same issue comes up in unicast associations. If we change your example to use multiple BGP instances for example, It seems fine for B and C to use the same SA to protect all BGP traffic between B and C given that this affects nothing else in the system and given the KARP threat model. From housley@vigilsec.com Mon Nov 7 05:25:17 2011 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 6C48C21F8B4E for ; Mon, 7 Nov 2011 05:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejdvriuwtmyL for ; Mon, 7 Nov 2011 05:25:13 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 0C71D21F8B4D for ; Mon, 7 Nov 2011 05:25:13 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 95F56F24062; Mon, 7 Nov 2011 08:25:16 -0500 (EST) 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 NNizKRC4sLpI; Mon, 7 Nov 2011 08:25:09 -0500 (EST) Received: from [192.168.43.130] (unknown [198.232.60.42]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 084EDF24061; Mon, 7 Nov 2011 08:25:16 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Mon, 7 Nov 2011 08:25:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E9104B8.30701@joelhalpern.com> To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: karp@ietf.org Subject: Re: [karp] Russ Housley's Discuss on draft-ietf-karp-design-guide-05: (with DISCUSS and COMMENT) 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, 07 Nov 2011 13:25:17 -0000 Sam: > Joel> Russ asked what the WG's opinion is, which seems an > Joel> appropriate question. >=20 > I think that the design guide does address common elements that > cross routing protocol boundaries. > I also believe that the process would not be served by delaying the > design guide in order to add significant text about a common approach. So, this is the part where we disagree. I do not think the current = document does a very good job at documenting common design elements. By = doing so now, the I think the WG will save a lot of time as each routing = protocol is considered. I am asking if others agree. If there is not = support for this position, then I will clear. Russ From hartmans@mit.edu Mon Nov 7 11:16:26 2011 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 A1B0011E80A6 for ; Mon, 7 Nov 2011 11:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.959 X-Spam-Level: X-Spam-Status: No, score=-102.959 tagged_above=-999 required=5 tests=[AWL=-0.694, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbuKZHZ2mpAs for ; Mon, 7 Nov 2011 11:16:26 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4133011E80A3 for ; Mon, 7 Nov 2011 11:16:26 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 478CC2019A; Mon, 7 Nov 2011 14:17:15 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F4212435A; Mon, 7 Nov 2011 14:16:14 -0500 (EST) From: Sam Hartman To: Russ Housley References: <4E9104B8.30701@joelhalpern.com> Date: Mon, 07 Nov 2011 14:16:14 -0500 In-Reply-To: (Russ Housley's message of "Mon, 7 Nov 2011 08:25:08 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , karp@ietf.org Subject: Re: [karp] Russ Housley's Discuss on draft-ietf-karp-design-guide-05: (with DISCUSS and COMMENT) 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, 07 Nov 2011 19:16:26 -0000 >>>>> "Russ" == Russ Housley writes: Russ> So, this is the part where we disagree. I do not think the Russ> current document does a very good job at documenting common Russ> design elements. By doing so now, the I think the WG will Russ> save a lot of time as each routing protocol is considered. I Russ> am asking if others agree. If there is not support for this Russ> position, then I will clear. If you put together some slides talking about the sort of elements you're looking for and we had some discussion about what we think we can do I know I'd be very interested in the presentation and discussion. From bew@cisco.com Mon Nov 7 15:38:38 2011 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 60EE61F0C3E for ; Mon, 7 Nov 2011 15:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUvxkeDGGu2y for ; Mon, 7 Nov 2011 15:38:34 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id D092021F84D3 for ; Mon, 7 Nov 2011 15:38:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=423; q=dns/txt; s=iport; t=1320709114; x=1321918714; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=IwhMEFxh2yLEV1Dl7cOTVVh+T4yz5YMhqm00+6AsKtM=; b=kPwjLxab/Vqu/bTBcRwdMbuSrhj7H42tnx1FsCYhoU3YOX4SXABIqhZh VYorNVUrit2WIe7eIIQfz5vVa2F/Onba2iafXO6qRXcLcK+N4McEU/lII OEt5QbviK20uJYpFdUjeyThifThl0E0B+1po+XZHpC5cEeecQ6wBCTGkq o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0GABNruE6rRDoH/2dsb2JhbABDmk6PJ4EFggsBCh2CECKgP4EmAZ8BiEhjBIgLjBaSDQ X-IronPort-AV: E=Sophos;i="4.69,472,1315180800"; d="scan'208";a="12839500" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 07 Nov 2011 23:38:33 +0000 Received: from dhcp-128-107-105-38.cisco.com (dhcp-128-107-105-38.cisco.com [128.107.105.38]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pA7NcXwG020243 for ; Mon, 7 Nov 2011 23:38:33 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Nov 2011 15:38:34 -0800 Message-Id: <24A64BA2-8C85-4FA3-905B-10ACA765633C@cisco.com> To: karp@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [karp] Call for IETF 82 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, 07 Nov 2011 23:38:38 -0000 Greetings, The KARP WG will be meeting Wednesday afternoon in Taipei. We have a = couple of WG documents to discuss, as well as a few individual = submissions analyzing routing protocols and making suggestions regarding = automated key management. The schedule is pretty tight, but if you have = an additional topic for the meeting please email the chairs = (karp-chairs@tools.ietf.org). Thanks, Brian & Joel= From jmh@joelhalpern.com Tue Nov 8 10:47:46 2011 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 A519E1F0C43 for ; Tue, 8 Nov 2011 10:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.165 X-Spam-Level: X-Spam-Status: No, score=-102.165 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYocE6B9qDjz for ; Tue, 8 Nov 2011 10:47:46 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 513BA1F0C35 for ; Tue, 8 Nov 2011 10:47:46 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 22B79CD068 for ; Tue, 8 Nov 2011 10:47:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id D45D62402FA for ; Tue, 8 Nov 2011 10:47:44 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-48.clppva.btas.verizon.net [71.161.52.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 7BF932402F8 for ; Tue, 8 Nov 2011 10:47:44 -0800 (PST) Message-ID: <4EB9794E.1010800@joelhalpern.com> Date: Tue, 08 Nov 2011 13:47:42 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "karp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [karp] Scribes 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, 08 Nov 2011 18:47:46 -0000 We really need both a minute taker and a jabber scribe for the meeting. Volunteers please? Thank you very much, Joel & Brian From rja.lists@gmail.com Wed Nov 9 16:30:41 2011 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 058EB21F84AC for ; Wed, 9 Nov 2011 16:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5APQfNKqaDU for ; Wed, 9 Nov 2011 16:30:40 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB14621F84AB for ; Wed, 9 Nov 2011 16:30:39 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so2210576vcb.31 for ; Wed, 09 Nov 2011 16:30:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=9clt8WKDRF/0o3zkxtsiE9PiW3i1Vrr3qEQHOFiSrN0=; b=K7s5NWS8KH6scYKrJXYsqxK504ERVFL3tdnFVUD8cVPFcbEYxutJpOqUNkseSUaUqh d261yXttw5YvQxgRVUH0XxCllgRyZrJH9oo2H7jgng1DNwKwpQoNktXDDS7BZS4jZ+0V pasDYGjLmHlwyNcavD0xMecXReHmfz+23hELk= Received: by 10.220.222.73 with SMTP id if9mr593135vcb.123.1320885039243; Wed, 09 Nov 2011 16:30:39 -0800 (PST) Received: from [172.17.104.84] (2016ahost130.starwoodbroadband.com. [12.159.173.130]) by mx.google.com with ESMTPS id f7sm9660639vdj.13.2011.11.09.16.30.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Nov 2011 16:30:38 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 9 Nov 2011 19:30:13 -0500 Message-Id: To: karp@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: Re: [karp] Russ Housley's Discuss on draft-ietf-karp-design-guide-05: (with DISCUSS and COMMENT) 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, 10 Nov 2011 00:30:41 -0000 Earlier, Russ Housley wrote: > I do not think the current document does a very good job > at documenting common design elements. By doing so now, > I think the WG will save a lot of time as each routing protocol > is considered. I am asking if others agree. I agree. Ran From housley@vigilsec.com Fri Nov 11 00:01:04 2011 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 8965F1F0C5F for ; Fri, 11 Nov 2011 00:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.911 X-Spam-Level: X-Spam-Status: No, score=-100.911 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZDrV8nU5x5A for ; Fri, 11 Nov 2011 00:01:03 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id AF0C21F0C34 for ; Fri, 11 Nov 2011 00:01:03 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 71F4FF24031; Fri, 11 Nov 2011 03:01:38 -0500 (EST) 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 UxlMzhjJgEic; Fri, 11 Nov 2011 03:00:49 -0500 (EST) Received: from [10.59.77.93] (unknown [210.229.158.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id DC797F2401D; Fri, 11 Nov 2011 03:01:36 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Thu, 10 Nov 2011 20:01:15 -0500 Content-Transfer-Encoding: 7bit Message-Id: <1243F92A-F0D7-414A-BD5C-ABAD2140183E@vigilsec.com> References: <4E9104B8.30701@joelhalpern.com> To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: karp@ietf.org Subject: Re: [karp] Russ Housley's Discuss on draft-ietf-karp-design-guide-05: (with DISCUSS and COMMENT) 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, 11 Nov 2011 08:01:04 -0000 Sam: I hope my note to Glen answers your question. Russ On Nov 7, 2011, at 2:16 PM, Sam Hartman wrote: >>>>>> "Russ" == Russ Housley writes: > > Russ> So, this is the part where we disagree. I do not think the > Russ> current document does a very good job at documenting common > Russ> design elements. By doing so now, the I think the WG will > Russ> save a lot of time as each routing protocol is considered. I > Russ> am asking if others agree. If there is not support for this > Russ> position, then I will clear. > > If you put together some slides talking about the sort of elements > you're looking for and we had some discussion about what we think we can > do I know I'd be very interested in the presentation and discussion. From housley@vigilsec.com Fri Nov 11 00:46:11 2011 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 3439121F84A9 for ; Fri, 11 Nov 2011 00:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.574 X-Spam-Level: X-Spam-Status: No, score=-101.574 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+QQ5EbQFk7O for ; Fri, 11 Nov 2011 00:46:10 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB6421F84A5 for ; Fri, 11 Nov 2011 00:46:10 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 578FEF2401D; Fri, 11 Nov 2011 03:46:19 -0500 (EST) 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 Lwu-A4q9A8LO; Fri, 11 Nov 2011 03:46:07 -0500 (EST) Received: from [10.59.77.93] (unknown [210.229.158.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 2ED57F2402B; Fri, 11 Nov 2011 03:46:17 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Fri, 11 Nov 2011 03:46:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6DF470CD-802E-4EA3-87C1-3CC3535359C3@vigilsec.com> References: <4E9104B8.30701@joelhalpern.com> To: Glen Kent X-Mailer: Apple Mail (2.1084) Cc: karp@ietf.org Subject: Re: [karp] Russ Housley's Discuss on draft-ietf-karp-design-guide-05: (with DISCUSS and COMMENT) 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, 11 Nov 2011 08:46:11 -0000 Glen: >> So, this is the part where we disagree. I do not think the current = document does a very >> good job at documenting common design elements. By doing so now, the = I think the >> WG >=20 > Mind elaborating what you mean by not documenting common design = elements? Since we know that manual key management must be supported, the WG has = decided to specify a crypto key table. Manual key management is = populating the table, but this needs to be accomplished using an = interface that protects the keying material from disclosure or = alteration. In addition, we want to specify automated key management. A protocol to = automatically populate the crypto key table will be used. Several cases = need to be considered: 1) pairwise keys -- IKEv2 and TLS already offer mechanisms that are = directly applicable. 2) group keys -- 2a) group keys distributed by a key center -- KeyProv offers mechanisms = that are directly applicable, but additional attributes may be needed. 2b) group keying protocols -- new protocol work is needed for this = approach to be employed. A design guide ought to say what work needs to be done and when each of = these cases ought to be employed. Russ= From touch@isi.edu Fri Nov 11 04:39:22 2011 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 C3AF221F86D0 for ; Fri, 11 Nov 2011 04:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLPOwAlYBNRk for ; Fri, 11 Nov 2011 04:39:22 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5939821F86AA for ; Fri, 11 Nov 2011 04:39:22 -0800 (PST) Received: from [172.35.1.4] (pc3.shinagawaphvod2-unet.ocn.ne.jp [220.110.141.59]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id pABCVHdi009541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 11 Nov 2011 04:31:28 -0800 (PST) Message-ID: <4EBD1593.2030103@isi.edu> Date: Fri, 11 Nov 2011 04:31:15 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Russ Housley References: <4E9104B8.30701@joelhalpern.com> <6DF470CD-802E-4EA3-87C1-3CC3535359C3@vigilsec.com> In-Reply-To: <6DF470CD-802E-4EA3-87C1-3CC3535359C3@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: karp@ietf.org Subject: Re: [karp] Russ Housley's Discuss on draft-ietf-karp-design-guide-05: (with DISCUSS and COMMENT) 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, 11 Nov 2011 12:39:22 -0000 On 11/11/2011 12:46 AM, Russ Housley wrote: > Glen: > >>> So, this is the part where we disagree. I do not think the current document does a very >>> good job at documenting common design elements. By doing so now, the I think the >>> WG >> >> Mind elaborating what you mean by not documenting common design elements? > > Since we know that manual key management must be supported, the WG has decided to specify a crypto key table. Manual key management is populating the table, but this needs to be accomplished using an interface that protects the keying material from disclosure or alteration. > > In addition, we want to specify automated key management. A protocol to automatically populate the crypto key table will be used. Several cases need to be considered: > > 1) pairwise keys -- IKEv2 and TLS already offer mechanisms that are directly applicable. FWIW, based on other recent discussions, it would be useful to know whether such keys need to be unidirectional or can be bidirection, and whether multiple concurrent keys between the same two endpoints is expected (i.e., for separate assocations, not as a key rollover issue). > 2) group keys -- > > 2a) group keys distributed by a key center -- KeyProv offers mechanisms that are directly applicable, but additional attributes may be needed. > > 2b) group keying protocols -- new protocol work is needed for this approach to be employed. > > A design guide ought to say what work needs to be done and when each of these cases ought to be employed. > > Russ > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp From jmh@joelhalpern.com Fri Nov 11 04:41:30 2011 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 310B321F87FC for ; Fri, 11 Nov 2011 04:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.172 X-Spam-Level: X-Spam-Status: No, score=-102.172 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuExzSzPEw9Z for ; Fri, 11 Nov 2011 04:41:29 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id C4A2D21F87D9 for ; Fri, 11 Nov 2011 04:41:29 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 87A02CD04C for ; Fri, 11 Nov 2011 04:41:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 47EB51BCC1D8 for ; Fri, 11 Nov 2011 04:41:28 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-169.clppva.btas.verizon.net [71.161.50.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id CDF301BCC1C6 for ; Fri, 11 Nov 2011 04:41:27 -0800 (PST) Message-ID: <4EBD17F7.4030806@joelhalpern.com> Date: Fri, 11 Nov 2011 07:41:27 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: karp@ietf.org References: <4E9104B8.30701@joelhalpern.com> <6DF470CD-802E-4EA3-87C1-3CC3535359C3@vigilsec.com> In-Reply-To: <6DF470CD-802E-4EA3-87C1-3CC3535359C3@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [karp] Russ Housley's Discuss on draft-ietf-karp-design-guide-05: (with DISCUSS and COMMENT) 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, 11 Nov 2011 12:41:30 -0000 This seems reasoanble, clear, and something that we can act on. Authors, can you do what is requested? Yours, Joel On 11/11/2011 3:46 AM, Russ Housley wrote: > Glen: > >>> So, this is the part where we disagree. I do not think the current document does a very >>> good job at documenting common design elements. By doing so now, the I think the >>> WG >> >> Mind elaborating what you mean by not documenting common design elements? > > Since we know that manual key management must be supported, the WG has decided to specify a crypto key table. Manual key management is populating the table, but this needs to be accomplished using an interface that protects the keying material from disclosure or alteration. > > In addition, we want to specify automated key management. A protocol to automatically populate the crypto key table will be used. Several cases need to be considered: > > 1) pairwise keys -- IKEv2 and TLS already offer mechanisms that are directly applicable. > > 2) group keys -- > > 2a) group keys distributed by a key center -- KeyProv offers mechanisms that are directly applicable, but additional attributes may be needed. > > 2b) group keying protocols -- new protocol work is needed for this approach to be employed. > > A design guide ought to say what work needs to be done and when each of these cases ought to be employed. > > Russ > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From jmh@joelhalpern.com Fri Nov 11 08:02:08 2011 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 AD28121F84B8 for ; Fri, 11 Nov 2011 08:02:08 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEI6eOcN7s1H for ; Fri, 11 Nov 2011 08:02:08 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 532C021F849E for ; Fri, 11 Nov 2011 08:02:08 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id F06E7CD0F5 for ; Fri, 11 Nov 2011 08:02:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 23A921BCE398; Fri, 11 Nov 2011 08:02:07 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.242.22.224] (m2f5f36d0.tmodns.net [208.54.95.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 89FE91BCE395; Fri, 11 Nov 2011 08:02:06 -0800 (PST) Message-ID: <4EBD46FE.6020508@joelhalpern.com> Date: Fri, 11 Nov 2011 11:02:06 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "karp@ietf.org" References: <4E9104B8.30701@joelhalpern.com> <6DF470CD-802E-4EA3-87C1-3CC3535359C3@vigilsec.com> <4EBD17F7.4030806@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [karp] Russ Housley's Discuss on draft-ietf-karp-design-guide-05: (with DISCUSS and COMMENT) 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, 11 Nov 2011 16:02:08 -0000 Given your and Manav's concern, we will try to include time for discussing this at the meeting in Taipei. I look forward to your note to the list, and hope other folks will respond to you beteen your posting and our WG session. Thank you, Joel On 11/11/2011 10:26 AM, Sam Hartman wrote: >>>>>> "Joel" == Joel M Halpern writes: > > Joel> This seems reasoanble, clear, and something that we can act > Joel> on. Authors, can you do what is requested? > > I actually kind of disagree with it. I don't think this belongs in the > design guide. I'll have mail explaining my position to the list by the > meeting. > > I'd prefer that a document that attempts to address this not get > approved before we can discuss whether Russ is right. > From manav.bhatia@alcatel-lucent.com Fri Nov 11 08:09:42 2011 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 0C83021F86AA for ; Fri, 11 Nov 2011 08:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.673 X-Spam-Level: X-Spam-Status: No, score=-6.673 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9UxNRd65PVQ for ; Fri, 11 Nov 2011 08:09:41 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE0D21F849E for ; Fri, 11 Nov 2011 08:09:41 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id pABG9aM7004383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 11 Nov 2011 10:09:39 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pABG9ZiE012845 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 11 Nov 2011 21:39:35 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Fri, 11 Nov 2011 21:39:35 +0530 From: "Bhatia, Manav (Manav)" To: "karp@ietf.org" Date: Fri, 11 Nov 2011 21:39:37 +0530 Thread-Topic: [karp] Russ Housley's Discuss on draft-ietf-karp-design-guide-05: (with DISCUSS and COMMENT) Thread-Index: Acygb0AOrF6ckjW7S5eYrBnlSmU/cQAAEKXQAAcr6JA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350D01222AAF@INBANSXCHMBSA1.in.alcatel-lucent.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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: [karp] FW: Russ Housley's Discuss on draft-ietf-karp-design-guide-05: (with DISCUSS and COMMENT) 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, 11 Nov 2011 16:09:42 -0000 Fwding to the KARP mailing list .. -----Original Message----- From: Bhatia, Manav (Manav)=20 Sent: Friday, November 11, 2011 6:19 PM To: 'Joel M. Halpern'; 'Brian Weis'; 'Gregory Lebovitz' Subject: RE: [karp] Russ Housley's Discuss on draft-ietf-karp-design-guide-= 05: (with DISCUSS and COMMENT) Hi Joel, I disagree that its very clear and reasonable. Russ seems to be making a sweeping assumption that design guide ought to me= ntion that a solution with manual keying needs to revolve around the crypto= key table. I am not too sure of that. I agree that it's a WG doc, but we h= ave not had any discussions on whether this is the FINAL approach that we a= re taking. I think its too premature to commit to this and the design guide= should remain oblivious to a solution that has not even been debated in th= e WG. If we really want to do as Russ suggests then we need to probably wait for = some more time till we have good clarity on where we're going with the cryp= to key table document. Cheers, Manav=20 > -----Original Message----- > From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf=20 > Of Joel M. Halpern > Sent: Friday, November 11, 2011 6:11 PM > To: karp@ietf.org > Subject: Re: [karp] Russ Housley's Discuss on > draft-ietf-karp-design-guide-05: (with DISCUSS and COMMENT) >=20 > This seems reasoanble, clear, and something that we can act on. > Authors, can you do what is requested? >=20 > Yours, > Joel >=20 > On 11/11/2011 3:46 AM, Russ Housley wrote: > > Glen: > > > >>> So, this is the part where we disagree. I do not think > the current > >>> document does a very good job at documenting common > design elements. =20 > >>> By doing so now, the I think the WG > >> > >> Mind elaborating what you mean by not documenting common > design elements? > > > > Since we know that manual key management must be supported, > the WG has decided to specify a crypto key table. Manual key=20 > management is populating the table, but this needs to be accomplished=20 > using an interface that protects the keying material from disclosure=20 > or alteration. > > > > In addition, we want to specify automated key management. =20 > A protocol to automatically populate the crypto key table will be=20 > used. Several cases need to be considered: > > > > 1) pairwise keys -- IKEv2 and TLS already offer mechanisms > that are directly applicable. > > > > 2) group keys -- > > > > 2a) group keys distributed by a key center -- KeyProv > offers mechanisms that are directly applicable, but additional=20 > attributes may be needed. > > > > 2b) group keying protocols -- new protocol work is needed > for this approach to be employed. > > > > A design guide ought to say what work needs to be done and > when each of these cases ought to be employed. > > > > Russ > > _______________________________________________ > > karp mailing list > > karp@ietf.org > > https://www.ietf.org/mailman/listinfo/karp > > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > = From housley@vigilsec.com Fri Nov 11 14:56:01 2011 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 E29FF11E8083 for ; Fri, 11 Nov 2011 14:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9O+7CFa5Yore for ; Fri, 11 Nov 2011 14:56:01 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 67A4F11E8099 for ; Fri, 11 Nov 2011 14:56:01 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 3BB7A9A473E; Fri, 11 Nov 2011 17:56:22 -0500 (EST) 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 jqijzR2IRGbn; Fri, 11 Nov 2011 17:55:50 -0500 (EST) Received: from [172.20.0.163] (unknown [203.69.99.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id F3C909A4742; Fri, 11 Nov 2011 17:56:20 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <4EBD1593.2030103@isi.edu> Date: Fri, 11 Nov 2011 17:55:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <835E1292-910E-43DA-88E3-E8AFC01B20F2@vigilsec.com> References: <4E9104B8.30701@joelhalpern.com> <6DF470CD-802E-4EA3-87C1-3CC3535359C3@vigilsec.com> <4EBD1593.2030103@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1084) Cc: karp@ietf.org Subject: Re: [karp] Russ Housley's Discuss on draft-ietf-karp-design-guide-05: (with DISCUSS and COMMENT) 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, 11 Nov 2011 22:56:02 -0000 Joe: > FWIW, based on other recent discussions, it would be useful to know = whether such keys need to be unidirectional or can be bidirection, and = whether multiple concurrent keys between the same two endpoints is = expected (i.e., for separate assocations, not as a key rollover issue). These are attributes that are stored in the crypto key table under the = current draft. Russ= From acee@lindem.com Fri Nov 11 20:05:39 2011 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 9E1981F0C42 for ; Fri, 11 Nov 2011 20:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5p1im+VDQZo8 for ; Fri, 11 Nov 2011 20:05:39 -0800 (PST) Received: from bthceg-momta01-cwmx.mycingular.net (bthceg-momta01-cwmx.mycingular.net [166.216.231.204]) by ietfa.amsl.com (Postfix) with ESMTP id 1E25C1F0C41 for ; Fri, 11 Nov 2011 20:05:39 -0800 (PST) Received: from [166.205.136.176] ([166.205.136.176:17526] helo=[10.90.136.16]) by bthceg-momta01 (envelope-from ) (ecelerity 3.0.23.37692 r(37717)) with ESMTP id 1A/21-11285-F80FDBE4; Fri, 11 Nov 2011 20:05:36 -0800 References: <7C362EEF9C7896468B36C9B79200D8350D01222AAF@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D01222AAF@INBANSXCHMBSA1.in.alcatel-lucent.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <27B2DF3C-C8E4-40F5-843E-7339EB503A4A@lindem.com> X-Mailer: iPhone Mail (9A334) From: Acee Lindem Date: Fri, 11 Nov 2011 20:05:31 -0800 To: "Bhatia, Manav (Manav)" Cc: "karp@ietf.org" Subject: Re: [karp] FW: Russ Housley's Discuss on draft-ietf-karp-design-guide-05: (with DISCUSS and COMMENT) 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, 12 Nov 2011 04:05:39 -0000 I agree with Manav.=20 Thanks, Acee On Nov 11, 2011, at 8:09 AM, "Bhatia, Manav (Manav)" wrote: > Fwding to the KARP mailing list .. >=20 > -----Original Message----- > From: Bhatia, Manav (Manav)=20 > Sent: Friday, November 11, 2011 6:19 PM > To: 'Joel M. Halpern'; 'Brian Weis'; 'Gregory Lebovitz' > Subject: RE: [karp] Russ Housley's Discuss on draft-ietf-karp-design-guide= -05: (with DISCUSS and COMMENT) >=20 > Hi Joel, >=20 > I disagree that its very clear and reasonable. >=20 > Russ seems to be making a sweeping assumption that design guide ought to m= ention that a solution with manual keying needs to revolve around the crypto= key table. I am not too sure of that. I agree that it's a WG doc, but we ha= ve not had any discussions on whether this is the FINAL approach that we are= taking. I think its too premature to commit to this and the design guide sh= ould remain oblivious to a solution that has not even been debated in the WG= . >=20 > If we really want to do as Russ suggests then we need to probably wait for= some more time till we have good clarity on where we're going with the cryp= to key table document. >=20 > Cheers, Manav=20 >=20 >> -----Original Message----- >> From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf=20 >> Of Joel M. Halpern >> Sent: Friday, November 11, 2011 6:11 PM >> To: karp@ietf.org >> Subject: Re: [karp] Russ Housley's Discuss on >> draft-ietf-karp-design-guide-05: (with DISCUSS and COMMENT) >>=20 >> This seems reasoanble, clear, and something that we can act on. >> Authors, can you do what is requested? >>=20 >> Yours, >> Joel >>=20 >> On 11/11/2011 3:46 AM, Russ Housley wrote: >>> Glen: >>>=20 >>>>> So, this is the part where we disagree. I do not think >> the current >>>>> document does a very good job at documenting common >> design elements. =20 >>>>> By doing so now, the I think the WG >>>>=20 >>>> Mind elaborating what you mean by not documenting common >> design elements? >>>=20 >>> Since we know that manual key management must be supported, >> the WG has decided to specify a crypto key table. Manual key=20 >> management is populating the table, but this needs to be accomplished=20 >> using an interface that protects the keying material from disclosure=20 >> or alteration. >>>=20 >>> In addition, we want to specify automated key management. =20 >> A protocol to automatically populate the crypto key table will be=20 >> used. Several cases need to be considered: >>>=20 >>> 1) pairwise keys -- IKEv2 and TLS already offer mechanisms >> that are directly applicable. >>>=20 >>> 2) group keys -- >>>=20 >>> 2a) group keys distributed by a key center -- KeyProv >> offers mechanisms that are directly applicable, but additional=20 >> attributes may be needed. >>>=20 >>> 2b) group keying protocols -- new protocol work is needed >> for this approach to be employed. >>>=20 >>> A design guide ought to say what work needs to be done and >> when each of these cases ought to be employed. >>>=20 >>> Russ >>> _______________________________________________ >>> karp mailing list >>> karp@ietf.org >>> https://www.ietf.org/mailman/listinfo/karp >>>=20 >> _______________________________________________ >> karp mailing list >> karp@ietf.org >> https://www.ietf.org/mailman/listinfo/karp >>=20 > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp From vnktshsriram@gmail.com Sat Nov 12 16:18:10 2011 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 6DFA721F861E for ; Sat, 12 Nov 2011 16:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlUCfwWbUWqS for ; Sat, 12 Nov 2011 16:18:09 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id BED9221F85AA for ; Sat, 12 Nov 2011 16:18:09 -0800 (PST) Received: by ywt34 with SMTP id 34so3616804ywt.31 for ; Sat, 12 Nov 2011 16:18:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yzRtayLdgdKkb+m5y7Yzo9lKcOPbLG8PZBVNQlkCZ2I=; b=K6dKuRSKUajp4wE9Ck1yxIczctTgGCiDF0wwbx31/cAyeXrbj6oZH5nKKu/4WakZ8z zMmKs3PeYUO4LKYWaTJ6kqOUGAhf/FA21i9esR3U3M3HOHV1Xp9xNxnMMj3RbOg2mZQY pBDxqM1BIhiBFU2vT2ey50jr21brGFvPEaU4E= MIME-Version: 1.0 Received: by 10.236.143.3 with SMTP id k3mr5714920yhj.91.1321143487845; Sat, 12 Nov 2011 16:18:07 -0800 (PST) Received: by 10.236.105.165 with HTTP; Sat, 12 Nov 2011 16:18:07 -0800 (PST) In-Reply-To: <27B2DF3C-C8E4-40F5-843E-7339EB503A4A@lindem.com> References: <7C362EEF9C7896468B36C9B79200D8350D01222AAF@INBANSXCHMBSA1.in.alcatel-lucent.com> <27B2DF3C-C8E4-40F5-843E-7339EB503A4A@lindem.com> Date: Sun, 13 Nov 2011 05:48:07 +0530 Message-ID: From: Venkatesh Sriram To: Acee Lindem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "karp@ietf.org" Subject: Re: [karp] FW: Russ Housley's Discuss on draft-ietf-karp-design-guide-05: (with DISCUSS and COMMENT) 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, 13 Nov 2011 00:18:10 -0000 +1 Sriram On Sat, Nov 12, 2011 at 9:35 AM, Acee Lindem wrote: > I agree with Manav. > > Thanks, > Acee > > > On Nov 11, 2011, at 8:09 AM, "Bhatia, Manav (Manav)" wrote: > >> Fwding to the KARP mailing list .. >> >> -----Original Message----- >> From: Bhatia, Manav (Manav) >> Sent: Friday, November 11, 2011 6:19 PM >> To: 'Joel M. Halpern'; 'Brian Weis'; 'Gregory Lebovitz' >> Subject: RE: [karp] Russ Housley's Discuss on draft-ietf-karp-design-gui= de-05: (with DISCUSS and COMMENT) >> >> Hi Joel, >> >> I disagree that its very clear and reasonable. >> >> Russ seems to be making a sweeping assumption that design guide ought to= mention that a solution with manual keying needs to revolve around the cry= pto key table. I am not too sure of that. I agree that it's a WG doc, but w= e have not had any discussions on whether this is the FINAL approach that w= e are taking. I think its too premature to commit to this and the design gu= ide should remain oblivious to a solution that has not even been debated in= the WG. >> >> If we really want to do as Russ suggests then we need to probably wait f= or some more time till we have good clarity on where we're going with the c= rypto key table document. >> >> Cheers, Manav >> >>> -----Original Message----- >>> From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf >>> Of Joel M. Halpern >>> Sent: Friday, November 11, 2011 6:11 PM >>> To: karp@ietf.org >>> Subject: Re: [karp] Russ Housley's Discuss on >>> draft-ietf-karp-design-guide-05: (with DISCUSS and COMMENT) >>> >>> This seems reasoanble, clear, and something that we can act on. >>> Authors, can you do what is requested? >>> >>> Yours, >>> Joel >>> >>> On 11/11/2011 3:46 AM, Russ Housley wrote: >>>> Glen: >>>> >>>>>> So, this is the part where we disagree. =A0I do not think >>> the current >>>>>> document does a very good job at documenting common >>> design elements. >>>>>> By doing so now, the I think the WG >>>>> >>>>> Mind elaborating what you mean by not documenting common >>> design elements? >>>> >>>> Since we know that manual key management must be supported, >>> the WG has decided to specify a crypto key table. =A0Manual key >>> management is populating the table, but this needs to be accomplished >>> using an interface that protects the keying material from disclosure >>> or alteration. >>>> >>>> In addition, we want to specify automated key management. >>> A protocol to automatically populate the crypto key table will be >>> used. =A0Several cases need to be considered: >>>> >>>> 1) pairwise keys -- IKEv2 and TLS already offer mechanisms >>> that are directly applicable. >>>> >>>> 2) group keys -- >>>> >>>> 2a) group keys distributed by a key center -- KeyProv >>> offers mechanisms that are directly applicable, but additional >>> attributes may be needed. >>>> >>>> 2b) group keying protocols -- new protocol work is needed >>> for this approach to be employed. >>>> >>>> A design guide ought to say what work needs to be done and >>> when each of these cases ought to be employed. >>>> >>>> Russ >>>> _______________________________________________ >>>> karp mailing list >>>> karp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/karp >>>> >>> _______________________________________________ >>> karp mailing list >>> karp@ietf.org >>> https://www.ietf.org/mailman/listinfo/karp >>> >> _______________________________________________ >> karp mailing list >> karp@ietf.org >> https://www.ietf.org/mailman/listinfo/karp > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From turners@ieca.com Sat Nov 12 21:07:58 2011 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 6AD1D21F8AF9 for ; Sat, 12 Nov 2011 21:07:58 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNJZ9xijEyz8 for ; Sat, 12 Nov 2011 21:07:57 -0800 (PST) Received: from gateway.websitewelcome.com (gateway13.websitewelcome.com [69.93.164.20]) by ietfa.amsl.com (Postfix) with ESMTP id D556221F8AF8 for ; Sat, 12 Nov 2011 21:07:57 -0800 (PST) Received: by gateway.websitewelcome.com (Postfix, from userid 5007) id 84B54418263A6; Sat, 12 Nov 2011 23:07:56 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway.websitewelcome.com (Postfix) with ESMTP id 772A241826386 for ; Sat, 12 Nov 2011 23:07:56 -0600 (CST) Received: from [130.129.38.246] (port=51005 helo=dhcp-26f6.meeting.ietf.org) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RPSIN-000798-Se for karp@ietf.org; Sat, 12 Nov 2011 23:07:56 -0600 Message-ID: <4EBF50AA.9060902@ieca.com> Date: Sun, 13 Nov 2011 13:07:54 +0800 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "karp@ietf.org" References: <7C362EEF9C7896468B36C9B79200D8350D01222AAF@INBANSXCHMBSA1.in.alcatel-lucent.com> <27B2DF3C-C8E4-40F5-843E-7339EB503A4A@lindem.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: dhcp-26f6.meeting.ietf.org [130.129.38.246]:51005 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [karp] FW: Russ Housley's Discuss on draft-ietf-karp-design-guide-05: (with DISCUSS and COMMENT) 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, 13 Nov 2011 05:07:58 -0000 -1 spt On 11/13/11 8:18 AM, Venkatesh Sriram wrote: > +1 > > Sriram > > On Sat, Nov 12, 2011 at 9:35 AM, Acee Lindem wrote: >> I agree with Manav. >> >> Thanks, >> Acee >> >> >> On Nov 11, 2011, at 8:09 AM, "Bhatia, Manav (Manav)" wrote: >> >>> Fwding to the KARP mailing list .. >>> >>> -----Original Message----- >>> From: Bhatia, Manav (Manav) >>> Sent: Friday, November 11, 2011 6:19 PM >>> To: 'Joel M. Halpern'; 'Brian Weis'; 'Gregory Lebovitz' >>> Subject: RE: [karp] Russ Housley's Discuss on draft-ietf-karp-design-guide-05: (with DISCUSS and COMMENT) >>> >>> Hi Joel, >>> >>> I disagree that its very clear and reasonable. >>> >>> Russ seems to be making a sweeping assumption that design guide ought to mention that a solution with manual keying needs to revolve around the crypto key table. I am not too sure of that. I agree that it's a WG doc, but we have not had any discussions on whether this is the FINAL approach that we are taking. I think its too premature to commit to this and the design guide should remain oblivious to a solution that has not even been debated in the WG. >>> >>> If we really want to do as Russ suggests then we need to probably wait for some more time till we have good clarity on where we're going with the crypto key table document. >>> >>> Cheers, Manav >>> >>>> -----Original Message----- >>>> From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf >>>> Of Joel M. Halpern >>>> Sent: Friday, November 11, 2011 6:11 PM >>>> To: karp@ietf.org >>>> Subject: Re: [karp] Russ Housley's Discuss on >>>> draft-ietf-karp-design-guide-05: (with DISCUSS and COMMENT) >>>> >>>> This seems reasoanble, clear, and something that we can act on. >>>> Authors, can you do what is requested? >>>> >>>> Yours, >>>> Joel >>>> >>>> On 11/11/2011 3:46 AM, Russ Housley wrote: >>>>> Glen: >>>>> >>>>>>> So, this is the part where we disagree. I do not think >>>> the current >>>>>>> document does a very good job at documenting common >>>> design elements. >>>>>>> By doing so now, the I think the WG >>>>>> >>>>>> Mind elaborating what you mean by not documenting common >>>> design elements? >>>>> >>>>> Since we know that manual key management must be supported, >>>> the WG has decided to specify a crypto key table. Manual key >>>> management is populating the table, but this needs to be accomplished >>>> using an interface that protects the keying material from disclosure >>>> or alteration. >>>>> >>>>> In addition, we want to specify automated key management. >>>> A protocol to automatically populate the crypto key table will be >>>> used. Several cases need to be considered: >>>>> >>>>> 1) pairwise keys -- IKEv2 and TLS already offer mechanisms >>>> that are directly applicable. >>>>> >>>>> 2) group keys -- >>>>> >>>>> 2a) group keys distributed by a key center -- KeyProv >>>> offers mechanisms that are directly applicable, but additional >>>> attributes may be needed. >>>>> >>>>> 2b) group keying protocols -- new protocol work is needed >>>> for this approach to be employed. >>>>> >>>>> A design guide ought to say what work needs to be done and >>>> when each of these cases ought to be employed. >>>>> >>>>> Russ >>>>> _______________________________________________ >>>>> karp mailing list >>>>> karp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/karp >>>>> >>>> _______________________________________________ >>>> karp mailing list >>>> karp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/karp >>>> >>> _______________________________________________ >>> karp mailing list >>> karp@ietf.org >>> https://www.ietf.org/mailman/listinfo/karp >> _______________________________________________ >> karp mailing list >> karp@ietf.org >> https://www.ietf.org/mailman/listinfo/karp >> > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From hartmans@mit.edu Tue Nov 15 22:11:30 2011 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 ABACE11E812B for ; Tue, 15 Nov 2011 22:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.89 X-Spam-Level: X-Spam-Status: No, score=-103.89 tagged_above=-999 required=5 tests=[AWL=-1.625, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XW5yoXuIE37k for ; Tue, 15 Nov 2011 22:11:24 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7A32A21F9270 for ; Tue, 15 Nov 2011 22:11:01 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (dhcp-51cb.meeting.ietf.org [130.129.81.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 7CB1F20F27 for ; Wed, 16 Nov 2011 01:11:38 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DD87E435A; Wed, 16 Nov 2011 01:10:49 -0500 (EST) From: Sam Hartman To: karp@ietf.org Date: Wed, 16 Nov 2011 01:10:49 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [karp] Proposed text for design guide 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, 16 Nov 2011 06:11:30 -0000 KARP will focus on an abstraction for keying information that describes the interface between routing protocols, operators and automated key management. Conceptually when routing protocols send or recieve packets they will look up the key to use in this abstract key table. Conceptually, there will be an interface for a routing protocol to make requests of automated key management when it is being used; when keys become available they will be made available in the key table. There is no requirement that this abstraction be used for implementation; the abstraction serves the needs of standardization an and management. Specifically as part of the KARP work plan: 1) KARP will design the key table abstraction and the interface between key management protocols and routing protocols. 2) For each routing protocol, we will define the mapping between how the protocol represents key material and the protocol independent key table abstraction. When routing protocols share a common mechanism for authentication, such as the TCP Authentication Option, the same mapping is likely to be reused between protocols. An implementation may be able to move much of the keying logic into code related to this shared authentication primitive rather than code specific to routing protocols. 3) When designing automated key management for both symmetric keys and group keys, we will only use the abstractions designed in point 1 above to communicate between automated key management and routing protocols. From jmh@joelhalpern.com Tue Nov 15 22:19:54 2011 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 888D711E8116 for ; Tue, 15 Nov 2011 22:19:54 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zrw4QPPx88D5 for ; Tue, 15 Nov 2011 22:19:50 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id BF79421F8479 for ; Tue, 15 Nov 2011 22:19:50 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 65373CAEC1 for ; Tue, 15 Nov 2011 22:19:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 1ED291C1362; Tue, 15 Nov 2011 22:19:49 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [130.129.38.181] (dhcp-26b5.meeting.ietf.org [130.129.38.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 8D53F1C1361; Tue, 15 Nov 2011 22:19:48 -0800 (PST) Message-ID: <4EC35600.9050004@joelhalpern.com> Date: Wed, 16 Nov 2011 01:19:44 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: karp@ietf.org Subject: Re: [karp] Proposed text for design guide 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, 16 Nov 2011 06:19:54 -0000 Thank you Sam. WG, this text attempts to capture an apparent agreement in the face-to-face meeting on how to resolve Russ Housley's discuss of the design guidelines document. Do members of the WG find this acceptable? Thank you, Joel & Brian On 11/16/2011 1:10 AM, Sam Hartman wrote: > > KARP will focus on an abstraction for keying information that describes > the interface between routing protocols, operators and automated key > management. Conceptually when routing protocols send or recieve packets > they will look up the key to use in this abstract key > table. Conceptually, there will be an interface for a routing protocol > to make requests of automated key management when it is being used; when > keys become available they will be made available in the key > table. There is no requirement that this abstraction be used for > implementation; the abstraction serves the needs of standardization an > and management. Specifically as part of the KARP work plan: > > 1) KARP will design the key table abstraction and the interface between > key management protocols and routing protocols. > > 2) For each routing protocol, we will define the mapping between how the > protocol represents key material and the protocol independent key table > abstraction. When routing protocols share a common mechanism for > authentication, such as the TCP Authentication Option, the same mapping > is likely to be reused between protocols. An implementation may be able > to move much of the keying logic into code related to this shared > authentication primitive rather than code specific to routing protocols. > > 3) When designing automated key management for both symmetric keys and > group keys, we will only use the abstractions designed in point 1 above > to communicate between automated key management and routing protocols. > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From hartmans@mit.edu Tue Nov 15 22:53:19 2011 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 BF39F11E81A9 for ; Tue, 15 Nov 2011 22:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.565 X-Spam-Level: X-Spam-Status: No, score=-103.565 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRsTaXp8h5ug for ; Tue, 15 Nov 2011 22:53:19 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4D65E11E81A1 for ; Tue, 15 Nov 2011 22:53:19 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (dhcp-51cb.meeting.ietf.org [130.129.81.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id E9B7120F33; Wed, 16 Nov 2011 01:53:57 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 51DE7435A; Wed, 16 Nov 2011 01:53:16 -0500 (EST) From: Sam Hartman To: "Joel M. Halpern" References: <4EC35600.9050004@joelhalpern.com> Date: Wed, 16 Nov 2011 01:53:16 -0500 In-Reply-To: <4EC35600.9050004@joelhalpern.com> (Joel M. Halpern's message of "Wed, 16 Nov 2011 01:19:44 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , karp@ietf.org Subject: Re: [karp] Proposed text for design guide 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, 16 Nov 2011 06:53:19 -0000 Joel asked me to flag that as various people have talked about AKM proposals, they have all needed to have some interface for the routing protocol or TCP-AO or whatever to request keys from the AKM. I've talked about that abstraction as well in my text, not just the existing key tables abstraction. From russw@riw.us Wed Nov 16 17:43:08 2011 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 039E111E8081 for ; Wed, 16 Nov 2011 17:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awk0Wu1ba+Zq for ; Wed, 16 Nov 2011 17:43:07 -0800 (PST) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 1202F11E80B4 for ; Wed, 16 Nov 2011 17:43:07 -0800 (PST) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:50767 helo=[192.168.100.58]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RQr0K-0003Wf-Ue for karp@ietf.org; Wed, 16 Nov 2011 20:43:05 -0500 Message-ID: <4EC4669E.5030105@riw.us> Date: Wed, 16 Nov 2011 20:42:54 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: karp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [karp] Proposed text for design guide 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, 17 Nov 2011 01:43:08 -0000 This looks good to me... :-) Russ On 11/16/2011 1:10 AM, Sam Hartman wrote: > > KARP will focus on an abstraction for keying information that describes > the interface between routing protocols, operators and automated key > management. Conceptually when routing protocols send or recieve packets > they will look up the key to use in this abstract key > table. Conceptually, there will be an interface for a routing protocol > to make requests of automated key management when it is being used; when > keys become available they will be made available in the key > table. There is no requirement that this abstraction be used for > implementation; the abstraction serves the needs of standardization an > and management. Specifically as part of the KARP work plan: > > 1) KARP will design the key table abstraction and the interface between > key management protocols and routing protocols. > > 2) For each routing protocol, we will define the mapping between how the > protocol represents key material and the protocol independent key table > abstraction. When routing protocols share a common mechanism for > authentication, such as the TCP Authentication Option, the same mapping > is likely to be reused between protocols. An implementation may be able > to move much of the keying logic into code related to this shared > authentication primitive rather than code specific to routing protocols. > > 3) When designing automated key management for both symmetric keys and > group keys, we will only use the abstractions designed in point 1 above > to communicate between automated key management and routing protocols. > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp From touch@isi.edu Wed Nov 16 18:34:31 2011 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 B69AB1F0C3D for ; Wed, 16 Nov 2011 18:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.018 X-Spam-Level: X-Spam-Status: No, score=-105.018 tagged_above=-999 required=5 tests=[AWL=1.581, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOUknVoEqxIT for ; Wed, 16 Nov 2011 18:34:26 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id B22871F0C38 for ; Wed, 16 Nov 2011 18:34:26 -0800 (PST) Received: from [130.129.66.136] (dhcp-4288.meeting.ietf.org [130.129.66.136]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id pAH2XsEs019981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 16 Nov 2011 18:34:05 -0800 (PST) Message-ID: <4EC47290.4080000@isi.edu> Date: Wed, 16 Nov 2011 18:33:52 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: karp@ietf.org Subject: Re: [karp] Proposed text for design guide 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, 17 Nov 2011 02:34:31 -0000 On 11/15/2011 10:10 PM, Sam Hartman wrote: > > KARP will focus on an abstraction for keying information that describes > the interface between routing protocols, operators and automated key > management. Conceptually when routing protocols send or recieve packets > they will look up the key to use in this abstract key > table. I don't think KARP should specify things in terms of packets - those abstractions exist at other layers of the stack (transport = segment, network = packet, link = frame). IMO, this should refer to *messages*, and say: Conceptually when routing protocols send or receive messages they are associated with a key in this abstract key table. I.e., "associated" could mean (and this might be useful to explain): - used by the routing protocol to protect a message - associated with a session at a lower protocol layer to protect transfers at that layer > ...Conceptually, there will be an interface for a routing protocol > to make requests of automated key management when it is being used; when > keys become available they will be made available in the key > table. There is no requirement that this abstraction be used for > implementation; the abstraction serves the needs of standardization an > and management. Specifically as part of the KARP work plan: > > 1) KARP will design the key table abstraction and the interface between > key management protocols and routing protocols. And (possibly) security protocols at other layers. > 2) For each routing protocol, we will define the mapping between how the > protocol represents key material and the protocol independent key table > abstraction. When routing protocols share a common mechanism for > authentication, such as the TCP Authentication Option, the same mapping > is likely to be reused between protocols. An implementation may be able > to move much of the keying logic into code related to this shared > authentication primitive rather than code specific to routing protocols. > > 3) When designing automated key management for both symmetric keys and > group keys, we will only use the abstractions designed in point 1 above > to communicate between automated key management and routing protocols. > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp From acee@lindem.com Wed Nov 16 20:44:03 2011 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 CF32C11E80E2 for ; Wed, 16 Nov 2011 20:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0X7j0IKZ4k3i for ; Wed, 16 Nov 2011 20:44:03 -0800 (PST) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD0811E80DA for ; Wed, 16 Nov 2011 20:44:02 -0800 (PST) X-Authority-Analysis: v=2.0 cv=a9WyBDuF c=1 sm=0 a=C2g1Hp6idNFTy4K9KrF8yg==:17 a=jx89SKSrr_4A:10 a=Wma4Of2gTTwA:10 a=kj9zAlcOel0A:10 a=48vgC7mUAAAA:8 a=k1VEMO89lDWjgDmseQoA:9 a=RHYUbL6yz3Oumfj0ib4A:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=C2g1Hp6idNFTy4K9KrF8yg==:117 X-Cloudmark-Score: 0 X-Originating-IP: 65.190.0.120 Received: from [65.190.0.120] ([65.190.0.120:49587] helo=[192.168.1.100]) by cdptpa-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 1F/42-04465-11194CE4; Thu, 17 Nov 2011 04:44:02 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Acee Lindem In-Reply-To: <4EC35600.9050004@joelhalpern.com> Date: Wed, 16 Nov 2011 23:44:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EC35600.9050004@joelhalpern.com> To: Joel M. Halpern X-Mailer: Apple Mail (2.1084) Cc: Sam Hartman , karp@ietf.org Subject: Re: [karp] Proposed text for design guide 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, 17 Nov 2011 04:44:03 -0000 Hi Joel,=20 While this may be the ultimate positioning of the key table draft, I = think it is premature to elevate it to this status.=20 I have the following comments on the -02 version: =20 1. LocalKeyID - Don't overload whether it is a pairwise or group key = in the high order bit of the ID. Since there are already over 15 key = fields in conceptual database, I don't see advantage of overloading the = ID space. Let's not forget that if this draft becomes an RFC, = administrators may actually have to configure these IDs.=20 2. Peers - How are peers identified?=20 3. Interfaces - How are interfaces and virtual interfaces identified? = Is it protocol dependent? 4. Use KeyStartAccept, KeyStopAccept, KeyStartGenerate, and = KeyStopGenerate as field names in the conceptual database rather than = RcvNotBefore, RcvNotAfter, SendNotBefore, and SendNotAfter.=20 This will be consistent with RFC 2238 and RFC 5709. The answer to #3 will be useful in determining whether or not the keys = for OSPF virtual links can easily mapped to the database. I had = previously raised this issue but hadn't received a response.=20 Thanks, Acee=20 On Nov 16, 2011, at 1:19 AM, Joel M. Halpern wrote: > Thank you Sam. >=20 > WG, this text attempts to capture an apparent agreement in the = face-to-face meeting on how to resolve Russ Housley's discuss of the = design guidelines document. >=20 > Do members of the WG find this acceptable? >=20 > Thank you, > Joel & Brian >=20 > On 11/16/2011 1:10 AM, Sam Hartman wrote: >>=20 >> KARP will focus on an abstraction for keying information that = describes >> the interface between routing protocols, operators and automated key >> management. Conceptually when routing protocols send or recieve = packets >> they will look up the key to use in this abstract key >> table. Conceptually, there will be an interface for a routing = protocol >> to make requests of automated key management when it is being used; = when >> keys become available they will be made available in the key >> table. There is no requirement that this abstraction be used for >> implementation; the abstraction serves the needs of standardization = an >> and management. Specifically as part of the KARP work plan: >>=20 >> 1) KARP will design the key table abstraction and the interface = between >> key management protocols and routing protocols. >>=20 >> 2) For each routing protocol, we will define the mapping between how = the >> protocol represents key material and the protocol independent key = table >> abstraction. When routing protocols share a common mechanism for >> authentication, such as the TCP Authentication Option, the same = mapping >> is likely to be reused between protocols. An implementation may be = able >> to move much of the keying logic into code related to this shared >> authentication primitive rather than code specific to routing = protocols. >>=20 >> 3) When designing automated key management for both symmetric keys = and >> group keys, we will only use the abstractions designed in point 1 = above >> to communicate between automated key management and routing = protocols. >> _______________________________________________ >> karp mailing list >> karp@ietf.org >> https://www.ietf.org/mailman/listinfo/karp >>=20 > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp From turners@ieca.com Wed Nov 16 21:10:51 2011 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 63FE321F95B5 for ; Wed, 16 Nov 2011 21:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.272 X-Spam-Level: X-Spam-Status: No, score=-102.272 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdYWb-fowFg2 for ; Wed, 16 Nov 2011 21:10:51 -0800 (PST) Received: from gateway.websitewelcome.com (gateway12.websitewelcome.com [69.93.154.13]) by ietfa.amsl.com (Postfix) with ESMTP id F369821F945C for ; Wed, 16 Nov 2011 21:10:50 -0800 (PST) Received: by gateway.websitewelcome.com (Postfix, from userid 5007) id 28C284AC738F4; Wed, 16 Nov 2011 23:10:50 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway.websitewelcome.com (Postfix) with ESMTP id 1980F4AC738B2 for ; Wed, 16 Nov 2011 23:10:50 -0600 (CST) Received: from [130.129.37.148] (port=51252 helo=dhcp-2594.meeting.ietf.org) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RQuFM-0006xp-Oq for karp@ietf.org; Wed, 16 Nov 2011 23:10:48 -0600 Message-ID: <4EC49757.20009@ieca.com> Date: Thu, 17 Nov 2011 13:10:47 +0800 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: karp@ietf.org 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: dhcp-2594.meeting.ietf.org [130.129.37.148]:51252 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [karp] draft-ietf-ospf-auth-trailer-ospfv3 vs draft-ietf-karp-crypto-key-table 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, 17 Nov 2011 05:10:51 -0000 Folks, We've got draft-ietf-karp-crypto-key-table with some table entries and draft-ietf-ospf-auth-trailer-ospfv3 with some table entries. The two don't match. I think this is bad. Can we work to align them? spt From jmh@joelhalpern.com Wed Nov 16 21:20:19 2011 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 91DEF11E8114 for ; Wed, 16 Nov 2011 21:20:18 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B99dCz7SlTaa for ; Wed, 16 Nov 2011 21:20:17 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7E87911E810A for ; Wed, 16 Nov 2011 21:20:15 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 46749A5D26 for ; Wed, 16 Nov 2011 21:20:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 09FEE20122B; Wed, 16 Nov 2011 21:20:15 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [130.129.38.181] (dhcp-26b5.meeting.ietf.org [130.129.38.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 60A7120122A; Wed, 16 Nov 2011 21:20:14 -0800 (PST) Message-ID: <4EC4998B.9070504@joelhalpern.com> Date: Thu, 17 Nov 2011 00:20:11 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Acee Lindem References: <4EC35600.9050004@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: karp@ietf.org Subject: Re: [karp] Proposed text for design guide 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, 17 Nov 2011 05:20:19 -0000 These appear to be useful questions that we need to answer before we send keytables for publication. I look forward to comments from the authors. However, since the proposed reference to keytables in the design-guidelines is to the concept, not a normative reference to the specific document, I am not sure I understand why those detail issues are an objection to the conceptual reference in the design guidelines document. Can you clarify? Yours, Joel On 11/16/2011 11:44 PM, Acee Lindem wrote: > Hi Joel, > While this may be the ultimate positioning of the key table draft, I think it is premature to elevate it to this status. > > I have the following comments on the -02 version: > > 1. LocalKeyID - Don't overload whether it is a pairwise or group key in the high order bit of the ID. Since there are already over 15 key fields in conceptual database, I don't see advantage of overloading the ID space. Let's not forget that if this draft becomes an RFC, administrators may actually have to configure these IDs. > 2. Peers - How are peers identified? > 3. Interfaces - How are interfaces and virtual interfaces identified? Is it protocol dependent? > 4. Use KeyStartAccept, KeyStopAccept, KeyStartGenerate, and KeyStopGenerate as field names in the conceptual database rather than RcvNotBefore, RcvNotAfter, SendNotBefore, and SendNotAfter. > This will be consistent with RFC 2238 and RFC 5709. > > The answer to #3 will be useful in determining whether or not the keys for OSPF virtual links can easily mapped to the database. I had previously raised this issue but hadn't received a response. > > Thanks, > Acee > > On Nov 16, 2011, at 1:19 AM, Joel M. Halpern wrote: > >> Thank you Sam. >> >> WG, this text attempts to capture an apparent agreement in the face-to-face meeting on how to resolve Russ Housley's discuss of the design guidelines document. >> >> Do members of the WG find this acceptable? >> >> Thank you, >> Joel& Brian >> >> On 11/16/2011 1:10 AM, Sam Hartman wrote: >>> >>> KARP will focus on an abstraction for keying information that describes >>> the interface between routing protocols, operators and automated key >>> management. Conceptually when routing protocols send or recieve packets >>> they will look up the key to use in this abstract key >>> table. Conceptually, there will be an interface for a routing protocol >>> to make requests of automated key management when it is being used; when >>> keys become available they will be made available in the key >>> table. There is no requirement that this abstraction be used for >>> implementation; the abstraction serves the needs of standardization an >>> and management. Specifically as part of the KARP work plan: >>> >>> 1) KARP will design the key table abstraction and the interface between >>> key management protocols and routing protocols. >>> >>> 2) For each routing protocol, we will define the mapping between how the >>> protocol represents key material and the protocol independent key table >>> abstraction. When routing protocols share a common mechanism for >>> authentication, such as the TCP Authentication Option, the same mapping >>> is likely to be reused between protocols. An implementation may be able >>> to move much of the keying logic into code related to this shared >>> authentication primitive rather than code specific to routing protocols. >>> >>> 3) When designing automated key management for both symmetric keys and >>> group keys, we will only use the abstractions designed in point 1 above >>> to communicate between automated key management and routing protocols. >>> _______________________________________________ >>> karp mailing list >>> karp@ietf.org >>> https://www.ietf.org/mailman/listinfo/karp >>> >> _______________________________________________ >> karp mailing list >> karp@ietf.org >> https://www.ietf.org/mailman/listinfo/karp > > From manav.bhatia@alcatel-lucent.com Wed Nov 16 21:28:49 2011 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 52B5C21F9684 for ; Wed, 16 Nov 2011 21:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.666 X-Spam-Level: X-Spam-Status: No, score=-6.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvsQ9EvaY6aJ for ; Wed, 16 Nov 2011 21:28:47 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id CF67221F967E for ; Wed, 16 Nov 2011 21:28:47 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id pAH5Sige026639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Nov 2011 23:28:46 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pAH5SaFf000886 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 17 Nov 2011 10:58:36 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Thu, 17 Nov 2011 10:58:36 +0530 From: "Bhatia, Manav (Manav)" To: Acee Lindem , "Joel M. Halpern" Date: Thu, 17 Nov 2011 10:58:32 +0530 Thread-Topic: [karp] Proposed text for design guide Thread-Index: Acyk46aGJTPoOhWqTMu9UGT3WmkhJwABAjzQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350D012232CF@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4EC35600.9050004@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: Sam Hartman , "karp@ietf.org" Subject: Re: [karp] Proposed text for design guide 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, 17 Nov 2011 05:28:49 -0000 In addition to this the LocalKeyID and PeerKeyID defined in karp-crypto-tab= le are 15 bit values (the MSB is reserved). This cant even accommodate the = key size specified in RFC 5310 and several other routing security drafts. S= o the least that needs to be done is to increase this to 17 bits. When doing draft-ietf-ospf-auth-trailer-ospfv3 there was some discussion on= the key size and we had reached a consensus on keeping the key size (equiv= alent of LocalKeyID and PeerKeyID) as 32 bits. It would thus make sense to = increase the LocalKeyID and PeerKeyID sizes in the karp-crypto-table to at = least 32 or 33 bits. Cheers, Manav > -----Original Message----- > From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On=20 > Behalf Of Acee Lindem > Sent: Thursday, November 17, 2011 10:14 AM > To: Joel M. Halpern > Cc: Sam Hartman; karp@ietf.org > Subject: Re: [karp] Proposed text for design guide >=20 > Hi Joel, > While this may be the ultimate positioning of the key table=20 > draft, I think it is premature to elevate it to this status.=20 >=20 > I have the following comments on the -02 version: > =20 > 1. LocalKeyID - Don't overload whether it is a pairwise or=20 > group key in the high order bit of the ID. Since there are=20 > already over 15 key fields in conceptual database, I don't=20 > see advantage of overloading the ID space. Let's not forget=20 > that if this draft becomes an RFC, administrators may=20 > actually have to configure these IDs.=20 > 2. Peers - How are peers identified?=20 > 3. Interfaces - How are interfaces and virtual interfaces=20 > identified? Is it protocol dependent? > 4. Use KeyStartAccept, KeyStopAccept, KeyStartGenerate, and=20 > KeyStopGenerate as field names in the conceptual database=20 > rather than RcvNotBefore, RcvNotAfter, SendNotBefore, and=20 > SendNotAfter.=20 > This will be consistent with RFC 2238 and RFC 5709. >=20 > The answer to #3 will be useful in determining whether or not=20 > the keys for OSPF virtual links can easily mapped to the=20 > database. I had previously raised this issue but hadn't=20 > received a response.=20 >=20 > Thanks, > Acee=20 >=20 > On Nov 16, 2011, at 1:19 AM, Joel M. Halpern wrote: >=20 > > Thank you Sam. > >=20 > > WG, this text attempts to capture an apparent agreement in=20 > the face-to-face meeting on how to resolve Russ Housley's=20 > discuss of the design guidelines document. > >=20 > > Do members of the WG find this acceptable? > >=20 > > Thank you, > > Joel & Brian > >=20 > > On 11/16/2011 1:10 AM, Sam Hartman wrote: > >>=20 > >> KARP will focus on an abstraction for keying information that=20 > >> describes the interface between routing protocols, operators and=20 > >> automated key management. Conceptually when routing=20 > protocols send or=20 > >> recieve packets they will look up the key to use in this=20 > abstract key=20 > >> table. Conceptually, there will be an interface for a routing=20 > >> protocol to make requests of automated key management when it is=20 > >> being used; when keys become available they will be made=20 > available in=20 > >> the key table. There is no requirement that this=20 > abstraction be used=20 > >> for implementation; the abstraction serves the needs of=20 > >> standardization an and management. Specifically as part of=20 > the KARP work plan: > >>=20 > >> 1) KARP will design the key table abstraction and the interface=20 > >> between key management protocols and routing protocols. > >>=20 > >> 2) For each routing protocol, we will define the mapping=20 > between how=20 > >> the protocol represents key material and the protocol=20 > independent key=20 > >> table abstraction. When routing protocols share a common mechanism=20 > >> for authentication, such as the TCP Authentication Option,=20 > the same=20 > >> mapping is likely to be reused between protocols. An=20 > implementation=20 > >> may be able to move much of the keying logic into code related to=20 > >> this shared authentication primitive rather than code=20 > specific to routing protocols. > >>=20 > >> 3) When designing automated key management for both symmetric keys=20 > >> and group keys, we will only use the abstractions designed=20 > in point 1=20 > >> above to communicate between automated key management and=20 > routing protocols. > >> _______________________________________________ > >> karp mailing list > >> karp@ietf.org > >> https://www.ietf.org/mailman/listinfo/karp > >>=20 > > _______________________________________________ > > karp mailing list > > karp@ietf.org > > https://www.ietf.org/mailman/listinfo/karp >=20 > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > = From hartmans@mit.edu Thu Nov 17 00:06:14 2011 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 2F8C911E814D for ; Thu, 17 Nov 2011 00:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.194 X-Spam-Level: X-Spam-Status: No, score=-103.194 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fMP4BCHWVwt for ; Thu, 17 Nov 2011 00:06:13 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id BF14A11E80E6 for ; Thu, 17 Nov 2011 00:06:05 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (dhcp-51cb.meeting.ietf.org [130.129.81.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6BAB321048; Thu, 17 Nov 2011 03:06:42 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BFD26435A; Thu, 17 Nov 2011 03:06:01 -0500 (EST) From: Sam Hartman To: Sean Turner References: <4EC49757.20009@ieca.com> Date: Thu, 17 Nov 2011 03:06:01 -0500 In-Reply-To: <4EC49757.20009@ieca.com> (Sean Turner's message of "Thu, 17 Nov 2011 13:10:47 +0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: karp@ietf.org Subject: Re: [karp] draft-ietf-ospf-auth-trailer-ospfv3 vs draft-ietf-karp-crypto-key-table 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, 17 Nov 2011 08:06:14 -0000 >>>>> "Sean" == Sean Turner writes: Sean> Folks, We've got draft-ietf-karp-crypto-key-table with some Sean> table entries and draft-ietf-ospf-auth-trailer-ospfv3 with Sean> some table entries. The two don't match. I think this is Sean> bad. Can we work to align them? This was discussed during the last call of the ospf v3 draft. My understanding is that we believed that the crypto-key-table draft is not mature enough to depend on. We tried to use the KARP key table for draft-ietf-ospf-security-extension-manual-keying-01.txt and ran into a multi-month block that is still blocked. I propose that we align OSPF and the KARP crypto table in that draft, but given the delays so far we don't hold a post-ietf-lc draft to that. From acee@lindem.com Thu Nov 17 02:28:50 2011 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 0279321F9BA0 for ; Thu, 17 Nov 2011 02:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZPhjcsVEuxz for ; Thu, 17 Nov 2011 02:28:49 -0800 (PST) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.121]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA1921F9B9E for ; Thu, 17 Nov 2011 02:28:49 -0800 (PST) X-Authority-Analysis: v=2.0 cv=VcZ1zSV9 c=1 sm=0 a=C2g1Hp6idNFTy4K9KrF8yg==:17 a=jx89SKSrr_4A:10 a=Wma4Of2gTTwA:10 a=kj9zAlcOel0A:10 a=48vgC7mUAAAA:8 a=AiRK4Qx1HGJKWr8rcEQA:9 a=XqBHIoYRYChO2lbZmWMA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=C2g1Hp6idNFTy4K9KrF8yg==:117 X-Cloudmark-Score: 0 X-Originating-IP: 65.190.0.120 Received: from [65.190.0.120] ([65.190.0.120:50151] helo=[192.168.1.100]) by cdptpa-oedge02.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id E5/19-03218-0E1E4CE4; Thu, 17 Nov 2011 10:28:48 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Acee Lindem In-Reply-To: <4EC4998B.9070504@joelhalpern.com> Date: Thu, 17 Nov 2011 05:28:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EC35600.9050004@joelhalpern.com> <4EC4998B.9070504@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1084) Cc: karp@ietf.org Subject: Re: [karp] Proposed text for design guide 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, 17 Nov 2011 10:28:50 -0000 On Nov 17, 2011, at 12:20 AM, Joel M. Halpern wrote: > These appear to be useful questions that we need to answer before we = send keytables for publication. > I look forward to comments from the authors. >=20 > However, since the proposed reference to keytables in the = design-guidelines is to the concept, not a normative reference to the = specific document, I am not sure I understand why those detail issues = are an objection to the conceptual reference in the design guidelines = document. > Can you clarify? As there are open issues on the draft, how can we be sure that this = draft will become an RFC and ultimately be published? Would this be a = normative or informative reference in the KARP design guide?=20 Thanks, Acee >=20 > Yours, > Joel >=20 > On 11/16/2011 11:44 PM, Acee Lindem wrote: >> Hi Joel, >> While this may be the ultimate positioning of the key table draft, I = think it is premature to elevate it to this status. >>=20 >> I have the following comments on the -02 version: >>=20 >> 1. LocalKeyID - Don't overload whether it is a pairwise or group = key in the high order bit of the ID. Since there are already over 15 key = fields in conceptual database, I don't see advantage of overloading the = ID space. Let's not forget that if this draft becomes an RFC, = administrators may actually have to configure these IDs. >> 2. Peers - How are peers identified? >> 3. Interfaces - How are interfaces and virtual interfaces = identified? Is it protocol dependent? >> 4. Use KeyStartAccept, KeyStopAccept, KeyStartGenerate, and = KeyStopGenerate as field names in the conceptual database rather than = RcvNotBefore, RcvNotAfter, SendNotBefore, and SendNotAfter. >> This will be consistent with RFC 2238 and RFC 5709. >>=20 >> The answer to #3 will be useful in determining whether or not the = keys for OSPF virtual links can easily mapped to the database. I had = previously raised this issue but hadn't received a response. >>=20 >> Thanks, >> Acee >>=20 >> On Nov 16, 2011, at 1:19 AM, Joel M. Halpern wrote: >>=20 >>> Thank you Sam. >>>=20 >>> WG, this text attempts to capture an apparent agreement in the = face-to-face meeting on how to resolve Russ Housley's discuss of the = design guidelines document. >>>=20 >>> Do members of the WG find this acceptable? >>>=20 >>> Thank you, >>> Joel& Brian >>>=20 >>> On 11/16/2011 1:10 AM, Sam Hartman wrote: >>>>=20 >>>> KARP will focus on an abstraction for keying information that = describes >>>> the interface between routing protocols, operators and automated = key >>>> management. Conceptually when routing protocols send or recieve = packets >>>> they will look up the key to use in this abstract key >>>> table. Conceptually, there will be an interface for a routing = protocol >>>> to make requests of automated key management when it is being used; = when >>>> keys become available they will be made available in the key >>>> table. There is no requirement that this abstraction be used for >>>> implementation; the abstraction serves the needs of standardization = an >>>> and management. Specifically as part of the KARP work plan: >>>>=20 >>>> 1) KARP will design the key table abstraction and the interface = between >>>> key management protocols and routing protocols. >>>>=20 >>>> 2) For each routing protocol, we will define the mapping between = how the >>>> protocol represents key material and the protocol independent key = table >>>> abstraction. When routing protocols share a common mechanism for >>>> authentication, such as the TCP Authentication Option, the same = mapping >>>> is likely to be reused between protocols. An implementation may be = able >>>> to move much of the keying logic into code related to this shared >>>> authentication primitive rather than code specific to routing = protocols. >>>>=20 >>>> 3) When designing automated key management for both symmetric keys = and >>>> group keys, we will only use the abstractions designed in point 1 = above >>>> to communicate between automated key management and routing = protocols. >>>> _______________________________________________ >>>> karp mailing list >>>> karp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/karp >>>>=20 >>> _______________________________________________ >>> karp mailing list >>> karp@ietf.org >>> https://www.ietf.org/mailman/listinfo/karp >>=20 >>=20 From rja.lists@gmail.com Thu Nov 17 07:15:05 2011 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 9CB7511E8143 for ; Thu, 17 Nov 2011 07:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.527 X-Spam-Level: X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgHq6jXDdRA3 for ; Thu, 17 Nov 2011 07:15:05 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0157911E8144 for ; Thu, 17 Nov 2011 07:15:04 -0800 (PST) Received: by vcbfl15 with SMTP id fl15so2300624vcb.31 for ; Thu, 17 Nov 2011 07:15:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=0MxWJzceaT1NBBxslGZOawpVCz+RJgGxgnpvMUEDylI=; b=of+HZJJ49pBUulht+QqUskYd1b1p96CXJLnncypByNgn/DbaQEe4yVswWDMLNjL93F NCqrCxXhVdZqagwWbPPDWB7BZw/Wpzwmr4fP9ZV1WBNyCQ+iuvb0pMkOfn25KCT5wOLT VP+ia+ajiB0zxGYhn3gIxfA1BixotNXXsw3hk= Received: by 10.52.36.109 with SMTP id p13mr56424751vdj.59.1321542904500; Thu, 17 Nov 2011 07:15:04 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id p2sm47966479vdi.22.2011.11.17.07.15.02 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Nov 2011 07:15:02 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 17 Nov 2011 10:15:01 -0500 Message-Id: To: karp@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: Re: [karp] Proposed text for design guide 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, 17 Nov 2011 15:15:05 -0000 Earlier, Joel Halpern wrote: > However, since the proposed reference to keytables in the > design-guidelines is to the concept, not a normative reference > to the specific document, I am not sure I understand why those > detail issues are an objection to the conceptual reference > in the design guidelines document. > > Can you clarify? Manav responded here: but with a narrow engineering issue about the bit length of a particular field, rather than with any objection to the concept -- and Joel was clearly and precisely asking about the concept alone. Then Acee responded here: but asked whether there would be a normative reference to the Key Tables I-D -- which Joel *already* answered above with "not a normative reference to the specific document". So I don't see either of those notes to the KARP list as actually responsive to Joel's precise question. The practical reality is that any implementation of routing protocol authentication using cryptography has to have some internal form of a key table. The engineering details of how a particular implementation might code that capability are both beyond the contents of the current Key Table I-D and also well beyond the scope of the Design Guide -- as it should be. However, having an internal key table of some sort is simply *unavoidable* for any implementation supporting cryptographic routing authentication. Its existence is mandated by numerous RFCs, for example RFC-2328 Section D.3 (which I wrote long ago). For the record, I do support a reference to the concept of a key table and I agree with Joel that a normative reference to the specific Key Tables I-D is not needed for the Design Guide. Yours, Ran From acee@lindem.com Thu Nov 17 14:27:43 2011 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 7FDC31F0C72 for ; Thu, 17 Nov 2011 14:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwVhGrsdR3p8 for ; Thu, 17 Nov 2011 14:27:43 -0800 (PST) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.123]) by ietfa.amsl.com (Postfix) with ESMTP id D87C81F0C63 for ; Thu, 17 Nov 2011 14:27:42 -0800 (PST) X-Authority-Analysis: v=2.0 cv=JsJzXbEC c=1 sm=0 a=C2g1Hp6idNFTy4K9KrF8yg==:17 a=jx89SKSrr_4A:10 a=Wma4Of2gTTwA:10 a=kj9zAlcOel0A:10 a=48vgC7mUAAAA:8 a=WPlyUduS2uoMBj1A0T0A:9 a=6FY08N-Wi1O2cYlPVSYA:7 a=CjuIK1q_8ugA:10 a=ZmXWRglzrFMA:10 a=AfgZba1JyJcA:10 a=lZB815dzVvQA:10 a=C2g1Hp6idNFTy4K9KrF8yg==:117 X-Cloudmark-Score: 0 X-Originating-IP: 65.190.0.120 Received: from [65.190.0.120] ([65.190.0.120:53648] helo=[192.168.1.100]) by cdptpa-oedge04.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 97/92-04648-D5A85CE4; Thu, 17 Nov 2011 22:27:42 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Acee Lindem In-Reply-To: Date: Thu, 17 Nov 2011 17:27:41 -0500 Content-Transfer-Encoding: 7bit Message-Id: <74CD1A20-B5EF-428E-A93B-016474138B51@lindem.com> References: To: RJ Atkinson X-Mailer: Apple Mail (2.1084) Cc: karp@ietf.org Subject: Re: [karp] Proposed text for design guide 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, 17 Nov 2011 22:27:43 -0000 Hi Ran, On Nov 17, 2011, at 10:15 AM, RJ Atkinson wrote: > Earlier, Joel Halpern wrote: >> However, since the proposed reference to keytables in the >> design-guidelines is to the concept, not a normative reference >> to the specific document, I am not sure I understand why those >> detail issues are an objection to the conceptual reference >> in the design guidelines document. >> >> Can you clarify? > > > Manav responded here: > > but with a narrow engineering issue about the bit length > of a particular field, rather than with any objection to the concept > -- and Joel was clearly and precisely asking about the concept alone. > > > Then Acee responded here: > > but asked whether there would be a normative reference > to the Key Tables I-D -- which Joel *already* answered > above with "not a normative reference to the specific document". > > > So I don't see either of those notes to the KARP list > as actually responsive to Joel's precise question. > > > The practical reality is that any implementation of routing > protocol authentication using cryptography has to have some > internal form of a key table. The engineering details of > how a particular implementation might code that capability > are both beyond the contents of the current Key Table I-D > and also well beyond the scope of the Design Guide -- as > it should be. > > > However, having an internal key table of some sort is simply > *unavoidable* for any implementation supporting cryptographic > routing authentication. Its existence is mandated by numerous > RFCs, for example RFC-2328 Section D.3 (which I wrote long ago). > > > For the record, I do support a reference to the concept > of a key table and I agree with Joel that a normative > reference to the specific Key Tables I-D is not needed > for the Design Guide. I'd agree with that as well. Thanks, Acee > > Yours, > > Ran > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp From touch@isi.edu Thu Nov 17 18:00:08 2011 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 7201811E8097 for ; Thu, 17 Nov 2011 18:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.226 X-Spam-Level: X-Spam-Status: No, score=-103.226 tagged_above=-999 required=5 tests=[AWL=-0.627, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyeEo+UgvRnh for ; Thu, 17 Nov 2011 18:00:07 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id D32D611E808A for ; Thu, 17 Nov 2011 18:00:07 -0800 (PST) Received: from [130.129.66.136] (dhcp-4288.meeting.ietf.org [130.129.66.136]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id pAI1x5Nv022814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Nov 2011 17:59:16 -0800 (PST) Message-ID: <4EC5BBE6.9010909@isi.edu> Date: Thu, 17 Nov 2011 17:59:02 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Sam Hartman References: <4EC47290.4080000@isi.edu> In-Reply-To: <4EC47290.4080000@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: karp@ietf.org Subject: Re: [karp] Proposed text for design guide 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, 18 Nov 2011 02:00:08 -0000 Hi, all, Following up on my view about the keytable issue, based on a lengthy discussion I had this AM with Ron Bonica on this: There are three basic components in automatic keying: - a key negotiation/exchange protocol here, IKEv2 - something that uses keys to protect messages here at the transport layer, TCP-AO and at other layers various message-signing mechanisms - something that manages key use THIS is the missing part, AFAICT Gatekeeper is a KMS - it is the key manager system. More specifically, it manages the meta-information about keys - lifetime, key exchange tags, etc. It need not ever contain key values. This is true across all KARP solutions - the "keytable" describes a place where keys are stored, but that is an artifact of an implementation. In TCP-AO, these are inside AO. In IPsec, they're inside IPsec. But that's not the component we need to describe - all keying mechanisms have a place they store the keys they use. What we need to describe (if at all) is the KMS as distinct from the keying protocol and the key-use mechanism. Joe On 11/16/2011 6:33 PM, Joe Touch wrote: > > > On 11/15/2011 10:10 PM, Sam Hartman wrote: >> >> KARP will focus on an abstraction for keying information that describes >> the interface between routing protocols, operators and automated key >> management. Conceptually when routing protocols send or recieve packets >> they will look up the key to use in this abstract key >> table. > > I don't think KARP should specify things in terms of packets - those > abstractions exist at other layers of the stack (transport = segment, > network = packet, link = frame). > > IMO, this should refer to *messages*, and say: > > Conceptually when routing protocols send or receive messages they are > associated with a key in this abstract key table. > > I.e., "associated" could mean (and this might be useful to explain): > > - used by the routing protocol to protect a message > - associated with a session at a lower protocol layer > to protect transfers at that layer > >> ...Conceptually, there will be an interface for a routing protocol >> to make requests of automated key management when it is being used; when >> keys become available they will be made available in the key >> table. There is no requirement that this abstraction be used for >> implementation; the abstraction serves the needs of standardization an >> and management. Specifically as part of the KARP work plan: >> >> 1) KARP will design the key table abstraction and the interface between >> key management protocols and routing protocols. > > And (possibly) security protocols at other layers. > >> 2) For each routing protocol, we will define the mapping between how the >> protocol represents key material and the protocol independent key table >> abstraction. When routing protocols share a common mechanism for >> authentication, such as the TCP Authentication Option, the same mapping >> is likely to be reused between protocols. An implementation may be able >> to move much of the keying logic into code related to this shared >> authentication primitive rather than code specific to routing protocols. >> >> 3) When designing automated key management for both symmetric keys and >> group keys, we will only use the abstractions designed in point 1 above >> to communicate between automated key management and routing protocols. >> _______________________________________________ >> karp mailing list >> karp@ietf.org >> https://www.ietf.org/mailman/listinfo/karp From manav.bhatia@alcatel-lucent.com Thu Nov 17 21:15:43 2011 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 6551B11E80B2 for ; Thu, 17 Nov 2011 21:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.663 X-Spam-Level: X-Spam-Status: No, score=-6.663 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUY2XGzJOciY for ; Thu, 17 Nov 2011 21:15:42 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 462E311E8097 for ; Thu, 17 Nov 2011 21:15:42 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id pAI5FWTP015390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Nov 2011 23:15:38 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pAI5FVmA002466 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 18 Nov 2011 10:45:31 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Fri, 18 Nov 2011 10:45:31 +0530 From: "Bhatia, Manav (Manav)" To: RJ Atkinson , "karp@ietf.org" Date: Fri, 18 Nov 2011 10:45:39 +0530 Thread-Topic: [karp] Proposed text for design guide Thread-Index: AcylO8PD6lFg3qYkQSSD6UR/Gm/OHgAc9M3A Message-ID: <7C362EEF9C7896468B36C9B79200D8350D012D6A9B@INBANSXCHMBSA1.in.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [karp] Proposed text for design guide 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, 18 Nov 2011 05:15:43 -0000 >=20 > Manav responded here: > =09 > > but with a narrow engineering issue about the bit length of a=20 > particular field, rather than with any objection to the concept > -- and Joel was clearly and precisely asking about the concept alone. Aha. I wasn't responding to Joel's question. I was merely trying to point o= ut that there is work left to be done in the crypto-key-table document. I s= ent my note because Sean has a DISCUSS saying that certain fields used in d= raft-ietf-ospf-auth-trailer-ospfv3 must align with the crypto-key-table doc= ument. I concede that my point would have been clearer if I had chosen to respond = to the right thread. Cheers, Manav > Then Acee responded here: > =09 > > but asked whether there would be a normative reference > to the Key Tables I-D -- which Joel *already* answered > above with "not a normative reference to the specific document". >=20 >=20 > So I don't see either of those notes to the KARP list=20 > as actually responsive to Joel's precise question. >=20 >=20 > The practical reality is that any implementation of routing > protocol authentication using cryptography has to have some=20 > internal form of a key table. The engineering details of > how a particular implementation might code that capability > are both beyond the contents of the current Key Table I-D > and also well beyond the scope of the Design Guide -- as > it should be. >=20 >=20 > However, having an internal key table of some sort is simply > *unavoidable* for any implementation supporting cryptographic=20 > routing authentication. Its existence is mandated by numerous=20 > RFCs, for example RFC-2328 Section D.3 (which I wrote long ago). >=20 >=20 > For the record, I do support a reference to the concept > of a key table and I agree with Joel that a normative > reference to the specific Key Tables I-D is not needed=20 > for the Design Guide. >=20 > Yours, >=20 > Ran >=20 > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > = From internet-drafts@ietf.org Mon Nov 21 07:17:51 2011 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 566751F0C50; Mon, 21 Nov 2011 07:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCdpAzXizwtX; Mon, 21 Nov 2011 07:17:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5EB1F0C36; Mon, 21 Nov 2011 07:17:46 -0800 (PST) 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: 3.64 Message-ID: <20111121151746.21149.28887.idtracker@ietfa.amsl.com> Date: Mon, 21 Nov 2011 07:17:46 -0800 Cc: karp@ietf.org Subject: [karp] I-D Action: draft-ietf-karp-design-guide-08.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, 21 Nov 2011 15:17:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Keying and Authentication for Routing= Protocols Working Group of the IETF. Title : Keying and Authentication for Routing Protocols (KARP) D= esign Guidelines Author(s) : Gregory M. Lebovitz Manav Bhatia Filename : draft-ietf-karp-design-guide-08.txt Pages : 31 Date : 2011-11-21 This document is one of a series concerned with defining a roadmap of protocol specification work for the use of modern cryptographic mechanisms and algorithms for message authentication in routing protocols. In particular, it defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity. = A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-karp-design-guide-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-karp-design-guide-08.txt From bew@cisco.com Mon Nov 21 22:01:20 2011 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 958B521F8BE5 for ; Mon, 21 Nov 2011 22:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-4cWqDEfoP1 for ; Mon, 21 Nov 2011 22:01:20 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0102B21F8BDE for ; Mon, 21 Nov 2011 22:01:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=267; q=dns/txt; s=iport; t=1321941679; x=1323151279; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=7GYqLsnqbaLZHoKYB/dUV8Mo2pez5wC6NhnW6/BdVuI=; b=hX6WlD1+Y4DkotsGV8A0A+BXBwQdmk99JwOEUIbBCkqYql262FlFLQnS mtbUp9mczRlCuwzazOKb9kd4w+BQt4+tBssju9Pb/IdboCAHgxYPAH04C ql0Ena+Zlli2xE9vfHRHy3OkHBxZIO81qlV+QZ27ffzQooWWC6qA1NQ5A 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4FAA06y06rRDoJ/2dsb2JhbABDnwIDi0aBBYILASeCEAkZh2uUd4EmAZ5PhzqCMmMEiBuMJZIp X-IronPort-AV: E=Sophos;i="4.69,551,1315180800"; d="scan'208";a="13894823" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 22 Nov 2011 06:01:19 +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.3/8.14.3) with ESMTP id pAM61JEu026652 for ; Tue, 22 Nov 2011 06:01:19 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Nov 2011 22:01:19 -0800 Message-Id: <381BDD7C-ED2E-47D1-A4AA-22B4BA23E15C@cisco.com> To: karp@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [karp] IETF82 KARP WG minutes X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 06:01:20 -0000 Greetings, The KARP WG minutes have been posted. Many thanks to Richard Graveman = for providing them. Corrections may be sent to the list or to the chairs = . Brian & Joel