From jhaas@slice.pfrc.org Wed May 8 10:54:17 2013 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 10F8D21F8ECB for ; Wed, 8 May 2013 10:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7XbHxryGToJ for ; Wed, 8 May 2013 10:54:12 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5888321F91CB for ; Wed, 8 May 2013 10:54:11 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id D5482C25D; Wed, 8 May 2013 13:54:10 -0400 (EDT) Date: Wed, 8 May 2013 13:54:10 -0400 From: Jeffrey Haas To: karp@ietf.org Message-ID: <20130508175410.GF12732@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [karp] draft-ietf-karp-bfd-analysis-00 comments X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 17:54:17 -0000 I've just read the current version of draft-ietf-karp-bfd-analysis. I have one comment and one question: The draft correctly identifies the potential security implications of predictable BFD session discriminator values. The following text in RFC 5880 attempts to cover this issue: bfd.LocalDiscr The local discriminator for this BFD session, used to uniquely identify it. It MUST be unique across all BFD sessions on this system, and nonzero. It SHOULD be set to a random (but still unique) value to improve security. The value is otherwise outside the scope of this specification. Obviously implementations may make choices that are problematic from a replay standpoint, but I don't believe there is anything to really cover in a new BFD document. Do the authors believe otherwise, or is this primarily pointing out "you know better, don't do that!" It should also be noted that we have two I-Ds as WG documents that cover the other issues noted in this draft: draft-ietf-bfd-hmac-sha and draft-ietf-bfd-generic-crypto-auth. Presuming my analysis of the above is correct (an admonition to do the right thing), this document appears of reasonable quality. Is there an intent to last call it sometime soon? -- Jeff From manav.bhatia@alcatel-lucent.com Wed May 8 17:25:43 2013 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 44ECA21F9104 for ; Wed, 8 May 2013 17:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtQtXEornlWH for ; Wed, 8 May 2013 17:25:37 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8F16321F8EAC for ; Wed, 8 May 2013 17:25:37 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r490PZ9E004155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 8 May 2013 19:25:35 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r490PZJZ011033 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 May 2013 20:25:35 -0400 Received: from SG70XWXCHHUB02.zap.alcatel-lucent.com (135.253.2.47) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 8 May 2013 20:25:35 -0400 Received: from SG70XWXCHMBA01.zap.alcatel-lucent.com ([169.254.1.53]) by SG70XWXCHHUB02.zap.alcatel-lucent.com ([135.253.2.47]) with mapi id 14.02.0247.003; Thu, 9 May 2013 08:25:32 +0800 From: "Bhatia, Manav (Manav)" To: Jeffrey Haas , "karp@ietf.org" Thread-Topic: [karp] draft-ietf-karp-bfd-analysis-00 comments Thread-Index: AQHOTBUSVKEpC/kypkq1TZbgeL0yOZj7/X+w Date: Thu, 9 May 2013 00:25:31 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C3014274@SG70XWXCHMBA01.zap.alcatel-lucent.com> References: <20130508175410.GF12732@pfrc> In-Reply-To: <20130508175410.GF12732@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.17] 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] draft-ietf-karp-bfd-analysis-00 comments X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 00:25:43 -0000 Hi Jeff, Your analysis is correct - the gap analysis doc in the KARP lists the gaps = that exists today when using manual keying. The two IDs that you've mention= ed are still WG documents, and not yet standards and have been mentioned he= re in the gap analysis document. Additionally, I think we should also cover= any new security considerations introduced by BFD over LAGs when using man= ual keying. I haven't thought much over this. Cheers, Manav > -----Original Message----- > From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On=20 > Behalf Of Jeffrey Haas > Sent: Wednesday, May 08, 2013 11:24 PM > To: karp@ietf.org > Subject: [karp] draft-ietf-karp-bfd-analysis-00 comments >=20 > I've just read the current version of=20 > draft-ietf-karp-bfd-analysis. I have one comment and one question: >=20 > The draft correctly identifies the potential security=20 > implications of predictable BFD session discriminator values.=20 > The following text in RFC 5880 attempts to cover this issue: >=20 >=20 > bfd.LocalDiscr >=20 > The local discriminator for this BFD session, used to uniquely > identify it. It MUST be unique across all BFD sessions on this > system, and nonzero. It SHOULD be set to a random (but still > unique) value to improve security. The value is=20 > otherwise outside > the scope of this specification. >=20 > Obviously implementations may make choices that are problematic from a > replay standpoint, but I don't believe there is anything to=20 > really cover in > a new BFD document. Do the authors believe otherwise, or is=20 > this primarily > pointing out "you know better, don't do that!" >=20 > It should also be noted that we have two I-Ds as WG documents=20 > that cover the > other issues noted in this draft: draft-ietf-bfd-hmac-sha and > draft-ietf-bfd-generic-crypto-auth. >=20 > Presuming my analysis of the above is correct (an admonition=20 > to do the right > thing), this document appears of reasonable quality. Is=20 > there an intent to > last call it sometime soon? >=20 > -- Jeff > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > = From jhaas@slice.pfrc.org Fri May 10 09:24:16 2013 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 B037E21F8F53 for ; Fri, 10 May 2013 09:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNfM3gwDPWBy for ; Fri, 10 May 2013 09:24:11 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A752721F8A7B for ; Fri, 10 May 2013 09:24:11 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6F2B6C27A; Fri, 10 May 2013 12:24:11 -0400 (EDT) Date: Fri, 10 May 2013 12:24:11 -0400 From: Jeffrey Haas To: "Bhatia, Manav (Manav)" Message-ID: <20130510162411.GW12732@pfrc> References: <20130508175410.GF12732@pfrc> <20211F91F544D247976D84C5D778A4C3014274@SG70XWXCHMBA01.zap.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211F91F544D247976D84C5D778A4C3014274@SG70XWXCHMBA01.zap.alcatel-lucent.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "karp@ietf.org" Subject: Re: [karp] draft-ietf-karp-bfd-analysis-00 comments X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 16:24:16 -0000 Manav, On Thu, May 09, 2013 at 12:25:31AM +0000, Bhatia, Manav (Manav) wrote: > Additionally, I think we should also cover any new security considerations > introduced by BFD over LAGs when using manual keying. I haven't thought > much over this. Given that the use case for BFD over LAG is directly connected links without even an underyling switch, I suspect the existing single-hop analysis is probably applicable. -- Jeff From jmh@joelhalpern.com Mon May 13 14:23:05 2013 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 40A0B21F93EE; Mon, 13 May 2013 14:23:05 -0700 (PDT) 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 zOJSu7eh8zZW; Mon, 13 May 2013 14:22:59 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADE621F92BC; Mon, 13 May 2013 14:22:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 418911D25EF; Mon, 13 May 2013 14:22:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-209.clppva.east.verizon.net [70.106.134.209]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id B790D1C0463; Mon, 13 May 2013 14:22:57 -0700 (PDT) Message-ID: <519159A3.5080107@joelhalpern.com> Date: Mon, 13 May 2013 17:22:43 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "karp@ietf.org" , "lisp@ietf.org" References: <7ABACB5F-A36C-4F07-801E-585FFEA50CD5@verisign.com> In-Reply-To: <7ABACB5F-A36C-4F07-801E-585FFEA50CD5@verisign.com> X-Forwarded-Message-Id: <7ABACB5F-A36C-4F07-801E-585FFEA50CD5@verisign.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [karp] Fwd: NomCom 2013-2014 Call for Volunteers 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, 13 May 2013 21:23:05 -0000 If you are eligible (and if chosen willing to forgo appointment), please volunteer. Thank you, Joel -------- Original Message -------- Subject: NomCom 2013-2014 Call for Volunteers Date: Mon, 13 May 2013 21:08:59 +0000 From: Mankin, Allison To: ietf-announce@ietf.org The IETF nominating committee (nomcom) process for 2010-11 has begun. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. This year, a challenge: let's get beyond the 100-mark for number of volunteers. Let's get to 200 volunteers! The details of the operation of the nomcom can be found in RFC 3777. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended three are IETF 82, 83, 84, 85, 86. If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Chris Griffiths IAB: Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG: Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) The primary activity for this nomcom will begin in July 2013 and should be completed in January 2014. The nomcom will have regularly scheduled conference calls to ensure progress. There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment. Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours) June 16, 2013, as follows: To: amankin@verisign.com Subject: Nomcom 2013-14 Volunteer Please include the following information in the email body: // First/Given Name followed by Last/Family Name // matching how you enter it in the IETF Registration Form) // Typically what goes in the Company field // in the IETF Registration Form [] // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Volunteering for the nomcom is a great way to contribute to the IETF! I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you! Allison Mankin amankin@verisign.com P.S. Because the 2012-2013 nomcom is still at work, we cannot use the ietf addresses for the nomcom chair or the nomcom committee yet, so please send all volunteer mail (and any questions/comments you may have) to the address given. From jmh@joelhalpern.com Mon May 13 15:10:17 2013 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 2FC5521F8630; Mon, 13 May 2013 15:10:17 -0700 (PDT) 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=[AWL=0.000, 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 jPNX58ZEqkpz; Mon, 13 May 2013 15:10:11 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 63A9121F8D8E; Mon, 13 May 2013 15:10:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 3DF671C084F; Mon, 13 May 2013 15:10:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-209.clppva.east.verizon.net [70.106.134.209]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id D3D771C07A1; Mon, 13 May 2013 15:10:08 -0700 (PDT) Message-ID: <519164B1.7020900@joelhalpern.com> Date: Mon, 13 May 2013 18:09:53 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "karp@ietf.org" , "lisp@ietf.org" References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [karp] Fwd: NomCom 2013-2014 Call for Volunteers - CORRECTED dates in first sentence 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, 13 May 2013 22:10:17 -0000 As per my previous email, with corrected dates for forms sake: -------- Original Message -------- Subject: NomCom 2013-2014 Call for Volunteers - CORRECTED dates in first sentence Date: Mon, 13 May 2013 21:27:21 +0000 From: Mankin, Allison To: ietf-announce@ietf.org The IETF nominating committee (nomcom) process for 2013-14 has begun. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. This year, a challenge: let's get beyond the 100-mark for number of volunteers. Let's get to 200 volunteers! The details of the operation of the nomcom can be found in RFC 3777. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended three are IETF 82, 83, 84, 85, 86. If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Chris Griffiths IAB: Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG: Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) The primary activity for this nomcom will begin in July 2013 and should be completed in January 2014. The nomcom will have regularly scheduled conference calls to ensure progress. There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment. Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours) June 16, 2013, as follows: To: amankin@verisign.com Subject: Nomcom 2013-14 Volunteer Please include the following information in the email body: // First/Given Name followed by Last/Family Name // matching how you enter it in the IETF Registration Form) // Typically what goes in the Company field // in the IETF Registration Form [] // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Volunteering for the nomcom is a great way to contribute to the IETF! I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you! Allison Mankin amankin@verisign.com P.S. Because the 2012-2013 nomcom is still at work, we cannot use the ietf addresses for the nomcom chair or the nomcom committee yet, so please send all the volunteer mail (and any questions/comments you may have) to the address given. From hartmans@mit.edu Mon May 20 10:04:45 2013 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 94C1621F9206 for ; Mon, 20 May 2013 10:04:45 -0700 (PDT) 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 Wgf8H+314Bow for ; Mon, 20 May 2013 10:04:40 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 8356921F9050 for ; Mon, 20 May 2013 10:04:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 296C720607; Mon, 20 May 2013 13:01:44 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwTZQtlSY_Rg; Mon, 20 May 2013 13:01:43 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 20 May 2013 13:01:43 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0D3F2440B; Mon, 20 May 2013 13:04:38 -0400 (EDT) From: Sam Hartman To: Uma Chunduri References: <67832B1175062E48926BF3CB27C49B240C8C7837@xmb-aln-x12.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD5923042D13FDBA@PRVPEXVS15.corp.twcable.com> <1B502206DFA0C544B7A604691520086305F61947@eusaamb105.ericsson.se> Date: Mon, 20 May 2013 13:04:38 -0400 In-Reply-To: <1B502206DFA0C544B7A604691520086305F61947@eusaamb105.ericsson.se> (Uma Chunduri's message of "Mon, 15 Apr 2013 21:11:19 +0000") 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: "draft-ietf-karp-ops-model@tools.ietf.org" , "karp@ietf.org" Subject: Re: [karp] [OPSEC] FW: WG LC: draft-ietf-karp-ops-model-05 to Informational 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, 20 May 2013 17:04:45 -0000 Hi. i've added text to an upcoming document to address your small issues. Thanks for the comments. From internet-drafts@ietf.org Mon May 20 17:13:45 2013 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 2F29F21F96F7; Mon, 20 May 2013 17:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 FxnqYo1QN38f; Mon, 20 May 2013 17:13:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A54A121F90BB; Mon, 20 May 2013 17:13:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130521001344.24252.39669.idtracker@ietfa.amsl.com> Date: Mon, 20 May 2013 17:13:44 -0700 Cc: karp@ietf.org Subject: [karp] I-D Action: draft-ietf-karp-ops-model-06.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 00:13:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Keying and Authentication for Routing Pro= tocols Working Group of the IETF. Title : Operations Model for Router Keying Author(s) : Sam Hartman Dacheng Zhang Filename : draft-ietf-karp-ops-model-06.txt Pages : 23 Date : 2013-05-20 Abstract: Developing an operational and management model for routing protocol security that works across protocols will be critical to the success of routing protocol security efforts. This document discusses issues and begins to consider development of these models. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-karp-ops-model There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-karp-ops-model-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-karp-ops-model-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hartmans@mit.edu Mon May 20 17:28:33 2013 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 52F3221F9711 for ; Mon, 20 May 2013 17:28:33 -0700 (PDT) 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=[AWL=0.000, 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 z5gYBtIESAAX for ; Mon, 20 May 2013 17:28:27 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF4721F9721 for ; Mon, 20 May 2013 17:28:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9F18F2060A for ; Mon, 20 May 2013 20:25:30 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kubBdxpjF7vx for ; Mon, 20 May 2013 20:25:30 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for ; Mon, 20 May 2013 20:25:30 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EB7AC440B; Mon, 20 May 2013 20:28:24 -0400 (EDT) From: Sam Hartman To: karp@ietf.org Date: Mon, 20 May 2013 20:28:24 -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 Subject: [karp] Updated ops model 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, 21 May 2013 00:28:33 -0000 I believe that version 6 addresses all the last call comments we got except for one item. i recieved no proposed text for section 6.1 and already indicated i don't know what people are looking for that fits within the scope of KARP. my preferenc8e is to make no change in 6.1 but i'm happy to review any text suggestions that come up. From hartmans@painless-security.com Tue May 21 05:29:54 2013 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 71C3321F8CEC for ; Tue, 21 May 2013 05:29:54 -0700 (PDT) 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 W6DtJP4GhE8M for ; Tue, 21 May 2013 05:29:49 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6459921F85F4 for ; Tue, 21 May 2013 05:29:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 3A27120608 for ; Tue, 21 May 2013 08:26:52 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4waf7l3sIzqX for ; Tue, 21 May 2013 08:26:51 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for ; Tue, 21 May 2013 08:26:51 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 09E8A440B; Tue, 21 May 2013 08:29:46 -0400 (EDT) From: Sam Hartman To: karp@ietf.org Date: Tue, 21 May 2013 08:29:45 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: [karp] rt-dir review of draft-ietf-karp-crypto-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: Tue, 21 May 2013 12:29:54 -0000 --=-=-= I've already written back indicating that i don't think we want to change the scope of this document or of the KARP working group. As such, I don't think we want to address issues 1 and 6 Similar i'm sure we're correct with regard to issue 7. I'll propose comments on some of the other issues in follow-ups to this message. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from mail.painless-security.com ([unix socket]) by mail.suchdamage.org (Cyrus v2.4.16-Debian-2.4.16-4) with LMTPA; Sun, 12 May 2013 16:11:45 -0400 X-Sieve: CMU Sieve 2.4 Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 311662048D for ; Sun, 12 May 2013 16:11:45 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6S4BJM6o71b for ; Sun, 12 May 2013 16:11:43 -0400 (EDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.painless-security.com (Postfix) with ESMTPS for ; Sun, 12 May 2013 16:11:42 -0400 (EDT) Received: from asmtp2.iomartmail.com ([62.128.201.249]:50248) by grenache.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Ubcen-0000S5-QI for draft-ietf-karp-crypto-key-table.all@tools.ietf.org; Sun, 12 May 2013 22:14:11 +0200 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4CKDwBU027482; Sun, 12 May 2013 21:13:58 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4CKDsje027461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 12 May 2013 21:13:55 +0100 Reply-To: From: "Adrian Farrel" To: Cc: , "'Danny McPherson'" References: In-Reply-To: Date: Sun, 12 May 2013 21:13:54 +0100 Message-ID: <00d701ce4f4d$3bc9cc80$b35d6580$@olddog.co.uk> X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIZQHEifWRr9rkK4Fbzg/QpL8iQkQLAth9GmFYS3wA= Content-Language: en-gb X-SA-Exim-Connect-IP: 62.128.201.249 X-SA-Exim-Rcpt-To: draft-ietf-karp-crypto-key-table.all@tools.ietf.org X-SA-Exim-Mail-From: adrian@olddog.co.uk Subject: FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on grenache.tools.ietf.org) Resent-To: bew@cisco.com,, hartmans@painless-security.com, housley@vigilsec.com, jmh@joelhalpern.com, stewart@g3ysx.org.uk, tim.polk@nist.gov, zhangdacheng@huawei.com List-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===-=-=" --===-=-= Content-Type: text/plain; charset=utf-8 All, I am attaching Danny's routing directorate review of your draft. Please read his note below. As IETF last call has completed, you do not need to heed these comments in the same way as you might for comments coming during IETF last call. However, the ADs will be sifting through what Danny has written and potentially adding issues he raises to our Discusses/Comments. In view of that, you may feel it wise to read what he has written and see whether you are moved to answer his questions and maybe update the text. Thanks, Adrian > -----Original Message----- > From: Danny McPherson [mailto:danny@tcb.net] > Sent: 12 May 2013 20:57 > To: BRUNGARD, DEBORAH A > Cc: stbryant@cisco.com; adrian@olddog.co.uk; Dan Li > (huawei.danli@huawei.com) > Subject: Re: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table > > Review attached, apologies for the latency. Also, I'm sending this > without a full review of the review so if anything seems abrasive it > wasn't meant to be.. > > Thanks, > > -danny --===-=-= Content-Type: text/plain; name=rtgdir-review-draft-ietf-karp-crypto-key-table.txt Content-Disposition: attachment; filename=rtgdir-review-draft-ietf-karp-crypto-key-table.txt Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other comments that you receive, and strive to resolve them through discussion or by updating the draft as appropriate. Document: http://tools.ietf.org/html/draft-ietf-karp-crypto-key-table-07 Reviewer: Danny McPherson Review Date: 08 MAY 2013 Intended Status: Standards Track There is at least one major issue with this document, as it is now written. Comments/Questions: =================== 1) This document specifically restricts itself to only ever talking about symmetric keys, and therefore it is not going to work for public key crypto approaches like RPKI/BGPSEC. If the objective is "Keying and Authentication for routing protocols (not just *routed* protocols) then not accommodating BGP would seem to miss the mark. An array of mechanisms to get keys into routers and store them for a lot of different purposes is precisely one of the reasons why folks don't update keys or perform more authentication functions today. 2) As a Standards Track document it feels entirely too generic. It should employ some specific example usages to illustrate its efficacy and refine its inadequacies, the current "boil the ocean" leaves me wonder what's actually to be implemented from this ID. 3) There is a clear need to discuss proper time synchronization that is conspicuously missing, and this seems the type of place to tackle it rather than avoiding the topic.. 4) There is _no_ error handling recommendations, and plenty of failure modes. 5) There are lots of instances where you might have multiple sessions (link local, IGP, or EGP) between a single peer (e.g., BGP multisession or diverse path) that MAY employ different credentials, this model doesn't seem to accommodate this at all. 6) What about use for authentication data of other sorts? E.g., NTP or SNMP, or L2TPv3, or other types of PWs, etc..? If we're going to define a generic model shouldn't it accommodate those? 7) S.2 text suggests multiple times that "many routing protocols restrict their key names to integers that can be represented in 16 or 32 bits." Is this really the case? Are there ANY that restrict their key *names* to 32 bits today? This really doesn't afford much in the way of operator usability and mnemonic values, etc.. Specific comments: 1) Section 2 starts off by talking about if/when long-lived keys will be reused... It says ``hopefully'' they won't be... Is there a recommendaiton to reference (or provide) here or just well placed aspirations? :-) 2) Section 2 talks about ``ProtocolSpecificInfo'' but stays super vague... not even an example. I would suggest something be provided to demonstrate how this field would be used (or motivate its existence). We don't want it to wind up being used to store plain-text passphrases! 3) Section 2 opens Pandora's box with the SendLifetime[Start|End]/AcceptedLifetime[Start|End]. The inevitability of peers losing time sync w/o a systemic solution (e.g., NTP/TICTOC/Other) is glossed over. Routers would, without persistent sync, eventually stop being able to talk to each other. At no point in the draft is there any discussion of how protocol errors are handled in routing or routed protocols. So, if I'm a sender, and suddenly my receiver can't sync w/ me, then I have no error message to use to debug. Having dealt with this before, I can tell you that it is _no_fun_! Also, this is clearly not just for adjacent peers, as BGP , LSPs, LSAs, etc.. are all preserved multi-hop. Some taxonomy for routed v. routing (session v. multi-hop messages) might be useful here. I think some of the other KARP work touches on this a bit, perhaps references and application are in order? 4) Section 3 the key selection protocol seems a little too generic to be useful... Pre-canning algorithm preference as the first choice seems to miss other degrees of freedom that might be very application specific. Also, I wonder if (as this protocol might evolve) there would be contention between peers in which one would _presume_ a certain algo preference order, but the other might implement a different choice? The point is, codifying that there is a mandate here seems optimistic and reaching, shouldn't that be done in the corresponding protocol specifications?. 5) Section 6's operational considerations seems like a very under powered provision for the need for time synchronization between peers. As suggested, this text essentially acknowledges that there is a problem, and offers a wouldbe solution that (by definition) will fail after prolonged clock drift. 6) Section 7 should include a treatise on the dependency this protocol will have on time sync (such as through NTP or something)... NITs: ===== S.2: --- s/will multiple rows will contain/...?/ --- Under the "Peers" definition what's "unicast keys" mean? --- Also, what do you mean by "name a routing area for a multicast routing protocol"? Are you suggesting reference the area or level in LS protocols, or referring to something in PIM-* et al, or something else? Then intention and context here is unclear? --- Recommend replacing "packet" with "message" in *all* such instances? --- As for "Interfaces", the concept of interface groups would likely be valuable here, or perpaps the notion of "router" or "context" level values? This applies to the TCP-AO example where eBGP v. Transit eBGP for internal would all be large numers with lots of overlap, but may vary across sets and perhaps even across AFI/SAFI. --- In the Protocol section here, it's still unclear to me if we're talking about routing or routed protocols, or PWs, or LS updates in LS protocols, etc.. --- I'm kinda surprised there's nothing some akin to a KDF or AlgID registry already. How to those developers no to include their algorithms in this registry now? --- S.3: --- "Outoing packet" v. "message" again? I think we need to be more precise here. --- What does "loosely bound" mean? --- The conditions outlined in key matches would likely benefit considerably from the notion of interface groups or similar (e.g., internal v. external, etc..). --- You talk in this section about how exceeding the lifetime on a particular long-lived key does not have any impact - how do you know this? SHouldn't that be left to the protocol and deployment model? --- The last graf of S.3 about TCP-AO and other protocols using their own DB - did I miss something about what this should be the case? Is this IF they don't want to use this DB, or is there something else here? The current text isn't very helpful in groking the context. --- S.4 talks again a lot about "packets", when I think sometime you mean messages v. packets, but perhaps sometime not? --- References: Russ, I'm a little surprised you use your home address in these.. --- s/when received in a packet./when received in a message./ --===-=-=-- --=-=-=-- From kent@bbn.com Tue May 21 08:59:13 2013 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 B149621F97CD for ; Tue, 21 May 2013 08:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 3qXoaDrOw-ON for ; Tue, 21 May 2013 08:59:09 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 47B4C21F97ED for ; Tue, 21 May 2013 08:59:08 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:52957 helo=COMSEC.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Ueoxv-000HQg-8b for karp@ietf.org; Tue, 21 May 2013 11:59:07 -0400 Message-ID: <519B99CA.9080307@bbn.com> Date: Tue, 21 May 2013 11:59:06 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: karp@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060003050209040906050106" Subject: Re: [karp] rt-dir review of draft-ietf-karp-crypto-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: Tue, 21 May 2013 15:59:13 -0000 This is a multi-part message in MIME format. --------------060003050209040906050106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I agree with Sam that the scope for this doc makes the first comment out of scope. More importantly, the RPKI and BGPSEC are not relevant to the key table design. The former requires no crypto operations on a router. The latter deals with keys for routers, but management of these keys is very different, precisely because they are public keys. Steve ------- On 5/21/13 8:29 AM, Sam Hartman wrote: > I've already written back indicating that i don't think we want to > change the scope of this document or of the KARP working group. > As such, I don't think we want to address issues 1 and 6 > > Similar i'm sure we're correct with regard to issue 7. > > I'll propose comments on some of the other issues in follow-ups to this > message. > > > > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp --------------060003050209040906050106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I agree with Sam that the scope for this doc makes the first comment out of scope.

More importantly, the RPKI and BGPSEC are not relevant to the key table design. The former requires
no crypto operations on a router. The latter deals with keys for routers, but management of these keys
is very different, precisely because they are public keys.

Steve
-------
On 5/21/13 8:29 AM, Sam Hartman wrote:
I've already written back indicating that i don't think we want to
change the scope of this document or of the KARP working group.
As such, I don't think we want to address issues 1 and 6

Similar i'm sure we're correct with regard to issue 7.

I'll propose comments on some of the other issues in follow-ups to this
message.





_______________________________________________
karp mailing list
karp@ietf.org
https://www.ietf.org/mailman/listinfo/karp

--------------060003050209040906050106-- From randy@psg.com Tue May 21 23:56:26 2013 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 7A06121F92B2 for ; Tue, 21 May 2013 23:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 tG-E5nkD7oBo for ; Tue, 21 May 2013 23:56:26 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id B286F21F9232 for ; Tue, 21 May 2013 23:56:25 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Uf2yG-000M5C-Ng; Wed, 22 May 2013 06:56:25 +0000 Date: Wed, 22 May 2013 15:56:22 +0900 Message-ID: From: Randy Bush To: Stephen Kent In-Reply-To: <519B99CA.9080307@bbn.com> References: <519B99CA.9080307@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: karp@ietf.org Subject: Re: [karp] rt-dir review of draft-ietf-karp-crypto-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: Wed, 22 May 2013 06:56:26 -0000 > More importantly, the RPKI and BGPSEC are not relevant to the key > table design. The former requires no crypto operations on a > router. The latter deals with keys for routers, but management of > these keys is very different, precisely because they are public keys. that last clause is false. in bgpsec, the router has at least one private key so that it can sign announcements. i am scratching my head on whether a karp table entry could be helpful in the use of bgpsec keys, and have not found a clear need. but this could be my fault. randy From kent@bbn.com Wed May 22 08:39:36 2013 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 A21A221F93B7 for ; Wed, 22 May 2013 08:39:36 -0700 (PDT) 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=[AWL=0.000, 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 83+yGMGatAGo for ; Wed, 22 May 2013 08:39:30 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id CB0A621F93FC for ; Wed, 22 May 2013 08:39:27 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:36501 helo=COMSEC.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UfB8P-000Chq-U7; Wed, 22 May 2013 11:39:26 -0400 Message-ID: <519CE6AE.3000102@bbn.com> Date: Wed, 22 May 2013 11:39:26 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Randy Bush References: <519B99CA.9080307@bbn.com> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: karp@ietf.org Subject: Re: [karp] rt-dir review of draft-ietf-karp-crypto-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: Wed, 22 May 2013 15:39:36 -0000 Randy, You're right that each BGPSEC router has a private key. However, the key table is designed to manage key rollover for keys that are shared on a pairwise basis. The private router key does not have that property, so it seems a bad fit. I should have been more precise in my reply. Steve >> More importantly, the RPKI and BGPSEC are not relevant to the key >> table design. The former requires no crypto operations on a >> router. The latter deals with keys for routers, but management of >> these keys is very different, precisely because they are public keys. > that last clause is false. in bgpsec, the router has at least one > private key so that it can sign announcements. > > i am scratching my head on whether a karp table entry could be helpful > in the use of bgpsec keys, and have not found a clear need. but this > could be my fault. > > randy > From jmh@joelhalpern.com Thu May 23 12:06:07 2013 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 0DF1F21F982A; Thu, 23 May 2013 12:06:07 -0700 (PDT) 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=[AWL=0.000, 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 Xvt1fGsbhhNM; Thu, 23 May 2013 12:05:53 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 6826221F972E; Thu, 23 May 2013 11:41:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 44E1E1D2627; Thu, 23 May 2013 11:41:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-160.clppva.east.verizon.net [70.106.134.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 617F11D2613; Thu, 23 May 2013 11:41:11 -0700 (PDT) Message-ID: <519E62C4.5080607@joelhalpern.com> Date: Thu, 23 May 2013 14:41:08 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "karp@ietf.org" , "lisp@ietf.org" References: <20130523155412.29158.24895.idtracker@ietfa.amsl.com> In-Reply-To: <20130523155412.29158.24895.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130523155412.29158.24895.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [karp] Fwd: IETF Meeting in South America 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, 23 May 2013 19:06:07 -0000 For tose who care about meeting locations, and do not read IETF Announce or IETF Discuss. Yours, Joel -------- Original Message -------- Subject: IETF Meeting in South America Date: Thu, 23 May 2013 08:54:12 -0700 From: The IAOC To: IETF Announcement List CC: ietf@ietf.org As you may know the IAOC has been investigating the feasibility of having an IETF meeting in South America. There was a site visit to South America last February. We have found two venues that we believe will support a successful IETF meeting and we would like to get feedback from the community. The venues are in Buenos Aires. They meet our requirements for the meeting space, networking, nearby restaurants and bars, hotel room rates in the mid $200 dollar range, nearby alternate hotels at a broad range of prices, nice area in the city, safe, direct international flights, and accessible visas. The IAOC thinks we could have a successful IETF meeting in Buenos Aires and that attendees would like the venues. There has been a consistent level of IETF participation from South and Central America, and it has been growing since IETF82. The data on this is posted at http://iaoc.ietf.org/documents/IETF-Regional-Attendance-00.pdf. The current meeting regional rotation (announced at IETF79) allows for an occasional IETF meeting outside of our main regions (Europe, North America, Asia/Pacific). IETF standards are made more valuable the more relevant they are and the more uptake they get. IETF standards are also made more robust when all perspectives are represented during their development. Encouraging growing participation will help strengthen the Internet, further encourage participation from those areas that will see the most growth in the coming years, and will help advance the IETF in political and international circles which is becoming more of an imperative. We have asked the IESG for their feedback and they are supportive of a meeting in South America if there is community support and active participants attend. Things to consider are that it will be a long trip for the majority of IETFers and the air fares are more expensive (about 10% to 20% higher than average), though restaurants are less expensive. This would be a case where most IETFers would bear more travel pain and expense. The IAOC would like to understand if the IETF community thinks that the IETF should have a meeting in the next few years in Buenos Aires. The IAOC would also like to get feedback on how we can ensure the meeting is as successful as possible and on ways to grow participation in the region. We have set up a survey at https://www.surveymonkey.com/s/NWYLQCD where you can indicate your likelihood of attending, and we encourage you to send your general feedback to the IETF list . Thanks, Bob Hinden IAOC Chair From hartmans@mit.edu Thu May 23 12:45:09 2013 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 880FC21F89A6 for ; Thu, 23 May 2013 12:45:09 -0700 (PDT) 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=[AWL=0.000, 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 PS2uRPaY4tF5 for ; Thu, 23 May 2013 12:44:55 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 0CECC21F972C for ; Thu, 23 May 2013 12:08:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id C132F2061B; Thu, 23 May 2013 15:05:38 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFl-1oncjgHf; Thu, 23 May 2013 15:05:38 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 23 May 2013 15:05:38 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 39545440B; Thu, 23 May 2013 15:08:39 -0400 (EDT) From: Sam Hartman To: Stephen Kent References: <519B99CA.9080307@bbn.com> <519CE6AE.3000102@bbn.com> Date: Thu, 23 May 2013 15:08:39 -0400 In-Reply-To: <519CE6AE.3000102@bbn.com> (Stephen Kent's message of "Wed, 22 May 2013 11:39:26 -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] rt-dir review of draft-ietf-karp-crypto-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, 23 May 2013 19:45:09 -0000 >>>>> "Stephen" == Stephen Kent writes: Stephen> Randy, You're right that each BGPSEC router has a private Stephen> key. However, the key table is designed to manage key Stephen> rollover for keys that are shared on a pairwise basis. The Stephen> private router key does not have that property, so it seems Stephen> a bad fit. I should have been more precise in my reply. Here are some of the reasons I think the key table is a bad fit for managing asymmetric key pairs: * Symmetric key pairs have both a public and private portion. The current key table is designed assuming a single asymmetric key. It doesn't have a concept of a portion of a key row that can be public nor does it have a concept of making sure the public key corresponding to a private key row is available. * You often need additional public information such as certificates (or in some cases CRLs or cached OCSP responses) to provide to a relying party to make an asymmetric key useful. The key table is not designed to manage this information. I don't know much about BGPSEC, but my assumption is that it builds on the RPKI's certificate and key management practices. If so, those practices seem very specialized to build into something like the key table. * The concepts of peers, interfaces, key names and protocol specific information seem inappropriate to private keys. From wwwrun@rfc-editor.org Fri May 24 16:22:02 2013 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 20E2F21F95EC; Fri, 24 May 2013 16:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.411 X-Spam-Level: X-Spam-Status: No, score=-102.411 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 F3B1ExhAq4sQ; Fri, 24 May 2013 16:22:01 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5A10A21F95E9; Fri, 24 May 2013 16:22:01 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7E5FB62113; Fri, 24 May 2013 16:21:19 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130524232119.7E5FB62113@rfc-editor.org> Date: Fri, 24 May 2013 16:21:19 -0700 (PDT) Cc: karp@ietf.org, rfc-editor@rfc-editor.org Subject: [karp] RFC 6952 on Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) 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, 24 May 2013 23:22:02 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6952 Title: Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide Author: M. Jethanandani, K. Patel, L. Zheng Status: Informational Stream: IETF Date: May 2013 Mailbox: mjethanandani@gmail.com, keyupate@cisco.com, vero.zheng@huawei.com Pages: 17 Characters: 37969 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-karp-routing-tcp-analysis-07.txt URL: http://www.rfc-editor.org/rfc/rfc6952.txt This document analyzes TCP-based routing protocols, the Border Gateway Protocol (BGP), the Label Distribution Protocol (LDP), the Path Computation Element Communication Protocol (PCEP), and the Multicast Source Distribution Protocol (MSDP), according to guidelines set forth in Section 4.2 of "Keying and Authentication for Routing Protocols Design Guidelines", RFC 6518. This document is a product of the Keying and Authentication for Routing Protocols Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From kent@bbn.com Tue May 28 09:34:58 2013 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 B18C121F989B for ; Tue, 28 May 2013 09:34:58 -0700 (PDT) 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 BEpmjQIyRxzP for ; Tue, 28 May 2013 09:34:52 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C01E721F9889 for ; Tue, 28 May 2013 09:34:52 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50004) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UhMrJ-000LrU-Uv; Tue, 28 May 2013 12:34:50 -0400 Message-ID: <51A4DCA9.70109@bbn.com> Date: Tue, 28 May 2013 12:34:49 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Sam Hartman References: <519B99CA.9080307@bbn.com> <519CE6AE.3000102@bbn.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: karp@ietf.org Subject: Re: [karp] rt-dir review of draft-ietf-karp-crypto-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: Tue, 28 May 2013 16:34:58 -0000 On 5/23/13 3:08 PM, Sam Hartman wrote: >>>>>> "Stephen" == Stephen Kent writes: > Stephen> Randy, You're right that each BGPSEC router has a private > Stephen> key. However, the key table is designed to manage key > Stephen> rollover for keys that are shared on a pairwise basis. The > Stephen> private router key does not have that property, so it seems > Stephen> a bad fit. I should have been more precise in my reply. > > Here are some of the reasons I think the key table is a bad fit for > managing asymmetric key pairs: > > * Symmetric key pairs have both a public and private portion. asymmetric > The > current key table is designed assuming a single asymmetric key. symmetric > It > doesn't have a concept of a portion of a key row that can be public > nor does it have a concept of making sure the public key corresponding > to a private key row is available. I agree that the key table is not a good fit for these reasons. > * You often need additional public information such as certificates (or > in some cases CRLs or cached OCSP responses) to provide to a relying > party to make an asymmetric key useful. The key table is not designed > to manage this information. I don't know much about BGPSEC, but my > assumption is that it builds on the RPKI's certificate and key > management practices. If so, those practices seem very specialized to > build into something like the key table. more good reasons. Yes, BGPSEC makes use of the RPKI for distribution of certs and CRLs for router keys. > * The concepts of peers, interfaces, key names and protocol specific > information seem inappropriate to private keys. secret Yes, BGPSEC router keys are neither peer nor interface-specific. Steve From jmh@joelhalpern.com Wed May 29 15:54:00 2013 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 AA60221F971C; Wed, 29 May 2013 15:54:00 -0700 (PDT) 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=[AWL=0.000, 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 sQB7C2TgF9BS; Wed, 29 May 2013 15:53:54 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id B1E7121F9712; Wed, 29 May 2013 15:53:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 9ED421C046B; Wed, 29 May 2013 15:53:52 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-119.clppva.east.verizon.net [70.106.134.119]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id C6BA71C06E9; Wed, 29 May 2013 15:53:51 -0700 (PDT) Message-ID: <51A686FC.9070704@joelhalpern.com> Date: Wed, 29 May 2013 18:53:48 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "karp@ietf.org" , "lisp@ietf.org" References: <639CE511-1B0E-47D8-9D9D-1A48964467E2@verisign.com> In-Reply-To: <639CE511-1B0E-47D8-9D9D-1A48964467E2@verisign.com> X-Forwarded-Message-Id: <639CE511-1B0E-47D8-9D9D-1A48964467E2@verisign.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [karp] Fwd: Oooops CORRECTION Reply to This - Re: Nomcom 2013-14 Volunteering - 2nd Call 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, 29 May 2013 22:54:00 -0000 For those of you who did not get the message the first time... Yours, Joel -------- Original Message -------- Subject: Oooops CORRECTION Reply to This - Re: Nomcom 2013-14 Volunteering - 2nd Call Date: Wed, 29 May 2013 21:08:56 +0000 From: Mankin, Allison Reply-To: Mankin, Allison To: ietf-announce@ietf.org CC: Sorry - my eye was on entering the reply-to field and then I forgot....apologies in advance for pain that may result from this lapse. On May 29, 2013, at 5:04 PM, "Mankin, Allison" wrote: > Hi, everyone, > > Remember that I'm challenging the IETF to come up with 200 volunteers for > the upcoming nomcom. You can volunteer just by hitting Reply to this email. > > What are you waiting for?? The more volunteers we get, the better chance we > have of choosing a random yet representative cross section of the IETF > population. Respond to the 200-volunteer challenge and hit Reply right now. > (Well, much as I want you to do this, please look below at the posts being > filled and be sure you are willing to forgo trying for any of them this year). > > The official information: > The IETF nominating committee (nomcom) process for 2013-14 is under way. The > IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, > and the IESG. Ten voting members for the nomcom are selected in a verifiably > random way from a pool of volunteers. > > The details of the selection and operation of the nomcom can be found > in RFCs 3777, 5078, 5633, 5680, and 6859. Four of those RFCs (3777, 5633, > 5680 and 6859) comprise BCP 10. We will also reference RFC 3797. > > Volunteers must have attended 3 of the past 5 IETF meetings. As specified in > RFC 3777, that means three out of the five past meetings up to the time this > email announcement goes out to start the solicitation of volunteers. The five > meetings out of which you must have attended three are IETF 82, 83, 84, 85, 86. > > If you qualify, reply to this email and volunteer. > > The list of people and posts whose terms end with the March 2014 IETF > meeting, and thus the positions for which this nomcom is responsible, are > IAOC: > Chris Griffiths > > IAB: > Bernard Aboba > Marc Blanchet > Ross Callon > Eliot Lear > Hannes Tschofenig > > IESG: > Barry Leiba (Applications) > Brian Haberman (Internet) > Benoit Claise (Operations and Management) > Gonzalo Camarillo (RAI) > Stewart Bryant (Routing) > Sean Turner (Security) > Martin Stiemerling (Transport) > > The primary activity for this nomcom will begin in July 2013 and should be > completed in January 2014. Being a nomcom member will require some time > commitment - there will be interviews with candidates at meetings, regularly > scheduled conference calls to ensure progress, collection and review of > requirements from the commitment, review of candidate questionnaires and > of community feedback. A more detailed timetable for the nomcom tasks > will appear soon. > > Please respond to this email before 11:59 pm EDT (UTC -4 hours) > June 16, 2013. In the body include: > 1. your Given Name as you enter it when you register for the IETF > 2. your Family Name as you enter it when you register for the IETF > 3. your current primary affilation (the information you enter into the Company field) > 4. any/all email addresses you've used to register for IETF meetings > 5. which email address you prefer > 6. your phone number (for our use in confirming you if selected). > > You should expect an email response from me within 3 business days stating > whether or not you are qualified (and added to the list). If you don't receive this > response, please re-send your email adding the tag "RESEND" to the subject line. > > Participating in the IETF nomcom is a meaningful and fun way to contribute to the IETF. > Please help us meet the 200-volunteer challenge by hitting Reply to this message today. > > Allison > > Allison Mankin > Nomcom Chair 2013-2014