From ietfc@btconnect.com Mon Aug 1 09:45:41 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 893F821F8D3B for ; Mon, 1 Aug 2011 09:45:41 -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] 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 uZs5ojgqQwGg for ; Mon, 1 Aug 2011 09:45:40 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by ietfa.amsl.com (Postfix) with ESMTP id 58BB321F8D3A for ; Mon, 1 Aug 2011 09:45:39 -0700 (PDT) Received: from host109-153-78-164.range109-153.btcentralplus.com (HELO pc6) ([109.153.78.164]) by c2bthomr09.btconnect.com with SMTP id DXL93210; Mon, 01 Aug 2011 17:45:16 +0100 (BST) Message-ID: <04fe01cc5061$90fdbe60$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Shane Amante" , "Montgomery, Douglas" References: <19BD9B69-B1EE-495E-8795-38DDE3BF6D4A@castlepoint.net> <2C3246E7-A4AD-4335-BCDA-73D98DDB0274@castlepoint.net> Date: Mon, 1 Aug 2011 17:42:01 +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.0A0B0301.4E36D81A.00C7, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.8.1.153314:17:7.586, ip=109.153.78.164, 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, BODY_SIZE_5000_5999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, 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.0A0B0209.4E36D81F.00F9,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@ietf.org Subject: Re: [sidr] pCNT & (AS_PATH) prepending: Is it in scope? 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, 01 Aug 2011 16:45:41 -0000 ----- Original Message ----- From: "Shane Amante" To: "Montgomery, Douglas" Cc: Sent: Thursday, July 28, 2011 11:18 PM > > On Jul 28, 2011, at 1:43 PM, Montgomery, Douglas wrote: > > > The discussion so far has not been protecting/validating if prepending *should have* occurred. BGPSEC protects the AS_PATH. Prepending occurs in the AS_PATH. Today's strawman presented one approach to protect the fact that prepending *did* occur (without comment as if it should have occurred). > > Right. But, if BGPSEC is not "commenting" whether AS_PATH prepending should, or should not, have occurred, then wouldn't it be more straightforward to avoid representing AS_PATH prepending in BGPSEC's AS_PATH Attr? IOW, isn't the intent of the BGPSEC AS_PATH signature to "simply" represent the ASN's over which the BGP UPDATE has travelled? Why does AS_PATH prepending *need* representation in the BGPSEC AS_PATH Attr, (or, what does it help with wrt BGPSEC)? > > The SIDR WG instigated the deprecation of AS_SET's for reasons of simplification. If WG really believes in simplification, then why does that not apply here wrt AS_PATH prepending? I do not think that it was simplification that led to the deprecation of AS-SET, rather the difficulty or impossibility of securing it to the same extent as a single AS; which led to the discovery that AS_SET were rare and that their loss would not affect almost all of the Internet. Question is; how common is prepending? I thought that it was widespread and 'normal' but there would have to be hard data first, before deprecation could be contemplated. Tom Petch > > With that interpretation, I don't think today's proposal violates the requirement about presuming intent. > > > > This too is good discussion as to what the requirement is. > > > > If we want to protect the common encoding of prepending in the AS_PATH today's strawman provides a simple approach. > > > > I don't know if your example is primarily pointing out another situation where prepending occurs on ingress .... or if we you are proposing that we discuss protecting the intent to prepend. > > > > If it is the latter - that is a significant expansion of requirements - and there are no obvious simple enhancements of bgpsec-00 mechanisms that would get us there. > > So, I grudgingly agree with the requirement, as written, that a BGPSEC AS_PATH signature should not describe/express intent. (I'd feel better if the requirement were changed to say "does not" describe/express intent, but I'm not sure there is consensus to do so ...). > > Ultimately, my concern is the more "faithfully" the AS_PATH appears to be represented in the BGPSEC AS_PATH Attr (i.e.: it does include AS_PATH prepending), then: > a) The more potential confusion there might be with operators who aren't well versed in SIDR incorrectly /assuming/ that it does describe intent[1]; and/or, > b) The more potential/temptation there may be for vendors to use the BGPSEC AS_PATH Attr in BGP path selection (i.e.: as the AS_PATH length tie-breaker) in place of the legacy AS_PATH Attribute. This has implications wrt control plane scaling w/out any appreciable benefit. > > -shane > > [1] Yeah, yeah, they should RTFM ... > > > > > > dougm > > > > > > > > > > Doug Montgomery - Manager Internet and Scalable Systems Research Group / Information Technology Laboratory / NIST > > ________________________________________ > > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] On Behalf Of Shane Amante [shane@castlepoint.net] > > Sent: Thursday, July 28, 2011 3:00 PM > > To: sidr@ietf.org > > Subject: [sidr] pCNT & (AS_PATH) prepending: Is it in scope? > > > > Hi, > > > > I have a question for the WG. In a series of e-mail exchanges earlier this year, I had thought it was concluded that BGPSEC was merely being used as a means to express that a BGP UPDATE had passed through a series of ASN's, i.e.: it's an expression of a "breadcrumbs", if you will, that can [later] be validated by receiver that are further downstream. IOW, it's not a validation of the TE policies (e.g.: AS_PATH prepending) applied by ASN's. > > > > I went back to the BGPSEC requirements: > > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-reqs-00 > > ... and, if I look at Req #3.19: > > 3.19 A BGPsec design SHOULD NOT presume to know the intent of the > > originator of a NLRI, nor that of any AS on the AS Path. > > > > What was the intended meaning of the word "intent"? I thought that word was meant to say that BGPsec was not intended to validate TE policies that may, or may not, be applied to the NLRI. If that is correct, then why is the WG looking at signing an BGP attribute that expresses the the number of times an ASN may be prepended? Or, has the WG had a change of direction and I haven't kept up to speed? > > > > I would note that the reason I'm asking the above is that it may not be the originator that is performing AS_PATH prepending. Specifically, a customer may use a provider's BGP TE communities to ask the provider to perform AS_PATH prepending (selectively) on their behalf. But, since these BGP TE communities are not signed, then how would a receiver of the NLRI know that an AS_PATH should or should not have been prepended by an intermediate/transit ASN? > > > > Thanks, > > > > -shane > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Mon Aug 1 10:17: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 CC74411E80AB for ; Mon, 1 Aug 2011 10:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 Kvb0NoW67nnT for ; Mon, 1 Aug 2011 10:17:55 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 04D2821F8A67 for ; Mon, 1 Aug 2011 10:17:36 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qnw7T-0003z2-Fa; Mon, 01 Aug 2011 17:17:35 +0000 Date: Tue, 02 Aug 2011 02:17:34 +0900 Message-ID: From: Randy Bush To: "t.petch" In-Reply-To: <04fe01cc5061$90fdbe60$4001a8c0@gateway.2wire.net> References: <19BD9B69-B1EE-495E-8795-38DDE3BF6D4A@castlepoint.net> <2C3246E7-A4AD-4335-BCDA-73D98DDB0274@castlepoint.net> <04fe01cc5061$90fdbe60$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@ietf.org Subject: Re: [sidr] pCNT & (AS_PATH) prepending: Is it in scope? 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, 01 Aug 2011 17:17:55 -0000 not your fault, but very hard to find your text amid the top posting, lack of line wraps, quoting disasters, ... > I do not think that it was simplification that led to the deprecation > of AS-SET, rather the difficulty or impossibility of securing it to > the same extent as a single AS; which led to the discovery that AS_SET > were rare and that their loss would not affect almost all of the > Internet. we knew as-sets were rare. but before moving to deprecate we decided to actually measure how rare. note that as-sets affect both origin validation and path validation. > Question is; how common is prepending? I thought that it was > widespread and 'normal' but there would have to be hard data first, > before deprecation could be contemplated. we could measure. but given that we can see that it is quite common, and we have reasonable ways to deal with it, why should we spend the time? what might we learn? randy From dougm@nist.gov Mon Aug 1 10:31: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 1D8D021F8CBE for ; Mon, 1 Aug 2011 10:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=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 WsHW1+iSiwGo for ; Mon, 1 Aug 2011 10:31:54 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id F0D3021F8CBC for ; Mon, 1 Aug 2011 10:31:53 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.323.0; Mon, 1 Aug 2011 13:32:00 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 1 Aug 2011 13:31:58 -0400 From: "Montgomery, Douglas" To: t.petch , Shane Amante , "Montgomery, Douglas" Date: Mon, 1 Aug 2011 13:31:55 -0400 Thread-Topic: [sidr] pCNT & (AS_PATH) prepending: Is it in scope? Thread-Index: AcxQcNZ6vmxc0/WeTUe+3z9P7kLioQ== Message-ID: In-Reply-To: <04fe01cc5061$90fdbe60$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] pCNT & (AS_PATH) prepending: Is it in scope? 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, 01 Aug 2011 17:31:55 -0000 I find the discussion of the "intent" of prepending a bit confusing. The previous notes and presentation in SIDR tried to make clear that ... 1. As currently spec'ed bgpsec-00 signs each prepend with a unique sig. I.e., prepend lists are protected in -00 spec. 2. We could either (a) continue to protect prepends, but optimize down to 1 sig per unique AS, or (b) completely ignore (I.e, skip over and not protect) prepends in the sig gen/validation logic, or (c) leave it as currently specified. In all cases, we are just discussing protecting the field, as put on the wire, nothing more. The requirement about not making assumptions about the intent of an update, derives from a similar logic. That is BGPSEC does not assure that a router intended to send an announcement to a peer (I.e., that the announce is actually consistent with local policy), it only allows us to verify that the router *did* send the update. Thus if the definition of "intent" is that it is consistent with local policy etc, neither the basic BGPSEC AS_PATH protection mechanisms, nor the proposed enhancements for prepending give any assurances of intent. Actually, to turn the question around a bit ... What would it mean to protect/verify intent. If we stick with a mechanistic view of this, we can either: 1. Provide ways to detect that a prepend list was manipulated after original transmission (AS's added or subtracted). 2. Or Not, making is possible to have downstream AS's manipulate the length of a prepend list without BGPSEC detecting it. I would think the discussion should be on the use/business case for allowing/disallowing downstream modification. WRT use in path_length computations ... So far the -00 spec and the proposed enhancements from the SIDR meeting have taken the view that is best to leave the semantics and encoding of the existing AS_PATH attribute unmodified. There were some opinions expressed that a lot of existing mechanisms/configuration is based upon the AS_PATH attribute as it currently exists. Thus BGPSEC's PATH_SIG attribute does not replicate or change the AS_PATH attribute, it just provides the data that allows a receiver to validate the AS_PATH. So as it stands, there is no BGPSEC_AS_PATH ... Now I guess one could count the number of unique SIGs to come up with an AS_PATH_Length that ignores prepends, but that is already trivial to do with the existing AS_PATH attribute. In fact some commercial implementations provide such a feature. So I don't think optimizing the number of SIGs will give away anything that you couldn't already easily figure out ... Dougm On 8/1/11 11:42 AM, "t.petch" wrote: >----- Original Message ----- >From: "Shane Amante" >To: "Montgomery, Douglas" >Cc: >Sent: Thursday, July 28, 2011 11:18 PM >> >> On Jul 28, 2011, at 1:43 PM, Montgomery, Douglas wrote: >> >> > The discussion so far has not been protecting/validating if prepending >*should have* occurred. BGPSEC protects the AS_PATH. Prepending >occurs in >the AS_PATH. Today's strawman presented one approach to protect the fact >that >prepending *did* occur (without comment as if it should have occurred). >> >> Right. But, if BGPSEC is not "commenting" whether AS_PATH prepending >>should, >or should not, have occurred, then wouldn't it be more straightforward to >avoid >representing AS_PATH prepending in BGPSEC's AS_PATH Attr? IOW, isn't the >intent >of the BGPSEC AS_PATH signature to "simply" represent the ASN's over >which the >BGP UPDATE has travelled? Why does AS_PATH prepending *need* >representation in >the BGPSEC AS_PATH Attr, (or, what does it help with wrt BGPSEC)? >> >> The SIDR WG instigated the deprecation of AS_SET's for reasons of >simplification. If WG really believes in simplification, then why does >that not >apply here wrt AS_PATH prepending? > >I do not think that it was simplification that led to the deprecation of >AS-SET, >rather the difficulty or impossibility of securing it to the same extent >as a >single >AS; which led to the discovery that AS_SET were rare and that their loss >would not affect almost all of the Internet. > >Question is; how common is prepending? I thought that it was widespread >and >'normal' but there would have to be hard data first, before deprecation >could >be contemplated. > >Tom Petch > >> > With that interpretation, I don't think today's proposal violates the >requirement about presuming intent. >> > >> > This too is good discussion as to what the requirement is. >> > >> > If we want to protect the common encoding of prepending in the AS_PATH >today's strawman provides a simple approach. >> > >> > I don't know if your example is primarily pointing out another >>situation >where prepending occurs on ingress .... or if we you are proposing that we >discuss protecting the intent to prepend. >> > >> > If it is the latter - that is a significant expansion of requirements >>- and >there are no obvious simple enhancements of bgpsec-00 mechanisms that >would get >us there. >> >> So, I grudgingly agree with the requirement, as written, that a BGPSEC >>AS_PATH >signature should not describe/express intent. (I'd feel better if the >requirement were changed to say "does not" describe/express intent, but >I'm not >sure there is consensus to do so ...). >> >> Ultimately, my concern is the more "faithfully" the AS_PATH appears to >>be >represented in the BGPSEC AS_PATH Attr (i.e.: it does include AS_PATH >prepending), then: >> a) The more potential confusion there might be with operators who >>aren't well >versed in SIDR incorrectly /assuming/ that it does describe intent[1]; >and/or, >> b) The more potential/temptation there may be for vendors to use the >>BGPSEC >AS_PATH Attr in BGP path selection (i.e.: as the AS_PATH length >tie-breaker) in >place of the legacy AS_PATH Attribute. This has implications wrt control >plane >scaling w/out any appreciable benefit. >> >> -shane >> >> [1] Yeah, yeah, they should RTFM ... >> >> >> > >> > dougm >> > >> > >> > >> > >> > Doug Montgomery - Manager Internet and Scalable Systems Research >>Group / >Information Technology Laboratory / NIST >> > ________________________________________ >> > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] On Behalf Of Shane >Amante [shane@castlepoint.net] >> > Sent: Thursday, July 28, 2011 3:00 PM >> > To: sidr@ietf.org >> > Subject: [sidr] pCNT & (AS_PATH) prepending: Is it in scope? >> > >> > Hi, >> > >> > I have a question for the WG. In a series of e-mail exchanges >>earlier this >year, I had thought it was concluded that BGPSEC was merely being used as >a >means to express that a BGP UPDATE had passed through a series of ASN's, >i.e.: >it's an expression of a "breadcrumbs", if you will, that can [later] be >validated by receiver that are further downstream. IOW, it's not a >validation >of the TE policies (e.g.: AS_PATH prepending) applied by ASN's. >> > >> > I went back to the BGPSEC requirements: >> > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-reqs-00 >> > ... and, if I look at Req #3.19: >> > 3.19 A BGPsec design SHOULD NOT presume to know the intent of the >> > originator of a NLRI, nor that of any AS on the AS Path. >> > >> > What was the intended meaning of the word "intent"? I thought that >>word was >meant to say that BGPsec was not intended to validate TE policies that >may, or >may not, be applied to the NLRI. If that is correct, then why is the WG >looking >at signing an BGP attribute that expresses the the number of times an ASN >may be >prepended? Or, has the WG had a change of direction and I haven't kept >up to >speed? >> > >> > I would note that the reason I'm asking the above is that it may not >>be the >originator that is performing AS_PATH prepending. Specifically, a >customer may >use a provider's BGP TE communities to ask the provider to perform AS_PATH >prepending (selectively) on their behalf. But, since these BGP TE >communities >are not signed, then how would a receiver of the NLRI know that an AS_PATH >should or should not have been prepended by an intermediate/transit ASN? >> > >> > Thanks, >> > >> > -shane >> > _______________________________________________ >> > sidr mailing list >> > sidr@ietf.org >> > https://www.ietf.org/mailman/listinfo/sidr >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From dougm@nist.gov Mon Aug 1 12:01: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 AB4C621F8D19 for ; Mon, 1 Aug 2011 12:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 L77VkscjoUJW for ; Mon, 1 Aug 2011 12:01:48 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id A2CE421F8D17 for ; Mon, 1 Aug 2011 12:01:47 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.323.0; Mon, 1 Aug 2011 15:01:53 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 1 Aug 2011 15:01:51 -0400 From: "Montgomery, Douglas" To: Randy Bush , t.petch Date: Mon, 1 Aug 2011 15:01:49 -0400 Thread-Topic: [sidr] pCNT & (AS_PATH) prepending: Is it in scope? Thread-Index: AcxQfWVxKOd0kXBwSeC6p2H3t8ro4Q== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] pCNT & (AS_PATH) prepending: Is it in scope? 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, 01 Aug 2011 19:01:48 -0000 On 8/1/11 1:17 PM, "Randy Bush" wrote: > > >> Question is; how common is prepending? I thought that it was >> widespread and 'normal' but there would have to be hard data first, >> before deprecation could be contemplated. > >we could measure. but given that we can see that it is quite common, >and we have reasonable ways to deal with it, why should we spend the >time? what might we learn? Randy's answer was better. Given that it is easy to do, what is the down side to enabling one to tell if someone else added/subtracted from your prepend list? Maybe to help that discussion, I will note by "tell" above, what the current proposal suggests is that such adding/trimming would cause BGPSEC path validation to FAIL. Dougm From jakob.heitz@ericsson.com Mon Aug 1 12:16:27 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 38C5721F8D84 for ; Mon, 1 Aug 2011 12:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.541 X-Spam-Level: X-Spam-Status: No, score=-5.541 tagged_above=-999 required=5 tests=[AWL=0.458, 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 2v7w+6xadGmF for ; Mon, 1 Aug 2011 12:16:26 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 35A1921F8D9A for ; Mon, 1 Aug 2011 12:16:26 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p71JGFTV031572; Mon, 1 Aug 2011 14:16:31 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.59]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 1 Aug 2011 15:16:20 -0400 From: Jakob Heitz To: "Montgomery, Douglas" , Randy Bush , "t.petch" Date: Mon, 1 Aug 2011 15:16:18 -0400 Thread-Topic: [sidr] pCNT & (AS_PATH) prepending: Is it in scope? Thread-Index: AcxQfWVxKOd0kXBwSeC6p2H3t8ro4QAAKShA Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E5DA24E7A@EUSAACMS0701.eamcs.ericsson.se> 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] pCNT & (AS_PATH) prepending: Is it in scope? 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, 01 Aug 2011 19:16:27 -0000 It is easy enough to tell, but should we? It is also easy to protect other bgp attributes that affect path selection. However, the real question is: Do we want to invalidate an update if someone changes such an attribute? Remember, if we send a route to an AS, even if it is less preferred than another route, then that route will be used if the preferred route becomes infeasible. Therefore, there is not as much value in protecting attributes as there is in protecting the path. I thought there was a statement some time ago that we only protect the path, not the attributes. A prepend is not a change in path. It is more like an attribute. -- Jakob Heitz. =20 > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On=20 > Behalf Of Montgomery, Douglas > Sent: Monday, August 01, 2011 12:02 PM > To: Randy Bush; t.petch > Cc: sidr@ietf.org > Subject: Re: [sidr] pCNT & (AS_PATH) prepending: Is it in scope? >=20 >=20 >=20 > On 8/1/11 1:17 PM, "Randy Bush" wrote: >=20 > > > > > >> Question is; how common is prepending? I thought that it was > >> widespread and 'normal' but there would have to be hard data first, > >> before deprecation could be contemplated. > > > >we could measure. but given that we can see that it is quite common, > >and we have reasonable ways to deal with it, why should we spend the > >time? what might we learn? >=20 >=20 > Randy's answer was better. Given that it is easy to do, what=20 > is the down > side to enabling one to tell if someone else added/subtracted=20 > from your > prepend list? >=20 > Maybe to help that discussion, I will note by "tell" above, what the > current proposal suggests is that such adding/trimming would=20 > cause BGPSEC > path validation to FAIL. >=20 > Dougm >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > = From kent@bbn.com Mon Aug 1 14:19: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 0CCFB21F8CE1 for ; Mon, 1 Aug 2011 14:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.572 X-Spam-Level: X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 eHyiiZIdvfli for ; Mon, 1 Aug 2011 14:19:00 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7E55E21F8C90 for ; Mon, 1 Aug 2011 14:19:00 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:58073 helo=[10.84.131.231]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QnztA-000NrE-HW; Mon, 01 Aug 2011 17:19:04 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E5DA24E7A@EUSAACMS0701.eamcs.ericsson.se > References: <7309FCBCAE981B43ABBE69B31C8D21390E5DA24E7A@EUSAACMS0701.eamcs.ericsson.se > Date: Mon, 1 Aug 2011 17:18:51 -0400 To: Jakob Heitz From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org" Subject: Re: [sidr] pCNT & (AS_PATH) prepending: Is it in scope? 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, 01 Aug 2011 21:19:01 -0000 At 3:16 PM -0400 8/1/11, Jakob Heitz wrote: >It is easy enough to tell, but should we? >It is also easy to protect other bgp attributes that affect path selection. maybe, or maybe not. The AS path info can be protected using the RPKI, because each ISP gets a cert that enumerates all AS#'s associated with that ISP. So, when a router signs an AS path entry, the authorization of the router to represent can be verified using the RPKI data. Other attributes may not correspond to data that we can verify, based on the RPKI. >However, the real question is: >Do we want to invalidate an update if someone changes such an attribute? in the case of As path, sinec we know that ISPs make use of AS path to distinguish between different routes for the same prefix, it makes sense to reject (or at least penalize locally) a route if the path sig data is invalid. >Remember, if we send a route to an AS, even if it is less preferred >than another route, then that route will be used if the preferred route >becomes infeasible. More precisely, the route MAY become the preferred route if the previous preferred route becomes ... >Therefore, there is not as much value in >protecting attributes as there is in protecting the path. I don't agree. because the AS path length if a very important attribute in pat selection, it merits protection. >I thought there was a statement some time ago that we only protect >the path, not the attributes. that have been a lot of statements on this list over time :-). >A prepend is not a change in path. It is more like an attribute. Prepedning is a way that ISP use BGP to effect traffic engineering, at a distance. A route, technically, is a set of prefixes (NLRI) plus an AS path. I believe we are trying to protect routes. Biut I agree that we ought to be more precise in the way we say this. Steve From internet-drafts@ietf.org Tue Aug 2 02:20: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 BE83E21F8EF0; Tue, 2 Aug 2011 02:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 xpxTL62N6FHq; Tue, 2 Aug 2011 02:20:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125F121F8EC3; Tue, 2 Aug 2011 02:20:22 -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.57 Message-ID: <20110802092021.13671.46784.idtracker@ietfa.amsl.com> Date: Tue, 02 Aug 2011 02:20:21 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-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: Tue, 02 Aug 2011 09:20:23 -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 : Algorithm Agility Procedure for RPKI. Author(s) : Roque Gagliano Stephen Kent Sean Turner Filename : draft-ietf-sidr-algorithm-agility-03.txt Pages : 25 Date : 2011-08-02 This document specifies the process that Certification Authorities (CAs) and Relying Parties (RP) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed in a time scale of months or years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-algorithm-agility-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-algorithm-agility-03.txt From rogaglia@cisco.com Tue Aug 2 02:32: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 70D8321F8EFA for ; Tue, 2 Aug 2011 02:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMPm1gpi3w7n for ; Tue, 2 Aug 2011 02:31:59 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id E14E521F8EF4 for ; Tue, 2 Aug 2011 02:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=12438; q=dns/txt; s=iport; t=1312277528; x=1313487128; h=from:subject:date:references:to:message-id:mime-version; bh=GDqlmNAK+CvIrQveeHu4xCw9HPqN5rSQdsX6HUViZJg=; b=Pa9gVCAzGfqMi9/kVVFo+eOomkIj5ePgifnIp/JuZ89A5bljm8Tkm8Cy vb97eBHDnzZniTSZSxYA1kIey1ClA74l3H81j2sde6DLtQKnJQ7qoedc5 AE/xJBv41Qqkoq3MoHN+M71wg6DWXbomP6sgZd4rJ2Ef/v7HWxI4KvY1m Q=; X-Files: smime.p7s : 4389 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAI7DN06Q/khL/2dsb2JhbABCp2B3gUABAQEBAgESAWQHCxwDAQIvAksCCAYTIodKoiYBnwyFY18EknuQZg X-IronPort-AV: E=Sophos;i="4.67,305,1309737600"; d="p7s'?scan'208,217";a="106139675" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 02 Aug 2011 09:32:06 +0000 Received: from dhcp-144-254-20-178.cisco.com (dhcp-144-254-20-178.cisco.com [144.254.20.178]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p729VwmU006135 for ; Tue, 2 Aug 2011 09:31:58 GMT From: Roque Gagliano Content-Type: multipart/signed; boundary=Apple-Mail-113--1037130997; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 2 Aug 2011 11:31:56 +0200 References: <20110802092022.13671.96567.idtracker@ietfa.amsl.com> To: sidr wg list Message-Id: <1C1A5E2A-1C8A-4023-B2BA-A2D340470649@cisco.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [sidr] Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-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: Tue, 02 Aug 2011 09:32:00 -0000 --Apple-Mail-113--1037130997 Content-Type: multipart/alternative; boundary=Apple-Mail-112--1037132038 --Apple-Mail-112--1037132038 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear WG, I uploaded a new version of the draft preparing it for WGLC. The only change is a requirement from the BGPSEC team to include a = paragraph in section 4.2 that clarifies that "mixed" certs are not = allowed only for CA certs but may be possible for EE certs that do not = validate repository objects (i.e. BGPSEC certs). Regards, Roque Begin forwarded message: > From: internet-drafts@ietf.org > Date: August 2, 2011 11:20:22 AM GMT+02:00 > To: rogaglia@cisco.com > Cc: turners@ieca.com, rogaglia@cisco.com, kent@bbn.com > Subject: New Version Notification for = draft-ietf-sidr-algorithm-agility-03.txt >=20 > A new version of I-D, draft-ietf-sidr-algorithm-agility-03.txt has = been successfully submitted by Roque Gagliano and posted to the IETF = repository. >=20 > Filename: draft-ietf-sidr-algorithm-agility > Revision: 03 > Title: Algorithm Agility Procedure for RPKI. > Creation date: 2011-08-02 > WG ID: sidr > Number of pages: 25 >=20 > Abstract: > This document specifies the process that Certification Authorities > (CAs) and Relying Parties (RP) participating in the Resource Public > Key Infrastructure (RPKI) will need to follow to transition to a new > (and probably cryptographically stronger) algorithm set. The = process > is expected to be completed in a time scale of months or years. > Consequently, no emergency transition is specified. The transition > procedure defined in this document supports only a top-down = migration > (parent migrates before children). >=20 >=20 >=20 >=20 > The IETF Secretariat --Apple-Mail-112--1037132038 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = WG,

I uploaded a new version of the draft = preparing it for WGLC.

The only change is a = requirement from the BGPSEC team to include a paragraph in section 4.2 = that clarifies that "mixed" certs are not allowed only for CA certs but = may be possible for EE certs that do not validate repository objects = (i.e. BGPSEC = certs).


Regards,
Roque


Begin forwarded message:

Date: August 2, 2011 11:20:22 AM = GMT+02:00
=
Subject: New Version = Notification for = draft-ietf-sidr-algorithm-agility-03.txt

A = new version of I-D, draft-ietf-sidr-algorithm-agility-03.txt has been = successfully submitted by Roque Gagliano and posted to the IETF = repository.

Filename: = draft-ietf-sidr-algorithm-agility
Revision: = 03
Title: = = Algorithm Agility Procedure for RPKI.
Creation date: = 2011-08-02
WG ID: sidr
Number of pages: = 25

Abstract:
  This document specifies the process = that Certification Authorities
  (CAs) and Relying Parties = (RP) participating in the Resource Public
  Key = Infrastructure (RPKI) will need to follow to transition to a new
=   (and probably cryptographically stronger) algorithm set. =  The process
  is expected to be completed in a time = scale of months or years.
  Consequently, no emergency = transition is specified.  The transition
  procedure = defined in this document supports only a top-down migration
=   (parent migrates before children).




The = IETF Secretariat

= --Apple-Mail-112--1037132038-- --Apple-Mail-113--1037130997 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXDCCBWYw ggROoAMCAQICEFyqcUyRFrhvN5s0SHw/EO4wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA1MTAwMDAwMDBaFw0x MjA1MTEyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5Sb3F1ZSBHYWdsaWFubzEhMB8GCSqGSIb3DQEJARYScm9nYWdsaWFAY2lz Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxIp28SUiJ/fiFYD/Nct8MUbG WJuPqSnhkfBYMFbbWfDDrHR8OXzK2LkWIuHY5aeAo1nalAQCO40oeTYt0cp9W++a7USNCEDQzgVN Rg0YMYL27YSQoVJnecO3u9wi0jjwhJGblWWxphaztdaMbqiChgND1PHqf7dcs4UjeUOhhKFk0/61 mTmduV721jrxj6ABIlUHAc7nXhKANtDbKdBZzEhM4dbzp6STKq65EQ3xRLVFIuapTgNVckvXtc1e Cyu4xLOLZgaD2aLq9JzBn9y/rFRMtf2euP/Nmzl7QRjAUjpPdo1n6NXWGDtNyR0lUrcJ/x1leccZ Gfj0eaqe+tpJmQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAG A1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29t L0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAsvqKrlga/tU0vyBtnBOj 4miDAZxou0/fN2wVEK7dRLzIQLYEJD35sELVhiP8v8wVHtgOeVHz9FyBEVqXmJ0RKy4kMC7gdQxj +t1MlqSTDShEaPMmiwaK6M1iJ9jpBL4JvoiirpHnQYGukkgvTUeqITWZ5ecg03nB3QHuab91Gc+n RZ1OKL4D4p5IkvzWhRlIAlxW9yGZyB8r9V6iu3+1SYEpPPUN3AYCxXeXrn8fJjkOoEodybRiGyfW pMpShpTZg2tHB7ZX162Ti3sRvwA2mktDMnBtEm1pXo15z7yieDUPmjVybMA4byV7AQcbIrjQj0eq c/biBsueC2KWoJY7TDCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEF BQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBG b3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5 MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwT j+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliW B6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGce dAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69s sQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOM Wev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0 cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtg hkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoG CCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCeg JYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4G CCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNV HREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN 7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqT OtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih /1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0D uFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRIfD8Q7jAJBgUr DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4 MDIwOTMxNThaMCMGCSqGSIb3DQEJBDEWBBQqMj6o/Yu6vD6ta49ZmRBpuimgLDCCAQMGCSsGAQQB gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBcqnFMkRa4bzebNEh8PxDuMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRI fD8Q7jANBgkqhkiG9w0BAQEFAASCAQC/reT5oWRM90arkTd39kA54WiSE9DqIzeIxn3Cx5WWwq8c ebXGjpZSUwnuPZJ2VhMWqMEO2CEedzN9bPn9yioGViuJAwbzarrvK1MYqDdu3qhZ662HKJatBeqN AGvAkuaz+0eRA8MtcOtdqA9ttVib6Lo7OJOYazh9i9WTEVKAHFgD741I7eR60Ww2oSBtygJaof1q Tdw1b18b0mWfOG4Qtcz10EdCGbJoIa/VStMXXUf6D9loDPfGnUp27PWBabVYP1/GjdbSEst43xru lZk67q4UiaIwl0aeRR4jEpsDV/pKTd/pWwHEfsu1usoVIiYtms9swkgPpSfyGLz2lFnmAAAAAAAA --Apple-Mail-113--1037130997-- From paul.hoffman@vpnc.org Tue Aug 2 10:34: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 5F28511E8080 for ; Tue, 2 Aug 2011 10:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.617 X-Spam-Level: X-Spam-Status: No, score=-102.617 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 jQVfdhB6Hc+0 for ; Tue, 2 Aug 2011 10:34:01 -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 B563711E807F for ; Tue, 2 Aug 2011 10:34:00 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p72HXnUq019894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 2 Aug 2011 10:33:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Aug 2011 10:34:07 -0700 Message-Id: <84CE1DEB-76A8-4123-B20D-0AEB72CA694B@vpnc.org> To: sidr wg list Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [sidr] Expected protocols in rpki-rtr 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, 02 Aug 2011 17:34:01 -0000 Greetings again. Section 7 of draft-ietf-sidr-rpki-rtr-14 has a list of = supported transports. However, it does not list the one that some people = have said that they expect it to be run under sometimes, namely bare = TCP. If we all know that this is likely to be the case, we should have = it listed in the document. I propose the following for the end of = section 7, just before 7.1: Caches and routers MAY use unprotected TCP as a transport, even though this provides none of the security protections of the other protocols listed here. Unprotected TCP MUST only be used when there is other forms of trusted security in place. Of course, we can also just ignore the fact that many users want to do = this, but being honest in the document might be better than pretending = otherwise. --Paul Hoffman From touch@isi.edu Tue Aug 2 10:43:31 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 70AF511E8098 for ; Tue, 2 Aug 2011 10:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.291 X-Spam-Level: X-Spam-Status: No, score=-103.291 tagged_above=-999 required=5 tests=[AWL=-0.692, 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 zPNM9PK-PXOK for ; Tue, 2 Aug 2011 10:43:31 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA2A11E808C for ; Tue, 2 Aug 2011 10:43:23 -0700 (PDT) Received: from [128.9.184.177] ([128.9.184.177]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p72HgqVe007897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Aug 2011 10:42:53 -0700 (PDT) Message-ID: <4E38371C.9080000@isi.edu> Date: Tue, 02 Aug 2011 10:42:52 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Paul Hoffman References: <84CE1DEB-76A8-4123-B20D-0AEB72CA694B@vpnc.org> In-Reply-To: <84CE1DEB-76A8-4123-B20D-0AEB72CA694B@vpnc.org> 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 wg list Subject: Re: [sidr] Expected protocols in rpki-rtr 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, 02 Aug 2011 17:43:31 -0000 On 8/2/2011 10:34 AM, Paul Hoffman wrote: > Greetings again. Section 7 of draft-ietf-sidr-rpki-rtr-14 has a list of supported transports. However, it does not list the one that some people have said that they expect it to be run under sometimes, namely bare TCP. If we all know that this is likely to be the case, we should have it listed in the document. I propose the following for the end of section 7, just before 7.1: > > Caches and routers MAY use unprotected TCP as a transport, > even though this provides none of the security protections of > the other protocols listed here. Unprotected TCP MUST only be > used when there is other forms of trusted security in place. Hi, all, IMO, this last line should read: other forms of trusted security at or below TCP I.e., TLS is not a viable solution to "untrusted TCP" - it may address trust at other layers, but not at the transport. Joe From dougm@nist.gov Tue Aug 2 10:47: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 A28A221F84EB for ; Tue, 2 Aug 2011 10:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.262, 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 0sSk9AG88Fl0 for ; Tue, 2 Aug 2011 10:47:35 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id E716D11E80C2 for ; Tue, 2 Aug 2011 10:47:30 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.323.0; Tue, 2 Aug 2011 13:47:38 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 2 Aug 2011 13:47:05 -0400 From: "Montgomery, Douglas" To: Paul Hoffman , sidr wg list Date: Tue, 2 Aug 2011 13:47:36 -0400 Thread-Topic: [sidr] Expected protocols in rpki-rtr Thread-Index: AcxRPDDVTPjx4NSDRw25pWD/07oaqA== Message-ID: In-Reply-To: <84CE1DEB-76A8-4123-B20D-0AEB72CA694B@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] Expected protocols in rpki-rtr 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, 02 Aug 2011 17:47:38 -0000 As a practical matter, what do you think the effect of the "MUST" in the last sentence will be? --=20 Doug Montgomery =AD Mgr. Internet & Scalable Systems Research / ITL / NIST On 8/2/11 1:34 PM, "Paul Hoffman" wrote: >Greetings again. Section 7 of draft-ietf-sidr-rpki-rtr-14 has a list of >supported transports. However, it does not list the one that some people >have said that they expect it to be run under sometimes, namely bare TCP. >If we all know that this is likely to be the case, we should have it >listed in the document. I propose the following for the end of section 7, >just before 7.1: > > Caches and routers MAY use unprotected TCP as a transport, > even though this provides none of the security protections of > the other protocols listed here. Unprotected TCP MUST only be > used when there is other forms of trusted security in place. > >Of course, we can also just ignore the fact that many users want to do >this, but being honest in the document might be better than pretending >otherwise. > >--Paul Hoffman > >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From paul.hoffman@vpnc.org Tue Aug 2 11:17: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 5D82521F8661 for ; Tue, 2 Aug 2011 11:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.617 X-Spam-Level: X-Spam-Status: No, score=-102.617 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 bl8CHaAvlMH4 for ; Tue, 2 Aug 2011 11:17:02 -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 AC36D21F8640 for ; Tue, 2 Aug 2011 11:17:01 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p72IGiGw021975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 2 Aug 2011 11:16:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1244.3) From: Paul Hoffman In-Reply-To: Date: Tue, 2 Aug 2011 11:17:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3E45FD30-EB93-4AF5-A8FC-5D5122E82923@vpnc.org> References: To: sidr wg list X-Mailer: Apple Mail (2.1244.3) Subject: Re: [sidr] Expected protocols in rpki-rtr 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, 02 Aug 2011 18:17:02 -0000 On Aug 2, 2011, at 10:47 AM, Montgomery, Douglas wrote: > As a practical matter, what do you think the effect of the "MUST" in = the > last sentence will be? That vendors cannot provide bare TCP as a transport in a system that = contains no other security mechanisms.=20 On Aug 2, 2011, at 10:42 AM, Joe Touch wrote: > IMO, this last line should read: >=20 > other forms of trusted security at or below TCP That seems like a good addition. --Paul Hoffman From randy@psg.com Tue Aug 2 11:37:31 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 86A8A21F856A for ; Tue, 2 Aug 2011 11:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 uFfJFcPZ8ICi for ; Tue, 2 Aug 2011 11:37:31 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id DC67921F8564 for ; Tue, 2 Aug 2011 11:37:30 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QoJqU-000AEl-TJ; Tue, 02 Aug 2011 18:37:39 +0000 Date: Wed, 03 Aug 2011 03:37:37 +0900 Message-ID: From: Randy Bush To: Paul Hoffman In-Reply-To: <84CE1DEB-76A8-4123-B20D-0AEB72CA694B@vpnc.org> References: <84CE1DEB-76A8-4123-B20D-0AEB72CA694B@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 wg list Subject: Re: [sidr] Expected protocols in rpki-rtr 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, 02 Aug 2011 18:37:31 -0000 > Greetings again. Section 7 of draft-ietf-sidr-rpki-rtr-14 has a list > of supported transports. However, it does not list the one that some > people have said that they expect it to be run under sometimes, namely > bare TCP. huh? i see the following: Caches and routers MUST implement unprotected transport over TCP using a port, RPKI-Rtr, to be assigned, see Section 12. Operators SHOULD use procedural means, ACLs, ... to reduce the exposure to authentication issues. > I propose the following for the end of section 7, just before 7.1: > > Caches and routers MAY use unprotected TCP as a transport, > even though this provides none of the security protections of > the other protocols listed here. Unprotected TCP MUST only be > used when there is other forms of trusted security in place. we actually can't. to rehash (null algroithm) the discussion o AO, which may come for some routers late this year or the first half of next year, does not exist for servers. as the market for AO in servers is miniscule, i am not optimistic. side note: for example a number of very large operators use only solaris. o MD5, does not exist for many server platforms, or is half-assed. o SSH, fine on servers, but many router platforms do not have SSH APIs. they just have client code burned into the CLI. o TLS, fine on servers, but many router platforms do not have SSH APIs. they just have client code burned in. > being honest in the document might be better than pretending > otherwise. exactly! randy From paul.hoffman@vpnc.org Tue Aug 2 12:00: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 A33CB11E808C for ; Tue, 2 Aug 2011 12:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.617 X-Spam-Level: X-Spam-Status: No, score=-102.617 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 rE-bpRpJLJoc for ; Tue, 2 Aug 2011 12:00:06 -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 4A4BD11E80BD for ; Tue, 2 Aug 2011 12:00:06 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p72IxuPB024110 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Aug 2011 11:59:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Tue, 2 Aug 2011 12:00:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3D922BE8-1F42-478A-8EC7-85186350801B@vpnc.org> References: <84CE1DEB-76A8-4123-B20D-0AEB72CA694B@vpnc.org> To: Randy Bush X-Mailer: Apple Mail (2.1244.3) Cc: sidr wg list Subject: Re: [sidr] Expected protocols in rpki-rtr 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, 02 Aug 2011 19:00:08 -0000 On Aug 2, 2011, at 11:37 AM, Randy Bush wrote: >> Greetings again. Section 7 of draft-ietf-sidr-rpki-rtr-14 has a list >> of supported transports. However, it does not list the one that some >> people have said that they expect it to be run under sometimes, = namely >> bare TCP. >=20 > huh? i see the following: >=20 > Caches and routers MUST implement unprotected transport over TCP > using a port, RPKI-Rtr, to be assigned, see Section 12. Operators > SHOULD use procedural means, ACLs, ... to reduce the exposure to > authentication issues. Arrgh. My bad. (I read the intro, I read TCP-AO, and I skipped to the = end of the list.) Never mind, what I want is already there. --Paul Hoffman From randy@psg.com Tue Aug 2 12:05: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 4A2AB1F0C43 for ; Tue, 2 Aug 2011 12:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 fwDYkFlfij2m for ; Tue, 2 Aug 2011 12:05:28 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id CB3CF1F0C39 for ; Tue, 2 Aug 2011 12:05:27 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QoKHY-000AJL-Hj; Tue, 02 Aug 2011 19:05:36 +0000 Date: Wed, 03 Aug 2011 04:05:35 +0900 Message-ID: From: Randy Bush To: Paul Hoffman In-Reply-To: <3D922BE8-1F42-478A-8EC7-85186350801B@vpnc.org> References: <84CE1DEB-76A8-4123-B20D-0AEB72CA694B@vpnc.org> <3D922BE8-1F42-478A-8EC7-85186350801B@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 wg list Subject: Re: [sidr] Expected protocols in rpki-rtr 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, 02 Aug 2011 19:05:28 -0000 >> huh? i see the following: > Arrgh. My bad. (I read the intro, I read TCP-AO, and I skipped to the > end of the list.) it is a carefully constructed yet painful compromise with reality. > Never mind, what I want is already there. do i get a refund? :) randy From Sandra.Murphy@cobham.com Tue Aug 2 15:16:33 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 D1F8021F8565 for ; Tue, 2 Aug 2011 15:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.06 X-Spam-Level: X-Spam-Status: No, score=-102.06 tagged_above=-999 required=5 tests=[AWL=0.539, 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 Ge0KhrRpslJL for ; Tue, 2 Aug 2011 15:16:33 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2D06721F8563 for ; Tue, 2 Aug 2011 15:16:32 -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 p72MGf9T026770; Tue, 2 Aug 2011 17:16:41 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p72MGfmo030671; Tue, 2 Aug 2011 17:16:41 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.128]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Aug 2011 18:16:40 -0400 Date: Tue, 2 Aug 2011 18:16:39 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Roque Gagliano In-Reply-To: <1C1A5E2A-1C8A-4023-B2BA-A2D340470649@cisco.com> Message-ID: References: <20110802092022.13671.96567.idtracker@ietfa.amsl.com> <1C1A5E2A-1C8A-4023-B2BA-A2D340470649@cisco.com> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 02 Aug 2011 22:16:40.0580 (UTC) FILETIME=[DA76D440:01CC5161] Cc: sidr wg list Subject: Re: [sidr] Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-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: Tue, 02 Aug 2011 22:16:33 -0000 Speaking only as a regular ol' wg member: The draft does not say why the mixed certificate prohibition was needed in the first place. The new text says: This exception to the mixed algorithm suite certificate rule is allowed because an EE certificate that is not used to verify repository objects does not interfere with the ability of RPs to download and verify repository content. There's a hint there that mixed certificates for CAs signing CA certs might cause a problem for RPs. I think it would be good to describe the problems RPs would see if CAs could sign CA certs with a mix of algorithms. And it might be good to say why the mixed certificate case for some EE certs was desirable. YMMV. Also, the draft says: In the RPKI, a CA MUST NOT sign a CA certificate carrying a subject key that corresponds to an algorithm suite that differs from the one used to sign the certificate. It used to say that In RPKI an algorithm suite MUST NOT sign a certificate carrying a subject key that corresponds to another algorithm suite. To me, the old text sounded like issuance of any mixed certificate was prohibited. The new prohibition applies only to CAs issuing a CA cert and the new exception applies only to EE certs that are not used to verify repository objects. The new text sounds to me like it leaves open the case of EE certs that *are* used to verify repository objects. --Sandy, regular ol' wg member On Tue, 2 Aug 2011, Roque Gagliano wrote: > Dear WG, > > I uploaded a new version of the draft preparing it for WGLC. > > The only change is a requirement from the BGPSEC team to include a paragraph in section 4.2 that clarifies that "mixed" certs are not allowed only for CA certs but may be possible for EE certs that do not validate repository objects (i.e. BGPSEC certs). > > > Regards, > Roque > > > Begin forwarded message: > >> From: internet-drafts@ietf.org >> Date: August 2, 2011 11:20:22 AM GMT+02:00 >> To: rogaglia@cisco.com >> Cc: turners@ieca.com, rogaglia@cisco.com, kent@bbn.com >> Subject: New Version Notification for draft-ietf-sidr-algorithm-agility-03.txt >> >> A new version of I-D, draft-ietf-sidr-algorithm-agility-03.txt has been successfully submitted by Roque Gagliano and posted to the IETF repository. >> >> Filename: draft-ietf-sidr-algorithm-agility >> Revision: 03 >> Title: Algorithm Agility Procedure for RPKI. >> Creation date: 2011-08-02 >> WG ID: sidr >> Number of pages: 25 >> >> Abstract: >> This document specifies the process that Certification Authorities >> (CAs) and Relying Parties (RP) participating in the Resource Public >> Key Infrastructure (RPKI) will need to follow to transition to a new >> (and probably cryptographically stronger) algorithm set. The process >> is expected to be completed in a time scale of months or years. >> Consequently, no emergency transition is specified. The transition >> procedure defined in this document supports only a top-down migration >> (parent migrates before children). >> >> >> >> >> The IETF Secretariat > > From internet-drafts@ietf.org Tue Aug 2 22:41: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 EC8E311E809C; Tue, 2 Aug 2011 22:41:50 -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 CuwqXQ0hDDCJ; Tue, 2 Aug 2011 22:41:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE8011E8093; Tue, 2 Aug 2011 22:41:50 -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.57 Message-ID: <20110803054150.15229.72459.idtracker@ietfa.amsl.com> Date: Tue, 02 Aug 2011 22:41:50 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-origin-validation-signaling-01.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, 03 Aug 2011 05:41:51 -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 : BGP Prefix Origin Validation State Extended Community Author(s) : Pradosh Mohapatra Keyur Patel John Scudder David Ward Randy Bush Filename : draft-ietf-sidr-origin-validation-signaling-01.txt Pages : 7 Date : 2011-08-02 As part of the origination AS validation process, it can be desirable to automatically consider the validation state of routes in the BGP decision process. The purpose of this document is to provide a specification for doing so. The document also defines a new BGP opaque extended community to carry the validation state inside an autonomous system to influence the decision process of the IBGP speakers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-origin-validation-signa= ling-01.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-validation-signal= ing-01.txt From pmohapat@cisco.com Tue Aug 2 23:53: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 23B895E8009 for ; Tue, 2 Aug 2011 23:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 ALrv+DvnCUCC for ; Tue, 2 Aug 2011 23:53:24 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B0F1C5E8001 for ; Tue, 2 Aug 2011 23:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pmohapat@cisco.com; l=1786; q=dns/txt; s=iport; t=1312354408; x=1313564008; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=gnWeekvfGLEu49uhOfA/xLqYyExE68OSbhjWHyZzM3A=; b=dcZggYoJhgO8g5Ab/YZftOp/jezmAZcTV4lvd4lO0A3DyU9sahG4zy5N hFb3WbVFh4lEqEf0KEP2xflyLO6Q3FqsQt6cIOKL7rTlvo2b58PJWKeTe crECIbGO91cdjKj95uDRR7yTLKoxXHJ3ysFkpXfjjE7fE+kJnTYw28HAn 0=; X-IronPort-AV: E=Sophos;i="4.67,309,1309737600"; d="scan'208";a="9105691" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-1.cisco.com with ESMTP; 03 Aug 2011 06:53:26 +0000 Received: from sjc-vpn7-1017.cisco.com (sjc-vpn7-1017.cisco.com [10.21.147.249]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p736rQjx000695; Wed, 3 Aug 2011 06:53:26 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Pradosh Mohapatra In-Reply-To: Date: Tue, 2 Aug 2011 23:58:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110711215154.14120.98609.idtracker@ietfa.amsl.com> <39DD9BDD-C1A8-43B3-9A69-CA8DB1E3E685@cisco.com> To: Roque Gagliano X-Mailer: Apple Mail (2.1084) Cc: "sidr@ietf.org wg" Subject: Re: [sidr] Fwd: I-D Action: draft-ietf-sidr-pfx-validate-02.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, 03 Aug 2011 06:53:25 -0000 Hi Roque, Thanks for the review and comments. > General Comment: > " Depending on the lookup result, we define a property for each = route, > called the "validity state". It can assume the values "valid", = "not > found", or "invalid"." >=20 > You may want to consider calling it "Origin AS validity state" to = distinguish it from the validity state in BGPSEC ("valid" and = "invalid"). Ack. > Section 1: > p2: s/verifyable/verifiable Ack. > Section 2: > "An AS can originate more than one > prefix set. Thus, multiple prefix sets in the database can contain > the same origin AS(es)." >=20 > I believe you also need to mention that in the table there may be = "multi-origin prefixes". Geoff report identifies 2400 but you may find = more in local/regional environments = (http://bgp.potaroo.net/as6447/report.txt). I looked at the document again and I see many places where we say there = can be multiple origin ASes for the prefix. E.g.: we define terms "UPDATE prefix" and "UPDATE origin AS number" to denote the values derived from the received UPDATE = message, and "database prefix set" and "database origin AS number set" to mean the = values derived from the database lookup. where it's defined as "database origin AS number set" instead of just an = AS number. >=20 > Section 5: > p5:=20 > I believe you should reference = draft-ietf-sidr-origin-validation-signaling-00 Ack > Security Consideration: > I think you need to consider what you already mentioned in section 4, = if the connectivity to the local-caches is lost, invalid routes will be = classified as "not-found", which could have a different set of local = policies. Is this different from current behavior? - Pradosh= From rogaglia@cisco.com Wed Aug 3 02:51: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 D3B8021F8B14 for ; Wed, 3 Aug 2011 02:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 bK8gDzost6ut for ; Wed, 3 Aug 2011 02:51:00 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4E39421F8B13 for ; Wed, 3 Aug 2011 02:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=11972; q=dns/txt; s=iport; t=1312365071; x=1313574671; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=pb5L6qsP6CL3mJ5/RIZOaIsZmS3TQPKAxE0/6TYLz54=; b=SGWEpSq++OUco7z9RXH8aOJ+VSsTi5wAdPhkUrjmuzQfbERDqj9U/+Tb jqlLscAJ4RX1gez9dJbgd/eXlDeN5q5PjmXKeqHA5C/kIsQ90bkzZsFZT SeNN5NhSpsNcjWcp/m0mfLSNDHilNR0MNlam4odG4AkZP7IIu+y+yWngk E=; X-Files: smime.p7s : 4389 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOgZOU6Q/khL/2dsb2JhbABCp1t3gUABAQEBAQEBEgFkAgULCxEDAQIBLgJNCAYTCRmHSgSgWQGeXoVjXwSSe5Bm X-IronPort-AV: E=Sophos;i="4.67,309,1309737600"; d="p7s'?scan'208";a="106443105" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 03 Aug 2011 09:51:06 +0000 Received: from dhcp-144-254-20-178.cisco.com (dhcp-144-254-20-178.cisco.com [144.254.20.178]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p739p6so003345; Wed, 3 Aug 2011 09:51:06 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-38--949582785; protocol="application/pkcs7-signature"; micalg=sha1 From: Roque Gagliano In-Reply-To: Date: Wed, 3 Aug 2011 11:51:05 +0200 Message-Id: References: <20110802092022.13671.96567.idtracker@ietfa.amsl.com> <1C1A5E2A-1C8A-4023-B2BA-A2D340470649@cisco.com> To: Sandra Murphy X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-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, 03 Aug 2011 09:51:00 -0000 --Apple-Mail-38--949582785 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Sandra, Thanks for the comment. Please see inline. Roque On Aug 3, 2011, at 12:16 AM, Sandra Murphy wrote: > Speaking only as a regular ol' wg member: >=20 > The draft does not say why the mixed certificate prohibition was = needed in the first place. (Roque) The "prohibition" is implicit in the fact that we are taking a = TOP-DOWN migration (parent migrates before children). In practice this = only affects CA certs. It detailed in section 4.2 paragraph 2: In order to facilitate the transition, CAs will start issuing certificates using the Algorithm B in a hierarchical top-down order. In our example, CA Y will issue certificates using the Algorithm B suite only after CA X has started to do so (CA Y Ready Algorithm B Date > CA X Ready Algorithm B Date). This ordered transition avoids issuance of "mixed" suite certificates, e.g., a CA certificate signed using Suite A, containing a key from Suite B > The new text says: >=20 > This exception to the mixed algorithm suite certificate > rule is allowed because an EE certificate that is not used to verify > repository objects does not interfere with the ability of RPs to > download and verify repository content. >=20 > There's a hint there that mixed certificates for CAs signing CA certs = might cause a problem for RPs. >=20 > I think it would be good to describe the problems RPs would see if CAs = could sign CA certs with a mix of algorithms. (Roque) The problem with CA certs signing mix of algorithms is the = exponential growth of the Repository. We explored and discarded this = option in the WG. Best analysis are IETF 79 slides: = http://www.ietf.org/proceedings/79/slides/sidr-4.pdf > And it might be good to say why the mixed certificate case for some EE = certs was desirable. (Roque) I do not think we should say that it is "desirable" but that it = is NOT "prohibited". In any case, the consequence for a RP that does not = support the new "mixed" EE certs is that those certs will fail = validation. > YMMV. >=20 > Also, the draft says: >=20 > In the RPKI, a CA MUST > NOT sign a CA certificate carrying a subject key that corresponds to > an algorithm suite that differs from the one used to sign the > certificate. >=20 > It used to say that >=20 > In RPKI an algorithm > suite MUST NOT sign a certificate carrying a subject key that > corresponds to another algorithm suite. >=20 > To me, the old text sounded like issuance of any mixed certificate was = prohibited. >=20 > The new prohibition applies only to CAs issuing a CA cert and the new > exception applies only to EE certs that are not used to verify = repository objects. The new text sounds to me like it leaves open the = case of EE certs that *are* used to verify repository objects. >=20 (Roque) Agreed, what about this new text? This ordered transition avoids issuance of "mixed" suite certificates, e.g., a CA certificate signed using Suite A, containing a key from Suite B. In the RPKI, a CA MUST NOT sign a CA certificate carrying a subject key that corresponds to an algorithm suite that differs from the one used to sign the certificate. Also, a CA MUST NOT sign an EE certificate with a=20 subject public key from a different algorithm suite, if that = certificate=20 is used to verify repository objects. The algorithm agility model described here does not prohibit a CA issuing an EE certificate with a subject public key from a different algorithm suite, if that certificate is not used to verify repository objects. Regards, Roque >=20 > --Sandy, regular ol' wg member >=20 >=20 > On Tue, 2 Aug 2011, Roque Gagliano wrote: >=20 >> Dear WG, >>=20 >> I uploaded a new version of the draft preparing it for WGLC. >>=20 >> The only change is a requirement from the BGPSEC team to include a = paragraph in section 4.2 that clarifies that "mixed" certs are not = allowed only for CA certs but may be possible for EE certs that do not = validate repository objects (i.e. BGPSEC certs). >>=20 >>=20 >> Regards, >> Roque >>=20 >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Date: August 2, 2011 11:20:22 AM GMT+02:00 >>> To: rogaglia@cisco.com >>> Cc: turners@ieca.com, rogaglia@cisco.com, kent@bbn.com >>> Subject: New Version Notification for = draft-ietf-sidr-algorithm-agility-03.txt >>>=20 >>> A new version of I-D, draft-ietf-sidr-algorithm-agility-03.txt has = been successfully submitted by Roque Gagliano and posted to the IETF = repository. >>>=20 >>> Filename: draft-ietf-sidr-algorithm-agility >>> Revision: 03 >>> Title: Algorithm Agility Procedure for RPKI. >>> Creation date: 2011-08-02 >>> WG ID: sidr >>> Number of pages: 25 >>>=20 >>> Abstract: >>> This document specifies the process that Certification Authorities >>> (CAs) and Relying Parties (RP) participating in the Resource Public >>> Key Infrastructure (RPKI) will need to follow to transition to a = new >>> (and probably cryptographically stronger) algorithm set. The = process >>> is expected to be completed in a time scale of months or years. >>> Consequently, no emergency transition is specified. The transition >>> procedure defined in this document supports only a top-down = migration >>> (parent migrates before children). >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>=20 >>=20 --Apple-Mail-38--949582785 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXDCCBWYw ggROoAMCAQICEFyqcUyRFrhvN5s0SHw/EO4wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA1MTAwMDAwMDBaFw0x MjA1MTEyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5Sb3F1ZSBHYWdsaWFubzEhMB8GCSqGSIb3DQEJARYScm9nYWdsaWFAY2lz Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxIp28SUiJ/fiFYD/Nct8MUbG WJuPqSnhkfBYMFbbWfDDrHR8OXzK2LkWIuHY5aeAo1nalAQCO40oeTYt0cp9W++a7USNCEDQzgVN Rg0YMYL27YSQoVJnecO3u9wi0jjwhJGblWWxphaztdaMbqiChgND1PHqf7dcs4UjeUOhhKFk0/61 mTmduV721jrxj6ABIlUHAc7nXhKANtDbKdBZzEhM4dbzp6STKq65EQ3xRLVFIuapTgNVckvXtc1e Cyu4xLOLZgaD2aLq9JzBn9y/rFRMtf2euP/Nmzl7QRjAUjpPdo1n6NXWGDtNyR0lUrcJ/x1leccZ Gfj0eaqe+tpJmQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAG A1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29t L0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAsvqKrlga/tU0vyBtnBOj 4miDAZxou0/fN2wVEK7dRLzIQLYEJD35sELVhiP8v8wVHtgOeVHz9FyBEVqXmJ0RKy4kMC7gdQxj +t1MlqSTDShEaPMmiwaK6M1iJ9jpBL4JvoiirpHnQYGukkgvTUeqITWZ5ecg03nB3QHuab91Gc+n RZ1OKL4D4p5IkvzWhRlIAlxW9yGZyB8r9V6iu3+1SYEpPPUN3AYCxXeXrn8fJjkOoEodybRiGyfW pMpShpTZg2tHB7ZX162Ti3sRvwA2mktDMnBtEm1pXo15z7yieDUPmjVybMA4byV7AQcbIrjQj0eq c/biBsueC2KWoJY7TDCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEF BQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBG b3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5 MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwT j+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliW B6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGce dAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69s sQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOM Wev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0 cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtg hkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoG CCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCeg JYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4G CCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNV HREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN 7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqT OtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih /1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0D uFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRIfD8Q7jAJBgUr DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4 MDMwOTUxMDZaMCMGCSqGSIb3DQEJBDEWBBTKoY790NQYpdRtXWirs0QXEDPpgjCCAQMGCSsGAQQB gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBcqnFMkRa4bzebNEh8PxDuMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRI fD8Q7jANBgkqhkiG9w0BAQEFAASCAQAOqhBimOvqE4Mq/QC7pyNAHRkxIeNh8Mj7aimFeT0+DT9t V7eFet8+z11BDn5E+nnfqDN59HjYHJ/5MWNW0OTaj3TlR/JEQQ1WDJY1O7XtaEr9U9SqgfFwjkEA g15rVpf0gi7Ot5dh5fIdwI3YKSm5nVNYWiH2Yqlk3zneXYZA1vVcudQKLvssUGYIPh8IlFKQQcJw tFwKDLw/UQwAypmtIJyqIgRzjf2BDRXxmOnlBWwihJYbUHD7r7PYQtjT0Wvwrt0qhG34DfUXJyxk mTM+pCSvTnoa17Xm8pxc4FAtuv53mIluuOIrVHEvBb/Cg86sqygbVhFB5FIOxtgiClt7AAAAAAAA --Apple-Mail-38--949582785-- From rogaglia@cisco.com Wed Aug 3 03:05: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 606CC21F8B48 for ; Wed, 3 Aug 2011 03:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 I9ybsxb1+xAN for ; Wed, 3 Aug 2011 03:05:56 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0D73821F8AFC for ; Wed, 3 Aug 2011 03:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=8346; q=dns/txt; s=iport; t=1312365967; x=1313575567; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=0UA716Xv4aW/wEPJzEAlZh7XeVNjU0tElw0Winr2OUE=; b=UO3fUAMOwVyJAVJ+9+L9+4EUZsPXqdYRQsZqVReb/CvcDFc2+7c5UuVK Q1AAuuzq6eXqWHTPI9EY70f2ndSXzYZpcErfMrQdvSDGgYfU6ecm1vOK7 fhIdTqlqg9XriBcda1kTloo4DH31HDSPJHyhOly5wZzMK/eJtstlIdUjU Y=; X-Files: smime.p7s : 4389 X-IronPort-AV: E=Sophos;i="4.67,309,1309737600"; d="p7s'?scan'208";a="106446754" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 03 Aug 2011 10:03:33 +0000 Received: from dhcp-144-254-20-178.cisco.com (dhcp-144-254-20-178.cisco.com [144.254.20.178]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p73A3WBN006903; Wed, 3 Aug 2011 10:03:32 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-41--948842138; protocol="application/pkcs7-signature"; micalg=sha1 From: Roque Gagliano In-Reply-To: Date: Wed, 3 Aug 2011 12:03:24 +0200 Message-Id: <8C46CE12-AA87-4DD2-B6A8-731D8AB72045@cisco.com> References: <20110711215154.14120.98609.idtracker@ietfa.amsl.com> <39DD9BDD-C1A8-43B3-9A69-CA8DB1E3E685@cisco.com> To: Pradosh Mohapatra X-Mailer: Apple Mail (2.1084) Cc: "sidr@ietf.org wg" Subject: Re: [sidr] Fwd: I-D Action: draft-ietf-sidr-pfx-validate-02.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, 03 Aug 2011 10:05:57 -0000 --Apple-Mail-41--948842138 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Pradosh, (skiping) >> Section 2: >> "An AS can originate more than one >> prefix set. Thus, multiple prefix sets in the database can contain >> the same origin AS(es)." >>=20 >> I believe you also need to mention that in the table there may be = "multi-origin prefixes". Geoff report identifies 2400 but you may find = more in local/regional environments = (http://bgp.potaroo.net/as6447/report.txt). >=20 > I looked at the document again and I see many places where we say = there can be multiple origin ASes for the prefix. E.g.: >=20 > we define terms "UPDATE prefix" and "UPDATE origin > AS number" to denote the values derived from the received UPDATE = message, and > "database prefix set" and "database origin AS number set" to mean the = values > derived from the database lookup. >=20 > where it's defined as "database origin AS number set" instead of just = an AS number. >=20 Ok. I got it now. >>=20 >> Section 5: >> p5:=20 >> I believe you should reference = draft-ietf-sidr-origin-validation-signaling-00 >=20 > Ack >=20 >> Security Consideration: >> I think you need to consider what you already mentioned in section 4, = if the connectivity to the local-caches is lost, invalid routes will be = classified as "not-found", which could have a different set of local = policies. >=20 > Is this different from current behavior? Not sure what do you refer for "current behavior". My point was that in = the security considerations you should point to the analysis in Section = 4 on loosing connectivity to the cache servers. Example: Router set loc-pref 100 for "valid" and loc-pref 50 for = "not-found". If the router looses connectivity with caches, either by = operational issues or by malicious event (on the cache/ the router or = the network between the two), the set of prefixes that should be "valid" = based on RPKI will be classified as "not found" and loc-pref set to 50. Roque >=20 > - Pradosh --Apple-Mail-41--948842138 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXDCCBWYw ggROoAMCAQICEFyqcUyRFrhvN5s0SHw/EO4wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA1MTAwMDAwMDBaFw0x MjA1MTEyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5Sb3F1ZSBHYWdsaWFubzEhMB8GCSqGSIb3DQEJARYScm9nYWdsaWFAY2lz Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxIp28SUiJ/fiFYD/Nct8MUbG WJuPqSnhkfBYMFbbWfDDrHR8OXzK2LkWIuHY5aeAo1nalAQCO40oeTYt0cp9W++a7USNCEDQzgVN Rg0YMYL27YSQoVJnecO3u9wi0jjwhJGblWWxphaztdaMbqiChgND1PHqf7dcs4UjeUOhhKFk0/61 mTmduV721jrxj6ABIlUHAc7nXhKANtDbKdBZzEhM4dbzp6STKq65EQ3xRLVFIuapTgNVckvXtc1e Cyu4xLOLZgaD2aLq9JzBn9y/rFRMtf2euP/Nmzl7QRjAUjpPdo1n6NXWGDtNyR0lUrcJ/x1leccZ Gfj0eaqe+tpJmQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAG A1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29t L0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAsvqKrlga/tU0vyBtnBOj 4miDAZxou0/fN2wVEK7dRLzIQLYEJD35sELVhiP8v8wVHtgOeVHz9FyBEVqXmJ0RKy4kMC7gdQxj +t1MlqSTDShEaPMmiwaK6M1iJ9jpBL4JvoiirpHnQYGukkgvTUeqITWZ5ecg03nB3QHuab91Gc+n RZ1OKL4D4p5IkvzWhRlIAlxW9yGZyB8r9V6iu3+1SYEpPPUN3AYCxXeXrn8fJjkOoEodybRiGyfW pMpShpTZg2tHB7ZX162Ti3sRvwA2mktDMnBtEm1pXo15z7yieDUPmjVybMA4byV7AQcbIrjQj0eq c/biBsueC2KWoJY7TDCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEF BQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBG b3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5 MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwT j+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliW B6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGce dAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69s sQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOM Wev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0 cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtg hkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoG CCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCeg JYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4G CCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNV HREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN 7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqT OtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih /1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0D uFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRIfD8Q7jAJBgUr DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4 MDMxMDAzMjdaMCMGCSqGSIb3DQEJBDEWBBT7KEmRSYzZhGRfl/lmeaiiRWobwjCCAQMGCSsGAQQB gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBcqnFMkRa4bzebNEh8PxDuMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRI fD8Q7jANBgkqhkiG9w0BAQEFAASCAQBI+8crAXBva56J9+xm/MFAmfpP/TMVUsER6nyOPwrS53zM 2BUlYoxJZAI6Xog4Iz5AEIpuBjcov97CUxd5T+VB6LIpNN8A661zT523ENdU4loER6UrcPNyy53L /eO6otPLmcha0giX9qNc5Cy9LtKf2aFuLKnHz+e5HquFyB1yoSjjOzisOLIM12P2e+3klg7tjiyx nVpWI5SaGoWY1QVKxIkX5MB82XJ0CjP31/suWHP914lisKnzF6AuitEjjgGyJ6W+h1v3otszXqke rf5Bx1Brcs+heN/y4UnAK3Y2zVcNBcHqaM/Sy+0EErSbSAO1994JjvRaayJX0nIIoWXdAAAAAAAA --Apple-Mail-41--948842138-- From dougm@nist.gov Wed Aug 3 10:04: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 725F421F8B6B for ; Wed, 3 Aug 2011 10:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, 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 H4mMmT+TTXBe for ; Wed, 3 Aug 2011 10:04:07 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id BB64D21F8B55 for ; Wed, 3 Aug 2011 10:04:06 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.323.0; Wed, 3 Aug 2011 13:04:17 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 3 Aug 2011 13:04:18 -0400 From: "Montgomery, Douglas" To: "sidr@ietf.org" Date: Wed, 3 Aug 2011 13:04:16 -0400 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-origin-validation-signaling-01.txt Thread-Index: AcxR/02ZygiZT5YMRmyHb0D5VjI+Dg== Message-ID: In-Reply-To: <20110803054150.15229.72459.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] I-D Action: draft-ietf-sidr-origin-validation-signaling-01.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, 03 Aug 2011 17:04:07 -0000 Should this draft address the issue (sending and receiving side) that a rtr might temporarily be unable to perform origin validation (e.g., reboot, has not synched with cache yet, ... )? I suppose absence of the community at all is a signal that the sender did not attempt validation ... Maybe the text for receiving should address the possibility that you support this draft, but receive an IBGP update that does not include this community? dougm --=20 Doug Montgomery =AD Mgr. Internet & Scalable Systems Research / ITL / NIST On 8/3/11 1:41 AM, "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 : BGP Prefix Origin Validation State Extended Community > Author(s) : Pradosh Mohapatra > Keyur Patel > John Scudder > David Ward > Randy Bush > Filename : draft-ietf-sidr-origin-validation-signaling-01.txt > Pages : 7 > Date : 2011-08-02 > > As part of the origination AS validation process, it can be desirable > to automatically consider the validation state of routes in the BGP > decision process. The purpose of this document is to provide a > specification for doing so. The document also defines a new BGP > opaque extended community to carry the validation state inside an > autonomous system to influence the decision process of the IBGP > speakers. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sidr-origin-validation-sign >aling-01.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-validation-signa >ling-01.txt >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From kent@bbn.com Wed Aug 3 11:06:16 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 5A5E621F8828 for ; Wed, 3 Aug 2011 11:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.619 X-Spam-Level: X-Spam-Status: No, score=-106.619 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 SnekSIznDqug for ; Wed, 3 Aug 2011 11:06:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8E54321F881C for ; Wed, 3 Aug 2011 11:06:15 -0700 (PDT) Received: from dhcp89-089-043.bbn.com ([128.89.89.43]:49200) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QofMN-000LVP-SI; Wed, 03 Aug 2011 13:35:59 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20110802092022.13671.96567.idtracker@ietfa.amsl.com> <1C1A5E2A-1C8A-4023-B2BA-A2D340470649@cisco.com> Date: Wed, 3 Aug 2011 13:34:54 -0400 To: Sandra Murphy From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-899729537==_ma============" Cc: sidr wg list Subject: Re: [sidr] Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-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, 03 Aug 2011 18:06:16 -0000 --============_-899729537==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 6:16 PM -0400 8/2/11, Sandra Murphy wrote: >Speaking only as a regular ol' wg member: > >The draft does not say why the mixed certificate prohibition was >needed in the first place. > >The new text says: > > This exception to the mixed algorithm suite certificate > rule is allowed because an EE certificate that is not used to verify > repository objects does not interfere with the ability of RPs to > download and verify repository content. > >There's a hint there that mixed certificates for CAs signing CA >certs might cause a problem for RPs. Goeff noted a serious problem that could arise if we allow for mixed certs at the CA level, i.e., a potential exponential directory explosion. I noted this in the briefing I made in Prague. (See slide 3, bullet 3.) >I think it would be good to describe the problems RPs would see if >CAs could sign CA certs with a mix of algorithms. > >And it might be good to say why the mixed certificate case for some >EE certs was desirable. It's not clear why one would want mixed mode EE certs, for any EE cert used to verify a repository object. It would impose a burden on all RPs (they would have to be able to deal with two suites). In contrast, mixed mode certs for EE certs that are NOT used to validate repository objects do not impose a burden on ALL RPs. Only RPs that need to process these certs to extract and use he public key would need to be capable of dealing with the alg for the Subject public key. >YMMV. > >Also, the draft says: > > In the RPKI, a CA MUST > NOT sign a CA certificate carrying a subject key that corresponds to > an algorithm suite that differs from the one used to sign the > certificate. > >It used to say that > > In RPKI an algorithm > suite MUST NOT sign a certificate carrying a subject key that > corresponds to another algorithm suite. > >To me, the old text sounded like issuance of any mixed certificate >was prohibited. yes, and it was also not good English :-). It would at least have to say "In the RPKI an algorithm suite MUST NOT be used to sign a certificate carrying a subject key that contains a key that is used with another algorithm suite. >The new prohibition applies only to CAs issuing a CA cert and the new >exception applies only to EE certs that are not used to verify >repository objects. The new text sounds to me like it leaves open >the case of EE certs that *are* used to verify repository objects. That was not the intent. The cited text at the beginning of this message was intended to describe the context in which it's OK to have a mixed mode EE cert. We can try to make this limitation clearer. Steve --============_-899729537==_ma============ Content-Type: text/html; charset="us-ascii" Re: [sidr] Fwd: New Version Notification for draft-ietf-s
At 6:16 PM -0400 8/2/11, Sandra Murphy wrote:
Speaking only as a regular ol' wg member:

The draft does not say why the mixed certificate prohibition was needed in the first place.

The new text says:

             This exception to the mixed algorithm suite certificate
   rule is allowed because an EE certificate that is not used to verify
   repository objects does not interfere with the ability of RPs to
   download and verify repository content.

There's a hint there that mixed certificates for CAs signing CA certs might cause a problem for RPs.

Goeff noted a serious problem that could arise if we allow for mixed certs at the CA level, i.e., a potential exponential directory explosion. I noted this
in the briefing I made in Prague. (See slide 3, bullet 3.)

I think it would be good to describe the problems RPs would see if CAs could sign CA certs with a mix of algorithms.
And it might be good to say why the mixed certificate case for some EE certs was desirable.

It's not clear why one would want mixed mode EE certs, for any EE cert used
to verify a repository object. It would impose a burden on all RPs (they would have to be able to deal with two suites).

In contrast, mixed mode certs for EE certs that are NOT used to validate repository objects do not impose a burden on ALL RPs. Only RPs that need to process these certs to extract and use he public key would need to be capable
of dealing with the alg for the Subject public key.


YMMV.

Also, the draft says:

                                                 In the RPKI, a CA MUST
   NOT sign a CA certificate carrying a subject key that corresponds to
   an algorithm suite that differs from the one used to sign the
   certificate.

It used to say that
                                                 In RPKI an algorithm
   suite MUST NOT sign a certificate carrying a subject key that
   corresponds to another algorithm suite.

To me, the old text sounded like issuance of any mixed certificate was prohibited.

yes, and it was also not good English :-). It would at least have to
say "In the RPKI an algorithm suite MUST NOT be used to sign a certificate carrying a subject key that contains a key that is used with another algorithm suite.

The new prohibition applies only to CAs issuing a CA cert and the new
exception applies only to EE certs that are not used to verify repository objects.  The new text sounds to me like it leaves open the case of EE certs that *are* used to verify repository objects.

That was not the intent. The cited text at the beginning of this message was intended to describe the context in which it's OK to have a mixed mode EE cert.  We can try to make this limitation clearer.

Steve
--============_-899729537==_ma============-- From kent@bbn.com Wed Aug 3 12:35:50 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 8E33E21F8B8E for ; Wed, 3 Aug 2011 12:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.617 X-Spam-Level: X-Spam-Status: No, score=-106.617 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 fXM1E8QEr4xg for ; Wed, 3 Aug 2011 12:35:50 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 08CBE21F8B8B for ; Wed, 3 Aug 2011 12:35:50 -0700 (PDT) Received: from dhcp89-089-043.bbn.com ([128.89.89.43]:49157) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QohEY-000P4L-HD for sidr@ietf.org; Wed, 03 Aug 2011 15:36:02 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1C1A5E2A-1C8A-4023-B2BA-A2D340470649@cisco.com> References: <20110802092022.13671.96567.idtracker@ietfa.amsl.com> <1C1A5E2A-1C8A-4023-B2BA-A2D340470649@cisco.com> Date: Wed, 3 Aug 2011 15:35:56 -0400 To: sidr@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: [sidr] Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-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, 03 Aug 2011 19:35:50 -0000 At 11:31 AM +0200 8/2/11, Roque Gagliano wrote: >Content-Type: multipart/signed; boundary=Apple-Mail-113--1037130997; >protocol="application/pkcs7-signature"; micalg=sha1 > >Dear WG, > >I uploaded a new version of the draft preparing it for WGLC. > >The only change is a requirement from the BGPSEC team to include a >paragraph in section 4.2 that clarifies that "mixed" certs are not >allowed only for CA certs but may be possible for EE certs that do >not validate repository objects (i.e. BGPSEC certs). > > >Regards, >Roque Folks, As the individual responsible for the changed text, let me explain the history for these changes. Geoff Huston sent one or more messages to Sean Turner asking some questions about Sean's BGPSEC router cert I-D. Sean passed on one of these questions to me. The question asked whether using an ECDSA key in a router cert (as Sean's draft proposes) would require invoking the alg transition doc on which Roque, Sean, and I are co-authors. I thought about the question and decided to revise the text that we had written. Specifically, I felt that use of a different alg suite in a EE cert that was NOT used to verify a sig on a repository object need not invoke the alg transition spec. The reasons for this are detailed in a message I sent earlier today. So, when Roque refers to the "BGPSEC team" above, I think he is referring to Sean, and me, as his co-authors on this doc, plus Geoff, the WG member who raised a question that motivated the changed text. Steve From rogaglia@cisco.com Wed Aug 3 13:37:35 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 DADD721F84F6 for ; Wed, 3 Aug 2011 13:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 QRjOwh6MRpaX for ; Wed, 3 Aug 2011 13:37:35 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id CD1D822800D for ; Wed, 3 Aug 2011 13:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=6847; q=dns/txt; s=iport; t=1312403868; x=1313613468; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=8Ep3Oe2AHck6S0/6u6vlPdqR07uexkOd3N7n54zlwPI=; b=B+kq/QXUXHAm8jVdTJtmSiRic7gk3l5+q18HgyvILl2EML5s7CxpA+dw herPR4m9AciwGErQyD2WT7E1ry6Xlw3fBk8s5vSctwjcvzfB3CTpHCz3M DgrHKNIjd87JLtr+3P4x8JcrYREfxz2YeqMehPI7Upm0sRyUoZYXKorem 8=; X-Files: smime.p7s : 4389 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAN6wOU6Q/khN/2dsb2JhbABCp2F3gUABAQEBAgESAWQCBQsLRgJVBjWHSqI7AZ5phWNfBJJ7kGY X-IronPort-AV: E=Sophos;i="4.67,312,1309737600"; d="p7s'?scan'208";a="106600789" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 03 Aug 2011 20:37:46 +0000 Received: from dhcp-10-61-103-13.cisco.com (dhcp-10-61-103-13.cisco.com [10.61.103.13]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p73KbknU001365; Wed, 3 Aug 2011 20:37:46 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-239--910783006; protocol="application/pkcs7-signature"; micalg=sha1 From: Roque Gagliano In-Reply-To: Date: Wed, 3 Aug 2011 22:37:45 +0200 Message-Id: References: <20110802092022.13671.96567.idtracker@ietfa.amsl.com> <1C1A5E2A-1C8A-4023-B2BA-A2D340470649@cisco.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: Re: [sidr] Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-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, 03 Aug 2011 20:37:36 -0000 --Apple-Mail-239--910783006 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > So, when Roque refers to the "BGPSEC team" above, I think he is = referring to > Sean, and me, as his co-authors on this doc, plus Geoff, the WG member = who > raised a question that motivated the changed text. Thanks Steve to clarify the history, which I was not completely aware. =20= Looks like I over-simplified the original acknowledge of the request = received by the co-authors. The intention was to focus on the use case = for the proposed changes (BGPSEC certs). Roque --Apple-Mail-239--910783006 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXDCCBWYw ggROoAMCAQICEFyqcUyRFrhvN5s0SHw/EO4wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA1MTAwMDAwMDBaFw0x MjA1MTEyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5Sb3F1ZSBHYWdsaWFubzEhMB8GCSqGSIb3DQEJARYScm9nYWdsaWFAY2lz Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxIp28SUiJ/fiFYD/Nct8MUbG WJuPqSnhkfBYMFbbWfDDrHR8OXzK2LkWIuHY5aeAo1nalAQCO40oeTYt0cp9W++a7USNCEDQzgVN Rg0YMYL27YSQoVJnecO3u9wi0jjwhJGblWWxphaztdaMbqiChgND1PHqf7dcs4UjeUOhhKFk0/61 mTmduV721jrxj6ABIlUHAc7nXhKANtDbKdBZzEhM4dbzp6STKq65EQ3xRLVFIuapTgNVckvXtc1e Cyu4xLOLZgaD2aLq9JzBn9y/rFRMtf2euP/Nmzl7QRjAUjpPdo1n6NXWGDtNyR0lUrcJ/x1leccZ Gfj0eaqe+tpJmQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAG A1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29t L0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAsvqKrlga/tU0vyBtnBOj 4miDAZxou0/fN2wVEK7dRLzIQLYEJD35sELVhiP8v8wVHtgOeVHz9FyBEVqXmJ0RKy4kMC7gdQxj +t1MlqSTDShEaPMmiwaK6M1iJ9jpBL4JvoiirpHnQYGukkgvTUeqITWZ5ecg03nB3QHuab91Gc+n RZ1OKL4D4p5IkvzWhRlIAlxW9yGZyB8r9V6iu3+1SYEpPPUN3AYCxXeXrn8fJjkOoEodybRiGyfW pMpShpTZg2tHB7ZX162Ti3sRvwA2mktDMnBtEm1pXo15z7yieDUPmjVybMA4byV7AQcbIrjQj0eq c/biBsueC2KWoJY7TDCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEF BQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBG b3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5 MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwT j+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliW B6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGce dAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69s sQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOM Wev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0 cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtg hkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoG CCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCeg JYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4G CCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNV HREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN 7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqT OtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih /1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0D uFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRIfD8Q7jAJBgUr DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4 MDMyMDM3NDZaMCMGCSqGSIb3DQEJBDEWBBQJ6dPVU+8R0pGgmJZBEHrTX6P5gjCCAQMGCSsGAQQB gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBcqnFMkRa4bzebNEh8PxDuMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRI fD8Q7jANBgkqhkiG9w0BAQEFAASCAQAZOWhcC/OnELWDqKQL1xwCkmc9TKxbPVkGbpxRY5Djdgmq 5i20F4PhONK0bEBCrSXSYfqndUd+/h+w0A3BuyF94Cw6tCYcFV1peH2zN5OoZCaYqjNyXE3YzuNN JqcPOSH7Jt78WTCstreZt2+nRMECwyWArNgsr4fZx7IdFNundgGF6TWQHe/bdkqPqYRkMHk9A8hZ kc3LIv87RDGTFBUMfrHVGfjKO9H5MF9cZJyCbVsdjKYa1yoaIJ0JkCSIdGr0F7HwDaInh3s5f8ks wcvGXTEoGllzX9uDCxB+IYFPczempym71ICk8iPRbNeG/EwmHsS7sT93HIScEWPESbDJAAAAAAAA --Apple-Mail-239--910783006-- From randy@psg.com Wed Aug 3 17:43: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 DD24D11E80B7 for ; Wed, 3 Aug 2011 17:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 rth7EIsyxtdE for ; Wed, 3 Aug 2011 17:43:25 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 6919B11E80B0 for ; Wed, 3 Aug 2011 17:43:25 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qom2B-000GYn-FZ; Thu, 04 Aug 2011 00:43:35 +0000 Date: Thu, 04 Aug 2011 09:43:34 +0900 Message-ID: From: Randy Bush To: Roque Gagliano In-Reply-To: References: <20110802092022.13671.96567.idtracker@ietfa.amsl.com> <1C1A5E2A-1C8A-4023-B2BA-A2D340470649@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@ietf.org Subject: Re: [sidr] Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-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: Thu, 04 Aug 2011 00:43:26 -0000 > The intention was to focus on the use case for the proposed changes > (BGPSEC certs). what is a "BGPSEC cert?" randy From turners@ieca.com Thu Aug 4 06:10: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 402EE21F8B36 for ; Thu, 4 Aug 2011 06:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.234 X-Spam-Level: X-Spam-Status: No, score=-102.234 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFYU3cGh6ljq for ; Thu, 4 Aug 2011 06:10:52 -0700 (PDT) Received: from nm12-vm0.bullet.mail.ac4.yahoo.com (nm12-vm0.bullet.mail.ac4.yahoo.com [98.139.53.198]) by ietfa.amsl.com (Postfix) with SMTP id 957E021F8B2C for ; Thu, 4 Aug 2011 06:10:52 -0700 (PDT) Received: from [98.139.52.188] by nm12.bullet.mail.ac4.yahoo.com with NNFMP; 04 Aug 2011 13:11:04 -0000 Received: from [98.139.52.161] by tm1.bullet.mail.ac4.yahoo.com with NNFMP; 04 Aug 2011 13:11:04 -0000 Received: from [127.0.0.1] by omp1044.mail.ac4.yahoo.com with NNFMP; 04 Aug 2011 13:11:04 -0000 X-Yahoo-Newman-Id: 390795.30023.bm@omp1044.mail.ac4.yahoo.com Received: (qmail 2910 invoked from network); 4 Aug 2011 13:11:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1312463463; bh=p/t2Yq2EPdcP2fjW0kZiaCQVTsjx1JhGVdISNQkXp0I=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=oBiBBTGIDjwMwswZQmf9KyViW7fTnrZx0lm/OLDupPs+QKiUGCodlPWr2tIgLXnt3Ry2Dvy33sNc3K9DJiS83dQpl6v5AgbJQyG7iaoU5Hh9SFUqYuMaXgTScxmGSU1Z4yuRW1fzuXyP4aVlNt/qKvE1gE4Pbp6+zI1yqJek2uc= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: EJo8tJUVM1m4xfNRrHnArdem0Ng1AX7j3ezIX1EGrf7SAE9 XAkWmOM8ggMImkoTrq5k0FE_PMDxac7IfHwBsjzS62T7CTZZ8rMbK5LYp61L 2iBQ32.sP_noOYXQXHlYRgL4J4qGTIt6p5k0jQlNb60MAsz9GW5EgvOH_C57 nejThRxF3M5XOpHlgRysF13Gz9drM2t4JMwlk4JZzypoGMKnPSKrUtc0w3zz CGTiVN1_KfjK0b66BKoYjNbyV82CZW1ea1wO6WzyHglDOhhI8CsuHcnIbKwQ 9YMg8NTT30cOn3CPqxGl_6T9WDXNm_T4QJqfT5hxG4ama90nhWKmh4B0J3pn xuc3Kea5Xn.IgBidp1m_lqtglo2LBGro62gXLzAvAItxrUnWdLZ.VplYM4Dd CruhuuD7MOJzec3hwX3cxeqZkldtJTSFcxCoCT4ln X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from thunderfish.westell.com (turners@96.231.115.219 with plain) by smtp112.biz.mail.mud.yahoo.com with SMTP; 04 Aug 2011 06:11:03 -0700 PDT Message-ID: <4E3A9A65.4010207@ieca.com> Date: Thu, 04 Aug 2011 09:11:01 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Randy Bush References: <20110802092022.13671.96567.idtracker@ietfa.amsl.com> <1C1A5E2A-1C8A-4023-B2BA-A2D340470649@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-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: Thu, 04 Aug 2011 13:10:53 -0000 On 8/3/11 8:43 PM, Randy Bush wrote: >> The intention was to focus on the use case for the proposed changes >> (BGPSEC certs). > > what is a "BGPSEC cert?" What Mark and I are currently proposing in draft-turner-sidr-bgpsec-pki-profiles is that a BGPSEC certificate is a special purpose Resource Certificate (and hence issued by an RPKI CA) that always contains: - A non-critical "BGPSEC" Extended Key Usage (defined in the draft) - An Autonomous System (AS) Identifier Delegation extension (from 3779) and never contains: - the Subject Information Access (SIA) extension - the IP Address Delegation extension With the BGPSEC EKU, RPs will easily be able to distinguish a BGPSEC certificate from the Resource Certificates defined with draft-ietf-sidr-res-certs and even from those defined in draft-ietf-csi-send-cert. The EKU is pretty much the big clue to RPs for two things 1) this certificate is only used by BGPSEC speakers and 2) that the validation procedures defined in draft-ietf-sidr-res-certs won't work on BGPSEC certificates. The procedures in draft-turner-sidr-bgpsec-pki-profiles need to be used.* Note that including EKUs in "routers or other devices" is allowed by draft-ietf-sidr-res-certs. The AS Identifier Delegation extension is always included because BGPSEC is only about AS-Paths. The IP Address Delegation extension just isn't needed so it's left out. The SIA is omitted because it isn't needed. The objects signed by the BGPSEC speaker (i.e., the BGPSEC update message defined in draft-ietf-sidr-bgpsec-protocol) are not included in a repository - the objects are exchanged as part of the BGPSEC protocol. * The difference in path processing is about checking for the presence of the EKU and AS Identifier Delegation extensions and the absence of the SIA and IP Address Delegation extensions. spt PS Technically, the EKU is defined in draft-turner-bpgsec-pki-profiles. It's just an object identifier (OID) that Mark and I would get out of the PKIX Arc, which is where all the IETF EKU OIDs come from. We obviously haven't requested the OID yet so it's still "TBD". If the WG decides to adopt this approach, then we'll go through the appropriate procedures to request an OID and include it in the draft. From randy@psg.com Thu Aug 4 16:17: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 873B921F86C2 for ; Thu, 4 Aug 2011 16:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 PpKkqgwDHKEw for ; Thu, 4 Aug 2011 16:17:46 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2FD21F86C0 for ; Thu, 4 Aug 2011 16:17:46 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qp7Au-000K1r-Nv for sidr@ietf.org; Thu, 04 Aug 2011 23:18:01 +0000 Date: Fri, 05 Aug 2011 08:17:59 +0900 Message-ID: From: Randy Bush To: sidr wg list 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: [sidr] adopt a mib 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, 04 Aug 2011 23:17:46 -0000 i would request the wg adopt draft-ymbk-bgp-origin-validation-mib draft-ymbk-rpki-rtr-protocol-mib yes, they are works in progress. but that's what a wg is for. fwiw, bert is hacking away. expect fuller work in a week. randy From sra@hactrn.net Thu Aug 4 16:21:39 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 4A32511E807C for ; Thu, 4 Aug 2011 16:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sd-CtV93tls1 for ; Thu, 4 Aug 2011 16:21:39 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by ietfa.amsl.com (Postfix) with ESMTP id A2D7421F86C2 for ; Thu, 4 Aug 2011 16:21:38 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 39C8628471; Thu, 4 Aug 2011 23:21:50 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 0AB812282A; Thu, 4 Aug 2011 19:21:50 -0400 (EDT) Date: Thu, 04 Aug 2011 19:21:50 -0400 From: Rob Austein To: Sandra Murphy In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20110804232150.0AB812282A@thrintun.hactrn.net> Cc: sidr wg list Subject: Re: [sidr] WG LC for draft-ietf-sidr-ghostbusters-06.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, 04 Aug 2011 23:21:39 -0000 At Wed, 13 Jul 2011 19:35:11 -0400 (Eastern Daylight Time), Sandy Murphy wrote: > > The chairs have received a request from the authors for a WG Last Call for > "The RPKI Ghostbusters Record", draft-ietf-sidr-ghostbusters-06. I've read this draft and support it going forward. FWIW, I've also implemented most of it, all but the VCard generation and validation. Our code does that too, but in a separate application that I didn't write. From rogaglia@cisco.com Thu Aug 4 16:38:21 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 D6A1711E807F for ; Thu, 4 Aug 2011 16:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 X6TjqhSEg9jg for ; Thu, 4 Aug 2011 16:38:21 -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 B030011E807C for ; Thu, 4 Aug 2011 16:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=7083; q=dns/txt; s=iport; t=1312501117; x=1313710717; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=/1gASNjgbO721FU9mj7RCkN950Ra+N8kxwIIKItaey8=; b=DEJA0q6FxW4D/B5dgCR1spLpqG0mLAXJ2BMr4qLxVhSQAxu+Rl8sKh1Z PwCZ18IlR1YI9KANid3RcTmo2gIZsiJwNd6ZcIEUOkJ1e1Z8gHYOkT3Uu 9oK5zEU0DHm+8CSNK8umAarO7X4iKxFfUAdJ9RLGtp7isKewSlv3MFbIo g=; X-Files: smime.p7s : 4389 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAAstO06Q/khN/2dsb2JhbABDp2t3gUABAQEBAgEBAQEPAVsLBQsLRgIlMAYTIodKBKJLAZ5dhWNfBJJ7kGY X-IronPort-AV: E=Sophos;i="4.67,320,1309737600"; d="p7s'?scan'208";a="46709398" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 04 Aug 2011 23:38:36 +0000 Received: from ams3-vpn-dhcp7896.cisco.com (ams3-vpn-dhcp7896.cisco.com [10.61.94.215]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p74NcZWq001780; Thu, 4 Aug 2011 23:38:35 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-653--813533496; protocol="application/pkcs7-signature"; micalg=sha1 From: Roque Gagliano In-Reply-To: Date: Fri, 5 Aug 2011 01:38:34 +0200 Message-Id: References: To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] adopt a mib 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, 04 Aug 2011 23:38:21 -0000 --Apple-Mail-653--813533496 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I support adoption of both documents with one comment: On "draft-ymbk-bgp-origin-validation-mib", I would not use the word = "ROATable". The router does not interact with ROAs and I believe it is = confusing. In "draft-ietf-sidr-pfx-validate-02", the same table is referred as: = "pfx_validate_table". Roque > i would request the wg adopt >=20 > draft-ymbk-bgp-origin-validation-mib > draft-ymbk-rpki-rtr-protocol-mib >=20 > yes, they are works in progress. but that's what a wg is for. >=20 > fwiw, bert is hacking away. expect fuller work in a week. >=20 > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-653--813533496 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXDCCBWYw ggROoAMCAQICEFyqcUyRFrhvN5s0SHw/EO4wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA1MTAwMDAwMDBaFw0x MjA1MTEyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5Sb3F1ZSBHYWdsaWFubzEhMB8GCSqGSIb3DQEJARYScm9nYWdsaWFAY2lz Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxIp28SUiJ/fiFYD/Nct8MUbG WJuPqSnhkfBYMFbbWfDDrHR8OXzK2LkWIuHY5aeAo1nalAQCO40oeTYt0cp9W++a7USNCEDQzgVN Rg0YMYL27YSQoVJnecO3u9wi0jjwhJGblWWxphaztdaMbqiChgND1PHqf7dcs4UjeUOhhKFk0/61 mTmduV721jrxj6ABIlUHAc7nXhKANtDbKdBZzEhM4dbzp6STKq65EQ3xRLVFIuapTgNVckvXtc1e Cyu4xLOLZgaD2aLq9JzBn9y/rFRMtf2euP/Nmzl7QRjAUjpPdo1n6NXWGDtNyR0lUrcJ/x1leccZ Gfj0eaqe+tpJmQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAG A1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29t L0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAsvqKrlga/tU0vyBtnBOj 4miDAZxou0/fN2wVEK7dRLzIQLYEJD35sELVhiP8v8wVHtgOeVHz9FyBEVqXmJ0RKy4kMC7gdQxj +t1MlqSTDShEaPMmiwaK6M1iJ9jpBL4JvoiirpHnQYGukkgvTUeqITWZ5ecg03nB3QHuab91Gc+n RZ1OKL4D4p5IkvzWhRlIAlxW9yGZyB8r9V6iu3+1SYEpPPUN3AYCxXeXrn8fJjkOoEodybRiGyfW pMpShpTZg2tHB7ZX162Ti3sRvwA2mktDMnBtEm1pXo15z7yieDUPmjVybMA4byV7AQcbIrjQj0eq c/biBsueC2KWoJY7TDCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEF BQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBG b3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5 MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwT j+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliW B6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGce dAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69s sQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOM Wev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0 cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtg hkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoG CCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCeg JYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4G CCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNV HREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN 7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqT OtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih /1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0D uFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRIfD8Q7jAJBgUr DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4 MDQyMzM4MzVaMCMGCSqGSIb3DQEJBDEWBBToj8wqVmjtbNA6fOTsZ6yvh/spIDCCAQMGCSsGAQQB gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBcqnFMkRa4bzebNEh8PxDuMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRI fD8Q7jANBgkqhkiG9w0BAQEFAASCAQCpK0FAa6dKGVvkr3M5AexDLUnj36lPXTd2JdqYXHQXO2ZH kI896c5qV7+eN3khEh3CRhom1sTqNshOENF2ClggiFAqL3UrHicmNOEiO+qvRz41RTt1+lBT4NTz ISVTSog/A/97P4o05C4x8PQWCEBQFP/j3/gkxeiPdYgTn/UMRVibERhKHE1Q8t5B7pLf0E1nfXia y1DwibTadDrC7Mjzx6kNkK02yGLy4595XEOw3QefGaspA82xn1acdchU+vXiq5iYtL8I1mj+auYe 1Y+CoLvHq9P5/waVfWQgdX7N/XqPWeKRmFQSthqF1z2Ld5+xeFZfU9Nc7oohmslDI5UzAAAAAAAA --Apple-Mail-653--813533496-- From randy@psg.com Thu Aug 4 16:47: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 B1F2D11E8094 for ; Thu, 4 Aug 2011 16:47:32 -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 nP35eqzmA6kH for ; Thu, 4 Aug 2011 16:47:32 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA1911E807C for ; Thu, 4 Aug 2011 16:47:32 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qp7di-000K6g-GP; Thu, 04 Aug 2011 23:47:46 +0000 Date: Fri, 05 Aug 2011 08:47:45 +0900 Message-ID: From: Randy Bush To: Roque Gagliano In-Reply-To: References: 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] adopt a mib 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, 04 Aug 2011 23:47:32 -0000 > On "draft-ymbk-bgp-origin-validation-mib", I would not use the word > "ROATable". The router does not interact with ROAs and I believe it is > confusing. point taken randy From raszuk@cisco.com Thu Aug 4 23:10:04 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 C95B521F8AE4 for ; Thu, 4 Aug 2011 23:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=-0.925, 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 tEmNrHJU92xm for ; Thu, 4 Aug 2011 23:10:04 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 18C6221F8ADC for ; Thu, 4 Aug 2011 23:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=660; q=dns/txt; s=iport; t=1312524621; x=1313734221; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=ELcy2hnV0ilAM4WwEK3BOFBPNAYkbwcHDnf5mJwHqho=; b=NEUgIJB8DTvDMsbyDLh3aODVNkT0e6ahNAaPB3NllbvLwV/EWah03ma/ at5OFftRWV8g97nS+j6OpVLd0oYIO21H9ZnTJHoBc2kgUYsYShp0lfiqU 5+vazd9F7vUVGEUpi/2AAaJVecqRZv6qqgcPVk5/djaduUQwesA3CDx0Z o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANKIO06rRDoJ/2dsb2JhbABDp293gUABAQEBAgEBAQEPAQIBIjYKEQsYCRYPCQMCAQIBFTAGAQwGAgEBHodLBKJrAYMcDwGbQoZGBIdbiySFCIt/ X-IronPort-AV: E=Sophos;i="4.67,321,1309737600"; d="scan'208";a="9916491" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-6.cisco.com with ESMTP; 05 Aug 2011 06:09:51 +0000 Received: from [10.21.108.126] ([10.21.108.126]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7569oht008079; Fri, 5 Aug 2011 06:09:50 GMT Message-ID: <4E3B8930.9090605@cisco.com> Date: Thu, 04 Aug 2011 23:09:52 -0700 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Randy Bush , sidr wg list References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] adopt a mib 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: Fri, 05 Aug 2011 06:10:05 -0000 Hi, Just looking at draft-ymbk-bgp-origin-validation-mib may I ask what would be the root OID string to start SNMP tree walk (or set the trap) to list all INVALID or NOT_FOUND BGP entries ? Rgs, R. > On 8/4/2011 4:17 PM, Randy Bush wrote: > i would request the wg adopt > > draft-ymbk-bgp-origin-validation-mib > draft-ymbk-rpki-rtr-protocol-mib > > yes, they are works in progress. but that's what a wg is for. > > fwiw, bert is hacking away. expect fuller work in a week. > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From bertietf@bwijnen.net Thu Aug 4 23:33:09 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 CA3CC11E8073 for ; Thu, 4 Aug 2011 23:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 lASER7fEcA8M for ; Thu, 4 Aug 2011 23:33:09 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id D77A811E807F for ; Thu, 4 Aug 2011 23:33:07 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QpDyD-0000Ot-Sa; Fri, 05 Aug 2011 08:33:22 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1QpDyD-0006Wx-Ja; Fri, 05 Aug 2011 08:33:21 +0200 Message-ID: <4E3B8EB1.7030007@bwijnen.net> Date: Fri, 05 Aug 2011 08:33:21 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: raszuk@cisco.com References: <4E3B8930.9090605@cisco.com> In-Reply-To: <4E3B8930.9090605@cisco.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: 86ab03e524994f79ca2c75a176445dd493e4874422ec82d9f810b8f5907f436b Cc: sidr wg list Subject: Re: [sidr] adopt a mib 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, 05 Aug 2011 06:33:09 -0000 During the discussion at the SIDR WG session at IETF81 we found that the bgpVRTValid attribute in that table makes no sense, because we do not have that info. These are ALL validated ROAs (or better validated prefixes) as I understand it. Bert On 8/5/11 8:09 AM, Robert Raszuk wrote: > Hi, > > Just looking at draft-ymbk-bgp-origin-validation-mib may I ask what would be the root OID string to start SNMP tree walk (or set > the trap) to list all INVALID or NOT_FOUND BGP entries ? > > Rgs, > R. > > > On 8/4/2011 4:17 PM, Randy Bush wrote: >> i would request the wg adopt >> >> draft-ymbk-bgp-origin-validation-mib >> draft-ymbk-rpki-rtr-protocol-mib >> >> yes, they are works in progress. but that's what a wg is for. >> >> fwiw, bert is hacking away. expect fuller work in a week. >> >> randy >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From raszuk@cisco.com Thu Aug 4 23:39: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 B5EBD21F863E for ; Thu, 4 Aug 2011 23:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=-0.740, 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 ekjW3LeImwpp for ; Thu, 4 Aug 2011 23:39:03 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7C221F84E1 for ; Thu, 4 Aug 2011 23:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1056; q=dns/txt; s=iport; t=1312526360; x=1313735960; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=stCSLt0sGTJo64omIPLhpQ5HqsJ1xOBQ4vR2yKyJkU4=; b=Nld4+rPr7DeCwk1CVB5sgl8oXNpzVrecm+PdVy3Kt+7qBHVZYEFAY/rk EQ0URqgOEWbXPdU4mnsKaNvpmD92iZCbxJWPygcWwS+IA/BYNLOSBTSCl DfMYPpwoVOY1IhjZwkMnlQG9U8oN808ZSG8IEwANxOpAGeCwOkbNhFGRT s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOGPO06rRDoI/2dsb2JhbABDp3B3gUABAQEBAgESAQIBIkEFCwsYCSUPAkYGDQEHAQEeh0uiNAGDHA8Bm0SGRgSHW4skhQiLfw X-IronPort-AV: E=Sophos;i="4.67,321,1309737600"; d="scan'208";a="9928618" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-5.cisco.com with ESMTP; 05 Aug 2011 06:39:19 +0000 Received: from [10.21.108.126] ([10.21.108.126]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p756dI3Q029347; Fri, 5 Aug 2011 06:39:19 GMT Message-ID: <4E3B9018.80808@cisco.com> Date: Thu, 04 Aug 2011 23:39:20 -0700 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Bert (IETF) Wijnen" References: <4E3B8930.9090605@cisco.com> <4E3B8EB1.7030007@bwijnen.net> In-Reply-To: <4E3B8EB1.7030007@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr wg list Subject: Re: [sidr] adopt a mib 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: Fri, 05 Aug 2011 06:39:03 -0000 Hi Bert, Many thx for your comment .. I was not able to stay at the IETF till the SIDR session. If that is the case the draft-ymbk-bgp-origin-validation-mib is just completely not ready for adoption until it contains bare minimum which will allow operators to use it. It would be insane to list 1 million of valid prefixes as opposed to little fraction of them being in question. Whoever authored that draft needs to develop a bit more real network operational experience :) Best regards, R. > During the discussion at the SIDR WG session at IETF81 we > found that the bgpVRTValid attribute in that table makes no > sense, because we do not have that info. These are ALL > validated ROAs (or better validated prefixes) as I understand > it. > > Bert > On 8/5/11 8:09 AM, Robert Raszuk wrote: >> Hi, >> >> Just looking at draft-ymbk-bgp-origin-validation-mib may I ask what >> would be the root OID string to start SNMP tree walk (or set the trap) >> to list all INVALID or NOT_FOUND BGP entries ? >> >> Rgs, >> R. From bertietf@bwijnen.net Fri Aug 5 00:01:17 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 5061811E807F for ; Fri, 5 Aug 2011 00:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fu5RT6R8xSwf for ; Fri, 5 Aug 2011 00:01:16 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBFC11E8073 for ; Fri, 5 Aug 2011 00:01:16 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QpEPO-0000s0-Kw; Fri, 05 Aug 2011 09:01:31 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1QpEPO-000860-EK; Fri, 05 Aug 2011 09:01:26 +0200 Message-ID: <4E3B9546.4000808@bwijnen.net> Date: Fri, 05 Aug 2011 09:01:26 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: raszuk@cisco.com References: <4E3B8930.9090605@cisco.com> <4E3B8EB1.7030007@bwijnen.net> <4E3B9018.80808@cisco.com> In-Reply-To: <4E3B9018.80808@cisco.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: 86ab03e524994f79ca2c75a176445dd4e765352ec59c48178628518ca9053e35 Cc: sidr wg list Subject: Re: [sidr] adopt a mib 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, 05 Aug 2011 07:01:17 -0000 Inline On 8/5/11 8:39 AM, Robert Raszuk wrote: > Hi Bert, > > Many thx for your comment .. I was not able to stay at the IETF till the SIDR session. > > If that is the case the draft-ymbk-bgp-origin-validation-mib is just completely not ready for adoption until it contains bare > minimum which will allow operators to use it. > The MIB module is not ready for WGLC, I agree on that. In my feel, the adoption question is more of: Does the WG want to work on these 2 MIB modules. The exact content then needs to be agreed on by the WG. If you want to see another individual draft with better content first.. I have no problem with that, up to the chair to decide I think. > It would be insane to list 1 million of valid prefixes as opposed to little fractionof them being in question. Whoever authored > that draft needs to develop a bit more real network operational experience :) > I did not author it, but I am now working on it. I am a MIB/SMI/SNMP guy. Not a router or BGP or RPKI expert. Constructive input is helpfull The table (as in the current I-D) has this attribute: bgpVRTValid OBJECT-TYPE SYNTAX INTEGER { unknown(1), valid(2), invalid(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "This is indicates if the state of the roa associated with this row." DEFVAL { unknown } ::= { bgpValROATableEntry 5 } So my answer to your comments: - listing the status (unknown, valid or invalid) will only result in MORE entries than just listing the valid ones. - My understanding is/was that the table might have some 300K entries But that is from hearsay. Anyways, that is still a lot, I Understand that. And therefor, proper indexing is important. I need to know what sort of queries operators are most likely to do on this table. If you (with lots of operator experience I assume) or others can help me with that, that would be great. Bert > Best regards, > R. > >> During the discussion at the SIDR WG session at IETF81 we >> found that the bgpVRTValid attribute in that table makes no >> sense, because we do not have that info. These are ALL >> validated ROAs (or better validated prefixes) as I understand >> it. >> >> Bert >> On 8/5/11 8:09 AM, Robert Raszuk wrote: >>> Hi, >>> >>> Just looking at draft-ymbk-bgp-origin-validation-mib may I ask what >>> would be the root OID string to start SNMP tree walk (or set the trap) >>> to list all INVALID or NOT_FOUND BGP entries ? >>> >>> Rgs, >>> R. > > > From raszuk@cisco.com Fri Aug 5 00:17:16 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 ACA6B11E8091 for ; Fri, 5 Aug 2011 00:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.216 X-Spam-Level: X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=-0.617, 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 WSg7FWCPP6nV for ; Fri, 5 Aug 2011 00:17:16 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id F247A5E8007 for ; Fri, 5 Aug 2011 00:17:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=3683; q=dns/txt; s=iport; t=1312528653; x=1313738253; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=4RdJygEhmiAd5c62diSHrlEDjhSt1dl73DZ3rdNu85U=; b=ECHYcUkfpDYaxWMPk/pHV7TkAgF3heK0URr/gCJjn+mddePb2qBJn6Tr 0TZSaDKyK5vfyTgKHHA72cpRNA3lS2DWgeVhkwpw3Bu2XRc3UhFjxAwj1 s0NOXRa1rM1yvKpTlTLzVOeOmz1zr9nKiULC7WgMgXyGbSwsYhL7FcUvR M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANqXO06rRDoI/2dsb2JhbABDp253gUABAQEBAgESAQIBIjMNAQULCxgJFg8JAwIBAgFFBg0BBwEBHodLoj8BgxwPAZtLhkYEh1uLJIUIi38 X-IronPort-AV: E=Sophos;i="4.67,321,1309737600"; d="scan'208";a="9940339" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-4.cisco.com with ESMTP; 05 Aug 2011 07:17:30 +0000 Received: from [10.21.108.128] ([10.21.108.128]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p757HTbo015421; Fri, 5 Aug 2011 07:17:29 GMT Message-ID: <4E3B990B.1060409@cisco.com> Date: Fri, 05 Aug 2011 00:17:31 -0700 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Bert (IETF) Wijnen" References: <4E3B8930.9090605@cisco.com> <4E3B8EB1.7030007@bwijnen.net> <4E3B9018.80808@cisco.com> <4E3B9546.4000808@bwijnen.net> In-Reply-To: <4E3B9546.4000808@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr wg list Subject: Re: [sidr] adopt a mib 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: Fri, 05 Aug 2011 07:17:16 -0000 Hi Bert, > The MIB module is not ready for WGLC, I agree on that. Nothing personal to you Bert and I highly value your work and as we met few times it is just awesome. But when I write a draft I do try hard to make it useful. Then WG adoption to will make it fine-tuned to be perfect and be able to accommodate various additional little points which I may not have thought about. > In my feel, the adoption question is more of: Does the WG want to work on > these 2 MIB modules. The exact content then needs to be agreed on by the > WG. The answer is yes - however WG IMHO should adopt a sculpture to polish rather then piece of wood. Let's try to maintain some level of value in this or any other WG. > If you want to see another individual draft with better content first.. > I have no problem with that, up to the chair to decide I think. My personal opinion is that the bear minimum is to see a draft which allows to query for all states. Then we can accept this as WG item and work on polishing it with sand paper. > I did not author it, but I am now working on it. I am glad you are as I know you and you are very experienced person. > I am a MIB/SMI/SNMP guy. Not a router or BGP or RPKI expert. > Constructive input is helpfull Just trying to provide some input to you :) And I am just complete mirror .. I (unfortunately :) had to spend months on developing SNMP scripts when I was an operator, but now all I care about is to make sure what we define for the router to do is at least minimally useful. > The table (as in the current I-D) has this attribute: > bgpVRTValid OBJECT-TYPE > SYNTAX INTEGER { unknown(1), valid(2), invalid(3) } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This is indicates if the state of the roa associated with > this row." > DEFVAL { unknown } > ::= { bgpValROATableEntry 5 } > > So my answer to your comments: > - listing the status (unknown, valid or invalid) will only result in > MORE entries than just listing the valid ones. We do need few more attributes to be able to explicitly ask for all validation criteria. Doing those is just really minor work. > - My understanding is/was that the table might have some 300K entries > But that is from hearsay. > Anyways, that is still a lot, I Understand that. And therefor, proper > indexing is important. I need to know what sort of queries operators > are most likely to do on this table. > If you (with lots of operator experience I assume) or others can help > me with that, that would be great. The minimum passing grade for me would be to have ability to query for all results of origin validation state check. However if we really would like to help NOC eng we should also provide new class of attributes on what communities the routes after being examined and been colored were advertised to IBGP peers. I personally see no need for more to get to WG adoption phase. Best regards and many thx for your reply Bert, Robert. > > Bert > >> Best regards, >> R. >> >>> During the discussion at the SIDR WG session at IETF81 we >>> found that the bgpVRTValid attribute in that table makes no >>> sense, because we do not have that info. These are ALL >>> validated ROAs (or better validated prefixes) as I understand >>> it. >>> >>> Bert >>> On 8/5/11 8:09 AM, Robert Raszuk wrote: >>>> Hi, >>>> >>>> Just looking at draft-ymbk-bgp-origin-validation-mib may I ask what >>>> would be the root OID string to start SNMP tree walk (or set the trap) >>>> to list all INVALID or NOT_FOUND BGP entries ? >>>> >>>> Rgs, >>>> R. >> >> >> > > From turners@ieca.com Fri Aug 5 06:04:41 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 A5BB321F8B80 for ; Fri, 5 Aug 2011 06:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.318 X-Spam-Level: X-Spam-Status: No, score=-101.318 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_20=-0.74, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMWy7MXwigWF for ; Fri, 5 Aug 2011 06:04:41 -0700 (PDT) Received: from nm24.bullet.mail.sp2.yahoo.com (nm24.bullet.mail.sp2.yahoo.com [98.139.91.94]) by ietfa.amsl.com (Postfix) with SMTP id 401E421F8B7C for ; Fri, 5 Aug 2011 06:04:41 -0700 (PDT) Received: from [98.139.91.67] by nm24.bullet.mail.sp2.yahoo.com with NNFMP; 05 Aug 2011 13:04:58 -0000 Received: from [98.139.91.42] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 05 Aug 2011 13:04:58 -0000 Received: from [127.0.0.1] by omp1042.mail.sp2.yahoo.com with NNFMP; 05 Aug 2011 13:04:58 -0000 X-Yahoo-Newman-Id: 871089.86560.bm@omp1042.mail.sp2.yahoo.com Received: (qmail 79385 invoked from network); 5 Aug 2011 13:04:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1312549498; bh=2gy9cffz0iSnOy4yjFDk47SiXCBiTYQmvgHg10m/jyY=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=F7tgB3hMyjuwFZLgCOioJ0/QGJv+PhiFqerDw4VQ1mPEClpLHaRGeTfKSeiI86SyPKcDLyEipcTJfK+cKW7xPTXbqyVDUVgFVRuHLzuEAJ5rACT9bb95n4TShsOKQ4xSrZNriprlNbujIs77vqIjrSojBIkQAQOFpfLyqrvqZwk= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: f8XOlmMVM1k69XqI10su0v1xcZs2NiURs6EP_FvwjRF36zh iaDvcJ3jIeAMcoh_GzCYNN54MRBZ0XcdRH8MPdl6s9SypR1DSVN8TowVmvuc qLhKIyE2SgDEVJjL_gspms94H0VrMfdavqcQdloajmRUjNhWicEzZ2gjqVC9 F8AVR1dThRxrDNlz9BuTIE_DcdEeLEWs22wPOmxxszPE89KW5mLapQ_bOp9v ZW8Muz.lbnlRYHnFFHSsstPdNxji49pGqEkvsLDwwbeSKFT9LgWUbJKR2hMJ d9PsDCO0lRLgUOV9cxfh30AytKWqvAIcpqgX_.x0HlCf62V4yCQ2UBO7.TXQ 7QLT5lbA3ezGa8_5JNkwffnCaunNGDD7j6yYYCH.pNvoRdGUOS6IiL3Ud2hx KHfKlFP_Fi_fbXvvh_nKZ6TH4yoQM7OpazvSs.Q-- X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from thunderfish.westell.com (turners@96.231.115.219 with plain) by smtp113.biz.mail.sp1.yahoo.com with SMTP; 05 Aug 2011 06:04:58 -0700 PDT Message-ID: <4E3BEA79.1050103@ieca.com> Date: Fri, 05 Aug 2011 09:04:57 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: sidr wg list References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] adopt a mib 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, 05 Aug 2011 13:04:41 -0000 I support both too. spt On 8/4/11 7:38 PM, Roque Gagliano wrote: > I support adoption of both documents with one comment: > On "draft-ymbk-bgp-origin-validation-mib", I would not use the word "ROATable". The router does not interact with ROAs and I believe it is confusing. > In "draft-ietf-sidr-pfx-validate-02", the same table is referred as: "pfx_validate_table". > > Roque > > > >> i would request the wg adopt >> >> draft-ymbk-bgp-origin-validation-mib >> draft-ymbk-rpki-rtr-protocol-mib >> >> yes, they are works in progress. but that's what a wg is for. >> >> fwiw, bert is hacking away. expect fuller work in a week. >> >> randy >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From sra@hactrn.net Fri Aug 5 06: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 1F4FC21F8BBF for ; Fri, 5 Aug 2011 06:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YJPY9fdgPKJ for ; Fri, 5 Aug 2011 06:52:10 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by ietfa.amsl.com (Postfix) with ESMTP id 7700D21F8BB1 for ; Fri, 5 Aug 2011 06:52:10 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 0B32728471 for ; Fri, 5 Aug 2011 13:52:23 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id CF0522282A for ; Fri, 5 Aug 2011 09:52:22 -0400 (EDT) Date: Fri, 05 Aug 2011 09:52:22 -0400 From: Rob Austein To: sidr wg list In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20110805135222.CF0522282A@thrintun.hactrn.net> Subject: Re: [sidr] adopt a mib 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, 05 Aug 2011 13:52:11 -0000 At Fri, 05 Aug 2011 08:17:59 +0900, Randy Bush wrote: > > i would request the wg adopt > > draft-ymbk-bgp-origin-validation-mib > draft-ymbk-rpki-rtr-protocol-mib Support. > yes, they are works in progress. but that's what a wg is for. Just so. From warren@kumari.net Fri Aug 5 07:25: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 62C5021F8B4D for ; Fri, 5 Aug 2011 07:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.316 X-Spam-Level: X-Spam-Status: No, score=-102.316 tagged_above=-999 required=5 tests=[AWL=0.283, 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 QrVlgcGRkq7w for ; Fri, 5 Aug 2011 07:25:41 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id DDFCC21F8B2A for ; Fri, 5 Aug 2011 07:25:41 -0700 (PDT) Received: from dhcp-172-19-118-113.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id EDDCB1B416D8; Fri, 5 Aug 2011 10:25:58 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Fri, 5 Aug 2011 10:25:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <88E22E87-5D4A-4C5E-B097-12098F543F63@kumari.net> References: To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] adopt a mib 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, 05 Aug 2011 14:25:42 -0000 On Aug 4, 2011, at 7:17 PM, Randy Bush wrote: > i would request the wg adopt >=20 > draft-ymbk-bgp-origin-validation-mib Support adoption. > draft-ymbk-rpki-rtr-protocol-mib Support adoption. >=20 > yes, they are works in progress. but that's what a wg is for. Yes they are, and, yes it is (although sometimes a wg feels more like a = soapbox... or a pulpit...) W >=20 > fwiw, bert is hacking away. expect fuller work in a week. >=20 > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From randy@psg.com Fri Aug 5 07:27: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 B39FB21F86F6 for ; Fri, 5 Aug 2011 07:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 5yRWzzRy-PHm for ; Fri, 5 Aug 2011 07:27:40 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 4163221F86EE for ; Fri, 5 Aug 2011 07:27:40 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QpLNU-000Mu8-1r; Fri, 05 Aug 2011 14:27:56 +0000 Date: Fri, 05 Aug 2011 23:27:55 +0900 Message-ID: From: Randy Bush To: Warren Kumari In-Reply-To: <88E22E87-5D4A-4C5E-B097-12098F543F63@kumari.net> References: <88E22E87-5D4A-4C5E-B097-12098F543F63@kumari.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] adopt a mib 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, 05 Aug 2011 14:27:40 -0000 >> yes, they are works in progress. > Yes they are bert is slaving away as we type randy From waehlisch@ieee.org Fri Aug 5 07:39: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 2762121F8C11 for ; Fri, 5 Aug 2011 07:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 KRuPBifieBD4 for ; Fri, 5 Aug 2011 07:39:29 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 272BA21F8B3C for ; Fri, 5 Aug 2011 07:39:29 -0700 (PDT) Envelope-to: sidr@ietf.org Received: from 0x535d92a4.kjnxx10.dynamic.dsl.tele.dk ([83.93.146.164] helo=mw-PC) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QpLYv-0006nu-EW; Fri, 05 Aug 2011 16:39:45 +0200 Date: Fri, 5 Aug 2011 16:39:56 +0200 From: Matthias Waehlisch To: Randy Bush In-Reply-To: Message-ID: References: X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: sidr@ietf.org Cc: sidr wg list Subject: Re: [sidr] adopt a mib 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, 05 Aug 2011 14:39:30 -0000 On Fri, 5 Aug 2011, Randy Bush wrote: > i would request the wg adopt > > draft-ymbk-bgp-origin-validation-mib > draft-ymbk-rpki-rtr-protocol-mib > I support the adoption, as well. Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From warren@kumari.net Fri Aug 5 07:56: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 BC4E521F8C1E for ; Fri, 5 Aug 2011 07:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.357 X-Spam-Level: X-Spam-Status: No, score=-102.357 tagged_above=-999 required=5 tests=[AWL=0.242, 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 pMZNWemJDbBR for ; Fri, 5 Aug 2011 07:56:19 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 48F1B21F8C1B for ; Fri, 5 Aug 2011 07:56:19 -0700 (PDT) Received: from dhcp-172-19-118-113.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 4E4521B416C6; Fri, 5 Aug 2011 10:56:36 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Fri, 5 Aug 2011 10:56:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <799E942A-690B-45E5-9E14-143E814E46FF@kumari.net> References: To: Sandra Murphy X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] WG LC for draft-ietf-sidr-ghostbusters-06.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: Fri, 05 Aug 2011 14:56:19 -0000 Support. On Jul 13, 2011, at 7:35 PM, Sandra Murphy wrote: >=20 > The chairs have received a request from the authors for a WG Last Call = for "The RPKI Ghostbusters Record", draft-ietf-sidr-ghostbusters-06. >=20 > The document and the draft version history are available at: = http://tools.ietf.org/wg/sidr/draft-ietf-sidr-ghostbusters >=20 > The Last Call will end Wed, 3 Aug 2011 (AOE). This is three weeks = instead of the usual two, because the IETF week will occupy people's = time and attention. Yes, the IETF week did indeed occupy my (notoriously fickle) attention = and I completely forgot to weigh in before the official cutoff.=20 >=20 > As usual, please address all comments to the WG mailing list, and = please be clear in your comments to this last call if you are supporting = the document's submission to the IESG or if you are opposed. If you are = opposed, please indicate why. I am "supporting the document's submission to the IESG" -- I have read = the draft, and it addresses and obvious need.=20 Personally I would have thrown a bunch more stuff in the record, but = then it would have ended up bloated and unusable, so I support it how it = is... W >=20 > --Sandy, speaking as wg chair, with wg chair snood on Oooh, picture please?.... I lost my snood in the canal and have been = looking for a replacement, preferably one with polka dots, a miniature = short-wave radio, and a packet suitable for storing butter paddles, but = it's really hard to find a good one these days... >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From Sandra.Murphy@cobham.com Fri Aug 5 11:44: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 3D63921F8B01 for ; Fri, 5 Aug 2011 11:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.087 X-Spam-Level: X-Spam-Status: No, score=-102.087 tagged_above=-999 required=5 tests=[AWL=0.512, 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 iYdbaV8r2lAc for ; Fri, 5 Aug 2011 11:44:45 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9C65921F8AFB for ; Fri, 5 Aug 2011 11:44:45 -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 p75IivPF019657; Fri, 5 Aug 2011 13:44:57 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p75IjiiS002423; Fri, 5 Aug 2011 13:45:44 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.128]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 5 Aug 2011 14:11:02 -0400 Date: Fri, 5 Aug 2011 14:11:02 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org, Sean Turner In-Reply-To: <4E3A9A65.4010207@ieca.com> Message-ID: References: <20110802092022.13671.96567.idtracker@ietfa.amsl.com> <1C1A5E2A-1C8A-4023-B2BA-A2D340470649@cisco.com> <4E3A9A65.4010207@ieca.com> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 05 Aug 2011 18:11:02.0205 (UTC) FILETIME=[08F286D0:01CC539B] Subject: Re: [sidr] Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-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: Fri, 05 Aug 2011 18:44:46 -0000 On Thu, 4 Aug 2011, Sean Turner wrote: > On 8/3/11 8:43 PM, Randy Bush wrote: >>> The intention was to focus on the use case for the proposed changes >>> (BGPSEC certs). >> >> what is a "BGPSEC cert?" > > What Mark and I are currently proposing in > draft-turner-sidr-bgpsec-pki-profiles is that a BGPSEC certificate is a > > PS Technically, the EKU is defined in draft-turner-bpgsec-pki-profiles. It's > If the WG decides to adopt this > approach, then we'll go through the appropriate procedures to request an OID > and include it in the draft. Sean, would you like to request wg adoption for these two drafts? --Sandy From Sandra.Murphy@cobham.com Fri Aug 5 11:44: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 5B6B121F8AFB for ; Fri, 5 Aug 2011 11:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.111 X-Spam-Level: X-Spam-Status: No, score=-102.111 tagged_above=-999 required=5 tests=[AWL=0.488, 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 SCSpJYLOk-bi for ; Fri, 5 Aug 2011 11:44:45 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 99CB121F8AF0 for ; Fri, 5 Aug 2011 11:44:45 -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 p75Ij2iT019669 for ; Fri, 5 Aug 2011 13:45:02 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p75IjiiY002423 for ; Fri, 5 Aug 2011 13:45:45 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.128]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 5 Aug 2011 14:25:54 -0400 Date: Fri, 5 Aug 2011 14:25:54 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 05 Aug 2011 18:25:54.0651 (UTC) FILETIME=[1CE2FAB0:01CC539D] Subject: [sidr] wg adoption for draft-ymbk-bgp-origin-validation-mib and draft-ymbk-rpki-rtr-protocol-mib 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, 05 Aug 2011 18:44:46 -0000 The working group has been requested to adopt draft-ymbk-bgp-origin-validation-mib draft-ymbk-rpki-rtr-protocol-mib as working group drafts. As these are drafts are so similar in topic, I am running the adoption call for both simultaneously. Please respond to the list with your opinion as to whether you accept these drafts as working group drafts and are willing to work on them. 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 19 Aug 2011 Those who anticipated this call for adoption and have already responded do not need to respond again. --Sandy, speaking as wg co-chair From bertietf@bwijnen.net Fri Aug 5 12:53: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 0E15611E8070 for ; Fri, 5 Aug 2011 12:53:14 -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 Tk3Wqu+J-7SS for ; Fri, 5 Aug 2011 12:53:13 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 35AA95E8005 for ; Fri, 5 Aug 2011 12:53:11 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QpQST-0007eW-4H; Fri, 05 Aug 2011 21:53:27 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1QpQSS-00048i-U1; Fri, 05 Aug 2011 21:53:25 +0200 Message-ID: <4E3C4A34.3000503@bwijnen.net> Date: Fri, 05 Aug 2011 21:53:24 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Sandra Murphy References: In-Reply-To: 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: 86ab03e524994f79ca2c75a176445dd4ccd9023c219d4709fc7e4ce53e7eb753 Cc: sidr@ietf.org Subject: Re: [sidr] wg adoption for draft-ymbk-bgp-origin-validation-mib and draft-ymbk-rpki-rtr-protocol-mib 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, 05 Aug 2011 19:53:14 -0000 as co-editor I support to work on this. My current work seems to indicate that both drafts may even merge into one. But we'll leat the WG speak up once I am done with the edits. Bert On 8/5/11 8:25 PM, Sandra Murphy wrote: > The working group has been requested to adopt > draft-ymbk-bgp-origin-validation-mib > draft-ymbk-rpki-rtr-protocol-mib > > as working group drafts. > > As these are drafts are so similar in topic, I am running the adoption call for both simultaneously. > > Please respond to the list with your opinion as to whether you accept these drafts as working group drafts and are willing to work > on them. 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 19 Aug 2011 > > Those who anticipated this call for adoption and have already responded do not need to respond again. > > --Sandy, speaking as wg co-chair > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From turners@ieca.com Fri Aug 5 13:18:52 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 482A721F865E for ; Fri, 5 Aug 2011 13:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JYiwpHKsF8U for ; Fri, 5 Aug 2011 13:18:51 -0700 (PDT) Received: from nm3-vm0.access.bullet.mail.mud.yahoo.com (nm3-vm0.access.bullet.mail.mud.yahoo.com [66.94.237.136]) by ietfa.amsl.com (Postfix) with SMTP id BB7E521F865B for ; Fri, 5 Aug 2011 13:18:51 -0700 (PDT) Received: from [66.94.237.200] by nm3.access.bullet.mail.mud.yahoo.com with NNFMP; 05 Aug 2011 20:19:10 -0000 Received: from [98.139.221.63] by tm11.access.bullet.mail.mud.yahoo.com with NNFMP; 05 Aug 2011 20:19:10 -0000 Received: from [127.0.0.1] by smtp104.biz.mail.bf1.yahoo.com with NNFMP; 05 Aug 2011 20:19:10 -0000 X-Yahoo-Newman-Id: 30899.36879.bm@smtp104.biz.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: VMBIx8EVM1nl6RydGbwqXCP7bUH31D5OqEis3a5wzoab._B xlrjGxH51mGO.Zds7.0FilTuuecBsXpQbvE0mg2xqxNw1mFke9LSG0Lp5Dc6 cejmnAjw7HribtYT6PnYU6rspL1eEVP9NY_aucwriR1HyEoXAojXVpSps2zk 8r87Y9nMoarf6HqMnhyg.98FGztkV9ataKon5Bs2ieKrNME_m3E0v6yBStGL z4uc86M9FNoiYuWvjVd4oR1Gs.cv9KaOu41m90XPsfZKy89yfKKYaZn51JqQ vvwOJqGepXZVXbw3OrsD5FW2Ab01iaqbLMFFOHYbmuef9kAx.aqZYuzzxsXb e4biOQnYrQhDgKZfaUY_85Zj0WjHSbkKKU9mzEAWzBbOMrN28I7XFYEA94Ny PguxVMaaOQFDsoOkfPgnhqc1M58pZ619jJiRyey0zbwdOlR7yDsBnrURKZ9l aZ8iEHGCbHOQksy.emc5WaNy2mZlWn3KhJJlcTvBoG3xNJtud6TA0molYnH4 dUy5hP18- X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from thunderfish.westell.com (turners@96.231.124.70 with plain) by smtp104.biz.mail.bf1.yahoo.com with SMTP; 05 Aug 2011 13:19:09 -0700 PDT Message-ID: <4E3C503D.2050004@ieca.com> Date: Fri, 05 Aug 2011 16:19:09 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Sandra Murphy References: <20110802092022.13671.96567.idtracker@ietfa.amsl.com> <1C1A5E2A-1C8A-4023-B2BA-A2D340470649@cisco.com> <4E3A9A65.4010207@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-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: Fri, 05 Aug 2011 20:18:52 -0000 On 8/5/11 2:11 PM, Sandra Murphy wrote: > > > On Thu, 4 Aug 2011, Sean Turner wrote: > >> On 8/3/11 8:43 PM, Randy Bush wrote: >>>> The intention was to focus on the use case for the proposed changes >>>> (BGPSEC certs). >>> >>> what is a "BGPSEC cert?" >> >> What Mark and I are currently proposing in >> draft-turner-sidr-bgpsec-pki-profiles is that a BGPSEC certificate is a > > > >> >> PS Technically, the EKU is defined in >> draft-turner-bpgsec-pki-profiles. It's > > > >> If the WG decides to adopt this approach, then we'll go through the >> appropriate procedures to request an OID and include it in the draft. > > Sean, would you like to request wg adoption for these two drafts? Yes I would like the wg to consider adoption of: http://datatracker.ietf.org/doc/draft-turner-sidr-bgpsec-pki-profiles/ http://datatracker.ietf.org/doc/draft-turner-sidr-bgpsec-algs/ as the starting point for certificates and algorithms for BGPSEC. spt From randy@psg.com Fri Aug 5 13:22: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 706C221F8B8D for ; Fri, 5 Aug 2011 13:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 woPQIYK5jei1 for ; Fri, 5 Aug 2011 13:22:29 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id D80DC21F8B7E for ; Fri, 5 Aug 2011 13:22:28 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QpQur-000Npg-Sp; Fri, 05 Aug 2011 20:22:46 +0000 Date: Sat, 06 Aug 2011 05:22:44 +0900 Message-ID: From: Randy Bush To: Sean Turner In-Reply-To: <4E3C503D.2050004@ieca.com> References: <20110802092022.13671.96567.idtracker@ietfa.amsl.com> <1C1A5E2A-1C8A-4023-B2BA-A2D340470649@cisco.com> <4E3A9A65.4010207@ieca.com> <4E3C503D.2050004@ieca.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] Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-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: Fri, 05 Aug 2011 20:22:29 -0000 > Yes I would like the wg to consider adoption of: > > http://datatracker.ietf.org/doc/draft-turner-sidr-bgpsec-pki-profiles/ > http://datatracker.ietf.org/doc/draft-turner-sidr-bgpsec-algs/ they seem well within the scope of the wg's work. i support adoption. randy, who confesses to have skimmed more than read deeply From warren@kumari.net Fri Aug 5 14:24: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 5A48F21F8A7E for ; Fri, 5 Aug 2011 14:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 fpx7RlwlmUPf for ; Fri, 5 Aug 2011 14:24:35 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id A711421F8A66 for ; Fri, 5 Aug 2011 14:24:35 -0700 (PDT) Received: from dhcp-172-19-118-113.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 666541B405C3; Fri, 5 Aug 2011 17:24:48 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Fri, 5 Aug 2011 17:24:45 -0400 Content-Transfer-Encoding: 7bit Message-Id: <4DA3E136-D417-4810-946B-F1E83626FD46@kumari.net> References: <20110802092022.13671.96567.idtracker@ietfa.amsl.com> <1C1A5E2A-1C8A-4023-B2BA-A2D340470649@cisco.com> <4E3A9A65.4010207@ieca.com> <4E3C503D.2050004@ieca.com> To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-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: Fri, 05 Aug 2011 21:24:36 -0000 On Aug 5, 2011, at 4:22 PM, Randy Bush wrote: >> Yes I would like the wg to consider adoption of: >> >> http://datatracker.ietf.org/doc/draft-turner-sidr-bgpsec-pki-profiles/ >> http://datatracker.ietf.org/doc/draft-turner-sidr-bgpsec-algs/ > > they seem well within the scope of the wg's work. i support adoption. Support. > > randy, who confesses to have skimmed more than read deeply Warren, who actually read many of the words (before getting sidetracked). > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From aservin@lacnic.net Sat Aug 6 08:42: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 C768A21F85E3 for ; Sat, 6 Aug 2011 08:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.358 X-Spam-Level: X-Spam-Status: No, score=0.358 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_DIALUP=0.862, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GJ38FFUyjjl for ; Sat, 6 Aug 2011 08:42:43 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 990DC21F85CE for ; Sat, 6 Aug 2011 08:42:42 -0700 (PDT) Received: from [192.168.1.102] (r186-48-217-161.dialup.adsl.anteldata.net.uy [186.48.217.161]) by mail.lacnic.net.uy (Postfix) with ESMTP id 85F57308447 for ; Sat, 6 Aug 2011 12:42:50 -0300 (UYT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Arturo Servin In-Reply-To: Date: Sat, 6 Aug 2011 12:42:49 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <823D382E-CEEC-419B-B80C-3B09F957BA21@lacnic.net> References: To: sidr wg list X-Mailer: Apple Mail (2.1084) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [sidr] adopt a mib 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: Sat, 06 Aug 2011 15:42:43 -0000 Support. Some comments. Roque previously mentioned something similar, for me it's a bit = confusing to talk about ROAs validity in a router. In my mind ROAs are = validated somewhere else and in routers you search for the validity of a = prefix which I think what is referenced here. Also, as Robert Raszuk mentioned I am a bit concerned that in = order to get the validity of a prefix first I need to get a table with = ~400k entries. I do not normally get a full table BGP via SNMP so may be = my concern is unjustified by my lack of experience. May be is it just = the way it is with SNMP and we need to live with it. Cheers, -as On 5 Aug 2011, at 11:39, Matthias Waehlisch wrote: >=20 > On Fri, 5 Aug 2011, Randy Bush wrote: >=20 >> i would request the wg adopt >>=20 >> draft-ymbk-bgp-origin-validation-mib >> draft-ymbk-rpki-rtr-protocol-mib >>=20 >=20 > I support the adoption, as well. >=20 >=20 > Cheers > matthias >=20 > --=20 > Matthias Waehlisch > . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST > . Takustr. 9, D-14195 Berlin, Germany > .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl > :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From carlosm3011@gmail.com Sun Aug 7 22:08: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 05A5D21F8A4B for ; Sun, 7 Aug 2011 22:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oo4lmfwqp2PD for ; Sun, 7 Aug 2011 22:08:09 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D7E4D21F89A7 for ; Sun, 7 Aug 2011 22:08:08 -0700 (PDT) Received: by ewy19 with SMTP id 19so795503ewy.31 for ; Sun, 07 Aug 2011 22:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=ZMzcbDxpIMpFnAMMEWr2ymDQLT2Leg3ngV0ldpsbG2c=; b=NrIY6gk0DHTujPvTKQnP3KlHozpXsqWiOB+aPtGcA/8NgTXr7qmrnNU2lXQGPezms5 zVsGYxJ7btG/nw2w6cAVEQSjEh2xCeyT/KyXl5agTsw4VvFQWyOEtR8+pUmPCcsX+hN3 Z+DR/r+lNCJOxreMFO4a+Jp/wWcYvINjq0OtM= MIME-Version: 1.0 Received: by 10.14.9.196 with SMTP id 44mr1354069eet.122.1312780112632; Sun, 07 Aug 2011 22:08:32 -0700 (PDT) Received: by 10.14.45.4 with HTTP; Sun, 7 Aug 2011 22:08:32 -0700 (PDT) In-Reply-To: <823D382E-CEEC-419B-B80C-3B09F957BA21@lacnic.net> References: <823D382E-CEEC-419B-B80C-3B09F957BA21@lacnic.net> Date: Mon, 8 Aug 2011 05:08:32 +0000 Message-ID: From: Carlos Martinez-Cagnazzo To: Arturo Servin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] adopt a mib X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 05:08:10 -0000 I agree that some additional indexes in the tables may be needed, to avoid the situation described by Arturo. regards, Carlos On Sat, Aug 6, 2011 at 3:42 PM, Arturo Servin wrote: > > =A0 =A0 =A0 =A0Support. > > =A0 =A0 =A0 =A0Some comments. > > =A0 =A0 =A0 =A0Roque previously mentioned something similar, for me it's = a bit confusing to talk about ROAs validity in a router. In my mind ROAs ar= e validated somewhere else and in routers you search for the validity of a = prefix which I think what is referenced here. > > =A0 =A0 =A0 =A0Also, as Robert Raszuk mentioned I am a bit concerned that= in order to get the validity of a prefix first I need to get a table with = ~400k entries. I do not normally get a full table BGP via SNMP so may be my= concern is unjustified by my lack of experience. May be is it just the way= it is with SNMP and we need to live with it. > > Cheers, > -as > > > On 5 Aug 2011, at 11:39, Matthias Waehlisch wrote: > >> >> On Fri, 5 Aug 2011, Randy Bush wrote: >> >>> i would request the wg adopt >>> >>> =A0 =A0draft-ymbk-bgp-origin-validation-mib >>> =A0 =A0draft-ymbk-rpki-rtr-protocol-mib >>> >> >> I support the adoption, as well. >> >> >> Cheers >> =A0matthias >> >> -- >> Matthias Waehlisch >> . =A0Freie Universitaet Berlin, Inst. fuer Informatik, AG CST >> . =A0Takustr. 9, D-14195 Berlin, Germany >> .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl >> :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --=20 -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From randy@psg.com Sun Aug 7 22:16: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 3376C21F8A23 for ; Sun, 7 Aug 2011 22:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fgo1Zv-j1Xq6 for ; Sun, 7 Aug 2011 22:16:06 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id D7B3221F8A1A for ; Sun, 7 Aug 2011 22:16:06 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QqICR-000Cbg-Om; Mon, 08 Aug 2011 05:16:28 +0000 Date: Mon, 08 Aug 2011 14:16:26 +0900 Message-ID: From: Randy Bush To: Carlos Martinez-Cagnazzo In-Reply-To: References: <823D382E-CEEC-419B-B80C-3B09F957BA21@lacnic.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] adopt a mib 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, 08 Aug 2011 05:16:07 -0000 > I agree that some additional indexes in the tables may be needed, to > avoid the situation described by Arturo. yep. exactly what bert was doing when he left for holiday. randy From ietfc@btconnect.com Mon Aug 8 02:14: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 9F4ED21F84F8 for ; Mon, 8 Aug 2011 02:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=0.530, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yW4oNCUR2m4Q for ; Mon, 8 Aug 2011 02:14:54 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr08.btconnect.com [213.123.26.186]) by ietfa.amsl.com (Postfix) with ESMTP id 8373221F85AA for ; Mon, 8 Aug 2011 02:14:52 -0700 (PDT) Received: from host81-159-99-55.range81-159.btcentralplus.com (HELO pc6) ([81.159.99.55]) by c2beaomr08.btconnect.com with SMTP id DVR73876; Mon, 08 Aug 2011 10:15:11 +0100 (BST) Message-ID: <018a01cc55a2$d54a9700$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Arturo Servin" , "sidr wg list" References: <823D382E-CEEC-419B-B80C-3B09F957BA21@lacnic.net> Date: Mon, 8 Aug 2011 10:11:47 +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.4E3FA91F.0033, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.8.8.75715:17:7.586, ip=81.159.99.55, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __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, 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=c2beaomr08.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0203.4E3FA921.0264,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] adopt a mib 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, 08 Aug 2011 09:14:55 -0000 ----- Original Message ----- From: "Arturo Servin" To: "sidr wg list" Sent: Saturday, August 06, 2011 5:42 PM > > Support. > > Some comments. > > Roque previously mentioned something similar, for me it's a bit confusing to talk about ROAs validity in a router. In my mind ROAs are validated somewhere else and in routers you search for the validity of a prefix which I think what is referenced here. > > Also, as Robert Raszuk mentioned I am a bit concerned that in order to get the validity of a prefix first I need to get a table with ~400k entries. I do not normally get a full table BGP via SNMP so may be my concern is unjustified by my lack of experience. May be is it just the way it is with SNMP and we need to live with it. The way with SNMPv1, long superseded, but still around, is to get table entries one at a time, and if the table is dynamic, this process may never end - I once set such a retrieval going (on statistics data rather than routing) and cancelled it three days later, still incomplete (a good way of stress testing router control planes:-) SNMPv2 has a smarter way of bulk data retrieval but it depends on having the right table structure, that is it can efficiently retrieve a slice through some of the columns. If you have thousands of rows, most with property X and a few with property Y, then it should work well if X/Y is an index to a column and Y collates after X, that is what you want is at the bottom of the column (since the retrieval works down a column and ends at the end of the column [RFC3416]). But you can still be sabotaged by considerations of maximum PDU so for me, accessing large tables remains troublesome:-( Tom Petch > > Cheers, > -as > > > On 5 Aug 2011, at 11:39, Matthias Waehlisch wrote: > > > > > On Fri, 5 Aug 2011, Randy Bush wrote: > > > >> i would request the wg adopt > >> > >> draft-ymbk-bgp-origin-validation-mib > >> draft-ymbk-rpki-rtr-protocol-mib > >> > > > > I support the adoption, as well. > > > > > > Cheers > > matthias > > > > -- > > Matthias Waehlisch > > . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST > > . Takustr. 9, D-14195 Berlin, Germany > > .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl > > :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From warren@kumari.net Mon Aug 8 10:11:58 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 EB4E821F86D7 for ; Mon, 8 Aug 2011 10:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zx4K6tmDEc14 for ; Mon, 8 Aug 2011 10:11:58 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 7649421F8793 for ; Mon, 8 Aug 2011 10:11:58 -0700 (PDT) Received: from [5.5.0.3] (vpn.snozzages.com [204.194.22.7]) by vimes.kumari.net (Postfix) with ESMTPSA id 4576F1B40A8D; Mon, 8 Aug 2011 13:12:24 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: Date: Mon, 8 Aug 2011 10:12:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6DAE0A36-336C-4638-8B1B-69AA18B5E615@kumari.net> References: To: Sandra Murphy X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: Re: [sidr] wg adoption for draft-ymbk-bgp-origin-validation-mib and draft-ymbk-rpki-rtr-protocol-mib 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, 08 Aug 2011 17:11:59 -0000 On Aug 5, 2011, at 11:25 AM, Sandra Murphy wrote: > The working group has been requested to adopt > draft-ymbk-bgp-origin-validation-mib Support. > draft-ymbk-rpki-rtr-protocol-mib Support. I am willing to review and provide input, but am by no means a MIB = monkey, and so my review will be limited to content, not syntax=85 W >=20 > as working group drafts. >=20 > As these are drafts are so similar in topic, I am running the adoption = call for both simultaneously. >=20 > Please respond to the list with your opinion as to whether you accept = these drafts as working group drafts and are willing to work on them. = 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 19 Aug 2011 >=20 > Those who anticipated this call for adoption and have already = responded do not need to respond again. >=20 > --Sandy, speaking as wg co-chair >=20 >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From baerm@mikesoffice.com Mon Aug 8 11:31: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 7198121F8BA4 for ; Mon, 8 Aug 2011 11:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtsQJdTh13Uu for ; Mon, 8 Aug 2011 11:31:25 -0700 (PDT) Received: from mail.mikesoffice.com (v6.mikesoffice.com [IPv6:2001:470:1f05:274::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D40C21F8B8F for ; Mon, 8 Aug 2011 11:31:21 -0700 (PDT) Received: from localhost (rebma.ipv6.mikesoffice.com [IPv6:2001:470:1f05:274:d69a:20ff:feb8:b0b2]) by mail.mikesoffice.com (Postfix) with ESMTPSA id 84AF19DBFC; Mon, 8 Aug 2011 11:31:47 -0700 (PDT) From: Michael Baer To: raszuk@cisco.com References: <4E3B8930.9090605@cisco.com> <4E3B8EB1.7030007@bwijnen.net> <4E3B9018.80808@cisco.com> X-Face: "*g#dUT3; 8M9AE5dLk\\b4G\cNCQkRb.g/2QwEXQKf.: (Robert Raszuk's message of "Thu, 04 Aug 2011 23:39:20 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: sidr wg list Subject: Re: [sidr] adopt a mib 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, 08 Aug 2011 18:31:26 -0000 >>>>> On Thu, 04 Aug 2011 23:39:20 -0700, Robert Raszuk said: Robert> Hi Bert, Robert> Many thx for your comment .. I was not able to stay at the IETF till Robert> the SIDR session. Robert> If that is the case the draft-ymbk-bgp-origin-validation-mib is just Robert> completely not ready for adoption until it contains bare minimum which Robert> will allow operators to use it. Robert> It would be insane to list 1 million of valid prefixes as opposed to Robert> little fraction of them being in question. Whoever authored that draft Robert> needs to develop a bit more real network operational experience :) Hi Robert, I am co-editing the MIB and was the person that originally put most of the MIB into SMI form. Major flaws in the original MIB design are going to be mostly due to me. My SNMP background is much greater than my routing knowledge, and I'm sure it shows (not shockingly, no network operator experience). I expected and hoped to get feedback on what was wrong with the MIB and how it could be improved. I do look at WG at adoption criteria differently. I can see your point of view. But I generally look on adoption as whether a document/MIB is useful, and appropriate for a particular WG and not whether the first version of the doc/MIB is ready, with just minor adjustment, to be coded and used. But regardless of WG adoption, I am curious whether you think these MIBs would be useful to have, not in the current state, but in a closer to ideal state? And please give as much feedback as you can, Thanks, Mike Robert> Best regards, Robert> R. >> During the discussion at the SIDR WG session at IETF81 we >> found that the bgpVRTValid attribute in that table makes no >> sense, because we do not have that info. These are ALL >> validated ROAs (or better validated prefixes) as I understand >> it. >> >> Bert >> On 8/5/11 8:09 AM, Robert Raszuk wrote: >>> Hi, >>> >>> Just looking at draft-ymbk-bgp-origin-validation-mib may I ask what >>> would be the root OID string to start SNMP tree walk (or set the trap) >>> to list all INVALID or NOT_FOUND BGP entries ? >>> >>> Rgs, >>> R. Robert> _______________________________________________ Robert> sidr mailing list Robert> sidr@ietf.org Robert> https://www.ietf.org/mailman/listinfo/sidr -- Michael Baer baerm@mikesoffice.com From baerm@mikesoffice.com Mon Aug 8 11:33:16 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 8ED7421F8BA2 for ; Mon, 8 Aug 2011 11:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSUqWja8VJ92 for ; Mon, 8 Aug 2011 11:33:16 -0700 (PDT) Received: from mail.mikesoffice.com (v6.mikesoffice.com [IPv6:2001:470:1f05:274::1]) by ietfa.amsl.com (Postfix) with ESMTP id 088B921F84E6 for ; Mon, 8 Aug 2011 11:33:16 -0700 (PDT) Received: from localhost (rebma.ipv6.mikesoffice.com [IPv6:2001:470:1f05:274:d69a:20ff:feb8:b0b2]) by mail.mikesoffice.com (Postfix) with ESMTPSA id 7B0F89DBFC; Mon, 8 Aug 2011 11:33:42 -0700 (PDT) From: Michael Baer To: Sandra Murphy References: X-Face: "*g#dUT3; 8M9AE5dLk\\b4G\cNCQkRb.g/2QwEXQKf.: (Sandra Murphy's message of "Fri, 5 Aug 2011 14:25:54 -0400 (Eastern Daylight Time)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: sidr@ietf.org Subject: Re: [sidr] wg adoption for draft-ymbk-bgp-origin-validation-mib and draft-ymbk-rpki-rtr-protocol-mib 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, 08 Aug 2011 18:33:16 -0000 >>>>> On Fri, 5 Aug 2011 14:25:54 -0400 (Eastern Daylight Time), Sandra Murphy said: Sandra> The working group has been requested to adopt Sandra> draft-ymbk-bgp-origin-validation-mib Sandra> draft-ymbk-rpki-rtr-protocol-mib Sandra> as working group drafts. Sandra> As these are drafts are so similar in topic, I am running the adoption Sandra> call for both simultaneously. Sandra> Please respond to the list with your opinion as to whether you accept Sandra> these drafts as working group drafts and are willing to work on Sandra> them. Remember that you do not need to accept all content in a draft Sandra> to adopt, as draft editors are required to reflect the consensus of Sandra> the working group. I support adoption of both (and am co-editing) Sandra> This call will end 19 Aug 2011 Sandra> Those who anticipated this call for adoption and have already Sandra> responded do not need to respond again. Sandra> --Sandy, speaking as wg co-chair Sandra> _______________________________________________ Sandra> sidr mailing list Sandra> sidr@ietf.org Sandra> https://www.ietf.org/mailman/listinfo/sidr -- Michael Baer baerm@mikesoffice.com From raszuk@cisco.com Mon Aug 8 12:59: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 866DF11E80A8 for ; Mon, 8 Aug 2011 12:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.128 X-Spam-Level: X-Spam-Status: No, score=-3.128 tagged_above=-999 required=5 tests=[AWL=-0.529, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgD-c3TMJiQs for ; Mon, 8 Aug 2011 12:59:09 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A925C11E80A7 for ; Mon, 8 Aug 2011 12:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=3265; q=dns/txt; s=iport; t=1312833576; x=1314043176; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=y5SsPhmJ90ndGHFQyn8+WloeRQg8XQDBm2fUWMsvvd0=; b=QcsGnSAWzF4AiQEVdgOW+hsYFMS9pz09qhlJnF+UCctvQnmZc4MaOYJ8 KHqei7b2/GWgB52CZ2co26oQP3R2Rt/dBlCTRU4kzmJGFSo6t8NuXN4OQ HaLm3Mivfx5LHjvoJzCwO/YNE3PkmQ39BfNlmZVXjHhvO61hTHsqjPKGr U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACs/QE6rRDoI/2dsb2JhbABDpyd3gUABAQEBAwEBAQ8BAgEiNgoBEAsYCRYPCQMCAQIBFTAGDQEFAgEBHodPoAgBgxwPAZtAhkcEkwKFCIti X-IronPort-AV: E=Sophos;i="4.67,338,1309737600"; d="scan'208";a="10957743" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-1.cisco.com with ESMTP; 08 Aug 2011 19:59:35 +0000 Received: from [192.168.1.68] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p78JxWtg010755; Mon, 8 Aug 2011 19:59:33 GMT Message-ID: <4E404043.7080004@cisco.com> Date: Mon, 08 Aug 2011 22:00:03 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Michael Baer References: <4E3B8930.9090605@cisco.com> <4E3B8EB1.7030007@bwijnen.net> <4E3B9018.80808@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: robert@raszuk.net, sidr wg list Subject: Re: [sidr] adopt a mib 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: Mon, 08 Aug 2011 19:59:10 -0000 Hello Michael, By all means this MIB extension is useful and I do support it's adoption. I was only suggesting to perhaps wait just a bit and adopt something which we do already know will be needed in this MIB to avoid next rev just few days after the adoption and save authors of this MIB another submission cycle :) But You, Bert and Randy are so ready and open to continue enhancing it I see no show-stopper. Once I will see new rev (regardless if this is WG item already or not yet) I will take a look again and provide my comments (if any are needed then :). Many thx, R. >>>>>> On Thu, 04 Aug 2011 23:39:20 -0700, Robert Raszuk said: > > Robert> Hi Bert, > Robert> Many thx for your comment .. I was not able to stay at the IETF till > Robert> the SIDR session. > > Robert> If that is the case the draft-ymbk-bgp-origin-validation-mib is just > Robert> completely not ready for adoption until it contains bare minimum which > Robert> will allow operators to use it. > > Robert> It would be insane to list 1 million of valid prefixes as opposed to > Robert> little fraction of them being in question. Whoever authored that draft > Robert> needs to develop a bit more real network operational experience :) > > Hi Robert, > > I am co-editing the MIB and was the person that originally put most of > the MIB into SMI form. Major flaws in the original MIB design are going > to be mostly due to me. My SNMP background is much greater than my > routing knowledge, and I'm sure it shows (not shockingly, no network > operator experience). I expected and hoped to get feedback on what was > wrong with the MIB and how it could be improved. > > I do look at WG at adoption criteria differently. I can see your point > of view. But I generally look on adoption as whether a document/MIB is > useful, and appropriate for a particular WG and not whether the first > version of the doc/MIB is ready, with just minor adjustment, to be coded > and used. > > But regardless of WG adoption, I am curious whether you think these MIBs > would be useful to have, not in the current state, but in a closer to > ideal state? > > And please give as much feedback as you can, > > Thanks, > Mike > > > Robert> Best regards, > Robert> R. > > >> During the discussion at the SIDR WG session at IETF81 we > >> found that the bgpVRTValid attribute in that table makes no > >> sense, because we do not have that info. These are ALL > >> validated ROAs (or better validated prefixes) as I understand > >> it. > >> > >> Bert > >> On 8/5/11 8:09 AM, Robert Raszuk wrote: > >>> Hi, > >>> > >>> Just looking at draft-ymbk-bgp-origin-validation-mib may I ask what > >>> would be the root OID string to start SNMP tree walk (or set the trap) > >>> to list all INVALID or NOT_FOUND BGP entries ? > >>> > >>> Rgs, > >>> R. > > > Robert> _______________________________________________ > Robert> sidr mailing list > Robert> sidr@ietf.org > Robert> https://www.ietf.org/mailman/listinfo/sidr > > From rogaglia@cisco.com Tue Aug 9 08:58: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 086B821F8C16 for ; Tue, 9 Aug 2011 08:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EatuB2maqkMl for ; Tue, 9 Aug 2011 08:58:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id BB55C21F8B81 for ; Tue, 9 Aug 2011 08:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=8247; q=dns/txt; s=iport; t=1312905561; x=1314115161; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=Mx6BVrJmbzqSEC3tgmpllMKtBLgAMvQDTJEregIZNN8=; b=AgIkZu58vFfHQR2SYAW9Sz4zIa0abuvYs67h3tbWZZ47WwdlQ9nGIkj4 LPAmBUrWVa/1ZWTd6/Wwf39qMP7rRBmIKLvdmw75ddt3iD0hNPaoePocI fUGnTJgbTbA47ai0r6jLosToPuXotP4zywUrXILaWH9VZZti/lCogIeVF M=; X-Files: smime.p7s : 4389 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGtYQU6Q/khR/2dsb2JhbABCpz53gUABAQEBAgEBAQEPAVsJAgULCxguAiUwBhMih0sEoB4Bnm+FZ18EkwWQbQ X-IronPort-AV: E=Sophos;i="4.67,344,1309737600"; d="p7s'?scan'208";a="108450394" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 09 Aug 2011 15:59:20 +0000 Received: from dhcp-10-61-97-252.cisco.com (dhcp-10-61-97-252.cisco.com [10.61.97.252]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p79FxJvp010751; Tue, 9 Aug 2011 15:59:19 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-1845--409089361; protocol="application/pkcs7-signature"; micalg=sha1 From: Roque Gagliano In-Reply-To: <4E3C503D.2050004@ieca.com> Date: Tue, 9 Aug 2011 17:59:18 +0200 Message-Id: References: <20110802092022.13671.96567.idtracker@ietfa.amsl.com> <1C1A5E2A-1C8A-4023-B2BA-A2D340470649@cisco.com> <4E3A9A65.4010207@ieca.com> <4E3C503D.2050004@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1084) Cc: Sandra Murphy , sidr@ietf.org Subject: Re: [sidr] Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-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: Tue, 09 Aug 2011 15:58:53 -0000 --Apple-Mail-1845--409089361 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sean, In Section 3.3 of = http://datatracker.ietf.org/doc/draft-turner-sidr-bgpsec-pki-profiles/, = you are missing to mention that one of the difference from = draft-ietf-sidr-res-cert-profile is that your document refers a = different algorithm suite document. Consequently, a BGPSEC certificate = will not validate draft-ietf-res-cert-profile, as long as the two = algorithm suites are different, correct? If that is the case, I believe = you should clarify it and probably remove the references that the new = profile is consistent with draft-ietf-sidr-res-cert-profile = certificates. Roque On Aug 5, 2011, at 10:19 PM, Sean Turner wrote: > On 8/5/11 2:11 PM, Sandra Murphy wrote: >>=20 >>=20 >> On Thu, 4 Aug 2011, Sean Turner wrote: >>=20 >>> On 8/3/11 8:43 PM, Randy Bush wrote: >>>>> The intention was to focus on the use case for the proposed = changes >>>>> (BGPSEC certs). >>>>=20 >>>> what is a "BGPSEC cert?" >>>=20 >>> What Mark and I are currently proposing in >>> draft-turner-sidr-bgpsec-pki-profiles is that a BGPSEC certificate = is a >>=20 >> >>=20 >>>=20 >>> PS Technically, the EKU is defined in >>> draft-turner-bpgsec-pki-profiles. It's >>=20 >> >>=20 >>> If the WG decides to adopt this approach, then we'll go through the >>> appropriate procedures to request an OID and include it in the = draft. >>=20 >> Sean, would you like to request wg adoption for these two drafts? >=20 > Yes I would like the wg to consider adoption of: >=20 > http://datatracker.ietf.org/doc/draft-turner-sidr-bgpsec-pki-profiles/ > http://datatracker.ietf.org/doc/draft-turner-sidr-bgpsec-algs/ >=20 > as the starting point for certificates and algorithms for BGPSEC. >=20 > spt > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-1845--409089361 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXDCCBWYw ggROoAMCAQICEFyqcUyRFrhvN5s0SHw/EO4wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA1MTAwMDAwMDBaFw0x MjA1MTEyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5Sb3F1ZSBHYWdsaWFubzEhMB8GCSqGSIb3DQEJARYScm9nYWdsaWFAY2lz Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxIp28SUiJ/fiFYD/Nct8MUbG WJuPqSnhkfBYMFbbWfDDrHR8OXzK2LkWIuHY5aeAo1nalAQCO40oeTYt0cp9W++a7USNCEDQzgVN Rg0YMYL27YSQoVJnecO3u9wi0jjwhJGblWWxphaztdaMbqiChgND1PHqf7dcs4UjeUOhhKFk0/61 mTmduV721jrxj6ABIlUHAc7nXhKANtDbKdBZzEhM4dbzp6STKq65EQ3xRLVFIuapTgNVckvXtc1e Cyu4xLOLZgaD2aLq9JzBn9y/rFRMtf2euP/Nmzl7QRjAUjpPdo1n6NXWGDtNyR0lUrcJ/x1leccZ Gfj0eaqe+tpJmQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAG A1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29t L0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAsvqKrlga/tU0vyBtnBOj 4miDAZxou0/fN2wVEK7dRLzIQLYEJD35sELVhiP8v8wVHtgOeVHz9FyBEVqXmJ0RKy4kMC7gdQxj +t1MlqSTDShEaPMmiwaK6M1iJ9jpBL4JvoiirpHnQYGukkgvTUeqITWZ5ecg03nB3QHuab91Gc+n RZ1OKL4D4p5IkvzWhRlIAlxW9yGZyB8r9V6iu3+1SYEpPPUN3AYCxXeXrn8fJjkOoEodybRiGyfW pMpShpTZg2tHB7ZX162Ti3sRvwA2mktDMnBtEm1pXo15z7yieDUPmjVybMA4byV7AQcbIrjQj0eq c/biBsueC2KWoJY7TDCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEF BQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBG b3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5 MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwT j+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliW B6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGce dAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69s sQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOM Wev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0 cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtg hkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoG CCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCeg JYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4G CCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNV HREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN 7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqT OtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih /1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0D uFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRIfD8Q7jAJBgUr DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4 MDkxNTU5MjBaMCMGCSqGSIb3DQEJBDEWBBQ9AnVWyB64+pZTYDa+9iY/cnoY+jCCAQMGCSsGAQQB gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBcqnFMkRa4bzebNEh8PxDuMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRI fD8Q7jANBgkqhkiG9w0BAQEFAASCAQDBxkntrpHYXe8ADFUs2KS5DB6iokw0WSiOxJdtUuqTGcs5 dUHk92sgzQGI3InBzIClFSC1w2MH3jdeij9grv1Ogj37jSjqNZaovCFEp8l1Zzka2g75o1DvY7yZ M3Hxgjj7HGPTKRK4s3j45cE7/DYvdKKUqOs8jGDg22Nip8TGopRJSGXAoIcJo/qztVR9ZhnbPjhj 2+wNhxg/VU6FNsa9L11diXw3c3t1BZk33fUboNDQGIMBDg4mf5xmo7IhdM57AuDj06roZcGI5Gmz LM2fS0aka+JVbZ0glOrnJX1jYgS+Ar0sPX2nnaUOv2OhYb1f/dAhPd+RvYmfknxw1k50AAAAAAAA --Apple-Mail-1845--409089361-- From Sandra.Murphy@cobham.com Tue Aug 9 13:46:41 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 3AF8421F8C95 for ; Tue, 9 Aug 2011 13:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.133 X-Spam-Level: X-Spam-Status: No, score=-102.133 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKwkdU0xK75f for ; Tue, 9 Aug 2011 13:46:40 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB8A21F8C92 for ; Tue, 9 Aug 2011 13:46:39 -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 p79Kl6UM022004 for ; Tue, 9 Aug 2011 15:47:06 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p79Kl6N5029270 for ; Tue, 9 Aug 2011 15:47:07 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.128]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 16:47:06 -0400 Date: Tue, 9 Aug 2011 16:47:05 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 09 Aug 2011 20:47:06.0527 (UTC) FILETIME=[802BAAF0:01CC56D5] Subject: [sidr] call for wg adoption of draft-turner-sidr-bgpsec-algs 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, 09 Aug 2011 20:46:41 -0000 The working group has been requested to adopt draft-turner-sidr-bgpsec-algs as a working group draft. The draft is available at http://tools.ietf.org/html/draft-turner-sidr-bgpsec-algs Please respond to the list to say 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 23 Aug 2011 --Sandy, speaking as wg co-chair From Sandra.Murphy@cobham.com Tue Aug 9 13:47: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 BFF4F21F874E for ; Tue, 9 Aug 2011 13:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.153 X-Spam-Level: X-Spam-Status: No, score=-102.153 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcwwIWR3qelB for ; Tue, 9 Aug 2011 13:47:08 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0D321F86D8 for ; Tue, 9 Aug 2011 13:47:08 -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 p79Klbfk022008 for ; Tue, 9 Aug 2011 15:47:37 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p79Klaxo029293 for ; Tue, 9 Aug 2011 15:47:36 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.128]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 16:47:15 -0400 Date: Tue, 9 Aug 2011 16:47:14 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 09 Aug 2011 20:47:15.0402 (UTC) FILETIME=[8575E2A0:01CC56D5] Subject: [sidr] call for wg adoption of draft-turner-sidr-bgpsec-pki-profiles 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, 09 Aug 2011 20:47:08 -0000 The working group has been requested to adopt draft-turner-sidr-bgpsec-pki-profiles as a working group draft. The draft is available at http://tools.ietf.org/html/draft-turner-sidr-bgpsec-pki-profiles Please respond to the list to say 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 23 Aug 2011 --Sandy, speaking as wg co-chair From randy@psg.com Tue Aug 9 15:57: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 702A611E808B for ; Tue, 9 Aug 2011 15:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noYCtOj+7Ec2 for ; Tue, 9 Aug 2011 15:57:34 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 20F5611E8070 for ; Tue, 9 Aug 2011 15:57:34 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QqvFK-0005WB-S5; Tue, 09 Aug 2011 22:58:03 +0000 Date: Wed, 10 Aug 2011 07:58:01 +0900 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: References: 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] call for wg adoption of draft-turner-sidr-bgpsec-algs 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, 09 Aug 2011 22:57:34 -0000 > The working group has been requested to adopt > draft-turner-sidr-bgpsec-algs as a working group draft. have read. support. randy From randy@psg.com Tue Aug 9 16:01: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 E524A11E809E for ; Tue, 9 Aug 2011 16:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAylAIRDiNv2 for ; Tue, 9 Aug 2011 16:01:03 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 9A01811E8070 for ; Tue, 9 Aug 2011 16:01:03 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QqvIj-0005Wq-7j; Tue, 09 Aug 2011 23:01:33 +0000 Date: Wed, 10 Aug 2011 08:01:32 +0900 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: References: 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] call for wg adoption of draft-turner-sidr-bgpsec-pki-profiles 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, 09 Aug 2011 23:01:04 -0000 > The working group has been requested to adopt > draft-turner-sidr-bgpsec-pki-profiles as a working group draft. have read. support as wg item. will take up my confusions with author. randy From internet-drafts@ietf.org Tue Aug 9 16:36: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 8744C11E80D7; Tue, 9 Aug 2011 16:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpk8O4+Bquje; Tue, 9 Aug 2011 16:36:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F70C11E80CE; Tue, 9 Aug 2011 16:36:01 -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.57 Message-ID: <20110809233601.3876.20184.idtracker@ietfa.amsl.com> Date: Tue, 09 Aug 2011 16:36:01 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-15.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, 09 Aug 2011 23:36:01 -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 : The RPKI/Router Protocol Author(s) : Randy Bush Rob Austein Filename : draft-ietf-sidr-rpki-rtr-15.txt Pages : 25 Date : 2011-08-09 In order to formally validate the origin ASs of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-15.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-rtr-15.txt From danny@tcb.net Tue Aug 9 18:06: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 D278C21F8AA9 for ; Tue, 9 Aug 2011 18:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCkS6GfHmcU3 for ; Tue, 9 Aug 2011 18:06:11 -0700 (PDT) Received: from mailserver.ops-netman.net (unknown [IPv6:2001:470:e495:fade:5054:ff:fe79:69db]) by ietfa.amsl.com (Postfix) with ESMTP id EE2C821F8A95 for ; Tue, 9 Aug 2011 18:06:10 -0700 (PDT) Received: from [192.168.1.9] (90.sub-166-248-43.myvzw.com [166.248.43.90]) (Authenticated sender: danny@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id DE4913202FA for ; Wed, 10 Aug 2011 01:06:36 +0000 (UTC) From: Danny McPherson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Aug 2011 21:06:34 -0400 Message-Id: To: sidr wg list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [sidr] beacons and 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: Wed, 10 Aug 2011 01:06:22 -0000 The discussion of "Beacons" at the last meeting reminds of of EIGRP's = 'triggered updates" v. RIP's "periodic updates" (i.e., cousin of = beacons)... I think Randy successfully convinced me during his talk at the Quebec = City WG session that "beacons" at a frequency of 24 hours (or anything = in the "hours" range) are pretty much useless and add considerable churn = and complexity with little return from a practical attack surface = perspective. =20 With the lifetime of the average phishing site being only ~55 hours (for = many reasons, I know), and an inclination to believe that infrastructure = threats are likely to be even more temporal, and I'm inclined to = recommend that beacons be removed altogether in their current = incarnation of bgpsec, as there are plenty of other scale issues to = focus on.=20 Further study on alternatives, downstream purging issues, and clock skew = for network elements might be useful in this context. I saw something = on the DANE list from PHB about vast skew across end systems, wondering = if anyone has measured this? Thoughts? -danny= From geeohgeegeeoh@gmail.com Tue Aug 9 18:14: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 2FADF21F8B05 for ; Tue, 9 Aug 2011 18:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imLY9Y0OUgB0 for ; Tue, 9 Aug 2011 18:14:44 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4039921F89C2 for ; Tue, 9 Aug 2011 18:14:44 -0700 (PDT) Received: by yxp4 with SMTP id 4so441255yxp.31 for ; Tue, 09 Aug 2011 18:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Vxnd/AdpqvZeTdyBiXL38QSq7WxvRaTLSqMj9Ov7QgA=; b=hoo4FZy4/k1gcBUKVjvslbkU7z8LzbpI3hwAGybavuOGkn74EZzyZaiRKGplm4HZP5 EqR/In4ZhE0Y/SQLGGT79QPv1eU/0UKRsoJwkG9QoYLAFzuJdjmIfBAbq1bcIxfxME6G hoDcZNYboYSGZidjxuKZd+2ugSlrWXqrnTpRc= Received: by 10.100.245.35 with SMTP id s35mr6682210anh.84.1312938914252; Tue, 09 Aug 2011 18:15:14 -0700 (PDT) Received: from dynamic201.apnic.net (dynamic201.apnic.net [203.119.42.201]) by mx.google.com with ESMTPS id o11sm404461anh.23.2011.08.09.18.15.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Aug 2011 18:15:13 -0700 (PDT) Sender: George Michaelson Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: George Michaelson In-Reply-To: Date: Wed, 10 Aug 2011 11:15:09 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> References: To: Danny McPherson X-Mailer: Apple Mail (2.1244.3) Cc: sidr wg list Subject: Re: [sidr] beacons and 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: Wed, 10 Aug 2011 01:14:45 -0000 On 10/08/2011, at 11:06 AM, Danny McPherson wrote: >=20 > The discussion of "Beacons" at the last meeting reminds of of EIGRP's = 'triggered updates" v. RIP's "periodic updates" (i.e., cousin of = beacons)... >=20 > I think Randy successfully convinced me during his talk at the Quebec = City WG session that "beacons" at a frequency of 24 hours (or anything = in the "hours" range) are pretty much useless and add considerable churn = and complexity with little return from a practical attack surface = perspective. =20 >=20 > With the lifetime of the average phishing site being only ~55 hours = (for many reasons, I know), and an inclination to believe that = infrastructure threats are likely to be even more temporal, and I'm = inclined to recommend that beacons be removed altogether in their = current incarnation of bgpsec, as there are plenty of other scale issues = to focus on.=20 >=20 > Further study on alternatives, downstream purging issues, and clock = skew for network elements might be useful in this context. I saw = something on the DANE list from PHB about vast skew across end systems, = wondering if anyone has measured this? >=20 > Thoughts? >=20 Forgive a peanut gallery observation, but are we defining things as = useless which we cannot understand in RPKI, because to admit that we = don't understand them in RPKI means making RPKI more complex? -G From danny@tcb.net Tue Aug 9 18:18: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 116AA21F8B28 for ; Tue, 9 Aug 2011 18:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aasDoORcvvQF for ; Tue, 9 Aug 2011 18:18:52 -0700 (PDT) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id 40C5921F8B26 for ; Tue, 9 Aug 2011 18:18:52 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKTkHcmGrObc5a83ZtTltTd8hdAIZGuLlH@postini.com; Tue, 09 Aug 2011 18:19:22 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p7A1JJIF003356; Tue, 9 Aug 2011 21:19:19 -0400 Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com ([10.100.0.146]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 21:19:18 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> Date: Tue, 9 Aug 2011 21:19:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> To: George Michaelson X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 10 Aug 2011 01:19:19.0069 (UTC) FILETIME=[871FCCD0:01CC56FB] Cc: sidr wg list Subject: Re: [sidr] beacons and 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: Wed, 10 Aug 2011 01:18:53 -0000 On Aug 9, 2011, at 9:15 PM, George Michaelson wrote: >=20 > Forgive a peanut gallery observation, but are we defining things as = useless which we cannot understand in RPKI, because to admit that we = don't understand them in RPKI means making RPKI more complex? I'm not talking about RPKI, I'm talking about BGPSEC. =20 I don't understand your question... -danny From geeohgeegeeoh@gmail.com Tue Aug 9 18:23: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 6E29C228017 for ; Tue, 9 Aug 2011 18:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHFX2XVfY2pV for ; Tue, 9 Aug 2011 18:23:22 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 76C6F22800E for ; Tue, 9 Aug 2011 18:23:21 -0700 (PDT) Received: by yie12 with SMTP id 12so443231yie.31 for ; Tue, 09 Aug 2011 18:23:50 -0700 (PDT) Received: by 10.151.102.12 with SMTP id e12mr762352ybm.138.1312939430021; Tue, 09 Aug 2011 18:23:50 -0700 (PDT) Received: from dynamic201.apnic.net (dynamic201.apnic.net [203.119.42.201]) by mx.google.com with ESMTPS id 16sm2564793ybm.18.2011.08.09.18.23.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Aug 2011 18:23:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: George Michaelson In-Reply-To: <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> Date: Wed, 10 Aug 2011 11:23:46 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> To: Danny McPherson X-Mailer: Apple Mail (2.1244.3) Cc: sidr wg list Subject: Re: [sidr] beacons and 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: Wed, 10 Aug 2011 01:23:22 -0000 On 10/08/2011, at 11:19 AM, Danny McPherson wrote: >=20 > On Aug 9, 2011, at 9:15 PM, George Michaelson wrote: >=20 >>=20 >> Forgive a peanut gallery observation, but are we defining things as = useless which we cannot understand in RPKI, because to admit that we = don't understand them in RPKI means making RPKI more complex? >=20 > I'm not talking about RPKI, I'm talking about BGPSEC. =20 Ok. S/RPKI/BGPSEC/ >=20 > I don't understand your question... You seemed to be saying "some people are saying beacons wont work" when you said: "I think Randy successfully convinced me during his talk = at the Quebec City WG session that "beacons" at a frequency of 24 hours = (or anything in the "hours" range) are pretty much useless and add = considerable churn and complexity with little return from a practical = attack surface perspective. " So, I am asking, are we removing support for beacons in BGPSEC because = we don't understand their impact on BGPSEC and they add complexity which = makes BGPSEC harder to push uphill. Its very probably an unfair question. Thats why I called it the peanut = gallery. -G >=20 > -danny >=20 From danny@tcb.net Tue Aug 9 18:33: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 17DCD21F8B18 for ; Tue, 9 Aug 2011 18:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAmlZbiv+ZLj for ; Tue, 9 Aug 2011 18:33:50 -0700 (PDT) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id 48A4B21F8A7E for ; Tue, 9 Aug 2011 18:33:50 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKTkHgGtRo0ypvNeLGv3Idqf1SLTrAiVbZ@postini.com; Tue, 09 Aug 2011 18:34:20 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id p7A1YHEx005287; Tue, 9 Aug 2011 21:34:17 -0400 Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com ([10.100.0.146]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 21:34:17 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> Date: Tue, 9 Aug 2011 21:34:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> To: George Michaelson X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 10 Aug 2011 01:34:17.0174 (UTC) FILETIME=[9E6FBF60:01CC56FD] Cc: sidr wg list Subject: Re: [sidr] beacons and 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: Wed, 10 Aug 2011 01:33:51 -0000 On Aug 9, 2011, at 9:23 PM, George Michaelson wrote: >=20 > You seemed to be saying "some people are saying beacons wont work" No, that's precisely why I referenced Randy's presentation, if you = didn't see it you should have a look at the proceedings... > when you said: "I think Randy successfully convinced me during his = talk at the Quebec City WG session that "beacons" at a frequency of 24 = hours (or anything in the "hours" range) are pretty much useless and add = considerable churn and complexity with little return from a practical = attack surface perspective. " >=20 > So, I am asking, are we removing support for beacons in BGPSEC because = we don't understand their impact on BGPSEC and they add complexity which = makes BGPSEC harder to push uphill. I was contemplating the ROI for a newly designed protocol (bgpsec) and = why they were put there in the first place (replay attacks [and more = frequent wedgie oscillation :)]) and considering attack surface and = practical implications, realizing that from an engineering tradeoff = perspective they're quite likely not worth the effort. Hence my broken = attempt at a corollary with phishing site lifetime and RIPv1 scaling = properties, because I don't have quantitative empirical data handy of = routing hijack duration, nor could I possibly predict what it might = entail in a bgpsec-enabled world, but I do suspect 24 hours is, umm... = quite a while. > Its very probably an unfair question. Thats why I called it the peanut = gallery. If it makes any difference, I think Randy both proposed beacons, and = made a compelling case for removing them. =20 -danny= From geeohgeegeeoh@gmail.com Tue Aug 9 18:41: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 283CF11E8070 for ; Tue, 9 Aug 2011 18:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmFm3SLAq6e0 for ; Tue, 9 Aug 2011 18:41:36 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B036228016 for ; Tue, 9 Aug 2011 18:41:36 -0700 (PDT) Received: by ywm21 with SMTP id 21so428957ywm.31 for ; Tue, 09 Aug 2011 18:42:06 -0700 (PDT) Received: by 10.100.78.10 with SMTP id a10mr6499436anb.34.1312940526332; Tue, 09 Aug 2011 18:42:06 -0700 (PDT) Received: from dynamic201.apnic.net (dynamic201.apnic.net [203.119.42.201]) by mx.google.com with ESMTPS id l2sm420918anm.24.2011.08.09.18.42.04 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Aug 2011 18:42:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: George Michaelson In-Reply-To: Date: Wed, 10 Aug 2011 11:42:01 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <4DA5E29E-7B05-4986-B993-3EDF2BDB847D@pobox.com> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> To: Danny McPherson X-Mailer: Apple Mail (2.1244.3) Cc: sidr wg list Subject: Re: [sidr] beacons and 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: Wed, 10 Aug 2011 01:41:37 -0000 On 10/08/2011, at 11:34 AM, Danny McPherson wrote: >=20 > On Aug 9, 2011, at 9:23 PM, George Michaelson wrote: >=20 >>=20 >> You seemed to be saying "some people are saying beacons wont work" >=20 > No, that's precisely why I referenced Randy's presentation, if you = didn't see it you should have a look at the proceedings... >=20 Will look >> when you said: "I think Randy successfully convinced me during his = talk at the Quebec City WG session that "beacons" at a frequency of 24 = hours (or anything in the "hours" range) are pretty much useless and add = considerable churn and complexity with little return from a practical = attack surface perspective. " >>=20 >> So, I am asking, are we removing support for beacons in BGPSEC = because we don't understand their impact on BGPSEC and they add = complexity which makes BGPSEC harder to push uphill. >=20 > I was contemplating the ROI for a newly designed protocol (bgpsec) and = why they were put there in the first place (replay attacks [and more = frequent wedgie oscillation :)]) and considering attack surface and = practical implications, realizing that from an engineering tradeoff = perspective they're quite likely not worth the effort. Hence my broken = attempt at a corollary with phishing site lifetime and RIPv1 scaling = properties, because I don't have quantitative empirical data handy of = routing hijack duration, nor could I possibly predict what it might = entail in a bgpsec-enabled world, but I do suspect 24 hours is, umm... = quite a while. Popup announcements for spamming might well lie under 24h lifetime. I = think some people have notes on that. You can inject a humongous amount = of store-and-forward from far far less than 24h of routing. But from the 1 week captures we did for the runout of IPv4, over a = duration of a week we saw some frankly long lived, and widespread = assumptions about routability of the spaces. Very probably not = consciously in the wide, which goes to Randy's observations about the = extent of default route propagating un-expectedly. Also, "newly designed" seems a bit strong. This is BGP + signing chains = isn't it? Its not re-entering from the top clean state.. I said it in part, because AS_SET has gone, precisely because its just = too hard to do in BGPSEC, as I understand it. The justification is "its = not useful" but its removed because of its impact on the emerging = protocol modifications. I am still struggling to understand how Path prepend is going to work. = What I heard suggests its going to have to be administratively = constrained to be sign-able. At the edge its more in the hands of the = origin AS but beyond that where does the permission to play with the = path come from? (again, I may have misunderstood) >=20 >> Its very probably an unfair question. Thats why I called it the = peanut gallery. >=20 > If it makes any difference, I think Randy both proposed beacons, and = made a compelling case for removing them. I guess I live in a margin where they are research TOOL and you = sometimes remove TOOLS. If they were added for another purpose, what I = get from them (which is not much btw, but they get talked about in my = hearing) is not the core motivation. What they seem to do, is help confirm people are seeing BGP state. So = they add something to the question "do I see the same kind(s) of BGP you = see". Maybe thats not enough justifier. -G= From randy@psg.com Tue Aug 9 18:43: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 E824A228020 for ; Tue, 9 Aug 2011 18:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZi1Ajz5A23l for ; Tue, 9 Aug 2011 18:43:22 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 53A7722801B for ; Tue, 9 Aug 2011 18:43:22 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qqxpm-0006ZC-E2; Wed, 10 Aug 2011 01:43:50 +0000 Date: Wed, 10 Aug 2011 10:43:49 +0900 Message-ID: From: Randy Bush To: George Michaelson In-Reply-To: <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.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] beacons and 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: Wed, 10 Aug 2011 01:43:23 -0000 all in all, as my preso is being a bit mis-remembered, i think rereading my preso may be helpful http://archive.psg.com/110728.sidr-replay.pdf randy From danny@tcb.net Tue Aug 9 18:53:54 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 94EB05E8002 for ; Tue, 9 Aug 2011 18:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0pJ+ZhUcnPC for ; Tue, 9 Aug 2011 18:53:54 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by ietfa.amsl.com (Postfix) with ESMTP id C7573228011 for ; Tue, 9 Aug 2011 18:53:53 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKTkHkzQ6a58B4QNhdZwADdnXUkvD95isT@postini.com; Tue, 09 Aug 2011 18:54:24 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id p7A1sJob006030; Tue, 9 Aug 2011 21:54:19 -0400 Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com ([10.100.0.146]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 21:54:19 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <4DA5E29E-7B05-4986-B993-3EDF2BDB847D@pobox.com> Date: Tue, 9 Aug 2011 21:54:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <04CD3192-892F-4032-8AF2-8E6BFF245A52@tcb.net> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <4DA5E29E-7B05-4986-B993-3EDF2BDB847D@pobox.com> To: George Michaelson X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 10 Aug 2011 01:54:19.0268 (UTC) FILETIME=[6AF0BC40:01CC5700] Cc: sidr wg list Subject: Re: [sidr] beacons and 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: Wed, 10 Aug 2011 01:53:54 -0000 On Aug 9, 2011, at 9:42 PM, George Michaelson wrote: >=20 > Also, "newly designed" seems a bit strong. This is BGP + signing = chains isn't it? Its not re-entering from the top clean state. A BGPSEC-enabled routing system looks a lot different than BGP... But let's say "new functionality" for periodic v. triggered updates, you = ok with that? :-) > I am still struggling to understand how Path prepend is going to work. = What I heard suggests its going to have to be administratively = constrained to be sign-able. At the edge its more in the hands of the = origin AS but beyond that where does the permission to play with the = path come from? That's orthogonal, perhaps you should have a look at Doug's slides and = mailing list discussion related to pCNT, which has it's own set of = issues. > I guess I live in a margin where they are research TOOL and you = sometimes remove TOOLS. If they were added for another purpose, what I = get from them (which is not much btw, but they get talked about in my = hearing) is not the core motivation. Again, adding periodic updates to BGP is far from a trivial change from = where we are today, and simply to "reduce the vulnerability window for = replay attacks" I'm not convinced we can get to any frequency where such = a fundamental architectural element is worth the investment. -danny= From paul.hoffman@vpnc.org Tue Aug 9 18:55: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 8BED011E8092 for ; Tue, 9 Aug 2011 18:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25wYrYpEKbHX for ; Tue, 9 Aug 2011 18:55:34 -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 D6F37228014 for ; Tue, 9 Aug 2011 18:55:33 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7A1tefJ018450 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Aug 2011 18:55:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Tue, 9 Aug 2011 18:56:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <78CF412E-8C71-49F8-A5DE-6A89C58196AB@vpnc.org> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> To: Randy Bush X-Mailer: Apple Mail (2.1244.3) Cc: sidr wg list Subject: Re: [sidr] beacons and 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: Wed, 10 Aug 2011 01:55:34 -0000 On Aug 9, 2011, at 6:43 PM, Randy Bush wrote: > all in all, as my preso is being a bit mis-remembered, i think = rereading > my preso may be helpful >=20 > http://archive.psg.com/110728.sidr-replay.pdf +1. I don't see anything in my notes on Randy's presentation about "are = pretty much useless and add considerable churn and complexity with = little return from a practical attack surface perspective". The closest = I see in my notes is "Doesn't gain anything against attack where an = attacker could just do a withdraw". --Paul Hoffman From danny@tcb.net Tue Aug 9 19:02:49 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 AF02C228014 for ; Tue, 9 Aug 2011 19:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuFwvbs-qRp3 for ; Tue, 9 Aug 2011 19:02:49 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id D994E228013 for ; Tue, 9 Aug 2011 19:02:48 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKTkHm2hIPkLms+j1isaemm1DsnV4eLzKu@postini.com; Tue, 09 Aug 2011 19:03:19 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id p7A2355j006352; Tue, 9 Aug 2011 22:03:05 -0400 Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com ([10.100.0.146]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 22:03:04 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <78CF412E-8C71-49F8-A5DE-6A89C58196AB@vpnc.org> Date: Tue, 9 Aug 2011 22:03:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <78CF412E-8C71-49F8-A5DE-6A89C58196AB@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 10 Aug 2011 02:03:05.0071 (UTC) FILETIME=[A457E7F0:01CC5701] Cc: sidr wg list Subject: Re: [sidr] beacons and 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: Wed, 10 Aug 2011 02:02:49 -0000 On Aug 9, 2011, at 9:56 PM, Paul Hoffman wrote: >=20 > +1. I don't see anything in my notes on Randy's presentation about = "are pretty much useless and add considerable churn and complexity with = little return from a practical attack surface perspective". The closest = I see in my notes is "Doesn't gain anything against attack where an = attacker could just do a withdraw". My comment in the initial message: "I think Randy successfully convinced me during his talk at the Quebec = City WG session that "beacons" at a frequency of 24 hours (or anything = in the "hours" range) are pretty much useless and add considerable churn = and complexity with little return from a practical attack surface = perspective. " I didn't quite Randy or his slides there, but I stand by my conclusions. -danny From internet-drafts@ietf.org Wed Aug 10 03:25: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 032C121F863A; Wed, 10 Aug 2011 03:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.891 X-Spam-Level: X-Spam-Status: No, score=-102.891 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLobYw5UvKmF; Wed, 10 Aug 2011 03:25:05 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 9144D21F86AE; Wed, 10 Aug 2011 03:25:05 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EA64F958008; Wed, 10 Aug 2011 12:34:05 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id E2B3C95800E; Wed, 10 Aug 2011 12:34:05 +0200 (CEST) Received: from ftrdsmtp4.rd.francetelecom.fr ([10.192.128.49]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Aug 2011 11:59:21 +0200 Received: from mail pickup service by ftrdsmtp4.rd.francetelecom.fr with Microsoft SMTPSVC; Wed, 10 Aug 2011 02:00:28 +0200 Received: from omfedm05.si.francetelecom.fr ([10.98.84.129]) by ftrdsmtp4.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Aug 2011 01:36:47 +0200 Received: from omfedm11.si.francetelecom.fr (unknown [10.98.62.19]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 790C535C078; Wed, 10 Aug 2011 01:36:46 +0200 (CEST) Received: from omfedm11.si.francetelecom.fr (localhost.localdomain [127.0.0.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with SMTP id 6709C3B427C; Wed, 10 Aug 2011 01:36:46 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by relais-inet.francetelecom.com (ESMTP service) with ESMTP id 2CC393B4250; Wed, 10 Aug 2011 01:36:46 +0200 (CEST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A6E11E80D0; Tue, 9 Aug 2011 16:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1312932962; bh=T9LVmKeGicAbMbFLxqqf5qOvubO8Rj6YNnih2pJMKbY=; h=MIME-Version:From:To:Subject:Message-ID:Date:Cc:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=ENOGyJzkl6iO8MwpG0rjv1hmy6qwVjDkJEZIt2e8Lr+ERAd4jn9jrS0Fb7zBQAqeh I4j1L27m4hML82R5ViE1/YI0U+bCrCMmvaKxgxLKsDdR+0g62RUnWut1Mqzy6dAMZi j3+50yOTT6YNqxXZgVqFWK6ukR2Qcs12g/HIM1EM= X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8744C11E80D7; Tue, 9 Aug 2011 16:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpk8O4+Bquje; Tue, 9 Aug 2011 16:36:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F70C11E80CE; Tue, 9 Aug 2011 16:36:01 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110809233601.3876.20184.idtracker@ietfa.amsl.com> Date: Tue, 09 Aug 2011 16:36:01 -0700 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.9.233017 X-OriginalArrivalTime: 09 Aug 2011 23:36:47.0161 (UTC) FILETIME=[344D2290:01CC56ED] Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-15.txt X-BeenThere: sidr@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 10:25:10 -0000 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 : The RPKI/Router Protocol Author(s) : Randy Bush Rob Austein Filename : draft-ietf-sidr-rpki-rtr-15.txt Pages : 25 Date : 2011-08-09 In order to formally validate the origin ASs of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-15.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-rtr-15.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From dougm@nist.gov Wed Aug 10 06:35: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 F384A21F89BA for ; Wed, 10 Aug 2011 06:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74qE3+WFD649 for ; Wed, 10 Aug 2011 06:35:07 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 332E821F899F for ; Wed, 10 Aug 2011 06:35:07 -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.323.0; Wed, 10 Aug 2011 09:35:03 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 10 Aug 2011 09:35:37 -0400 From: "Montgomery, Douglas" To: George Michaelson , Danny McPherson Date: Wed, 10 Aug 2011 09:35:35 -0400 Thread-Topic: [sidr] beacons and bgpsec Thread-Index: AcxXYk2MitxN+/w7RbiKD7HXQ9Y0fw== Message-ID: In-Reply-To: <4DA5E29E-7B05-4986-B993-3EDF2BDB847D@pobox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] beacons and 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: Wed, 10 Aug 2011 13:35:08 -0000 On 8/9/11 9:42 PM, "George Michaelson" wrote: > >On 10/08/2011, at 11:34 AM, Danny McPherson wrote: > >> >> On Aug 9, 2011, at 9:23 PM, George Michaelson wrote: >> >>> >>> You seemed to be saying "some people are saying beacons wont work" >> >> No, that's precisely why I referenced Randy's presentation, if you >>didn't see it you should have a look at the proceedings... >> > >Will look > >>> when you said: "I think Randy successfully convinced me during his >>>talk at the Quebec City WG session that "beacons" at a frequency of 24 >>>hours (or anything in the "hours" range) are pretty much useless and >>>add considerable churn and complexity with little return from a >>>practical attack surface perspective. " >>> >>> So, I am asking, are we removing support for beacons in BGPSEC because >>>we don't understand their impact on BGPSEC and they add complexity >>>which makes BGPSEC harder to push uphill. >> >> I was contemplating the ROI for a newly designed protocol (bgpsec) and >>why they were put there in the first place (replay attacks [and more >>frequent wedgie oscillation :)]) and considering attack surface and >>practical implications, realizing that from an engineering tradeoff >>perspective they're quite likely not worth the effort. Hence my broken >>attempt at a corollary with phishing site lifetime and RIPv1 scaling >>properties, because I don't have quantitative empirical data handy of >>routing hijack duration, nor could I possibly predict what it might >>entail in a bgpsec-enabled world, but I do suspect 24 hours is, umm... >>quite a while. > >Popup announcements for spamming might well lie under 24h lifetime. I >think some people have notes on that. You can inject a humongous amount >of store-and-forward from far far less than 24h of routing. I think it important to remember that BGPSEC and Origin Validation are basically preventative, not reactionary/response mechanisms. That is infrastructure that is manipulated in human time scales (e.g., ROAs, AS/router Certs) that prevent future false announcements. I think it is the assumption that having ROAs in place will address most pop-up spam false announcements. The issue of expire time and beacons - and reducing the vulnerability window of "stale" BGPSEC signed announcements - is a bit more of a reactionary measure. The idea of expire time exists to address an BGPSEC signed update that *was a valid signed path* at one time but is no longer. Given the assumption that the RPKI is a fairly stable and slowly reacting infrastructure (and one that requires administrative actions to change) it was seemed better to just bound the useful lifetime of a BGPSSEC signed update, than to propose to churn the RPKI to invalidate previously valid paths. At the 24hour + range, our estimates are that it adds 1-2% load of announcements. Dougm > From warren@kumari.net Wed Aug 10 08:09: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 57A0A21F86F4 for ; Wed, 10 Aug 2011 08:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0FOnp2vlgHd for ; Wed, 10 Aug 2011 08:09:09 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id B1D1421F86DF for ; Wed, 10 Aug 2011 08:09:09 -0700 (PDT) Received: from [192.168.1.4] (24-104-73-2-ip-static.hfc.comcastbusiness.net [24.104.73.2]) by vimes.kumari.net (Postfix) with ESMTPSA id 924CF1B4105C; Wed, 10 Aug 2011 11:09:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Wed, 10 Aug 2011 08:09:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6E1F73A6-9D0E-4698-B9EB-E49C7874250E@kumari.net> References: To: Sandra Murphy X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: Re: [sidr] call for wg adoption of draft-turner-sidr-bgpsec-pki-profiles 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, 10 Aug 2011 15:09:10 -0000 On Aug 9, 2011, at 1:47 PM, Sandra Murphy wrote: > The working group has been requested to adopt = draft-turner-sidr-bgpsec-pki-profiles as a working group draft. >=20 > The draft is available at = http://tools.ietf.org/html/draft-turner-sidr-bgpsec-pki-profiles >=20 > Please respond to the list to say whether you accept this draft as a = working group draft Yes. > and are willing to work on it. Yes. > 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 23 Aug 2011 >=20 > --Sandy, speaking as wg co-chair >=20 >=20 >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From jakob.heitz@ericsson.com Wed Aug 10 08:24: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 DC40321F84FE for ; Wed, 10 Aug 2011 08:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.986 X-Spam-Level: X-Spam-Status: No, score=-5.986 tagged_above=-999 required=5 tests=[AWL=0.613, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30WrfZFA8nI4 for ; Wed, 10 Aug 2011 08:24:43 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0799C21F84F4 for ; Wed, 10 Aug 2011 08:24:42 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p7AFP8Qp001814; Wed, 10 Aug 2011 10:25:09 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.94]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 10 Aug 2011 11:25:08 -0400 From: Jakob Heitz To: "Montgomery, Douglas" Date: Wed, 10 Aug 2011 11:25:32 -0400 Thread-Topic: [sidr] beacons and bgpsec Thread-Index: AcxXca/4vxiDP9EMR6yBC/tlIwomgQ== Message-ID: <57F4C7B1-F1C7-4B95-8C6F-A15544C2715D@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list , George Michaelson Subject: Re: [sidr] beacons and 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: Wed, 10 Aug 2011 15:24:44 -0000 Sorry, where did the 2% load come from? Does that mean that every prefix in the Internet is already being advertise= d 50 times every day? Then, one more advertisement per day would make it 2% extra load. Also, note that a beacon every day means a timeout of 3 days. Previous sugg= estions were a timeout of ~24 hours and a beacon of ~8 hours. An alternative to beaconing is a push model instead of pull. That is, every= router registers it's interest with the repository instead of querying it = periodically. Then the repository would tell all registered parties when a = change occurred rather than waiting for them to ask. -- Jakob Heitz. On Aug 10, 2011, at 6:35 AM, "Montgomery, Douglas" wrote: >=20 > On 8/9/11 9:42 PM, "George Michaelson" wrote: >=20 >>=20 >> On 10/08/2011, at 11:34 AM, Danny McPherson wrote: >>=20 >>>=20 >>> On Aug 9, 2011, at 9:23 PM, George Michaelson wrote: >>>=20 >>>>=20 >>>> You seemed to be saying "some people are saying beacons wont work" >>>=20 >>> No, that's precisely why I referenced Randy's presentation, if you >>> didn't see it you should have a look at the proceedings... >>>=20 >>=20 >> Will look >>=20 >>>> when you said: "I think Randy successfully convinced me during his >>>> talk at the Quebec City WG session that "beacons" at a frequency of 24 >>>> hours (or anything in the "hours" range) are pretty much useless and >>>> add considerable churn and complexity with little return from a >>>> practical attack surface perspective. " >>>>=20 >>>> So, I am asking, are we removing support for beacons in BGPSEC because >>>> we don't understand their impact on BGPSEC and they add complexity >>>> which makes BGPSEC harder to push uphill. >>>=20 >>> I was contemplating the ROI for a newly designed protocol (bgpsec) and >>> why they were put there in the first place (replay attacks [and more >>> frequent wedgie oscillation :)]) and considering attack surface and >>> practical implications, realizing that from an engineering tradeoff >>> perspective they're quite likely not worth the effort. Hence my broken >>> attempt at a corollary with phishing site lifetime and RIPv1 scaling >>> properties, because I don't have quantitative empirical data handy of >>> routing hijack duration, nor could I possibly predict what it might >>> entail in a bgpsec-enabled world, but I do suspect 24 hours is, umm... >>> quite a while. >>=20 >> Popup announcements for spamming might well lie under 24h lifetime. I >> think some people have notes on that. You can inject a humongous amount >> of store-and-forward from far far less than 24h of routing. >=20 > I think it important to remember that BGPSEC and Origin Validation are > basically preventative, not reactionary/response mechanisms. That is > infrastructure that is manipulated in human time scales (e.g., ROAs, > AS/router Certs) that prevent future false announcements. I think it is > the assumption that having ROAs in place will address most pop-up spam > false announcements. >=20 > The issue of expire time and beacons - and reducing the vulnerability > window of "stale" BGPSEC signed announcements - is a bit more of a > reactionary measure. The idea of expire time exists to address an BGPSE= C > signed update that *was a valid signed path* at one time but is no longer= . > Given the assumption that the RPKI is a fairly stable and slowly > reacting infrastructure (and one that requires administrative actions to > change) it was seemed better to just bound the useful lifetime of a > BGPSSEC signed update, than to propose to churn the RPKI to invalidate > previously valid paths. >=20 > At the 24hour + range, our estimates are that it adds 1-2% load of > announcements. >=20 > Dougm >>=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From kent@bbn.com Wed Aug 10 09:06:12 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 5029221F8AA8 for ; Wed, 10 Aug 2011 09:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.614 X-Spam-Level: X-Spam-Status: No, score=-106.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLhcNSzKsUUP for ; Wed, 10 Aug 2011 09:06:11 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D29F121F88B6 for ; Wed, 10 Aug 2011 09:06:11 -0700 (PDT) Received: from dhcp89-089-043.bbn.com ([128.89.89.43]:49214) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QrBIn-000Nmu-NO; Wed, 10 Aug 2011 12:06:41 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> Date: Wed, 10 Aug 2011 12:04:06 -0400 To: Danny McPherson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: George Michaelson , sidr wg list Subject: Re: [sidr] beacons and 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: Wed, 10 Aug 2011 16:06:12 -0000 Danny, My recollection of Randy's presentation was not what you suggest. I think he said that having each AS along a path associated a lifetime with the sig it applied to an update was a bad idea. He also said that a beacon rate of about 24 hours, at the origin AS, seemed potentially useful, and would not result in excessive routing churn. Steve From kent@bbn.com Wed Aug 10 09:06: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 33ECD21F8ACA for ; Wed, 10 Aug 2011 09:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.613 X-Spam-Level: X-Spam-Status: No, score=-106.613 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nd5xkUQhmuFw for ; Wed, 10 Aug 2011 09:06:22 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id BFB9421F8AC3 for ; Wed, 10 Aug 2011 09:06:22 -0700 (PDT) Received: from dhcp89-089-043.bbn.com ([128.89.89.43]:49214) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QrBIp-000Nmu-HZ; Wed, 10 Aug 2011 12:06:43 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4DA5E29E-7B05-4986-B993-3EDF2BDB847D@pobox.com> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <4DA5E29E-7B05-4986-B993-3EDF2BDB847D@pobox.com> Date: Wed, 10 Aug 2011 12:06:21 -0400 To: George Michaelson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr wg list Subject: Re: [sidr] beacons and 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: Wed, 10 Aug 2011 16:06:23 -0000 A >... >I said it in part, because AS_SET has gone, precisely because its >just too hard to do in BGPSEC, as I understand it. The justification >is "its not useful" but its removed because of its impact on the >emerging protocol modifications. AS_SET is hard to do, but the principle reason for deprecating it in IDR was because nobody appears to use it (properly). Measurement indicate a very, very tiny number of updates made use of AS_SET, and further examination of those indicated a likely misunderstanding of the "feature" by the ASes in question. Steve From Sandra.Murphy@cobham.com Wed Aug 10 09:20: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 8509621F8584 for ; Wed, 10 Aug 2011 09:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.182 X-Spam-Level: X-Spam-Status: No, score=-102.182 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rs311R5RVTWg for ; Wed, 10 Aug 2011 09:20:43 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id CEA3021F856C for ; Wed, 10 Aug 2011 09:20: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 p7AGL9mn029029; Wed, 10 Aug 2011 11:21:11 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p7AGL9WP018051; Wed, 10 Aug 2011 11:21:09 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.128]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Aug 2011 12:21:09 -0400 Date: Wed, 10 Aug 2011 12:21:08 -0400 (Eastern Daylight Time) From: Sandra Murphy To: George Michaelson In-Reply-To: <4DA5E29E-7B05-4986-B993-3EDF2BDB847D@pobox.com> Message-ID: References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <4DA5E29E-7B05-4986-B993-3EDF2BDB847D@pobox.com> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 10 Aug 2011 16:21:09.0428 (UTC) FILETIME=[83695740:01CC5779] Cc: sidr wg list Subject: Re: [sidr] beacons and 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: Wed, 10 Aug 2011 16:20:44 -0000 On Wed, 10 Aug 2011, George Michaelson wrote: > > On 10/08/2011, at 11:34 AM, Danny McPherson wrote: > >> >> On Aug 9, 2011, at 9:23 PM, George Michaelson wrote: >> >>> >>> You seemed to be saying "some people are saying beacons wont work" >> > > I said it in part, because AS_SET has gone, precisely because its just too hard to do in BGPSEC, as I understand it. The justification is "its not useful" but its removed because of its impact on the emerging protocol modifications. Speaking of my view of the discussion, AS_SETs presented difficulties in origin validation, without consideration of path validation. The topic has come up many times in the wg. In 2010, and in the Beijing meeting in particular, we (energetically) discussed various aspects of validating an origin for AS_SETs. The eventual decision was to abandon determining the origin AS for AS_SETs. --Sandy > > I am still struggling to understand how Path prepend is going to work. What I heard suggests its going to have to be administratively constrained to be sign-able. At the edge its more in the hands of the origin AS but beyond that where does the permission to play with the path come from? > > (again, I may have misunderstood) > >> >>> Its very probably an unfair question. Thats why I called it the peanut gallery. >> >> If it makes any difference, I think Randy both proposed beacons, and made a compelling case for removing them. > > I guess I live in a margin where they are research TOOL and you sometimes remove TOOLS. If they were added for another purpose, what I get from them (which is not much btw, but they get talked about in my hearing) is not the core motivation. > > What they seem to do, is help confirm people are seeing BGP state. So they add something to the question "do I see the same kind(s) of BGP you see". Maybe thats not enough justifier. > > -G > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From Sandra.Murphy@cobham.com Wed Aug 10 10:43: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 DA8A921F8876 for ; Wed, 10 Aug 2011 10:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.213 X-Spam-Level: X-Spam-Status: No, score=-102.213 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ar3h7Q29NxBK for ; Wed, 10 Aug 2011 10:43:40 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3C221F886D for ; Wed, 10 Aug 2011 10:43:40 -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 p7AHiBxo030272; Wed, 10 Aug 2011 12:44:11 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p7AHi6JZ021757; Wed, 10 Aug 2011 12:44:08 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.128]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Aug 2011 13:44:00 -0400 Date: Wed, 10 Aug 2011 13:44:00 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr wg list , "Montgomery, Douglas" In-Reply-To: Message-ID: References: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 10 Aug 2011 17:44:00.0879 (UTC) FILETIME=[16A08FF0:01CC5785] Subject: Re: [sidr] beacons and 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: Wed, 10 Aug 2011 17:43:41 -0000 Speaking as a regular ol' member On Wed, 10 Aug 2011, Montgomery, Douglas wrote: > > On 8/9/11 9:42 PM, "George Michaelson" wrote: > >> >> On 10/08/2011, at 11:34 AM, Danny McPherson wrote: >> >>> >>> On Aug 9, 2011, at 9:23 PM, George Michaelson wrote: >>> >>>> > > I think it important to remember that BGPSEC and Origin Validation are > basically preventative, not reactionary/response mechanisms. That is > infrastructure that is manipulated in human time scales (e.g., ROAs, > AS/router Certs) that prevent future false announcements. I think it is > the assumption that having ROAs in place will address most pop-up spam > false announcements. > I agree that the RPKI is an infrastructure whose contents change in human time scales, with the examples you mention. But the bgpsec protocol operates in-line and at bgp time scales. (Whether that is human scale or not, I'll leave to the operators.) Certainly ROAs would make the pop-up spammers work harder, but I don't know that ROAs could be said to address them completely. Danny has pointed out many times that origin validation does not prevent a bad actor from attaching the valid origin to a bogus path. That was a motivation for doing path validation. I would think pop-up spammers might be determined enough to go to the effort of doing the attach-valid-to-bogus step. They seem to be determined enough to take steps to thwart any other measure thrown in their path. --Sandy From kent@bbn.com Wed Aug 10 12:12: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 38DDF21F8B61 for ; Wed, 10 Aug 2011 12:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.612 X-Spam-Level: X-Spam-Status: No, score=-106.612 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFs1BUw8Us4g for ; Wed, 10 Aug 2011 12:12:21 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9F25721F8B5E for ; Wed, 10 Aug 2011 12:12:21 -0700 (PDT) Received: from dhcp89-089-043.bbn.com ([128.89.89.43]:49221) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QrECz-00008E-EC; Wed, 10 Aug 2011 15:12:53 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <57F4C7B1-F1C7-4B95-8C6F-A15544C2715D@ericsson.com> References: <57F4C7B1-F1C7-4B95-8C6F-A15544C2715D@ericsson.com> Date: Wed, 10 Aug 2011 15:12:01 -0400 To: Jakob Heitz From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr wg list Subject: Re: [sidr] beacons and 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: Wed, 10 Aug 2011 19:12:22 -0000 >... > >Also, note that a beacon every day means a timeout of 3 days. >Previous suggestions were a timeout of ~24 hours and a beacon of ~8 >hours. I think your characterization is accurate, i.e., a TTL of 24 hours which implies a more frequent beacon rate, to avoid a signed route from expiring. >An alternative to beaconing is a push model instead of pull. That >is, every router registers it's interest with the repository instead >of querying it periodically. Then the repository would tell all >registered parties when a change occurred rather than waiting for >them to ask. Every AS that does not rely on default routes is potentially "interested" in the freshness of every origin's route announcement. So I don't see how a registration approach to trigger pushes will help. Also, a motivation for pushing the route freshness info via updates is because this reduces the need for frequent access to the repository system. The downside is that it creates the need to "refresh" a route that might otherwise not need to be announced. Steve From danny@tcb.net Wed Aug 10 12:37: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 3ACF121F8B38 for ; Wed, 10 Aug 2011 12:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeGCbauyKVGD for ; Wed, 10 Aug 2011 12:37:52 -0700 (PDT) Received: from exprod6og114.obsmtp.com (exprod6og114.obsmtp.com [64.18.1.33]) by ietfa.amsl.com (Postfix) with ESMTP id 68FB821F8B37 for ; Wed, 10 Aug 2011 12:37:52 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKTkLeMI5vDeTYkJYObuTxNVdtoZJSwhJC@postini.com; Wed, 10 Aug 2011 12:38:25 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p7AJcNlM004102 for ; Wed, 10 Aug 2011 15:38:23 -0400 Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com ([10.100.0.146]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Aug 2011 15:38:22 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Danny McPherson In-Reply-To: Date: Wed, 10 Aug 2011 15:38:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> To: sidr wg list X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 10 Aug 2011 19:38:22.0826 (UTC) FILETIME=[10AA94A0:01CC5795] Subject: Re: [sidr] beacons and 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: Wed, 10 Aug 2011 19:37:53 -0000 On Aug 10, 2011, at 12:04 PM, Stephen Kent wrote: > My recollection of Randy's presentation was not what you suggest. Again, I don't recall putting any words in Randy's mouth, if I did, it = was unintentional. However... > I think he said that having each AS along a path associated a lifetime = with the sig it applied to an update was a bad idea. He also said that = a beacon rate of about 24 hours, at the origin AS, seemed potentially = useful, and would not result in excessive routing churn. Periodic updates of the entire routing table *with much larger and more = updates* seems undesirable at best to me, particularly to ""reduce the = vulnerability window for replay attacks" to "days". I suggest we stick with the current triggered updates operation or take = this to IDR, it's a fundamental change from where we are today, and = one's perspective of "excessive routing churn" seems to be relative. -danny= From jakob.heitz@ericsson.com Wed Aug 10 12:44: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 3BCE221F8B67 for ; Wed, 10 Aug 2011 12:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.033 X-Spam-Level: X-Spam-Status: No, score=-6.033 tagged_above=-999 required=5 tests=[AWL=0.566, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYHG76orGgFv for ; Wed, 10 Aug 2011 12:44:42 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id A61C021F86D0 for ; Wed, 10 Aug 2011 12:44:42 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p7AJjAco024495; Wed, 10 Aug 2011 14:45:12 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.94]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 10 Aug 2011 15:45:07 -0400 From: Jakob Heitz To: Danny McPherson , sidr wg list Date: Wed, 10 Aug 2011 15:45:06 -0400 Thread-Topic: [sidr] beacons and bgpsec Thread-Index: AcxXlRmnQwW7h1DgS1SnG58OR0IO1gAAIZlw Message-ID: <7309FCBCAE981B43ABBE69B31C8D213914A20DE8E5@EUSAACMS0701.eamcs.ericsson.se> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.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 Subject: Re: [sidr] beacons and 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: Wed, 10 Aug 2011 19:44:43 -0000 Beaconing 3,600,000 paths (from RIB size preso) every 8 hours is 125 updates per second on average. More than a few percent extra load. -- Jakob Heitz. =20 > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On=20 > Behalf Of Danny McPherson > Sent: Wednesday, August 10, 2011 12:38 PM > To: sidr wg list > Subject: Re: [sidr] beacons and bgpsec >=20 >=20 > On Aug 10, 2011, at 12:04 PM, Stephen Kent wrote: >=20 > > My recollection of Randy's presentation was not what you suggest. >=20 > Again, I don't recall putting any words in Randy's mouth, if=20 > I did, it was unintentional. However... >=20 > > I think he said that having each AS along a path associated=20 > a lifetime with the sig it applied to an update was a bad=20 > idea. He also said that a beacon rate of about 24 hours, at=20 > the origin AS, seemed potentially useful, and would not=20 > result in excessive routing churn. >=20 > Periodic updates of the entire routing table *with much=20 > larger and more updates* seems undesirable at best to me,=20 > particularly to ""reduce the vulnerability window for replay=20 > attacks" to "days". >=20 > I suggest we stick with the current triggered updates=20 > operation or take this to IDR, it's a fundamental change from=20 > where we are today, and one's perspective of "excessive=20 > routing churn" seems to be relative. >=20 > -danny > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > = From Sandra.Murphy@cobham.com Wed Aug 10 12:46:41 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 A004721F8B7A for ; Wed, 10 Aug 2011 12:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.227 X-Spam-Level: X-Spam-Status: No, score=-102.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFMNKywYAKkP for ; Wed, 10 Aug 2011 12:46:41 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id D456721F86D0 for ; Wed, 10 Aug 2011 12:46:40 -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 p7AJl7Lq031712; Wed, 10 Aug 2011 14:47:07 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p7AJkwDA027202; Wed, 10 Aug 2011 14:46:58 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.128]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Aug 2011 15:46:54 -0400 Date: Wed, 10 Aug 2011 15:46:54 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Jakob Heitz In-Reply-To: <57F4C7B1-F1C7-4B95-8C6F-A15544C2715D@ericsson.com> Message-ID: References: <57F4C7B1-F1C7-4B95-8C6F-A15544C2715D@ericsson.com> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 10 Aug 2011 19:46:54.0440 (UTC) FILETIME=[419CAE80:01CC5796] Cc: George Michaelson , sidr wg list Subject: Re: [sidr] beacons and 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: Wed, 10 Aug 2011 19:46:41 -0000 Speaking as a regular ol' member On Wed, 10 Aug 2011, Jakob Heitz wrote: > Sorry, where did the 2% load come from? > Does that mean that every prefix in the Internet is already being advertised 50 times every day? > Then, one more advertisement per day would make it 2% extra load. > > Also, note that a beacon every day means a timeout of 3 days. Previous suggestions were a timeout of ~24 hours and a beacon of ~8 hours. > > An alternative to beaconing is a push model instead of pull. That is, every router registers it's interest with the repository instead of querying it periodically. Then the repository would tell all registered parties when a change occurred rather than waiting for them to ask. > I'm not sure I understand your suggestion that the repository push changes, as the bgpsec protocol (where beaconing occurs) is not a repository based system. The bgpsec protocol draft describes an in-band system, where protections for bgp routes get transmitted synchronously with the bgp routes. Trying to couple transmission (whether push or pull) of protections of the bgp routes via a repository system would present difficulties in getting the protections to the recipients at the right time. OTOH, the RPKI *is* a repository system, and that works for the types of data stored in the RPKI because it changes infrequently (or infrequently compared to the rate of change in BGP routes), changes can be anticipated and uploaded ahead of time, etc. For the RPKI, one could imagine a service that would push changes out to RPKI customers, as you suggest. --Sandy > -- > Jakob Heitz. > > > On Aug 10, 2011, at 6:35 AM, "Montgomery, Douglas" wrote: > >> >> On 8/9/11 9:42 PM, "George Michaelson" wrote: >> >>> >>> On 10/08/2011, at 11:34 AM, Danny McPherson wrote: >>> >>>> >>>> On Aug 9, 2011, at 9:23 PM, George Michaelson wrote: >>>> >>>>> >>>>> You seemed to be saying "some people are saying beacons wont work" >>>> >>>> No, that's precisely why I referenced Randy's presentation, if you >>>> didn't see it you should have a look at the proceedings... >>>> >>> >>> Will look >>> >>>>> when you said: "I think Randy successfully convinced me during his >>>>> talk at the Quebec City WG session that "beacons" at a frequency of 24 >>>>> hours (or anything in the "hours" range) are pretty much useless and >>>>> add considerable churn and complexity with little return from a >>>>> practical attack surface perspective. " >>>>> >>>>> So, I am asking, are we removing support for beacons in BGPSEC because >>>>> we don't understand their impact on BGPSEC and they add complexity >>>>> which makes BGPSEC harder to push uphill. >>>> >>>> I was contemplating the ROI for a newly designed protocol (bgpsec) and >>>> why they were put there in the first place (replay attacks [and more >>>> frequent wedgie oscillation :)]) and considering attack surface and >>>> practical implications, realizing that from an engineering tradeoff >>>> perspective they're quite likely not worth the effort. Hence my broken >>>> attempt at a corollary with phishing site lifetime and RIPv1 scaling >>>> properties, because I don't have quantitative empirical data handy of >>>> routing hijack duration, nor could I possibly predict what it might >>>> entail in a bgpsec-enabled world, but I do suspect 24 hours is, umm... >>>> quite a while. >>> >>> Popup announcements for spamming might well lie under 24h lifetime. I >>> think some people have notes on that. You can inject a humongous amount >>> of store-and-forward from far far less than 24h of routing. >> >> I think it important to remember that BGPSEC and Origin Validation are >> basically preventative, not reactionary/response mechanisms. That is >> infrastructure that is manipulated in human time scales (e.g., ROAs, >> AS/router Certs) that prevent future false announcements. I think it is >> the assumption that having ROAs in place will address most pop-up spam >> false announcements. >> >> The issue of expire time and beacons - and reducing the vulnerability >> window of "stale" BGPSEC signed announcements - is a bit more of a >> reactionary measure. The idea of expire time exists to address an BGPSEC >> signed update that *was a valid signed path* at one time but is no longer. >> Given the assumption that the RPKI is a fairly stable and slowly >> reacting infrastructure (and one that requires administrative actions to >> change) it was seemed better to just bound the useful lifetime of a >> BGPSSEC signed update, than to propose to churn the RPKI to invalidate >> previously valid paths. >> >> At the 24hour + range, our estimates are that it adds 1-2% load of >> announcements. >> >> Dougm >>> >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From jakob.heitz@ericsson.com Wed Aug 10 12:54:49 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 DE41D11E807E for ; Wed, 10 Aug 2011 12:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.073 X-Spam-Level: X-Spam-Status: No, score=-6.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StpovS0IgtwE for ; Wed, 10 Aug 2011 12:54:49 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0900C11E8073 for ; Wed, 10 Aug 2011 12:54:48 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p7AJtJAc017417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Aug 2011 14:55:20 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.94]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 10 Aug 2011 15:55:18 -0400 From: Jakob Heitz To: Sandra Murphy Date: Wed, 10 Aug 2011 15:55:17 -0400 Thread-Topic: [sidr] beacons and bgpsec Thread-Index: AcxXlk3v018iessfRTmmzs2pWqZAPAAAF7bg Message-ID: <7309FCBCAE981B43ABBE69B31C8D213914A20DE908@EUSAACMS0701.eamcs.ericsson.se> References: <57F4C7B1-F1C7-4B95-8C6F-A15544C2715D@ericsson.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: George Michaelson , sidr wg list Subject: Re: [sidr] beacons and 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: Wed, 10 Aug 2011 19:54:50 -0000 A push model is just an idea. It is highly likely to have lots of problems. I haven't thought much about it. Has it come up before and was it discredited? Is it worth developing? -- Jakob Heitz. =20 > -----Original Message----- > From: Sandra Murphy [mailto:Sandra.Murphy@sparta.com]=20 > Sent: Wednesday, August 10, 2011 12:47 PM > To: Jakob Heitz > Cc: Montgomery, Douglas; sidr wg list; George Michaelson > Subject: Re: [sidr] beacons and bgpsec >=20 > Speaking as a regular ol' member >=20 > On Wed, 10 Aug 2011, Jakob Heitz wrote: >=20 > > Sorry, where did the 2% load come from? > > Does that mean that every prefix in the Internet is already=20 > being advertised 50 times every day? > > Then, one more advertisement per day would make it 2% extra load. > > > > Also, note that a beacon every day means a timeout of 3=20 > days. Previous suggestions were a timeout of ~24 hours and a=20 > beacon of ~8 hours. > > > > An alternative to beaconing is a push model instead of=20 > pull. That is, every router registers it's interest with the=20 > repository instead of querying it periodically. Then the=20 > repository would tell all registered parties when a change=20 > occurred rather than waiting for them to ask. > > >=20 > I'm not sure I understand your suggestion that the repository push=20 > changes, as the bgpsec protocol (where beaconing occurs) is not a=20 > repository based system. >=20 > The bgpsec protocol draft describes an in-band system, where=20 > protections=20 > for bgp routes get transmitted synchronously with the bgp=20 > routes. Trying=20 > to couple transmission (whether push or pull) of protections=20 > of the bgp=20 > routes via a repository system would present difficulties in=20 > getting the=20 > protections to the recipients at the right time. >=20 > OTOH, the RPKI *is* a repository system, and that works for=20 > the types of=20 > data stored in the RPKI because it changes infrequently (or=20 > infrequently=20 > compared to the rate of change in BGP routes), changes can be=20 > anticipated=20 > and uploaded ahead of time, etc. For the RPKI, one could imagine a=20 > service that would push changes out to RPKI customers, as you suggest. >=20 > --Sandy >=20 >=20 > > -- > > Jakob Heitz. > > > > > > On Aug 10, 2011, at 6:35 AM, "Montgomery, Douglas"=20 > wrote: > > > >> > >> On 8/9/11 9:42 PM, "George Michaelson" wrote: > >> > >>> > >>> On 10/08/2011, at 11:34 AM, Danny McPherson wrote: > >>> > >>>> > >>>> On Aug 9, 2011, at 9:23 PM, George Michaelson wrote: > >>>> > >>>>> > >>>>> You seemed to be saying "some people are saying beacons=20 > wont work" > >>>> > >>>> No, that's precisely why I referenced Randy's=20 > presentation, if you > >>>> didn't see it you should have a look at the proceedings... > >>>> > >>> > >>> Will look > >>> > >>>>> when you said: "I think Randy successfully convinced me=20 > during his > >>>>> talk at the Quebec City WG session that "beacons" at a=20 > frequency of 24 > >>>>> hours (or anything in the "hours" range) are pretty=20 > much useless and > >>>>> add considerable churn and complexity with little return from a > >>>>> practical attack surface perspective. " > >>>>> > >>>>> So, I am asking, are we removing support for beacons in=20 > BGPSEC because > >>>>> we don't understand their impact on BGPSEC and they add=20 > complexity > >>>>> which makes BGPSEC harder to push uphill. > >>>> > >>>> I was contemplating the ROI for a newly designed=20 > protocol (bgpsec) and > >>>> why they were put there in the first place (replay=20 > attacks [and more > >>>> frequent wedgie oscillation :)]) and considering attack=20 > surface and > >>>> practical implications, realizing that from an=20 > engineering tradeoff > >>>> perspective they're quite likely not worth the effort. =20 > Hence my broken > >>>> attempt at a corollary with phishing site lifetime and=20 > RIPv1 scaling > >>>> properties, because I don't have quantitative empirical=20 > data handy of > >>>> routing hijack duration, nor could I possibly predict=20 > what it might > >>>> entail in a bgpsec-enabled world, but I do suspect 24=20 > hours is, umm... > >>>> quite a while. > >>> > >>> Popup announcements for spamming might well lie under 24h=20 > lifetime. I > >>> think some people have notes on that. You can inject a=20 > humongous amount > >>> of store-and-forward from far far less than 24h of routing. > >> > >> I think it important to remember that BGPSEC and Origin=20 > Validation are > >> basically preventative, not reactionary/response=20 > mechanisms. That is > >> infrastructure that is manipulated in human time scales=20 > (e.g., ROAs, > >> AS/router Certs) that prevent future false announcements. =20 > I think it is > >> the assumption that having ROAs in place will address most=20 > pop-up spam > >> false announcements. > >> > >> The issue of expire time and beacons - and reducing the=20 > vulnerability > >> window of "stale" BGPSEC signed announcements - is a bit more of a > >> reactionary measure. The idea of expire time exists to=20 > address an BGPSEC > >> signed update that *was a valid signed path* at one time=20 > but is no longer. > >> Given the assumption that the RPKI is a fairly stable and slowly > >> reacting infrastructure (and one that requires=20 > administrative actions to > >> change) it was seemed better to just bound the useful lifetime of a > >> BGPSSEC signed update, than to propose to churn the RPKI=20 > to invalidate > >> previously valid paths. > >> > >> At the 24hour + range, our estimates are that it adds 1-2% load of > >> announcements. > >> > >> Dougm > >>> > >> > >> _______________________________________________ > >> sidr mailing list > >> sidr@ietf.org > >> https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > > > = From gih@apnic.net Wed Aug 10 20:40: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 7620911E80BB for ; Wed, 10 Aug 2011 20:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.106 X-Spam-Level: X-Spam-Status: No, score=-101.106 tagged_above=-999 required=5 tests=[AWL=-1.177, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPi66r92FsPL for ; Wed, 10 Aug 2011 20:40:39 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id BAC6F11E8083 for ; Wed, 10 Aug 2011 20:40:39 -0700 (PDT) Received: from [202.158.221.120] (unknown [202.158.221.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id E8EF8B673D; Wed, 10 Aug 2011 23:41:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Thu, 11 Aug 2011 13:41:10 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <8670FC34-2364-404A-A27F-7667BFA03007@apnic.net> References: To: "Montgomery, Douglas" X-Mailer: Apple Mail (2.1244.3) Cc: sidr wg list Subject: Re: [sidr] beacons and 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: Thu, 11 Aug 2011 03:40:40 -0000 On 10/08/2011, at 11:35 PM, Montgomery, Douglas wrote: >=20 >=20 > At the 24hour + range, our estimates are that it adds 1-2% load of > announcements. >=20 Doug, Thats a fascinating claim Doug, and I just don't accept it. Are you seriously suggesting that you are basing this on a measurement = of a eBGP location that has an update load such that adding some 370,000 = additional updates would add 1 - 2 % to the existing load? i.e. an eBGP = location that currently experiences some 18,500,000 - 37,000,00 updates = per day. Really? Where is this location? The data I have collected at AS2.0 on BGP update loads over a baseline = of many years suggests that adding 370,000 announcements every day to a = base eBGP average workload of some 100,000 announcements a day is not = exactly a 2% increase. Nowhere close. So where did your "adds 1-2% load" = estimates come from? Geoff From iesg-secretary@ietf.org Thu Aug 11 09:08: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 306B021F8B77; Thu, 11 Aug 2011 09:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1kKYidZn6hd; Thu, 11 Aug 2011 09:08:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747DC21F8B7C; Thu, 11 Aug 2011 09:08:41 -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.57 Message-ID: <20110811160841.18839.73279.idtracker@ietfa.amsl.com> Date: Thu, 11 Aug 2011 09:08:41 -0700 Cc: sidr mailing list , sidr chair , RFC Editor Subject: [sidr] Protocol Action: 'A Profile for Resource Certificate Repository Structure' to BCP (draft-ietf-sidr-repos-struct-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: Thu, 11 Aug 2011 16:08:42 -0000 The IESG has approved the following document: - 'A Profile for Resource Certificate Repository Structure' (draft-ietf-sidr-repos-struct-09.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-repos-struct/ Technical Summary This document defines a profile for the structure of the Resource PKI distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509 / PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile defines the recommended object (file) naming scheme, the recommended contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and facilitate certification path construction. Working Group Summary The working group considered the use of standardized file extensions in the draft and decided that the best mechanism was to establish an IANA registry. Creating an IANA registry required a new IANA considerations section, which created a small delay waiting for a new version. Document Quality There are no concerns about the document quality. It has been reviewed in the working group many times and has been implemented by several independent implementers. Personnel Sandra Murphy (Sandra.Murphy@sparta.com) is the document shepherd. Stewart Bryant (stbryant@cisco.com) is the Responsible Area Director. From iesg-secretary@ietf.org Thu Aug 11 10:14: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 DF59E21F8C34; Thu, 11 Aug 2011 10:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONv-xXhkdKwd; Thu, 11 Aug 2011 10:14:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8FE21F8C37; Thu, 11 Aug 2011 10:14:36 -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.57 Message-ID: <20110811171436.18039.8679.idtracker@ietfa.amsl.com> Date: Thu, 11 Aug 2011 10:14:36 -0700 Cc: sidr mailing list , sidr chair , RFC Editor Subject: [sidr] CORRECTED Protocol Action: 'A Profile for Resource Certificate Repository Structure' to Proposed Standard (draft-ietf-sidr-repos-struct-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: Thu, 11 Aug 2011 17:14:38 -0000 The IESG has approved the following document: - 'A Profile for Resource Certificate Repository Structure' (draft-ietf-sidr-repos-struct-09.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-repos-struct/ Technical Summary This document defines a profile for the structure of the Resource PKI distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509 / PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile defines the recommended object (file) naming scheme, the recommended contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and facilitate certification path construction. Working Group Summary The working group considered the use of standardized file extensions in the draft and decided that the best mechanism was to establish an IANA registry. Creating an IANA registry required a new IANA considerations section, which created a small delay waiting for a new version. Document Quality There are no concerns about the document quality. It has been reviewed in the working group many times and has been implemented by several independent implementers. Personnel Sandra Murphy (Sandra.Murphy@sparta.com) is the document shepherd. Stewart Bryant (stbryant@cisco.com) is the Responsible Area Director. From wesley.george@twcable.com Thu Aug 11 14:39: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 A260E21F8770 for ; Thu, 11 Aug 2011 14:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.065 X-Spam-Level: X-Spam-Status: No, score=-0.065 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXZSwVp5QiGj for ; Thu, 11 Aug 2011 14:39:55 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 04FE421F875E for ; Thu, 11 Aug 2011 14:39:54 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,358,1309752000"; d="scan'208";a="261476713" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 11 Aug 2011 17:38:03 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Thu, 11 Aug 2011 17:40:29 -0400 From: "George, Wesley" To: Danny McPherson , sidr wg list Date: Thu, 11 Aug 2011 17:40:33 -0400 Thread-Topic: BGPSec scaling (was RE: [sidr] beacons and bgpsec) Thread-Index: AcxXlRYzx19OWW9WR+qLPmTOJN+B3gAtymVA Message-ID: <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.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 Subject: [sidr] BGPSec scaling (was RE: beacons and 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: Thu, 11 Aug 2011 21:39:55 -0000 Danny said, "Periodic updates of the entire routing table *with much larger and more up= dates* seems undesirable at best to me, particularly to 'reduce the vulnera= bility window for replay attacks' to 'days'." --------------------------------------------------------- I think that this is a small part of a much larger issue that has been bugg= ing me since our meeting in Quebec City. After looking at Sriram's estimates around the necessary amount of memory, = etc for the different algorithms, I'm bothered by what is being asked of th= e routing system in support of BGPSec. For ~5 years, IETF via 4984, & 6227 has said that simply relying on Moore's= law to cover the impacts of the growth of the routing table is not sustain= able. Yet here we are doing exactly that, while also doing something that w= ill tilt the curve of the memory footprint, processing requirements, etc fo= r the RIB significantly in the wrong direction. When scale comes up, mostly= I've heard "well, this isn't going to be deployable for 5 years because yo= u have to ask YFV to build hardware that can support it, but by then it'll = be fine, mumble mumble cheap RAM mumble crypto acceleration..." I guess you could say that I'm having a bit of a philosophical crisis over = the taste of the Kool-aid here in terms of the benefits vs the potential co= sts. Don't get me wrong, I very much support SIDR's work and goals, but I think = we shouldn't downplay the overall scaling considerations. If it's no longer= a concern, or won't be in 5 years, we need to articulate (in a broader for= um) the reasons why the concerns and assumptions in 4984/6227 are no longer= valid or not applicable to this case. Assuming that the situation hasn't fundamentally changed and those concerns= are still valid, the supposed 5-year event horizon for BGPSec adoption mak= es it somewhat more likely that between now and serious deployment, we will= be seriously considering some design changes (whether outputs from RRG or = something new) to improve the scalability of the global routing system, and= I fear that we will end up with a lovely protocol suite from this WG that = would end up in need of radical changes because we've since fundamentally a= ltered the function of the routing system to make it scale better. As far as where this leaves BGPSec, I don't know. Perhaps a solution comes = in the form of some of us starting to champion the necessary work to move o= ne or more of the better ideas from RRG into implementation so that the und= erlying scaling problem is being addressed in parallel. It should be quite = possible to incorporate improvements to route security into whatever must a= lready be done to improve scale, and even if not, these are two things that= both share a barrier to deployment, especially incrementally, and would ce= rtainly benefit from being designed and deployed in concert instead of in = separate silos. 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. From internet-drafts@ietf.org Thu Aug 11 19:01:35 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 875AE11E80A3; Thu, 11 Aug 2011 19:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXCvrYvUezvA; Thu, 11 Aug 2011 19:01:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3188311E8095; Thu, 11 Aug 2011 19:01:35 -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.57 Message-ID: <20110812020113.6590.17578.idtracker@ietfa.amsl.com> Date: Thu, 11 Aug 2011 19:01:13 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-ghostbusters-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: Fri, 12 Aug 2011 02:01:35 -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 : The RPKI Ghostbusters Record Author(s) : Randy Bush Filename : draft-ietf-sidr-ghostbusters-07.txt Pages : 8 Date : 2011-08-11 In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information which might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This draft describes the RPKI Ghostbusters Record containing human contact information to be signed (indirectly) by a resource-owning certificate. The data in the record are those of a severely profiled vCARD. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-ghostbusters-07.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-ghostbusters-07.txt From ietfc@btconnect.com Fri Aug 12 03:51: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 3055A21F871E for ; Fri, 12 Aug 2011 03:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.022 X-Spam-Level: X-Spam-Status: No, score=-1.022 tagged_above=-999 required=5 tests=[AWL=-1.023, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdrDdfKAOjhZ for ; Fri, 12 Aug 2011 03:51:22 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by ietfa.amsl.com (Postfix) with ESMTP id EC2A021F84F0 for ; Fri, 12 Aug 2011 03:51:20 -0700 (PDT) Received: from host81-159-99-55.range81-159.btcentralplus.com (HELO pc6) ([81.159.99.55]) by c2beaomr06.btconnect.com with SMTP id EDT51496; Fri, 12 Aug 2011 11:51:49 +0100 (BST) Message-ID: <011701cc58d4$fbbd4ce0$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><017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> Date: Fri, 12 Aug 2011 11:48:20 +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.0A0B0303.4E4505C5.002C, actions=TAG X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.8.12.94816:17:7.586, ip=81.159.99.55, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __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, BODY_SIZE_200_299, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, BODY_SIZE_1000_LESS, RDNS_SUSP, BODY_SIZE_2000_LESS, SMALL_BODY, BODY_SIZE_7000_LESS, NO_URI_FOUND X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.4E4505C5.016E,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] draft-sidr-rpki-rtr 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, 12 Aug 2011 10:51:23 -0000 I notice that there is no mention of which range the port number should be from, in section 12. This has been a hot topic with TSVWG, so if guidance can be given - eg we do not care - then that could forestall later debate. Tom Petch From touch@isi.edu Fri Aug 12 09:56: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 1123C21F8582 for ; Fri, 12 Aug 2011 09:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.968 X-Spam-Level: X-Spam-Status: No, score=-104.968 tagged_above=-999 required=5 tests=[AWL=1.031, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3laHxYPgyJK for ; Fri, 12 Aug 2011 09:56:47 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 31A9C21F8581 for ; Fri, 12 Aug 2011 09:56:47 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p7CGuQN2003423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Aug 2011 09:56:27 -0700 (PDT) Message-ID: <4E455B3A.7030005@isi.edu> Date: Fri, 12 Aug 2011 09:56:26 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "t.petch" 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> <011701cc58d4$fbbd4ce0$4001a8c0@gateway.2wire.net> In-Reply-To: <011701cc58d4$fbbd4ce0$4001a8c0@gateway.2wire.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: sidr@ietf.org Subject: Re: [sidr] draft-sidr-rpki-rtr 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, 12 Aug 2011 16:56:48 -0000 On 8/12/2011 2:48 AM, t.petch wrote: > I notice that there is no mention of which range the port number should be from, > in section 12. > > This has been a hot topic with TSVWG, so if guidance can be given - eg we do not > care - then that could forestall later debate. Hi, Tom, The general issue of the difference in the "system" (privileged) and "user" (non-privileged) ports has been a topic on TSVWG, but not recently and not in this specific context AFAICT. There is a move afoot for many years to deprecate the difference between the ranges, but it doesn't appear to be going anywhere quickly. If you can provide a pointer otherwise, let me know. There have been very few recent assignments to the system range, notably netconf over ssh this past year. IMO, this does belong in the system range, but it's your decision. Joe From randy@psg.com Fri Aug 12 18:07: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 96C5B11E8084 for ; Fri, 12 Aug 2011 18:07:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+w50CeHa9yU for ; Fri, 12 Aug 2011 18:07:19 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 281C811E807E for ; Fri, 12 Aug 2011 18:07:19 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qs2hg-000Ju7-9o; Sat, 13 Aug 2011 01:07:56 +0000 Date: Sat, 13 Aug 2011 10:07:55 +0900 Message-ID: From: Randy Bush To: Tom Petch In-Reply-To: <011701cc58d4$fbbd4ce0$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> <011701cc58d4$fbbd4ce0$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] draft-sidr-rpki-rtr 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: Sat, 13 Aug 2011 01:07:19 -0000 > I notice that there is no mention of which range the port number > should be from, in section 12. i had hoped that the iesg or some other guardian of port numbers would sort this out with the iana if they felt they needed guidance. which would you recommend and why? randy From stbryant@cisco.com Sat Aug 13 01:01: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 A051A21F8770 for ; Sat, 13 Aug 2011 01:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.241 X-Spam-Level: X-Spam-Status: No, score=-110.241 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWQBb4JyoCUu for ; Sat, 13 Aug 2011 01:01:08 -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 A678821F874C for ; Sat, 13 Aug 2011 01:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=1282; q=dns/txt; s=iport; t=1313222507; x=1314432107; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=IG5zRiAovk0W1nL2CKWaTHFVW5J1ESvKomPdgGYRX5Q=; b=Y5cvqRpnSBT8uwGgmBPuofn1bE6ZxiOLuWSOGMvAWAhDiPu82/2ApFSi Iu5grOhlGoff8MOs3Dpji2rUeezMrjkCgmF5bWuOXO5PjkJUwEgRDj/kH Iq6cU5/nj14tjO+egvSvY7jimiDLpETHK6Hq62Vuza4Dyhqj364rkAIs9 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEGAMYuRk6Q/khR/2dsb2JhbABBmHCPCHeBQAEBAQEDEgECASJAEQsYCRYPCQMCAQIBRRMIAQEeokQBgyAPAZsdhkcEkxKQdg X-IronPort-AV: E=Sophos;i="4.67,366,1309737600"; d="scan'208";a="50315824" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 13 Aug 2011 08:01:45 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7D81j5l026076 for ; Sat, 13 Aug 2011 08:01:45 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p7D81g0k018120; Sat, 13 Aug 2011 09:01:44 +0100 (BST) Message-ID: <4E462F65.2020905@cisco.com> Date: Sat, 13 Aug 2011 09:01:41 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: sidr@ietf.org 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> <011701cc58d4$fbbd4ce0$4001a8c0@gateway.2wire.net> <4E455B3A.7030005@isi.edu> In-Reply-To: <4E455B3A.7030005@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] draft-sidr-rpki-rtr 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: Sat, 13 Aug 2011 08:01:08 -0000 On 12/08/2011 17:56, Joe Touch wrote: > > > On 8/12/2011 2:48 AM, t.petch wrote: >> I notice that there is no mention of which range the port number >> should be from, >> in section 12. >> >> This has been a hot topic with TSVWG, so if guidance can be given - >> eg we do not >> care - then that could forestall later debate. > > Hi, Tom, > > The general issue of the difference in the "system" (privileged) and > "user" (non-privileged) ports has been a topic on TSVWG, but not > recently and not in this specific context AFAICT. There is a move > afoot for many years to deprecate the difference between the ranges, > but it doesn't appear to be going anywhere quickly. > > If you can provide a pointer otherwise, let me know. > > There have been very few recent assignments to the system range, > notably netconf over ssh this past year. > > IMO, this does belong in the system range, but it's your decision. > > Joe Yes from looking at the registry text on the two ranges this looks like it needs to be from the "well known port range" = 0..1023 where BGP itself is. I suggest that you put in a request for an allocation in that range and leave it to the transport area reviewers to tell us that we are wrong (and why). Stewart From internet-drafts@ietf.org Sat Aug 13 02:51:49 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 373FC21F8862; Sat, 13 Aug 2011 02:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjVSw+0f1ACK; Sat, 13 Aug 2011 02:51:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D1521F880C; Sat, 13 Aug 2011 02:51:48 -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.57 Message-ID: <20110813095148.21543.40422.idtracker@ietfa.amsl.com> Date: Sat, 13 Aug 2011 02:51:48 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-16.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: Sat, 13 Aug 2011 09:51:49 -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 : The RPKI/Router Protocol Author(s) : Randy Bush Rob Austein Filename : draft-ietf-sidr-rpki-rtr-16.txt Pages : 25 Date : 2011-08-13 In order to formally validate the origin ASs of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-16.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-rtr-16.txt From ietfc@btconnect.com Mon Aug 15 03:16: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 85EF621F8B29 for ; Mon, 15 Aug 2011 03:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omfyvkwBZK01 for ; Mon, 15 Aug 2011 03:16:18 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by ietfa.amsl.com (Postfix) with ESMTP id 92D5E21F8B27 for ; Mon, 15 Aug 2011 03:16:16 -0700 (PDT) Received: from host86-163-150-187.range86-163.btcentralplus.com (HELO pc6) ([86.163.150.187]) by c2beaomr06.btconnect.com with SMTP id EEK58157; Mon, 15 Aug 2011 11:16:36 +0100 (BST) Message-ID: <01ad01cc5b2b$8cf52860$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Joe Touch" 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> <011701cc58d4$fbbd4ce0$4001a8c0@gateway.2wire.net> <4E455B3A.7030005@isi.edu> Date: Mon, 15 Aug 2011 11:13:02 +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=Neutral-1, source=Queried, refid=tid=0001.0A0B0303.4E48F203.00DC, actions=TAG X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.8.15.95715:17:7.586, ip=86.163.150.187, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __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, __FRAUD_BODY_WEBMAIL, __URI_NO_WWW, __URI_NO_PATH, 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, __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.0A0B0202.4E48F210.0080,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@ietf.org Subject: Re: [sidr] draft-sidr-rpki-rtr 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, 15 Aug 2011 10:16:18 -0000 ----- Original Message ----- From: "Joe Touch" To: "t.petch" Cc: "Christopher Morrow" ; Sent: Friday, August 12, 2011 6:56 PM > > > On 8/12/2011 2:48 AM, t.petch wrote: > > I notice that there is no mention of which range the port number should be from, > > in section 12. > > > > This has been a hot topic with TSVWG, so if guidance can be given - eg we do not > > care - then that could forestall later debate. > > Hi, Tom, > > The general issue of the difference in the "system" (privileged) and > "user" (non-privileged) ports has been a topic on TSVWG, but not > recently and not in this specific context AFAICT. There is a move afoot > for many years to deprecate the difference between the ranges, but it > doesn't appear to be going anywhere quickly. > > If you can provide a pointer otherwise, let me know. Joe, I was thinking, as I am sure you know, of draft-ietf-tsvwg-iana-ports where my recollection is that in WGLC, last December, the issue of unifying the two ranges did get raised and was declared out of scope. Then in IETF LC, in January, there were comments that the I-D did not give enough guidance to IANA as to what to do when reviewing a request, the underlying concern being that ports are a scarce resource and should be conserved. At that time, the concern was more that protocols should not be allowed a second port for security but should be designed to negotiate security in-band:-( but I read into that the concern as also being that system ports are even more scarce and so the rules should be tighter. I also recall a TLS discussion as to whether two ports are better than one for security, with no clear consensus emerging. So I anticipate some more discussion along these lines at IETF LC and would like us to have an answer ready. Two system ports would seem to be the most demanding request to make and so the one needing the most justification. As you say, netconf over ssh went 'system', but netconf over TLS did not, nor did SNMP over ssh. Tom Petch. > > There have been very few recent assignments to the system range, notably > netconf over ssh this past year. > > IMO, this does belong in the system range, but it's your decision. > > Joe From touch@isi.edu Mon Aug 15 09:50: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 2D89221F8C64 for ; Mon, 15 Aug 2011 09:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.985 X-Spam-Level: X-Spam-Status: No, score=-102.985 tagged_above=-999 required=5 tests=[AWL=-0.986, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2b9niKM4gzqV for ; Mon, 15 Aug 2011 09:50:55 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA5D21F8C61 for ; Mon, 15 Aug 2011 09:50:55 -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 p7FGp7Go000626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Aug 2011 09:51:07 -0700 (PDT) Message-ID: <4E494E7B.3050809@isi.edu> Date: Mon, 15 Aug 2011 09:51:07 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "t.petch" 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> <011701cc58d4$fbbd4ce0$4001a8c0@gateway.2wire.net> <4E455B3A.7030005@isi.edu> <01ad01cc5b2b$8cf52860$4001a8c0@gateway.2wire.net> In-Reply-To: <01ad01cc5b2b$8cf52860$4001a8c0@gateway.2wire.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: sidr@ietf.org Subject: Re: [sidr] draft-sidr-rpki-rtr 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, 15 Aug 2011 16:50:56 -0000 Hi, Tom, On 8/15/2011 2:13 AM, t.petch wrote: ... > I was thinking, as I am sure you know, of draft-ietf-tsvwg-iana-ports where my > recollection is that in WGLC, last December, the issue of unifying the two > ranges did get raised and was declared out of scope. For that doc. It will be addressed in the user port recommendations, though it's not clear yet whether it will be resolved or just the issues documented. > Then in IETF LC, in > January, there were comments that the I-D did not give enough guidance to IANA > as to what to do when reviewing a request, the underlying concern being that > ports are a scarce resource and should be conserved. At that time, the concern > was more that protocols should not be allowed a second port for security but > should be designed to negotiate security in-band:-( but I read into that the > concern as also being that system ports are even more scarce and so the rules > should be tighter. The rate of port allocations hasn't changed in over a decade; recent reforms have served well to conserve the space. They've focused on avoiding gratuitous allocations of ranges of ports, not the security issue or the user/system issue. > I also recall a TLS discussion as to whether two ports are better than one for > security, with no clear consensus emerging. Yes. For other related protocol issues, the general consensus is "mux in band", i.e., that ports are scarce and that additional ports should never be allocated solely for performance or software complexity reasons. Security has other issues - e.g., port filtering, for one. However, the primary argument in favor of separate secure/insecure ports appears to be focused solely on performance, AFAICT. FWIW, there are already examples where multiple protocol 'stacks' require separate ports because the muxing can't happen in-band. > So I anticipate some more discussion along these lines at IETF LC and would like > us to have an answer ready. Two system ports would seem to be the most > demanding request to make and so the one needing the most justification. For this service, the key question isn't whether there should be a secure port, but why there would ever be a need for an insecure one -- especially if these are in the system range. > As you say, netconf over ssh went 'system', but netconf over TLS did not, nor > did SNMP over ssh. Whether a service goes into system or user is up to the protocol designer, and whether you all feel that this provides any benefit or not. As to the hurdles once you pick a range, yes - there will be more for system ports than for user ports. One part you're already clean on - this being an IETF proposed standard. The allocations of ports aren't particularly more conservative for system vs user, except (as above) that the argument for purely non-secure ports is even more thin. Joe From internet-drafts@ietf.org Wed Aug 17 11:57: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 6156011E809D; Wed, 17 Aug 2011 11:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+so7JDbttf5; Wed, 17 Aug 2011 11:57:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17E111E8089; Wed, 17 Aug 2011 11:57:27 -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.58 Message-ID: <20110817185727.8390.50303.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2011 11:57:27 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-ghostbusters-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: Wed, 17 Aug 2011 18:57:28 -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 : The RPKI Ghostbusters Record Author(s) : Randy Bush Filename : draft-ietf-sidr-ghostbusters-08.txt Pages : 8 Date : 2011-08-17 In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information which might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This draft describes the RPKI Ghostbusters Record containing human contact information which may be verified (indirectly) by a CA certificate. The data in the record are those of a severely profiled vCARD. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-ghostbusters-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-ghostbusters-08.txt From christopher.morrow@gmail.com Thu Aug 18 20:59: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 E5C4A21F86BE; Thu, 18 Aug 2011 20:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.549 X-Spam-Level: X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kW+A0XMno5Y5; Thu, 18 Aug 2011 20:59:24 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC9921F86B1; Thu, 18 Aug 2011 20:59:21 -0700 (PDT) Received: by pzk33 with SMTP id 33so6838088pzk.18 for ; Thu, 18 Aug 2011 21:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=UWIeLoKkHTCYoGyfKZr/s//2sKizxMykZg/CvVC0rvQ=; b=cwjWllbskc6VIzMU5jVmIgQmGEBqhoABf3R42LqcZgrf7qJutbEe0nmutxWclMVAap hGwZzDO7HCl3R2r18pFuPug4RMXCVEFGQzq9dVqaygt6HLfXpATgQVBAZsDGpl09f3zJ Cg2KI4lJhbDHM7gpdZnMoQJ5I9AuHBAPZEifI= MIME-Version: 1.0 Received: by 10.142.48.2 with SMTP id v2mr833464wfv.291.1313726416995; Thu, 18 Aug 2011 21:00:16 -0700 (PDT) Received: by 10.68.43.196 with HTTP; Thu, 18 Aug 2011 21:00:16 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Aug 2011 00:00:16 -0400 Message-ID: From: Christopher Morrow To: sidr@ietf.org, sidr-chairs@ietf.org, Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Fri, 19 Aug 2011 03:59:25 -0000 Hello, Waking a longishly dead thread to call some form of consensus on what is now rev16 of this draft: http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-16 I believe we cycled around most of the heated parts, finding compromise and reaching steady-state (last real message on this topic was 5 or so days ago). At this point I think we're safe to go forward to IESG review. I'll be packaging up a protos doc and mailing that forward tomorrow. -chris (co-chair-in-training) On Wed, Feb 16, 2011 at 1:39 PM, Christopher Morrow wrote: > Ok folk, > The rpki-rtr document: > =A0 > > went through WGLC on version ~02, it's since had a slight mod (added a > Cache-nonce added) which is here in section 4.1: > > "The Cache Nonce reassures the router that the serial numbers are > =A0 comensurate, i.e. the cache session has not been changed." > > and again in 4.2: > "The Cache Nonce tells the cache what instance the router expects to > =A0 ensure that the serial numbers are comensurate, i.e. the cache > =A0 session has not been changed." > > and again in 4.4: > "In response to a Reset Query, the Cache Nonce tells the router the > =A0 instance of the cache session for future confirmation. =A0In response > =A0 to a Serial Query, the Cache Nonce reassures the router that the > =A0 serial numbers are comensurate, i.e. the cache session has not been > =A0 changed." > > and again in 4.7: > "The Cache Nonce MUST be the same as that of the corresponding Cache > =A0 Response which began the, possibly null, sequence of data PDUs." > > There's not much meat to the actual change, and the authors identified > the problem on their own. So, in the spirit of valentines day, let's > decide by Friday Feb 18, 2011 23:59 UTC if things are still ok to move > forward. If there are no further comments/issues I'll push this > version out over the weekend to the AD's as a publication request. > > -Chris > > From pmohapat@cisco.com Fri Aug 19 23:47: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 3F0A821F8574 for ; Fri, 19 Aug 2011 23:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLKbizRx-2H4 for ; Fri, 19 Aug 2011 23:47:17 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4038D21F8568 for ; Fri, 19 Aug 2011 23:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pmohapat@cisco.com; l=2485; q=dns/txt; s=iport; t=1313822896; x=1315032496; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=qFg0q89JwrUb+l/65SSzsN6621Aelr5PM15O13j0flE=; b=R22XY2gNol6HMpmRn7smwwHqtgIRthRHs4p/Qh68GOuzJmKcAxcbr75t VLPJD02GfQIENYbYzxhnOBUURUV/m3TcmLQj1a1rLrq75207ynaLRX1hL ACVS4l/KKiqpyFo93EroJB45fxG8MJ8x5vssG+3oJMwcfKgmet0/wDkhn g=; X-IronPort-AV: E=Sophos;i="4.68,254,1312156800"; d="scan'208";a="14891998" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-6.cisco.com with ESMTP; 20 Aug 2011 06:48:15 +0000 Received: from sjc-vpn4-1308.cisco.com (sjc-vpn4-1308.cisco.com [10.21.85.27]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7K6mFN9016669; Sat, 20 Aug 2011 06:48:15 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Pradosh Mohapatra In-Reply-To: <8C46CE12-AA87-4DD2-B6A8-731D8AB72045@cisco.com> Date: Fri, 19 Aug 2011 23:53:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <08E36325-11E9-4997-90C7-FC0371CF2526@cisco.com> References: <20110711215154.14120.98609.idtracker@ietfa.amsl.com> <39DD9BDD-C1A8-43B3-9A69-CA8DB1E3E685@cisco.com> <8C46CE12-AA87-4DD2-B6A8-731D8AB72045@cisco.com> To: Roque Gagliano X-Mailer: Apple Mail (2.1084) Cc: "sidr@ietf.org wg" Subject: Re: [sidr] Fwd: I-D Action: draft-ietf-sidr-pfx-validate-02.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: Sat, 20 Aug 2011 06:47:18 -0000 Hi Roque, >>> Security Consideration: >>> I think you need to consider what you already mentioned in section = 4, if the connectivity to the local-caches is lost, invalid routes will = be classified as "not-found", which could have a different set of local = policies. >>=20 >> Is this different from current behavior? >=20 > Not sure what do you refer for "current behavior". My point was that = in the security considerations you should point to the analysis in = Section 4 on loosing connectivity to the cache servers. >=20 > Example: > Router set loc-pref 100 for "valid" and loc-pref 50 for = "not-found". > If the router looses connectivity with caches, either by = operational issues or by malicious event (on the cache/ the router or = the network between the two), the set of prefixes that should be "valid" = based on RPKI will be classified as "not found" and loc-pref set to 50. Does the following suffice for the security considerations section? Note = the added sentence in emphasis "_Similarly..." Although this specification discusses one portion of a system to validate BGP routes, it should be noted that it relies on a database (RPKI or other) to provide validation information. As such, the security properties of that database must be considered in order to determine the security provided by the overall solution. If "invalid" routes are blocked as this specification suggests, the overall system provides a possible denial-of-service vector, for example if an attacker is able to inject one or more spoofed records into the validation database which lead a good route to be declared invalid. _Similarly, if the connection to the cache is lost for = whatever reason, the integrity of the database is no longer maintained. This may result in undesired behavior._ In addition, this system is only = able=20 to provide limited protection against a determined attacker -- the=20 attacker need only prepend the "valid" source AS to a forged BGP=20 route announcement in order to defeat the protection provided by =20 this system. This mechanism does not protect against "AS in the=20 middle attacks" or provide any path validation. It only attempts to=20= verify the origin. In general, this system should be thought of more=20= as a protection against misconfiguration than as true "security" in=20= the strong sense. Thanks, - Pradosh= From rogaglia@cisco.com Mon Aug 22 04:14: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 A23FE21F8B22 for ; Mon, 22 Aug 2011 04:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWXOStVVhx7c for ; Mon, 22 Aug 2011 04:14:37 -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 80CEC21F8A91 for ; Mon, 22 Aug 2011 04:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=7294; q=dns/txt; s=iport; t=1314011741; x=1315221341; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=9nULZU5UigANrYVXjC69VtgqhfCML0VnzEO1+fh6jEs=; b=GbgiutWlQFcnwZb3ZclKPecCZDwXbc1HOOmxEbB3PTxvNzxhf69aUl25 +QQdguJts422XvizPmTQhNLNhlcotIxe1wwRvqh5xKKJHREILyBlViINf 4uoWKf/7f7UNXMoe5ETppL7Lqdqms69iJp8+UXvCRzB9Llh08z2h1y82Q M=; X-Files: smime.p7s : 4389 X-IronPort-AV: E=Sophos;i="4.68,262,1312156800"; d="p7s'?scan'208,217";a="51468467" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 22 Aug 2011 11:15:37 +0000 Received: from dhcp-144-254-20-205.cisco.com (dhcp-144-254-20-205.cisco.com [144.254.20.205]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7MBEkHH019385; Mon, 22 Aug 2011 11:15:37 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-293-697088556; protocol="application/pkcs7-signature"; micalg=sha1 From: Roque Gagliano In-Reply-To: <08E36325-11E9-4997-90C7-FC0371CF2526@cisco.com> Date: Mon, 22 Aug 2011 13:15:36 +0200 Message-Id: <6E77FE18-5CA8-4868-9C22-320831215087@cisco.com> References: <20110711215154.14120.98609.idtracker@ietfa.amsl.com> <39DD9BDD-C1A8-43B3-9A69-CA8DB1E3E685@cisco.com> <8C46CE12-AA87-4DD2-B6A8-731D8AB72045@cisco.com> <08E36325-11E9-4997-90C7-FC0371CF2526@cisco.com> To: Pradosh Mohapatra X-Mailer: Apple Mail (2.1084) Cc: "sidr@ietf.org wg" Subject: Re: [sidr] Fwd: I-D Action: draft-ietf-sidr-pfx-validate-02.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, 22 Aug 2011 11:14:37 -0000 --Apple-Mail-293-697088556 Content-Type: multipart/alternative; boundary=Apple-Mail-292-697087609 --Apple-Mail-292-697087609 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Pradosh, >=20 > Does the following suffice for the security considerations section? = Note the added sentence in emphasis "_Similarly..." Yes, looks good. Roque= --Apple-Mail-292-697087609 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi Pradosh,


Does the following suffice for the security considerations section? Note the added sentence in emphasis  "_Similarly..."

Yes, looks good.

Roque
--Apple-Mail-292-697087609-- --Apple-Mail-293-697088556 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXDCCBWYw ggROoAMCAQICEFyqcUyRFrhvN5s0SHw/EO4wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA1MTAwMDAwMDBaFw0x MjA1MTEyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5Sb3F1ZSBHYWdsaWFubzEhMB8GCSqGSIb3DQEJARYScm9nYWdsaWFAY2lz Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxIp28SUiJ/fiFYD/Nct8MUbG WJuPqSnhkfBYMFbbWfDDrHR8OXzK2LkWIuHY5aeAo1nalAQCO40oeTYt0cp9W++a7USNCEDQzgVN Rg0YMYL27YSQoVJnecO3u9wi0jjwhJGblWWxphaztdaMbqiChgND1PHqf7dcs4UjeUOhhKFk0/61 mTmduV721jrxj6ABIlUHAc7nXhKANtDbKdBZzEhM4dbzp6STKq65EQ3xRLVFIuapTgNVckvXtc1e Cyu4xLOLZgaD2aLq9JzBn9y/rFRMtf2euP/Nmzl7QRjAUjpPdo1n6NXWGDtNyR0lUrcJ/x1leccZ Gfj0eaqe+tpJmQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAG A1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29t L0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAsvqKrlga/tU0vyBtnBOj 4miDAZxou0/fN2wVEK7dRLzIQLYEJD35sELVhiP8v8wVHtgOeVHz9FyBEVqXmJ0RKy4kMC7gdQxj +t1MlqSTDShEaPMmiwaK6M1iJ9jpBL4JvoiirpHnQYGukkgvTUeqITWZ5ecg03nB3QHuab91Gc+n RZ1OKL4D4p5IkvzWhRlIAlxW9yGZyB8r9V6iu3+1SYEpPPUN3AYCxXeXrn8fJjkOoEodybRiGyfW pMpShpTZg2tHB7ZX162Ti3sRvwA2mktDMnBtEm1pXo15z7yieDUPmjVybMA4byV7AQcbIrjQj0eq c/biBsueC2KWoJY7TDCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEF BQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBG b3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5 MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwT j+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliW B6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGce dAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69s sQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOM Wev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0 cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtg hkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoG CCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCeg JYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4G CCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNV HREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN 7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqT OtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih /1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0D uFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRIfD8Q7jAJBgUr DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4 MjIxMTE1MzdaMCMGCSqGSIb3DQEJBDEWBBQg02GMXAjePLYbmEHLhCw9TW8WBTCCAQMGCSsGAQQB gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBcqnFMkRa4bzebNEh8PxDuMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRI fD8Q7jANBgkqhkiG9w0BAQEFAASCAQA+FwON9Rg+5Mp2TNv2Q8JEKKEnwPOUAcaIqS5wUxkiWpu7 BwgwUWK5QacLUNrPnHPDg8kCCUgwkMMGqnSYa7KFf5f6syTUv0KUhFS1C/JAykWEZRr8TgYcd7M2 Vm2yFFxuxYD8/qXkPlNWnqnqRH5S/fbklNzHRbdKOq/VjHFwZew7wye5ILvtHe2xELIvPhSzQ4sv Hsa2kpSkFaPsB9t7AhXtkAsqSjtwjTU7MGPwF+AyvXsWph+Rrvbj4n5yBBxuv06CuRcPjXkRInms 9AVmDeUU7kfgw+k+W8yBL4cst5woB3hYYTCHtyZnclO9mei+s7M/AVJ/GaBetSQ5NtShAAAAAAAA --Apple-Mail-293-697088556-- From ietfc@btconnect.com Mon Aug 22 05:05: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 D873721F8B1D; Mon, 22 Aug 2011 05:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVAXGPahlh8n; Mon, 22 Aug 2011 05:05:56 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr07.btconnect.com [213.123.26.185]) by ietfa.amsl.com (Postfix) with ESMTP id 4567E21F8B1C; Mon, 22 Aug 2011 05:05:52 -0700 (PDT) Received: from host109-153-79-81.range109-153.btcentralplus.com (HELO pc6) ([109.153.79.81]) by c2beaomr07.btconnect.com with SMTP id EBP98034; Mon, 22 Aug 2011 13:06:54 +0100 (BST) Message-ID: <001801cc60bb$19329d00$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Christopher Morrow" , , , "Randy Bush" References: Date: Mon, 22 Aug 2011 13:03:11 +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.0A0B0301.4E52465E.0039, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.8.22.104514:17:7.586, ip=109.153.79.81, 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, __FRAUD_BODY_WEBMAIL, __FRAUD_REFNUM, __CP_URI_IN_BODY, 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=c2beaomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4E52465F.0151,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] 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, 22 Aug 2011 12:05:58 -0000 Chris I don't know if your training included draft-ietf-tsvwg-iana-ports-10 currently in AUTH48 but it does say, as some on this list know well, " A service name or port number assignment request contains the following information. The service name is the unique identifier of a given service: Service Name (REQUIRED) Transport Protocol(s) (REQUIRED) Assignee (REQUIRED) Contact (REQUIRED) Description (REQUIRED) Reference (REQUIRED) Port Number (OPTIONAL) Service Code (REQUIRED for DCCP only) Known Unauthorized Uses (OPTIONAL) Assignment Notes (OPTIONAL)" which suggests a fairly rapid rejection of our I-D. The section on two ports or one, which I alluded to earlier, is section 7.2 which starts with " o IANA strives to assign only one assigned port number per service or application" Uh huh; I wish the iana I-D did not say what it says, and argued against it, in tsvwg and ietf, but it does and is about to become an RFC which will control our lives; sigh:-( Tom Petch ----- Original Message ----- From: "Christopher Morrow" To: ; ; "Randy Bush" Sent: Friday, August 19, 2011 6:00 AM Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? Hello, Waking a longishly dead thread to call some form of consensus on what is now rev16 of this draft: http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-16 I believe we cycled around most of the heated parts, finding compromise and reaching steady-state (last real message on this topic was 5 or so days ago). At this point I think we're safe to go forward to IESG review. I'll be packaging up a protos doc and mailing that forward tomorrow. -chris (co-chair-in-training) On Wed, Feb 16, 2011 at 1:39 PM, Christopher Morrow wrote: > Ok folk, > The rpki-rtr document: > > > went through WGLC on version ~02, it's since had a slight mod (added a > Cache-nonce added) which is here in section 4.1: > > "The Cache Nonce reassures the router that the serial numbers are > comensurate, i.e. the cache session has not been changed." > > and again in 4.2: > "The Cache Nonce tells the cache what instance the router expects to > ensure that the serial numbers are comensurate, i.e. the cache > session has not been changed." > > and again in 4.4: > "In response to a Reset Query, the Cache Nonce tells the router the > instance of the cache session for future confirmation. In response > to a Serial Query, the Cache Nonce reassures the router that the > serial numbers are comensurate, i.e. the cache session has not been > changed." > > and again in 4.7: > "The Cache Nonce MUST be the same as that of the corresponding Cache > Response which began the, possibly null, sequence of data PDUs." > > There's not much meat to the actual change, and the authors identified > the problem on their own. So, in the spirit of valentines day, let's > decide by Friday Feb 18, 2011 23:59 UTC if things are still ok to move > forward. If there are no further comments/issues I'll push this > version out over the weekend to the AD's as a publication request. > > -Chris > > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From christopher.morrow@gmail.com Mon Aug 22 06:16: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 4440D21F8B3D; Mon, 22 Aug 2011 06:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.256 X-Spam-Level: X-Spam-Status: No, score=-103.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RivilwDnBns; Mon, 22 Aug 2011 06:16:06 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8412121F85C6; Mon, 22 Aug 2011 06:16:06 -0700 (PDT) Received: by iye1 with SMTP id 1so9609781iye.27 for ; Mon, 22 Aug 2011 06:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=aSxWMh82eNd+t5ZM63RIF+vvyBMI8HBKBXzoFwMovh8=; b=k123V12dTxUI+1ecA6ppYSxb0Pptf2uh+yBwkuf1lDTsz4tjysIQnerG9irI5nLz/R R1wHxrvlhQdz1DY2LjUOLIR8adqFw0cNiSTlQHcefaaJwSo9zIg85r5U8YGha/eXSted al4HBo/DEMJCtKethymPCfUHCMm5+neuJRnyw= MIME-Version: 1.0 Received: by 10.231.4.99 with SMTP id 35mr5568248ibq.85.1314019031198; Mon, 22 Aug 2011 06:17:11 -0700 (PDT) Received: by 10.231.116.164 with HTTP; Mon, 22 Aug 2011 06:17:11 -0700 (PDT) In-Reply-To: <001801cc60bb$19329d00$4001a8c0@gateway.2wire.net> References: <001801cc60bb$19329d00$4001a8c0@gateway.2wire.net> Date: Mon, 22 Aug 2011 09:17:11 -0400 Message-ID: From: Christopher Morrow To: "t.petch" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr-chairs@ietf.org, sidr@ietf.org 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, 22 Aug 2011 13:16:07 -0000 On Mon, Aug 22, 2011 at 7:03 AM, t.petch wrote: > Chris > > I don't know if your training included > draft-ietf-tsvwg-iana-ports-10 > currently in AUTH48 but it does say, as some on this list know well, > it didn't. > " =A0 A service name or port number assignment request contains the > =A0 following information. =A0The service name is the unique identifier o= f > =A0 a given service: > > =A0 =A0 =A0Service Name (REQUIRED) > =A0 =A0 =A0Transport Protocol(s) (REQUIRED) > =A0 =A0 =A0Assignee (REQUIRED) > =A0 =A0 =A0Contact (REQUIRED) > =A0 =A0 =A0Description (REQUIRED) > =A0 =A0 =A0Reference (REQUIRED) > =A0 =A0 =A0Port Number (OPTIONAL) > =A0 =A0 =A0Service Code (REQUIRED for DCCP only) > =A0 =A0 =A0Known Unauthorized Uses (OPTIONAL) > =A0 =A0 =A0Assignment Notes (OPTIONAL)" > ok, so we had dealt with IANA requests after submission previously (I thought). We can do that here, or while I make a protos doc an author could spin a new rev with this data included, eh? Oddly, 'CONTACT' there is a person? or a WG? a 'person' seems non-scalable in a number of dimensions. :( -chris > which suggests a fairly rapid rejection of our I-D. =A0The section on two= ports or > one, which I alluded to earlier, is section 7.2 which starts with > " =A0 o =A0IANA strives to assign only one assigned port number per servi= ce > =A0 =A0 =A0or application" > > Uh huh; I wish the iana I-D did not say what it says, and argued against = it, in > tsvwg and ietf, but it does and is about to become an RFC which will cont= rol our > lives; sigh:-( > > Tom Petch > > ----- Original Message ----- > From: "Christopher Morrow" > To: ; ; "Randy Bush" > Sent: Friday, August 19, 2011 6:00 AM > Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? > > > Hello, > Waking a longishly dead thread to call some form of consensus on what > is now rev16 of this draft: > > http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-16 > > I believe we cycled around most of the heated parts, finding > compromise and reaching steady-state (last real message on this topic > was 5 or so days ago). > > At this point I think we're safe to go forward to IESG review. I'll be > packaging up a protos doc and mailing that forward tomorrow. > > -chris > (co-chair-in-training) > > On Wed, Feb 16, 2011 at 1:39 PM, Christopher Morrow > wrote: >> Ok folk, >> The rpki-rtr document: >> >> >> went through WGLC on version ~02, it's since had a slight mod (added a >> Cache-nonce added) which is here in section 4.1: >> >> "The Cache Nonce reassures the router that the serial numbers are >> comensurate, i.e. the cache session has not been changed." >> >> and again in 4.2: >> "The Cache Nonce tells the cache what instance the router expects to >> ensure that the serial numbers are comensurate, i.e. the cache >> session has not been changed." >> >> and again in 4.4: >> "In response to a Reset Query, the Cache Nonce tells the router the >> instance of the cache session for future confirmation. In response >> to a Serial Query, the Cache Nonce reassures the router that the >> serial numbers are comensurate, i.e. the cache session has not been >> changed." >> >> and again in 4.7: >> "The Cache Nonce MUST be the same as that of the corresponding Cache >> Response which began the, possibly null, sequence of data PDUs." >> >> There's not much meat to the actual change, and the authors identified >> the problem on their own. So, in the spirit of valentines day, let's >> decide by Friday Feb 18, 2011 23:59 UTC if things are still ok to move >> forward. If there are no further comments/issues I'll push this >> version out over the weekend to the AD's as a publication request. >> >> -Chris >> >> > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > From ietfc@btconnect.com Mon Aug 22 06:46: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 5A5F821F8B46; Mon, 22 Aug 2011 06:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFvFaw3tvZox; Mon, 22 Aug 2011 06:46:19 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by ietfa.amsl.com (Postfix) with ESMTP id E404921F8B43; Mon, 22 Aug 2011 06:46:17 -0700 (PDT) Received: from host109-153-79-81.range109-153.btcentralplus.com (HELO pc6) ([109.153.79.81]) by c2beaomr10.btconnect.com with SMTP id EAF12716; Mon, 22 Aug 2011 14:47:18 +0100 (BST) Message-ID: <002801cc60c9$1fe9a2c0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Christopher Morrow" References: <001801cc60bb$19329d00$4001a8c0@gateway.2wire.net> Date: Mon, 22 Aug 2011 14:42:59 +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.0A0B0303.4E525DE5.010E, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.8.22.124823:17:7.944, ip=109.153.79.81, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __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, __FRAUD_BODY_WEBMAIL, __FRAUD_REFNUM, __CP_URI_IN_BODY, BODY_SIZE_4000_4999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS, MULTIPLE_RCPTS X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0201.4E525DE9.01AA,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-chairs@ietf.org, sidr@ietf.org 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, 22 Aug 2011 13:46:20 -0000 ----- Original Message ----- From: "Christopher Morrow" To: "t.petch" Cc: ; ; "Randy Bush" Sent: Monday, August 22, 2011 3:17 PM Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? On Mon, Aug 22, 2011 at 7:03 AM, t.petch wrote: > Chris > > I don't know if your training included > draft-ietf-tsvwg-iana-ports-10 > currently in AUTH48 but it does say, as some on this list know well, > it didn't. > " A service name or port number assignment request contains the > following information. The service name is the unique identifier of > a given service: > > Service Name (REQUIRED) > Transport Protocol(s) (REQUIRED) > Assignee (REQUIRED) > Contact (REQUIRED) > Description (REQUIRED) > Reference (REQUIRED) > Port Number (OPTIONAL) > Service Code (REQUIRED for DCCP only) > Known Unauthorized Uses (OPTIONAL) > Assignment Notes (OPTIONAL)" > ok, so we had dealt with IANA requests after submission previously (I thought). We can do that here, or while I make a protos doc an author could spin a new rev with this data included, eh? Oddly, 'CONTACT' there is a person? or a WG? a 'person' seems non-scalable in a number of dimensions. :( Chris CONTACT can be a WG, the ietf or iesg, or even a person. My thinking was, be prepared for this to come back to us with a request for information, rather than spin a new draft; I suspect there will be other requests as well. I have been waiting for a port request to appear since the iana draft was approved and have not seen one - this may be the first. The port registry is one of those that IANA has converted to XML rendering it almost unusable:-( Tom Petch -chris > which suggests a fairly rapid rejection of our I-D. The section on two ports or > one, which I alluded to earlier, is section 7.2 which starts with > " o IANA strives to assign only one assigned port number per service > or application" > > Uh huh; I wish the iana I-D did not say what it says, and argued against it, in > tsvwg and ietf, but it does and is about to become an RFC which will control our > lives; sigh:-( > > Tom Petch > > ----- Original Message ----- > From: "Christopher Morrow" > To: ; ; "Randy Bush" > Sent: Friday, August 19, 2011 6:00 AM > Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? > > > Hello, > Waking a longishly dead thread to call some form of consensus on what > is now rev16 of this draft: > > http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-16 > > I believe we cycled around most of the heated parts, finding > compromise and reaching steady-state (last real message on this topic > was 5 or so days ago). > > At this point I think we're safe to go forward to IESG review. I'll be > packaging up a protos doc and mailing that forward tomorrow. > > -chris > (co-chair-in-training) > > On Wed, Feb 16, 2011 at 1:39 PM, Christopher Morrow > wrote: >> Ok folk, >> The rpki-rtr document: >> >> >> went through WGLC on version ~02, it's since had a slight mod (added a >> Cache-nonce added) which is here in section 4.1: >> >> "The Cache Nonce reassures the router that the serial numbers are >> comensurate, i.e. the cache session has not been changed." >> >> and again in 4.2: >> "The Cache Nonce tells the cache what instance the router expects to >> ensure that the serial numbers are comensurate, i.e. the cache >> session has not been changed." >> >> and again in 4.4: >> "In response to a Reset Query, the Cache Nonce tells the router the >> instance of the cache session for future confirmation. In response >> to a Serial Query, the Cache Nonce reassures the router that the >> serial numbers are comensurate, i.e. the cache session has not been >> changed." >> >> and again in 4.7: >> "The Cache Nonce MUST be the same as that of the corresponding Cache >> Response which began the, possibly null, sequence of data PDUs." >> >> There's not much meat to the actual change, and the authors identified >> the problem on their own. So, in the spirit of valentines day, let's >> decide by Friday Feb 18, 2011 23:59 UTC if things are still ok to move >> forward. If there are no further comments/issues I'll push this >> version out over the weekend to the AD's as a publication request. >> >> -Chris >> >> > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > From touch@isi.edu Mon Aug 22 09:00: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 A37C721F863A; Mon, 22 Aug 2011 09:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.959 X-Spam-Level: X-Spam-Status: No, score=-102.959 tagged_above=-999 required=5 tests=[AWL=-0.960, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 863SP34aWu+S; Mon, 22 Aug 2011 09:00:45 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 19F9521F853E; Mon, 22 Aug 2011 09:00:45 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p7MG1VPO014838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Aug 2011 09:01:34 -0700 (PDT) Message-ID: <4E527D5B.2080104@isi.edu> Date: Mon, 22 Aug 2011 09:01:31 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "t.petch" References: <001801cc60bb$19329d00$4001a8c0@gateway.2wire.net> In-Reply-To: <001801cc60bb$19329d00$4001a8c0@gateway.2wire.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: Christopher Morrow , sidr-chairs@ietf.org, sidr@ietf.org 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, 22 Aug 2011 16:00:45 -0000 Hi, Tom, On 8/22/2011 4:03 AM, t.petch wrote: > Chris > > I don't know if your training included > draft-ietf-tsvwg-iana-ports-10 > currently in AUTH48 but it does say, as some on this list know well, > > " A service name or port number assignment request contains the > following information. The service name is the unique identifier of > a given service: > > Service Name (REQUIRED) > Transport Protocol(s) (REQUIRED) > Assignee (REQUIRED) > Contact (REQUIRED) > Description (REQUIRED) > Reference (REQUIRED) > Port Number (OPTIONAL) > Service Code (REQUIRED for DCCP only) > Known Unauthorized Uses (OPTIONAL) > Assignment Notes (OPTIONAL)" > > which suggests a fairly rapid rejection of our I-D. Sure, but on trivial grounds (the service names you provide have spaces). To assist with your application, here's a suggestion (this need not be in the RFC, but the RFC should conform to the following information where it differs, e.g., the list of requested service names - note that this isn't guaranteed to fly, though, as per below): Service Name (REQUIRED) RPKI-Rtr Transport Protocol(s) (REQUIRED) TCP Assignee (REQUIRED) IESG (as per sec 8.1.1.) Contact (REQUIRED) IETF Chair Description (REQUIRED) request/response exchange, including an initial message indicating version number; data transferred as native records with in-band record separators and transaction terminators; transport connection is persistent across multiple request/response exchanges; exchanges MUST be protected by access control, and MAY use TCP MD5, TCP-AO, or IPsec Reference (REQUIRED) See RFC (TBD) Port Number (OPTIONAL) any in the well-known range Service Code (REQUIRED for DCCP only) N/A Known Unauthorized Uses (OPTIONAL) N/A Assignment Notes (OPTIONAL) Service Name (REQUIRED) RPKI-Rtr-TLS Transport Protocol(s) (REQUIRED) TCP Assignee (REQUIRED) (as per sec 8.1.1.) Contact (REQUIRED) IETF Chair Description (REQUIRED) request/response exchange, including an initial message indicating version number; data transferred as native records with in-band record separators and transaction terminators; transport connection is persistent across multiple request/response exchanges; exchanges MUST be protected by access control and TLS Reference (REQUIRED)See RFC (TBD) Port Number (OPTIONAL) any in the well-known range Service Code (REQUIRED for DCCP only) N/A Known Unauthorized Uses (OPTIONAL) N/A Assignment Notes (OPTIONAL) Regarding Chris's question: On 8/22/2011 6:17 AM, Christopher Morrow wrote: > Oddly, 'CONTACT' there is a person? or a WG? a 'person' seems > non-scalable in a number of dimensions. Again see Sec 8.1.1. It's a person (usually the person who issues the request) in all cases except IETF document stream assignments. > The section on two ports or > one, which I alluded to earlier, is section 7.2 which starts with > " o IANA strives to assign only one assigned port number per service > or application"\ This was updated as a result of IETF last call and IESG review. The current text (pending final typo corrections) reads as follows (the tracker here shows this:) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/writeup/ -- o IANA strives to assign only one assigned port number per service or application Note: At the time of writing of this document there is no IETF consensus on when it is appropriate to use a second port for an insecure version of a protocol. -- This is a bit of a sticky example, mostly because you're asking for a well-known port. It'd help to have IESG consensus on the use of an insecure protocol in that range. The current doc is a bit confusing on this point - do you ever intend to allow both insecure and TCP MD5/TCP-AO/IPsec on the same port? AFAICT, you actually want (need) three ports: RPKI-Rtr-open - insecure RPKI-Rtr-tnsec - transport/network security RPKI-Rtr-apsec - application-layer security (TLS) Then you need to explain clearly why you *cannot* determine which category a connection falls from the packets that arrive -- and performance alone is not a sufficient reason (that could then be used to argue, e.g., for dozens of ports for various services, and the port space is too limited to support that just for performance reasons). It seems like -open is an uphill issue if you ask for a well-known port, IMO. Joe From touch@isi.edu Mon Aug 22 09:04: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 5539321F89B8; Mon, 22 Aug 2011 09:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.944 X-Spam-Level: X-Spam-Status: No, score=-102.944 tagged_above=-999 required=5 tests=[AWL=-0.945, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+9npu9+nWEf; Mon, 22 Aug 2011 09:04:38 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id E66EB21F87F0; Mon, 22 Aug 2011 09:04:37 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p7MG5QRT016155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Aug 2011 09:05:26 -0700 (PDT) Message-ID: <4E527E46.7060002@isi.edu> Date: Mon, 22 Aug 2011 09:05:26 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "t.petch" References: <001801cc60bb$19329d00$4001a8c0@gateway.2wire.net> <002801cc60c9$1fe9a2c0$4001a8c0@gateway.2wire.net> In-Reply-To: <002801cc60c9$1fe9a2c0$4001a8c0@gateway.2wire.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: Christopher Morrow , sidr-chairs@ietf.org, sidr@ietf.org 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, 22 Aug 2011 16:04:38 -0000 On 8/22/2011 5:42 AM, t.petch wrote: ... > Oddly, 'CONTACT' there is a person? or a WG? a 'person' seems > non-scalable in a number of dimensions. :( > > Chris > > CONTACT can be a WG, the ietf or iesg, or even a person. Contact is always a person. It can be a role (WG-chair email, IETF chair, etc.), but it's always a person -- typically the person who issues the request for the port, FWIW. > My thinking was, be prepared for this to come back to us with a request for > information, rather than spin a new draft; I suspect there will be other > requests as > well. The doc needs to have sufficient information for IANA handling of the request, but the info in the doc on that point can change if needed (e.g., it's not unusual to ask for a port number and have the final RFC text include that value, which is assigned before AUTH48). > I have been waiting for a port request to appear since the iana draft was > approved and have not seen one - this may be the first. Port requests for IETF docs typically happen during the final assignment, and are generated automatically from the IANA actions portion of the doc. > The port registry is one of those that IANA has converted to XML rendering it > almost unusable:-( It would be useful to know (off-list if desired) why you have this view; the conversion was intended to make the information more useful to programs (e.g., than 'screen scraping'), more complete, and sortable on each field to show relationships more clearly. Joe From ietfc@btconnect.com Wed Aug 24 09:08: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 E52BA21F8C42; Wed, 24 Aug 2011 09:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cM0gb-gHqAY4; Wed, 24 Aug 2011 09:08:30 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by ietfa.amsl.com (Postfix) with ESMTP id A8ED521F8876; Wed, 24 Aug 2011 09:08:29 -0700 (PDT) Received: from host109-153-79-81.range109-153.btcentralplus.com (HELO pc6) ([109.153.79.81]) by c2beaomr10.btconnect.com with SMTP id EBA23763; Wed, 24 Aug 2011 17:09:25 +0100 (BST) Message-ID: <003f01cc626f$4d2d2d40$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Joe Touch" References: <001801cc60bb$19329d00$4001a8c0@gateway.2wire.net> <4E527D5B.2080104@isi.edu> Date: Wed, 24 Aug 2011 12:51:46 +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.4E552234.0067, actions=tag X-Junkmail-Premium-Raw: score=12/50, refid=2.7.2:2011.8.24.140615:17:12.455, ip=109.153.79.81, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __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, DATE_IN_PAST_03_06, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_WWW, __URI_NO_PATH, __PHISH_PHRASE2, __FRAUD_REFNUM, BODY_SIZE_5000_5999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS, MULTIPLE_RCPTS X-Junkmail-Status: score=12/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020B.4E552236.003A,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: Christopher Morrow , sidr-chairs@ietf.org, sidr@ietf.org 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, 24 Aug 2011 16:08:31 -0000 Joe Thanks for the information. I had missed the IESG update to the guidelines on Port allocation, which relaxes the constraints on a separate port for security a little. Also, from experience with requests to IANA for the specification of URI and such like schemes, where there is a pro forma which I always see in the requesting RFC, I had imagined that something similar would now be needed for Port number requests but perhaps not; and if there is, then you have provided it for us. Tom Petch ----- Original Message ----- From: "Joe Touch" To: "t.petch" Cc: "Christopher Morrow" ; ; ; "Randy Bush" Sent: Monday, August 22, 2011 6:01 PM > On 8/22/2011 4:03 AM, t.petch wrote: > > Chris > > > > I don't know if your training included > > draft-ietf-tsvwg-iana-ports-10 > > currently in AUTH48 but it does say, as some on this list know well, > > > > " A service name or port number assignment request contains the > > following information. The service name is the unique identifier of > > a given service: > > > > Service Name (REQUIRED) > > Transport Protocol(s) (REQUIRED) > > Assignee (REQUIRED) > > Contact (REQUIRED) > > Description (REQUIRED) > > Reference (REQUIRED) > > Port Number (OPTIONAL) > > Service Code (REQUIRED for DCCP only) > > Known Unauthorized Uses (OPTIONAL) > > Assignment Notes (OPTIONAL)" > > > > which suggests a fairly rapid rejection of our I-D. > > Sure, but on trivial grounds (the service names you provide have spaces). > > To assist with your application, here's a suggestion (this need not be > in the RFC, but the RFC should conform to the following information > where it differs, e.g., the list of requested service names - note that > this isn't guaranteed to fly, though, as per below): > > Service Name (REQUIRED) RPKI-Rtr > Transport Protocol(s) (REQUIRED) TCP > Assignee (REQUIRED) IESG (as per sec 8.1.1.) > Contact (REQUIRED) IETF Chair > Description (REQUIRED) request/response exchange, including > an initial message indicating version number; data transferred > as native records with in-band record separators and > transaction terminators; transport connection is > persistent across multiple request/response exchanges; > exchanges MUST be protected by access control, and MAY > use TCP MD5, TCP-AO, or IPsec > Reference (REQUIRED) See RFC (TBD) > Port Number (OPTIONAL) any in the well-known range > Service Code (REQUIRED for DCCP only) N/A > Known Unauthorized Uses (OPTIONAL) N/A > Assignment Notes (OPTIONAL) > > Service Name (REQUIRED) RPKI-Rtr-TLS > Transport Protocol(s) (REQUIRED) TCP > Assignee (REQUIRED) (as per sec 8.1.1.) > Contact (REQUIRED) IETF Chair > Description (REQUIRED) request/response exchange, including > an initial message indicating version number; data transferred > as native records with in-band record separators and > transaction terminators; transport connection is > persistent across multiple request/response exchanges; > exchanges MUST be protected by access control and TLS > Reference (REQUIRED)See RFC (TBD) > Port Number (OPTIONAL) any in the well-known range > Service Code (REQUIRED for DCCP only) N/A > Known Unauthorized Uses (OPTIONAL) N/A > Assignment Notes (OPTIONAL) > > Regarding Chris's question: > On 8/22/2011 6:17 AM, Christopher Morrow wrote: > > Oddly, 'CONTACT' there is a person? or a WG? a 'person' seems > > non-scalable in a number of dimensions. > > Again see Sec 8.1.1. It's a person (usually the person who issues the > request) in all cases except IETF document stream assignments. > > > The section on two ports or > > one, which I alluded to earlier, is section 7.2 which starts with > > " o IANA strives to assign only one assigned port number per service > > or application"\ > > This was updated as a result of IETF last call and IESG review. The > current text (pending final typo corrections) reads as follows (the > tracker here shows this:) > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/writeup/ > > -- > o IANA strives to assign only one assigned port number per service > or application > > Note: At the time of writing of this document there is no IETF consensus > on when it is appropriate to use a second port for an insecure version > of a protocol. > -- > > This is a bit of a sticky example, mostly because you're asking for a > well-known port. It'd help to have IESG consensus on the use of an > insecure protocol in that range. > > The current doc is a bit confusing on this point - do you ever intend to > allow both insecure and TCP MD5/TCP-AO/IPsec on the same port? > > AFAICT, you actually want (need) three ports: > > RPKI-Rtr-open - insecure > RPKI-Rtr-tnsec - transport/network security > RPKI-Rtr-apsec - application-layer security (TLS) > > Then you need to explain clearly why you *cannot* determine which > category a connection falls from the packets that arrive -- and > performance alone is not a sufficient reason (that could then be used to > argue, e.g., for dozens of ports for various services, and the port > space is too limited to support that just for performance reasons). > > It seems like -open is an uphill issue if you ask for a well-known port, > IMO. > > Joe From touch@isi.edu Wed Aug 24 12:19:27 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 A04FE21F8B81; Wed, 24 Aug 2011 12:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.299 X-Spam-Level: X-Spam-Status: No, score=-104.299 tagged_above=-999 required=5 tests=[AWL=1.700, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TecaWX82W3LP; Wed, 24 Aug 2011 12:19:26 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id D6C6321F8B4E; Wed, 24 Aug 2011 12:19:26 -0700 (PDT) Received: from [207.151.143.121] ([207.151.143.121]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p7OJJeEm020911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Aug 2011 12:19:49 -0700 (PDT) Message-ID: <4E554ECC.3020408@isi.edu> Date: Wed, 24 Aug 2011 12:19:40 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "t.petch" References: <001801cc60bb$19329d00$4001a8c0@gateway.2wire.net> <4E527D5B.2080104@isi.edu> <003f01cc626f$4d2d2d40$4001a8c0@gateway.2wire.net> In-Reply-To: <003f01cc626f$4d2d2d40$4001a8c0@gateway.2wire.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: Christopher Morrow , sidr-chairs@ietf.org, sidr@ietf.org 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, 24 Aug 2011 19:19:27 -0000 On 8/24/2011 3:51 AM, t.petch wrote: > Joe > > Thanks for the information. I had missed the IESG update to the guidelines on > Port allocation, which relaxes the constraints on a separate port for security a > little. > > Also, from experience with requests to IANA for the specification of URI and > such like schemes, where there is a pro forma which I always see in the > requesting RFC, I had imagined that something similar would now be needed for > Port number requests but perhaps not; and if there is, then you have provided it > for us. There's an online form at IANA, but they're in the process of updating it based on the I-D below. The info below answers the questions that apply for this protocol. Note, however, that there still remains an interesting question here - whether 1, 2, or 3 ports are really needed. 1 = insecure, out-of-band security (IPsec, TCP MD5, TCP-AO), in-band-sec (TLS) all on one port 2 = as per the current doc: - insecure and out-of-band (IPsec, TCP MD5, TCP-AO) (rpki-rtr) - TLS (rpki-rtr-tls) 3 = all three on separate ports Is there ever a reason that this service should exist as a totally open and insecure port? Also, is there a reason for not assuming that the out-of-band and in-band services cannot exist on the same port (other than performance of the connection establishment)? (IMO, this might be more of a sticking point if a well-known port is requested) Joe > ----- Original Message ----- > From: "Joe Touch" > To: "t.petch" > Cc: "Christopher Morrow";; > ; "Randy Bush" > Sent: Monday, August 22, 2011 6:01 PM >> On 8/22/2011 4:03 AM, t.petch wrote: >>> Chris >>> >>> I don't know if your training included >>> draft-ietf-tsvwg-iana-ports-10 >>> currently in AUTH48 but it does say, as some on this list know well, >>> >>> " A service name or port number assignment request contains the >>> following information. The service name is the unique identifier of >>> a given service: >>> >>> Service Name (REQUIRED) >>> Transport Protocol(s) (REQUIRED) >>> Assignee (REQUIRED) >>> Contact (REQUIRED) >>> Description (REQUIRED) >>> Reference (REQUIRED) >>> Port Number (OPTIONAL) >>> Service Code (REQUIRED for DCCP only) >>> Known Unauthorized Uses (OPTIONAL) >>> Assignment Notes (OPTIONAL)" >>> >>> which suggests a fairly rapid rejection of our I-D. >> >> Sure, but on trivial grounds (the service names you provide have spaces). >> >> To assist with your application, here's a suggestion (this need not be >> in the RFC, but the RFC should conform to the following information >> where it differs, e.g., the list of requested service names - note that >> this isn't guaranteed to fly, though, as per below): >> >> Service Name (REQUIRED) RPKI-Rtr >> Transport Protocol(s) (REQUIRED) TCP >> Assignee (REQUIRED) IESG (as per sec 8.1.1.) >> Contact (REQUIRED) IETF Chair >> Description (REQUIRED) request/response exchange, including >> an initial message indicating version number; data transferred >> as native records with in-band record separators and >> transaction terminators; transport connection is >> persistent across multiple request/response exchanges; >> exchanges MUST be protected by access control, and MAY >> use TCP MD5, TCP-AO, or IPsec >> Reference (REQUIRED) See RFC (TBD) >> Port Number (OPTIONAL) any in the well-known range >> Service Code (REQUIRED for DCCP only) N/A >> Known Unauthorized Uses (OPTIONAL) N/A >> Assignment Notes (OPTIONAL) >> >> Service Name (REQUIRED) RPKI-Rtr-TLS >> Transport Protocol(s) (REQUIRED) TCP >> Assignee (REQUIRED) (as per sec 8.1.1.) >> Contact (REQUIRED) IETF Chair >> Description (REQUIRED) request/response exchange, including >> an initial message indicating version number; data transferred >> as native records with in-band record separators and >> transaction terminators; transport connection is >> persistent across multiple request/response exchanges; >> exchanges MUST be protected by access control and TLS >> Reference (REQUIRED)See RFC (TBD) >> Port Number (OPTIONAL) any in the well-known range >> Service Code (REQUIRED for DCCP only) N/A >> Known Unauthorized Uses (OPTIONAL) N/A >> Assignment Notes (OPTIONAL) >> >> Regarding Chris's question: >> On 8/22/2011 6:17 AM, Christopher Morrow wrote: >> > Oddly, 'CONTACT' there is a person? or a WG? a 'person' seems >> > non-scalable in a number of dimensions. >> >> Again see Sec 8.1.1. It's a person (usually the person who issues the >> request) in all cases except IETF document stream assignments. >> >>> The section on two ports or >>> one, which I alluded to earlier, is section 7.2 which starts with >>> " o IANA strives to assign only one assigned port number per service >>> or application"\ >> >> This was updated as a result of IETF last call and IESG review. The >> current text (pending final typo corrections) reads as follows (the >> tracker here shows this:) >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/writeup/ >> >> -- >> o IANA strives to assign only one assigned port number per service >> or application >> >> Note: At the time of writing of this document there is no IETF consensus >> on when it is appropriate to use a second port for an insecure version >> of a protocol. >> -- >> >> This is a bit of a sticky example, mostly because you're asking for a >> well-known port. It'd help to have IESG consensus on the use of an >> insecure protocol in that range. >> >> The current doc is a bit confusing on this point - do you ever intend to >> allow both insecure and TCP MD5/TCP-AO/IPsec on the same port? >> >> AFAICT, you actually want (need) three ports: >> >> RPKI-Rtr-open - insecure >> RPKI-Rtr-tnsec - transport/network security >> RPKI-Rtr-apsec - application-layer security (TLS) >> >> Then you need to explain clearly why you *cannot* determine which >> category a connection falls from the packets that arrive -- and >> performance alone is not a sufficient reason (that could then be used to >> argue, e.g., for dozens of ports for various services, and the port >> space is too limited to support that just for performance reasons). >> >> It seems like -open is an uphill issue if you ask for a well-known port, >> IMO. >> >> Joe From paul.hoffman@vpnc.org Wed Aug 24 13:26: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 DAB9B21F8CA9; Wed, 24 Aug 2011 13:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.64 X-Spam-Level: X-Spam-Status: No, score=-102.64 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1MN8XkV1xo8; Wed, 24 Aug 2011 13:26:37 -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 5419421F8CA7; Wed, 24 Aug 2011 13:26:37 -0700 (PDT) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7OKRh1J040861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Aug 2011 13:27:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4E554ECC.3020408@isi.edu> Date: Wed, 24 Aug 2011 13:27:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <001801cc60bb$19329d00$4001a8c0@gateway.2wire.net> <4E527D5B.2080104@isi.edu> <003f01cc626f$4d2d2d40$4001a8c0@gateway.2wire.net> <4E554ECC.3020408@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1244.3) Cc: Christopher Morrow , sidr-chairs@ietf.org, sidr@ietf.org 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, 24 Aug 2011 20:26:38 -0000 On Aug 24, 2011, at 12:19 PM, Joe Touch wrote: > Is there ever a reason that this service should exist as a totally = open and insecure port? Given that it is explicitly listed in the draft, I find it worrisome = that you even ask the question. Caches and routers MUST implement unprotected transport over TCP using a port, RPKI-Rtr, to be assigned, see Section 12. Operators SHOULD use procedural means, ACLs, ... to reduce the exposure to authentication issues. > Also, is there a reason for not assuming that the out-of-band and = in-band services cannot exist on the same port (other than performance = of the connection establishment)? Those aren't enough !?!? --Paul Hoffman From touch@isi.edu Wed Aug 24 14:44: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 5F4AF21F8D7C; Wed, 24 Aug 2011 14:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.524 X-Spam-Level: X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=-0.925, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGPFkHRwWsa5; Wed, 24 Aug 2011 14:44:35 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id C7FFA21F8D5F; Wed, 24 Aug 2011 14:44:35 -0700 (PDT) Received: from [207.151.143.121] ([207.151.143.121]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p7OLjJOw014010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Aug 2011 14:45:29 -0700 (PDT) Message-ID: <4E5570EF.4020202@isi.edu> Date: Wed, 24 Aug 2011 14:45:19 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Paul Hoffman References: <001801cc60bb$19329d00$4001a8c0@gateway.2wire.net> <4E527D5B.2080104@isi.edu> <003f01cc626f$4d2d2d40$4001a8c0@gateway.2wire.net> <4E554ECC.3020408@isi.edu> 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: Christopher Morrow , sidr-chairs@ietf.org, sidr@ietf.org 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, 24 Aug 2011 21:44:36 -0000 On 8/24/2011 1:27 PM, Paul Hoffman wrote: > On Aug 24, 2011, at 12:19 PM, Joe Touch wrote: > >> Is there ever a reason that this service should exist as a totally open and insecure port? > > Given that it is explicitly listed in the draft, I find it worrisome that you even ask the question. > > Caches and routers MUST implement unprotected transport over TCP > using a port, RPKI-Rtr, to be assigned, see Section 12. Operators > SHOULD use procedural means, ACLs, ... to reduce the exposure to > authentication issues. I saw a declaration that this was required, but no REASON that unprotected transport was necessary. >> Also, is there a reason for not assuming that the out-of-band and > in-band services cannot exist on the same port (other than performance > of the connection establishment)? > > Those aren't enough !?!? "those"? I listed only one - performance. There are not enough ports to assign multiples just for performance reasons. Joe From paul.hoffman@vpnc.org Wed Aug 24 15:56: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 1C4FA21F8CF4; Wed, 24 Aug 2011 15:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.635 X-Spam-Level: X-Spam-Status: No, score=-102.635 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0xq0sSzjgwJ; Wed, 24 Aug 2011 15:56:13 -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 3116521F8CF0; Wed, 24 Aug 2011 15:56:13 -0700 (PDT) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7OMvLUS081480 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Aug 2011 15:57:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4E5570EF.4020202@isi.edu> Date: Wed, 24 Aug 2011 15:57:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6E68CE6B-920E-4A4C-AEB4-1E775C702284@vpnc.org> References: <001801cc60bb$19329d00$4001a8c0@gateway.2wire.net> <4E527D5B.2080104@isi.edu> <003f01cc626f$4d2d2d40$4001a8c0@gateway.2wire.net> <4E554ECC.3020408@isi.edu> <4E5570EF.4020202@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1244.3) Cc: Christopher Morrow , sidr-chairs@ietf.org, sidr@ietf.org 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, 24 Aug 2011 22:56:14 -0000 On Aug 24, 2011, at 2:45 PM, Joe Touch wrote: > On 8/24/2011 1:27 PM, Paul Hoffman wrote: >> On Aug 24, 2011, at 12:19 PM, Joe Touch wrote: >>=20 >>> Is there ever a reason that this service should exist as a totally = open and insecure port? >>=20 >> Given that it is explicitly listed in the draft, I find it worrisome = that you even ask the question. >>=20 >> Caches and routers MUST implement unprotected transport over TCP >> using a port, RPKI-Rtr, to be assigned, see Section 12. Operators >> SHOULD use procedural means, ACLs, ... to reduce the exposure to >> authentication issues. >=20 > I saw a declaration that this was required, but no REASON that = unprotected transport was necessary. Three paragraphs earlier in the document: Unfortunately, there is no protocol to do so on all currently used platforms. Therefore, as of this document, there is no mandatory to implement transport which provides authentication and integrity protection. This was discussed heavily in the WG. >>> Also, is there a reason for not assuming that the out-of-band and >> in-band services cannot exist on the same port (other than = performance >> of the connection establishment)? >>=20 >> Those aren't enough !?!? >=20 > "those"? I listed only one - performance. Sorry, I misread your parenthetical as "other than performance and = connection establishment". The idea that you can do TLS on the same port = as not-TLS has been widely debated. It was finally agreed (maybe not by = you) that the STARTTLS method for sharing a port may or may not be = appropriate for each protocol. When I look at this protocol, I do not = see a way to do it without completely rewriting the protocol = interactions. --Paul Hoffman From touch@isi.edu Wed Aug 24 17:07: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 7B9BD21F8781; Wed, 24 Aug 2011 17:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.216 X-Spam-Level: X-Spam-Status: No, score=-105.216 tagged_above=-999 required=5 tests=[AWL=1.383, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZaBpYWtvl95; Wed, 24 Aug 2011 17:07:17 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id A97A221F877B; Wed, 24 Aug 2011 17:07:17 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p7P07sf5028480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Aug 2011 17:07:54 -0700 (PDT) Message-ID: <4E55925A.90309@isi.edu> Date: Wed, 24 Aug 2011 17:07:54 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Paul Hoffman References: <001801cc60bb$19329d00$4001a8c0@gateway.2wire.net> <4E527D5B.2080104@isi.edu> <003f01cc626f$4d2d2d40$4001a8c0@gateway.2wire.net> <4E554ECC.3020408@isi.edu> <4E5570EF.4020202@isi.edu> <6E68CE6B-920E-4A4C-AEB4-1E775C702284@vpnc.org> In-Reply-To: <6E68CE6B-920E-4A4C-AEB4-1E775C702284@vpnc.org> 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: Christopher Morrow , sidr-chairs@ietf.org, sidr@ietf.org 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: Thu, 25 Aug 2011 00:07:18 -0000 On 8/24/2011 3:57 PM, Paul Hoffman wrote: > On Aug 24, 2011, at 2:45 PM, Joe Touch wrote: > >> On 8/24/2011 1:27 PM, Paul Hoffman wrote: >>> On Aug 24, 2011, at 12:19 PM, Joe Touch wrote: >>> >>>> Is there ever a reason that this service should exist as a totally open and insecure port? >>> >>> Given that it is explicitly listed in the draft, I find it worrisome that you even ask the question. >>> >>> Caches and routers MUST implement unprotected transport over TCP >>> using a port, RPKI-Rtr, to be assigned, see Section 12. Operators >>> SHOULD use procedural means, ACLs, ... to reduce the exposure to >>> authentication issues. >> >> I saw a declaration that this was required, but no REASON that unprotected transport was necessary. > > Three paragraphs earlier in the document: > > Unfortunately, > there is no protocol to do so on all currently used platforms. > Therefore, as of this document, there is no mandatory to implement > transport which provides authentication and integrity protection. I recall that discussion, but not the assertion that this would mean that you'd suggest using an insecure port. If that's the case, I strongly recommend NOT asking for a system port. > This was discussed heavily in the WG. > >>>> Also, is there a reason for not assuming that the out-of-band and >>> in-band services cannot exist on the same port (other than performance >>> of the connection establishment)? >>> >>> Those aren't enough !?!? >> >> "those"? I listed only one - performance. > > Sorry, I misread your parenthetical as "other than performance and > connection establishment". The idea that you can do TLS on the same port > as not-TLS has been widely debated. It was finally agreed (maybe not by > you) that the STARTTLS method for sharing a port may or may not be > appropriate for each protocol. When I look at this protocol, I do not > see a way to do it without completely rewriting the protocol interactions. Here I wasn't asking about TLS vs open, I was asking about TLS vs. IPsec/MD5/AO, and whether that has a different answer than TLS vs. open. Whether for this protocol or not, I would appreciate understanding that in more detail - even if off-list. I cannot see how the protocol matters if TLS is started or not on a per-connection basis since the TLS would wrap (or not) the data of the connect at the start. We can continue that off-list, though. Joe From internet-drafts@ietf.org Fri Aug 26 08:30: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 D002921F8A35; Fri, 26 Aug 2011 08:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKaSKPXS1VBm; Fri, 26 Aug 2011 08:30:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736A721F8834; Fri, 26 Aug 2011 08:30:56 -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.59 Message-ID: <20110826153056.18646.66246.idtracker@ietfa.amsl.com> Date: Fri, 26 Aug 2011 08:30:56 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rescerts-provisioning-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: Fri, 26 Aug 2011 15:30:56 -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 Protocol for Provisioning Resource Certificates Author(s) : Geoff Huston Robert Loomans Byron Ellacott Rob Austein Filename : draft-ietf-sidr-rescerts-provisioning-11.txt Pages : 32 Date : 2011-08-26 This document defines a framework for certificate management interactions between an Internet Number Resource issuer ("Issuer&qu= ot;) and an Internet Number Resource recipient ("Subject") through = the specification of a protocol for interaction between the two parties. The protocol supports the transmission of requests from the Subject, and corresponding responses from the Issuer encompassing the actions of certificate issuance, certificate revocation and certificate status information reports. This protocol is intended to be limited to the application of Internet Number Resource Certificate management and is not intended to be used as part of a more general certificate management framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rescerts-provisioning-1= 1.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-rescerts-provisioning-11= .txt From iesg-secretary@ietf.org Mon Aug 29 10:59: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 A50E221F8C45; Mon, 29 Aug 2011 10:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CZm3jo5Ng5k; Mon, 29 Aug 2011 10:59:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91E021F8C46; Mon, 29 Aug 2011 10:59:25 -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.60 Message-ID: <20110829175925.23727.41314.idtracker@ietfa.amsl.com> Date: Mon, 29 Aug 2011 10:59:25 -0700 Cc: sidr mailing list , sidr chair , RFC Editor Subject: [sidr] Protocol Action: 'A Protocol for Provisioning Resource Certificates' to Proposed Standard (draft-ietf-sidr-rescerts-provisioning-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: Mon, 29 Aug 2011 17:59:26 -0000 The IESG has approved the following document: - 'A Protocol for Provisioning Resource Certificates' (draft-ietf-sidr-rescerts-provisioning-11.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-rescerts-provisioning/ Technical Summary This document defines a framework for certificate management interactions between a resource issuer ("Issuer") and a resource recipient ("Subject") through the specification of a protocol for interaction between the two parties. The protocol supports the transmission of requests from the Subject, and corresponding responses from the Issuer encompassing the actions of certificate issuance, certificate revocation and certificate status information reports. This protocol is intended to be limited to the application of resource certificate management and is not intended to be used as part of a more general certificate management framework. Working Group Summary The working group progress with this draft has been smooth. The most contentious issue related to the use of TLS in the protocol. While the use of TLS seemed to be a generally good idea, the operational difficulties reported by users and implementers and the lack of any clear benefit from TLS convinced the working group to remove it from the protocol. Document Quality The document is well written and clear. There are independent implementations of this protocol and planned implementations, not by vendors but by RIRs who are the critical deployment points of this protocol. Personnel Sandra Murphy is the Document Shepherd for this document. Stewart Bryant is the Responsible Area Director. From holler_f@informatik.haw-hamburg.de Wed Aug 31 14:55: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 8977421F8ECC for ; Wed, 31 Aug 2011 14:55:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L95P3SQEvlMH for ; Wed, 31 Aug 2011 14:55:13 -0700 (PDT) Received: from wp197.webpack.hosteurope.de (wp197.webpack.hosteurope.de [IPv6:2a01:488:42::50ed:84cc]) by ietfa.amsl.com (Postfix) with ESMTP id B3E7D21F8EBD for ; Wed, 31 Aug 2011 14:55:13 -0700 (PDT) Received: from fholler.de ([46.4.186.47]); authenticated by wp197.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1Qysm2-00068e-VL; Wed, 31 Aug 2011 23:56:43 +0200 Date: Wed, 31 Aug 2011 23:56:41 +0200 From: Fabian Holler To: sidr@ietf.org Message-ID: <20110831215641.GE7965@fholler.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="42/8TDB0GUY6FXEm" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-bounce-key: webpack.hosteurope.de; holler_f@informatik.haw-hamburg.de; 1314827805; 9fe66cd4; Subject: [sidr] RTRlib 0.1 released 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, 31 Aug 2011 21:55:14 -0000 --42/8TDB0GUY6FXEm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi folks! We are pleased to announce the first beta release of the RTRlib. The library implements the RPKI-RTR client protocol in C and is based on draft-ietf-sidr-rpki-rtr-16 and draft-ietf-sidr-pfx-validate-02. The current release implements RTR-Sockets, which support SSH and unprotected TCP as transport layer. Automatic failover for multiple RTR servers is not yet implemented, but planned for the next release. The RTRlib 0.1 and its documentation is available at: http://rpki.realmv6.org/ Any feedback is highly welcome! best regards Fabian Holler --42/8TDB0GUY6FXEm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk5erhkACgkQeki1sRhDXQAJyQCdFnHq44yNqwvqqOJCPk4UwbbD ZzcAniPYhcoxrip8M+RCe0z5lNYAtEAa =HTuN -----END PGP SIGNATURE----- --42/8TDB0GUY6FXEm--