From randy@psg.com Sun May 1 02:18:40 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFEDE0682 for ; Sun, 1 May 2011 02:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.259 X-Spam-Level: X-Spam-Status: No, score=-5.259 tagged_above=-999 required=5 tests=[AWL=1.340, 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 9Nc1M5L9TF74 for ; Sun, 1 May 2011 02:18:40 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 358AFE065F for ; Sun, 1 May 2011 02:18:39 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QGSnW-0006wd-6z; Sun, 01 May 2011 09:18:38 +0000 Date: Sun, 01 May 2011 11:19:37 +0200 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: <4DBBE34D.3050507@cisco.com> References: <8A7BEFB8FCD25A43BB73B1D879B82F770457B0AF@xmb-sjc-239.amer.cisco.com> <4DBBE34D.3050507@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] rpki-rtr protocol maximum message length X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 09:18:40 -0000 > And while we are here .. is this a copy and paste error that section > 5.6 in IPv6 prefix PDU definition allows only 0..32 min prefix length > for IPv6 prefix ? Can't I specify 64 as min length prefix for example ? that was caught a while ago and is in the currently published draft. randy From raszuk@cisco.com Sun May 1 03:08:28 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA56DE06C9 for ; Sun, 1 May 2011 03:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 LZzM-1riOLKX for ; Sun, 1 May 2011 03:08:28 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 38E96E06B0 for ; Sun, 1 May 2011 03:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=893; q=dns/txt; s=iport; t=1304244508; x=1305454108; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=21/MsijRZ9fzN8BW+NMPXsg4ges3ouEIXElZo7aZUP0=; b=dLSLIDmVtxBOX9w+XhYqEsAzfP07J3OdbEWvy99+4AEHmTh0Ls0RDSOn 7JdG3khnIPUTuhmbtjMNuFNGWRl7o5OBNbt8uq/MAAsxmfPx1NSU+2Ovi NYV5SMVpxD4bwXNCjlM55Fc0XAYm5Cf2mib5HIlt3zmSoFpBLN172jH2d Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANkwvU2rRDoH/2dsb2JhbACmGneIcZ4OgngPAZhFhgAEjnmEGYoL X-IronPort-AV: E=Sophos;i="4.64,297,1301875200"; d="scan'208";a="690024049" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 01 May 2011 10:08:27 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p41A8Qwi002908; Sun, 1 May 2011 10:08:27 GMT Message-ID: <4DBD311A.5030005@cisco.com> Date: Sun, 01 May 2011 12:08:26 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Randy Bush References: <8A7BEFB8FCD25A43BB73B1D879B82F770457B0AF@xmb-sjc-239.amer.cisco.com> <4DBBE34D.3050507@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr wg list Subject: Re: [sidr] rpki-rtr protocol maximum message length X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 10:08:28 -0000 Hi Randy, > that was caught a while ago and is in the currently published draft. Looking at ver -12 (published 4 days ago) it seems still not fixed there. Ref: http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-12 --- > the longest non-error pdu is pdu 6, the ipv6 pdu. this limits the max > size error pdu to a fairly small size. PDU sizes are irrelevant as error-report allows "Arbitrary Text" which is not size limited in the current draft. I am not sure about you but for me malloc(sizeof("fairly small size")) does not compile well ;-). R. >> And while we are here .. is this a copy and paste error that section >> 5.6 in IPv6 prefix PDU definition allows only 0..32 min prefix length >> for IPv6 prefix ? Can't I specify 64 as min length prefix for example ? > > that was caught a while ago and is in the currently published draft. > > randy > From randy@psg.com Sun May 1 03:59:03 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75084E0682 for ; Sun, 1 May 2011 03:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.292 X-Spam-Level: X-Spam-Status: No, score=-5.292 tagged_above=-999 required=5 tests=[AWL=1.307, 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 aY8gPL6WEByD for ; Sun, 1 May 2011 03:59:03 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 05162E0593 for ; Sun, 1 May 2011 03:59:03 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QGUMf-0007NU-Ne; Sun, 01 May 2011 10:59:01 +0000 Date: Sun, 01 May 2011 13:00:00 +0200 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: <4DBD311A.5030005@cisco.com> References: <8A7BEFB8FCD25A43BB73B1D879B82F770457B0AF@xmb-sjc-239.amer.cisco.com> <4DBBE34D.3050507@cisco.com> <4DBD311A.5030005@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] rpki-rtr protocol maximum message length X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 10:59:03 -0000 >> that was caught a while ago and is in the currently published draft. > Looking at ver -12 (published 4 days ago) it seems still not fixed > there. Ref: http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-12 sorry, that one was not caught until -13, which i'll drop out when any other significant changes are in. >> the longest non-error pdu is pdu 6, the ipv6 pdu. this limits the max >> size error pdu to a fairly small size. > > PDU sizes are irrelevant as error-report allows "Arbitrary Text" which > is not size limited in the current draft. shall i put in "don't be stupid?" > I am not sure about you but for me malloc(sizeof("fairly small size")) > does not compile well ;-). i did not realize you wrote code. randy From kent@bbn.com Mon May 2 05:50:47 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43333E072D for ; Mon, 2 May 2011 05:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.8 X-Spam-Level: X-Spam-Status: No, score=-101.8 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 q8zyK8q+941g for ; Mon, 2 May 2011 05:50:46 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 11F37E0742 for ; Mon, 2 May 2011 05:50:42 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:47131 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QGsaF-00078i-Aq; Mon, 02 May 2011 08:50:39 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sun, 1 May 2011 16:45:39 -0400 To: Jac Kloots From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr wg list Subject: Re: [sidr] time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 12:50:47 -0000 At 9:25 AM +0200 4/26/11, Jac Kloots wrote: >Randy, Others, > >It doesn't seem to be a new problem to me. How is this time problem >evaluated in the current off-line cache software? > >Why think of another approach if the only difference is the device >doing the validation of certs and ROA's? > >Regards, > >Jac > I'm not sure about the context an y more, but I'll note that the BBN RPKI relying party software has (will have?) a local clock tolerance knob that allows each RP to decide how "stale" a signed object can be before it is considered "too old." I would anticipate an analogous router knob for dealing with time issues in BGPSEC signed objects. Steve From iesg-secretary@ietf.org Mon May 2 10:29:45 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C4EE06FE; Mon, 2 May 2011 10:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 ZU9dcyeNDnu3; Mon, 2 May 2011 10:29:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609A6E0720; Mon, 2 May 2011 10:29:44 -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.52 Message-ID: <20110502172944.28569.8532.idtracker@ietfa.amsl.com> Date: Mon, 02 May 2011 10:29:44 -0700 Cc: sidr mailing list , sidr chair , RFC Editor Subject: [sidr] Document Action: 'Validation of Route Origination using the Resource Certificate PKI and ROAs' to Informational RFC (draft-ietf-sidr-roa-validation-10.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 17:29:45 -0000 The IESG has approved the following document: - 'Validation of Route Origination using the Resource Certificate PKI and ROAs' (draft-ietf-sidr-roa-validation-10.txt) as an Informational RFC This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sidr-roa-validation/ Technical Summary This document defines the semantics of a Route Origin Authorization (ROA) in terms of an application of the Resource Public Key Infrastructure (RPKI) to the validation of the origination of routes advertised in the Border Gateway Protocol. Working Group Summary The initial versions of this document presented a validation algorithm that was considerably more complex than the final verison. It was modified and simplified over many versions and discussions. The present document is an outcome of energetic discussions involving a broad cross-section of the working group. The authors advocated the original approach vigorously, but eventually accepted the group consensus. IP has been filed at http://datatracker.ietf.org/ipr/1204/ The working group discussed this in Nov 2009. The WG decided that it prefered non-IPR'd technologies, but did not reject this work and continued with it. Document Quality This document is clear and submitted as Informational without anything to be implemented. A related document describes an implementation in the BGP decision process. The related document is itself being implemented by at least one router vendor. Personnel Sandy Murphy (sandy@sparta.com) is the Document Shepherd. Adrian Farrel (adrian/farrel@hauwei,com) is the responsible AD. RFC Editor Note Section 4 final sentence s/MAY/may/ --- Section 5 OLD A ROA validation "expires" at the Validity To field of the signing EE certificate, or at such a time when there is no certification path that can validate the ROA. A ROA issuer may elect to prematurely invalidate a ROA by revoking the EE certificate that was used to sign the ROA. NEW A ROA validation "expires" at the notAfter field of the signing EE certificate, or at such a time when there is no certification path that can validate the ROA. A ROA issuer may elect to prematurely invalidate a ROA by revoking the EE certificate that was used to sign the ROA. END From jgs@juniper.net Mon May 2 11:42:18 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D98E0678 for ; Mon, 2 May 2011 11:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.31 X-Spam-Level: X-Spam-Status: No, score=-6.31 tagged_above=-999 required=5 tests=[AWL=0.289, 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 P7xKVr6RqmOw for ; Mon, 2 May 2011 11:42:17 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 68DFEE0618 for ; Mon, 2 May 2011 11:42:17 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTb769rpS8RKRZoU4k0jJPa3ZXw2VNd2l@postini.com; Mon, 02 May 2011 11:42:17 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 2 May 2011 11:40:23 -0700 From: John Scudder To: Sandra Murphy Date: Mon, 2 May 2011 11:40:21 -0700 Thread-Topic: [sidr] call for adoption of draft-kent-bgpsec-threats-01 Thread-Index: AcwI+GTaoaPSM9nlQzasyS8EzUc28Q== Message-ID: <9B45F146-97A9-4D8E-A9C7-057BDFCFB37D@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] call for adoption of draft-kent-bgpsec-threats-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 18:42:18 -0000 I support adoption of the whole pile-o-drafts with "bgpsec" in their names.= [*] I thought I'd aggregate my response rather than replying individually = to each thread. --John [*] threats, overview, protocol, ops, reqs On Apr 19, 2011, at 4:26 AM, Sandra Murphy wrote: > The working group has been requested to adopt draft-kent-bgpsec-threats-0= 1 as a working group draft, to satisfy the following item on our charter: >=20 > ID Date Pub Date > Mar 2011 Jun 2012 A document describing threats to the routing system >=20 > Please respond to the list with your opinion as to whether you accept thi= s > draft as a working group draft and are willing to work on it. Remember > that you do not need to accept all content in a draft to adopt, as draft > editors are required to reflect the consensus of the working group. >=20 > This call will end 3 May 2011. >=20 > --Sandy, speaking as wg co-chair, with wg ceremonial garb donned From Internet-Drafts@ietf.org Tue May 3 03:30:03 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67936E07B2; Tue, 3 May 2011 03:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.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 h5GipvKv+1uQ; Tue, 3 May 2011 03:30:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27C5E07B5; Tue, 3 May 2011 03:30:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110503103002.10905.31524.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2011 03:30:02 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-origin-ops-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 10:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : RPKI-Based Origin Validation Operation Author(s) : R. Bush Filename : draft-ietf-sidr-origin-ops-07.txt Pages : 8 Date : 2011-05-03 Deployment of RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present them. It is expected to evolve as RPKI-based origin validation is deployed and the dynamics are better understood. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-origin-ops-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-origin-ops-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-03031613.I-D@ietf.org> --NextPart-- From iesg-secretary@ietf.org Wed May 4 08:16:23 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDDAE0788; Wed, 4 May 2011 08:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.159, 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 J92IwdOdIpVx; Wed, 4 May 2011 08:16:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716B7E0791; Wed, 4 May 2011 08:16:21 -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.53 Message-ID: <20110504151621.28650.21952.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2011 08:16:21 -0700 Cc: sidr mailing list , sidr chair , RFC Editor Subject: [sidr] Protocol Action: 'Certificate Policy (CP) for the Resource PKI (RPKI' to BCP (draft-ietf-sidr-cp-17.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 15:16:23 -0000 The IESG has approved the following document: - 'Certificate Policy (CP) for the Resource PKI (RPKI' (draft-ietf-sidr-cp-17.txt) as a BCP This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sidr-cp/ Technical Summary The document is a Certificate Policy (CP) for the Resource PKI. It follows the format established for document of this type, in RFC 3647. It is customary for a large scale PKI to publish an associated CP. In the case of the RPKI, this CP describes essential, common aspects of CA operation, both as guidance to CAs and for the benefit of all relying parties (RPs). The CP defers many details of Certification Authority (CA) procedures to the Certification Practice Statement (CPS) that will be published by most CAs that operate in the RPKI context. (Not all CAs need to publish a CPS; a CA that issues certificates only to entities within the same administrative realm as the CA need not generate or publish a CPS.) Working Group Summary An early review was provided by the NRO (the RIRs), and, as a result, the document was reduced in length. A PKI expert (formerly with VeriSign Japan, now with IANA) provided extensive comments, as did Sean Turner, the cognizant security AD. Document Quality The document is well written and clear. It does not describe a protocol, so there are no "implementations" per se. However, at least four RIRs have developed CPS's that are based on the CP. There is no MIB, and no Media Types are involved. However, as noted above more than one PKI expert has reviewed the document. Personnel Sandra Murphy the Document Shepherd for this document. Stewart Bryant is the Responsible Area Director. RFC Editor Note In the title s/for the Resource PKI (RPKI/for the Resource PKI (RPKI)/ (missing closing parenthesis) ===== 3.2.2 page16: s/bedescribed/be described/ ===== From iesg-secretary@ietf.org Wed May 4 09:01:37 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574A8E07AA; Wed, 4 May 2011 09:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 48PLFIpnvXDz; Wed, 4 May 2011 09:01:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F56E07AC; Wed, 4 May 2011 09:01:31 -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.53 Message-ID: <20110504160131.750.98875.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2011 09:01:31 -0700 Cc: sidr@ietf.org Subject: [sidr] Last Call: (CA Key Rollover in the RPKI) to BCP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 16:01:37 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'CA Key Rollover in the RPKI' as a BCP 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-05-18. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-keyroll/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-keyroll/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Wed May 4 10:21:55 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB293E07E2; Wed, 4 May 2011 10:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 ZcuZb4ICv8xv; Wed, 4 May 2011 10:21:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A5FE0786; Wed, 4 May 2011 10:21:55 -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.53 Message-ID: <20110504172155.4834.25835.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2011 10:21:55 -0700 Cc: sidr@ietf.org Subject: [sidr] Last Call: (A Profile for Resource Certificate Repository Structure) to BCP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 17:21:56 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'A Profile for Resource Certificate Repository Structure' as a BCP 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-05-18. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-repos-struct/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-repos-struct/ No IPR declarations have been submitted directly on this I-D. From Internet-Drafts@ietf.org Wed May 4 13:00:02 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0015E0700; Wed, 4 May 2011 13:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 LqxIx1vuwbiG; Wed, 4 May 2011 13:00:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6CDE074D; Wed, 4 May 2011 13:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110504200002.26961.73838.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2011 13:00:02 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-roa-format-11.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 20:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Profile for Route Origin Authorizations (ROAs) Author(s) : M. Lepinski, et al. Filename : draft-ietf-sidr-roa-format-11.txt Pages : 9 Date : 2011-05-04 This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to that one or more prefixes within the address block. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-format-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-roa-format-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-04125614.I-D@ietf.org> --NextPart-- From gih@apnic.net Wed May 4 20:55:44 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6EBAE084B for ; Wed, 4 May 2011 20:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, 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 y1S9iytYYVUT for ; Wed, 4 May 2011 20:55:44 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id DAFDDE0618 for ; Wed, 4 May 2011 20:55:41 -0700 (PDT) Received: from [192.168.49.35] (unknown [84.35.81.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 3575EB66C9; Thu, 5 May 2011 13:55:37 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: <3CDA3E59-7F13-4655-9B55-DB22B9C10843@cisco.com> Date: Thu, 5 May 2011 13:54:58 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <0A7DEB7E-26FB-42D8-B32C-D2D446943306@apnic.net> References: <3CDA3E59-7F13-4655-9B55-DB22B9C10843@cisco.com> To: Pradosh Mohapatra X-Mailer: Apple Mail (2.1084) Cc: "sidr@ietf.org wg" Subject: Re: [sidr] draft-ietf-sidr-pfx-validate-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 03:55:44 -0000 On 22/02/2011, at 5:36 AM, Pradosh Mohapatra wrote: > The -01 version of the draft addresses the comments that were received = during the last call, most notably: >=20 > http://www.ietf.org/mail-archive/web/sidr/current/msg02168.html > http://www.ietf.org/mail-archive/web/sidr/current/msg02204.html >=20 > Would be great to have a round of review to verify the comments were = indeed addressed and see if there are any new comments/concerns. >=20 Hi I have now reviewed this version of the draft My previous review comment is at = http://www.ietf.org/mail-archive/web/sidr/current/msg02168.html I note that you have elected to address my review comments by removing = text rather than adding explanation or guidance. The current text simply states: Policies which could be implemented include filtering routes based on validation state (for example, rejecting all "invalid" routes) or adjusting a route's degree of preference in the selection algorithm based on its validation state. The latter could be accomplished by adjusting the value of such attributes as LOCAL_PREF. Considering invalid routes for BGP decision process is a pure local policy matter and should be done with utmost care. This test appears to be less than helpful in so far as it offer no = guidance at all! I'm afraid that my original comment that this document is not ready to = head to the IESG is still the case for me, and my original comments in = my earlier review still stand. regards, Geoff =20 From randy@psg.com Thu May 5 00:32:47 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B51E06F6 for ; Thu, 5 May 2011 00:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[AWL=1.247, 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 Cs2y7QJHXgVn for ; Thu, 5 May 2011 00:32:46 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id C0E49E06AF for ; Thu, 5 May 2011 00:32:46 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=dhcp-27-124.ripemtg.ripe.net.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QHt20-0008pe-2b; Thu, 05 May 2011 07:31:28 +0000 Date: Thu, 05 May 2011 09:32:49 +0200 Message-ID: From: Randy Bush To: Geoff Huston In-Reply-To: <0A7DEB7E-26FB-42D8-B32C-D2D446943306@apnic.net> References: <3CDA3E59-7F13-4655-9B55-DB22B9C10843@cisco.com> <0A7DEB7E-26FB-42D8-B32C-D2D446943306@apnic.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org wg" Subject: Re: [sidr] draft-ietf-sidr-pfx-validate-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 07:32:47 -0000 i think/hope these concerns were addressed by moving operational recommendations to draft-ietf-sidr-origin-ops randy From internet-drafts@ietf.org Thu May 5 00:36:26 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5072DE0704; Thu, 5 May 2011 00:36:26 -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 EJp1L9-7rw1m; Thu, 5 May 2011 00:36:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FE6E06AF; Thu, 5 May 2011 00:36:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110505073625.3870.84234.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2011 00:36:25 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-manifests-11.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 07:36:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : Manifests for the Resource Public Key Infrastructure Author(s) : Rob Austein Geoff Huston Stephen Kent Matt Lepinski Filename : draft-ietf-sidr-rpki-manifests-11.txt Pages : 19 Date : 2011-05-05 This document defines a "manifest" for use in the Resource Pub= lic Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority, that are published at this repository publication point, the manifest contains both the name of the file containing the object, and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (= valid) data and deletion of signed objects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-manifests-11.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-sidr-rpki-manifests-11.txt From gih@apnic.net Thu May 5 00:45:57 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619ECE06AF for ; Thu, 5 May 2011 00:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.101 X-Spam-Level: X-Spam-Status: No, score=-101.101 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_DYNAMIC_DHCP=1.398, RDNS_DYNAMIC=0.1, 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 YHre2I6pIlJc for ; Thu, 5 May 2011 00:45:56 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 903F2E0651 for ; Thu, 5 May 2011 00:45:56 -0700 (PDT) Received: from dhcp-27-178.ripemtg.ripe.net (dhcp-27-178.ripemtg.ripe.net [193.0.27.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id BF874B66C9; Thu, 5 May 2011 17:45:31 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Thu, 5 May 2011 17:43:48 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <1B57A7D6-387C-4A7C-87AD-365FCFBD4D63@apnic.net> References: <3CDA3E59-7F13-4655-9B55-DB22B9C10843@cisco.com> <0A7DEB7E-26FB-42D8-B32C-D2D446943306@apnic.net> To: Randy Bush , Pradosh Mohapatra X-Mailer: Apple Mail (2.1084) Cc: "sidr@ietf.org wg" Subject: Re: [sidr] draft-ietf-sidr-pfx-validate-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 07:45:57 -0000 On 05/05/2011, at 5:32 PM, Randy Bush wrote: > i think/hope these concerns were addressed by moving operational > recommendations to draft-ietf-sidr-origin-ops Thanks for this. I would suggest to the pfx-validate draft author(s) = that the pfx-validate document then make a more explicit reference to this origin-ops document = as being the place where the operational considerations of how to treat the various = ROA validation outcomes in the context of local routing policy and the operational = implications of such local policy settings is considered. The shift of material from the = pfx-validate draft to the origin-ops draft is not clear when reviewing the = pfx-validate text. (Fair warning - I've not done a nit-pick scan of the pfx-validate draft = to ensure that normative text is used appropriately throughout the draft. My quick scan = pointed to the need to carefully comb through the draft as there appears to be still some = further instances of use of "may" vs "MAY" etc.) regards, Geoff From randy@psg.com Thu May 5 01:05:05 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C387E0651 for ; Thu, 5 May 2011 01:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.381 X-Spam-Level: X-Spam-Status: No, score=-5.381 tagged_above=-999 required=5 tests=[AWL=1.218, 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 xWhD0PaAgNaE for ; Thu, 5 May 2011 01:05:04 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id B2385E0692 for ; Thu, 5 May 2011 01:05:04 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=dhcp-27-124.ripemtg.ripe.net.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QHtYS-00090z-Oo; Thu, 05 May 2011 08:05:00 +0000 Date: Thu, 05 May 2011 10:06:22 +0200 Message-ID: From: Randy Bush To: Geoff Huston In-Reply-To: <1B57A7D6-387C-4A7C-87AD-365FCFBD4D63@apnic.net> References: <3CDA3E59-7F13-4655-9B55-DB22B9C10843@cisco.com> <0A7DEB7E-26FB-42D8-B32C-D2D446943306@apnic.net> <1B57A7D6-387C-4A7C-87AD-365FCFBD4D63@apnic.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org wg" Subject: Re: [sidr] draft-ietf-sidr-pfx-validate-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 08:05:05 -0000 > I would suggest to the pfx-validate draft author(s) that the > pfx-validate document then make a more explicit reference to this > origin-ops document as being the place where the operational > considerations of how to treat the various ROA validation outcomes in > the context of local routing policy and the operational implications > of such local policy settings is considered. The shift of material > from the pfx-validate draft to the origin-ops draft is not clear when > reviewing the pfx-validate text. good point. thanks. > I've not done a nit-pick scan of the pfx-validate draft to ensure that > normative text is used appropriately throughout the draft. i hang on tenterhooks :) randy From internet-drafts@ietf.org Thu May 5 12:09:34 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC07CE094D; Thu, 5 May 2011 12:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 EEvwcs-WtaDE; Thu, 5 May 2011 12:09:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099F5E08C2; Thu, 5 May 2011 12:09:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110505190934.7383.82013.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2011 12:09:34 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-res-certs-22.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 19:09:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : A Profile for X.509 PKIX Resource Certificates Author(s) : Geoff Huston George Michaelson Robert Loomans Filename : draft-ietf-sidr-res-certs-22.txt Pages : 31 Date : 2011-05-05 This document defines a standard profile for X.509 certificates for the purposes of supporting validation of assertions of "right-of-us= e" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the Issuer's authorisation of the Subject to be regarded as the current holder of a "right-of-use&quo= t; of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). The document also specifies profiles for the format of certificate requests. The document also specifies the Relying Party RPKI certificate path validation procedure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-res-certs-22.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-sidr-res-certs-22.txt From Internet-Drafts@ietf.org Mon May 9 18:00:02 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80FB3E06FE; Mon, 9 May 2011 18:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 MJnguv-maBx5; Mon, 9 May 2011 18:00:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0762AE0924; Mon, 9 May 2011 18:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110510010002.11083.48306.idtracker@ietfa.amsl.com> Date: Mon, 09 May 2011 18:00:02 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-roa-format-12.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 01:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Profile for Route Origin Authorizations (ROAs) Author(s) : M. Lepinski, et al. Filename : draft-ietf-sidr-roa-format-12.txt Pages : 9 Date : 2011-05-09 This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-format-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-roa-format-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-09175007.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Tue May 10 01:45:03 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DF3E08D5; Tue, 10 May 2011 01:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 gQupcvOAxSuQ; Tue, 10 May 2011 01:45:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA0FE08DA; Tue, 10 May 2011 01:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110510084502.30700.51047.idtracker@ietfa.amsl.com> Date: Tue, 10 May 2011 01:45:02 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-origin-ops-08.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 08:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : RPKI-Based Origin Validation Operation Author(s) : R. Bush Filename : draft-ietf-sidr-origin-ops-08.txt Pages : 8 Date : 2011-05-10 Deployment of RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present them. It is expected to evolve as RPKI-based origin validation is deployed and the dynamics are better understood. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-origin-ops-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-origin-ops-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-10014201.I-D@ietf.org> --NextPart-- From randy@psg.com Tue May 10 01:59:32 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717ADE095B for ; Tue, 10 May 2011 01:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.434 X-Spam-Level: X-Spam-Status: No, score=-5.434 tagged_above=-999 required=5 tests=[AWL=1.165, 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 PTjLVof-aHzu for ; Tue, 10 May 2011 01:59:32 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id F1873E094F for ; Tue, 10 May 2011 01:59:31 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.home.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QJig7-000IPl-PC for sidr@ietf.org; Tue, 10 May 2011 08:52:28 +0000 Date: Tue, 10 May 2011 10:54:05 +0200 Message-ID: From: Randy Bush To: sidr wg list In-Reply-To: <20110510084502.30700.51047.idtracker@ietfa.amsl.com> References: <20110510084502.30700.51047.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: Re: [sidr] I-D Action:draft-ietf-sidr-origin-ops-08.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 08:59:32 -0000 + Use of RPKI-based origin validation obviates the utility of + announcing many longer prefix when the covering prefix would do. + + To aid translation of ROAs into efficient search algorithms in + routers, ROAs SHOULD be as precise as possible, i.e. match prefixes + as announced in BGP. E.g. software and operators SHOULD avoid use of + excessive max length values in ROAs unless operationally necessary. + + Therefore, ROA generation software MUST use the prefix length as the + max length if the user does not specify a max length. + + Operators SHOULD be conservative in use of max length in ROAs. E.g., + if a prefix will have only a few sub-prefixes announced, multiple + ROAs for the specific announcements SHOULD be used as opposed to one + ROA with a long max length. yes, i will fix s/prefix/prefixes/ in the next edition randy From Internet-Drafts@ietf.org Tue May 10 14:45:05 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7BBE06DB; Tue, 10 May 2011 14:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 K8FODQZPHB62; Tue, 10 May 2011 14:45:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48D6E0691; Tue, 10 May 2011 14:45:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110510214504.7929.24222.idtracker@ietfa.amsl.com> Date: Tue, 10 May 2011 14:45:04 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-signed-object-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 21:45:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Signed Object Template for the Resource Public Key Infrastructure Author(s) : M. Lepinski, et al. Filename : draft-ietf-sidr-signed-object-04.txt Pages : 13 Date : 2011-05-10 This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-signed-object-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-signed-object-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-10144502.I-D@ietf.org> --NextPart-- From achi@bbn.com Tue May 10 15:01:30 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB9BE08FC for ; Tue, 10 May 2011 15:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.562 X-Spam-Level: X-Spam-Status: No, score=-4.562 tagged_above=-999 required=5 tests=[AWL=2.038, 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 cT5Ss2dQcV0D for ; Tue, 10 May 2011 15:01:29 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 40C15E06D9 for ; Tue, 10 May 2011 15:01:28 -0700 (PDT) Received: from dhcp89-089-014.bbn.com ([128.89.89.14]:57735) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QJuzf-0004BE-89 for sidr@ietf.org; Tue, 10 May 2011 18:01:27 -0400 Message-ID: <4DC9B5B7.90307@bbn.com> Date: Tue, 10 May 2011 18:01:27 -0400 From: Andrew Chi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: sidr wg References: <20110510214504.7929.24222.idtracker@ietfa.amsl.com> In-Reply-To: <20110510214504.7929.24222.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] I-D Action:draft-ietf-sidr-signed-object-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 22:01:30 -0000 This is in response to Stephen Farrell's discuss. We've added IANA instructions to create a registry for signed-object OIDs. Note: OIDs, not filename extensions b/c future types might not all be signed objects. (The filename extension registry is requested by -repos-struct.) The signed-object registry will be initially populated with the ROA and manifest OIDs; the -roa-format and -manifests docs can move forward without modification. -Andrew On 05/10/2011 05:45 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 Secure Inter-Domain Routing Working Group of the IETF. > > > Title : Signed Object Template for the Resource Public Key Infrastructure > Author(s) : M. Lepinski, et al. > Filename : draft-ietf-sidr-signed-object-04.txt > Pages : 13 > Date : 2011-05-10 > > This document defines a generic profile for signed objects used in > the Resource Public Key Infrastructure (RPKI). These RPKI signed > objects make use of Cryptographic Message Syntax (CMS) as a standard > encapsulation format. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-signed-object-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From internet-drafts@ietf.org Tue May 10 19:24:24 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4304CE06E3; Tue, 10 May 2011 19:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.871 X-Spam-Level: X-Spam-Status: No, score=-99.871 tagged_above=-999 required=5 tests=[AWL=0.130, 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 p2iocJ15JVOc; Tue, 10 May 2011 19:24:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE7FE06B5; Tue, 10 May 2011 19:24:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110511022423.3196.82002.idtracker@ietfa.amsl.com> Date: Tue, 10 May 2011 19:24:23 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-iana-objects-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 02:24:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : RPKI Objects issued by IANA Author(s) : Terry Manderson Leo Vegoda Steve Kent Filename : draft-ietf-sidr-iana-objects-03.txt Pages : 22 Date : 2011-05-10 This document provides specific direction to IANA as to the Resource Public Key Infrastructure (RPKI) objects it should issue. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-iana-objects-03.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-sidr-iana-objects-03.txt From randy@psg.com Tue May 10 21:30:23 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36DE0E0748 for ; Tue, 10 May 2011 21:30: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 xnAu9uB1g71R for ; Tue, 10 May 2011 21:30:22 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id D02B2E072C for ; Tue, 10 May 2011 21:30:22 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.home.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QK12l-000OYL-KD; Wed, 11 May 2011 04:29:03 +0000 Date: Wed, 11 May 2011 06:30:43 +0200 Message-ID: From: Randy Bush To: Andrew Chi In-Reply-To: <4DC9B5B7.90307@bbn.com> References: <20110510214504.7929.24222.idtracker@ietfa.amsl.com> <4DC9B5B7.90307@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg Subject: Re: [sidr] I-D Action:draft-ietf-sidr-signed-object-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 04:30:23 -0000 > The signed-object registry will be initially populated with the ROA and > manifest OIDs; the -roa-format and -manifests docs can move forward > without modification. ghostbusters too, please 1.2.840.113549.1.9.16.1.35 randy From mlepinski@bbn.com Wed May 11 08:08:25 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42DF5E076F for ; Wed, 11 May 2011 08:08:25 -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 R9xieurnOq06 for ; Wed, 11 May 2011 08:08:24 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B91CFE06DF for ; Wed, 11 May 2011 08:08:24 -0700 (PDT) Received: from dhcp89-089-020.bbn.com ([128.89.89.20]:1398) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QKB1U-000DOP-9v for sidr@ietf.org; Wed, 11 May 2011 11:08:24 -0400 Message-ID: <4DCAA670.1000201@bbn.com> Date: Wed, 11 May 2011 11:08:32 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: sidr@ietf.org References: <20110510214504.7929.24222.idtracker@ietfa.amsl.com> <4DC9B5B7.90307@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] I-D Action:draft-ietf-sidr-signed-object-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 15:08:25 -0000 Randy, The registry we are creating contains (along with the OID and a descriptive name) a specification pointer so that an implementer looking at the registry can find the spec for the signed object in question. I'm willing to add a reference to ghostbusters in the signed-object draft, but my concern is that adding a reference to ghostbusters might delay publication of the signed object draft. (As signed objects is in IESG review and is now very close to publication.) If we did not add a reference to ghostbusters in the signed-object draft, then the way forward would be for ghostbusters to contain a very short IANA considerations section that says: "Please add the following triple to the signed object registry specified in [reference to signed object]. " If the working group chairs could provide advice on the best way to proceed forward (either adding a reference to ghostbusters in the signed-object draft, or else adding an IANA considerations section to ghostbusters) I would appreciate it. - Matt Lepinski On 5/11/2011 12:30 AM, Randy Bush wrote: >> The signed-object registry will be initially populated with the ROA and >> manifest OIDs; the -roa-format and -manifests docs can move forward >> without modification. > ghostbusters too, please > > 1.2.840.113549.1.9.16.1.35 > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From randy@psg.com Wed May 11 08:13:02 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B579FE06D8 for ; Wed, 11 May 2011 08:13:02 -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 HjyIINZsWoJU for ; Wed, 11 May 2011 08:13:02 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 47F02E0679 for ; Wed, 11 May 2011 08:13:02 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.home.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QKB4j-0001HK-Gs; Wed, 11 May 2011 15:11:46 +0000 Date: Wed, 11 May 2011 17:13:26 +0200 Message-ID: From: Randy Bush To: Matt Lepinski In-Reply-To: <4DCAA670.1000201@bbn.com> References: <20110510214504.7929.24222.idtracker@ietfa.amsl.com> <4DC9B5B7.90307@bbn.com> <4DCAA670.1000201@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action:draft-ietf-sidr-signed-object-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 15:13:02 -0000 if manifest and roa are also in iesg, then i can see your point. and the ghostbusters draft was waiting for signed-object to open the registry in any case, just as i presume manifest and roa would be. randy From kent@bbn.com Wed May 11 08:54:23 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0440CE082D for ; Wed, 11 May 2011 08:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fLAmRnKUiCt for ; Wed, 11 May 2011 08:54:22 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8C0E0659 for ; Wed, 11 May 2011 08:54:22 -0700 (PDT) Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49203) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QKBjx-000C28-N6; Wed, 11 May 2011 11:54:22 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20110510214504.7929.24222.idtracker@ietfa.amsl.com> <4DC9B5B7.90307@bbn.com> <4DCAA670.1000201@bbn.com> Date: Wed, 11 May 2011 11:26:35 -0400 To: Randy Bush From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action:draft-ietf-sidr-signed-object-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 15:54:23 -0000 At 5:13 PM +0200 5/11/11, Randy Bush wrote: >if manifest and roa are also in iesg, then i can see your point. and >the ghostbusters draft was waiting for signed-object to open the >registry in any case, just as i presume manifest and roa would be. > >randy >_______________________________________________ ROA format is on the IESG telechat for tomorrow. manifests had the DISCUSS cleared and is good to go, awaiting action by Stewart (I believe). In contrast, ghostbusters is in the "I-D Exists" state, far behind in the approval process. Steve From stbryant@cisco.com Wed May 11 10:23:44 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F81E0844 for ; Wed, 11 May 2011 10:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ud5nPdejMwiK for ; Wed, 11 May 2011 10:23:43 -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 2791AE073C for ; Wed, 11 May 2011 10:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=1098; q=dns/txt; s=iport; t=1305134623; x=1306344223; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=VnKRfztXMjvDsxVNgh1t4jCY2FN0lzLk9bnfdt0kJ5I=; b=l3Os1os7Z3qkANVCGZKoBDlfKMqt1TJj8iS3pc9zV7r0UwFdoB2kafZP 8psWbnTLvto78ozovnitp8Andruila1bCRboTx8xerR6FGs7NPgAZ4W6I utd6GJgmWK5YMM58qc3SaETHpLv5RaN+TnSb1XGKjzBJ9HwzqaKpNG2gI s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEFAMjFyk2Q/khMgWdsb2JhbACYHI1yFAEBFiYlqhWCeA8BmyWGEASPcI5i X-IronPort-AV: E=Sophos;i="4.64,353,1301875200"; d="scan'208";a="29767076" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 11 May 2011 17:23:37 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4BHNbue009970 for ; Wed, 11 May 2011 17:23:37 GMT Received: from dhcp-gpk02-vlan300-64-103-65-125.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p4BHNaU23608; Wed, 11 May 2011 18:23:36 +0100 (BST) Message-ID: <4DCAC617.1070607@cisco.com> Date: Wed, 11 May 2011 18:23:35 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: sidr@ietf.org References: <20110510214504.7929.24222.idtracker@ietfa.amsl.com> <4DC9B5B7.90307@bbn.com> <4DCAA670.1000201@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] I-D Action:draft-ietf-sidr-signed-object-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 17:23:44 -0000 On Friday I will go down the list of sidr docs that are approved making sure that there are no issues that I overlooked and should be sending out a bunch of approval notices then. - Stewart On 11/05/2011 16:26, Stephen Kent wrote: > At 5:13 PM +0200 5/11/11, Randy Bush wrote: >> if manifest and roa are also in iesg, then i can see your point. and >> the ghostbusters draft was waiting for signed-object to open the >> registry in any case, just as i presume manifest and roa would be. >> >> randy >> _______________________________________________ > > ROA format is on the IESG telechat for tomorrow. > > manifests had the DISCUSS cleared and is good to go, > awaiting action by Stewart (I believe). > > In contrast, ghostbusters is in the "I-D Exists" state, far behind in the > approval process. > > Steve > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From christopher.morrow@gmail.com Thu May 12 12:38:47 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80463E0706 for ; Thu, 12 May 2011 12:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 THpBEbwrFPHQ for ; Thu, 12 May 2011 12:38:47 -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 BB2BFE0704 for ; Thu, 12 May 2011 12:38:46 -0700 (PDT) Received: by wyb29 with SMTP id 29so1680993wyb.31 for ; Thu, 12 May 2011 12:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=IG75OOgRRQV16YhcmdHgdAX7tAPJWI6nqT6P2g3MkMQ=; b=QR8xkbLWmi8SBYRhYzSO63okpf//gNjqE+mZpuBJYcR5DqKPxp/UyxEeIr9wTOk3vu /EZw2K+bsV/djmdKzvqXX1qIVPowsIxwcGLZXJjmAEphYX1dHQjNqUu2DqHcx5eyGcqR TcxaFFpFiQCjGcsGJIta9wp10tnpE5o5Pu7Gk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=KwRIM9t0jCFosPT8tM4lwmOsu/JP8QNWDO1NxgFWeLs1q85e9+rUVIIgN/MRUDtrTp KENVSTmP7u5tYxFj671x6Wg6c7LJR+aVqdcqsNr63RDvybE4MWt7YIorjI8GfAlZgvkZ WakIN2Uo5M6zGeSEeIJjJppHvlMSlwdubRA8c= MIME-Version: 1.0 Received: by 10.216.61.77 with SMTP id v55mr2058031wec.114.1305229124327; Thu, 12 May 2011 12:38:44 -0700 (PDT) Received: by 10.216.26.141 with HTTP; Thu, 12 May 2011 12:38:44 -0700 (PDT) Date: Thu, 12 May 2011 15:38:44 -0400 Message-ID: From: Christopher Morrow To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] A note about work in IDR (last-call for draft-ietf-idr-deprecate-as-sets-04) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 19:38:47 -0000 According to: There's a last-call ending tomorrow (perhaps?) which SIDR folk may want to review/etc, sorry for the late notice on this. -chris From iesg-secretary@ietf.org Mon May 16 09:41:18 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0ECE077F; Mon, 16 May 2011 09:41:18 -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 89yTicuG3OCS; Mon, 16 May 2011 09:41:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63640E078E; Mon, 16 May 2011 09:41:17 -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.54 Message-ID: <20110516164117.9684.65658.idtracker@ietfa.amsl.com> Date: Mon, 16 May 2011 09:41:17 -0700 Cc: sidr mailing list , sidr chair , RFC Editor Subject: [sidr] Protocol Action: 'A Profile for X.509 PKIX Resource Certificates' to Proposed Standard (draft-ietf-sidr-res-certs-22.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 16:41:18 -0000 The IESG has approved the following document: - 'A Profile for X.509 PKIX Resource Certificates' (draft-ietf-sidr-res-certs-22.txt) as a Proposed Standard This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sidr-res-certs/ Technical Summary This document defines a standard profile for X.509 certificates for the purposes of supporting validation of assertions of "right-of-use" of Resources (INRs). The certificates issued under this profile are used to convey the Issuer's authorisation of the Subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). The document also specifies profiles for the format of certificate requests. The document also specifies the Relying Party RPKI certificate path validation procedure. Working Group Summary This draft was the first draft presented to the working group and has been a basis for other work in the working group. Several implementators of this certificate profile have conveyed implementation experience that has been incorporated into the draft. Document Quality This document is well written and clear. Over the years, portions have been extracted to become independent drafts and the language has become more concise as a result of detailed reviews. Although this profile does not define a protocol, several independent implementations of this certificate profile exist, indicating careful review. There have been careful reviews by X.509 PKI experts and by ASN.1 experts and their comments have been addressed. Personnel Sandra Murphy is the Document Shepherd for this document. Stewart Bryant is the Responsible Area Director. RFC Editor Note In the References: OLD [ID.sidr-cp] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate Policy (CP) for the Resource PKI (RPKI)", Work in progress: Internet Drafts draft-ietf-sidr-c-13.txt, September 2010. NEW [ID.sidr-cp] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate Policy (CP) for the Resource PKI (RPKI)", Work in progress: Internet Drafts draft-ietf-sidr-cp-13.txt, September 2010. END In Section 4.9.6, 3rd paragraph: OLD: The CRL Distribution Points (CRLDP) extension identifies the location(s) of the CRL(s) associated with certificates issued by this Issuer. The RPKI uses the URI form of object identification. The preferred URI access mechanism is a single RSYNC URI ("rsync://") [RFC5781] that references a single inclusive CRL for each Issuer. NEW: The CRL Distribution Points (CRLDP) extension identifies the location(s) of the CRL(s) associated with certificates issued by this Issuer. The RPKI uses the URI [RFC3986] form of object identification. The preferred URI access mechanism is a single RSYNC URI ("rsync://") [RFC5781] that references a single inclusive CRL for each Issuer. Please add [RFC3986] to the list of Normative References. Please move [RFC5781] to the Normative References. From christopher.morrow@gmail.com Mon May 16 11:25:55 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB40DE0790 for ; Mon, 16 May 2011 11:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, 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 Q8HLObXN-5fm for ; Mon, 16 May 2011 11:25:55 -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 C669AE06B1 for ; Mon, 16 May 2011 11:25:54 -0700 (PDT) Received: by wyb29 with SMTP id 29so4293158wyb.31 for ; Mon, 16 May 2011 11:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5y5cQwShFkTIrDTpb+mcPv1Njd/wGPucnzyT+c8mkDM=; b=fpHa3e9I+CoMVmMJP3JLUNd6lKu1AX6bbeotAytRVWPzB6o6iXBFXjBQom07W73NpP pfyNaaiZpU8EGv+5DYRQi5QaHsfb3cyNeOoieV2Fr9MGKtnD0j+VyYrAmMYF9GBPNFN2 aWEX0xmHw49ErQmnd7HB3eOkob1vfE1N0pMgc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=REHWJRPXqZNj2y8Af54Zkv5U98+3okGSY9tsdLP9kQ35jUtJAze/tbiGt73RXARaMQ TSmwU2DGdlCXiwNVBxzJYGBK+NB5OrWQmIOnYSgB1RVCUs1K71dFFPYj3txzuercDF3C nPR2izHOsY4s60nseojJ9Ua7SPqIAO5v+MrIU= MIME-Version: 1.0 Received: by 10.217.7.72 with SMTP id z50mr26187wes.60.1305570353920; Mon, 16 May 2011 11:25:53 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.216.73.212 with HTTP; Mon, 16 May 2011 11:25:53 -0700 (PDT) In-Reply-To: <4DB9A456.3060709@isi.edu> References: <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> Date: Mon, 16 May 2011 14:25:53 -0400 X-Google-Sender-Auth: jAYAKEpnbNvshk90BQ6hYXzHOgk Message-ID: From: Christopher Morrow To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 18:25:55 -0000 So.. this spun along for a time, the last real bit of controversy was "to AO or not to AO"... The author(s) I think are off looking at alternate options. For now we'll withdraw this WGLC and start another once the authors have updates to report. thanks though folks! -Chris On Thu, Apr 28, 2011 at 1:31 PM, Joe Touch wrote: > > > On 4/28/2011 6:27 AM, t.petch wrote: >> >> ----- Original Message ----- >> From: "Joe Touch" >> To: "t.petch" >> Cc: "Christopher Morrow"; "sidr wg list" >> >> Sent: Monday, April 25, 2011 5:26 PM >> >>> Hi, Tom, >>> >>> On 4/25/2011 1:47 AM, t.petch wrote: >>> .... >>>> >>>> I think that the point is not that it is or is not a BGP connection >>>> but that security for BGP was predicated on the assumption that >>>> the TCP connection would be short in terms of hops, ie none, >>>> and it was that that made a less stringent approach to security >>>> acceptable, one that would not be acceptable for an Internet >>>> wide access for - say - a Web site. >>> >>> Hopcount security, i.e., GTSM (RFC 3682) is not at all related to TCP-A= O. >> >> Understood; I was thinking of RFC4278 which calls out the unusual nature >> of >> BGP sessions and the impact on security requirements. > > That document explains why TCP MD5 was considered appropriate for BGP, gi= ven > the variance in the maturity level of the standards of the two docs. > > TCP-AO has no such assertions or qualifications. It is a general purpose > mechanism that includes some properties useful for BGP, but that are also > very relevant to exchanges between clients and caches as well. > >> I am familiar with TCP-AO from the TCPM list, but am not enough of a >> cryptanalyst to know whether or not it is appropriate for rpki-rtr. >> >> By contrast, I have seen SSH and TLS discussed much more extensively >> on their lists and have been part of the pain of adding them to syslog a= nd >> SNMP. >> >> And I do not know where these rpki-rtr sessions will go to and from but >> suspect that they will not be BGP-like. > > BGP-like presumably means: > =A0 =A0 =A0 =A0- long lived > =A0 =A0 =A0 =A0- between known endpoints > =A0 =A0 =A0 =A0- over short IP hops > > Of these, only "long lived" had any impact on the TCP-AO design. > > Of these, any can be relevant to rpki-rtr sessions, from the traffic I've > seen on this list. > > Keying is another relevant issue; configuration of SSH and TLS for > pre-shared keys is different than for TCP MD5 (and TCP-AO, which uses > similar master keys), and not the typical case. > > My point is that TCP-AO wasn't designed for BGP; it was designed as a > general purpose mechanism. > > Joe > > From iesg-secretary@ietf.org Mon May 16 11:58:08 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDF9E07B2; Mon, 16 May 2011 11:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 aKC0CQEP8auv; Mon, 16 May 2011 11:58:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BF0E07B5; Mon, 16 May 2011 11:58:04 -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.54 Message-ID: <20110516185804.9681.41166.idtracker@ietfa.amsl.com> Date: Mon, 16 May 2011 11:58:04 -0700 Cc: sidr mailing list , sidr chair , RFC Editor Subject: [sidr] Protocol Action: 'RPKI Objects issued by IANA' to Proposed Standard (draft-ietf-sidr-iana-objects-03.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 18:58:08 -0000 The IESG has approved the following document: - 'RPKI Objects issued by IANA' (draft-ietf-sidr-iana-objects-03.txt) as a Proposed Standard This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sidr-iana-objects/ Technical Summary This document provides specific direction to IANA as to the Resource Public Key Infrastructure (RPKI) objects it should issue. Working Group Summary Nothing of note happened in the WG discussion of this document. Document Quality There is nothing of note. There is a greater than normal IANA workload that results from publication of this document. Personnel Chris Morrow is the Document Shepherd for this document. Stewart Bryant is the Responsible Area Director. From iesg-secretary@ietf.org Mon May 16 11:59:57 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A563E07B1; Mon, 16 May 2011 11:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVIR7ozRG4UT; Mon, 16 May 2011 11:59:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D59E07B2; Mon, 16 May 2011 11:59:56 -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.54 Message-ID: <20110516185956.16491.72426.idtracker@ietfa.amsl.com> Date: Mon, 16 May 2011 11:59:56 -0700 Cc: sidr mailing list , sidr chair , RFC Editor Subject: [sidr] Protocol Action: 'Signed Object Template for the Resource Public Key Infrastructure' to Proposed Standard (draft-ietf-sidr-signed-object-04.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 18:59:57 -0000 The IESG has approved the following document: - 'Signed Object Template for the Resource Public Key Infrastructure' (draft-ietf-sidr-signed-object-04.txt) as a Proposed Standard This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sidr-signed-object/ Technical Summary This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. Working Group Summary This document has not been presented at an IETF meeting as an independent draft, but the documents from which the text was extracted have been presented at IETF70, IETF 71, IETF72, IETF73, IETF75, IETF 76, IETF 77, and IETF 79. So the working group has had opportunity to review the content a number of times. The document has had the advice and review of PKIX and CMS experts. Document Quality This document is well written and is clear. Furthermore, the choice to place common text about signatures in a single document (for reference by any other working group document that specifies a new signed object) has improved the quality of the other documents, by eliminating the possibility of inconsistencies between specifications of common features and by allowing the other documents to devote their text to the particular unique features of the signed object they specify. Personnel Sandra Murphy is the Document Shepherd for this document Stewart Bryant is the Responsible Area Director. RFC Editor Note Section 3 nit. If the all of the conditions above are true, then the signed object may be valid. s/the all/all/ From iesg-secretary@ietf.org Mon May 16 12:07:00 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA84E0798; Mon, 16 May 2011 12:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jp6hEuaWf66m; Mon, 16 May 2011 12:06:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F6AE07E5; Mon, 16 May 2011 12:06:42 -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.54 Message-ID: <20110516190642.9817.36077.idtracker@ietfa.amsl.com> Date: Mon, 16 May 2011 12:06:42 -0700 Cc: sidr mailing list , sidr chair , RFC Editor Subject: [sidr] Protocol Action: 'A Profile for Route Origin Authorizations (ROAs)' to Proposed Standard (draft-ietf-sidr-roa-format-12.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 19:07:00 -0000 The IESG has approved the following document: - 'A Profile for Route Origin Authorizations (ROAs)' (draft-ietf-sidr-roa-format-12.txt) as a Proposed Standard This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sidr-roa-format/ Technical Summary This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to that one or more prefixes within the address block. Working Group Summary The working group intently discussed the potential need for multiple signatures for a ROA. The eventual consensus was that the potential was extremely rare and multiple signatures would be painful to understand and diagnose in operational use. The wg decided that single signatures should be all that was required. Document Quality The document is well written and straightforward. Multiple implementations of the RPKI exist, all of which implement this object. The document makes use of the generic signed object draft. That has the intended effect of concentrating the discussion on the aspects of a ROA signed object that are unique to the ROA. Personnel Sandra Murphy is the Document Shepherd for this document. Stewart Bryant is the Responsible Area Director. From christopher.morrow@gmail.com Mon May 16 13:14:01 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38780E0674 for ; Mon, 16 May 2011 13:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 a69P06AIM0t3 for ; Mon, 16 May 2011 13:14:00 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 809F4E0670 for ; Mon, 16 May 2011 13:14:00 -0700 (PDT) Received: by wwa36 with SMTP id 36so3793965wwa.13 for ; Mon, 16 May 2011 13:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=xZgnerIH4LXpHA+xYl92boQGUq0C8bI58wUVusQvAks=; b=Pn/L6skftj/uCYd52jt1bAgXLE7PBBPUQAO2scHOOcCtDa2+DXtRL6koo8QTBnyfIq yTmfRDH6heXLSuk+BkMbnJv6jtR/sqXh/WIB3dcAo0sxk1eV9CWMWZojuNBn7CpAiAY5 MwKiEw/IGgyzseOdkKeF+vgqgk8YKVg/W4zPQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=IhiQS935kU46D+jVvnWS6/6nRUCKYgxREtSRbemaMCTTdCwT21PU1CAC0TRgNuWETJ zhvVDT4kwVOenrpkbKZ7zfeoaUn8aH3Eon5Ov4vYiWwcAPLsRn7nufMqj7EQphDdW1LR uV1q3M56rV5oaOyUDTSdjEy8eAgoC2Mpy5f2M= MIME-Version: 1.0 Received: by 10.216.144.166 with SMTP id n38mr2615912wej.75.1305576839525; Mon, 16 May 2011 13:13:59 -0700 (PDT) Received: by 10.216.73.212 with HTTP; Mon, 16 May 2011 13:13:59 -0700 (PDT) Date: Mon, 16 May 2011 16:13:59 -0400 Message-ID: From: Christopher Morrow To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] Notes from IETF80 meeting posted X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 20:14:01 -0000 like ... 1 month ago, and I forgot to post a note to the list. sorry! -chris From ietfc@btconnect.com Mon May 16 13:27:19 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645C7E07C4 for ; Mon, 16 May 2011 13:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6] 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 yoDF-SnRRWEx for ; Mon, 16 May 2011 13:27:18 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by ietfa.amsl.com (Postfix) with ESMTP id 33507E07AA for ; Mon, 16 May 2011 13:27:16 -0700 (PDT) Received: from host217-43-155-221.range217-43.btcentralplus.com (HELO pc6) ([217.43.155.221]) by c2beaomr06.btconnect.com with SMTP id DBL46741; Mon, 16 May 2011 21:27:13 +0100 (BST) Message-ID: <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Christopher Morrow" References: <4DAF44AC.8060408@isi.edu><4DAF796C.7010807@isi.edu><409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu><01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net><4DB592B3.3090805@isi.edu><033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net><4DB9A456.3060709@isi.edu> Date: Mon, 16 May 2011 21:25:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4DD188A1.004A, actions=TAG X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.5.16.194215:17:7.586, ip=217.43.155.221, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_WWW, __URI_NO_PATH, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4DD188A2.014B,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 20:27:19 -0000 Chris Stepping back from the immediate technical question, I would be surprised if the Security ADs would accept the Security Considerations in 2011. I lack the knowledge of where these sessions will be from and too, and see no guidance in any of the other I0Ds, but suspect that they will span the Internet, ie totally different to an IDR session. And that suggests that anyone anywhere can attack them, so I would expect to see a threat analysis and counters thereto. Just my 0.02£ Tom Petch ----- Original Message ----- From: "Christopher Morrow" To: "Joe Touch" Cc: "t.petch" ; "sidr wg list" Sent: Monday, May 16, 2011 8:25 PM Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? So.. this spun along for a time, the last real bit of controversy was "to AO or not to AO"... The author(s) I think are off looking at alternate options. For now we'll withdraw this WGLC and start another once the authors have updates to report. thanks though folks! -Chris On Thu, Apr 28, 2011 at 1:31 PM, Joe Touch wrote: > > > On 4/28/2011 6:27 AM, t.petch wrote: >> >> ----- Original Message ----- >> From: "Joe Touch" >> To: "t.petch" >> Cc: "Christopher Morrow"; "sidr wg list" >> >> Sent: Monday, April 25, 2011 5:26 PM >> >>> Hi, Tom, >>> >>> On 4/25/2011 1:47 AM, t.petch wrote: >>> .... >>>> >>>> I think that the point is not that it is or is not a BGP connection >>>> but that security for BGP was predicated on the assumption that >>>> the TCP connection would be short in terms of hops, ie none, >>>> and it was that that made a less stringent approach to security >>>> acceptable, one that would not be acceptable for an Internet >>>> wide access for - say - a Web site. >>> >>> Hopcount security, i.e., GTSM (RFC 3682) is not at all related to TCP-AO. >> >> Understood; I was thinking of RFC4278 which calls out the unusual nature >> of >> BGP sessions and the impact on security requirements. > > That document explains why TCP MD5 was considered appropriate for BGP, given > the variance in the maturity level of the standards of the two docs. > > TCP-AO has no such assertions or qualifications. It is a general purpose > mechanism that includes some properties useful for BGP, but that are also > very relevant to exchanges between clients and caches as well. > >> I am familiar with TCP-AO from the TCPM list, but am not enough of a >> cryptanalyst to know whether or not it is appropriate for rpki-rtr. >> >> By contrast, I have seen SSH and TLS discussed much more extensively >> on their lists and have been part of the pain of adding them to syslog and >> SNMP. >> >> And I do not know where these rpki-rtr sessions will go to and from but >> suspect that they will not be BGP-like. > > BGP-like presumably means: > - long lived > - between known endpoints > - over short IP hops > > Of these, only "long lived" had any impact on the TCP-AO design. > > Of these, any can be relevant to rpki-rtr sessions, from the traffic I've > seen on this list. > > Keying is another relevant issue; configuration of SSH and TLS for > pre-shared keys is different than for TCP MD5 (and TCP-AO, which uses > similar master keys), and not the typical case. > > My point is that TCP-AO wasn't designed for BGP; it was designed as a > general purpose mechanism. > > Joe > > From christopher.morrow@gmail.com Mon May 16 17:03:46 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D81E06F4 for ; Mon, 16 May 2011 17:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, 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 JafXgK4YjBdR for ; Mon, 16 May 2011 17:03:45 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 36BC4E0659 for ; Mon, 16 May 2011 17:03:44 -0700 (PDT) Received: by wwa36 with SMTP id 36so3907679wwa.13 for ; Mon, 16 May 2011 17:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lqJjxEv8bfFxi3M0JnkCjBLw5Xi8E/k861Wsen3lqrE=; b=q5HfD2xqMFNRdZzYg6nS2rkOxUnetu9G9JaeEBaCVqhnAfbfTOZLDJvtxi/H+kvSYa 9flglZYuOxhz4xwV/yVxDP+NXKMdi8n+bhGLQfYBJ219iSt99lvns3wHkbifcWsphqiC FmcFEb6Z8FjgqElWYb8iLrQlSpqVMlhuT/jfo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=l+GwfspZQfsKW87BK1Pv5Q11mJWJcO0eTS5zzAjoahg4os71nwXHq8Y1GW4hW8H8m5 iAorZzLjqk4kKJq5pUfYw4tY1PwBBkXffEtol4AO1NxJFb+JF8F2egF8Y2le5vdCyT5N DHK55Kvqn3GZe75jrmp3ow57PYtscF9PHtnEU= MIME-Version: 1.0 Received: by 10.216.239.73 with SMTP id b51mr2738556wer.60.1305590623792; Mon, 16 May 2011 17:03:43 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.216.73.212 with HTTP; Mon, 16 May 2011 17:03:42 -0700 (PDT) In-Reply-To: <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> References: <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> Date: Mon, 16 May 2011 20:03:42 -0400 X-Google-Sender-Auth: aXFzqPeLktGrgKXLimCNpXDQ9Ks Message-ID: From: Christopher Morrow To: "t.petch" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 00:03:46 -0000 On Mon, May 16, 2011 at 3:25 PM, t.petch wrote: > Chris > > Stepping back from the immediate technical question, I would be surprised > if the Security ADs would accept the Security Considerations in 2011. > > I lack the knowledge of where these sessions will be from and too, > and see no guidance in any of the other I0Ds, but I think the idea is that a router gets it's cache data from inside the local ASN, there may be cases where an operator decides to use an extra-AS cache, but that seems less than ideal (bootstrapping issues, business issues, etc). > suspect that they will span the Internet, ie totally different to an IDR > session. > And that suggests that anyone anywhere can attack them, so I would expect > to see a threat analysis and counters thereto. interesting, Randy does this seem like something that you were thinking of as well? or since the intent is to do this sort of thing inside a single ASN (or single administrative domain) is this something that's less critical? > > Just my 0.02=A3 > > Tom Petch > > ----- Original Message ----- > From: "Christopher Morrow" > To: "Joe Touch" > Cc: "t.petch" ; "sidr wg list" > Sent: Monday, May 16, 2011 8:25 PM > Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? > > > So.. this spun along for a time, the last real bit of controversy was > "to AO or not to AO"... The author(s) I think are off looking at > alternate options. For now we'll withdraw this WGLC and start another > once the authors have updates to report. > > thanks though folks! > -Chris > > On Thu, Apr 28, 2011 at 1:31 PM, Joe Touch wrote: >> >> >> On 4/28/2011 6:27 AM, t.petch wrote: >>> >>> ----- Original Message ----- >>> From: "Joe Touch" >>> To: "t.petch" >>> Cc: "Christopher Morrow"; "sidr wg list" >>> >>> Sent: Monday, April 25, 2011 5:26 PM >>> >>>> Hi, Tom, >>>> >>>> On 4/25/2011 1:47 AM, t.petch wrote: >>>> .... >>>>> >>>>> I think that the point is not that it is or is not a BGP connection >>>>> but that security for BGP was predicated on the assumption that >>>>> the TCP connection would be short in terms of hops, ie none, >>>>> and it was that that made a less stringent approach to security >>>>> acceptable, one that would not be acceptable for an Internet >>>>> wide access for - say - a Web site. >>>> >>>> Hopcount security, i.e., GTSM (RFC 3682) is not at all related to TCP-= AO. >>> >>> Understood; I was thinking of RFC4278 which calls out the unusual natur= e >>> of >>> BGP sessions and the impact on security requirements. >> >> That document explains why TCP MD5 was considered appropriate for BGP, g= iven >> the variance in the maturity level of the standards of the two docs. >> >> TCP-AO has no such assertions or qualifications. It is a general purpose >> mechanism that includes some properties useful for BGP, but that are als= o >> very relevant to exchanges between clients and caches as well. >> >>> I am familiar with TCP-AO from the TCPM list, but am not enough of a >>> cryptanalyst to know whether or not it is appropriate for rpki-rtr. >>> >>> By contrast, I have seen SSH and TLS discussed much more extensively >>> on their lists and have been part of the pain of adding them to syslog = and >>> SNMP. >>> >>> And I do not know where these rpki-rtr sessions will go to and from but >>> suspect that they will not be BGP-like. >> >> BGP-like presumably means: >> - long lived >> - between known endpoints >> - over short IP hops >> >> Of these, only "long lived" had any impact on the TCP-AO design. >> >> Of these, any can be relevant to rpki-rtr sessions, from the traffic I'v= e >> seen on this list. >> >> Keying is another relevant issue; configuration of SSH and TLS for >> pre-shared keys is different than for TCP MD5 (and TCP-AO, which uses >> similar master keys), and not the typical case. >> >> My point is that TCP-AO wasn't designed for BGP; it was designed as a >> general purpose mechanism. >> >> Joe >> >> > > From randy@psg.com Tue May 17 22:12:10 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F873E07DA for ; Tue, 17 May 2011 22:12:10 -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 R19EcXv+EfEf for ; Tue, 17 May 2011 22:12:09 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD35E07D0 for ; Tue, 17 May 2011 22:12:09 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QMZ24-0003Gm-KI; Wed, 18 May 2011 05:10:53 +0000 Date: Wed, 18 May 2011 07:10:51 +0200 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 05:12:10 -0000 >> suspect that they will span the Internet, ie totally different to an >> IDR session. And that suggests that anyone anywhere can attack them, >> so I would expect to see a threat analysis and counters thereto. > interesting, Randy does this seem like something that you were > thinking of as well? or since the intent is to do this sort of thing > inside a single ASN (or single administrative domain) is this > something that's less critical? the recommendations in draft-ietf-sidr-origin-ops would seem to be useful here. for example As RPKI-based origin validation relies on the availability of RPKI data, operators SHOULD locate caches close to routers that require these data and services. A router can peer with one or more nearby caches. randy From bertietf@bwijnen.net Wed May 18 01:22:36 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D3FE069E; Wed, 18 May 2011 01:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.299 X-Spam-Level: X-Spam-Status: No, score=-100.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_LIST=2.3, 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 1sxXlVPMYWE1; Wed, 18 May 2011 01:22:35 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 14331E0714; Wed, 18 May 2011 01:22:33 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QMc1H-0006hq-QH; Wed, 18 May 2011 10:22:29 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1QMc1H-0000pD-AM; Wed, 18 May 2011 10:22:15 +0200 Message-ID: <4DD381B6.8060100@bwijnen.net> Date: Wed, 18 May 2011 10:22:14 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Geoff Huston , ggm@apnic.net, Stephen Kent References: <000701cc0ec1$e552d630$aff88290$@com> In-Reply-To: <000701cc0ec1$e552d630$aff88290$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd408885a81480ec11db58983efb7ccffa3 Cc: "Romascanu, Dan \(Dan\)" , Ron Bonica , ops-dir@ietf.org, sidr@ietf.org Subject: [sidr] Operations Directorate Review of draft-ietf-sidr-keyroll-06 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 08:22:36 -0000 [I am not subscribed to the sidr list, so pls copy me explicitly if you want me to see any follow up or responses]. As a member of the Operations Directorate I was asked to review draft-ietf-sidr-keyroll-06 for it's operational impact. It is clear that following procedures described in this document is key to the proper operation of the routing system of the internet. RFC5706 suggests but does not require a separate "operational considerations section". The draft-ietf-sidr-keyroll-06 discusses the operational considerations in the "Security Considerations" section. I can live with that and leave it to the OPS ADs if they rather see that split out in a separate section or not. Substantive comments/questions: - last para on page 4 During the transition of the "current" and "new" CA instances it is necessary for the "new" CA instance to re-issue all subordinate products of the "current" CA. The procedure described here requires I wonder if the "requires" should be a "REQUIRES" (yep, I know that rfc2119 does not have that exact capitalized form of require, but I think that a MUST or REQUIRED is intended here, no?)? - page 6 4. The NEW CA enters a Staging Period. This duration of the Staging Period is determined by the CA, but it SHOULD be no less than 24 hours. Does/would it make sense to also suggest/recommend a max period? Would 48 hours make sense? - given the first para in sect 1, I wonder if ID.ietf-sidr-arch should be a normative instead of a informative reference. Editorial/nits: - sect 1. 1st sentence This document describes an algorithm to by employed by a s/by/be/ (the first occurrence of "by") - page 4, at top: CURRENT: The CURRENT CA is the active CA instance used to accept and process certificate issuance and revocation requests The starting s/requests/requests./ - page 5 expand acronym CPS on its first use in this document. - same for AIA acronym on page 6. - page 6: 4. The NEW CA enters a Staging Period. This duration of the s/This duration of the/The duration of this/ - page 8 expand acronym CMS on its first use in this document. Bert Wijnen From Marcus.Williams@ed.gov Wed May 18 11:04:51 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0026CE0752 for ; Wed, 18 May 2011 11:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 ZXsj6XJ0gWr8 for ; Wed, 18 May 2011 11:04:50 -0700 (PDT) Received: from exprod8og116.obsmtp.com (exprod8og116.obsmtp.com [64.18.3.32]) by ietfa.amsl.com (Postfix) with ESMTP id 973A3E072C for ; Wed, 18 May 2011 11:04:45 -0700 (PDT) Received: from eduptcexmr03.ed.gov ([160.109.63.136]) (using TLSv1) by exprod8ob116.postini.com ([64.18.7.12]) with SMTP ID DSNKTdQKPZRTi3rSu87VKe/Ba6eTAlSuXoyw@postini.com; Wed, 18 May 2011 11:04:50 PDT Received: from eduptcexhb02.ed.gov (eduptcexhb02.ed.gov [165.224.52.34]) by eduptcexmr03.ed.gov (8.13.8/8.13.8) with ESMTP id p4II4i6f032544 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 18 May 2011 13:04:44 -0500 Received: from EDUPTCEXMB02.ed.gov ([165.224.52.20]) by eduptcexhb02.ed.gov ([165.224.52.34]) with mapi; Wed, 18 May 2011 13:04:44 -0500 From: "Williams, Marcus (Contractor)" To: Randy Bush , "George, Wes E [NTK]" Date: Wed, 18 May 2011 13:04:42 -0500 Thread-Topic: [sidr] time Thread-Index: AcwEG+OY+UJiLPZzTRGD9ML03u6iZwRaTIWg Message-ID: References: <54E900DC635DAB4DB7A6D799B3C4CD8E10C8A3BB@PDAWM12B.ad.sprint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 18:04:51 -0000 > >> If you're more than a few years off from the latest ROA issuance > >> dates, then you're probably bogus. Is anyone sure what implications there are to line timing and multiplexed i= nterfaces if I'm "bogus"? Are my otherwise unbogus circuits at risk? Marcus Williams From internet-drafts@ietf.org Mon May 23 07:44:40 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9907EE07A1; Mon, 23 May 2011 07:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 Htb7mKtIwzUN; Mon, 23 May 2011 07:44:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D854DE077A; Mon, 23 May 2011 07:44:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110523144439.12779.30628.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2011 07:44:39 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-arch-13.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 14:44:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : An Infrastructure to Support Secure Internet Routing Author(s) : Matt Lepinski Stephen Kent Filename : draft-ietf-sidr-arch-13.txt Pages : 24 Date : 2011-05-23 This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a resource public key infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) Numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-arch-13.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-sidr-arch-13.txt From internet-drafts@ietf.org Mon May 23 09:15:15 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1638FE06CD; Mon, 23 May 2011 09:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 gHBdmYkZ26sd; Mon, 23 May 2011 09:15:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50B9E0684; Mon, 23 May 2011 09:15:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110523161514.18083.8443.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2011 09:15:14 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-origin-ops-09.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 16:15:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : RPKI-Based Origin Validation Operation Author(s) : Randy Bush Filename : draft-ietf-sidr-origin-ops-09.txt Pages : 9 Date : 2011-05-23 Deployment of RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present them. It is expected to evolve as RPKI-based origin validation is deployed and the dynamics are better understood. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-origin-ops-09.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-sidr-origin-ops-09.txt From randy@psg.com Mon May 23 09:24:28 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4CF0E07C5; Mon, 23 May 2011 09:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 lJRlk+BZPhAn; Mon, 23 May 2011 09:24:27 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 38343E07C4; Mon, 23 May 2011 09:24:27 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QOXve-0009yb-82; Mon, 23 May 2011 16:24:26 +0000 Date: Mon, 23 May 2011 18:24:24 +0200 Message-ID: From: Randy Bush To: internet-drafts@ietf.org In-Reply-To: <20110523161514.18083.8443.idtracker@ietfa.amsl.com> References: <20110523161514.18083.8443.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org, i-d-announce@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-origin-ops-09.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 16:24:28 -0000 modded section 3 Use of RPKI-based origin validation removes any need to originate more specifics to protect against mis-origination of a less specific prefix. Having a ROA for the covering prefix should protect it. To aid translation of ROAs into efficient search algorithms in routers, ROAs SHOULD be as precise as possible, i.e. match prefixes as announced in BGP. E.g. software and operators SHOULD avoid use of excessive max length values in ROAs unless operationally necessary. One advantage of minimal ROA length is that the forged origin attack does not work for sub-prefixes that are not covered by overly long max length. E.g. if, instead of 10.0.0.0/16-24, one issues 10.0.0.0/16 and 10.0.42.0/24, a forged origin attack can not succeed against 10.0.66.0/24. They must attack the whole /16, which is more likely to be noticed. Therefore, ROA generation software MUST use the prefix length as the max length if the user does not specify a max length. Operators SHOULD be conservative in use of max length in ROAs. E.g., if a prefix will have only a few sub-prefixes announced, multiple ROAs for the specific announcements SHOULD be used as opposed to one ROA with a long max length. From kotikalapudi.sriram@nist.gov Tue May 24 05:28:38 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04619E0738 for ; Tue, 24 May 2011 05:28:38 -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 8PyINTmXmLuE for ; Tue, 24 May 2011 05:28:37 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 60FA7E067C for ; Tue, 24 May 2011 05:28:37 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 24 May 2011 08:28:16 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 24 May 2011 08:28:35 -0400 From: "Sriram, Kotikalapudi" To: sidr wg list Date: Tue, 24 May 2011 08:28:05 -0400 Thread-Topic: RIB Size Estimation for BGPSEC Thread-Index: AQHMGgudEKCN3W9/GUSqMamtLl8hAw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] RIB Size Estimation for BGPSEC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 12:28:38 -0000 In response to a request during Q&A at the SIDR WG meeting, April 1, in Pra= gue, I am posting the results of modeling and estimation of the RIB size for BGP= SEC. (I plan to present this work at the SIDR WG meeting in Quebec.) Here is the link for the slides: http://www.antd.nist.gov/~ksriram/BGPSEC_RIB_Estimation.pdf I will also shortly post an excel spread sheet so you can input your view of the BGPSEC world (signed prefix-paths you expect to see in your PE route= r or route reflector over time), and observe the corresponding RIB size estim= ates. Key observations/conclusions =96 mostly copied from the summary/conclusions= slide (Slide #26): o RIB sizes have been estimated for realistic Route Reflector (RR) and Prov= ider Edge (PE) scenarios (with input from a large, Tier 1 ISP). o Different signature algorithms considered (RSA-2048, ECDSA-256). o RIB memory needs to be engineered so it is adequate for algorithm/protoco= l transition down the road. o 15% yearly growth for # unique eBGP prefixes (377K in 2011 to 2.7M in 202= 5). o 9.55x multiplier applied to determine # eBGP prefix paths in RR (i.e., # = eBGP prefix paths in RIB =3D 9.55 x # unique eBGP prefixes). o BGPSEC adoption curve =96 truncated Normal distribution (slides 7-9). =20 o RIB memory requirements (for the RR) are 0.5GB in 2016 to 8.3 GB in 2020 = to 32 GB in 2025 (worst case assuming RSA-2048 all the way; see Slides 14, = 16). o But algorithm transition to ECDSA-256 likely (should happen) before 2020 = [or perhaps even from Day 1 of BGPSEC deployment?]. o Assuming such transition, 20 GB for RIB memory would be a conservative es= timate =96 good all the way out to 2025 (see Slide 25). =20 Comments/suggestions are welcome. Sriram K. Sriram http://www.antd.nist.gov/~ksriram/ From wesley.george@twcable.com Wed May 25 12:55:45 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A92E06A0 for ; Wed, 25 May 2011 12:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.138 X-Spam-Level: ** X-Spam-Status: No, score=2.138 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] 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 5Qh3o4khsNMm for ; Wed, 25 May 2011 12:55:44 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id E3760E0684 for ; Wed, 25 May 2011 12:55:43 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.65,268,1304308800"; d="scan'208,217";a="230483467" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 25 May 2011 15:58:36 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Wed, 25 May 2011 15:54:07 -0400 From: "George, Wesley" To: "sidr@ietf.org" Date: Wed, 25 May 2011 15:54:06 -0400 Thread-Topic: sidr-origin-ops-09 Thread-Index: AcwbFYEquv7WHr6pQ6WPTM1jxba44Q== Message-ID: <34E4F50CAFA10349A41E0756550084FB06499155@PRVPEXVS04.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_34E4F50CAFA10349A41E0756550084FB06499155PRVPEXVS04corpt_" MIME-Version: 1.0 Subject: [sidr] sidr-origin-ops-09 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 19:55:45 -0000 --_000_34E4F50CAFA10349A41E0756550084FB06499155PRVPEXVS04corpt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not sure if this is a nitpick or a legitimate concern, but: "Use of RPKI-based origin validation removes any need to originate more specifics to protect against mis-origination of a less specific prefix. Having a ROA for the covering prefix should protect it." I'm not sure I totally agree with this. Sure, with a relatively complete im= plementation among major networks, coupled with some sane policies in how t= hose networks deal with invalid routes, that is basically true. However, in= an incremental deployment model, it's a little overly optimistic. Perhaps some sort of caveat about incremental deployment and policy is appr= opriate here? Off of the top of my head- "As it is deployed in more and more networks, use of RPKI-based origin vali= dation coupled with appropriate policies to handle invalid announcements wi= ll lessen (and hopefully eliminate?) the need to originate more specifics..= ." Thanks Wes George ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_34E4F50CAFA10349A41E0756550084FB06499155PRVPEXVS04corpt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m not sure if this is a nitpick or a legitim= ate concern, but:

 

“Use of RPKI-based origin validation removes any need to origina=
te

   more specifics to protect against mis-origina= tion of a less specific

   prefix.  Having a ROA for the covering p= refix should protect it.”

 

I’m not sure I totally agree with this. Sure, = with a relatively complete implementation among major networks, coupled wit= h some sane policies in how those networks deal with invalid routes, that i= s basically true. However, in an incremental deployment model, it’s a little overly optimistic.

 

Perhaps some sort of caveat about incremental deploy= ment and policy is appropriate here?

 

Off of the top of my head-

“As it is deployed in more and more networks, = use of RPKI-based origin validation coupled with appropriate policies to ha= ndle invalid announcements will lessen (and hopefully eliminate?) the need = to originate more specifics…”

 

Thanks

Wes George


This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_34E4F50CAFA10349A41E0756550084FB06499155PRVPEXVS04corpt_-- From randy@psg.com Wed May 25 13:31:43 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9493A1300DB for ; Wed, 25 May 2011 13:31:43 -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 5ros0CtvXGPe for ; Wed, 25 May 2011 13:31:42 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2691300D7 for ; Wed, 25 May 2011 13:31:42 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QPKim-000I5t-Vu; Wed, 25 May 2011 20:30:25 +0000 Date: Wed, 25 May 2011 22:30:23 +0200 Message-ID: From: Randy Bush To: Wes George In-Reply-To: <34E4F50CAFA10349A41E0756550084FB06499155@PRVPEXVS04.corp.twcable.com> References: <34E4F50CAFA10349A41E0756550084FB06499155@PRVPEXVS04.corp.twcable.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] sidr-origin-ops-09 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 20:31:43 -0000 > "Use of RPKI-based origin validation removes any need to originate > more specifics to protect against mis-origination of a less > specific prefix. Having a ROA for the covering prefix should > protect it." > > I'm not sure I totally agree with this. Sure, with a relatively > complete implementation among major networks, coupled with some sane > policies in how those networks deal with invalid routes, that is > basically true. However, in an incremental deployment model, it's a > little overly optimistic. > > Perhaps some sort of caveat about incremental deployment and policy is > appropriate here? sure. i'll add some text next pass. thanks. randy From zhangmingui@huawei.com Thu May 26 04:20:51 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B250EE0664; Thu, 26 May 2011 04:20:51 -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 k6iN3nMuBRZ7; Thu, 26 May 2011 04:20:51 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 37A89E06E2; Thu, 26 May 2011 04:20:50 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLS00994VCI89@szxga04-in.huawei.com>; Thu, 26 May 2011 19:17:06 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLS002ASVCITU@szxga04-in.huawei.com>; Thu, 26 May 2011 19:17:06 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 26 May 2011 19:16:56 +0800 Received: from SZXEML503-MBX.china.huawei.com ([169.254.7.71]) by SZXEML402-HUB.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Thu, 26 May 2011 19:17:06 +0800 Date: Thu, 26 May 2011 11:17:05 +0000 From: "Zhangmingui, (Mingui)" X-Originating-IP: [10.110.98.83] To: "sidr@ietf.org" Message-id: <4552F0907735844E9204A62BBDD325E737F477@SZXEML503-MBX.china.huawei.com> 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: [SIDR][IDR]Does DBGP have to be contiguously deployed? Thread-index: AcwblnDrNvIQluMLSdaIOwAOFxKpTw== X-MS-Has-Attach: X-MS-TNEF-Correlator: Cc: "idr@ietf.org" Subject: [sidr] [SIDR][IDR]Does DBGP have to be contiguously deployed? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 11:20:51 -0000 Hi all, The answer is that DBGP does NOT require contiguous deployment in order to be effective. The key purpose of DBGP is to recognize and propagate the suspicious path segment via the DAS-PATH. When the AS router at the far side obtain the UPDATE message with the DAS-PATH missing some intermediate AS numbers, it doesn't matter. This AS router can still use this path segment for detection/validation purpose. Let's use the example in Figure 5.1 to explain (http://tools.ietf.org/html/draft-zhang-idr-decoupling-02). The starter AS router of the DAS-PATH must have deployed DBGP. In this figure, "B" is the starter. "B" can recognize "X" as suspicious node and propagates this via DAS-PATH to "A". We suppose "A" has not deployed DBGP. When A's upstream AS router receives A's update message, it will find that the AS-PATH is "ABCO" and the DAS-PATH is "BX". The detection system just uses "BX" as the input. BTW, it is not recommended to complement the DAS-PATH according to the primary path contained in the same UDPATE message. You will easily find this kind of trick is in vain. Best regards, -- Mingui Zhang Huawei Technologies Co.,Ltd From Sandra.Murphy@cobham.com Thu May 26 14:53:45 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135CA13002B for ; Thu, 26 May 2011 14:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6OU89fAVTfJ for ; Thu, 26 May 2011 14:53:44 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 310AB130012 for ; Thu, 26 May 2011 14:53:42 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p4QLrflV021101; Thu, 26 May 2011 16:53:41 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p4QLrfgM031364; Thu, 26 May 2011 16:53:41 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.107]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 May 2011 17:53:41 -0400 Date: Thu, 26 May 2011 17:53:41 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 26 May 2011 21:53:41.0274 (UTC) FILETIME=[603E6FA0:01CC1BEF] Cc: draft-kent-bgpsec-threats@tools.ietf.org Subject: Re: [sidr] call for adoption of draft-kent-bgpsec-threats-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 21:53:45 -0000 The call for adoption had ended. I see 7 responses supporting adoption and none opposing. I consider this adequate consensus from the wg to adopt the document as a wg draft. The authors should submit a new version as a wg draft (with the draft-ietf-sidr format file name). --Sandy, speaking as wg chair, with appropriate ceremonial garb donned On Tue, 19 Apr 2011, Sandra Murphy wrote: > The working group has been requested to adopt draft-kent-bgpsec-threats-01 as > a working group draft, to satisfy the following item on our charter: > > ID Date Pub Date > Mar 2011 Jun 2012 A document describing threats to the routing system > > Please respond to the list with your opinion as to whether you accept this > draft as a working group draft and are willing to work on it. Remember > that you do not need to accept all content in a draft to adopt, as draft > editors are required to reflect the consensus of the working group. > > This call will end 3 May 2011. > > --Sandy, speaking as wg co-chair, with wg ceremonial garb donned > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From Sandra.Murphy@cobham.com Thu May 26 14:53:56 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D72130036 for ; Thu, 26 May 2011 14:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=-0.114, 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 GbDk9cSs1UzB for ; Thu, 26 May 2011 14:53:56 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 52A8C13002A for ; Thu, 26 May 2011 14:53:56 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p4QLrt6m021109; Thu, 26 May 2011 16:53:55 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p4QLrt5P031376; Thu, 26 May 2011 16:53:55 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.107]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 May 2011 17:53:55 -0400 Date: Thu, 26 May 2011 17:53:55 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 26 May 2011 21:53:55.0274 (UTC) FILETIME=[6896AAA0:01CC1BEF] Cc: draft-ymbk-bgpsec-reqs@tools.ietf.org Subject: Re: [sidr] call for adoption of draft-ymbk-bgpsec-reqs-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 21:53:57 -0000 The call for adoption had ended. I see 5 responses supporting adoption and none opposing. I consider this adequate consensus from the wg to adopt the document as a wg draft. The authors should submit a new version as a wg draft (with the draft-ietf-sidr format file name). --Sandy, speaking as wg chair, with appropriate ceremonial garb donned On Tue, 19 Apr 2011, Sandra Murphy wrote: > The working group has been requested to adopt draft-ymbk-bgpsec-reqs-02 as a > working group draft, to satisfy the following item on our charter: > > ID Date Pub Date > Mar 2011 Jun 2012 A requirements document that addresses these threats > > > Please respond to the list with your opinion as to whether you accept this > draft as a working group draft and are willing to work on it. Remember > that you do not need to accept all content in a draft to adopt, as draft > editors are required to reflect the consensus of the working group. > > This call will end 3 May 2011. > > --Sandy, speaking as wg co-chair, with wg ceremonial garb donned > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From Sandra.Murphy@cobham.com Thu May 26 14:54:20 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E49F13003A for ; Thu, 26 May 2011 14:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 7SLsqAReG9+7 for ; Thu, 26 May 2011 14:54:19 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7D04713002A for ; Thu, 26 May 2011 14:54:19 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p4QLsIRu021113; Thu, 26 May 2011 16:54:18 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p4QLsIhM031399; Thu, 26 May 2011 16:54:18 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.107]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 May 2011 17:54:18 -0400 Date: Thu, 26 May 2011 17:54:18 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 26 May 2011 21:54:18.0727 (UTC) FILETIME=[76914F70:01CC1BEF] Cc: draft-lepinski-bgpsec-overview@tools.ietf.org Subject: Re: [sidr] call for adoption of draft-lepinski-bgpsec-overview-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 21:54:20 -0000 The call for adoption had ended. I see 6 responses supporting adoption and none opposing. I consider this adequate consensus from the wg to adopt the document as a wg draft. The authors should submit a new version as a wg draft (with the draft-ietf-sidr format file name). --Sandy, speaking as wg chair, with appropriate ceremonial garb donned On Tue, 19 Apr 2011, Sandra Murphy wrote: > The working group has been requested to adopt > draft-lepinski-bgpsec-overview-00 as a working group draft, to satisfy the > following item on our charter: > > ID Date Pub Date > Mar 2011 Jan 2012 An overview of the RPKI and BGP Protocol changes > required for origin and path validation > > Please respond to the list with your opinion as to whether you accept this > draft as a working group draft and are willing to work on it. Remember that > you do not need to accept all content in a draft to adopt, as draft editors > are required to reflect the consensus of the working group. > > > This call will end 3 May 2011. > > --Sandy, speaking as wg co-chair, with wg ceremonial garb donned > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From Sandra.Murphy@cobham.com Thu May 26 14:54:29 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B75130041 for ; Thu, 26 May 2011 14:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 V072VK3soS7V for ; Thu, 26 May 2011 14:54:29 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id DD83F13002B for ; Thu, 26 May 2011 14:54:28 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p4QLsST7021123; Thu, 26 May 2011 16:54:28 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p4QLsSb6031411; Thu, 26 May 2011 16:54:28 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.107]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 May 2011 17:54:28 -0400 Date: Thu, 26 May 2011 17:54:28 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 26 May 2011 21:54:28.0196 (UTC) FILETIME=[7C362A40:01CC1BEF] Cc: draft-lepinski-bgpsec-protocol@tools.ietf.org Subject: Re: [sidr] call for adoption of draft-lepinski-bgpsec-protocol-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 21:54:29 -0000 The call for adoption had ended. I see 6 responses supporting adoption and none opposing. Three of the positive responses come from people listed as authors. I have stated in the past that authors need not respond to such calls as their support is presumed. I see that the draft is listed as having 9 authors (!). All told, I consider this adequate consensus from the wg to adopt the document as a wg draft. The authors should submit a new version as a wg draft (with the draft-ietf-sidr format file name). --Sandy, speaking as wg chair, with appropriate ceremonial garb donned On Tue, 19 Apr 2011, Sandra Murphy wrote: > The working group has been requested to adopt > draft-lepinski-bgpsec-protocol-00 as a working group draft, to satisfy the > following item on our charter: > > ID Date Pub Date > Mar 2011 Jan 2012 Document the BGP protocol enhancements that meet > the security requirements > > Please respond to the list with your opinion as to whether you accept this > draft as a working group draft and are willing to work on it. Remember that > you do not need to accept all content in a draft to adopt, as draft editors > are required to reflect the consensus of the working group. > > This call will end 3 May 2011. > > --Sandy, speaking as wg co-chair, with wg ceremonial garb donned > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From Sandra.Murphy@cobham.com Thu May 26 15:03:15 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7734F13002B for ; Thu, 26 May 2011 15:03:15 -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 hU+RD0yJFSef for ; Thu, 26 May 2011 15:03:15 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id CE8B713002A for ; Thu, 26 May 2011 15:03:14 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p4QLsaID021127; Thu, 26 May 2011 16:54:36 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p4QLsafe031417; Thu, 26 May 2011 16:54:36 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.107]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 May 2011 17:54:36 -0400 Date: Thu, 26 May 2011 17:54:36 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 26 May 2011 21:54:36.0243 (UTC) FILETIME=[81020A30:01CC1BEF] Cc: draft-ymbk-bgpsec-ops@tools.ietf.org Subject: Re: [sidr] call for adoption of draft-ymbk-bgpsec-ops-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 22:03:15 -0000 The call for adoption had ended. I see 5 responses supporting adoption and none opposing. I consider this adequate consensus from the wg to adopt the document as a wg draft. The authors should submit a new version as a wg draft (with the draft-ietf-sidr format file name). --Sandy, speaking as wg chair, with appropriate ceremonial garb donned On Tue, 19 Apr 2011, Sandra Murphy wrote: > The working group has been requested to adopt draft-ymbk-bgpsec-ops-01 as a > working group draft, to satisfy the following item on our charter: > > ID Date Pub Date > Mar 2011 Jul 2012 Operational deployment guidance for network operators > > > Please respond to the list with your opinion as to whether you accept this > draft as a working group draft and are willing to work on it. Remember > that you do not need to accept all content in a draft to adopt, as draft > editors are required to reflect the consensus of the working group. > > This call will end 3 May 2011. > > --Sandy, speaking as wg co-chair, with wg ceremonial garb donned > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From daedulus@btconnect.com Fri May 27 09:52:42 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEB2E0819 for ; Fri, 27 May 2011 09:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_20=-0.74] 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 Y0Roz0pElSfT for ; Fri, 27 May 2011 09:52:41 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by ietfa.amsl.com (Postfix) with ESMTP id 1D40EE081E for ; Fri, 27 May 2011 09:52:40 -0700 (PDT) Received: from host217-43-155-221.range217-43.btcentralplus.com (HELO pc6) ([217.43.155.221]) by c2bthomr09.btconnect.com with SMTP id DBG75005; Fri, 27 May 2011 17:52:35 +0100 (BST) Message-ID: <00f301cc1c85$dabc3fa0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Sriram, Kotikalapudi" , "sidr wg list" References: Date: Fri, 27 May 2011 17:50:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4DDFD6D2.011B, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.5.27.153024:17:7.586, ip=217.43.155.221, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __CP_URI_IN_BODY, __SUBJECT_ENDING_IN_LATIN_OR_NUMERALS, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.4DDFD6D5.00E4,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Subject: Re: [sidr] RIB Size Estimation for BGPSEC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 16:52:42 -0000 RRG, before looking for some architectures that would solve the world's routing problems, did discuss the expected capacity of DFZ routers, given the expected rate of growth of technology, so as to work out how long the IETF has got to come up with something new. The consensus was that routers could not be expected to support more than 1M entries in the RIB which is somewhat less than the 2.7M you expect in 2025. And the new architecture could make the world look very different by then, with outer routing headers for delivery to location, and inner routing headers for delivery to the identified host. Tom Petch ----- Original Message ----- From: "Sriram, Kotikalapudi" To: "sidr wg list" Sent: Tuesday, May 24, 2011 2:28 PM Subject: [sidr] RIB Size Estimation for BGPSEC In response to a request during Q&A at the SIDR WG meeting, April 1, in Prague, I am posting the results of modeling and estimation of the RIB size for BGPSEC. (I plan to present this work at the SIDR WG meeting in Quebec.) Here is the link for the slides: http://www.antd.nist.gov/~ksriram/BGPSEC_RIB_Estimation.pdf { file:///D:/Articles/BGPSEC_RIB_Estimation.pdf } I will also shortly post an excel spread sheet so you can input your view of the BGPSEC world (signed prefix-paths you expect to see in your PE router or route reflector over time), and observe the corresponding RIB size estimates. Key observations/conclusions – mostly copied from the summary/conclusions slide (Slide #26): o RIB sizes have been estimated for realistic Route Reflector (RR) and Provider Edge (PE) scenarios (with input from a large, Tier 1 ISP). o Different signature algorithms considered (RSA-2048, ECDSA-256). o RIB memory needs to be engineered so it is adequate for algorithm/protocol transition down the road. o 15% yearly growth for # unique eBGP prefixes (377K in 2011 to 2.7M in 2025). o 9.55x multiplier applied to determine # eBGP prefix paths in RR (i.e., # eBGP prefix paths in RIB = 9.55 x # unique eBGP prefixes). o BGPSEC adoption curve – truncated Normal distribution (slides 7-9). o RIB memory requirements (for the RR) are 0.5GB in 2016 to 8.3 GB in 2020 to 32 GB in 2025 (worst case assuming RSA-2048 all the way; see Slides 14, 16). o But algorithm transition to ECDSA-256 likely (should happen) before 2020 [or perhaps even from Day 1 of BGPSEC deployment?]. o Assuming such transition, 20 GB for RIB memory would be a conservative estimate – good all the way out to 2025 (see Slide 25). Comments/suggestions are welcome. Sriram K. Sriram http://www.antd.nist.gov/~ksriram/ _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From ietfc@btconnect.com Fri May 27 09:54:53 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23171E0720 for ; Fri, 27 May 2011 09:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6MwrCAjYORY for ; Fri, 27 May 2011 09:54:52 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by ietfa.amsl.com (Postfix) with ESMTP id EFE56E070C for ; Fri, 27 May 2011 09:54:51 -0700 (PDT) Received: from host217-43-155-221.range217-43.btcentralplus.com (HELO pc6) ([217.43.155.221]) by c2bthomr14.btconnect.com with SMTP id CZJ04244; Fri, 27 May 2011 17:54:32 +0100 (BST) Message-ID: <00fb01cc1c86$20345e00$4001a8c0@gateway.2wire.net> From: "t.petch" To: Date: Fri, 27 May 2011 17:52:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4DDFD747.010D, actions=tag X-Junkmail-Premium-Raw: score=9/50, refid=2.7.2:2011.5.27.153024:17:9.535, ip=217.43.155.221, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __TO_NO_NAME, __MIME_VERSION, __CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, TO_IN_SUBJECT, __ANY_URI, __CP_URI_IN_BODY, __SUBJECT_ENDING_IN_LATIN_OR_NUMERALS, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.4DDFD75A.000E,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Subject: [sidr] RIB Size Estimation for BGPSEC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 16:54:53 -0000 Try again ... and again ... RRG, before looking for some architectures that would solve the world's routing problems, did discuss the expected capacity of DFZ routers, given the expected rate of growth of technology, so as to work out how long the IETF has got to come up with something new. The consensus was that routers could not be expected to support more than 1M entries in the RIB which is somewhat less than the 2.7M you expect in 2025. And the new architecture could make the world look very different by then, with outer routing headers for delivery to location, and inner routing headers for delivery to the identified host. Tom Petch > ----- Original Message ----- > From: "Sriram, Kotikalapudi" > To: "sidr wg list" > Sent: Tuesday, May 24, 2011 2:28 PM > Subject: [sidr] RIB Size Estimation for BGPSEC > > > In response to a request during Q&A at the SIDR WG meeting, April 1, in Prague, > I am posting the results of modeling and estimation of the RIB size for BGPSEC. > (I plan to present this work at the SIDR WG meeting in Quebec.) > > Here is the link for the slides: > > http://www.antd.nist.gov/~ksriram/BGPSEC_RIB_Estimation.pdf > { file:///D:/Articles/BGPSEC_RIB_Estimation.pdf } > > I will also shortly post an excel spread sheet so you can input your view > of the BGPSEC world (signed prefix-paths you expect to see in your PE router > or route reflector over time), and observe the corresponding RIB size estimates. > > Key observations/conclusions – mostly copied from the summary/conclusions slide > (Slide #26): > > o RIB sizes have been estimated for realistic Route Reflector (RR) and Provider > Edge (PE) scenarios (with input from a large, Tier 1 ISP). > > o Different signature algorithms considered (RSA-2048, ECDSA-256). > > o RIB memory needs to be engineered so it is adequate for algorithm/protocol > transition down the road. > > o 15% yearly growth for # unique eBGP prefixes (377K in 2011 to 2.7M in 2025). > > o 9.55x multiplier applied to determine # eBGP prefix paths in RR (i.e., # eBGP > prefix paths in RIB = 9.55 x # unique eBGP prefixes). > > o BGPSEC adoption curve – truncated Normal distribution (slides 7-9). > > o RIB memory requirements (for the RR) are 0.5GB in 2016 to 8.3 GB in 2020 to 32 > GB in 2025 (worst case assuming RSA-2048 all the way; see Slides 14, 16). > > o But algorithm transition to ECDSA-256 likely (should happen) before 2020 [or > perhaps even from Day 1 of BGPSEC deployment?]. > > o Assuming such transition, 20 GB for RIB memory would be a conservative > estimate – good all the way out to 2025 (see Slide 25). > > Comments/suggestions are welcome. > > Sriram > > K. Sriram > http://www.antd.nist.gov/~ksriram/ > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From kotikalapudi.sriram@nist.gov Fri May 27 10:58:46 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74FEDE0726 for ; Fri, 27 May 2011 10:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] 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 QRJwAnPVPkvp for ; Fri, 27 May 2011 10:58:45 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDB6E066A for ; Fri, 27 May 2011 10:58:45 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 27 May 2011 13:58:19 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 27 May 2011 13:58:25 -0400 From: "Sriram, Kotikalapudi" To: t.petch , "sidr@ietf.org" Date: Fri, 27 May 2011 13:58:20 -0400 Thread-Topic: [sidr] RIB Size Estimation for BGPSEC Thread-Index: AcwcjsDTl4uOrtnsTmO4dbv4X0haMgABHe8g Message-ID: References: <00fb01cc1c86$20345e00$4001a8c0@gateway.2wire.net> In-Reply-To: <00fb01cc1c86$20345e00$4001a8c0@gateway.2wire.net> 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" MIME-Version: 1.0 Subject: Re: [sidr] RIB Size Estimation for BGPSEC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 17:58:46 -0000 Tom, Thanks for your comment. We have preliminary results that extend the RIB estimation (with BGPSEC) to LISP (or, similar map-and-encap type of protocols). That is, the scenario when LISP and BGPSEC are both in use. I thought of sharing only the BGPSEC RIB modeling results for now. Needless to say, in the scenario as you mention, "outer routing headers for delivery to location, and inner routing headers for delivery to the identified host", the RIB estimates for BGPSEC would be much smaller for core PE routers or RRs. Any thoughts on what a realistic timeline might be for adoption of LISP or ILNP (or any solution) for FIB scalability? (Well, I hear you say - by the time the FIB size exceeds ~1M.) Sriram > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of t.petch > Sent: Friday, May 27, 2011 11:53 AM > To: sidr@ietf.org > Subject: [sidr] RIB Size Estimation for BGPSEC > > Try again ... > and again ... > > RRG, before looking for some architectures that would solve the world's routing > problems, did discuss the expected capacity of DFZ routers, given the expected > rate of growth of technology, so as to work out how long the IETF has got to > come up with something new. > > The consensus was that routers could not be expected to support more than 1M > entries in the RIB which is somewhat less than the 2.7M you expect in 2025. > And > the new architecture could make the world look very different by then, with > outer routing headers for delivery to location, and inner routing headers for > delivery to the identified host. > > Tom Petch > > > ----- Original Message ----- > > From: "Sriram, Kotikalapudi" > > To: "sidr wg list" > > Sent: Tuesday, May 24, 2011 2:28 PM > > Subject: [sidr] RIB Size Estimation for BGPSEC > > > > > > In response to a request during Q&A at the SIDR WG meeting, April 1, in > Prague, > > I am posting the results of modeling and estimation of the RIB size for > BGPSEC. > > (I plan to present this work at the SIDR WG meeting in Quebec.) > > > > Here is the link for the slides: > > > > http://www.antd.nist.gov/~ksriram/BGPSEC_RIB_Estimation.pdf > > { file:///D:/Articles/BGPSEC_RIB_Estimation.pdf } -- snip --- From tony.li@tony.li Mon May 30 11:44:32 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C5BE0681 for ; Mon, 30 May 2011 11:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=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 E8CWpgDpfl-4 for ; Mon, 30 May 2011 11:44:29 -0700 (PDT) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by ietfa.amsl.com (Postfix) with ESMTP id D9954E0664 for ; Mon, 30 May 2011 11:44:29 -0700 (PDT) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta04.emeryville.ca.mail.comcast.net with comcast id puh71g0020EPchoA4ukUub; Mon, 30 May 2011 18:44:28 +0000 Received: from sjc-vpn3-80.cisco.com ([128.107.239.233]) by omta01.emeryville.ca.mail.comcast.net with comcast id puk81g00N52qHCY8MukF8L; Mon, 30 May 2011 18:44:30 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Tony Li X-Priority: 3 In-Reply-To: <00fb01cc1c86$20345e00$4001a8c0@gateway.2wire.net> Date: Mon, 30 May 2011 11:44:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <204B0BE0-30FA-4DD2-8117-D3A78B8CA684@tony.li> References: <00fb01cc1c86$20345e00$4001a8c0@gateway.2wire.net> To: t.petch X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: Re: [sidr] RIB Size Estimation for BGPSEC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 18:44:32 -0000 Not to mention the fact that IPv6 is going to have a significant = contribution. Tony =20 On May 27, 2011, at 8:52 AM, t.petch wrote: > Try again ... > and again ... >=20 > RRG, before looking for some architectures that would solve the = world's routing > problems, did discuss the expected capacity of DFZ routers, given the = expected > rate of growth of technology, so as to work out how long the IETF has = got to > come up with something new. >=20 > The consensus was that routers could not be expected to support more = than 1M > entries in the RIB which is somewhat less than the 2.7M you expect in = 2025. > And > the new architecture could make the world look very different by then, = with > outer routing headers for delivery to location, and inner routing = headers for > delivery to the identified host. >=20 > Tom Petch >=20 >> ----- Original Message ----- >> From: "Sriram, Kotikalapudi" >> To: "sidr wg list" >> Sent: Tuesday, May 24, 2011 2:28 PM >> Subject: [sidr] RIB Size Estimation for BGPSEC >>=20 >>=20 >> In response to a request during Q&A at the SIDR WG meeting, April 1, = in > Prague, >> I am posting the results of modeling and estimation of the RIB size = for > BGPSEC. >> (I plan to present this work at the SIDR WG meeting in Quebec.) >>=20 >> Here is the link for the slides: >>=20 >> http://www.antd.nist.gov/~ksriram/BGPSEC_RIB_Estimation.pdf >> { file:///D:/Articles/BGPSEC_RIB_Estimation.pdf } >>=20 >> I will also shortly post an excel spread sheet so you can input your = view >> of the BGPSEC world (signed prefix-paths you expect to see in your PE = router >> or route reflector over time), and observe the corresponding RIB size > estimates. >>=20 >> Key observations/conclusions =96 mostly copied from the = summary/conclusions > slide >> (Slide #26): >>=20 >> o RIB sizes have been estimated for realistic Route Reflector (RR) = and > Provider >> Edge (PE) scenarios (with input from a large, Tier 1 ISP). >>=20 >> o Different signature algorithms considered (RSA-2048, ECDSA-256). >>=20 >> o RIB memory needs to be engineered so it is adequate for = algorithm/protocol >> transition down the road. >>=20 >> o 15% yearly growth for # unique eBGP prefixes (377K in 2011 to 2.7M = in 2025). >>=20 >> o 9.55x multiplier applied to determine # eBGP prefix paths in RR = (i.e., # > eBGP >> prefix paths in RIB =3D 9.55 x # unique eBGP prefixes). >>=20 >> o BGPSEC adoption curve =96 truncated Normal distribution (slides = 7-9). >>=20 >> o RIB memory requirements (for the RR) are 0.5GB in 2016 to 8.3 GB in = 2020 to > 32 >> GB in 2025 (worst case assuming RSA-2048 all the way; see Slides 14, = 16). >>=20 >> o But algorithm transition to ECDSA-256 likely (should happen) before = 2020 [or >> perhaps even from Day 1 of BGPSEC deployment?]. >>=20 >> o Assuming such transition, 20 GB for RIB memory would be a = conservative >> estimate =96 good all the way out to 2025 (see Slide 25). >>=20 >> Comments/suggestions are welcome. >>=20 >> Sriram >>=20 >> K. Sriram >> http://www.antd.nist.gov/~ksriram/ >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From internet-drafts@ietf.org Tue May 31 05:03:14 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F609E0848; Tue, 31 May 2011 05:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 iQRdowUmwDix; Tue, 31 May 2011 05:03:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A1CE07A1; Tue, 31 May 2011 05:03:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110531120309.28188.99662.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2011 05:03:09 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-manifests-12.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 12:03:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : Manifests for the Resource Public Key Infrastructure Author(s) : Rob Austein Geoff Huston Stephen Kent Matt Lepinski Filename : draft-ietf-sidr-rpki-manifests-12.txt Pages : 19 Date : 2011-05-31 This document defines a "manifest" for use in the Resource Pub= lic Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority, that are published at this repository publication point, the manifest contains both the name of the file containing the object, and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (= valid) data and deletion of signed objects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-manifests-12.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-sidr-rpki-manifests-12.txt From iesg-secretary@ietf.org Tue May 31 09:07:43 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEED9E07DC; Tue, 31 May 2011 09:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBSvk6vQb+cU; Tue, 31 May 2011 09:07:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7A7E08A1; Tue, 31 May 2011 09:07:34 -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: <20110531160734.28776.86648.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2011 09:07:34 -0700 Cc: sidr mailing list , sidr chair , RFC Editor Subject: [sidr] Document Action: 'An Infrastructure to Support Secure Internet Routing' to Informational RFC (draft-ietf-sidr-arch-13.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 16:07:43 -0000 The IESG has approved the following document: - 'An Infrastructure to Support Secure Internet Routing' (draft-ietf-sidr-arch-13.txt) as an Informational RFC This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sidr-arch/ Technical Summary This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a public key infrastructure (PKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) Numbers; and a distributed repository system for storing and disseminating the data objects that comprise the PKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. Working Group Summary This draft's first version came early in the working group history. It has been presented many times and has gone through many versions but the outline remains essentially the same, indicating consistency in the working group thinking. Document Quality The document is well written and clear. It does not describe a protocol, so there are no "implementations" per se. However, it serves as the reference point for the other working group drafts, so the authors of this draft and the authors of the other drafts have worked to ensure that they remain mutually consistent. Several implementations exist of the PKI expressed in this architecture. Implementation experience has been reflected in changes in the architecture. Personnel Sandra Murphy is the Document Shepherd for this document. Stewart Bryant is the Responsible Area Director. From paul.hoffman@vpnc.org Tue May 31 09:40:05 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB899E0795 for ; Tue, 31 May 2011 09:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 KTSHq7qsbKaQ for ; Tue, 31 May 2011 09:40:05 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDD8E0746 for ; Tue, 31 May 2011 09:40:04 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p4VGe16q053602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 31 May 2011 09:40:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Tue, 31 May 2011 09:40:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4167B366-02DE-4637-9CA1-175E3A1BB321@vpnc.org> References: <8A7BEFB8FCD25A43BB73B1D879B82F770457B0AF@xmb-sjc-239.amer.cisco.com> To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: Re: [sidr] rpki-rtr protocol maximum message length X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 16:40:05 -0000 On Apr 30, 2011, at 11:14 PM, Randy Bush wrote: >> Most of the messages in the protocol are nice and small messages, but >> the error-report message can be of arbitrary size since it can have >> trailing diagnostic text... >>=20 >> Can we specify a maximum value for length of this message? A cache >> implementation can send a huge amount of diagnostic text in an >> error-report message and have it still be a valid message for the >> router to parse... It should be capped at a few K. >=20 > the longest non-error pdu is pdu 6, the ipv6 pdu. this limits the max > size error pdu to a fairly small size. Even with a restriction on the size of the arbitrary text, that = statement is not completely true. An Error PDU can be sent for another = Error PDU, ad infinitum; these could apply to error types 0 and 1. Maybe = add to section 5.9 "An Error Report PDU MUST NOT be sent for an Error = Report PDU.". To answer the initial request, it seems reasonable to specify "the = length of the Arbitrary Text of Error Diagnostic Message MUST NOT be = longer than 200 octets". That keeps the length of the entire PDU under = the semi-magic 256 octets for the current version of the protocol and = yet gives bloviators such as myself plenty of room in our error = messages. --Paul Hoffman From kotikalapudi.sriram@nist.gov Tue May 31 09:52:47 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF215E068E for ; Tue, 31 May 2011 09:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Eod+y+GUFTW for ; Tue, 31 May 2011 09:52:43 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id D7F45E0805 for ; Tue, 31 May 2011 09:52:14 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 31 May 2011 12:52:24 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 31 May 2011 12:50:23 -0400 From: "Sriram, Kotikalapudi" To: Tony Li , t.petch Date: Tue, 31 May 2011 12:50:22 -0400 Thread-Topic: [sidr] RIB Size Estimation for BGPSEC Thread-Index: Acwe+ZNh7J48JUP5RqGnLg3cgABfvwAsrKiA Message-ID: References: <00fb01cc1c86$20345e00$4001a8c0@gateway.2wire.net> <204B0BE0-30FA-4DD2-8117-D3A78B8CA684@tony.li> In-Reply-To: <204B0BE0-30FA-4DD2-8117-D3A78B8CA684@tony.li> 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" MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] RIB Size Estimation for BGPSEC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 16:52:47 -0000 > Not to mention the fact that IPv6 is going to have a significant contribution. > > Tony I think you are saying (extending Tom's observation) that the transition to a FIB scalability solution possibly should happen sooner due to IPv6 growth (as compared to that based on IPv4 growth considerations alone). Whenever such transition occurs, it would be beneficial for BGPSEC because engineered RIB capacity would be good for a far longer period. The following related observations regarding the RIB model are worth noting. The model assumes 15% yearly growth for # unique prefixes or total # prefix-paths. Currently we do not explicitly break it down between IPv4 and IPv6. Initially the bulk of the 15% growth would be due to IPv4 but one can expect that after a period of time, the IPv4 growth would trend down to a lower level while the IPv6 growth would contribute increasingly to the overall 15% yearly growth in announced prefixes. The model is parameterized and further refined projections for IPv4 and IPv6 can be incorporated when available. The BGPSEC RIB estimate for a given total # prefix-paths is minimally sensitive to the mix of IPv4 and IPv6. That is because a very high percentage of octets in a signed update is due to the signatures, and the sig size (for a given sig algorithm) is independent of IPv4 or IPv6. Sriram > > > >> ----- Original Message ----- > >> From: "Sriram, Kotikalapudi" > >> To: "sidr wg list" > >> Sent: Tuesday, May 24, 2011 2:28 PM > >> Subject: [sidr] RIB Size Estimation for BGPSEC > >> > >> > >> In response to a request during Q&A at the SIDR WG meeting, April 1, in > > Prague, > >> I am posting the results of modeling and estimation of the RIB size for > > BGPSEC. > >> (I plan to present this work at the SIDR WG meeting in Quebec.) > >> > >> Here is the link for the slides: > >> http://www.antd.nist.gov/~ksriram/BGPSEC_RIB_Estimation.pdf -- snip -- From randy@psg.com Tue May 31 10:25:07 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF48E088E for ; Tue, 31 May 2011 10:25:07 -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 OnDE3dmwLunX for ; Tue, 31 May 2011 10:25:06 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 9401EE085C for ; Tue, 31 May 2011 10:25:06 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QRSfU-000Axk-MP; Tue, 31 May 2011 17:23:49 +0000 Date: Tue, 31 May 2011 20:23:46 +0300 Message-ID: From: Randy Bush To: Paul Hoffman In-Reply-To: <4167B366-02DE-4637-9CA1-175E3A1BB321@vpnc.org> References: <8A7BEFB8FCD25A43BB73B1D879B82F770457B0AF@xmb-sjc-239.amer.cisco.com> <4167B366-02DE-4637-9CA1-175E3A1BB321@vpnc.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] rpki-rtr protocol maximum message length X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 17:25:07 -0000 > 1. Maybe add to section 5.9 "An Error Report PDU MUST NOT be sent for > an Error Report PDU.". makes sense > To answer the initial request, it seems reasonable to specify "the > length of the Arbitrary Text of Error Diagnostic Message MUST NOT be > longer than 200 octets". That keeps the length of the entire PDU under > the semi-magic 256 octets for the current version of the protocol in what way is 256 octets semi-magic? randy From tony.li@tony.li Tue May 31 10:26:22 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996E7E08A9 for ; Tue, 31 May 2011 10:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 YeK-GfblZmGM for ; Tue, 31 May 2011 10:26:20 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id A4F94E085C for ; Tue, 31 May 2011 10:26:11 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta04.westchester.pa.mail.comcast.net with comcast id qGqR1g0041swQuc54HSCDC; Tue, 31 May 2011 17:26:12 +0000 Received: from [10.155.35.134] ([128.107.239.233]) by omta15.westchester.pa.mail.comcast.net with comcast id qHRC1g03W52qHCY3bHRdMF; Tue, 31 May 2011 17:26:00 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: Date: Tue, 31 May 2011 10:25:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <816E6B06-F281-48E5-8433-2909058778BF@tony.li> References: <00fb01cc1c86$20345e00$4001a8c0@gateway.2wire.net> <204B0BE0-30FA-4DD2-8117-D3A78B8CA684@tony.li> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1084) Cc: "sidr@ietf.org" Subject: Re: [sidr] RIB Size Estimation for BGPSEC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 17:26:22 -0000 Not at all. What I'm trying to say is that the IPv6 RIB is already = growing at about 60% y/y. Further, the transition to IPv6 _may_ trigger = de-aggregation within the IPv4 RIB, as we maximize the utilization of = the v4 address space. Given these two factors, I'm highly skeptical of a 15% growth rate. Tony On May 31, 2011, at 9:50 AM, Sriram, Kotikalapudi wrote: >> Not to mention the fact that IPv6 is going to have a significant = contribution. >>=20 >> Tony >=20 > I think you are saying (extending Tom's observation) that the = transition to a=20 > FIB scalability solution possibly should happen sooner due to IPv6 = growth > (as compared to that based on IPv4 growth considerations alone). > Whenever such transition occurs, it would be beneficial for BGPSEC > because engineered RIB capacity would be good for a far longer period. >=20 > The following related observations regarding the RIB model are worth = noting. > The model assumes 15% yearly growth for # unique prefixes or total # = prefix-paths. > Currently we do not explicitly break it down between IPv4 and IPv6. > Initially the bulk of the 15% growth would be due to IPv4 but one can = expect that after a period of time, the IPv4 growth would trend down to = a lower level while the IPv6 growth would contribute increasingly to the = overall 15% yearly growth in announced prefixes. >=20 > The model is parameterized and further refined projections for=20 > IPv4 and IPv6 can be incorporated when available. >=20 > The BGPSEC RIB estimate for a given total # prefix-paths is minimally = sensitive to the mix of=20 > IPv4 and IPv6. That is because a very high percentage of octets in a = signed update is due=20 > to the signatures, and the sig size (for a given sig algorithm) is = independent of IPv4 or IPv6.=20 >=20 > Sriram >=20 >>>=20 >>>> ----- Original Message ----- >>>> From: "Sriram, Kotikalapudi" >>>> To: "sidr wg list" >>>> Sent: Tuesday, May 24, 2011 2:28 PM >>>> Subject: [sidr] RIB Size Estimation for BGPSEC >>>>=20 >>>>=20 >>>> In response to a request during Q&A at the SIDR WG meeting, April = 1, in >>> Prague, >>>> I am posting the results of modeling and estimation of the RIB size = for >>> BGPSEC. >>>> (I plan to present this work at the SIDR WG meeting in Quebec.) >>>>=20 >>>> Here is the link for the slides: >>>>=20 > http://www.antd.nist.gov/~ksriram/BGPSEC_RIB_Estimation.pdf=20 >=20 > -- snip -- From randy@psg.com Tue May 31 10:29:32 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891FEE07A2 for ; Tue, 31 May 2011 10:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ADv6nnAj62KI for ; Tue, 31 May 2011 10:29:31 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id AD998E068E for ; Tue, 31 May 2011 10:29:31 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QRSkx-000AyR-GZ; Tue, 31 May 2011 17:29:28 +0000 Date: Tue, 31 May 2011 20:29:24 +0300 Message-ID: From: Randy Bush To: Tony Li In-Reply-To: <816E6B06-F281-48E5-8433-2909058778BF@tony.li> References: <00fb01cc1c86$20345e00$4001a8c0@gateway.2wire.net> <204B0BE0-30FA-4DD2-8117-D3A78B8CA684@tony.li> <816E6B06-F281-48E5-8433-2909058778BF@tony.li> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] RIB Size Estimation for BGPSEC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 17:29:32 -0000 > Not at all. What I'm trying to say is that the IPv6 RIB is already > growing at about 60% y/y. Further, the transition to IPv6 _may_ > trigger de-aggregation within the IPv4 RIB, as we maximize the > utilization of the v4 address space. > > Given these two factors, I'm highly skeptical of a 15% growth rate. sriram was working on the effects of bgpsec on the growth rate, not every other game being played in town. give the man a break. randy From christopher.morrow@gmail.com Tue May 31 10:42:48 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E24E087A for ; Tue, 31 May 2011 10:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 sk7lF49dMTbH for ; Tue, 31 May 2011 10:42:48 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7D6E085C for ; Tue, 31 May 2011 10:42:48 -0700 (PDT) Received: by pzk5 with SMTP id 5so2375929pzk.31 for ; Tue, 31 May 2011 10:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rtiSUi//iwjDHZ/1m8HAEfw+oO5q1KWZCceW6kZLB6A=; b=oDUySd60mTfUWJHDKG7pGDgQ78B4j8Ke5QnI+bGkf6EN1WLCnBXIGgONhqyMfLGZqu OOp8m54V86gLq0OWjl2l0hIXrEvflsQQirOtbG4gxqFkMyJvtrn/WP9Z+Ga5YYSGB+OU hZDuf311Qxo+01sme46/8QHX8JNehS14m7DZo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=La7oFl+q0Tj9LJSM9xElz718qN34mHL+zM22kfAk+eus87164FIOCb1eqJ+FonPgiz w7hr+CLn0oBIlndP0+F8frK6q1xS1cfSFIn4Js7v3k8keIDNQ6m6j5Ad++vP8p83NBwW wd9u7d/eN2S61AxYXsjB0j2eo+v6VXxS/Slho= MIME-Version: 1.0 Received: by 10.68.17.99 with SMTP id n3mr2666915pbd.351.1306863767728; Tue, 31 May 2011 10:42:47 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.68.56.133 with HTTP; Tue, 31 May 2011 10:42:47 -0700 (PDT) In-Reply-To: References: <00fb01cc1c86$20345e00$4001a8c0@gateway.2wire.net> <204B0BE0-30FA-4DD2-8117-D3A78B8CA684@tony.li> <816E6B06-F281-48E5-8433-2909058778BF@tony.li> Date: Tue, 31 May 2011 13:42:47 -0400 X-Google-Sender-Auth: viKxf61xbvZ9ssmaZxZ-UW6leP4 Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] RIB Size Estimation for BGPSEC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 17:42:49 -0000 On Tue, May 31, 2011 at 1:29 PM, Randy Bush wrote: >> Not at all. =A0What I'm trying to say is that the IPv6 RIB is already >> growing at about 60% y/y. =A0Further, the transition to IPv6 _may_ >> trigger de-aggregation within the IPv4 RIB, as we maximize the >> utilization of the v4 address space. >> >> Given these two factors, I'm highly skeptical of a 15% growth rate. > > sriram was working on the effects of bgpsec on the growth rate, not > every other game being played in town. =A0give the man a break. to be fair to both parties... the excel can be adjusted if you so desire... (add/change/etc the routes data and watch the numbers really get big!) it does seem interesting to play with the numbers some, and depending upon your particular mix of routes/paths see what damage you may bring down. From ietfc@btconnect.com Tue May 31 10:43:48 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F84E086F for ; Tue, 31 May 2011 10:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.887 X-Spam-Level: X-Spam-Status: No, score=-0.887 tagged_above=-999 required=5 tests=[AWL=-1.488, BAYES_50=0.001, J_CHICKENPOX_15=0.6] 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 CVQbXVeGi8sY for ; Tue, 31 May 2011 10:43:47 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by ietfa.amsl.com (Postfix) with ESMTP id 66DB2E06D9 for ; Tue, 31 May 2011 10:43:46 -0700 (PDT) Received: from host217-43-155-221.range217-43.btcentralplus.com (HELO pc6) ([217.43.155.221]) by c2bthomr13.btconnect.com with SMTP id DAP65700; Tue, 31 May 2011 18:43:40 +0100 (BST) Message-ID: <021d01cc1fb1$a4429080$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Sriram, Kotikalapudi" , References: <00fb01cc1c86$20345e00$4001a8c0@gateway.2wire.net> Date: Tue, 31 May 2011 18:41:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4DE528CB.00BD, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.5.31.164218:17:7.586, ip=217.43.155.221, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __CP_URI_IN_BODY, __SUBJECT_ENDING_IN_LATIN_OR_NUMERALS, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020B.4DE528CD.0184,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Subject: Re: [sidr] RIB Size Estimation for BGPSEC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 17:43:48 -0000 ----- Original Message ----- From: "Sriram, Kotikalapudi" To: "t.petch" ; Sent: Friday, May 27, 2011 7:58 PM > Tom, > > Thanks for your comment. > We have preliminary results that extend the RIB estimation (with BGPSEC) to > LISP (or, similar map-and-encap type of protocols). > That is, the scenario when LISP and BGPSEC are both in use. > I thought of sharing only the BGPSEC RIB modeling results for now. > Needless to say, in the scenario as you mention, > "outer routing headers for delivery to location, and inner routing headers for > delivery to the identified host", the RIB estimates for BGPSEC > would be much smaller for core PE routers or RRs. > > Any thoughts on what a realistic timeline might be for adoption of > LISP or ILNP (or any solution) for FIB scalability? > (Well, I hear you say - by the time the FIB size exceeds ~1M.) Ah, you are much more ahead of the game than I realised:-) I don't have any good data on LISP (or ILNP) except that I expect that eventually LISP will sweep all before it. It's a bit like IPv6; we are out of IPv4 addresses so IPv6 is a must so why can't I get an IPv6 service from any ISP whatsoever? So we run out of FIB space and noone does anything? seems likely:-(. Pick a figure from the air - 2020? Tom Petch > Sriram > > > -----Original Message----- > > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of t.petch > > Sent: Friday, May 27, 2011 11:53 AM > > To: sidr@ietf.org > > Subject: [sidr] RIB Size Estimation for BGPSEC > > > > Try again ... > > and again ... > > > > RRG, before looking for some architectures that would solve the world's routing > > problems, did discuss the expected capacity of DFZ routers, given the expected > > rate of growth of technology, so as to work out how long the IETF has got to > > come up with something new. > > > > The consensus was that routers could not be expected to support more than 1M > > entries in the RIB which is somewhat less than the 2.7M you expect in 2025. > > And > > the new architecture could make the world look very different by then, with > > outer routing headers for delivery to location, and inner routing headers for > > delivery to the identified host. > > > > Tom Petch > > > > > ----- Original Message ----- > > > From: "Sriram, Kotikalapudi" > > > To: "sidr wg list" > > > Sent: Tuesday, May 24, 2011 2:28 PM > > > Subject: [sidr] RIB Size Estimation for BGPSEC > > > > > > > > > In response to a request during Q&A at the SIDR WG meeting, April 1, in > > Prague, > > > I am posting the results of modeling and estimation of the RIB size for > > BGPSEC. > > > (I plan to present this work at the SIDR WG meeting in Quebec.) > > > > > > Here is the link for the slides: > > > > > > http://www.antd.nist.gov/~ksriram/BGPSEC_RIB_Estimation.pdf > > > { file:///D:/Articles/BGPSEC_RIB_Estimation.pdf } > > -- snip --- From randy@psg.com Tue May 31 10:44:44 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF00E081B for ; Tue, 31 May 2011 10:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCmjJX8P28kr for ; Tue, 31 May 2011 10:44:43 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 30633E06D9 for ; Tue, 31 May 2011 10:44:43 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QRSzb-000B0p-PD; Tue, 31 May 2011 17:44:36 +0000 Date: Tue, 31 May 2011 20:44:32 +0300 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <00fb01cc1c86$20345e00$4001a8c0@gateway.2wire.net> <204B0BE0-30FA-4DD2-8117-D3A78B8CA684@tony.li> <816E6B06-F281-48E5-8433-2909058778BF@tony.li> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] RIB Size Estimation for BGPSEC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 17:44:44 -0000 >> sriram was working on the effects of bgpsec on the growth rate, not >> every other game being played in town. =A0give the man a break. >=20 > to be fair to both parties... the excel can be adjusted if you so > desire. true. and we could play with it to try to model lots of causes. point taken. randy From jgs@juniper.net Tue May 31 10:50:14 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B7FE086F for ; Tue, 31 May 2011 10:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 a2VBzOp8fY2c for ; Tue, 31 May 2011 10:50:13 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 394F7E06C0 for ; Tue, 31 May 2011 10:50:13 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTeUqTzr5MhCva10XxEiLHGFKDiiFFIi4@postini.com; Tue, 31 May 2011 10:50:13 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 31 May 2011 10:48:00 -0700 From: John Scudder To: t.petch Date: Tue, 31 May 2011 10:47:58 -0700 Thread-Topic: [sidr] RIB Size Estimation for BGPSEC Thread-Index: AcwfuuHIRO8VJU1HTH+DPy/SibSINg== Message-ID: References: <00f301cc1c85$dabc3fa0$4001a8c0@gateway.2wire.net> In-Reply-To: <00f301cc1c85$dabc3fa0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Sriram, Kotikalapudi" , sidr wg list Subject: Re: [sidr] RIB Size Estimation for BGPSEC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 17:50:14 -0000 On May 27, 2011, at 11:50 AM, t.petch wrote: > RRG, before looking for some architectures that would solve the world's r= outing > problems, did discuss the expected capacity of DFZ routers, given the ex= pected > rate of growth of technology, so as to work out how long the IETF has got= to > come up with something new. >=20 > The consensus was that routers could not be expected to support more than= 1M > entries in the RIB [...] Really? I wouldn't put too much stock in that, given that current routers = support substantially more than 1M. > which is somewhat less than the 2.7M you expect in 2025. More than that too. Possibly you meant FIB and not RIB? The reported numbers are wrong for tha= t too, though not as egregiously. --John= From paul.hoffman@vpnc.org Tue May 31 10:52:11 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE1BE081B for ; Tue, 31 May 2011 10:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 Qk82nxN9jwo0 for ; Tue, 31 May 2011 10:52:10 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 131BCE06C0 for ; Tue, 31 May 2011 10:52:09 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p4VHq7R1060700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 31 May 2011 10:52:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Tue, 31 May 2011 10:52:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8A7BEFB8FCD25A43BB73B1D879B82F770457B0AF@xmb-sjc-239.amer.cisco.com> <4167B366-02DE-4637-9CA1-175E3A1BB321@vpnc.org> To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: Re: [sidr] rpki-rtr protocol maximum message length X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 17:52:11 -0000 On May 31, 2011, at 10:23 AM, Randy Bush wrote: >> 1. Maybe add to section 5.9 "An Error Report PDU MUST NOT be sent for >> an Error Report PDU.". >=20 > makes sense >=20 >> To answer the initial request, it seems reasonable to specify "the >> length of the Arbitrary Text of Error Diagnostic Message MUST NOT be >> longer than 200 octets". That keeps the length of the entire PDU = under >> the semi-magic 256 octets for the current version of the protocol >=20 > in what way is 256 octets semi-magic? C or assembly-based implementations will need to malloc (etc.) the = buffer for the incoming message. Having that fit into 256 octets could = easily have some value to some implementations. There is no security = problem if the cache ignores such a MUST and makes the message longer = because the length is given the PDU. (Having said that, I hope router = implementers of this protocol are being robust in checking the lengths = in this PDU; I can already see ways to craft malicious versions of this = PDU that might trigger a buffer overflow...) One can say a lot in 200 octets, even of UTF8.=20 --Paul Hoffman From touch@isi.edu Tue May 31 10:57:22 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E66DE08AF for ; Tue, 31 May 2011 10:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.219 X-Spam-Level: X-Spam-Status: No, score=-103.219 tagged_above=-999 required=5 tests=[AWL=-0.620, 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 B75WcN0CmcS5 for ; Tue, 31 May 2011 10:57:21 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 79ABFE081B for ; Tue, 31 May 2011 10:57:21 -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 p4VHuqjn013471 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 31 May 2011 10:56:52 -0700 (PDT) Message-ID: <4DE52BE4.3040900@isi.edu> Date: Tue, 31 May 2011 10:56:52 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Paul Hoffman References: <8A7BEFB8FCD25A43BB73B1D879B82F770457B0AF@xmb-sjc-239.amer.cisco.com> <4167B366-02DE-4637-9CA1-175E3A1BB321@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: sidr@ietf.org Subject: Re: [sidr] rpki-rtr protocol maximum message length X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 17:57:22 -0000 On 5/31/2011 10:52 AM, Paul Hoffman wrote: > On May 31, 2011, at 10:23 AM, Randy Bush wrote: > >>> 1. Maybe add to section 5.9 "An Error Report PDU MUST NOT be sent for >>> an Error Report PDU.". >> >> makes sense >> >>> To answer the initial request, it seems reasonable to specify "the >>> length of the Arbitrary Text of Error Diagnostic Message MUST NOT be >>> longer than 200 octets". That keeps the length of the entire PDU under >>> the semi-magic 256 octets for the current version of the protocol >> >> in what way is 256 octets semi-magic? > > C or assembly-based implementations will need to malloc (etc.) the > buffer for the incoming message. Having that fit into 256 octets could > easily have some value to some implementations. There is no security > problem if the cache ignores such a MUST and makes the message longer > because the length is given the PDU. (Having said that, I hope router > implementers of this protocol are being robust in checking the lengths > in this PDU; I can already see ways to craft malicious versions of this > PDU that might trigger a buffer overflow...) These are good reasons for robust implementations to check for the message length and read only as much as the currently allocated buffer allows, reading more in as needed. There's no need for a MUST for that. Attackers tend to ignore MUSTs anyway. Joe From heas@shrubbery.net Tue May 31 11:14:34 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48220E071B for ; Tue, 31 May 2011 11:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+iraeNtD+Dr for ; Tue, 31 May 2011 11:14:33 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2402E06D9 for ; Tue, 31 May 2011 11:14:33 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 84DBC24B5F7; Tue, 31 May 2011 11:29:09 -0700 (PDT) Date: Tue, 31 May 2011 18:29:09 +0000 From: john heasley To: Paul Hoffman Message-ID: <20110531182909.GK19935@shrubbery.net> References: <8A7BEFB8FCD25A43BB73B1D879B82F770457B0AF@xmb-sjc-239.amer.cisco.com> <4167B366-02DE-4637-9CA1-175E3A1BB321@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.5.20 (2009-06-14) Cc: sidr@ietf.org Subject: Re: [sidr] rpki-rtr protocol maximum message length X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 18:14:34 -0000 Tue, May 31, 2011 at 10:52:07AM -0700, Paul Hoffman: > C or assembly-based implementations will need to malloc (etc.) the buffer for the incoming message. Having that fit into 256 octets could easily have some value to some implementations. that magic could just as easily be 64 or 512 octets (or ...). i dont understand this concern or need of compensation that keeps coming up for what seems like lousy implementations (of memory allocators, of ...). From hannes@juniper.net Tue May 31 11:21:26 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C5FE08CB for ; Tue, 31 May 2011 11:21:26 -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 cAdgMUA4LtGQ for ; Tue, 31 May 2011 11:21:26 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id AE64AE08C9 for ; Tue, 31 May 2011 11:21:25 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTeUxmZPXKLFnZa+OtW64fk/PmUJVdPMp@postini.com; Tue, 31 May 2011 11:21:25 PDT Received: from hannes-755.juniper.net (172.23.4.178) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.2.254.0; Tue, 31 May 2011 11:19:26 -0700 Received: by hannes-755.juniper.net (Postfix, from userid 1000) id F372B202BF; Tue, 31 May 2011 20:19:10 +0200 (CEST) Date: Tue, 31 May 2011 20:19:10 +0200 From: Hannes Gredler To: Joe Touch Message-ID: <20110531181909.GB18034@juniper.net> References: <8A7BEFB8FCD25A43BB73B1D879B82F770457B0AF@xmb-sjc-239.amer.cisco.com> <4167B366-02DE-4637-9CA1-175E3A1BB321@vpnc.org> <4DE52BE4.3040900@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <4DE52BE4.3040900@isi.edu> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Paul Hoffman , sidr@ietf.org Subject: Re: [sidr] rpki-rtr protocol maximum message length X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 18:21:26 -0000 On Tue, May 31, 2011 at 10:56:52AM -0700, Joe Touch wrote: | | | On 5/31/2011 10:52 AM, Paul Hoffman wrote: | >On May 31, 2011, at 10:23 AM, Randy Bush wrote: | > | >>>1. Maybe add to section 5.9 "An Error Report PDU MUST NOT be sent for | >>>an Error Report PDU.". | >> | >>makes sense | >> | >>>To answer the initial request, it seems reasonable to specify "the | >>>length of the Arbitrary Text of Error Diagnostic Message MUST NOT be | >>>longer than 200 octets". That keeps the length of the entire PDU under | >>>the semi-magic 256 octets for the current version of the protocol | >> | >>in what way is 256 octets semi-magic? | > | >C or assembly-based implementations will need to malloc (etc.) the | >buffer for the incoming message. Having that fit into 256 octets could | >easily have some value to some implementations. There is no security | >problem if the cache ignores such a MUST and makes the message longer | >because the length is given the PDU. (Having said that, I hope router | >implementers of this protocol are being robust in checking the lengths | >in this PDU; I can already see ways to craft malicious versions of this | >PDU that might trigger a buffer overflow...) | | These are good reasons for robust implementations to check for the | message length and read only as much as the currently allocated | buffer allows, reading more in as needed. wonder what the normative procedure is for "too-large" messages ? my pre-standard implementation has an inbound buffer of 4K and resets the session if it encounters a PDU length of > 4K. From touch@isi.edu Tue May 31 11:26:22 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BC6E06BE for ; Tue, 31 May 2011 11:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.188 X-Spam-Level: X-Spam-Status: No, score=-103.188 tagged_above=-999 required=5 tests=[AWL=-0.589, 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 QA6cfp4TCLVP for ; Tue, 31 May 2011 11:26:22 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0875AE06B6 for ; Tue, 31 May 2011 11:26:21 -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 p4VIQ6XL020992 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 31 May 2011 11:26:06 -0700 (PDT) Message-ID: <4DE532BD.5030805@isi.edu> Date: Tue, 31 May 2011 11:26:05 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Hannes Gredler References: <8A7BEFB8FCD25A43BB73B1D879B82F770457B0AF@xmb-sjc-239.amer.cisco.com> <4167B366-02DE-4637-9CA1-175E3A1BB321@vpnc.org> <4DE52BE4.3040900@isi.edu> <20110531181909.GB18034@juniper.net> In-Reply-To: <20110531181909.GB18034@juniper.net> 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: Paul Hoffman , sidr@ietf.org Subject: Re: [sidr] rpki-rtr protocol maximum message length X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 18:26:22 -0000 On 5/31/2011 11:19 AM, Hannes Gredler wrote: > On Tue, May 31, 2011 at 10:56:52AM -0700, Joe Touch wrote: > | > | > | On 5/31/2011 10:52 AM, Paul Hoffman wrote: > |>On May 31, 2011, at 10:23 AM, Randy Bush wrote: > |> > |>>>1. Maybe add to section 5.9 "An Error Report PDU MUST NOT be sent for > |>>>an Error Report PDU.". > |>> > |>>makes sense > |>> > |>>>To answer the initial request, it seems reasonable to specify "the > |>>>length of the Arbitrary Text of Error Diagnostic Message MUST NOT be > |>>>longer than 200 octets". That keeps the length of the entire PDU under > |>>>the semi-magic 256 octets for the current version of the protocol > |>> > |>>in what way is 256 octets semi-magic? > |> > |>C or assembly-based implementations will need to malloc (etc.) the > |>buffer for the incoming message. Having that fit into 256 octets could > |>easily have some value to some implementations. There is no security > |>problem if the cache ignores such a MUST and makes the message longer > |>because the length is given the PDU. (Having said that, I hope router > |>implementers of this protocol are being robust in checking the lengths > |>in this PDU; I can already see ways to craft malicious versions of this > |>PDU that might trigger a buffer overflow...) > | > | These are good reasons for robust implementations to check for the > | message length and read only as much as the currently allocated > | buffer allows, reading more in as needed. > > wonder what the normative procedure is for "too-large" messages ? > > my pre-standard implementation has an inbound buffer of 4K > and resets the session if it encounters a PDU length of> 4K. That makes an easy DOS attack. It's better to: - allocate a 4K (or whatever value you want) buffer - read up to the first 4K - check to see if there's more to read, and allocate more buffer space or read it into the first buffer (after the first 4K has been parsed) Either way, there's no reason for a *protocol action* to deal with a receiver buffering issue. Joe From randy@psg.com Tue May 31 11:28:40 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380E4E0709 for ; Tue, 31 May 2011 11:28:40 -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 L-ox-53iuhGp for ; Tue, 31 May 2011 11:28:39 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9B0E06B9 for ; Tue, 31 May 2011 11:28:39 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QRTgE-000B64-J8; Tue, 31 May 2011 18:28:39 +0000 Date: Tue, 31 May 2011 21:28:36 +0300 Message-ID: From: Randy Bush To: Hannes Gredler In-Reply-To: <20110531181909.GB18034@juniper.net> References: <8A7BEFB8FCD25A43BB73B1D879B82F770457B0AF@xmb-sjc-239.amer.cisco.com> <4167B366-02DE-4637-9CA1-175E3A1BB321@vpnc.org> <4DE52BE4.3040900@isi.edu> <20110531181909.GB18034@juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] rpki-rtr protocol maximum message length X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 18:28:40 -0000 > wonder what the normative procedure is for "too-large" messages ? anything over 246.34 octets should have every other nibble removed, then repacked, and the procedure repeated until it is under 246.34 octets. i'll get that into the next draft. can we please keep the idr out of sidr? randy From christopher.morrow@gmail.com Tue May 31 12:33:25 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70BF5E0849 for ; Tue, 31 May 2011 12:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 9XKnAX2OJEp4 for ; Tue, 31 May 2011 12:33:25 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id DD7A9E0681 for ; Tue, 31 May 2011 12:33:24 -0700 (PDT) Received: by pvh18 with SMTP id 18so2427554pvh.31 for ; Tue, 31 May 2011 12:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FeXhzTAKSj5aZA73NCo+TUAZ6QrNL7fYRSOwxmtnmjI=; b=MzAXpL4o2CVnyBEAVI3CRX4p8W2qEYbfeOrvg7g2JMwCAsp0WuWiRghhKnZpyZPgD6 iG6dKD6OYOxAg4aVXpsRj9WUlvZ6rhCj6HvglnWmSa3Yv+S7jnPdljd8j3ixla15g5Nc 3R3z3Ob0/BnnuAMIF9eJkUd5Vi03UDYm9RlM0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=k8T3IJIuQe9qeMZvyNB+nrg6tF1UsrEYWHRQBIMLIapjRXN0p1ih2K2Vqdx4P0p496 dJ6PxkzAAWachfi6WmuO5NlHMmShHRr55M5poQ2Tfvp2WElWAW12nv47oenp9oXiRcy7 zTa8EbNwDV3NhbKK9dRzMVMmEY1MFOFTeQe1k= MIME-Version: 1.0 Received: by 10.68.69.8 with SMTP id a8mr2486689pbu.418.1306870404184; Tue, 31 May 2011 12:33:24 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.68.56.133 with HTTP; Tue, 31 May 2011 12:33:24 -0700 (PDT) In-Reply-To: References: <00fb01cc1c86$20345e00$4001a8c0@gateway.2wire.net> <204B0BE0-30FA-4DD2-8117-D3A78B8CA684@tony.li> <816E6B06-F281-48E5-8433-2909058778BF@tony.li> Date: Tue, 31 May 2011 15:33:24 -0400 X-Google-Sender-Auth: H2rkGZ-2CFnd5b2msS1MVRb9BDA Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] RIB Size Estimation for BGPSEC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 19:33:25 -0000 On Tue, May 31, 2011 at 1:44 PM, Randy Bush wrote: >>> sriram was working on the effects of bgpsec on the growth rate, not >>> every other game being played in town. =A0give the man a break. >> >> to be fair to both parties... the excel can be adjusted if you so >> desire. > > true. =A0and we could play with it to try to model lots of causes. =A0poi= nt > taken. what I like it for is: "I see XX routes today, I think based on my past I should see YY in 2 years, tell that engineering guy to tell the procurement guy to get me more RAMZ!!!" please use this in your measurements before buying gear, cause if it takes you 5+ years to flip a piece of gear in/out of your network... knowing NOW what you may need THEN would be good to tell vendors NOW ;) -chris From hannes@juniper.net Tue May 31 23:59:34 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAFAE0697 for ; Tue, 31 May 2011 23:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPf8++Qs8bKM for ; Tue, 31 May 2011 23:59:33 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 4A438E06B6 for ; Tue, 31 May 2011 23:59:33 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTeXjSGfVul4f022xh6pMGByKb1FORjig@postini.com; Tue, 31 May 2011 23:59:33 PDT Received: from hannes-755.juniper.net (172.23.4.178) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.2.254.0; Tue, 31 May 2011 23:58:11 -0700 Received: by hannes-755.juniper.net (Postfix, from userid 1000) id 08DB1284E0; Wed, 1 Jun 2011 08:57:54 +0200 (CEST) Date: Wed, 1 Jun 2011 08:57:54 +0200 From: Hannes Gredler To: Joe Touch Message-ID: <20110601065753.GC18752@juniper.net> References: <8A7BEFB8FCD25A43BB73B1D879B82F770457B0AF@xmb-sjc-239.amer.cisco.com> <4167B366-02DE-4637-9CA1-175E3A1BB321@vpnc.org> <4DE52BE4.3040900@isi.edu> <20110531181909.GB18034@juniper.net> <4DE532BD.5030805@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <4DE532BD.5030805@isi.edu> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Paul Hoffman , sidr@ietf.org Subject: Re: [sidr] rpki-rtr protocol maximum message length X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 06:59:34 -0000 On Tue, May 31, 2011 at 11:26:05AM -0700, Joe Touch wrote: | | | On 5/31/2011 11:19 AM, Hannes Gredler wrote: | >On Tue, May 31, 2011 at 10:56:52AM -0700, Joe Touch wrote: | >| | >| | >| On 5/31/2011 10:52 AM, Paul Hoffman wrote: | >|>On May 31, 2011, at 10:23 AM, Randy Bush wrote: | >|> | >|>>>1. Maybe add to section 5.9 "An Error Report PDU MUST NOT be sent for | >|>>>an Error Report PDU.". | >|>> | >|>>makes sense | >|>> | >|>>>To answer the initial request, it seems reasonable to specify "the | >|>>>length of the Arbitrary Text of Error Diagnostic Message MUST NOT be | >|>>>longer than 200 octets". That keeps the length of the entire PDU under | >|>>>the semi-magic 256 octets for the current version of the protocol | >|>> | >|>>in what way is 256 octets semi-magic? | >|> | >|>C or assembly-based implementations will need to malloc (etc.) the | >|>buffer for the incoming message. Having that fit into 256 octets could | >|>easily have some value to some implementations. There is no security | >|>problem if the cache ignores such a MUST and makes the message longer | >|>because the length is given the PDU. (Having said that, I hope router | >|>implementers of this protocol are being robust in checking the lengths | >|>in this PDU; I can already see ways to craft malicious versions of this | >|>PDU that might trigger a buffer overflow...) | >| | >| These are good reasons for robust implementations to check for the | >| message length and read only as much as the currently allocated | >| buffer allows, reading more in as needed. | > | >wonder what the normative procedure is for "too-large" messages ? | > | >my pre-standard implementation has an inbound buffer of 4K | >and resets the session if it encounters a PDU length of> 4K. | | That makes an easy DOS attack. i fail to see why max-PDU size spelled out in a protocol-spec is a pre-cursor to a DOS attack. as long as the message integrity of your TCP session is preserved (e.g. MD5, AO) its perfectly letigimate to flap a session if i do not like what i see. | It's better to: | | - allocate a 4K (or whatever value you want) buffer | - read up to the first 4K | - check to see if there's more to read, and allocate more buffer | space or read it into the first buffer (after the first 4K has been | parsed) i am not so sure about wether the above is really "better", since there is a price to pay. in the above you are assuming that each input parser is a true "stream parser" such that the entire parsing context is saved when e.g. a PDU is scattered across two buffers. e.g. consider an IPV4 Prefix where the first part is in buffer #1 and the reminder is in buffer #2. --- Buffer 1 [ ... ] .-------------------------------------------. | Protocol | PDU | | | Version | Type | reserved = zero | | 0 | 4 | | +-------------------------------------------+ | | | Length=20 | | | +-------------------------------------------+ | | Prefix | Max | | | Flags | Length | Length | zero | | | 0..32 | 0..32 | | +-------------------------------------------+ | | | IPv4 Prefix | | | +-------------------------------------------+ --- End of Buffer 1 Buffer 2 +-------------------------------------------+ | | | Autonomous System Number | | | `-------------------------------------------' [ ... ] lets further assume that between reading buffer 1 and buffer 2 there is a time lag (e.g. the socket just got flow blocked). now you need to save your previous parsing results up until the socket becomes readable again. with max-PDU sized recv buffers the whole story gets a whole lot simpler, as you can avoid the context saving for each and every input parser: you just need to ask. 1. do i have enough data in the buffer for reading the PDU header ? 2. if so does the message exceed the recv buffer ? 3. do i have enough data in the buffer for parsing an entire PDU ? | Either way, there's no reason for a *protocol action* to deal with a | receiver buffering issue. i find less code-complexity in input parsers a quite compelling argument.