From jmh@joelhalpern.com Mon Jul 4 10:40: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 B901C1F0C88; Mon, 4 Jul 2011 10:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -82.1 X-Spam-Level: X-Spam-Status: No, score=-82.1 tagged_above=-999 required=5 tests=[BAYES_99=3.5, J_CHICKENPOX_23=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_48=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_75=0.6, J_CHICKENPOX_82=0.6, J_CHICKENPOX_83=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tytIfLH6uxKt; Mon, 4 Jul 2011 10:40:11 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id DF5471F0C68; Mon, 4 Jul 2011 10:40:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id C367F324764D; Mon, 4 Jul 2011 10:39:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.1.18] (pool-96-245-82-167.phlapa.fios.verizon.net [96.245.82.167]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 67C823228BEB; Mon, 4 Jul 2011 10:39:41 -0700 (PDT) Message-ID: <4E11FADC.8090702@joelhalpern.com> Date: Mon, 04 Jul 2011 13:39:40 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "lisp@ietf.org" , "karp@ietf.org" Content-Type: multipart/mixed; boundary="------------070006080302070807030003" Subject: [karp] Fwd: Nomcom 2011-2012: Third 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, 04 Jul 2011 17:40:12 -0000 This is a multi-part message in MIME format. --------------070006080302070807030003 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit -------- Original Message -------- Subject: Nomcom 2011-2012: Third Call for Volunteers Date: Mon, 4 Jul 2011 08:47:17 -0700 (PDT) From: NomCom Chair To: IETF Announcement list CC: ietf@ietf.org This is the Third call for Volunteers for the 2011-12 Nomcom. We are almost through the volunteer period so if you are considering volunteering, please do so very soon. We have had a very good response to the initial call for volunteers and I am pleased to report that we have 84 volunteers thus far whose qualifications have been confirmed by the secretariat. I have notified each of these volunteers by email. However, we would like to have many more volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. You have until 11:59 pm EDT July 10, 2011 to volunteer for Nomcom but it would be much better if you can volunteer as early as possible. If you volunteered before 09:00 EDT on June 29 to serve as a voting member and have not received a confirmation email from me, please re-submit and bring to my attention right away! Details about the process for volunteering for the Nomcom and the list of open positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2938/ The 84 volunteers who have thus far been qualified by the secretariat are: Alia Atlas,Juniper Networks Lixia Zhang,UCLA Wassim Haddad ,Ericsson Glen Zorn,Network Zen Richard Barnes,BBN Technologies Stephen Kent,BBN Technologies Scott Mansfield,Ericsson Tina TSOU (Ting ZOU),FutureWei Technologies Fernando Gont,UTN/FRH Karen Seo,BBN Technologies Jie Dong,Huawei Technologies Mach Chen,Huawei Technologies Co. Ltd. Sheng Jiang,Huawei Technologies Co. Ltd. Dimitri Papadimitriou,Alcatel-Lucent Thomas D. Nadeau,CA Technologies David Meyer,Cisco Systems/University of Oregon Wesley George,Time Warner Cable Cullen Jennings,Cisco Stephen Hanna,Juniper Networks Stephan Wenger,Bidyo Inc. Keyur Patel,Cisco Systems Michael (Mike) Hamilton,BreakingPoint Systems Behcet Sarikaya,Huawei USA Mark Townsley,Cisco Systems Fred Baker,Cisco Systems Brian Trammell,ETH Zürich Sam Hartman,Painless Security Chris Griffiths,Comcast George Michaelson,APNIC Jiankang Yao,CNNIC Sohel Khan,Comcast Dacheng Zhang,Huawei Lianshu Zheng,Huawei Technologies Hui Deng,China Mobile Gang Chen,China Mobile Mirja Kühlewind,University of Stuttgart IKR John E Drake,Juniper Networks Matt Lepinski,BBN Technologies Subir Das,Telcordia Technologies Inc Yi Zhao,Huawei John Scudder,Juniper Networks Christer Holmberg,LM Ericsson Teemu Savolainen,Nokia Samita Chakrabarti,Ericsson Jaap Akkerhuis,NLnet labs Jason Weil,Time Warner Cable Randy Bush,Internet Initiative Japan Christian Schmidt,Nokia Siemens Networks Sean Shen,CNNIC Lou Berger,LabN Consulting L.L.C. Donald Eastlake,Huawei Xiaohu Xu,Huawei Technologies co. Ltd. Börje Ohlman,Ericsson Deborah Brungard,AT&T Magnus Westerlund,Ericsson Zhen Cao,China Mobile Hadriel Kaplan,Acme Packet Lilla Dovner,Ericsson John Jason Brzozowski,Comcast Jonne Soininen,Renesas Mobile Javier Ubillos,Swedish Institute of Computer Science Eric Gray,Ericsson Thomas Herbst,Silver Spring Networks Ning Zong,Huawei Technologies Haibin Song,Huawei Technologies Yingjie Gu,Huawei Technologies Hongyu Li,Huawei Technologies Terry Manderson,ICANN Ari Keranen,Ericsson Jouni Korhonen,Nokia Siemens Networks Bhumip Khasnabish,ZTE USA Inc. Dapeng Liu,China Mobile Fangwei Hu,ZTE Corporation Ole Troan,Cisco Pascal Thubert,Cisco Wojciech Dec,Cisco Gunter Van de Velde,Cisco Ning So,Verizon Inc./University of Texas at Dallas Guoman liu,ZTE Simon Pietro Romano,Meetecho/University of Napoli Luca Martini,Cisco Bill VerSteeg,Cisco Toerless Eckert,Cisco Systems Joseph Salowey,Cisco Systems The primary activity for this nomcom will begin during IETF-81 in Quebec City and should be completed by January 2012. The nomcom will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. Please volunteer by sending an email to me before 11:59 pm EDT July 10, 2011 as follows: To: suresh.krishnan@ericsson.com Subject: Nomcom 2011-12 Volunteer Please include the following information in the body of the mail: Full Name: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name Current Primary Affiliation: // typically what goes in the Company // field in the IETF Registration Form Email Address(es): // all email addresses used to Register for the // past 5 IETF meetings // Please designate a Preferred email address for // contact if there is more than one email address Telephone number: // With country code (for confirmation if selected) Please expect an email response from me within 3 business days stating whether or not you are qualified. If you do not receive a response in this timeframe, please re-send your email with the tag "RESEND:" added to the subject line. If you are not yet sure you would like to volunteer, please consider that Nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the Nomcom is a good way of contributing in that direction. 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 very soon. Thank you in advance for your participation. Suresh Krishnan Nomcom Chair 2011-2012 Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com --------------070006080302070807030003 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklFVEYt QW5ub3VuY2UgbWFpbGluZyBsaXN0DQpJRVRGLUFubm91bmNlQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lldGYtYW5ub3VuY2UNCg0K --------------070006080302070807030003-- From touch@isi.edu Tue Jul 5 10:42: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 59C7D21F8843; Tue, 5 Jul 2011 10:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.999 X-Spam-Level: X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[AWL=-1.400, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypW-eSwnV0sa; Tue, 5 Jul 2011 10:42:50 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 3239C21F8630; Tue, 5 Jul 2011 10:42:43 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p65HfueJ027950 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 5 Jul 2011 10:41:56 -0700 (PDT) Message-ID: <4E134CE4.5070204@isi.edu> Date: Tue, 05 Jul 2011 10:41:56 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: internet-drafts@ietf.org References: <20110628061627.3026.91639.idtracker@ietfa.amsl.com> In-Reply-To: <20110628061627.3026.91639.idtracker@ietfa.amsl.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, i-d-announce@ietf.org Subject: Re: [karp] I-D Action: draft-ietf-karp-routing-tcp-analysis-00.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, 05 Jul 2011 17:42:51 -0000 FWIW, this doc needs a bit of revision around the TCP MD5 vs. TCP-AO issue, at least. It's simply deficient throughout on this issue, as well as on the details of TCP-AO (e.g., connectionless resets, key rollover, and even the fact that AO doesn't use per-session manual keys). I look forward to a revision that addresses this, as well as more general interactions between transport protocols and routing protocols in this doc. Joe On 6/27/2011 11:16 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Keying and Authentication for Routing Protocols Working Group of the IETF. > > Title : Analysis of BGP, LDP, PCEP, and MSDP Security According to KARP Design Guide > Author(s) : Mahesh Jethanandani > Keyur Patel > Lianshu Zheng > Filename : draft-ietf-karp-routing-tcp-analysis-00.txt > Pages : 16 > Date : 2011-06-27 > > This document analyzes BGP, LDP, PCEP and MSDP according to > guidelines set forth in section 4.2 of > [draft-ietf-karp-design-guide]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-karp-routing-tcp-analysis-00.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-routing-tcp-analysis-00.txt > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp From ananth@cisco.com Tue Jul 5 12:02: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 4767521F857E for ; Tue, 5 Jul 2011 12:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.832 X-Spam-Level: X-Spam-Status: No, score=-9.832 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fi2+ENutvWzE for ; Tue, 5 Jul 2011 12:02:50 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1CC21F8946 for ; Tue, 5 Jul 2011 12:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=2816; q=dns/txt; s=iport; t=1309892528; x=1311102128; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=dL6DTpNZraqWoQE5ZmSvTR0Jb5r1D4DmUY+zenciLFQ=; b=Nv+ikGRp+BuOakO7AnqdqcUW6D/pnr6UyO/hKMFwYP3qk+WFp1mvANIn n5dWI6z3bOTuNi8Q7UE16bg4jG+8uUvadoq6mu/mRgHDzcNPKwMcOzQpT 6tvma2xOIDYGPTs2GEuLI+M4vmI5Zb5LDvWwdsJvxTaG13lTh9CIGyWOo o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAANJeE06rRDoJ/2dsb2JhbABTEJhBjzl3iHqkUJ4AhjYEhz+PeIp+Vw X-IronPort-AV: E=Sophos;i="4.65,481,1304294400"; d="scan'208";a="361623111" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-5.cisco.com with ESMTP; 05 Jul 2011 19:02:08 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p65J28GV029440; Tue, 5 Jul 2011 19:02:08 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Jul 2011 12:02:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Jul 2011 12:02:06 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580D1A7670@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4E134CE4.5070204@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [karp] I-D Action: draft-ietf-karp-routing-tcp-analysis-00.txt Thread-Index: Acw7OxDUHOjvGX4ORmenz970ud6CCwACOwVA References: <20110628061627.3026.91639.idtracker@ietfa.amsl.com> <4E134CE4.5070204@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" X-OriginalArrivalTime: 05 Jul 2011 19:02:08.0150 (UTC) FILETIME=[09965B60:01CC3B46] Cc: karp@ietf.org Subject: Re: [karp] I-D Action: draft-ietf-karp-routing-tcp-analysis-00.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, 05 Jul 2011 19:02:51 -0000 Hi Joe, -----Original Message----- > From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf Of > Joe Touch > Sent: Tuesday, July 05, 2011 10:42 AM > To: internet-drafts@ietf.org > Cc: karp@ietf.org; i-d-announce@ietf.org > Subject: Re: [karp] I-D Action: draft-ietf-karp-routing-tcp-analysis- > 00.txt >=20 > FWIW, this doc needs a bit of revision around the TCP MD5 vs. TCP-AO > issue, at least. >=20 > It's simply deficient throughout on this issue, as well as on the > details of TCP-AO (e.g., connectionless resets, key rollover, and even > the fact that AO doesn't use per-session manual keys). I agree that there would be some scope for some making some elaborate descriptions on each of the above items and spelling out the issues. >=20 > I look forward to a revision that addresses this, as well as more > general interactions between transport protocols and routing protocols > in this doc. Can you paraphrase a bit on what you mean by "general interactions"? For instance : API's, event's, state machine changes can all be construed as "interactions" (direct or in-direct) which I think is out of place for this document. -Anantha >=20 > Joe >=20 > On 6/27/2011 11:16 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Keying and Authentication > for Routing Protocols Working Group of the IETF. > > > > Title : Analysis of BGP, LDP, PCEP, and MSDP Security > According to KARP Design Guide > > Author(s) : Mahesh Jethanandani > > Keyur Patel > > Lianshu Zheng > > Filename : draft-ietf-karp-routing-tcp-analysis-00.txt > > Pages : 16 > > Date : 2011-06-27 > > > > This document analyzes BGP, LDP, PCEP and MSDP according to > > guidelines set forth in section 4.2 of > > [draft-ietf-karp-design-guide]. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-karp-routing-tcp- > analysis-00.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-routing-tcp- > analysis-00.txt > > _______________________________________________ > > 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 touch@isi.edu Tue Jul 5 13:05: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 65AE321F8905 for ; Tue, 5 Jul 2011 13:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.299 X-Spam-Level: X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yyu+7txZpIYR for ; Tue, 5 Jul 2011 13:05:04 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7F62521F8904 for ; Tue, 5 Jul 2011 13:05:04 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p65K4bwF015306 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 5 Jul 2011 13:04:37 -0700 (PDT) Message-ID: <4E136E54.5000207@isi.edu> Date: Tue, 05 Jul 2011 13:04:36 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <20110628061627.3026.91639.idtracker@ietfa.amsl.com> <4E134CE4.5070204@isi.edu> <0C53DCFB700D144284A584F54711EC580D1A7670@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580D1A7670@xmb-sjc-21c.amer.cisco.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] I-D Action: draft-ietf-karp-routing-tcp-analysis-00.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, 05 Jul 2011 20:05:05 -0000 On 7/5/2011 12:02 PM, Anantha Ramaiah (ananth) wrote: > Hi Joe, > > to clutter in-boxes of many users who may not be interested in this > topic] > >> -----Original Message----- >> From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf > Of >> Joe Touch >> Sent: Tuesday, July 05, 2011 10:42 AM >> To: internet-drafts@ietf.org >> Cc: karp@ietf.org; i-d-announce@ietf.org >> Subject: Re: [karp] I-D Action: draft-ietf-karp-routing-tcp-analysis- >> 00.txt >> >> FWIW, this doc needs a bit of revision around the TCP MD5 vs. TCP-AO >> issue, at least. >> >> It's simply deficient throughout on this issue, as well as on the >> details of TCP-AO (e.g., connectionless resets, key rollover, and even >> the fact that AO doesn't use per-session manual keys). > > I agree that there would be some scope for some making some elaborate > descriptions on each of the above items and spelling out the issues. > >> >> I look forward to a revision that addresses this, as well as more >> general interactions between transport protocols and routing protocols >> in this doc. > > Can you paraphrase a bit on what you mean by "general interactions"? For > instance : API's, event's, state machine changes can all be construed as > "interactions" (direct or in-direct) which I think is out of place for > this document. Some routing protocols expect connections to be protected (i.e., they do something when a connection goes down, more than either reestablish the connection or ignore it). Joe > > -Anantha >> >> Joe >> >> On 6/27/2011 11:16 PM, internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Keying and > Authentication >> for Routing Protocols Working Group of the IETF. >>> >>> Title : Analysis of BGP, LDP, PCEP, and MSDP Security >> According to KARP Design Guide >>> Author(s) : Mahesh Jethanandani >>> Keyur Patel >>> Lianshu Zheng >>> Filename : draft-ietf-karp-routing-tcp-analysis-00.txt >>> Pages : 16 >>> Date : 2011-06-27 >>> >>> This document analyzes BGP, LDP, PCEP and MSDP according to >>> guidelines set forth in section 4.2 of >>> [draft-ietf-karp-design-guide]. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-karp-routing-tcp- >> analysis-00.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-routing-tcp- >> analysis-00.txt >>> _______________________________________________ >>> 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 jmh@joelhalpern.com Sun Jul 10 07:10: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 1564E21F86D4; Sun, 10 Jul 2011 07:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBJGGoDu-mDP; Sun, 10 Jul 2011 07:10:40 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id 4D09B21F86D1; Sun, 10 Jul 2011 07:10:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 964D7325BF6D; Sun, 10 Jul 2011 07:10:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-51-16.clppva.btas.verizon.net [71.161.51.16]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 8D1AC3246B60; Sun, 10 Jul 2011 07:10:38 -0700 (PDT) Message-ID: <4E19B2DC.4030003@joelhalpern.com> Date: Sun, 10 Jul 2011 10:10:36 -0400 From: Joel Halpern User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Joe Touch , "karp@ietf.org" , IETF discussion list References: <4E17210A.1070402@joelhalpern.com> <5662A966-70AD-4A63-BA31-8CE1C9635687@cisco.com> <4E1747BB.8080602@cisco.com> In-Reply-To: <4E1747BB.8080602@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [karp] notes from discussion of KARP design guidelines 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, 10 Jul 2011 14:10:41 -0000 Joe, THE KARP WG Chairs have reviewed your comments, in order to figure out what the best way to address them. We would appreciate it if you could engage in discussion of this proposal on the KARP working group email list. If you feel we are still not understanding your point, we would be happy to make some time avaialble for discussion at the WG session in Quebec City. (Comments from anyone else, particularly WG members, on the proposals being made by the WG chairs are appreciated as well.) Rather than a line by line response, we have tried to find the common themes and respond to them. If we have missed major issues, please let us know. You raised concern about the use of the term "on-the-wire." Rather than replace the term, we would prefer to add descriptive text early in the document. This text would note that it is a widely used term in IETF documents, including many RFCs. It would also state for clarity that in this document it is used to refer to the message sent from one routing process to another. With regard to your comment about identifiers, we can add in the description of protocol reviews indications that such reviews should be clear about what IDs the review considers need protecting, as that is important context for the protocol review. As noted in other exchanges, the document abstract needs a complete rewrite. It should be just an abstract, with the rest of the context either removed or moved to the introduction. In doing so, we will add text describing briefly the general concept of the routing protocol transport. In general however, protocol specific behaviors are to be left to the protocol analysis documents. Equally, descriptions of detailed threats will be left either to the threat document or to the individual protocol analysis document as appropriate. There are several items in your comments indicating that you would like to see more discussion in the design guidelines of the protocol layering. That does not seem to be a useful addition to this document. Again, individual protocol analysis documents will deal with that where it is appropriate, and avoid it where it is a distraction. We do not see useful general statements of guidance that can be put into this document. Adding some general text in the discussion of communication modes elaborating on the difference between the communication as seen by the routing and security components, and the actual communication (e.g. that what is seen as multicast may be delivered as broadcast or multiple uni-cast) does seem a helpful addition to the document, and we will do that. Yours, Joel and Brian From bew@cisco.com Tue Jul 12 10:35: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 A6E3621F8D03 for ; Tue, 12 Jul 2011 10:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvLCFZFmo0gP for ; Tue, 12 Jul 2011 10:35:14 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF7F21F8CF7 for ; Tue, 12 Jul 2011 10:35:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=289; q=dns/txt; s=iport; t=1310492114; x=1311701714; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=E8sBFiSjmkS6mGJtjah3B/PP68KNOii7Hn46y6D5AOs=; b=NXhHLNDfl7Y3euoZ7PaRrxZqvl+F0P4rlFxS/wucIkrFxqI8VP/DJPUt Cjs54OnxYlLpXXzeiVbWU1GGBrVLbC2MgKj1h9kbqPjUkGvLNwrBOim8h zUnceHqYMTQt74V8YgKZxVsJJSZI9n3gWu0hsNcMlg3blnFUb1ruOSAmS Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroGALyEHE6rRDoJ/2dsb2JhbABTmDiOeXerQoEinhOFW18Eh1GLC5Br X-IronPort-AV: E=Sophos;i="4.65,521,1304294400"; d="scan'208";a="2231498" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-8.cisco.com with ESMTP; 12 Jul 2011 17:35:10 +0000 Received: from stealth-10-32-244-213.cisco.com (stealth-10-32-244-213.cisco.com [10.32.244.213]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6CHZ9YG003962 for ; Tue, 12 Jul 2011 17:35:10 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jul 2011 10:35:09 -0700 Message-Id: To: karp@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [karp] Call for IETF 81 agenda items (KARP) X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 17:35:14 -0000 Greetings, The KARP WG will be meeting Wednesday afternoon in Quebec City. We have = several WG documents to discuss, as well as design team updates. If you = have an additional topic for the meeting please email the chairs = (karp-chairs@tools.ietf.org). Thanks, Brian & Joel= From touch@isi.edu Tue Jul 12 15:24:25 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 6119121F8C49; Tue, 12 Jul 2011 15:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.62 X-Spam-Level: X-Spam-Status: No, score=-105.62 tagged_above=-999 required=5 tests=[AWL=0.979, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Bfx+e1ifI94; Tue, 12 Jul 2011 15:24:24 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 72CF721F8C47; Tue, 12 Jul 2011 15:24:24 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p6CMNoiP020361 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 12 Jul 2011 15:23:50 -0700 (PDT) Message-ID: <4E1CC976.9000007@isi.edu> Date: Tue, 12 Jul 2011 15:23:50 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Joel Halpern References: <4E17210A.1070402@joelhalpern.com> <5662A966-70AD-4A63-BA31-8CE1C9635687@cisco.com> <4E1747BB.8080602@cisco.com> <4E19B2DC.4030003@joelhalpern.com> In-Reply-To: <4E19B2DC.4030003@joelhalpern.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: IETF discussion list , "karp@ietf.org" Subject: Re: [karp] notes from discussion of KARP design guidelines 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, 12 Jul 2011 22:24:25 -0000 Hi, Joel (et al.), On 7/10/2011 7:10 AM, Joel Halpern wrote: > Joe, > THE KARP WG Chairs have reviewed your comments, in order to figure out > what the best way to address them. We would appreciate it if you could > engage in discussion of this proposal on the KARP working group email > list. If you feel we are still not understanding your point, we would be > happy to make some time avaialble for discussion at the WG session in > Quebec City. (Comments from anyone else, particularly WG members, on the > proposals being made by the WG chairs are appreciated as well.) > > Rather than a line by line response, we have tried to find the common > themes and respond to them. If we have missed major issues, please let > us know. > > You raised concern about the use of the term "on-the-wire." Rather than > replace the term, we would prefer to add descriptive text early in the > document. This text would note that it is a widely used term in IETF > documents, including many RFCs. It would also state for clarity that in > this document it is used to refer to the message sent from one routing > process to another. That's a great example of why this term should be removed. The message sent from one BGP to another is sent *inside* a TCP connection, and nobody would ever call the TCP bytestream payload the message "on the wire". This term is simply sloppy, and just as the security community rightly raises issues with similarly poor use of its terms (e.g., "random" where pseudorandom or arbitrary are intended, or "authenticated" where integrity protection is intended), I consider this a *significant* transport issue. > With regard to your comment about identifiers, we can add in the > description of protocol reviews indications that such reviews should be > clear about what IDs the review considers need protecting, as that is > important context for the protocol review. OK. > As noted in other exchanges, the document abstract needs a complete > rewrite. It should be just an abstract, with the rest of the context > either removed or moved to the introduction. In doing so, we will add > text describing briefly the general concept of the routing protocol > transport. OK. > In general however, protocol specific behaviors are to be left to the > protocol analysis documents. Equally, descriptions of detailed threats > will be left either to the threat document or to the individual protocol > analysis document as appropriate. My goal is to make some transport properties as notable and discussed in as much (or as little) detail as, e.g., multicast and unicast already are in the current document. > There are several items in your comments indicating that you would like > to see more discussion in the design guidelines of the protocol > layering. That does not seem to be a useful addition to this document. > Again, individual protocol analysis documents will deal with that where > it is appropriate, and avoid it where it is a distraction. We do not see > useful general statements of guidance that can be put into this document. As noted above, this is already in the document w.r.t. multicast/unicast; I'm suggesting that it's equally appropriate to include similar discussion of the issues of other layers on routing protocol security. > Adding some general text in the discussion of communication modes > elaborating on the difference between the communication as seen by the > routing and security components, and the actual communication (e.g. that > what is seen as multicast may be delivered as broadcast or multiple > uni-cast) does seem a helpful addition to the document, and we will do > that. I'm not sure if this is basically all I'm asking for; see above. The intent was to add discussion of some known transport issues that are as relevant as the multicast/unicast difference already discussed, in similar detail. Joe From stbryant@cisco.com Tue Jul 12 15:35:33 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 BEC741F0C37; Tue, 12 Jul 2011 15:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.536 X-Spam-Level: X-Spam-Status: No, score=-110.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1j0VNFsDk4w; Tue, 12 Jul 2011 15:35:33 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 846501F0C36; Tue, 12 Jul 2011 15:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=4769; q=dns/txt; s=iport; t=1310510132; x=1311719732; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=XTiWrkE8cE518f7Gy7x8/JEyRrRSC3acpsQ3VHe/gHM=; b=XAgDvJJQQM8SeL++jNN2BkeNADr7z+QRoBrpi25saJ0Q/OSom8T/I4ni +lo7NoCnmrW+w+ccVe7BThvey0dMYH95keFRV+a64HOCBBz1gyR/cxQSr wxxf/pUEPiKToAM5eWuA8WQjG2CzZwRHMV40ufbdFd3A0cuQSnTKCPVXC k=; X-IronPort-AV: E=Sophos;i="4.65,522,1304294400"; d="scan'208";a="42528593" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 12 Jul 2011 22:35:31 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6CMZOcA018654; Tue, 12 Jul 2011 22:35:31 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p6CMZLNR007031; Tue, 12 Jul 2011 23:35:22 +0100 (BST) Message-ID: <4E1CCC76.9090409@cisco.com> Date: Tue, 12 Jul 2011 23:36:38 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Joe Touch References: <4E17210A.1070402@joelhalpern.com> <5662A966-70AD-4A63-BA31-8CE1C9635687@cisco.com> <4E1747BB.8080602@cisco.com> <4E19B2DC.4030003@joelhalpern.com> <4E1CC976.9000007@isi.edu> In-Reply-To: <4E1CC976.9000007@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF discussion list , "karp@ietf.org" Subject: Re: [karp] notes from discussion of KARP design guidelines X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com 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, 12 Jul 2011 22:35:33 -0000 On 12/07/2011 23:23, Joe Touch wrote: > Hi, Joel (et al.), > > On 7/10/2011 7:10 AM, Joel Halpern wrote: >> Joe, >> THE KARP WG Chairs have reviewed your comments, in order to figure out >> what the best way to address them. We would appreciate it if you could >> engage in discussion of this proposal on the KARP working group email >> list. If you feel we are still not understanding your point, we would be >> happy to make some time avaialble for discussion at the WG session in >> Quebec City. (Comments from anyone else, particularly WG members, on the >> proposals being made by the WG chairs are appreciated as well.) >> >> Rather than a line by line response, we have tried to find the common >> themes and respond to them. If we have missed major issues, please let >> us know. >> >> You raised concern about the use of the term "on-the-wire." Rather than >> replace the term, we would prefer to add descriptive text early in the >> document. This text would note that it is a widely used term in IETF >> documents, including many RFCs. It would also state for clarity that in >> this document it is used to refer to the message sent from one routing >> process to another. > > That's a great example of why this term should be removed. The message > sent from one BGP to another is sent *inside* a TCP connection, and > nobody would ever call the TCP bytestream payload the message "on the > wire". > > This term is simply sloppy, and just as the security community rightly > raises issues with similarly poor use of its terms (e.g., "random" > where pseudorandom or arbitrary are intended, or "authenticated" where > integrity protection is intended), I consider this a *significant* > transport issue. Joe Please can you suggest a suitable generic term that covers the set of cases that we need to deal with in routing - i.e. over the MAC, over IP, over UDP and over TCP, so that we can discuss inter routing entity message passing as an abstract operation. As Joel says when we get to the detailed design of each routing protocol we will discuss the details, but we want a high level discussion in this document. Note BTW that 186 RFCs use the term "on the wire" in this sort of situation. - Stewart > >> With regard to your comment about identifiers, we can add in the >> description of protocol reviews indications that such reviews should be >> clear about what IDs the review considers need protecting, as that is >> important context for the protocol review. > > OK. > >> As noted in other exchanges, the document abstract needs a complete >> rewrite. It should be just an abstract, with the rest of the context >> either removed or moved to the introduction. In doing so, we will add >> text describing briefly the general concept of the routing protocol >> transport. > > OK. > >> In general however, protocol specific behaviors are to be left to the >> protocol analysis documents. Equally, descriptions of detailed threats >> will be left either to the threat document or to the individual protocol >> analysis document as appropriate. > > My goal is to make some transport properties as notable and discussed > in as much (or as little) detail as, e.g., multicast and unicast > already are in the current document. > >> There are several items in your comments indicating that you would like >> to see more discussion in the design guidelines of the protocol >> layering. That does not seem to be a useful addition to this document. >> Again, individual protocol analysis documents will deal with that where >> it is appropriate, and avoid it where it is a distraction. We do not see >> useful general statements of guidance that can be put into this >> document. > > As noted above, this is already in the document w.r.t. > multicast/unicast; I'm suggesting that it's equally appropriate to > include similar discussion of the issues of other layers on routing > protocol security. > >> Adding some general text in the discussion of communication modes >> elaborating on the difference between the communication as seen by the >> routing and security components, and the actual communication (e.g. that >> what is seen as multicast may be delivered as broadcast or multiple >> uni-cast) does seem a helpful addition to the document, and we will do >> that. > > I'm not sure if this is basically all I'm asking for; see above. The > intent was to add discussion of some known transport issues that are > as relevant as the multicast/unicast difference already discussed, in > similar detail. > > Joe > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From touch@isi.edu Tue Jul 12 17:27: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 CB81921F85D9; Tue, 12 Jul 2011 17:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.669 X-Spam-Level: X-Spam-Status: No, score=-103.669 tagged_above=-999 required=5 tests=[AWL=-1.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+phsR9Nj2hh; Tue, 12 Jul 2011 17:27:09 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCA121F85CB; Tue, 12 Jul 2011 17:27:09 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p6D0QiWp014059 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 12 Jul 2011 17:26:44 -0700 (PDT) Message-ID: <4E1CE644.9090300@isi.edu> Date: Tue, 12 Jul 2011 17:26:44 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: stbryant@cisco.com References: <4E17210A.1070402@joelhalpern.com> <5662A966-70AD-4A63-BA31-8CE1C9635687@cisco.com> <4E1747BB.8080602@cisco.com> <4E19B2DC.4030003@joelhalpern.com> <4E1CC976.9000007@isi.edu> <4E1CCC76.9090409@cisco.com> In-Reply-To: <4E1CCC76.9090409@cisco.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: "tsv-ads@tools.ietf.org" , IETF discussion list , "karp@ietf.org" Subject: Re: [karp] notes from discussion of KARP design guidelines 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, 13 Jul 2011 00:27:09 -0000 On 7/12/2011 3:36 PM, Stewart Bryant wrote: > On 12/07/2011 23:23, Joe Touch wrote: >> Hi, Joel (et al.), >> >> On 7/10/2011 7:10 AM, Joel Halpern wrote: >>> Joe, >>> THE KARP WG Chairs have reviewed your comments, in order to figure out >>> what the best way to address them. We would appreciate it if you could >>> engage in discussion of this proposal on the KARP working group email >>> list. If you feel we are still not understanding your point, we would be >>> happy to make some time avaialble for discussion at the WG session in >>> Quebec City. (Comments from anyone else, particularly WG members, on the >>> proposals being made by the WG chairs are appreciated as well.) >>> >>> Rather than a line by line response, we have tried to find the common >>> themes and respond to them. If we have missed major issues, please let >>> us know. >>> >>> You raised concern about the use of the term "on-the-wire." Rather than >>> replace the term, we would prefer to add descriptive text early in the >>> document. This text would note that it is a widely used term in IETF >>> documents, including many RFCs. It would also state for clarity that in >>> this document it is used to refer to the message sent from one routing >>> process to another. >> >> That's a great example of why this term should be removed. The message >> sent from one BGP to another is sent *inside* a TCP connection, and >> nobody would ever call the TCP bytestream payload the message "on the >> wire". >> >> This term is simply sloppy, and just as the security community rightly >> raises issues with similarly poor use of its terms (e.g., "random" >> where pseudorandom or arbitrary are intended, or "authenticated" where >> integrity protection is intended), I consider this a *significant* >> transport issue. > > Joe > > Please can you suggest a suitable generic term that covers the > set of cases that we need to deal with in routing - i.e. > over the MAC, over IP, over UDP and over TCP, so that we can > discuss inter routing entity message passing as an abstract > operation. > > As Joel says when we get to the detailed design of each routing > protocol we will discuss the details, but we want a high level > discussion in this document. > > Note BTW that 186 RFCs use the term "on the wire" in this > sort of situation. I counted nearly 210, when including "over the wire" too. There are similar misuses of, e.g., security terms, though, so let's not let past errors suggest continued use. That said, let's proceed: First, when you say "on the wire" do you mean: (A)- the routing protocol data units (RPDUs) (B)- way in which RPDUs are exchanged this includes message payloads, meta-info (header information), and any other info at other layers beyond RPDUs that the routing protocol uses or relies upon I'm presuming the term "on the wire" is intended to differentiate between (A) and (B). There's no good way to describe (B) as a single entity because it's not one. You basically are differentiating between the message and the means of its communication. The latter is often called a 'channel' in other contexts, so maybe that's the term you want - a way to protect the 'channel'. Joe From jmh@joelhalpern.com Wed Jul 13 10:31:06 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 75CFD21F898E; Wed, 13 Jul 2011 10:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZHhVdkVbARJ; Wed, 13 Jul 2011 10:31:05 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1AD21F898B; Wed, 13 Jul 2011 10:31:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id CE6883245E54; Wed, 13 Jul 2011 10:31:04 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.154.181.24] (unknown [129.192.185.163]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id A68C032448B8; Wed, 13 Jul 2011 10:31:03 -0700 (PDT) Message-ID: <4E1DD654.3030603@joelhalpern.com> Date: Wed, 13 Jul 2011 13:31:00 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Joe Touch References: <4E17210A.1070402@joelhalpern.com> <5662A966-70AD-4A63-BA31-8CE1C9635687@cisco.com> <4E1747BB.8080602@cisco.com> <4E19B2DC.4030003@joelhalpern.com> <4E1CC976.9000007@isi.edu> <4E1CCC76.9090409@cisco.com> <4E1CE644.9090300@isi.edu> In-Reply-To: <4E1CE644.9090300@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tsv-ads@tools.ietf.org" , "karp@ietf.org" , IETF discussion list Subject: Re: [karp] notes from discussion of KARP design guidelines 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, 13 Jul 2011 17:31:06 -0000 Replacing a widely used term ("on the wire") with term that folks will not understand does not seem to me personally to be a benefit. In terms of this document, I do not see a problem with the usage as it is. This is not a protocol document. The use of the current term in this context seems helpful rather than harmful. Yours, Joel On 7/12/2011 8:26 PM, Joe Touch wrote: > > > On 7/12/2011 3:36 PM, Stewart Bryant wrote: >> On 12/07/2011 23:23, Joe Touch wrote: >>> Hi, Joel (et al.), >>> >>> On 7/10/2011 7:10 AM, Joel Halpern wrote: >>>> Joe, >>>> THE KARP WG Chairs have reviewed your comments, in order to figure out >>>> what the best way to address them. We would appreciate it if you could >>>> engage in discussion of this proposal on the KARP working group email >>>> list. If you feel we are still not understanding your point, we >>>> would be >>>> happy to make some time avaialble for discussion at the WG session in >>>> Quebec City. (Comments from anyone else, particularly WG members, on >>>> the >>>> proposals being made by the WG chairs are appreciated as well.) >>>> >>>> Rather than a line by line response, we have tried to find the common >>>> themes and respond to them. If we have missed major issues, please let >>>> us know. >>>> >>>> You raised concern about the use of the term "on-the-wire." Rather than >>>> replace the term, we would prefer to add descriptive text early in the >>>> document. This text would note that it is a widely used term in IETF >>>> documents, including many RFCs. It would also state for clarity that in >>>> this document it is used to refer to the message sent from one routing >>>> process to another. >>> >>> That's a great example of why this term should be removed. The message >>> sent from one BGP to another is sent *inside* a TCP connection, and >>> nobody would ever call the TCP bytestream payload the message "on the >>> wire". >>> >>> This term is simply sloppy, and just as the security community rightly >>> raises issues with similarly poor use of its terms (e.g., "random" >>> where pseudorandom or arbitrary are intended, or "authenticated" where >>> integrity protection is intended), I consider this a *significant* >>> transport issue. >> >> Joe >> >> Please can you suggest a suitable generic term that covers the >> set of cases that we need to deal with in routing - i.e. >> over the MAC, over IP, over UDP and over TCP, so that we can >> discuss inter routing entity message passing as an abstract >> operation. >> >> As Joel says when we get to the detailed design of each routing >> protocol we will discuss the details, but we want a high level >> discussion in this document. >> >> Note BTW that 186 RFCs use the term "on the wire" in this >> sort of situation. > > I counted nearly 210, when including "over the wire" too. There are > similar misuses of, e.g., security terms, though, so let's not let past > errors suggest continued use. > > That said, let's proceed: > > First, when you say "on the wire" do you mean: > > (A)- the routing protocol data units (RPDUs) > > (B)- way in which RPDUs are exchanged > this includes message payloads, meta-info > (header information), and any other info > at other layers beyond RPDUs that the routing > protocol uses or relies upon > > I'm presuming the term "on the wire" is intended to differentiate > between (A) and (B). > > There's no good way to describe (B) as a single entity because it's not > one. You basically are differentiating between the message and the means > of its communication. The latter is often called a 'channel' in other > contexts, so maybe that's the term you want - a way to protect the > 'channel'. > > Joe > > > > > > From touch@isi.edu Wed Jul 13 11:02: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 E198C21F8BC8; Wed, 13 Jul 2011 11:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.618 X-Spam-Level: X-Spam-Status: No, score=-103.618 tagged_above=-999 required=5 tests=[AWL=-1.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TynD7vrKf40; Wed, 13 Jul 2011 11:02:43 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 56C6A21F8BC9; Wed, 13 Jul 2011 11:02:37 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p6DI2P18014919 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 13 Jul 2011 11:02:27 -0700 (PDT) Message-ID: <4E1DDDB1.4020902@isi.edu> Date: Wed, 13 Jul 2011 11:02:25 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Joel M. Halpern" References: <4E17210A.1070402@joelhalpern.com> <5662A966-70AD-4A63-BA31-8CE1C9635687@cisco.com> <4E1747BB.8080602@cisco.com> <4E19B2DC.4030003@joelhalpern.com> <4E1CC976.9000007@isi.edu> <4E1CCC76.9090409@cisco.com> <4E1CE644.9090300@isi.edu> <4E1DD654.3030603@joelhalpern.com> In-Reply-To: <4E1DD654.3030603@joelhalpern.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: "tsv-ads@tools.ietf.org" , "karp@ietf.org" , IETF discussion list Subject: Re: [karp] notes from discussion of KARP design guidelines 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, 13 Jul 2011 18:02:44 -0000 Hi, Joel, On 7/13/2011 10:31 AM, Joel M. Halpern wrote: > Replacing a widely used term ("on the wire") with term that folks will > not understand does not seem to me personally to be a benefit. The problem is that "on the wire" is ambiguous. Many people think they know what it means definitively, but their views vary widely. > In terms of this document, I do not see a problem with the usage as it > is. This is not a protocol document. The use of the current term in this > context seems helpful rather than harmful. Since the whole point of this doc centers around protecting the way messages are exchanged, not the messages themselves (e.g., as would be the case with signed BGP routes), this is a crucial issue to make clear and precise in this doc. Joe > On 7/12/2011 8:26 PM, Joe Touch wrote: >> >> >> On 7/12/2011 3:36 PM, Stewart Bryant wrote: >>> On 12/07/2011 23:23, Joe Touch wrote: >>>> Hi, Joel (et al.), >>>> >>>> On 7/10/2011 7:10 AM, Joel Halpern wrote: >>>>> Joe, >>>>> THE KARP WG Chairs have reviewed your comments, in order to figure out >>>>> what the best way to address them. We would appreciate it if you could >>>>> engage in discussion of this proposal on the KARP working group email >>>>> list. If you feel we are still not understanding your point, we >>>>> would be >>>>> happy to make some time avaialble for discussion at the WG session in >>>>> Quebec City. (Comments from anyone else, particularly WG members, on >>>>> the >>>>> proposals being made by the WG chairs are appreciated as well.) >>>>> >>>>> Rather than a line by line response, we have tried to find the common >>>>> themes and respond to them. If we have missed major issues, please let >>>>> us know. >>>>> >>>>> You raised concern about the use of the term "on-the-wire." Rather >>>>> than >>>>> replace the term, we would prefer to add descriptive text early in the >>>>> document. This text would note that it is a widely used term in IETF >>>>> documents, including many RFCs. It would also state for clarity >>>>> that in >>>>> this document it is used to refer to the message sent from one routing >>>>> process to another. >>>> >>>> That's a great example of why this term should be removed. The message >>>> sent from one BGP to another is sent *inside* a TCP connection, and >>>> nobody would ever call the TCP bytestream payload the message "on the >>>> wire". >>>> >>>> This term is simply sloppy, and just as the security community rightly >>>> raises issues with similarly poor use of its terms (e.g., "random" >>>> where pseudorandom or arbitrary are intended, or "authenticated" where >>>> integrity protection is intended), I consider this a *significant* >>>> transport issue. >>> >>> Joe >>> >>> Please can you suggest a suitable generic term that covers the >>> set of cases that we need to deal with in routing - i.e. >>> over the MAC, over IP, over UDP and over TCP, so that we can >>> discuss inter routing entity message passing as an abstract >>> operation. >>> >>> As Joel says when we get to the detailed design of each routing >>> protocol we will discuss the details, but we want a high level >>> discussion in this document. >>> >>> Note BTW that 186 RFCs use the term "on the wire" in this >>> sort of situation. >> >> I counted nearly 210, when including "over the wire" too. There are >> similar misuses of, e.g., security terms, though, so let's not let past >> errors suggest continued use. >> >> That said, let's proceed: >> >> First, when you say "on the wire" do you mean: >> >> (A)- the routing protocol data units (RPDUs) >> >> (B)- way in which RPDUs are exchanged >> this includes message payloads, meta-info >> (header information), and any other info >> at other layers beyond RPDUs that the routing >> protocol uses or relies upon >> >> I'm presuming the term "on the wire" is intended to differentiate >> between (A) and (B). >> >> There's no good way to describe (B) as a single entity because it's not >> one. You basically are differentiating between the message and the means >> of its communication. The latter is often called a 'channel' in other >> contexts, so maybe that's the term you want - a way to protect the >> 'channel'. >> >> Joe >> >> >> >> >> >> From wes@mti-systems.com Wed Jul 13 11:24: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 8426621F8C2F for ; Wed, 13 Jul 2011 11:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWWBN1IUpznn for ; Wed, 13 Jul 2011 11:24:10 -0700 (PDT) Received: from omr17.networksolutionsemail.com (omr17.networksolutionsemail.com [205.178.146.67]) by ietfa.amsl.com (Postfix) with ESMTP id E0F5821F8C2C for ; Wed, 13 Jul 2011 11:24:07 -0700 (PDT) Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr17.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p6DIO6J0026858 for ; Wed, 13 Jul 2011 14:24:07 -0400 Authentication-Results: cm-omr1 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [107.46.81.255] ([107.46.81.255:58078] helo=[192.168.9.2]) by cm-omr1 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id D8/8B-29864-5C2ED1E4; Wed, 13 Jul 2011 14:24:06 -0400 Message-ID: <4E1DE2C2.8090209@mti-systems.com> Date: Wed, 13 Jul 2011 14:24:02 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Joel M. Halpern" References: <4E17210A.1070402@joelhalpern.com> <5662A966-70AD-4A63-BA31-8CE1C9635687@cisco.com> <4E1747BB.8080602@cisco.com> <4E19B2DC.4030003@joelhalpern.com> <4E1CC976.9000007@isi.edu> <4E1CCC76.9090409@cisco.com> <4E1CE644.9090300@isi.edu> <4E1DD654.3030603@joelhalpern.com> In-Reply-To: <4E1DD654.3030603@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 13 Jul 2011 11:27:33 -0700 Cc: "tsv-ads@tools.ietf.org" , "karp@ietf.org" , IETF discussion list Subject: Re: [karp] notes from discussion of KARP design guidelines 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, 13 Jul 2011 18:24:11 -0000 On 7/13/2011 1:31 PM, Joel M. Halpern wrote: > Replacing a widely used term ("on the wire") with term that folks will > not understand does not seem to me personally to be a benefit. I think Joe's point is that it's widely used as a concept, but what it means specifically in this document is not clear. A sentence to clarify up-front what the definition is in this document might be enough. > In terms of this document, I do not see a problem with the usage as it > is. This is not a protocol document. The use of the current term in this > context seems helpful rather than harmful. It might be reasonable to add a sentence that says, "In this document, 'on the wire' refers to (A) the routing protocol data itself, as well as (B) the way in which routing protocol data is exchanged using underlying protocols, including the headers and other meta-data used by those underlying protocols", or something like that? To me, that's a lot more useful than saying "this term is commonly used" without defining in what sense(s) you mean it in the present document. I think it's important because the protections possible are potentially a lot different, and if you want people to think about only one or both, it should be made explicit. On a lighter note, I once generated a lot of confusion using this term with people working on satellite networks, who were wondering what wires I could possibly be talking about since all of our links were microwave. I guess if KARP covered MANET protocols we'd have to protect them "on the wireless". -- Wes Eddy MTI Systems From jmh@joelhalpern.com Wed Jul 13 11:34: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 A13F4228006; Wed, 13 Jul 2011 11:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGbRLqks5lZY; Wed, 13 Jul 2011 11:34:30 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id 0335422800F; Wed, 13 Jul 2011 11:34:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 3626F3245DBB; Wed, 13 Jul 2011 11:34:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.154.181.24] (unknown [129.192.185.163]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 3023F32462B0; Wed, 13 Jul 2011 11:34:28 -0700 (PDT) Message-ID: <4E1DE530.5060701@joelhalpern.com> Date: Wed, 13 Jul 2011 14:34:24 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Wesley Eddy References: <4E17210A.1070402@joelhalpern.com> <5662A966-70AD-4A63-BA31-8CE1C9635687@cisco.com> <4E1747BB.8080602@cisco.com> <4E19B2DC.4030003@joelhalpern.com> <4E1CC976.9000007@isi.edu> <4E1CCC76.9090409@cisco.com> <4E1CE644.9090300@isi.edu> <4E1DD654.3030603@joelhalpern.com> <4E1DE2C2.8090209@mti-systems.com> In-Reply-To: <4E1DE2C2.8090209@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tsv-ads@tools.ietf.org" , "karp@ietf.org" , IETF discussion list Subject: Re: [karp] notes from discussion of KARP design guidelines 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, 13 Jul 2011 18:34:30 -0000 As I said in my earlier note proposing responses to Joe, we would be happy to some text in the front clarifying the usage. Quoting from my earlier email: This text would note that it is a widely used term in IETF documents, including many RFCs. It would also state for clarity that in this document it is used to refer to the message sent from one routing process to another. Apparently, this does not address Joe's concern. Yours, Joel On 7/13/2011 2:24 PM, Wesley Eddy wrote: > On 7/13/2011 1:31 PM, Joel M. Halpern wrote: >> Replacing a widely used term ("on the wire") with term that folks will >> not understand does not seem to me personally to be a benefit. > > I think Joe's point is that it's widely used as a concept, but what > it means specifically in this document is not clear. A sentence to > clarify up-front what the definition is in this document might be > enough. ... From touch@isi.edu Wed Jul 13 11:59:25 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 A7CBF11E813F; Wed, 13 Jul 2011 11:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.572 X-Spam-Level: X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=-0.973, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvmgYJY07lwi; Wed, 13 Jul 2011 11:59:25 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 10DB711E80AF; Wed, 13 Jul 2011 11:59:25 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p6DIwp3r001226 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 13 Jul 2011 11:58:51 -0700 (PDT) Message-ID: <4E1DEAEB.9040208@isi.edu> Date: Wed, 13 Jul 2011 11:58:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Joel M. Halpern" References: <4E17210A.1070402@joelhalpern.com> <5662A966-70AD-4A63-BA31-8CE1C9635687@cisco.com> <4E1747BB.8080602@cisco.com> <4E19B2DC.4030003@joelhalpern.com> <4E1CC976.9000007@isi.edu> <4E1CCC76.9090409@cisco.com> <4E1CE644.9090300@isi.edu> <4E1DD654.3030603@joelhalpern.com> <4E1DE2C2.8090209@mti-systems.com> <4E1DE530.5060701@joelhalpern.com> In-Reply-To: <4E1DE530.5060701@joelhalpern.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: Wesley Eddy , "tsv-ads@tools.ietf.org" , IETF discussion list , "karp@ietf.org" Subject: Re: [karp] notes from discussion of KARP design guidelines 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, 13 Jul 2011 18:59:25 -0000 On 7/13/2011 11:34 AM, Joel M. Halpern wrote: > As I said in my earlier note proposing responses to Joe, we would be > happy to some text in the front clarifying the usage. Quoting from my > earlier email: > > This text would note that it is a widely used term in IETF documents, > including many RFCs. It would also state for clarity that in this > document it is used to refer to the message sent from one routing > process to another. Here's why this is a problem: 1- does this refer to signing a BGP path? 2- does this refer to protecting the channel over which BGP paths are exchanged? From the intro: Four main steps were identified for that tightening: o More secure mechanisms and practices for operating routers. ... o Cleaning up the Internet Routing Registry repository [IRR], ... o Specifications for cryptographic validation of routing message content. ... o Securing the routing protocols' packets on the wire This document addresses the last bullet, securing the packets on the wire of the routing protocol exchanges. So this document is clearly NOT about "the message from one routing process to another (that would be 'routing message content', IMO). I.e., this doc focuses on securing the transfer mechanism NOT the message. Thus this is the key to the entirety of the doc. This doc needs to be very clear about what this is, at which point it can certainly also then refer back to the original RFC (e.g., "this is referred to in RFC 4948 as 'on the wire'"). Joe From jmh@joelhalpern.com Wed Jul 13 13:44:40 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 BA5C921F8AB0; Wed, 13 Jul 2011 13:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.278 X-Spam-Level: X-Spam-Status: No, score=-102.278 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYzL+SqDjKNI; Wed, 13 Jul 2011 13:44:40 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id 811EF21F8A7E; Wed, 13 Jul 2011 13:44:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id CB0A432444BF; Wed, 13 Jul 2011 13:44:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.154.181.24] (unknown [129.192.185.163]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id C2F453244A7B; Wed, 13 Jul 2011 13:44:37 -0700 (PDT) Message-ID: <4E1E03B2.3010405@joelhalpern.com> Date: Wed, 13 Jul 2011 16:44:34 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Wesley Eddy References: <4E17210A.1070402@joelhalpern.com> <5662A966-70AD-4A63-BA31-8CE1C9635687@cisco.com> <4E1747BB.8080602@cisco.com> <4E19B2DC.4030003@joelhalpern.com> <4E1CC976.9000007@isi.edu> <4E1CCC76.9090409@cisco.com> <4E1CE644.9090300@isi.edu> <4E1DD654.3030603@joelhalpern.com> <4E1DE2C2.8090209@mti-systems.com> <4E1DE530.5060701@joelhalpern.com> <4E1DE827.8000300@mti-systems.com> In-Reply-To: <4E1DE827.8000300@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tsv-ads@tools.ietf.org" , "karp@ietf.org" , IETF discussion list Subject: Re: [karp] notes from discussion of KARP design guidelines 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, 13 Jul 2011 20:44:40 -0000 Sorry, I apparently missed part of your earlier note. Would text like: This document uses the term "on-the-wire" to talk about the information used by routing systems. This term is widely used in IETF RFCs,but is used in several different ways. In this document, it is used to refer both to information exchanged between routing protocol instances, and to underlying protocols that may also need to be protected in specific circumstances. Individual protocol analysis documents will need to be more specific in their usage. work to address the issue? Yours, Joel On 7/13/2011 2:47 PM, Wesley Eddy wrote: > On 7/13/2011 2:34 PM, Joel M. Halpern wrote: >> As I said in my earlier note proposing responses to Joe, we would be >> happy to some text in the front clarifying the usage. Quoting from my >> earlier email: >> >> This text would note that it is a widely used term in IETF documents, >> including many RFCs. It would also state for clarity that in this >> document it is used to refer to the message sent from one routing >> process to another. >> >> Apparently, this does not address Joe's concern. >> > > "message sent from one routing process to another" doesn't seem to be > right to me either since it sounds like the first definition that > covers routing protocol data only, and not underlying protocols, so I > wouldn't expect that proposal to address Joe's concern. > From jmh@joelhalpern.com Wed Jul 13 13:59: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 3F26111E80C4; Wed, 13 Jul 2011 13:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fWpowwZo9e7; Wed, 13 Jul 2011 13:59:00 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id 98A7511E807D; Wed, 13 Jul 2011 13:59:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 071DB325C159; Wed, 13 Jul 2011 13:59:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.154.181.24] (unknown [129.192.185.163]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 01192325C155; Wed, 13 Jul 2011 13:58:58 -0700 (PDT) Message-ID: <4E1E070F.6000103@joelhalpern.com> Date: Wed, 13 Jul 2011 16:58:55 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Joe Touch References: <4E17210A.1070402@joelhalpern.com> <5662A966-70AD-4A63-BA31-8CE1C9635687@cisco.com> <4E1747BB.8080602@cisco.com> <4E19B2DC.4030003@joelhalpern.com> <4E1CC976.9000007@isi.edu> <4E1CCC76.9090409@cisco.com> <4E1CE644.9090300@isi.edu> <4E1DD654.3030603@joelhalpern.com> <4E1DE2C2.8090209@mti-systems.com> <4E1DE530.5060701@joelhalpern.com> <4E1DEAEB.9040208@isi.edu> In-Reply-To: <4E1DEAEB.9040208@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Wesley Eddy , "tsv-ads@tools.ietf.org" , IETF discussion list , "karp@ietf.org" Subject: Re: [karp] notes from discussion of KARP design guidelines 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, 13 Jul 2011 20:59:01 -0000 I don't understand your description of the problem. As you quote, the document clearly states its scope. So, when we then define the term "on-the-wire", I don't think we need to restate the scope definition. It woudl seem coutner-productive. Yours, Joel On 7/13/2011 2:58 PM, Joe Touch wrote: > > > On 7/13/2011 11:34 AM, Joel M. Halpern wrote: >> As I said in my earlier note proposing responses to Joe, we would be >> happy to some text in the front clarifying the usage. Quoting from my >> earlier email: >> >> This text would note that it is a widely used term in IETF documents, >> including many RFCs. It would also state for clarity that in this >> document it is used to refer to the message sent from one routing >> process to another. > > Here's why this is a problem: > > 1- does this refer to signing a BGP path? > > 2- does this refer to protecting the channel over which BGP paths are > exchanged? > > From the intro: > Four main steps were identified for that tightening: > > o More secure mechanisms and practices for operating routers. > ... > > o Cleaning up the Internet Routing Registry repository [IRR], > ... > > o Specifications for cryptographic validation of routing message > content. > ... > > o Securing the routing protocols' packets on the wire > > This document addresses the last bullet, securing the packets on the > wire of the routing protocol exchanges. > > So this document is clearly NOT about "the message from one routing > process to another (that would be 'routing message content', IMO). I.e., > this doc focuses on securing the transfer mechanism NOT the message. > > Thus this is the key to the entirety of the doc. This doc needs to be > very clear about what this is, at which point it can certainly also then > refer back to the original RFC (e.g., "this is referred to in RFC 4948 > as 'on the wire'"). > > Joe > > > From touch@isi.edu Wed Jul 13 14:06: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 0597421F8B32; Wed, 13 Jul 2011 14:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.191 X-Spam-Level: X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=-1.192, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGLIsv5pclkj; Wed, 13 Jul 2011 14:06:00 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF8721F8B2B; Wed, 13 Jul 2011 14:06:00 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p6DL5fA5006199 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 13 Jul 2011 14:05:42 -0700 (PDT) Message-ID: <4E1E08A5.4000809@isi.edu> Date: Wed, 13 Jul 2011 14:05:41 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Joel M. Halpern" References: <4E17210A.1070402@joelhalpern.com> <5662A966-70AD-4A63-BA31-8CE1C9635687@cisco.com> <4E1747BB.8080602@cisco.com> <4E19B2DC.4030003@joelhalpern.com> <4E1CC976.9000007@isi.edu> <4E1CCC76.9090409@cisco.com> <4E1CE644.9090300@isi.edu> <4E1DD654.3030603@joelhalpern.com> <4E1DE2C2.8090209@mti-systems.com> <4E1DE530.5060701@joelhalpern.com> <4E1DE827.8000300@mti-systems.com> <4E1E03B2.3010405@joelhalpern.com> In-Reply-To: <4E1E03B2.3010405@joelhalpern.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: Wesley Eddy , "tsv-ads@tools.ietf.org" , IETF discussion list , "karp@ietf.org" Subject: Re: [karp] notes from discussion of KARP design guidelines 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, 13 Jul 2011 21:06:01 -0000 Hi, Joel, On 7/13/2011 1:44 PM, Joel M. Halpern wrote: > Sorry, I apparently missed part of your earlier note. > Would text like: > This document uses the term "on-the-wire" to talk about the information > used by routing systems. This term is widely used in IETF RFCs,but is > used in several different ways. In this document, it is used to refer > both to information exchanged between routing protocol instances, and to > underlying protocols that may also need to be protected in specific > circumstances. I think that is in direct contrast to the current text in the intro, that appears to differentiate between the two and focus on the latter. Joe > Individual protocol analysis documents will need to be > more specific in their usage. > > work to address the issue? > Yours, > Joel > > On 7/13/2011 2:47 PM, Wesley Eddy wrote: >> On 7/13/2011 2:34 PM, Joel M. Halpern wrote: >>> As I said in my earlier note proposing responses to Joe, we would be >>> happy to some text in the front clarifying the usage. Quoting from my >>> earlier email: >>> >>> This text would note that it is a widely used term in IETF documents, >>> including many RFCs. It would also state for clarity that in this >>> document it is used to refer to the message sent from one routing >>> process to another. >>> >>> Apparently, this does not address Joe's concern. >>> >> >> "message sent from one routing process to another" doesn't seem to be >> right to me either since it sounds like the first definition that >> covers routing protocol data only, and not underlying protocols, so I >> wouldn't expect that proposal to address Joe's concern. >> From wes@mti-systems.com Wed Jul 13 11:47:07 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 43E0A11E8133 for ; Wed, 13 Jul 2011 11:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9TRFmF7XTVb for ; Wed, 13 Jul 2011 11:47:06 -0700 (PDT) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by ietfa.amsl.com (Postfix) with ESMTP id 82D7411E80B2 for ; Wed, 13 Jul 2011 11:47:06 -0700 (PDT) Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p6DIl67U012117 for ; Wed, 13 Jul 2011 14:47:06 -0400 Authentication-Results: cm-omr1 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [107.46.81.255] ([107.46.81.255:59849] helo=[192.168.9.2]) by cm-omr1 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id EF/E1-29864-828ED1E4; Wed, 13 Jul 2011 14:47:06 -0400 Message-ID: <4E1DE827.8000300@mti-systems.com> Date: Wed, 13 Jul 2011 14:47:03 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Joel M. Halpern" References: <4E17210A.1070402@joelhalpern.com> <5662A966-70AD-4A63-BA31-8CE1C9635687@cisco.com> <4E1747BB.8080602@cisco.com> <4E19B2DC.4030003@joelhalpern.com> <4E1CC976.9000007@isi.edu> <4E1CCC76.9090409@cisco.com> <4E1CE644.9090300@isi.edu> <4E1DD654.3030603@joelhalpern.com> <4E1DE2C2.8090209@mti-systems.com> <4E1DE530.5060701@joelhalpern.com> In-Reply-To: <4E1DE530.5060701@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 13 Jul 2011 14:06:07 -0700 Cc: "tsv-ads@tools.ietf.org" , "karp@ietf.org" , IETF discussion list Subject: Re: [karp] notes from discussion of KARP design guidelines 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, 13 Jul 2011 18:47:07 -0000 On 7/13/2011 2:34 PM, Joel M. Halpern wrote: > As I said in my earlier note proposing responses to Joe, we would be > happy to some text in the front clarifying the usage. Quoting from my > earlier email: > > This text would note that it is a widely used term in IETF documents, > including many RFCs. It would also state for clarity that in this > document it is used to refer to the message sent from one routing > process to another. > > Apparently, this does not address Joe's concern. > "message sent from one routing process to another" doesn't seem to be right to me either since it sounds like the first definition that covers routing protocol data only, and not underlying protocols, so I wouldn't expect that proposal to address Joe's concern. -- Wes Eddy MTI Systems From touch@isi.edu Wed Jul 13 14:08:53 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 0F61321F8B2B; Wed, 13 Jul 2011 14:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.443 X-Spam-Level: X-Spam-Status: No, score=-103.443 tagged_above=-999 required=5 tests=[AWL=-0.844, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hW9MkUQNklTX; Wed, 13 Jul 2011 14:08:52 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 87B2C21F8B02; Wed, 13 Jul 2011 14:08:52 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p6DL8D5O006983 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 13 Jul 2011 14:08:13 -0700 (PDT) Message-ID: <4E1E093D.9040903@isi.edu> Date: Wed, 13 Jul 2011 14:08:13 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Joel M. Halpern" References: <4E17210A.1070402@joelhalpern.com> <5662A966-70AD-4A63-BA31-8CE1C9635687@cisco.com> <4E1747BB.8080602@cisco.com> <4E19B2DC.4030003@joelhalpern.com> <4E1CC976.9000007@isi.edu> <4E1CCC76.9090409@cisco.com> <4E1CE644.9090300@isi.edu> <4E1DD654.3030603@joelhalpern.com> <4E1DE2C2.8090209@mti-systems.com> <4E1DE530.5060701@joelhalpern.com> <4E1DEAEB.9040208@isi.edu> <4E1E070F.6000103@joelhalpern.com> In-Reply-To: <4E1E070F.6000103@joelhalpern.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: Wesley Eddy , "tsv-ads@tools.ietf.org" , IETF discussion list , "karp@ietf.org" Subject: Re: [karp] notes from discussion of KARP design guidelines 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, 13 Jul 2011 21:08:53 -0000 Hi, Joel, On 7/13/2011 1:58 PM, Joel M. Halpern wrote: > I don't understand your description of the problem. > As you quote, the document clearly states its scope. > So, when we then define the term "on-the-wire", I don't think we need to > restate the scope definition. It woudl seem coutner-productive. The current scope is clear from the bullet list only by the assumption that (a) the bullets are mutually exclusive, and (b) since the "routing message content" is clear, it cannot be part of "on the wire". I.e., it requires the reader interpret scope by a matter of deduction and exclusion, rather than stating it clearly and explicitly. Joe > > Yours, > Joel > > > On 7/13/2011 2:58 PM, Joe Touch wrote: >> >> >> On 7/13/2011 11:34 AM, Joel M. Halpern wrote: >>> As I said in my earlier note proposing responses to Joe, we would be >>> happy to some text in the front clarifying the usage. Quoting from my >>> earlier email: >>> >>> This text would note that it is a widely used term in IETF documents, >>> including many RFCs. It would also state for clarity that in this >>> document it is used to refer to the message sent from one routing >>> process to another. >> >> Here's why this is a problem: >> >> 1- does this refer to signing a BGP path? >> >> 2- does this refer to protecting the channel over which BGP paths are >> exchanged? >> >> From the intro: >> Four main steps were identified for that tightening: >> >> o More secure mechanisms and practices for operating routers. >> ... >> >> o Cleaning up the Internet Routing Registry repository [IRR], >> ... >> >> o Specifications for cryptographic validation of routing message >> content. >> ... >> >> o Securing the routing protocols' packets on the wire >> >> This document addresses the last bullet, securing the packets on the >> wire of the routing protocol exchanges. >> >> So this document is clearly NOT about "the message from one routing >> process to another (that would be 'routing message content', IMO). I.e., >> this doc focuses on securing the transfer mechanism NOT the message. >> >> Thus this is the key to the entirety of the doc. This doc needs to be >> very clear about what this is, at which point it can certainly also then >> refer back to the original RFC (e.g., "this is referred to in RFC 4948 >> as 'on the wire'"). >> >> Joe >> >> >> From jmh@joelhalpern.com Wed Jul 13 14:26:15 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 225A011E8089; Wed, 13 Jul 2011 14:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmxVBP3iUV5c; Wed, 13 Jul 2011 14:26:14 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0C511E8075; Wed, 13 Jul 2011 14:26:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 86DCC32462B0; Wed, 13 Jul 2011 14:26:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.154.181.24] (unknown [129.192.185.163]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 5A3E43245E54; Wed, 13 Jul 2011 14:26:12 -0700 (PDT) Message-ID: <4E1E0D70.7040801@joelhalpern.com> Date: Wed, 13 Jul 2011 17:26:08 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Joe Touch References: <4E17210A.1070402@joelhalpern.com> <5662A966-70AD-4A63-BA31-8CE1C9635687@cisco.com> <4E1747BB.8080602@cisco.com> <4E19B2DC.4030003@joelhalpern.com> <4E1CC976.9000007@isi.edu> <4E1CCC76.9090409@cisco.com> <4E1CE644.9090300@isi.edu> <4E1DD654.3030603@joelhalpern.com> <4E1DE2C2.8090209@mti-systems.com> <4E1DE530.5060701@joelhalpern.com> <4E1DEAEB.9040208@isi.edu> <4E1E070F.6000103@joelhalpern.com> <4E1E093D.9040903@isi.edu> In-Reply-To: <4E1E093D.9040903@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Wesley Eddy , "tsv-ads@tools.ietf.org" , IETF discussion list , "karp@ietf.org" Subject: Re: [karp] notes from discussion of KARP design guidelines 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, 13 Jul 2011 21:26:15 -0000 You wording seems to induce confusion. Of course the routing message content is part of the message on-the-wire. It is the content of the message. It is in fact a significant part of what is being protected. What is NOT part of the scope, and which the text says is not part of the scope, is the validation of that information. KARP is not assuring that the information is valid. it is responsible to ensure that the message is not modified between the two peers. Yes, this means that there is an overlap in protection between validation information and packet authentication information. So? The scope is very clear as to whose problem is whose. (This is merely a statement of fact. If we have path signing and TCP-AO, there are two sets of mechanisms preventing modification of some of the BGP information.) The text after the bullet list explicitly says what part is in scope. it does not require any assumption or inference. If there is specific wording you would like to suggest to improve the introductory scoping material, I would be happy to look at it. Yours, Joel On 7/13/2011 5:08 PM, Joe Touch wrote: > Hi, Joel, > > On 7/13/2011 1:58 PM, Joel M. Halpern wrote: >> I don't understand your description of the problem. >> As you quote, the document clearly states its scope. >> So, when we then define the term "on-the-wire", I don't think we need to >> restate the scope definition. It woudl seem coutner-productive. > > The current scope is clear from the bullet list only by the assumption > that (a) the bullets are mutually exclusive, and (b) since the "routing > message content" is clear, it cannot be part of "on the wire". > > I.e., it requires the reader interpret scope by a matter of deduction > and exclusion, rather than stating it clearly and explicitly. > > Joe > >> >> Yours, >> Joel >> >> >> On 7/13/2011 2:58 PM, Joe Touch wrote: >>> >>> >>> On 7/13/2011 11:34 AM, Joel M. Halpern wrote: >>>> As I said in my earlier note proposing responses to Joe, we would be >>>> happy to some text in the front clarifying the usage. Quoting from my >>>> earlier email: >>>> >>>> This text would note that it is a widely used term in IETF documents, >>>> including many RFCs. It would also state for clarity that in this >>>> document it is used to refer to the message sent from one routing >>>> process to another. >>> >>> Here's why this is a problem: >>> >>> 1- does this refer to signing a BGP path? >>> >>> 2- does this refer to protecting the channel over which BGP paths are >>> exchanged? >>> >>> From the intro: >>> Four main steps were identified for that tightening: >>> >>> o More secure mechanisms and practices for operating routers. >>> ... >>> >>> o Cleaning up the Internet Routing Registry repository [IRR], >>> ... >>> >>> o Specifications for cryptographic validation of routing message >>> content. >>> ... >>> >>> o Securing the routing protocols' packets on the wire >>> >>> This document addresses the last bullet, securing the packets on the >>> wire of the routing protocol exchanges. >>> >>> So this document is clearly NOT about "the message from one routing >>> process to another (that would be 'routing message content', IMO). I.e., >>> this doc focuses on securing the transfer mechanism NOT the message. >>> >>> Thus this is the key to the entirety of the doc. This doc needs to be >>> very clear about what this is, at which point it can certainly also then >>> refer back to the original RFC (e.g., "this is referred to in RFC 4948 >>> as 'on the wire'"). >>> >>> Joe >>> >>> >>> > From touch@isi.edu Wed Jul 13 16:02: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 A141D21F8C0D; Wed, 13 Jul 2011 16:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.38 X-Spam-Level: X-Spam-Status: No, score=-103.38 tagged_above=-999 required=5 tests=[AWL=-0.781, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMIXt7-KNci6; Wed, 13 Jul 2011 16:02:32 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 5684721F8C07; Wed, 13 Jul 2011 16:02:32 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p6DN24FG009669 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 13 Jul 2011 16:02:04 -0700 (PDT) Message-ID: <4E1E23EC.7040502@isi.edu> Date: Wed, 13 Jul 2011 16:02:04 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Joel M. Halpern" References: <4E17210A.1070402@joelhalpern.com> <5662A966-70AD-4A63-BA31-8CE1C9635687@cisco.com> <4E1747BB.8080602@cisco.com> <4E19B2DC.4030003@joelhalpern.com> <4E1CC976.9000007@isi.edu> <4E1CCC76.9090409@cisco.com> <4E1CE644.9090300@isi.edu> <4E1DD654.3030603@joelhalpern.com> <4E1DE2C2.8090209@mti-systems.com> <4E1DE530.5060701@joelhalpern.com> <4E1DEAEB.9040208@isi.edu> <4E1E070F.6000103@joelhalpern.com> <4E1E093D.9040903@isi.edu> <4E1E0D70.7040801@joelhalpern.com> In-Reply-To: <4E1E0D70.7040801@joelhalpern.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: Wesley Eddy , "tsv-ads@tools.ietf.org" , IETF discussion list , "karp@ietf.org" Subject: Re: [karp] notes from discussion of KARP design guidelines 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, 13 Jul 2011 23:02:36 -0000 Hi, Joel, On 7/13/2011 2:26 PM, Joel M. Halpern wrote: > You wording seems to induce confusion. > Of course the routing message content is part of the message > on-the-wire. It is the content of the message. It is in fact a > significant part of what is being protected. > > What is NOT part of the scope, and which the text says is not part of > the scope, is the validation of that information. KARP is not assuring > that the information is valid. it is responsible to ensure that the > message is not modified between the two peers. > > Yes, this means that there is an overlap in protection between > validation information and packet authentication information.So? The > scope is very clear as to whose problem is whose. That makes absolutely no sense. If there's overlap, then it's obviously unclear as to whose problem is whose. > (This is merely a > statement of fact. If we have path signing and TCP-AO, there are two > sets of mechanisms preventing modification of some of the BGP information.) I appreciate that different layers can include redundant protections. However, I'm trying to understand what is *expected* from each layer. > The text after the bullet list explicitly says what part is in scope. it > does not require any assumption or inference. > If there is specific wording you would like to suggest to improve the > introductory scoping material, I would be happy to look at it. Glad to, with a bit more context. Can you please define what is being validated in the third bullet that is NOT protected by the last one or vice versa? AFAICT, it would be: #3 is entirely responsible for ensuring that a source has permission to advertise a particular route #3 or #4 could confirm the identity of the source of a piece of information (#3 is required if transitive, #4 works only if directly communicated). #3 or #4 could confirm the integrity of such information #4 is required to protect the properties of lower layers insofar as they are used as such information to the routing protocol (e.g., BGP tossing out routes because TCP connections fail). If this is the case, then I understand 4 as protecting the *channel* over which routing messages are exchanged (which ends up protecting the messages too), and 3 as focusing on the routing layer messages themselves. Is that the case? Joe > On 7/13/2011 5:08 PM, Joe Touch wrote: >> Hi, Joel, >> >> On 7/13/2011 1:58 PM, Joel M. Halpern wrote: >>> I don't understand your description of the problem. >>> As you quote, the document clearly states its scope. >>> So, when we then define the term "on-the-wire", I don't think we need to >>> restate the scope definition. It woudl seem coutner-productive. >> >> The current scope is clear from the bullet list only by the assumption >> that (a) the bullets are mutually exclusive, and (b) since the "routing >> message content" is clear, it cannot be part of "on the wire". >> >> I.e., it requires the reader interpret scope by a matter of deduction >> and exclusion, rather than stating it clearly and explicitly. >> >> Joe >> >>> >>> Yours, >>> Joel >>> >>> >>> On 7/13/2011 2:58 PM, Joe Touch wrote: >>>> >>>> >>>> On 7/13/2011 11:34 AM, Joel M. Halpern wrote: >>>>> As I said in my earlier note proposing responses to Joe, we would be >>>>> happy to some text in the front clarifying the usage. Quoting from my >>>>> earlier email: >>>>> >>>>> This text would note that it is a widely used term in IETF documents, >>>>> including many RFCs. It would also state for clarity that in this >>>>> document it is used to refer to the message sent from one routing >>>>> process to another. >>>> >>>> Here's why this is a problem: >>>> >>>> 1- does this refer to signing a BGP path? >>>> >>>> 2- does this refer to protecting the channel over which BGP paths are >>>> exchanged? >>>> >>>> From the intro: >>>> Four main steps were identified for that tightening: >>>> >>>> o More secure mechanisms and practices for operating routers. >>>> ... >>>> >>>> o Cleaning up the Internet Routing Registry repository [IRR], >>>> ... >>>> >>>> o Specifications for cryptographic validation of routing message >>>> content. >>>> ... >>>> >>>> o Securing the routing protocols' packets on the wire >>>> >>>> This document addresses the last bullet, securing the packets on the >>>> wire of the routing protocol exchanges. >>>> >>>> So this document is clearly NOT about "the message from one routing >>>> process to another (that would be 'routing message content', IMO). >>>> I.e., >>>> this doc focuses on securing the transfer mechanism NOT the message. >>>> >>>> Thus this is the key to the entirety of the doc. This doc needs to be >>>> very clear about what this is, at which point it can certainly also >>>> then >>>> refer back to the original RFC (e.g., "this is referred to in RFC 4948 >>>> as 'on the wire'"). >>>> >>>> Joe >>>> >>>> >>>> >> From jmh@joelhalpern.com Wed Jul 13 16:25: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 7EA5611E809B; Wed, 13 Jul 2011 16:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6N1ATmqcsSk; Wed, 13 Jul 2011 16:25:03 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id E232111E8075; Wed, 13 Jul 2011 16:25:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 1632232444BF; Wed, 13 Jul 2011 16:25:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.154.181.24] (unknown [129.192.185.163]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id C753132289B4; Wed, 13 Jul 2011 16:25:00 -0700 (PDT) Message-ID: <4E1E2949.30803@joelhalpern.com> Date: Wed, 13 Jul 2011 19:24:57 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Joe Touch References: <4E17210A.1070402@joelhalpern.com> <5662A966-70AD-4A63-BA31-8CE1C9635687@cisco.com> <4E1747BB.8080602@cisco.com> <4E19B2DC.4030003@joelhalpern.com> <4E1CC976.9000007@isi.edu> <4E1CCC76.9090409@cisco.com> <4E1CE644.9090300@isi.edu> <4E1DD654.3030603@joelhalpern.com> <4E1DE2C2.8090209@mti-systems.com> <4E1DE530.5060701@joelhalpern.com> <4E1DEAEB.9040208@isi.edu> <4E1E070F.6000103@joelhalpern.com> <4E1E093D.9040903@isi.edu> <4E1E0D70.7040801@joelhalpern.com> <4E1E23EC.7040502@isi.edu> In-Reply-To: <4E1E23EC.7040502@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Wesley Eddy , "tsv-ads@tools.ietf.org" , IETF discussion list , "karp@ietf.org" Subject: Re: [karp] notes from discussion of KARP design guidelines 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, 13 Jul 2011 23:25:08 -0000 I am not sure what you are asking. KARP is never concerned with whether the party is authorized to send the information it is sending. KARP is concerned with assuring that the information received is either the information sent, or recognizably NOT the information sent (so it can be discarded.) (I would have said that more simply, but I have been beat up by security folks for descriing what authentication does too simply.) It is also concerned that the receiver be able to correctly tell who sent the message, or discard the message. (Which layer those determinations are made at varies across the protocols, and is something we were trying not to get detailed about in the design guidelines document.) Sent and received refer to inforamtion being exchanged between directly communicating IP routers. (Of course, directly depends upon the protocol and configuration, as both targetted LDP and remote BGP the two parties are directly communicating through other routers.) This document is NOT supposed to be the framework document for the KARP work. The working group did not have enough energy to produce that, and I would therefore not want to turn this into a full-blown framework document. With that understanding, if there is an extra paragraph that will help the introduction be clear about this, please send text. Yours, Joel On 7/13/2011 7:02 PM, Joe Touch wrote: > Hi, Joel, > > On 7/13/2011 2:26 PM, Joel M. Halpern wrote: >> You wording seems to induce confusion. >> Of course the routing message content is part of the message >> on-the-wire. It is the content of the message. It is in fact a >> significant part of what is being protected. >> >> What is NOT part of the scope, and which the text says is not part of >> the scope, is the validation of that information. KARP is not assuring >> that the information is valid. it is responsible to ensure that the >> message is not modified between the two peers. >> >> Yes, this means that there is an overlap in protection between >> validation information and packet authentication information.So? The >> scope is very clear as to whose problem is whose. > > That makes absolutely no sense. If there's overlap, then it's obviously > unclear as to whose problem is whose. > >> (This is merely a >> statement of fact. If we have path signing and TCP-AO, there are two >> sets of mechanisms preventing modification of some of the BGP >> information.) > > I appreciate that different layers can include redundant protections. > However, I'm trying to understand what is *expected* from each layer. > >> The text after the bullet list explicitly says what part is in scope. it >> does not require any assumption or inference. >> If there is specific wording you would like to suggest to improve the >> introductory scoping material, I would be happy to look at it. > > Glad to, with a bit more context. > > Can you please define what is being validated in the third bullet that > is NOT protected by the last one or vice versa? AFAICT, it would be: > > #3 is entirely responsible for ensuring that a source has permission to > advertise a particular route > > #3 or #4 could confirm the identity of the source of a piece of > information (#3 is required if transitive, #4 works only if directly > communicated). > > #3 or #4 could confirm the integrity of such information > > #4 is required to protect the properties of lower layers insofar as they > are used as such information to the routing protocol (e.g., BGP tossing > out routes because TCP connections fail). > > If this is the case, then I understand 4 as protecting the *channel* > over which routing messages are exchanged (which ends up protecting the > messages too), and 3 as focusing on the routing layer messages themselves. > > Is that the case? > > Joe > > > >> On 7/13/2011 5:08 PM, Joe Touch wrote: >>> Hi, Joel, >>> >>> On 7/13/2011 1:58 PM, Joel M. Halpern wrote: >>>> I don't understand your description of the problem. >>>> As you quote, the document clearly states its scope. >>>> So, when we then define the term "on-the-wire", I don't think we >>>> need to >>>> restate the scope definition. It woudl seem coutner-productive. >>> >>> The current scope is clear from the bullet list only by the assumption >>> that (a) the bullets are mutually exclusive, and (b) since the "routing >>> message content" is clear, it cannot be part of "on the wire". >>> >>> I.e., it requires the reader interpret scope by a matter of deduction >>> and exclusion, rather than stating it clearly and explicitly. >>> >>> Joe >>> >>>> >>>> Yours, >>>> Joel >>>> >>>> >>>> On 7/13/2011 2:58 PM, Joe Touch wrote: >>>>> >>>>> >>>>> On 7/13/2011 11:34 AM, Joel M. Halpern wrote: >>>>>> As I said in my earlier note proposing responses to Joe, we would be >>>>>> happy to some text in the front clarifying the usage. Quoting from my >>>>>> earlier email: >>>>>> >>>>>> This text would note that it is a widely used term in IETF documents, >>>>>> including many RFCs. It would also state for clarity that in this >>>>>> document it is used to refer to the message sent from one routing >>>>>> process to another. >>>>> >>>>> Here's why this is a problem: >>>>> >>>>> 1- does this refer to signing a BGP path? >>>>> >>>>> 2- does this refer to protecting the channel over which BGP paths are >>>>> exchanged? >>>>> >>>>> From the intro: >>>>> Four main steps were identified for that tightening: >>>>> >>>>> o More secure mechanisms and practices for operating routers. >>>>> ... >>>>> >>>>> o Cleaning up the Internet Routing Registry repository [IRR], >>>>> ... >>>>> >>>>> o Specifications for cryptographic validation of routing message >>>>> content. >>>>> ... >>>>> >>>>> o Securing the routing protocols' packets on the wire >>>>> >>>>> This document addresses the last bullet, securing the packets on the >>>>> wire of the routing protocol exchanges. >>>>> >>>>> So this document is clearly NOT about "the message from one routing >>>>> process to another (that would be 'routing message content', IMO). >>>>> I.e., >>>>> this doc focuses on securing the transfer mechanism NOT the message. >>>>> >>>>> Thus this is the key to the entirety of the doc. This doc needs to be >>>>> very clear about what this is, at which point it can certainly also >>>>> then >>>>> refer back to the original RFC (e.g., "this is referred to in RFC 4948 >>>>> as 'on the wire'"). >>>>> >>>>> Joe >>>>> >>>>> >>>>> >>> > From touch@isi.edu Wed Jul 13 17:00: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 976F121F8B3C; Wed, 13 Jul 2011 17:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.353 X-Spam-Level: X-Spam-Status: No, score=-103.353 tagged_above=-999 required=5 tests=[AWL=-0.754, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Qepsl+aRKwA; Wed, 13 Jul 2011 17:00:13 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 6516821F8B3B; Wed, 13 Jul 2011 17:00:13 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p6DNxlff026880 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 13 Jul 2011 16:59:48 -0700 (PDT) Message-ID: <4E1E3173.2000803@isi.edu> Date: Wed, 13 Jul 2011 16:59:47 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Joel M. Halpern" References: <4E17210A.1070402@joelhalpern.com> <5662A966-70AD-4A63-BA31-8CE1C9635687@cisco.com> <4E1747BB.8080602@cisco.com> <4E19B2DC.4030003@joelhalpern.com> <4E1CC976.9000007@isi.edu> <4E1CCC76.9090409@cisco.com> <4E1CE644.9090300@isi.edu> <4E1DD654.3030603@joelhalpern.com> <4E1DE2C2.8090209@mti-systems.com> <4E1DE530.5060701@joelhalpern.com> <4E1DEAEB.9040208@isi.edu> <4E1E070F.6000103@joelhalpern.com> <4E1E093D.9040903@isi.edu> <4E1E0D70.7040801@joelhalpern.com> <4E1E23EC.7040502@isi.edu> <4E1E2949.30803@joelhalpern.com> In-Reply-To: <4E1E2949.30803@joelhalpern.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: Wesley Eddy , "tsv-ads@tools.ietf.org" , IETF discussion list , "karp@ietf.org" Subject: Re: [karp] notes from discussion of KARP design guidelines 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, 14 Jul 2011 00:00:17 -0000 Hi, Joel, On 7/13/2011 4:24 PM, Joel M. Halpern wrote: > I am not sure what you are asking. > KARP is never concerned with whether the party is authorized to send the > information it is sending. Right - that's bullet 3. > KARP is concerned with assuring that the information received is either > the information sent, or recognizably NOT the information sent (so it > can be discarded.) (I would have said that more simply, but I have been > beat up by security folks for describing what authentication does too > simply.) It is also concerned that the receiver be able to correctly > tell who sent the message, or discard the message. > > (Which layer those determinations are made at varies across the > protocols, and is something we were trying not to get detailed about in > the design guidelines document.) > > Sent and received refer to inforamtion being exchanged between directly > communicating IP routers. (Of course, directly depends upon the protocol > and configuration, as both targetted LDP and remote BGP the two parties > are directly communicating through other routers.) OK - so that's protecting the information exchanged between two routers. I would argue that it also presumes protecting such information whether it's explicit at the routing layer (e.g., BGP path messages), other headers (e.g., src/dst addrs, TTLs, and the like, if relied upon by the routing protocol), and the semantics of other layers of protocols (e.g., whether a connection remains "up", as with TCP or PPTP). > This document is NOT supposed to be the framework document for the KARP > work. The working group did not have enough energy to produce that, and > I would therefore not want to turn this into a full-blown framework > document. > With that understanding, if there is an extra paragraph that will help > the introduction be clear about this, please send text. If we agree on the above, then I can proceed to document suggested changes and the paragraph. Joe > > Yours, > Joel > > On 7/13/2011 7:02 PM, Joe Touch wrote: >> Hi, Joel, >> >> On 7/13/2011 2:26 PM, Joel M. Halpern wrote: >>> You wording seems to induce confusion. >>> Of course the routing message content is part of the message >>> on-the-wire. It is the content of the message. It is in fact a >>> significant part of what is being protected. >>> >>> What is NOT part of the scope, and which the text says is not part of >>> the scope, is the validation of that information. KARP is not assuring >>> that the information is valid. it is responsible to ensure that the >>> message is not modified between the two peers. >>> >>> Yes, this means that there is an overlap in protection between >>> validation information and packet authentication information.So? The >>> scope is very clear as to whose problem is whose. >> >> That makes absolutely no sense. If there's overlap, then it's obviously >> unclear as to whose problem is whose. >> >>> (This is merely a >>> statement of fact. If we have path signing and TCP-AO, there are two >>> sets of mechanisms preventing modification of some of the BGP >>> information.) >> >> I appreciate that different layers can include redundant protections. >> However, I'm trying to understand what is *expected* from each layer. >> >>> The text after the bullet list explicitly says what part is in scope. it >>> does not require any assumption or inference. >>> If there is specific wording you would like to suggest to improve the >>> introductory scoping material, I would be happy to look at it. >> >> Glad to, with a bit more context. >> >> Can you please define what is being validated in the third bullet that >> is NOT protected by the last one or vice versa? AFAICT, it would be: >> >> #3 is entirely responsible for ensuring that a source has permission to >> advertise a particular route >> >> #3 or #4 could confirm the identity of the source of a piece of >> information (#3 is required if transitive, #4 works only if directly >> communicated). >> >> #3 or #4 could confirm the integrity of such information >> >> #4 is required to protect the properties of lower layers insofar as they >> are used as such information to the routing protocol (e.g., BGP tossing >> out routes because TCP connections fail). >> >> If this is the case, then I understand 4 as protecting the *channel* >> over which routing messages are exchanged (which ends up protecting the >> messages too), and 3 as focusing on the routing layer messages >> themselves. >> >> Is that the case? >> >> Joe >> >> >> >>> On 7/13/2011 5:08 PM, Joe Touch wrote: >>>> Hi, Joel, >>>> >>>> On 7/13/2011 1:58 PM, Joel M. Halpern wrote: >>>>> I don't understand your description of the problem. >>>>> As you quote, the document clearly states its scope. >>>>> So, when we then define the term "on-the-wire", I don't think we >>>>> need to >>>>> restate the scope definition. It woudl seem coutner-productive. >>>> >>>> The current scope is clear from the bullet list only by the assumption >>>> that (a) the bullets are mutually exclusive, and (b) since the "routing >>>> message content" is clear, it cannot be part of "on the wire". >>>> >>>> I.e., it requires the reader interpret scope by a matter of deduction >>>> and exclusion, rather than stating it clearly and explicitly. >>>> >>>> Joe >>>> >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> >>>>> On 7/13/2011 2:58 PM, Joe Touch wrote: >>>>>> >>>>>> >>>>>> On 7/13/2011 11:34 AM, Joel M. Halpern wrote: >>>>>>> As I said in my earlier note proposing responses to Joe, we would be >>>>>>> happy to some text in the front clarifying the usage. Quoting >>>>>>> from my >>>>>>> earlier email: >>>>>>> >>>>>>> This text would note that it is a widely used term in IETF >>>>>>> documents, >>>>>>> including many RFCs. It would also state for clarity that in this >>>>>>> document it is used to refer to the message sent from one routing >>>>>>> process to another. >>>>>> >>>>>> Here's why this is a problem: >>>>>> >>>>>> 1- does this refer to signing a BGP path? >>>>>> >>>>>> 2- does this refer to protecting the channel over which BGP paths are >>>>>> exchanged? >>>>>> >>>>>> From the intro: >>>>>> Four main steps were identified for that tightening: >>>>>> >>>>>> o More secure mechanisms and practices for operating routers. >>>>>> ... >>>>>> >>>>>> o Cleaning up the Internet Routing Registry repository [IRR], >>>>>> ... >>>>>> >>>>>> o Specifications for cryptographic validation of routing message >>>>>> content. >>>>>> ... >>>>>> >>>>>> o Securing the routing protocols' packets on the wire >>>>>> >>>>>> This document addresses the last bullet, securing the packets on the >>>>>> wire of the routing protocol exchanges. >>>>>> >>>>>> So this document is clearly NOT about "the message from one routing >>>>>> process to another (that would be 'routing message content', IMO). >>>>>> I.e., >>>>>> this doc focuses on securing the transfer mechanism NOT the message. >>>>>> >>>>>> Thus this is the key to the entirety of the doc. This doc needs to be >>>>>> very clear about what this is, at which point it can certainly also >>>>>> then >>>>>> refer back to the original RFC (e.g., "this is referred to in RFC >>>>>> 4948 >>>>>> as 'on the wire'"). >>>>>> >>>>>> Joe >>>>>> >>>>>> >>>>>> >>>> >> From jmh@joelhalpern.com Wed Jul 13 17:01:29 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 32A5B11E8089; Wed, 13 Jul 2011 17:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uS0wXRUsasxb; Wed, 13 Jul 2011 17:01:28 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id 8A76411E8075; Wed, 13 Jul 2011 17:01:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id CD686325C161; Wed, 13 Jul 2011 17:01:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.154.181.24] (unknown [129.192.185.163]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id C6C85325C15F; Wed, 13 Jul 2011 17:01:25 -0700 (PDT) Message-ID: <4E1E31D1.7060509@joelhalpern.com> Date: Wed, 13 Jul 2011 20:01:21 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Joe Touch References: <4E17210A.1070402@joelhalpern.com> <5662A966-70AD-4A63-BA31-8CE1C9635687@cisco.com> <4E1747BB.8080602@cisco.com> <4E19B2DC.4030003@joelhalpern.com> <4E1CC976.9000007@isi.edu> <4E1CCC76.9090409@cisco.com> <4E1CE644.9090300@isi.edu> <4E1DD654.3030603@joelhalpern.com> <4E1DE2C2.8090209@mti-systems.com> <4E1DE530.5060701@joelhalpern.com> <4E1DEAEB.9040208@isi.edu> <4E1E070F.6000103@joelhalpern.com> <4E1E093D.9040903@isi.edu> <4E1E0D70.7040801@joelhalpern.com> <4E1E23EC.7040502@isi.edu> In-Reply-To: <4E1E23EC.7040502@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Wesley Eddy , "tsv-ads@tools.ietf.org" , IETF discussion list , "karp@ietf.org" Subject: Re: [karp] notes from discussion of KARP design guidelines 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, 14 Jul 2011 00:01:29 -0000 There may be a confusion of objectives. The WG and chairs do not expect the design guidelines document to achieve a degree of thoroughness such taht if one checks every item in there, and nothing else, then one will be able to do a complete analysis of a routing protocol. Rather, it is intended to provide assistance and a starting point for that analysis. Folks writing analysis documents are expected to bring security and routing protocol skills to the table, and to make sure they spot all the issues. Yours, Joel On 7/13/2011 7:02 PM, Joe Touch wrote: > Hi, Joel, > > On 7/13/2011 2:26 PM, Joel M. Halpern wrote: >> You wording seems to induce confusion. >> Of course the routing message content is part of the message >> on-the-wire. It is the content of the message. It is in fact a >> significant part of what is being protected. >> >> What is NOT part of the scope, and which the text says is not part of >> the scope, is the validation of that information. KARP is not assuring >> that the information is valid. it is responsible to ensure that the >> message is not modified between the two peers. >> >> Yes, this means that there is an overlap in protection between >> validation information and packet authentication information.So? The >> scope is very clear as to whose problem is whose. > > That makes absolutely no sense. If there's overlap, then it's obviously > unclear as to whose problem is whose. > >> (This is merely a >> statement of fact. If we have path signing and TCP-AO, there are two >> sets of mechanisms preventing modification of some of the BGP >> information.) > > I appreciate that different layers can include redundant protections. > However, I'm trying to understand what is *expected* from each layer. > >> The text after the bullet list explicitly says what part is in scope. it >> does not require any assumption or inference. >> If there is specific wording you would like to suggest to improve the >> introductory scoping material, I would be happy to look at it. > > Glad to, with a bit more context. > > Can you please define what is being validated in the third bullet that > is NOT protected by the last one or vice versa? AFAICT, it would be: > > #3 is entirely responsible for ensuring that a source has permission to > advertise a particular route > > #3 or #4 could confirm the identity of the source of a piece of > information (#3 is required if transitive, #4 works only if directly > communicated). > > #3 or #4 could confirm the integrity of such information > > #4 is required to protect the properties of lower layers insofar as they > are used as such information to the routing protocol (e.g., BGP tossing > out routes because TCP connections fail). > > If this is the case, then I understand 4 as protecting the *channel* > over which routing messages are exchanged (which ends up protecting the > messages too), and 3 as focusing on the routing layer messages themselves. > > Is that the case? > > Joe > > > >> On 7/13/2011 5:08 PM, Joe Touch wrote: >>> Hi, Joel, >>> >>> On 7/13/2011 1:58 PM, Joel M. Halpern wrote: >>>> I don't understand your description of the problem. >>>> As you quote, the document clearly states its scope. >>>> So, when we then define the term "on-the-wire", I don't think we >>>> need to >>>> restate the scope definition. It woudl seem coutner-productive. >>> >>> The current scope is clear from the bullet list only by the assumption >>> that (a) the bullets are mutually exclusive, and (b) since the "routing >>> message content" is clear, it cannot be part of "on the wire". >>> >>> I.e., it requires the reader interpret scope by a matter of deduction >>> and exclusion, rather than stating it clearly and explicitly. >>> >>> Joe >>> >>>> >>>> Yours, >>>> Joel >>>> >>>> >>>> On 7/13/2011 2:58 PM, Joe Touch wrote: >>>>> >>>>> >>>>> On 7/13/2011 11:34 AM, Joel M. Halpern wrote: >>>>>> As I said in my earlier note proposing responses to Joe, we would be >>>>>> happy to some text in the front clarifying the usage. Quoting from my >>>>>> earlier email: >>>>>> >>>>>> This text would note that it is a widely used term in IETF documents, >>>>>> including many RFCs. It would also state for clarity that in this >>>>>> document it is used to refer to the message sent from one routing >>>>>> process to another. >>>>> >>>>> Here's why this is a problem: >>>>> >>>>> 1- does this refer to signing a BGP path? >>>>> >>>>> 2- does this refer to protecting the channel over which BGP paths are >>>>> exchanged? >>>>> >>>>> From the intro: >>>>> Four main steps were identified for that tightening: >>>>> >>>>> o More secure mechanisms and practices for operating routers. >>>>> ... >>>>> >>>>> o Cleaning up the Internet Routing Registry repository [IRR], >>>>> ... >>>>> >>>>> o Specifications for cryptographic validation of routing message >>>>> content. >>>>> ... >>>>> >>>>> o Securing the routing protocols' packets on the wire >>>>> >>>>> This document addresses the last bullet, securing the packets on the >>>>> wire of the routing protocol exchanges. >>>>> >>>>> So this document is clearly NOT about "the message from one routing >>>>> process to another (that would be 'routing message content', IMO). >>>>> I.e., >>>>> this doc focuses on securing the transfer mechanism NOT the message. >>>>> >>>>> Thus this is the key to the entirety of the doc. This doc needs to be >>>>> very clear about what this is, at which point it can certainly also >>>>> then >>>>> refer back to the original RFC (e.g., "this is referred to in RFC 4948 >>>>> as 'on the wire'"). >>>>> >>>>> Joe >>>>> >>>>> >>>>> >>> > From jmh@joelhalpern.com Wed Jul 13 17:02:45 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 3DEA211E8101; Wed, 13 Jul 2011 17:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TssLKhSiQfXP; Wed, 13 Jul 2011 17:02:44 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1E011E8089; Wed, 13 Jul 2011 17:02:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 7C5C1325C15B; Wed, 13 Jul 2011 17:02:43 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.154.181.24] (unknown [129.192.185.163]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 56A05325C15C; Wed, 13 Jul 2011 17:02:42 -0700 (PDT) Message-ID: <4E1E321E.5010709@joelhalpern.com> Date: Wed, 13 Jul 2011 20:02:38 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Joe Touch References: <4E17210A.1070402@joelhalpern.com> <5662A966-70AD-4A63-BA31-8CE1C9635687@cisco.com> <4E1747BB.8080602@cisco.com> <4E19B2DC.4030003@joelhalpern.com> <4E1CC976.9000007@isi.edu> <4E1CCC76.9090409@cisco.com> <4E1CE644.9090300@isi.edu> <4E1DD654.3030603@joelhalpern.com> <4E1DE2C2.8090209@mti-systems.com> <4E1DE530.5060701@joelhalpern.com> <4E1DEAEB.9040208@isi.edu> <4E1E070F.6000103@joelhalpern.com> <4E1E093D.9040903@isi.edu> <4E1E0D70.7040801@joelhalpern.com> <4E1E23EC.7040502@isi.edu> <4E1E2949.30803@joelhalpern.com> <4E1E3173.2000803@isi.edu> In-Reply-To: <4E1E3173.2000803@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Wesley Eddy , "tsv-ads@tools.ietf.org" , IETF discussion list , "karp@ietf.org" Subject: Re: [karp] notes from discussion of KARP design guidelines 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, 14 Jul 2011 00:02:45 -0000 I am not sure we are in sync, but it looks clsoe enough that proposed introductory text would be veyr helpful at this point. Yours, Joel On 7/13/2011 7:59 PM, Joe Touch wrote: > Hi, Joel, > > On 7/13/2011 4:24 PM, Joel M. Halpern wrote: >> I am not sure what you are asking. >> KARP is never concerned with whether the party is authorized to send the >> information it is sending. > > Right - that's bullet 3. > >> KARP is concerned with assuring that the information received is either >> the information sent, or recognizably NOT the information sent (so it >> can be discarded.) (I would have said that more simply, but I have been >> beat up by security folks for describing what authentication does too >> simply.) It is also concerned that the receiver be able to correctly >> tell who sent the message, or discard the message. >> >> (Which layer those determinations are made at varies across the >> protocols, and is something we were trying not to get detailed about in >> the design guidelines document.) >> >> Sent and received refer to inforamtion being exchanged between directly >> communicating IP routers. (Of course, directly depends upon the protocol >> and configuration, as both targetted LDP and remote BGP the two parties >> are directly communicating through other routers.) > > OK - so that's protecting the information exchanged between two routers. > > I would argue that it also presumes protecting such information whether > it's explicit at the routing layer (e.g., BGP path messages), other > headers (e.g., src/dst addrs, TTLs, and the like, if relied upon by the > routing protocol), and the semantics of other layers of protocols (e.g., > whether a connection remains "up", as with TCP or PPTP). > >> This document is NOT supposed to be the framework document for the KARP >> work. The working group did not have enough energy to produce that, and >> I would therefore not want to turn this into a full-blown framework >> document. >> With that understanding, if there is an extra paragraph that will help >> the introduction be clear about this, please send text. > > If we agree on the above, then I can proceed to document suggested > changes and the paragraph. > > Joe > >> >> Yours, >> Joel >> >> On 7/13/2011 7:02 PM, Joe Touch wrote: >>> Hi, Joel, >>> >>> On 7/13/2011 2:26 PM, Joel M. Halpern wrote: >>>> You wording seems to induce confusion. >>>> Of course the routing message content is part of the message >>>> on-the-wire. It is the content of the message. It is in fact a >>>> significant part of what is being protected. >>>> >>>> What is NOT part of the scope, and which the text says is not part of >>>> the scope, is the validation of that information. KARP is not assuring >>>> that the information is valid. it is responsible to ensure that the >>>> message is not modified between the two peers. >>>> >>>> Yes, this means that there is an overlap in protection between >>>> validation information and packet authentication information.So? The >>>> scope is very clear as to whose problem is whose. >>> >>> That makes absolutely no sense. If there's overlap, then it's obviously >>> unclear as to whose problem is whose. >>> >>>> (This is merely a >>>> statement of fact. If we have path signing and TCP-AO, there are two >>>> sets of mechanisms preventing modification of some of the BGP >>>> information.) >>> >>> I appreciate that different layers can include redundant protections. >>> However, I'm trying to understand what is *expected* from each layer. >>> >>>> The text after the bullet list explicitly says what part is in >>>> scope. it >>>> does not require any assumption or inference. >>>> If there is specific wording you would like to suggest to improve the >>>> introductory scoping material, I would be happy to look at it. >>> >>> Glad to, with a bit more context. >>> >>> Can you please define what is being validated in the third bullet that >>> is NOT protected by the last one or vice versa? AFAICT, it would be: >>> >>> #3 is entirely responsible for ensuring that a source has permission to >>> advertise a particular route >>> >>> #3 or #4 could confirm the identity of the source of a piece of >>> information (#3 is required if transitive, #4 works only if directly >>> communicated). >>> >>> #3 or #4 could confirm the integrity of such information >>> >>> #4 is required to protect the properties of lower layers insofar as they >>> are used as such information to the routing protocol (e.g., BGP tossing >>> out routes because TCP connections fail). >>> >>> If this is the case, then I understand 4 as protecting the *channel* >>> over which routing messages are exchanged (which ends up protecting the >>> messages too), and 3 as focusing on the routing layer messages >>> themselves. >>> >>> Is that the case? >>> >>> Joe >>> >>> >>> >>>> On 7/13/2011 5:08 PM, Joe Touch wrote: >>>>> Hi, Joel, >>>>> >>>>> On 7/13/2011 1:58 PM, Joel M. Halpern wrote: >>>>>> I don't understand your description of the problem. >>>>>> As you quote, the document clearly states its scope. >>>>>> So, when we then define the term "on-the-wire", I don't think we >>>>>> need to >>>>>> restate the scope definition. It woudl seem coutner-productive. >>>>> >>>>> The current scope is clear from the bullet list only by the assumption >>>>> that (a) the bullets are mutually exclusive, and (b) since the >>>>> "routing >>>>> message content" is clear, it cannot be part of "on the wire". >>>>> >>>>> I.e., it requires the reader interpret scope by a matter of deduction >>>>> and exclusion, rather than stating it clearly and explicitly. >>>>> >>>>> Joe >>>>> >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> >>>>>> On 7/13/2011 2:58 PM, Joe Touch wrote: >>>>>>> >>>>>>> >>>>>>> On 7/13/2011 11:34 AM, Joel M. Halpern wrote: >>>>>>>> As I said in my earlier note proposing responses to Joe, we >>>>>>>> would be >>>>>>>> happy to some text in the front clarifying the usage. Quoting >>>>>>>> from my >>>>>>>> earlier email: >>>>>>>> >>>>>>>> This text would note that it is a widely used term in IETF >>>>>>>> documents, >>>>>>>> including many RFCs. It would also state for clarity that in this >>>>>>>> document it is used to refer to the message sent from one routing >>>>>>>> process to another. >>>>>>> >>>>>>> Here's why this is a problem: >>>>>>> >>>>>>> 1- does this refer to signing a BGP path? >>>>>>> >>>>>>> 2- does this refer to protecting the channel over which BGP paths >>>>>>> are >>>>>>> exchanged? >>>>>>> >>>>>>> From the intro: >>>>>>> Four main steps were identified for that tightening: >>>>>>> >>>>>>> o More secure mechanisms and practices for operating routers. >>>>>>> ... >>>>>>> >>>>>>> o Cleaning up the Internet Routing Registry repository [IRR], >>>>>>> ... >>>>>>> >>>>>>> o Specifications for cryptographic validation of routing message >>>>>>> content. >>>>>>> ... >>>>>>> >>>>>>> o Securing the routing protocols' packets on the wire >>>>>>> >>>>>>> This document addresses the last bullet, securing the packets on the >>>>>>> wire of the routing protocol exchanges. >>>>>>> >>>>>>> So this document is clearly NOT about "the message from one routing >>>>>>> process to another (that would be 'routing message content', IMO). >>>>>>> I.e., >>>>>>> this doc focuses on securing the transfer mechanism NOT the message. >>>>>>> >>>>>>> Thus this is the key to the entirety of the doc. This doc needs >>>>>>> to be >>>>>>> very clear about what this is, at which point it can certainly also >>>>>>> then >>>>>>> refer back to the original RFC (e.g., "this is referred to in RFC >>>>>>> 4948 >>>>>>> as 'on the wire'"). >>>>>>> >>>>>>> Joe >>>>>>> >>>>>>> >>>>>>> >>>>> >>> > From iesg-secretary@ietf.org Mon Jul 18 10:05: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 C338721F8BD6; Mon, 18 Jul 2011 10:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.406 X-Spam-Level: X-Spam-Status: No, score=-102.406 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmNOReusfp5t; Mon, 18 Jul 2011 10:05:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDC321F8B8C; Mon, 18 Jul 2011 10:05:09 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110718170509.30053.53766.idtracker@ietfa.amsl.com> Date: Mon, 18 Jul 2011 10:05:09 -0700 Cc: karp@ietf.org Subject: [karp] Last Call: (The Threat Analysis and Requirements for Cryptographic Authentication of Routing Protocols' Transports) to Informational RFC X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 17:05:10 -0000 The IESG has received a request from the Keying and Authentication for Routing Protocols WG (karp) to consider the following document: - 'The Threat Analysis and Requirements for Cryptographic Authentication of Routing Protocols' Transports' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-08-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Different routing protocols exist and each employs its own mechanism for securing the protocol packets on the wire. While most already have some method for accomplishing cryptographic message authentication, in many cases the existing methods are dated, vulnerable to attack, and employ cryptographic algorithms that have been deprecated. The "Keying and Authentication for Routing Protocols" (KARP) effort aims to overhaul and improve these mechanisms. This document has two main parts - the first describes the threat analysis for attacks against routing protocols' transports and the second enumerates the requirements for addressing the described threats. This document, along with the KARP design guide will be used by KARP design teams for specific protocol review and overhaul. This document reflects the input of both the IETF's Security Area and Routing Area in order to form a jointly agreed upon guidance. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/ No IPR declarations have been submitted directly on this I-D. From verozheng@huawei.com Mon Jul 18 20:31:29 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 AF27021F8546 for ; Mon, 18 Jul 2011 20:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5BdKXiVthEa for ; Mon, 18 Jul 2011 20:31:29 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id CB5F321F852C for ; Mon, 18 Jul 2011 20:31:28 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOK00BZB9NTIR@szxga03-in.huawei.com> for karp@ietf.org; Tue, 19 Jul 2011 11:28:41 +0800 (CST) Received: from Z50128Z ([10.110.98.53]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LOK00MH89NOPH@szxga03-in.huawei.com> for karp@ietf.org; Tue, 19 Jul 2011 11:28:41 +0800 (CST) Date: Tue, 19 Jul 2011 11:28:36 +0800 From: Vero Zheng In-reply-to: <7C362EEF9C7896468B36C9B79200D8350CFCF6715D@INBANSXCHMBSA1.in.alcatel-lucent.com> To: karp@ietf.org Message-id: <004401cc45c3$f2326530$d6972f90$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcvyRvNE/utLFXVtS6uugSbqzrtpdhTdS7Jg x-cr-hashedpuzzle: AEfl AVge CJPJ Du6p G/NS Hcy9 HgEO IzKu KB2F Pghs TJy/ TRGQ UTzC UkYA WJ9/ X+b2; 3; awBhAHIAcABAAGkAZQB0AGYALgBvAHIAZwA7AG0AYQBjAGgALgBjAGgAZQBuAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA7AG0AYQBuAGEAdgAuAGIAaABhAHQAaQBhAEAAYQBsAGMAYQB0AGUAbAAtAGwAdQBjAGUAbgB0AC4AYwBvAG0A; Sosha1_v1; 7; {A002D096-A00D-4B79-9644-864CDD113399}; dgBlAHIAbwB6AGgAZQBuAGcAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Tue, 19 Jul 2011 03:28:33 GMT; WwBLAGEAcgBwAF0AIABOAGUAdwAgAFYAZQByAHMAaQBvAG4AIABOAG8AdABpAGYAaQBjAGEAdABpAG8AbgAgAGYAbwByACAAZAByAGEAZgB0AC0AegBoAGUAbgBnAC0AbQBwAGwAcwAtAGwAZABwAC0AaABlAGwAbABvAC0AYwByAHkAcAB0AG8ALQBhAHUAdABoAC0AMAAyAC4AdAB4AHQALAAgAHAAbABlAGEAcwBlACAAYwBvAG0AbQBlAG4AdAAuAA== x-cr-puzzleid: {A002D096-A00D-4B79-9644-864CDD113399} References: <7C362EEF9C7896468B36C9B79200D8350CFCF6715D@INBANSXCHMBSA1.in.alcatel-lucent.com> Subject: [karp] [Karp] New Version Notification for draft-zheng-mpls-ldp-hello-crypto-auth-02.txt, please 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: Tue, 19 Jul 2011 03:31:29 -0000 A new version of I-D, draft-zheng-mpls-ldp-hello-crypto-auth-02.txt has been successfully submitted by Lianshu Zheng and posted to the IETF repository. Abstract: This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well known attacks against the IP header. This document describes how the National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms should be used to secure LDP Hello messages. Hi all, We have submitted the new version of the draft-zheng-mpls-ldp-hello-crypto-auth-02, it could be found at the URL http://tools.ietf.org/html/draft-zheng-mpls-ldp-hello-crypto-auth-02 Per WG discussion, we introduced a 64-bit strictly increasing sequence number that is used to guard against replay attacks. The 64-bit sequence number MUST be incremented for every LDP packet sent by the LDP router. Upon reception, the sequence number MUST be greater than the sequence number in the last LDP packet accepted from the sending LDP neighbor. In case it isnt, the LDP packet is considered a replayed packet and is dropped. LDP routers implementing this specification SHOULD use available mechanisms to preserve the sequence number's strictly increasing property for the deployed life of the LDP router (including cold restarts). Techniques such as sequence number space partitioning and non-volatile storage preservation can be used but are beyond the scope of this specification. We have also fixed the hash computing mistake in this update. Please review it and comment. BR, Mach, Manav and Vero > -----Original Message----- > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > Sent: Monday, April 04, 2011 5:35 AM > To: Mach Chen; zhenglianshu 50128 > Cc: karp@ietf.org > Subject: draft-zheng-mpls-ldp-hello-crypto-auth > > Hi, > > The current version of draft-zheng-mpls-ldp-hello-crypto-auth does not contain > any cryptographic sequence numbers and I spoke to Mach and Vero about this > in Prague. It seems that they were told that replay attacks are not considered > a big deal for LDP. While I can concede that replay attacks are a trifle more > difficult for LDP deployments (mostly service providers environment) I am not > comfortable in developing a solution that precludes the possibility of us ever > supporting this. > > Given this I would like to suggest the following change in the draft: > > We either define a new 4 byte field for crypto-sequence numbers that the > implementations MAY chose to ignore or define two Auth types where one > contains this field and the other doesn't. > > Also I just noticed that the TLV defines Auth Type which indicates the kind of > algo being used. I think this is redundant and I see no need for this given that > we are already carrying a Key ID. > > Cheers, Manav > > -- > Manav Bhatia, > IP Division, Alcatel-Lucent, > Bangalore - India > > From stbryant@cisco.com Tue Jul 19 10:28:07 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 DDD7A21F85EE for ; Tue, 19 Jul 2011 10:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.537 X-Spam-Level: X-Spam-Status: No, score=-110.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpEX0V4v5udg for ; Tue, 19 Jul 2011 10:28:04 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id E869021F85EC for ; Tue, 19 Jul 2011 10:27:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=1800; q=dns/txt; s=iport; t=1311096478; x=1312306078; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=he3kQtIeclm9ACOgz648dov5SSjNU+yRXlrzSIWYz3o=; b=LFvLkDfW0ZO6rZrRz6Rd5RV8bbqUmhpcT2gJQW/2Q06eeNa5p3siJuuU +1t31TRu707EBwVMbnX9UZJP+zJQIEFjmjF9lCZv6yrbtBJL1oNhHEqfA yFy6h3B/jleqnqdAHoB4b+v9rm6Bz+SZjTFo5gc0aeds8relFZ0PWyiO2 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsHANK9JU6Q/khM/2dsb2JhbABUp1BwB64wgxUPAZsshjwEkmeQWw X-IronPort-AV: E=Sophos;i="4.67,229,1309737600"; d="scan'208";a="43386656" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 19 Jul 2011 17:27:56 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6JHRrFe003945; Tue, 19 Jul 2011 17:27:56 GMT Received: from dhcp-gpk02-vlan300-64-103-65-77.cisco.com (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p6JHRrao011862; Tue, 19 Jul 2011 18:27:53 +0100 (BST) Message-ID: <4E25BE99.4000700@cisco.com> Date: Tue, 19 Jul 2011 18:27:53 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "karp@ietf.org" References: <20110719145739.5942.53564.idtracker@ietfa.amsl.com> In-Reply-To: <20110719145739.5942.53564.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20110719145739.5942.53564.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ospf-chairs@tools.ietf.org, "karp-chairs@tools.ietf.org" Subject: [karp] Fwd: [OSPF] Last Call: (Supporting Authentication Trailer for OSPFv3) to Proposed Standard X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com 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, 19 Jul 2011 17:28:08 -0000 KARP WG Please be aware of the following document in IETF Last Call Stewart -------- Original Message -------- Subject: [OSPF] Last Call: (Supporting Authentication Trailer for OSPFv3) to Proposed Standard Date: Tue, 19 Jul 2011 07:57:39 -0700 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce CC: ospf@ietf.org The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'Supporting Authentication Trailer for OSPFv3' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-08-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Currently OSPFv3 uses IPsec for authenticating protocol packets. However, there are some environments, e.g., Mobile Ad-hoc Networks (MANETs), where IPsec is difficult to configure and maintain, and this mechanism cannot be used. This draft proposes an alternative mechanism that can be used so that OSPFv3 does not depend upon IPsec for authentication. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ospf-auth-trailer-ospfv3/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ospf-auth-trailer-ospfv3/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From zhangdacheng@huawei.com Tue Jul 19 18:49:44 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 41EE921F84F1 for ; Tue, 19 Jul 2011 18:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kOemuOc6GDs for ; Tue, 19 Jul 2011 18:49:43 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id A838821F84EC for ; Tue, 19 Jul 2011 18:49:43 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOL00J2KZQTW9@szxga05-in.huawei.com> for karp@ietf.org; Wed, 20 Jul 2011 09:49:41 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOL00MMEZQJYN@szxga05-in.huawei.com> for karp@ietf.org; Wed, 20 Jul 2011 09:49:41 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACJ63883; Wed, 20 Jul 2011 09:49:40 +0800 (CST) Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 20 Jul 2011 09:49:36 +0800 Received: from SZXEML528-MBX.china.huawei.com ([169.254.4.166]) by szxeml410-hub.china.huawei.com ([169.254.101.122]) with mapi id 14.01.0270.001; Wed, 20 Jul 2011 09:49:40 +0800 Date: Wed, 20 Jul 2011 01:49:39 +0000 From: "Dacheng Zhang(Dacheng)" In-reply-to: <004401cc45c3$f2326530$d6972f90$@com> X-Originating-IP: [10.110.98.55] To: "karp@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: Collecting comments on draft-bhatia-zhang-karp-bfd-analysis-01 Thread-index: AQHMRn9J0zYmubOJt0Wcs/SQi5po7g== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <7C362EEF9C7896468B36C9B79200D8350CFCF6715D@INBANSXCHMBSA1.in.alcatel-lucent.com> <004401cc45c3$f2326530$d6972f90$@com> Subject: [karp] Collecting comments on draft-bhatia-zhang-karp-bfd-analysis-01 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, 20 Jul 2011 01:49:44 -0000 Hello, everybody: Manav and I have proposed a draft of the gap analysis on BFD. Analysis of Bidirectional Forwarding Detection (BFD) Security According to KARP Design Guide draft-bhatia-zhang-karp-bfd-analysis-01 Abstract This document analyzes the Bidirectional Forwarding Detection protocol (BFD) according to the guidelines set forth in section 4.2 of draft-ietf-karp-design-guide. We had the draft discussed in the BFD WG and updated it according to the collected comments. Could you please have a look ? Any comments will be appreciated. ^_^ All the best! Dacheng From jmh@joelhalpern.com Wed Jul 20 11:03: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 532A721F8B1E for ; Wed, 20 Jul 2011 11:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJhAlVT3-zOf for ; Wed, 20 Jul 2011 11:03:00 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id 756EC21F8B1C for ; Wed, 20 Jul 2011 11:03:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id D37493245118; Wed, 20 Jul 2011 11:02:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-210.clppva.btas.verizon.net [71.161.50.210]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id D784F325C15E; Wed, 20 Jul 2011 11:02:55 -0700 (PDT) Message-ID: <4E271846.6050003@joelhalpern.com> Date: Wed, 20 Jul 2011 14:02:46 -0400 From: Joel Halpern User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "karp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "George, Wes E \[NTK\]" Subject: [karp] Planned disposition of comments: draft-ietf-karp-design-guide-02 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, 20 Jul 2011 18:03:01 -0000 Joe Touch provided extensive comments on draft-ietf-karp-design-guide-02. There was significant discussion of those comments. Based on the discussion, the chairs propose to direct the authors to make the changes below. These changes are responsive to the ADs request for a new version of the document. 1) Replacement Abstract, basically, remove the majority of the front, and begin, with light editing, at "This document": This document is one of a series of documents 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. 2) Modify the short paragraph after the bulleted list to echo the abstract, and clarify the point of the exclusion. Something like: This document addresses the last bullet, securing the packets on the wire of the routing protocol exchanges. Thus, it is concerned with guidelines for describing issues and techniques for protecting the messages and their contents between directly communicating peers. This may overlap with, but is strongly distinct from, protection designed to ensure that routing information is properly authorized relative to sources of information. Such assurances are provided by other mechanisms and are outside the scope of this document and work that relies on it. 2') After that, add a short paragraph on the term on the wire. Along the lines of: This document uses the terminology "on the wire" to talk about the information used by routing systems. This term is widely used in IETF RFCs, but is used in several different ways. In this document, it is used to refer both to information exchanged between routing protocol instances, and to underlying protocols that may also need to be protected in specific circumstances. Individual protocol analysis documents will need to be more specific in their usage. 3) Add a paragraph on routing protocol transport in the introduction. Something along the lines of: This document refers to routing transport in order to provide a common referent for the varied ways that routing protocols exchange messages. This can be TCP, UDP, or even direct link level messaging in the case of some routing protocols. The term is used here to allow a referent for discussing both common and disparate issues that affect or interact with this dimension of the routing systems. The term is used here to refer generally to the set of mechanisms and exchanges underneath the routing protocol, whatever that is in specific cases. 4) In section 2.1 on Message Transaction Type, please add some additional text noting that there is actually ambiguity in this categorization. Something along the lines of: These categories affect both the routing protocol view of the communication, and the actual message transfer. As a result, some mechanism for some protocols, may be mixtures, for example using broadcast where multicast might be expected, or using serial unicast to deliver what looks to the routing protocol like broadcast or multicast. Protocol analysis documents need to pay attention both to the semantics of the communication, and the actual techniques taht are used for the message exchanges. Thank you, Joel Halpern and Brian Weis From touch@isi.edu Wed Jul 20 11:16: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 79BBB21F8B0B for ; Wed, 20 Jul 2011 11:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.365 X-Spam-Level: X-Spam-Status: No, score=-103.365 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvrxMHl3QFWF for ; Wed, 20 Jul 2011 11:16:53 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id D45D621F8B0A for ; Wed, 20 Jul 2011 11:16:53 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p6KIGU7B004760 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 20 Jul 2011 11:16:30 -0700 (PDT) Message-ID: <4E271B7E.6090404@isi.edu> Date: Wed, 20 Jul 2011 11:16:30 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Joel Halpern References: <4E271846.6050003@joelhalpern.com> In-Reply-To: <4E271846.6050003@joelhalpern.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: "George, Wes E \[NTK\]" , "karp@ietf.org" Subject: Re: [karp] Planned disposition of comments: draft-ietf-karp-design-guide-02 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, 20 Jul 2011 18:16:54 -0000 Hi, Joel (et al.), Thanks for the following. These changes would address most of my concerns, with a small addition below. Note that some would apply to the karp-threats doc as well. Joe On 7/20/2011 11:02 AM, Joel Halpern wrote: > Joe Touch provided extensive comments on draft-ietf-karp-design-guide-02. > There was significant discussion of those comments. Based on the > discussion, the chairs propose to direct the authors to make the changes > below. > These changes are responsive to the ADs request for a new version of the > document. > > 1) Replacement Abstract, basically, remove the majority of the front, > and begin, with light editing, at "This document": > > This document is one of a series of documents 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. > > 2) Modify the short paragraph after the bulleted list to echo the > abstract, and clarify the point of the exclusion. Something like: > > This document addresses the last bullet, securing the packets on the > wire of the routing protocol exchanges. Thus, it is concerned with > guidelines for describing issues and techniques for protecting the > messages and their contents between directly communicating peers. This > may overlap with, but is strongly distinct from, protection designed to > ensure that routing information is properly authorized relative to > sources of information. Such assurances are provided by other mechanisms > and are outside the scope of this document and work that relies on it. > > 2') After that, add a short paragraph on the term on the wire. Along the > lines of: > > This document uses the terminology "on the wire" to talk about the > information used by routing systems. This term is widely used in IETF > RFCs, but is used in several different ways. In this document, it is > used to refer both to information exchanged between routing protocol > instances, and to underlying protocols that may also need to be > protected in specific circumstances. Individual protocol analysis > documents will need to be more specific in their usage. > > 3) Add a paragraph on routing protocol transport in the introduction. > Something along the lines of: > > This document refers to routing transport in order to provide a common > referent for the varied ways that routing protocols exchange messages. > This can be TCP, UDP, or even direct link level messaging in the case of > some routing protocols. The term is used here to allow a referent for > discussing both common and disparate issues that affect or interact with > this dimension of the routing systems. The term is used here to refer > generally to the set of mechanisms and exchanges underneath the routing > protocol, whatever that is in specific cases. > > > 4) In section 2.1 on Message Transaction Type, please add some > additional text noting that there is actually ambiguity in this > categorization. Something along the lines of: > > These categories affect both the routing protocol view of the > communication, and the actual message transfer. As a result, some > mechanism for some protocols, may be mixtures, for example using > broadcast where multicast might be expected, or using serial unicast to > deliver what looks to the routing protocol like broadcast or multicast. > Protocol analysis documents need to pay attention both to the semantics > of the communication, and the actual techniques taht are used for the > message exchanges. This may include any semantics of the communication that impact the routing protocol, such as when source identity or path properties of the communication path are used by the routing algorithm, e.g., as when BGP infers routing table entry quality from the persistence of the TCP connection over which they are received. > > Thank you, > Joel Halpern and Brian Weis From jmh@joelhalpern.com Wed Jul 20 11:53: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 27A6A21F8ABE for ; Wed, 20 Jul 2011 11:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzeB8bC51TIC for ; Wed, 20 Jul 2011 11:53:04 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id 8E08821F8AA8 for ; Wed, 20 Jul 2011 11:53:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id EFEC53228BEB; Wed, 20 Jul 2011 11:53:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-210.clppva.btas.verizon.net [71.161.50.210]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 285C332466F0; Wed, 20 Jul 2011 11:53:02 -0700 (PDT) Message-ID: <4E272405.1030705@joelhalpern.com> Date: Wed, 20 Jul 2011 14:52:53 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Joe Touch References: <4E271846.6050003@joelhalpern.com> <4E271B7E.6090404@isi.edu> In-Reply-To: <4E271B7E.6090404@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "George, Wes E \[NTK\]" , "karp@ietf.org" Subject: Re: [karp] Planned disposition of comments: draft-ietf-karp-design-guide-02 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, 20 Jul 2011 18:53:05 -0000 Authors, the suggested amendment seems to improve the text. Please use it. Thanks Joe. Yours, Joel On 7/20/2011 2:16 PM, Joe Touch wrote: > Hi, Joel (et al.), > > Thanks for the following. These changes would address most of my > concerns, with a small addition below. > > Note that some would apply to the karp-threats doc as well. > > Joe > ... >> 4) In section 2.1 on Message Transaction Type, please add some >> additional text noting that there is actually ambiguity in this >> categorization. Something along the lines of: >> >> These categories affect both the routing protocol view of the >> communication, and the actual message transfer. As a result, some >> mechanism for some protocols, may be mixtures, for example using >> broadcast where multicast might be expected, or using serial unicast to >> deliver what looks to the routing protocol like broadcast or multicast. >> Protocol analysis documents need to pay attention both to the semantics >> of the communication, and the actual techniques taht are used for the >> message exchanges. > > This may include any semantics of the communication that impact the > routing protocol, such as when source identity or path properties of the > communication path are used by the routing algorithm, e.g., as when BGP > infers routing table entry quality from the persistence of the TCP > connection over which they are received. > >> >> Thank you, >> Joel Halpern and Brian Weis > From manav.bhatia@alcatel-lucent.com Wed Jul 20 16:40:23 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 790A621F8877 for ; Wed, 20 Jul 2011 16:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNepTmIGVdyd for ; Wed, 20 Jul 2011 16:40:23 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id E7C8D21F880C for ; Wed, 20 Jul 2011 16:40:22 -0700 (PDT) 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 p6KNeIXm020773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Jul 2011 18:40:20 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6KNeGVa031406 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Jul 2011 05:10:16 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.59]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 21 Jul 2011 05:10:15 +0530 From: "Bhatia, Manav (Manav)" To: "Joel M. Halpern" , Joe Touch Date: Thu, 21 Jul 2011 05:10:14 +0530 Thread-Topic: [karp] Planned disposition of comments: draft-ietf-karp-design-guide-02 Thread-Index: AcxHDkSiV8B8bb4gRNObWHsEzJSrJQAJ/s7w Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFEBFBC1D@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4E271846.6050003@joelhalpern.com> <4E271B7E.6090404@isi.edu> <4E272405.1030705@joelhalpern.com> In-Reply-To: <4E272405.1030705@joelhalpern.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.33 Cc: "George, Wes E \[NTK\]" , "karp@ietf.org" Subject: Re: [karp] Planned disposition of comments: draft-ietf-karp-design-guide-02 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, 20 Jul 2011 23:40:23 -0000 It certainly does - will update the draft with these comments and post a re= vised ID soon. Cheers, Manav=20 > -----Original Message----- > From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On=20 > Behalf Of Joel M. Halpern > Sent: Thursday, July 21, 2011 12.23 AM > To: Joe Touch > Cc: George, Wes E [NTK]; karp@ietf.org > Subject: Re: [karp] Planned disposition of comments:=20 > draft-ietf-karp-design-guide-02 >=20 > Authors, the suggested amendment seems to improve the text. =20 > Please use it. >=20 > Thanks Joe. > Yours, > Joel >=20 > On 7/20/2011 2:16 PM, Joe Touch wrote: > > Hi, Joel (et al.), > > > > Thanks for the following. These changes would address most of my > > concerns, with a small addition below. > > > > Note that some would apply to the karp-threats doc as well. > > > > Joe > > > ... > >> 4) In section 2.1 on Message Transaction Type, please add some > >> additional text noting that there is actually ambiguity in this > >> categorization. Something along the lines of: > >> > >> These categories affect both the routing protocol view of the > >> communication, and the actual message transfer. As a result, some > >> mechanism for some protocols, may be mixtures, for example using > >> broadcast where multicast might be expected, or using=20 > serial unicast to > >> deliver what looks to the routing protocol like broadcast=20 > or multicast. > >> Protocol analysis documents need to pay attention both to=20 > the semantics > >> of the communication, and the actual techniques taht are=20 > used for the > >> message exchanges. > > > > This may include any semantics of the communication that impact the > > routing protocol, such as when source identity or path=20 > properties of the > > communication path are used by the routing algorithm, e.g.,=20 > as when BGP > > infers routing table entry quality from the persistence of the TCP > > connection over which they are received. > > > >> > >> Thank you, > >> Joel Halpern and Brian Weis > > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > = From jmh@joelhalpern.com Thu Jul 21 22:19:35 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 B6AE021F85A1 for ; Thu, 21 Jul 2011 22:19:35 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81e4HQlT2SOB for ; Thu, 21 Jul 2011 22:19:35 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAF121F8599 for ; Thu, 21 Jul 2011 22:19:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 6F9D3325C155 for ; Thu, 21 Jul 2011 22:19:34 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.0.0.120] (unknown [12.228.245.151]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 77DAB3245025 for ; Thu, 21 Jul 2011 22:19:31 -0700 (PDT) Message-ID: <4E290854.1030201@joelhalpern.com> Date: Fri, 22 Jul 2011 01:19:16 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "karp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [karp] Minute taker 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, 22 Jul 2011 05:19:35 -0000 The KARP WG session is Wednesday, July 27 from 1300-1500. The current agenda is at http://www.ietf.org/proceedings/81/agenda/karp.html We need someone to take minutes. Please! Thank you, Joel From jhaas@slice.pfrc.org Wed Jul 27 11:39: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 A777321F8B73; Wed, 27 Jul 2011 11:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+ttiksgYGRI; Wed, 27 Jul 2011 11:39:42 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 284D221F8B6B; Wed, 27 Jul 2011 11:39:42 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id EBC762240C9; Wed, 27 Jul 2011 18:45:00 +0000 (UTC) Date: Wed, 27 Jul 2011 18:45:00 +0000 From: Jeffrey Haas To: karp@ietf.org, rtg-bfd@ietf.org Message-ID: <20110727184500.GA3056@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [karp] BFD authentication documents of interest to 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: Wed, 27 Jul 2011 18:39:42 -0000 As per the IETF 81 KARP session, Manav has a document that is intended to address some of the security gap issues for BFD: http://tools.ietf.org/html/draft-bhatia-bfd-crypto-auth-03 This document should be adopted as a WG item in BFD once our charter clears IESG. Please note that the authors were requested to split the document into two components: 1. The SHA-2 procedures 2. The generic keying mechanism. Please examine these documents for coverage of issues found in the KARP reviews. If there are additional gaps, consider if they are appropriate to include in the above documents or require a new document in BFD. -- Jeff (speaking as chair) From mjethanandani@gmail.com Wed Jul 27 11:56: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 9D39611E80AD; Wed, 27 Jul 2011 11:56:28 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJOWKkNFsPZF; Wed, 27 Jul 2011 11:56:28 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 43A1521F8733; Wed, 27 Jul 2011 11:56:27 -0700 (PDT) Received: by wyj26 with SMTP id 26so1203945wyj.31 for ; Wed, 27 Jul 2011 11:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type; bh=yrj4dUE2Ql5VWw1gn5hcGzkF+odZ0yfzcckHpWMwohY=; b=qmryM2GNMPds6gTKgaG9MN2cNS9xK5LlJ/cdbbokCS4RZE1CsFMSARaS22k6Db0Ycc kGdQiJbp9dMnpTZT/S1HFqiDWH5rGrvL5+8wqd8tGBQUVZ4kw78HicGOjZ48BHrNkreY 26eMFGiPNLdOVU0dwcbntWBnrKV6y5ysjji2o= Received: by 10.217.3.17 with SMTP id q17mr37093wes.107.1311792983943; Wed, 27 Jul 2011 11:56:23 -0700 (PDT) References: <20110727184500.GA3056@slice> From: Mahesh Jethanandani In-Reply-To: <20110727184500.GA3056@slice> Mime-Version: 1.0 (iPhone Mail 8G4) Date: Wed, 27 Jul 2011 11:56:15 -0700 Message-ID: <-1579726451630081949@unknownmsgid> To: Jeffrey Haas Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtg-bfd@ietf.org" , "karp@ietf.org" Subject: Re: [karp] BFD authentication documents of interest to 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: Wed, 27 Jul 2011 18:56:28 -0000 I see a general need for key management for all routing/signaling protocols that are either connection oriented or connectionless. Would it make sense to combine efforts? I know that Vero presented a LDP Hello draft today that is based on UDP. Could that be extended to cover all of UDP based protocols and BFD? On Jul 27, 2011, at 11:39 AM, Jeffrey Haas wrote: > As per the IETF 81 KARP session, Manav has a document that is intended to address > some of the security gap issues for BFD: > > http://tools.ietf.org/html/draft-bhatia-bfd-crypto-auth-03 > > This document should be adopted as a WG item in BFD once our charter clears > IESG. Please note that the authors were requested to split the document > into two components: > 1. The SHA-2 procedures > 2. The generic keying mechanism. > > Please examine these documents for coverage of issues found in the KARP > reviews. If there are additional gaps, consider if they are appropriate to > include in the above documents or require a new document in BFD. > > -- Jeff (speaking as chair) > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp From vishwas.ietf@gmail.com Wed Jul 27 12:35: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 F250811E8075; Wed, 27 Jul 2011 12:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=0.970, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTBzHuiFUbD1; Wed, 27 Jul 2011 12:35:37 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0807C11E8084; Wed, 27 Jul 2011 12:35:36 -0700 (PDT) Received: by vxi40 with SMTP id 40so1776007vxi.31 for ; Wed, 27 Jul 2011 12:35:36 -0700 (PDT) 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; bh=WU+MDwJIYKhD+YCqDZgFLzd/+9Km7yZg5oblJZEYnJE=; b=AYVI59NRW/cCHI7BZrF1gU/btTJgQjIvkTCTlUK1r74KxtnM20Itfz3kyKp2Rshb7g aMu9jH+zu88n5G2YtL6N3ZCq2DlfQhbcF5bz6kftObwqTn1o/t4D5xTFX5zkDSL79rp2 Qa+Ar42sLViyfu84EG3qg98ymZEy3byWAbrG8= MIME-Version: 1.0 Received: by 10.52.185.40 with SMTP id ez8mr244022vdc.112.1311795336387; Wed, 27 Jul 2011 12:35:36 -0700 (PDT) Received: by 10.52.158.234 with HTTP; Wed, 27 Jul 2011 12:35:36 -0700 (PDT) In-Reply-To: <-1579726451630081949@unknownmsgid> References: <20110727184500.GA3056@slice> <-1579726451630081949@unknownmsgid> Date: Wed, 27 Jul 2011 12:35:36 -0700 Message-ID: From: Vishwas Manral To: Mahesh Jethanandani Content-Type: multipart/alternative; boundary=bcaec547c61d0b1c6c04a912272b Cc: "rtg-bfd@ietf.org" , "karp@ietf.org" Subject: Re: [karp] BFD authentication documents of interest to 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: Wed, 27 Jul 2011 19:35:39 -0000 --bcaec547c61d0b1c6c04a912272b Content-Type: text/plain; charset=ISO-8859-1 Hi Mahesh, BFD does not only run on UDP, look at the work for BFD for MPLS-TP networks. One of the advantages of BFD is that protocol packets do not contain any transport specific information.:) With that said I agree if there was a mechanism to secure messages over UDP, that would be better then do the same for every protocol over UDP. Thanks, Vishwas On Wed, Jul 27, 2011 at 11:56 AM, Mahesh Jethanandani < mjethanandani@gmail.com> wrote: > I see a general need for key management for all routing/signaling > protocols that are either connection oriented or connectionless. Would > it make sense to combine efforts? I know that Vero presented a LDP > Hello draft today that is based on UDP. Could that be extended to > cover all of UDP based protocols and BFD? > > On Jul 27, 2011, at 11:39 AM, Jeffrey Haas wrote: > > > As per the IETF 81 KARP session, Manav has a document that is intended to > address > > some of the security gap issues for BFD: > > > > http://tools.ietf.org/html/draft-bhatia-bfd-crypto-auth-03 > > > > This document should be adopted as a WG item in BFD once our charter > clears > > IESG. Please note that the authors were requested to split the document > > into two components: > > 1. The SHA-2 procedures > > 2. The generic keying mechanism. > > > > Please examine these documents for coverage of issues found in the KARP > > reviews. If there are additional gaps, consider if they are appropriate > to > > include in the above documents or require a new document in BFD. > > > > -- Jeff (speaking as chair) > > _______________________________________________ > > 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 > --bcaec547c61d0b1c6c04a912272b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Mahesh,
=A0
BFD does not only run on UDP, look at the work for BFD for MPLS-TP net= works. One of the advantages of BFD is that protocol packets do not contain= any transport specific information.:)
=A0
With that said I agree if there was a mechanism to secure messages ove= r UDP, that would be better then do the same for every protocol over UDP.
=A0
Thanks,
Vishwas
On Wed, Jul 27, 2011 at 11:56 AM, Mahesh Jethana= ndani <mjet= hanandani@gmail.com> wrote:
I see a general need for key man= agement for all routing/signaling
protocols that are either connection o= riented or connectionless. Would
it make sense to combine efforts? I know that Vero presented a LDP
Hello= draft today that is based on UDP. Could that be extended to
cover all o= f UDP based protocols and BFD?

On Jul 27, 2011, at 11:39 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:

> As pe= r the IETF 81 KARP session, Manav has a document that is intended to addres= s
> some of the security gap issues for BFD:
>
> http://tools.ietf.org/html/draft-bhatia-bfd-crypto-auth-03
>
> This document should be adopted as a WG item in BFD once our charter c= lears
> IESG. =A0Please note that the authors were requested to split= the document
> into two components:
> 1. The SHA-2 procedures<= br> > 2. The generic keying mechanism.
>
> Please examine these = documents for coverage of issues found in the KARP
> reviews. =A0If t= here are additional gaps, consider if they are appropriate to
> inclu= de in the above documents or require a new document in BFD.
>
> -- Jeff (speaking as chair)
> __________________________= _____________________
> karp mailing list
> karp@ietf.org
> https://www.ietf.org/mailman/listinfo= /karp
_______________________________________________
karp mailing list
karp@ietf.org
https://www.ietf.org/mailm= an/listinfo/karp

--bcaec547c61d0b1c6c04a912272b-- From jmh@joelhalpern.com Wed Jul 27 12:38:59 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 EC5FE5E8028 for ; Wed, 27 Jul 2011 12:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rM+g+TELyYJ for ; Wed, 27 Jul 2011 12:38:59 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id 557505E800B for ; Wed, 27 Jul 2011 12:38:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 375CE3245901 for ; Wed, 27 Jul 2011 12:38:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [130.129.38.181] (dhcp-26b5.meeting.ietf.org [130.129.38.181]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id F1C783244FB4 for ; Wed, 27 Jul 2011 12:38:57 -0700 (PDT) Message-ID: <4E30694F.4000202@joelhalpern.com> Date: Wed, 27 Jul 2011 15:38:55 -0400 From: Joel Halpern User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "karp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [karp] Draft - PIM Gap Analysis - "extra license" 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, 27 Jul 2011 19:39:00 -0000 The presentation on the PIM Gap Analysis discussed, as one of the gaps, that some vendors charge more for IPSec on some products. This is alluded to in the text. The chairs opinion, and the rough consensus of the room, is that discussions of vendor charging should not be included in the document. Including this is a bad idea since business may engage in whatever business practices they choose, relative to any products. We need to focus on the technical limitations of the current state. This note is to determine whether the mailing list agrees with that. Please comment promptly. We expect to direct the authors to remove the text if they wish the document to be considered as a working group document. Yours, Joel From michael_barnes@usa.net Wed Jul 27 12:43:27 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 C0C9111E8084 for ; Wed, 27 Jul 2011 12:43:27 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZrAGUhGeIjj for ; Wed, 27 Jul 2011 12:43:26 -0700 (PDT) Received: from cmsout01.mbox.net (cmsout01.mbox.net [165.212.64.31]) by ietfa.amsl.com (Postfix) with ESMTP id BAFFC11E8073 for ; Wed, 27 Jul 2011 12:43:26 -0700 (PDT) Received: from cmsout01.mbox.net (cmsout01-lo [127.0.0.1]) by cmsout01.mbox.net (Postfix) with ESMTP id DA6292ACE39; Wed, 27 Jul 2011 19:43:25 +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 286PgATrX8288M01; Wed, 27 Jul 2011 19:43:23 -0000 X-USANET-Routed: 3 gwsout-vs Q:bmvirus Received: from cmsapps01.cms.usa.net [165.212.11.136] by cmsout01.mbox.net via smtad (C8.MAIN.3.72B) with ESMTP id XID290PgATrX1586X01; Wed, 27 Jul 2011 19:43:23 -0000 X-USANET-Source: 165.212.11.136 IN michael_barnes@usa.net cmsapps01.cms.usa.net X-USANET-MsgId: XID290PgATrX1586X01 Received: from web03.cms.usa.net [165.212.8.203] by cmsapps01.cms.usa.net (ESMTP/michael_barnes@usa.net) via mtad (C8.MAIN.3.72B) with ESMTP id 389PgATrX3168M36; Wed, 27 Jul 2011 19:43:23 -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.75F); Wed, 27 Jul 2011 19:43:23 -0000 Date: Wed, 27 Jul 2011 12:43:23 -0700 From: "Michael Barnes" To: Joel Halpern , "karp@ietf.org" X-Mailer: USANET web-mailer (C8.MAIN.3.75F) Mime-Version: 1.0 Message-ID: <975PgATQX8592S03.1311795803@web03.cms.usa.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Z-USANET-MsgId: XID389PgATrX3168X36 Subject: Re: [karp] Draft - PIM Gap Analysis - "extra license" 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, 27 Jul 2011 19:43:27 -0000 Agree that the document should not consider business practices by vendors= =2E Business policies can and do change, so a technical solution should not b= e based on them. Regards, Michael ------ Original Message ------ Received: Wed, 27 Jul 2011 12:39:10 PM PDT From: Joel Halpern To: "karp@ietf.org" Subject: [karp] Draft - PIM Gap Analysis - "extra license" > The presentation on the PIM Gap Analysis discussed, as one of the gaps,= = > that some vendors charge more for IPSec on some products. > = > This is alluded to in the text. > = > The chairs opinion, and the rough consensus of the room, is that = > discussions of vendor charging should not be included in the document. > = > Including this is a bad idea since business may engage in whatever = > business practices they choose, relative to any products. > We need to focus on the technical limitations of the current state. > = > This note is to determine whether the mailing list agrees with that. > = > Please comment promptly. We expect to direct the authors to remove the= = > text if they wish the document to be considered as a working group document. > = > Yours, > Joel > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp From tnadeau@lucidvision.com Wed Jul 27 12:46: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 578EC11E812F; Wed, 27 Jul 2011 12:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.927 X-Spam-Level: X-Spam-Status: No, score=-0.927 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYiKl5WKRENe; Wed, 27 Jul 2011 12:46:27 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7B35811E8114; Wed, 27 Jul 2011 12:46:27 -0700 (PDT) Received: from [130.129.19.44] (dhcp-132c.meeting.ietf.org [130.129.19.44]) by lucidvision.com (Postfix) with ESMTP id 047C71D2D2CF; Wed, 27 Jul 2011 15:46:27 -0400 (EDT) References: <20110727184500.GA3056@slice> <-1579726451630081949@unknownmsgid> In-Reply-To: Mime-Version: 1.0 (iPad Mail 8J2) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-19-628845124 Message-Id: <8C43BB8E-5428-4A63-9207-0FB362373CDD@lucidvision.com> X-Mailer: iPad Mail (8J2) From: Thomas Nadeau Date: Wed, 27 Jul 2011 15:46:49 -0400 To: Vishwas Manral X-Mailman-Approved-At: Wed, 27 Jul 2011 13:03:06 -0700 Cc: "rtg-bfd@ietf.org" , "karp@ietf.org" Subject: Re: [karp] BFD authentication documents of interest to 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: Wed, 27 Jul 2011 19:46:28 -0000 --Apple-Mail-19-628845124 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii BFD also runs inside of pseudo wires ala VCCV and natively inside of MPLS, s= o I think you have your work cutout if you want to go down this path. Tom On Jul 27, 2011, at 3:35 PM, Vishwas Manral wrote: > Hi Mahesh, > =20 > BFD does not only run on UDP, look at the work for BFD for MPLS-TP network= s. One of the advantages of BFD is that protocol packets do not contain any t= ransport specific information.:) > =20 > With that said I agree if there was a mechanism to secure messages over UD= P, that would be better then do the same for every protocol over UDP. > =20 > Thanks, > Vishwas > On Wed, Jul 27, 2011 at 11:56 AM, Mahesh Jethanandani wrote: > I see a general need for key management for all routing/signaling > protocols that are either connection oriented or connectionless. Would > it make sense to combine efforts? I know that Vero presented a LDP > Hello draft today that is based on UDP. Could that be extended to > cover all of UDP based protocols and BFD? >=20 > On Jul 27, 2011, at 11:39 AM, Jeffrey Haas wrote: >=20 > > As per the IETF 81 KARP session, Manav has a document that is intended t= o address > > some of the security gap issues for BFD: > > > > http://tools.ietf.org/html/draft-bhatia-bfd-crypto-auth-03 > > > > This document should be adopted as a WG item in BFD once our charter cle= ars > > IESG. Please note that the authors were requested to split the document= > > into two components: > > 1. The SHA-2 procedures > > 2. The generic keying mechanism. > > > > Please examine these documents for coverage of issues found in the KARP > > reviews. If there are additional gaps, consider if they are appropriate= to > > include in the above documents or require a new document in BFD. > > > > -- Jeff (speaking as chair) > > _______________________________________________ > > 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 >=20 --Apple-Mail-19-628845124 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
BFD also runs inside of pseudo wires ala VCCV and natively inside of MPLS, so I think you have your work cutout if you want to go down this path.

Tom



On Jul 27, 2011, at 3:35 PM, Vishwas Manral <vishwas.ietf@gmail.com> wrote:

Hi Mahesh,
 
BFD does not only run on UDP, look at the work for BFD for MPLS-TP networks. One of the advantages of BFD is that protocol packets do not contain any transport specific information.:)
 
With that said I agree if there was a mechanism to secure messages over UDP, that would be better then do the same for every protocol over UDP.
 
Thanks,
Vishwas
On Wed, Jul 27, 2011 at 11:56 AM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
I see a general need for key management for all routing/signaling
protocols that are either connection oriented or connectionless. Would
it make sense to combine efforts? I know that Vero presented a LDP
Hello draft today that is based on UDP. Could that be extended to
cover all of UDP based protocols and BFD?

On Jul 27, 2011, at 11:39 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:

> As per the IETF 81 KARP session, Manav has a document that is intended to address
> some of the security gap issues for BFD:
>
> http://tools.ietf.org/html/draft-bhatia-bfd-crypto-auth-03
>
> This document should be adopted as a WG item in BFD once our charter clears
> IESG.  Please note that the authors were requested to split the document
> into two components:
> 1. The SHA-2 procedures
> 2. The generic keying mechanism.
>
> Please examine these documents for coverage of issues found in the KARP
> reviews.  If there are additional gaps, consider if they are appropriate to
> include in the above documents or require a new document in BFD.
>
> -- Jeff (speaking as chair)
> _______________________________________________
> 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

--Apple-Mail-19-628845124-- From kent@bbn.com Wed Jul 27 13:09:18 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 2A48421F8AE9 for ; Wed, 27 Jul 2011 13:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.567 X-Spam-Level: X-Spam-Status: No, score=-106.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRZVYfu32wlg for ; Wed, 27 Jul 2011 13:09:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2376F21F8AE4 for ; Wed, 27 Jul 2011 13:09:16 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:50724 helo=[130.129.18.170]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QmAPs-000Jew-89; Wed, 27 Jul 2011 16:09:16 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4E30694F.4000202@joelhalpern.com> References: <4E30694F.4000202@joelhalpern.com> Date: Wed, 27 Jul 2011 16:04:43 -0400 To: Joel Halpern From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "karp@ietf.org" Subject: Re: [karp] Draft - PIM Gap Analysis - "extra license" 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, 27 Jul 2011 20:09:18 -0000 At 3:38 PM -0400 7/27/11, Joel Halpern wrote: >The presentation on the PIM Gap Analysis discussed, as one of the >gaps, that some vendors charge more for IPSec on some products. > >This is alluded to in the text. > >The chairs opinion, and the rough consensus of the room, is that >discussions of vendor charging should not be included in the >document. > >Including this is a bad idea since business may engage in whatever >business practices they choose, relative to any products. >We need to focus on the technical limitations of the current state. > >This note is to determine whether the mailing list agrees with that. > >Please comment promptly. We expect to direct the authors to remove >the text if they wish the document to be considered as a working >group document. > >Yours, >Joel I agree with the conclusion to exclude pricing from the gap analysis. Steve P.S. The IETF standard is spelled IPsec, not IPSec :-) Maybe IPSec costs more. From wei.yinxing@zte.com.cn Wed Jul 27 19:57:32 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 916E721F8AE9 for ; Wed, 27 Jul 2011 19:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOWgpScPCzlz for ; Wed, 27 Jul 2011 19:57:32 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9018621F8ADE for ; Wed, 27 Jul 2011 19:57:31 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 13132536813104; Thu, 28 Jul 2011 10:48:54 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 66715.536813104; Thu, 28 Jul 2011 10:57:03 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p6S2v8SW045989 for ; Thu, 28 Jul 2011 10:57:08 +0800 (GMT-8) (envelope-from wei.yinxing@zte.com.cn) MIME-Version: 1.0 To: karp@ietf.org X-KeepSent: 67EC8771:C81BC546-482578DB:000F3965; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wei.yinxing@zte.com.cn Date: Thu, 28 Jul 2011 10:56:37 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-28 10:57:09, Serialize complete at 2011-07-28 10:57:09 Content-Type: multipart/alternative; boundary="=_alternative 001037B8482578DB_=" X-MAIL: mse02.zte.com.cn p6S2v8SW045989 Subject: [karp] A new draft about RSVP-TE gap analysis is submitted, please review it. 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, 28 Jul 2011 02:57:32 -0000 This is a multipart message in MIME format. --=_alternative 001037B8482578DB_= Content-Type: text/plain; charset="US-ASCII" Hi, all RSVP-TE gap analysis is submitted, which is is available at http://tools.ietf.org/id/draft-wei-karp-rsvp-te-analysis-00.txt. please review it. Any comments are welcome. Filename: draft-wei-karp-rsvp-te-analysis Revision: 00 Title: Analysis of Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) Security According to KARP Design Guide Creation date: 2011-07-27 WG ID: Individual Submission Number of pages: 8 Abstract: This document analyzes Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) security according to the guidelines set forth in the KARP Design Guide. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 001037B8482578DB_= Content-Type: text/html; charset="US-ASCII"
Hi, all

  RSVP-TE gap analysis is submitted, which is is available at http://tools.ietf.org/id/draft-wei-karp-rsvp-te-analysis-00.txt. please review it. Any comments are welcome.

Filename:                  draft-wei-karp-rsvp-te-analysis
Revision:                  00
Title:                                   Analysis of Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) Security According to KARP Design Guide
Creation date:                  2011-07-27
WG ID:                                   Individual Submission
Number of pages: 8

Abstract:
  This document analyzes Resource ReSerVation Protocol-Traffic
  Engineering (RSVP-TE) security according to the guidelines set forth
  in the KARP Design Guide.
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 001037B8482578DB_=-- From manav.bhatia@alcatel-lucent.com Wed Jul 27 20:32: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 CDE1921F8891 for ; Wed, 27 Jul 2011 20:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9ElB49BkV5Q for ; Wed, 27 Jul 2011 20:32:30 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 36D7021F8880 for ; Wed, 27 Jul 2011 20:32:30 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p6S3WQiW018210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 27 Jul 2011 22:32:29 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6S3WPGO004984 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 28 Jul 2011 09:02:26 +0530 Received: from [135.250.26.32] (135.250.19.8) by INBANSXCHHUB01.in.alcatel-lucent.com (135.250.12.32) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 28 Jul 2011 09:02:26 +0530 Message-ID: <4E30D7EC.1040000@alcatel-lucent.com> Date: Thu, 28 Jul 2011 09:00:52 +0530 From: Manav Bhatia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 ThunderBrowse/3.8 MIME-Version: 1.0 To: References: <4E30694F.4000202@joelhalpern.com> In-Reply-To: <4E30694F.4000202@joelhalpern.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [karp] Draft - PIM Gap Analysis - "extra license" 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, 28 Jul 2011 03:32:30 -0000 Hi Joel, I had included this point as one of the reasons why PIM-SM security is not being being used by some folks. If the WG believes it ought to be removed then i will do that in the next revision. Are there any more comments besides this? Cheers, Manav On 7/28/2011 1:08 AM, Joel Halpern wrote: > The presentation on the PIM Gap Analysis discussed, as one of the gaps, > that some vendors charge more for IPSec on some products. > > This is alluded to in the text. > > The chairs opinion, and the rough consensus of the room, is that > discussions of vendor charging should not be included in the document. > > Including this is a bad idea since business may engage in whatever > business practices they choose, relative to any products. > We need to focus on the technical limitations of the current state. > > This note is to determine whether the mailing list agrees with that. > > Please comment promptly. We expect to direct the authors to remove the > text if they wish the document to be considered as a working group document. > > Yours, > Joel > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp From mjethanandani@gmail.com Wed Jul 27 23:02: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 93D6611E80BC for ; Wed, 27 Jul 2011 23:02:54 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOGDCAVKremm for ; Wed, 27 Jul 2011 23:02:54 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2427111E80B1 for ; Wed, 27 Jul 2011 23:02:54 -0700 (PDT) Received: by iye7 with SMTP id 7so3036725iye.31 for ; Wed, 27 Jul 2011 23:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=sMu9juvXSmTOiGO0FZhYy2CNdDJtmr92kjJK8cK8sHU=; b=BULbHPs6X4NmHgOa0nH+Rfhgr2lyRUTvN+L3VErhSu7Nz8JNdLx7QkATlk9kxCwsM7 s7EDwuyE9jkmqzowU1xcaD8gVyzRe3t5wPBsbQeL41mqKdN3m4UNbEqHFJKLa2WxRHaf qIoAa7Ej6u9hYOrM7I/KLXIdsbzNM2JPEr9K4= Received: by 10.231.113.33 with SMTP id y33mr444518ibp.62.1311832968085; Wed, 27 Jul 2011 23:02:48 -0700 (PDT) Received: from [192.168.1.147] (c-24-6-173-225.hsd1.ca.comcast.net [24.6.173.225]) by mx.google.com with ESMTPS id a10sm443722iba.24.2011.07.27.23.02.46 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jul 2011 23:02:47 -0700 (PDT) Message-ID: <4E30FB87.5080206@gmail.com> Date: Wed, 27 Jul 2011 23:02:47 -0700 From: Mahesh Jethanandani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: karp@ietf.org References: <4E30694F.4000202@joelhalpern.com> In-Reply-To: <4E30694F.4000202@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [karp] Draft - PIM Gap Analysis - "extra license" 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, 28 Jul 2011 06:02:54 -0000 Agree that we should remove reference to "extra license". On 7/27/2011 12:38 PM, Joel Halpern wrote: > This note is to determine whether the mailing list agrees with that. From rja.lists@gmail.com Thu Jul 28 06:50:47 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 9A7EB21F8B73 for ; Thu, 28 Jul 2011 06:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.585 X-Spam-Level: X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-kc9EqIrh6z for ; Thu, 28 Jul 2011 06:50:47 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id CA55321F8531 for ; Thu, 28 Jul 2011 06:50:27 -0700 (PDT) Received: by qyk29 with SMTP id 29so1700047qyk.10 for ; Thu, 28 Jul 2011 06:50:27 -0700 (PDT) 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=59ubrtV7JAKDPxbq3gP9DcwTDCUazYkXlaRFWyiL6U0=; b=hMAAM+u7XmlLQ33hvY5cDH+U+pzusJ1HxUfLj8qwg4m7ka3ZY3k0tlooWfPmSIGyYo yRkixGmuXTZfK8r0xZN3A2Qu6XhCN+xJuU4KCMXHOzn0bAMVW//5awVG2W+BNi0HjWWM qP/k7yxithycR27QJNIUOI2VLcAlf1TDUGl2E= Received: by 10.224.17.145 with SMTP id s17mr7030qaa.357.1311861027219; Thu, 28 Jul 2011 06:50:27 -0700 (PDT) Received: from [10.30.20.5] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id w12sm686897qct.12.2011.07.28.06.50.25 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 06:50:26 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jul 2011 09:50:24 -0400 Message-Id: To: karp@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [karp] Draft - PIM Gap Analysis - "extra license" 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, 28 Jul 2011 13:50:47 -0000 Earlier, Joel Halpern wrote: > The presentation on the PIM Gap Analysis discussed, as one of the = gaps,=20 > that some vendors charge more for IPSec on some products. > This is alluded to in the text. >=20 > The chairs opinion, and the rough consensus of the room,=20 > is that discussions of vendor charging should not be included in the = document. > Including this is a bad idea since business may engage in whatever = business=20 > practices they choose, relative to any products. > We need to focus on the technical limitations of the current state. >=20 > This note is to determine whether the mailing list agrees with that. >=20 > Please comment promptly. We expect to direct the authors to remove the = text > if they wish the document to be considered as a working group = document. Agreed. =20 Discussion of "business practices" and their potential impacts=20 are never properly within scope for IETF consideration, since the IETF is a technical body. Therefore, all such discussions=20 need to be entirely excluded from all KARP documents. Yours, Ran From turners@ieca.com Thu Jul 28 07:12: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 3E51F21F8C7E for ; Thu, 28 Jul 2011 07:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.96 X-Spam-Level: X-Spam-Status: No, score=-100.96 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_40=-0.185, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YG6TSxtLn+WU for ; Thu, 28 Jul 2011 07:12:07 -0700 (PDT) Received: from nm8.bullet.mail.bf1.yahoo.com (nm8.bullet.mail.bf1.yahoo.com [98.139.212.167]) by ietfa.amsl.com (Postfix) with SMTP id 9EDAD21F8793 for ; Thu, 28 Jul 2011 07:12:07 -0700 (PDT) Received: from [98.139.212.146] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 28 Jul 2011 14:12:04 -0000 Received: from [98.139.212.237] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 28 Jul 2011 14:12:04 -0000 Received: from [127.0.0.1] by omp1046.mail.bf1.yahoo.com with NNFMP; 28 Jul 2011 14:12:04 -0000 X-Yahoo-Newman-Id: 461903.48421.bm@omp1046.mail.bf1.yahoo.com Received: (qmail 31996 invoked from network); 28 Jul 2011 14:12:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311862323; bh=UEPrIoPWsRG0ziUivu8zrwL7yic6mWbW4eQcjj4XzUs=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=17qG/NQ7Sa2PP5mBKNFfFDQEOLkKLvv8NQqIgU/rjvCXD3Wmb6BDRhwTfKzVRmYmwMEDZRhkdguXU7VaafmluuF69MGVdWhj2edr9wsGP1VzHYg7QKVaeJUxDyZNx+v6efgamfItEN2RU6fqArHkY78ujODxVTdLFrJvJnAP63I= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: GhLVsGcVM1lsr6sTu0CejDWtCzF1kRNXlMuv0RRajxVv3Qf ZRjdgo1HvTqh1iR5Sn3.xwuZa6ti4MRMsT9pWlVKxio.ala7zH0pyum1iPAW .nkmoVeFnT9pPEDrlvNKtUB8NQtkdfja_sW0Ee8Uzvd7j_bnTof49YJ9P16j yh4ykvwYFAQrS6SBvx7MjOXri.ifWZjbf3yP6x0zf9yAGk1LW0_X1fdhP5Zn c.fFejhF5BbDTowRzI.kRUpa7zM2Bem6e_xmaKnPXncdAnkMjegfnauZbvDR 10eUdxw00aTWeu_pgpSbEsrWNnervLqE7XO_ULjQvyeAkH5cFtLXCsWvgApb GIV.9KJ0J2Qad3w4vxjCCdOhRqiKEENS_cu0zXD_vgPQ- X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from dhcp-1598.meeting.ietf.org (turners@130.129.21.152 with plain) by smtp111.biz.mail.mud.yahoo.com with SMTP; 28 Jul 2011 07:11:55 -0700 PDT Message-ID: <4E316E2A.2020002@ieca.com> Date: Thu, 28 Jul 2011 10:11:54 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Joel Halpern References: <4E30694F.4000202@joelhalpern.com> In-Reply-To: <4E30694F.4000202@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "karp@ietf.org" Subject: Re: [karp] Draft - PIM Gap Analysis - "extra license" 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, 28 Jul 2011 14:12:08 -0000 On 7/27/11 3:38 PM, Joel Halpern wrote: > The presentation on the PIM Gap Analysis discussed, as one of the gaps, > that some vendors charge more for IPSec on some products. > > This is alluded to in the text. > > The chairs opinion, and the rough consensus of the room, is that > discussions of vendor charging should not be included in the document. > > Including this is a bad idea since business may engage in whatever > business practices they choose, relative to any products. > We need to focus on the technical limitations of the current state. > > This note is to determine whether the mailing list agrees with that. > > Please comment promptly. We expect to direct the authors to remove the > text if they wish the document to be considered as a working group > document. > > Yours, > Joel Agreed (I was in the room too). spt From gwz@net-zen.net Thu Jul 28 09:47: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 2E89F11E807E for ; Thu, 28 Jul 2011 09:47:50 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khovE34dDeZh for ; Thu, 28 Jul 2011 09:47:49 -0700 (PDT) Received: from p3plsmtpa01-10.prod.phx3.secureserver.net (p3plsmtpa01-10.prod.phx3.secureserver.net [72.167.82.90]) by ietfa.amsl.com (Postfix) with SMTP id 1790311E8074 for ; Thu, 28 Jul 2011 09:47:48 -0700 (PDT) Received: (qmail 22370 invoked from network); 28 Jul 2011 16:47:48 -0000 Received: from unknown (130.129.17.166) by p3plsmtpa01-10.prod.phx3.secureserver.net (72.167.82.90) with ESMTP; 28 Jul 2011 16:47:47 -0000 Message-ID: <4E3192B1.7070605@net-zen.net> Date: Thu, 28 Jul 2011 12:47:45 -0400 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: Sean Turner References: <4E30694F.4000202@joelhalpern.com> <4E316E2A.2020002@ieca.com> In-Reply-To: <4E316E2A.2020002@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "karp@ietf.org" Subject: Re: [karp] Draft - PIM Gap Analysis - "extra license" 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, 28 Jul 2011 16:47:50 -0000 On 07/28/2011 10:11 AM, Sean Turner wrote: > On 7/27/11 3:38 PM, Joel Halpern wrote: >> The presentation on the PIM Gap Analysis discussed, as one of the gaps, >> that some vendors charge more for IPSec on some products. >> >> This is alluded to in the text. >> >> The chairs opinion, and the rough consensus of the room, is that >> discussions of vendor charging should not be included in the document. >> >> Including this is a bad idea since business may engage in whatever >> business practices they choose, relative to any products. >> We need to focus on the technical limitations of the current state. >> >> This note is to determine whether the mailing list agrees with that. >> >> Please comment promptly. We expect to direct the authors to remove the >> text if they wish the document to be considered as a working group >> document. >> >> Yours, >> Joel > > Agreed (I was in the room too). Ditto. > > spt > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > > From acee.lindem@gmail.com Thu Jul 28 12:06:23 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 6162E5E8027 for ; Thu, 28 Jul 2011 12:06:23 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDkvrBu+tUkk for ; Thu, 28 Jul 2011 12:06:22 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id B4CA45E8010 for ; Thu, 28 Jul 2011 12:06:08 -0700 (PDT) Received: by qyk29 with SMTP id 29so1917197qyk.10 for ; Thu, 28 Jul 2011 12:06:08 -0700 (PDT) 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 :cc:to:mime-version:x-mailer; bh=W94nqz6mttDChNTAO0S/TVyxaAe9qFxYtklOdU6h7v4=; b=lJxo8Xra0F3hTK0IAt9pY+t9PXGjzeJ0bB8irxG1pBi96u/Uz8iaMAJoixkX/JPIWl XeM/9vlROVQhEH1nArRd4SQD6Art8DsdC+No2z7zwAWp5Zf8Z/BFGFzBQ4IMbRzzMvWJ teeN48H2ItS0udVyrMDQ6Kw5D3hdxZqVBNa5k= Received: by 10.229.21.194 with SMTP id k2mr291173qcb.235.1311879968029; Thu, 28 Jul 2011 12:06:08 -0700 (PDT) Received: from ?IPv6:2001:df8::16:5ab0:35ff:fe74:605? ([2001:df8:0:16:5ab0:35ff:fe74:605]) by mx.google.com with ESMTPS id o4sm883214qct.1.2011.07.28.12.06.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 12:06:07 -0700 (PDT) From: Acee Lindem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jul 2011 15:05:53 -0400 Message-Id: To: karp@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Sam Hartman , Tim Polk Subject: [karp] Mapping of OSPFv2 Key to "Database of Long-Lived Symmetric Cryptographic Keys" () 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, 28 Jul 2011 19:06:23 -0000 As promised in yesterday's KARP proposal, I looked at the problem with = virtual links in our OSPFv2 manual keying security draft.=20 Basically, the problem is that one can have multiple virtual links to = the same endpoint router through multiple transit areas. Since a virtual = link can take any path through a transit area, the interface key in the = database isn't really applicable.=20 This may not be a common deployment but I can speak from experience that = it is one of the most popular system test scenarios ;^). =20 There are three possible resolutions to this problem: 1. Leave the crypto draft as is and map the virtual link = destination router ID to the database peer key and use the database = interface key for the virtual link's transit area. 2. Add a protocol specific identifier key to the database. This = could be used for the transit area ID to provide uniqueness.=20 3. Add an explicit area ID key to the database which could be used = to provide uniqueness.=20 Thanks, Acee= From acee.lindem@gmail.com Thu Jul 28 16:12: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 02F1421F8B29 for ; Thu, 28 Jul 2011 16:12:11 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7zm2+5ksjdC for ; Thu, 28 Jul 2011 16:12:10 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id D58ED21F8B15 for ; Thu, 28 Jul 2011 16:12:09 -0700 (PDT) Received: by qwc23 with SMTP id 23so2100804qwc.31 for ; Thu, 28 Jul 2011 16:12:09 -0700 (PDT) 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 :cc:to:mime-version:x-mailer; bh=bJlcdkLWwtvkJANiD3N2+crFq3wf4UNszNJGbWpXm+s=; b=o0W/HwNMy2yW7lGXrcyulg/aYCUCEHVwmVtsaeWOAcO2VJ8zxzS2xYTXA0ih1aXfoX oh6hXSK5aq7ytxZl92uvnHUNAPbEs0SxPvnRIgfP4STm0rXY04RK9hvdhFL8j6DvYm5x Kfrg651mp34D92IK2sGzGdL6H23nHC2HXtkTc= Received: by 10.224.200.132 with SMTP id ew4mr471472qab.340.1311894729377; Thu, 28 Jul 2011 16:12:09 -0700 (PDT) Received: from ?IPv6:2001:df8::16:5ab0:35ff:fe74:605? ([2001:df8:0:16:5ab0:35ff:fe74:605]) by mx.google.com with ESMTPS id 1sm1016744qcy.43.2011.07.28.16.12.07 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 16:12:08 -0700 (PDT) From: Acee Lindem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jul 2011 19:12:06 -0400 Message-Id: <287369F0-D8A2-44D3-9C17-BD1F32C64797@lindem.com> To: karp@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Sam Hartman Subject: [karp] Mapping of OSPFv2 Key to "Database of Long-Lived Symmetric Cryptographic Keys" () - Resending with Tim's Email Address Corrected 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, 28 Jul 2011 23:12:11 -0000 As promised in yesterday's KARP proposal, I looked at the problem with = virtual links in our OSPFv2 manual keying security draft.=20 Basically, the problem is that one can have multiple virtual links to = the same endpoint router through multiple transit areas. Since a virtual = link can take any path through a transit area, the interface key in the = database isn't really applicable.=20 This may not be a common deployment but I can speak from experience that = it is one of the most popular system test scenarios ;^). =20 There are three possible resolutions to this problem: 1. Leave the crypto draft as is and map the virtual link destination = router ID to the database peer key and use the database interface key = for the virtual link's transit area. 2. Add a protocol specific identifier key to the database. This could = be used for the transit area ID to provide uniqueness.=20 3. Add an explicit area ID key to the database which could be used to = provide uniqueness.=20 Thanks, Acee= From yoshifumi.nishida@gmail.com Sun Jul 31 21:58:47 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 4455D21F85DA; Sun, 31 Jul 2011 21:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.805 X-Spam-Level: X-Spam-Status: No, score=-102.805 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ed8diq-TVvOJ; Sun, 31 Jul 2011 21:58:46 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8319021F85A1; Sun, 31 Jul 2011 21:58:43 -0700 (PDT) Received: by iye7 with SMTP id 7so7712823iye.31 for ; Sun, 31 Jul 2011 21:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=YJ76QgGtXESITksLwOUihTJoJoWlNI7agKE5J/tgoXI=; b=XSGPCenYM4NkMrb3uALuQPPDy/muCVUlYLOAaVfVQU/soRQZFZWO8e8Lqpu1xPYRAM 9ROGWPvjeyZInvIOa2H+rF0/ChYv+FjLIk1gCBYOHkBKEryJxlrLkh1dm8A0CLxv4Yf+ X/RY7UEkRiniCGrhsU8Rwg0BqGiT1VDM5NP0c= MIME-Version: 1.0 Received: by 10.231.119.216 with SMTP id a24mr2803258ibr.58.1312174726387; Sun, 31 Jul 2011 21:58:46 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.199.12 with HTTP; Sun, 31 Jul 2011 21:58:46 -0700 (PDT) Date: Sun, 31 Jul 2011 21:58:46 -0700 X-Google-Sender-Auth: xol0NoegZ0PyF4j4dld_uf4u2YY Message-ID: From: Yoshifumi Nishida To: karp@ietf.org, ietf@ietf.org, draft-ietf-karp-threats-reqs@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Sun, 31 Jul 2011 22:17:21 -0700 Cc: tsv-dir@ietf.org Subject: [karp] tsv-dir review of draft-ietf-karp-threats-reqs-03 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, 01 Aug 2011 04:58:47 -0000 Hello folks, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. Transport Issues: I had some difficulties to grasp the objective of the document, however, I believe it's This document does not contain protocol specifications. Instead, it defines the areas where protocol specification work is needed and sets a direction, a set of requirements, and a relative priority for addressing that specification work. as it is stated in Section 1.3. Along with this context, I can understand section 2 and 3 are written for this purpose. Also, I think there is no specific transport layer concern in this document since there's no detailed discussion for protocol specs. However, if my presumption on the objective of the document is right, I think the title of this draft might not be appropriate. It would be something like "The Goal and Requirements for Cryptographic Authentication of Routing Protocols' Transports" or "The Requirements for Cryptographic Authentication of Routing Protocols' Transports". Because there is not threat analysis in the document. Also, abstract will need to be updated. Other minor comments: As stated above, I have some difficulties to read this document. I think this is likely because I'm not an expected audience for the document. However, if you think some of the following points are also reasonable for some expected audience, please consider updating. 1: I prefer that the objective of the draft is articulated at the beginning of the document. It will be very helpful to read the rest of the document. 2: I think it would be better to separate the introduction of this draft and KARP project. For example, it is a bit confusing for me to understand the focus of this draft since it is mixed with the focus of the KARP in Section 1.3. I think Section 1.1, 1.2 and 1.7 can be put in the introduction of this draft and 1.3, 1.4, 1.5, 1.6 can be put in another section which describes the overview of KARP. 3: I think it depends on the objective of the draft, but I feel some texts in Section 1 is not necessary for this draft. For example, I'm not very sure the audience of this doc need to read Section 1.4. Also, Section 1.5 seems to be too long. There are also many mentions about roadmap in this draft, but I'm not very sure these are necessary since this is not a roadmap document. (Hence, I don't understand the meaning of "this roadmap document". ) 4: Section 3 only describes the requirement for Phase 1. Will be there another document for Phase 2 or we don't need it? 5: 24 requirements seems to be too many to check easily. I think it would be better to categorize them in some ways. (priority? protocols? approach?) Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp