From ietf@meetecho.com Mon Oct 1 02:57:47 2012 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 BCC9121F860E for ; Mon, 1 Oct 2012 02:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.695 X-Spam-Level: * X-Spam-Status: No, score=1.695 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 Ox5f9naFH7lr for ; Mon, 1 Oct 2012 02:57:47 -0700 (PDT) Received: from smtplq01.aruba.it (smtplq-out13.aruba.it [62.149.158.33]) by ietfa.amsl.com (Postfix) with SMTP id 5A96F21F8608 for ; Mon, 1 Oct 2012 02:57:45 -0700 (PDT) Received: (qmail 20910 invoked by uid 89); 1 Oct 2012 09:57:41 -0000 Received: from unknown (HELO smtp8.aruba.it) (62.149.158.228) by smtplq01.aruba.it with SMTP; 1 Oct 2012 09:57:41 -0000 Received: (qmail 27954 invoked by uid 89); 1 Oct 2012 09:57:41 -0000 Received: from unknown (HELO ?143.225.229.163?) (alex@meetecho.com@143.225.229.163) by smtp8.ad.aruba.it with ESMTPA; 1 Oct 2012 09:57:41 -0000 Message-ID: <50696907.1020201@meetecho.com> Date: Mon, 01 Oct 2012 11:57:27 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtplq01.aruba.it 1.6.2 0/1000/N Subject: [sidr] Meetecho session recording available 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 Oct 2012 09:57:47 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of the SIDR session at IETF interim in Amsterdam is available. You can watch it by accessing the following URL: http://www.meetecho.com/ietf-interim/recordings For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From turners@ieca.com Mon Oct 1 11:49:23 2012 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 70ECD21F8917 for ; Mon, 1 Oct 2012 11:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.109 X-Spam-Level: X-Spam-Status: No, score=-102.109 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6Ocp9wZE6I1 for ; Mon, 1 Oct 2012 11:49:22 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [67.18.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id D4A7B21F8916 for ; Mon, 1 Oct 2012 11:49:22 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id CD63822110CA4; Mon, 1 Oct 2012 13:49:22 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id BBA9222110C52 for ; Mon, 1 Oct 2012 13:49:22 -0500 (CDT) Received: from [108.18.174.220] (port=53757 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TIl3S-0005Qf-6c; Mon, 01 Oct 2012 13:49:22 -0500 Message-ID: <5069E5B0.1040209@ieca.com> Date: Mon, 01 Oct 2012 14:49:20 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: sidr@ietf.org References: <50696907.1020201@meetecho.com> In-Reply-To: <50696907.1020201@meetecho.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:53757 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 15 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [sidr] Meetecho session recording available 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 Oct 2012 18:49:23 -0000 I watched/listened the meetecho recording through the HTML5 link. Pretty cool. Looking forward to the here's what I'm going to do as a result of the meeting email from Matt. BTW on 2.1 - my bad about forgetting that sending the NOTIFICATION message ends the sessions. Consider the comment withdrawn ;) spt On 10/1/12 5:57 AM, Meetecho IETF support wrote: > Dear all, > > the full recording (synchronized video, audio, slides and jabber room) > of the SIDR session at IETF interim in Amsterdam is available. > > You can watch it by accessing the following URL: > http://www.meetecho.com/ietf-interim/recordings > > For the chair(s): please feel free to put the link to the recording in > the minutes, if you think this might be useful. > > In case of problems with the playout, just drop an e-mail to > team@meetecho.com. > > Cheers, > the Meetecho team > From randy@psg.com Mon Oct 1 15:23:38 2012 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 1A8BA21F87AB for ; Mon, 1 Oct 2012 15:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 yIodhZE5Ty4Z for ; Mon, 1 Oct 2012 15:23:37 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 7C51E21F87A9 for ; Mon, 1 Oct 2012 15:23:37 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TIoOl-000Bsg-Pv; Mon, 01 Oct 2012 22:23:35 +0000 Date: Mon, 01 Oct 2012 23:23:34 +0100 Message-ID: From: Randy Bush To: Sean Turner In-Reply-To: <5069E5B0.1040209@ieca.com> References: <50696907.1020201@meetecho.com> <5069E5B0.1040209@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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Meetecho session recording available 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 Oct 2012 22:23:38 -0000 > I watched/listened the meetecho recording through the HTML5 link. > Pretty cool. i was really worried, as the hotel network had been horrid all week. but they turned out to have a second network, which was rather good for a hotel net. whew! randy From shane@castlepoint.net Mon Oct 1 19:22:19 2012 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 B93A51F0D44; Mon, 1 Oct 2012 19:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=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 zlBgrm95c3rB; Mon, 1 Oct 2012 19:22:19 -0700 (PDT) Received: from mail.tcb.net (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 191C91F0D5B; Mon, 1 Oct 2012 19:22:19 -0700 (PDT) Received: from mbpw.castlepoint.net (216-160-173-224.hlrn.qwest.net [216.160.173.224]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id DD96D430; Mon, 1 Oct 2012 20:22:15 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Shane Amante In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F62BEEFD1A@Hermes.columbia.ads.sparta.com> Date: Mon, 1 Oct 2012 20:22:22 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <21CAAAC9-79D3-460D-BEC2-F32742AD0E44@castlepoint.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F62BEEFD1A@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1498) Cc: "idr@ietf.org List" , "sidr@ietf.org list" Subject: Re: [sidr] comments on recent as migration drafts (draft-ga-idr-as-migration-00) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 02:22:19 -0000 Sandy, Adding IDR to response, since draft-ga-idr-as-migration-00 was submitted = to IDR. Trimming down to parts only relevant to = draft-ga-idr-as-migration-00. Please see below. On Sep 27, 2012, at 7:40 AM, "Murphy, Sandra" = wrote: > Speaking as regular ol' member. >=20 > Some comments about these drafts. [--snip--] > In the idr-as-migration draft, from the discussion it appears that the = implementation of the local-as feature on the PE router in AS supports = the local-as as something like an ebgp session inside the router. (like = it adds the old 300 ASN on AS_PATHs sent over ibgp sessions to AS 200 = neighbors). Am I understanding the examples correctly? I believe you are referring to Section 3, "Local AS". You are correct. Obviously, the implementers would have an authoritative answer to your = question, but I believe that the legacy ASN (AS 300) is actually applied = before the Adj-RIB-In. One important point to keep in mind is that the same PE will also have = eBGP sessions with other eBGP neighbors, (which may or may not be using = these AS migration features _outbound_). Thus, the easiest thing to = implement would be tacking on the legacy AS as the eBGP route is learned = and before it hits the Adj-RIB-In. This way, if it's selected as a = best-path, BGP can easily propagate that route "as-is" towards both iBGP = and other eBGP neighbors. > The goal is for the AS_PATH length to be the same length in the = migration interval as it was before migration. Does it matter if that = effect is accomplished some other way than the knobs currently = implemented? IE the local-as knob has a side effect of getting the 300 = ASN into the AS_PATH to ibgp neighbors so the second knob no-prepend = makes that go away. Do you need both behaviors -- local-as AND local-as = + no-prepend? Yes. Perhaps there is some confusion in the current draft talking about = the two knobs independently? In reality, the *only* behavior we want is = achieved through the combination of both local-as + no-prepend, in Cisco = IOS. If it makes you feel any better, JUNOS makes you also configure = two, separate (but related) knobs to get this behavior: "local-as = private", in the case of inbound eBGP updates. :-) > Would it be OK if the side effect did not happen and you got to the = no-increase-in-path-length goal without needing the no-prepend knob? That's not possible. IOW, the only way to achieve the = "no-increase-in-path-length goal" is to enable "no-prepend" in IOS or = "private" in JUNOS. I suspect that vendors (and, operators) will not be = clamoring to change the existing configuration of AS migration features = this late in the game, i.e.: to just configure them more simply with = just one keyword in the CLI ... > wrt the replace-as technique. The text says that "only the historical = (or, legacy) AS will be prepended in the outbound BGP UPDATE toward the = customer's network". But the example says "After ISP A' changes PE-1 to = include the "Replace AS" feature, CE-1 would receive an AS_PATH of: 200 = 400. " That is indeed "the same AS_PATH length pre-AS migration" as the = text says, which accomplishes that goal, but it would require = configuration of the CE router to accept a first-as that was different = from the one used in the OPEN. I suspect that's a typo, that is after = using replace-as the AS_PATH toward the CE would be "300 400". But it = is an important point so I'd like to make sure. You are correct, that is a typo. Thank you for finding that. We will = fix the text to be as follows in the next rev of the draft: ---snip--- By default, without "Replace AS" enabled, CE-1 would see an AS_PATH of: 300 200 400, which is artificially lengthened by the ASN Migration. After ISP A' changes PE-1 to include the "Replace AS" feature, CE-1 would receive an AS_PATH of: 300 400, which is the same AS_PATH length pre-AS migration. ---snip--- Thanks for your review. -shane= From shane@castlepoint.net Mon Oct 1 19:32:15 2012 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 E83961F0D44; Mon, 1 Oct 2012 19:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=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 i-rcuvCsoyyj; Mon, 1 Oct 2012 19:32:14 -0700 (PDT) Received: from mail.tcb.net (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1F89B1F0D5B; Mon, 1 Oct 2012 19:32:14 -0700 (PDT) Received: from mbpw.castlepoint.net (216-160-173-224.hlrn.qwest.net [216.160.173.224]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id 6A75F430; Mon, 1 Oct 2012 20:32:11 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Shane Amante In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F62BEEFF04@Hermes.columbia.ads.sparta.com> Date: Mon, 1 Oct 2012 20:32:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F62BEEFD1A@Hermes.columbia.ads.sparta.com>, <2671C6CDFBB59E47B64C10B3E0BD5923602AB34B@PRVPEXVS15.corp.twcable.com> <24B20D14B2CD29478C8D5D6E9CBB29F62BEEFF04@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1498) Cc: "idr@ietf.org List" , "sidr@ietf.org list" Subject: Re: [sidr] comments on recent as migration drafts (draft-ga-idr-as-migration-00) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 02:32:15 -0000 Sandy, Adding IDR to this response, as well. Please see below. On Sep 27, 2012, at 5:56 PM, "Murphy, Sandra" = wrote: > wrt: >=20 >>> In the idr-as-migration draft, from the discussion it appears that = the >>> implementation of the local-as feature on the PE router in AS = supports >>> the local-as as something like an ebgp session inside the router. = (like >>> it adds the old 300 ASN on AS_PATHs sent over ibgp sessions to AS = 200 >>> neighbors). Am I understanding the examples correctly? >> [WEG] Not exactly no. There's no additional internal eBGP session = between the=20 >> two ASNs on the PE, and remember that the PE has been reconfigured to = be in=20 >> the retained AS, not the legacy one, so this local-as and its related = switches are=20 >> used on the PE-CE sessions and their associated updates, not PE-PE. = All it's=20 >> doing is overriding the values from the global config that would = normally be=20 >> used to populate "MY ASN" and "AS_PATH" when generating BGP messages=20= >> to a specific neighbor. >=20 >=20 > No, I did not mean to suggest that there was an actual ebgp session. = I think maybe I was reading the replace-as example incorrectly. I am = not sure what the AS_PATH is when it is transmitted between PE1 and PE2 = and it looked like PE1 might be adding ASNs to the AS_PATH it sent over = the ibgp session to PE2. See my previous reply, but in short I believe that AS_PATH modifications = are, in this case, most likely made at the eBGP neighbor (where these AS = migration configurations are applied), since that isolates = modifications/state/etc. wrt the AS_PATH attribute to a single eBGP = neighbor. Of course, implementors should weigh-in if that is incorrect. = :-) =20 >>> from the one used in the OPEN. I suspect that's a typo, that is = after >>> using replace-as the AS_PATH toward the CE would be "300 400". But = it >>> is an important point so I'd like to make sure. >> [WEG] I think you're right that it's a typo, I'll doublecheck with my = co-author. > >> message. If the check determines this is not the case, the Error >> Subcode MUST be set to Malformed AS_PATH." >> I don't know if most common implementations perform this check. In = fact,=20 >> that's why I point out that the question needs to be answered as far = as path=20 >> validation is concerned - does the ASN of the established = neighborship have=20 >> to match the AS_Path or PATH_signatures or does it not matter as long = as the=20 >> signatures are all valid? Does that MAY need to be a MUST in BGPSec = land? >=20 > =46rom = http://www.cisco.com/en/US/docs/ios/12_3t/ip_route/command/reference/ip2_b= 1gt.html#wp1080615, "bgp enforce-first-as" default is enabled and it = means > To configure a router to deny an update received from an external BGP = (eBGP) peer that does not list its autonomous system (AS) number at the = beginning of the AS_PATH in the incoming update, use the bgp = enforce-first-as command in router configuration mode. >=20 > I think this is already a MUST in the protocol because the protocol = makes sure the AS listed are the ones that the packet came through. If = the update came from the neighbor and the first AS in the path is not = the neighbor's AS, then the validation will fail. (Unless the neighbor = has the keys to two ASs and uses an AS other than is used in the OPEN = packet. It's all about the keys.) WRT the above, "bgp enforce-first-as" ... as you pointed out there was a = typo in Section 4, "Replace AS", of draft-ga-idr-as-migration-00. The = last paragraph of that section should read: ---snip--- By default, without "Replace AS" enabled, CE-1 would see an AS_PATH of: 300 200 400, which is artificially lengthened by the ASN Migration. After ISP A' changes PE-1 to include the "Replace AS" feature, CE-1 would receive an AS_PATH of: 300 400, which is the same AS_PATH length pre-AS migration. ---snip---=20 And, in that case, even if/when the "bgp enforce-first-as" knob is = enabled at the CE router, (CE-1 in the diagram in the draft), then the = CE router is *still* going to receive AS 300 as the first AS in the = AS_PATH, even after the ISP A' changes their PE router to enable = 'replace-as'. Thus, this should not conflict with the "bgp = enforce-first-as" knob. Apologies for the typo. We'll fix in the next = rev. Thanks, -shane= From Sandra.Murphy@sparta.com Fri Oct 5 06:35:54 2012 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 DA1EC21F86D5 for ; Fri, 5 Oct 2012 06:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 y5zEY-pqtrdl for ; Fri, 5 Oct 2012 06:35:54 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3820F21F8691 for ; Fri, 5 Oct 2012 06:35:54 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q95DZrrU007398 for ; Fri, 5 Oct 2012 08:35:53 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q95DZmwJ029963 for ; Fri, 5 Oct 2012 08:35:53 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0379.000; Fri, 5 Oct 2012 09:35:47 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: agenda requests for IETF85 Thread-Index: Ac2i/lQFTW+vlS7vTy2YoyvWXeuZGQ== Date: Fri, 5 Oct 2012 13:35:47 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F62BEFE642@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] agenda requests for IETF85 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 Oct 2012 13:35:55 -0000 If you have a topic that you would like to see discussed at the IETF84 Atla= nta meeting, please send a request to the list.=0A= =0A= --Sandy, speaking as wg co-chair= From mlepinski.ietf@gmail.com Fri Oct 5 09:58:18 2012 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 9C80F21F87BE for ; Fri, 5 Oct 2012 09:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.652 X-Spam-Level: X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SS4vGniYxHQs for ; Fri, 5 Oct 2012 09:58:17 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9E021F87BD for ; Fri, 5 Oct 2012 09:58:17 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so5051403iec.31 for ; Fri, 05 Oct 2012 09:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ku4+jyoocFHkxpeW4PZM0AYitj+QVDvK0GAmA0lw2R4=; b=bn1ZoWLnaKjgpX4uk1mNfjnRvUCjyy4fb+Ykwb8qJbTfXQgKeoHoGxLsIZxBt9ZQHc eRyIn4kuNNP0MpXqvrOyN/yUjhdNNhU/JbDJPKPEIBP2rfwdjoehswi5y0SOtrBzz1CF libKbWqu8Q4RjkoboUoyN0dGJmRsgR3+peZd/bVTZdKZ7WiNP17ITzBBfr8PIAoptL2Z 9+x8Jo018yC7UFj5eZGpcMchPBOx9KAv4Eo5mMv/0P37PCt3In57A1pxgdFGMz3LryBV 0eCoJmoHMbpGNWhVUan6noHIcAY5+mukCgg1xy6jNE++0IOWK2ZynyobyWXOo+sYEOns H14Q== MIME-Version: 1.0 Received: by 10.50.12.168 with SMTP id z8mr1733363igb.74.1349456296666; Fri, 05 Oct 2012 09:58:16 -0700 (PDT) Received: by 10.231.76.82 with HTTP; Fri, 5 Oct 2012 09:58:16 -0700 (PDT) In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F62BEFE642@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F62BEFE642@Hermes.columbia.ads.sparta.com> Date: Fri, 5 Oct 2012 12:58:16 -0400 Message-ID: From: Matthew Lepinski To: "Murphy, Sandra" Content-Type: multipart/alternative; boundary=14dae93409b333e64404cb52c73c Cc: "sidr@ietf.org" Subject: Re: [sidr] agenda requests for IETF85 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 Oct 2012 16:58:18 -0000 --14dae93409b333e64404cb52c73c Content-Type: text/plain; charset=ISO-8859-1 Sandy, I would like a little bit of time to talk about draft-ietf-sidr-bgpsec-protocol to follow-up on the discussion at our interim meeting. - Matt Lepinski On Fri, Oct 5, 2012 at 9:35 AM, Murphy, Sandra wrote: > If you have a topic that you would like to see discussed at the IETF84 > Atlanta meeting, please send a request to the list. > > --Sandy, speaking as wg co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --14dae93409b333e64404cb52c73c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sandy,

I would like a little bit of time to talk about d= raft-ietf-sidr-bgpsec-protocol to follow-up on the discussion at our interi= m meeting.=A0

- Matt Lepinski

On Fri, Oct 5, 2012 at 9:35 AM, Murphy, Sandra <Sandra.Murphy@spart= a.com> wrote:
If you have a topic that you would like to see discussed at the IETF84 Atla= nta meeting, please send a request to the list.

--Sandy, speaking as wg co-chair
_______________________________________________
sidr mailing list
sidr@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sidr

--14dae93409b333e64404cb52c73c-- From achi@bbn.com Fri Oct 5 10:58:56 2012 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 80F1321F85C3 for ; Fri, 5 Oct 2012 10:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUg81HgA4X7Y for ; Fri, 5 Oct 2012 10:58:56 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1976221F85BB for ; Fri, 5 Oct 2012 10:58:56 -0700 (PDT) Received: from dhcp89-089-010.bbn.com ([128.89.89.10]:50099 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TKCAk-000NkF-Ve; Fri, 05 Oct 2012 13:58:51 -0400 Message-ID: <506F1FCE.5010000@bbn.com> Date: Fri, 05 Oct 2012 13:58:38 -0400 From: Andrew Chi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Murphy, Sandra" References: <24B20D14B2CD29478C8D5D6E9CBB29F62BEFE642@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F62BEFE642@Hermes.columbia.ads.sparta.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org" Subject: Re: [sidr] agenda requests for IETF85 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 Oct 2012 17:58:56 -0000 Assuming there's time, I'd like to give a brief update on BBN's RPKI validator testing (maybe to include gray areas). -Andrew On 10/5/2012 9:35 AM, Murphy, Sandra wrote: > If you have a topic that you would like to see discussed at the IETF84 Atlanta meeting, please send a request to the list. > > --Sandy, speaking as wg co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > From mlepinski.ietf@gmail.com Tue Oct 9 19:40:02 2012 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 7FE8B11E80F3 for ; Tue, 9 Oct 2012 19:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.636 X-Spam-Level: X-Spam-Status: No, score=-3.636 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 753tHmg1gcB5 for ; Tue, 9 Oct 2012 19:40:01 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7928721F86CA for ; Tue, 9 Oct 2012 19:40:01 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so30777iad.31 for ; Tue, 09 Oct 2012 19:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/w5fs73duT4BRcLgMgT82EgjasJAh/XZiRGYgh72aII=; b=MQEZN8qj31Huy6sk83BxouNuCV2L6mhegTQCGRJX5GeqXMNbxFv2cA37yxpo54U8PH aAvv8bIsxv+pcyg9sgnThpLXQEgy0Vkc5nHH8Mp38BbUx6zhwmNUL0N3vmgkFNSY5zst 4xtKmjkz9uqxUm2jM5Jf96Kv4skSxJY13Lvj7j7wWGT6CmkEj01+OWBGMOH8m4Uii+4f iGeWZiWBma1l8cdTch3pcbB0yY/16x/+OL6mwvH648FVSqw8dmVftjCHgmpl3CpFrPa6 nADOQ2FAihp6ISrsieglnlVjW5/9jeCOEKvJJQnUg+KESCnRvLpSyVrs8OFlF0mgKYW/ vZ3Q== MIME-Version: 1.0 Received: by 10.50.213.99 with SMTP id nr3mr3921615igc.16.1349836801068; Tue, 09 Oct 2012 19:40:01 -0700 (PDT) Received: by 10.231.76.82 with HTTP; Tue, 9 Oct 2012 19:40:01 -0700 (PDT) Date: Tue, 9 Oct 2012 22:40:01 -0400 Message-ID: From: Matthew Lepinski To: sidr@ietf.org Content-Type: multipart/alternative; boundary=14dae9399c7108505004cbab5ffc Subject: [sidr] Confirming that the last interim reflects working group concensus 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 Oct 2012 02:40:02 -0000 --14dae9399c7108505004cbab5ffc Content-Type: text/plain; charset=ISO-8859-1 At the interim meeting in Amsterdam, we had a discussion on open issues in draft-ietf-sidr-bgpsec-protocol-05. Here is a link to the slides that I presented at that meeting. ( http://www.ietf.org/proceedings/interim/2012/09/29/sidr/slides/slides-interim-2012-sidr-6-1.pdf ) I would like to confirm on the list that the discussions at the last interim reflect the consensus of the working group. In this message, I list for each open issue, my understanding of the sense of the room in Amsterdam. If you believe that for any of these issues that I may be misunderstanding the consensus of the working group, please start a discussion on the list as soon as possible. I am currently working on the -06 version of the protocol draft, therefore, if you have an objection to anything in this message, please raise it promptly. -------------------------------- 1.1. In referring to the data that is typically carried in the AS_PATH attribute, I will a phrase similar to "The sequence of ASes through which an update passes" 1.2 With regards to transport security, the document will specify "SHOULD" use transport security to protect BGP sessions. However, the document will NOT specify (as either a MUST or a SHOULD) and specific transport security mechanism. --14dae9399c7108505004cbab5ffc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable At the interim meeting in Amsterdam, we had a discussion on open issues in = draft-ietf-sidr-bgpsec-protocol-05.
Here is a link to the slides that I= presented at that meeting. (http://www.ietf.org/proceedings/interim/2012/09/29/sidr/slides/slides-= interim-2012-sidr-6-1.pdf)

I would like to confirm on the list that the discussion= s at the last interim reflect the=A0consensus=A0of the working group.=A0
In this message, I list for each open issue, my understanding of th= e sense of the room in Amsterdam. If you believe that for any of these issu= es that I may be misunderstanding the=A0consensus of the working group, ple= ase start a discussion on the list as soon as possible. I am currently work= ing on the -06 version of the protocol draft, therefore, if you have an obj= ection to anything in this message, please raise it promptly.

--------------------------------

1.1. In referring to the data that is typically carried in the AS_PATH a= ttribute, I will a phrase similar to "The=A0sequence of ASes through w= hich an update=A0passes"

1.2 With regards to transport security, the document wi= ll=A0specify=A0"SHOULD" use transport security to protect BGP ses= sions. However, the document will NOT specify (as either a MUST or a SHOULD= ) and specific transport security mechanism.


--14dae9399c7108505004cbab5ffc-- From mlepinski.ietf@gmail.com Tue Oct 9 20:36:07 2012 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 07E541F0417 for ; Tue, 9 Oct 2012 20:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.635 X-Spam-Level: X-Spam-Status: No, score=-3.635 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNsuKart3Hbc for ; Tue, 9 Oct 2012 20:36:06 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id C02D11F0C4A for ; Tue, 9 Oct 2012 20:36:05 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so147603iec.31 for ; Tue, 09 Oct 2012 20:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=NozwwcthAvAYbSWPgt0rT3aR2TqGzIbnqAFUMEka7iQ=; b=GqDVrX6p+yXtgyaC3Tii9lkKN0L56bMFim0Xgm+KzR2YYRLDHLlxX25U9DbOCArG7Y /2PNXIJERjKTt43YMTm9t9qrm57zy7cWL8cKXz7t1aLWmOLqiN8MhBqUT3MBNIt13a9/ TCmJAnhtDL2mlOGGmI70tIOLVi98h+c48qg6jrneclYAgTHd8Waz+vzQIUX3MyxJNw4t Ozbw5RlyiZ7NXbqHIHkcdGJJhS/Js5xEQ3RxzkQY9GCF/n9rqIi9RIq3y16iOqozZ0ad SF+LFbQBHXZi8qHecdM1XCqrax/uAhafUd8yV6T4dYuJLILFkMuol6hWaOMvoEPB+4zQ SaVw== MIME-Version: 1.0 Received: by 10.50.51.234 with SMTP id n10mr3996276igo.74.1349840165369; Tue, 09 Oct 2012 20:36:05 -0700 (PDT) Received: by 10.231.76.82 with HTTP; Tue, 9 Oct 2012 20:36:05 -0700 (PDT) Date: Tue, 9 Oct 2012 23:36:05 -0400 Message-ID: From: Matthew Lepinski To: sidr@ietf.org Content-Type: multipart/alternative; boundary=14dae93404958f76c504cbac275a Subject: [sidr] [fixed] Confirming that the last interim reflects working group consensus 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 Oct 2012 03:36:07 -0000 --14dae93404958f76c504cbac275a Content-Type: text/plain; charset=ISO-8859-1 Note: My apologies for the previous, incomplete, email. I accidently hit "Send" before the message was complete. At the interim meeting in Amsterdam, we had a discussion on open issues in draft-ietf-sidr-bgpsec-protocol-05. Here is a link to the slides that I presented at that meeting. ( http://www.ietf.org/proceedings/interim/2012/09/29/sidr/slides/slides-interim-2012-sidr-6-1.pdf ) I would like to confirm on the list that the discussions at the last interim reflect the consensus of the working group. In this message, I list for each open issue, my understanding of the sense of the room in Amsterdam. If you believe that for any of these issues that I may be misunderstanding the consensus of the working group, please start a discussion on the list as soon as possible. I am currently working on the -06 version of the protocol draft, therefore, if you have an objection to anything in this message, please raise it promptly. -------------------------------- 1.1. In referring to the data that is typically carried in the AS_PATH attribute, I will a phrase similar to "The sequence of ASes through which an update passes". 1.2. With regards to transport security, the document will specify "SHOULD" use transport security to protect BGP sessions. However, the document will NOT specify (as either a MUST or a SHOULD) and specific transport security mechanism. 1.3. There is no information in the current Editor's Notes that is worth retaining in future versions of the document 2.1. The document will recommend that if there is a failure to negotiate BGPSEC in a session with a peer, the BGP-speaker should fall back to BGP-4 without BGPSEC (instead of closing the session). 2.2. Unless someone comes to the list with a use-case for including SAFI in the BGPSEC capability advertisement, I will remove SAFI from the BGPSEC capability advertisement. 2.3. BGPSEC support and 4-byte ASN support are negotiated separately. However, the document will explicitly state that if 4-byte ASN support is not negotiated, then implementations shall consider BGPSEC to have not been negotiated. 2.4. The document should specify two separate BGP considerations: one for receiving BGPSEC, and one for sending of BGPSEC. 3.1. I will shorten the name of the BGPSEC_PATH_SIGNATURES attribute to BGPSEC_PATH attribute. 3.2. BGPSEC will not put Router_ID on the wire as part of the BGPSEC_PATH attribute. 3.3. My impression of the sense of the room in Amsterdam was that a majority of people were leaning towards removing the Additional_Info field form the BGPSEC_PATH attribute. However, several individuals spoke in favor of improving Additional_Info to be a more general extension mechanism. In the absence of discussion on the list, I will remove Additional_Info. However, I can see both sides of this issues and so I would be happy to see productive discussion of this on the list. 3.4. After discussion at the interim, I believe there is no issue here. I may add another pointer to the ops document if I can find a useful place to do so. 3.5. I will make sure the document is consistent throughout on the the issue of length fields. All length fields will include octets used to express the length itself. 4.1. When originating an update message within an AS. Whenever BGPSEC is negotiated on the i-BGP session, updates sent in this will be sent with a null BGPSEC_PATH attribute instead of a AS_PATH 5.1. I will change the names of the validation states to be "Valid" and "Not Valid". For now I am going to stay with two validation states. If you have a good use-case for three validation states, please bring it to the list. 5.2. There was no resolution to the issue of error handling at the interim. The options seem to be: (1) Normative reference to 4271; (2) Normative reference to the IDR error-handling draft; or (3) We pick a particular mechanism for error handling such as "treat as withdrawal", "drop session", or "drop update". Note: This is an area where guidance from the chairs would be very useful to the document editor! 5.3. The issue of deferred validation seemed to be a rat hole we want to avoid. The next version of the document will have less text on deferred validation. (In particular phrases like "as soon as possible" seem not to be helpful). The working group chairs will help the document authors get some implementer eyes on the -06 version of the document. If we get feedback that there is additional guidance on deferment that would be useful, we can always add something after Atlanta. 5.4. I will shrink the text on edge validation by combining the 2nd and 3rd sentence shown on the slide. In particular, I will avoid the phrase "MAY be conveyed via iBGP" and will instead go with something like "MAY be conveyed via some mechanism". 5.5. The protocol document will be silent on the issue of using the validation state. This type of issue will be left entirely to the bgpsec-ops document 5.6. I will add text to the document specifying that when RPKI state changes the router will re-run policy on all affected updates. I will look to 4271 to see if I can find any guidance in writing this text on re-evaluation of received updates. 5.7. I believe that a normative reference to rpki-rtr-keys draft. It was not clear to me whether an informative reference to rpki-rtr-keys is needed. However, based on discussion in Amsterdam, it seems that an informative reference to rpki-rtr-keys might be helpful. --14dae93404958f76c504cbac275a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Note: My apolog= ies for the previous, incomplete, email. I accidently hit "Send" = before the message was complete.

At the interim meeting in Amsterdam, we had a discussion on op= en issues in draft-ietf-sidr-bgpsec-protocol-05.
Here is a link to the slides that I presented at that meeting. (http= ://www.ietf.org/proceedings/interim/2012/09/29/sidr/slides/slides-interim-2= 012-sidr-6-1.pdf)

I would like to confirm on the list that the discussions at the last interi= m reflect the=A0consensus=A0of the working group.=A0
In this message, I list for each open issue, my understanding of the sense = of the room in Amsterdam. If you believe that for any of these issues that = I may be misunderstanding the=A0consensus of the working group, please star= t a discussion on the list as soon as possible. I am currently working on t= he -06 version of the protocol draft, therefore, if you have an objection t= o anything in this message, please raise it promptly.

--------------------------------

1.1. In referring to the data that is typically carried in the AS_PATH attr= ibute, I will a phrase similar to "The=A0sequence of ASes through whic= h an update=A0passes".

1.2. With r= egards to transport security, the document will=A0specify=A0"SHOULD&qu= ot; use transport security to protect BGP sessions. However, the document w= ill NOT specify (as either a MUST or a SHOULD) and specific transport secur= ity mechanism.

1.3. There is no information in the current Editor's Notes that is wort= h retaining in future versions of the document

2.1. The do= cument will recommend that if there is a failure to negotiate BGPSEC in a s= ession with a peer, the BGP-speaker should fall back to BGP-4 without BGPSE= C (instead of closing the session).

2.2. Unless someone comes to the list with a use-case for including SAFI in= the BGPSEC capability advertisement, I will remove SAFI from the BGPSEC ca= pability advertisement.

2.3. BGPSEC= support and 4-byte ASN support are negotiated separately. However, the doc= ument will explicitly state that if 4-byte ASN support is not negotiated, t= hen implementations shall consider BGPSEC to have not been negotiated.=A0

2.4. The document should specify two separate BGP considerations: one for r= eceiving BGPSEC, and one for sending of BGPSEC.

3.1. I will= shorten the name of the BGPSEC_PATH_SIGNATURES attribute to BGPSEC_PATH at= tribute.

3.2. BGPSEC will not put Router_ID on the wire as part of the BGPSEC_PATH a= ttribute.

3.3. My impress= ion of the sense of the room in Amsterdam was that a majority of people wer= e leaning towards removing the Additional_Info field form the BGPSEC_PATH a= ttribute. However, several individuals spoke in favor of improving Addition= al_Info to be a more general extension mechanism. In the absence of discuss= ion on the list, I will remove Additional_Info. However, I can see both sid= es of this issues and so I would be happy to see productive discussion of t= his on the list.

3.4. After discussion at the interim, =A0I believe there is no issue here. = I may add another pointer to the ops document if I can find a useful place = to do so.

3.5. I will= make sure the document is consistent throughout on the the issue of length= fields. All length fields will include octets used to express the length i= tself.

4.1. When originating an update message within an AS. Whenever BGPSEC is ne= gotiated on the i-BGP session, updates sent in this will be sent with a nul= l BGPSEC_PATH attribute instead of a AS_PATH=A0

5.1. I will= change the names of the validation states to be "Valid" and &quo= t;Not Valid". For now I am going to stay with two validation states. I= f you have a good use-case for three validation states, please bring it to = the list.

5.2. There was no resolution to the issue of error handling = at the interim. The options seem to be: (1) Normative reference to 4271; (2= ) Normative reference to the IDR error-handling draft; or (3) We pick a par= ticular mechanism for error handling such as "treat as=A0withdrawal&qu= ot;, "drop session", or "drop update".=A0
Note: This is an area where=A0guidance=A0from the = chairs would be very useful to the document editor!

5.3. The issue of deferred validation seemed to be a rat = hole we want to avoid. The next version of the document will have less text= on deferred validation. (In particular phrases like "as soon as possi= ble" seem not to be helpful). The working group chairs will help the d= ocument authors get some implementer eyes on the -06 version of the documen= t. If=A0we get feedback that there is additional=A0guidance on deferment th= at would be useful, we can always add something after Atlanta.

5.4. =A0= I will shrink the text on edge validation by combining the 2nd and 3rd sent= ence shown on the slide. In particular, I will avoid the phrase "MAY b= e conveyed via iBGP" and will instead go with something like "MAY= be conveyed via some mechanism".

5.5. The= protocol document will be silent on the issue of using the validation stat= e. This type of issue will be left entirely to the bgpsec-ops document

5.6. I w= ill add text to the document specifying that when RPKI state changes the ro= uter will re-run policy on all affected updates. I will look to 4271 to see= if I can find any guidance in writing this text on re-evaluation of receiv= ed updates.

5.7. I b= elieve that a normative reference to rpki-rtr-keys draft. It was not clear = to me whether an informative reference to rpki-rtr-keys is needed. However,= based on discussion in Amsterdam, it seems that an informative reference t= o rpki-rtr-keys might be helpful.


--14dae93404958f76c504cbac275a-- From danny@tcb.net Thu Oct 11 06:51:36 2012 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 7319121F876C for ; Thu, 11 Oct 2012 06:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 EZsr6znPBI+7 for ; Thu, 11 Oct 2012 06:51:35 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 780CA21F8768 for ; Thu, 11 Oct 2012 06:51:33 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 0CB862680CE; Thu, 11 Oct 2012 07:51:33 -0600 (MDT) Received: from dul1dmcphers-m2.home (pool-71-171-124-149.clppva.fios.verizon.net [71.171.124.149]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 11 Oct 2012 07:51:32 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.171.124.149; client-port=52478; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Danny McPherson In-Reply-To: Date: Thu, 11 Oct 2012 09:51:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Matthew Lepinski X-Mailer: Apple Mail (2.1283) Cc: sidr@ietf.org Subject: Re: [sidr] [fixed] Confirming that the last interim reflects working group consensus 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 Oct 2012 13:51:36 -0000 On Oct 9, 2012, at 11:36 PM, Matthew Lepinski wrote: >=20 > I would like to confirm on the list that the discussions at the last = interim reflect the consensus of the working group.=20 > In this message, I list for each open issue, my understanding of the = sense of the room in Amsterdam. If you believe that for any of these = issues that I may be misunderstanding the consensus of the working = group, please start a discussion on the list as soon as possible. I am = currently working on the -06 version of the protocol draft, therefore, = if you have an objection to anything in this message, please raise it = promptly. While I have no problem with this reflecting what occurred at the = interim meeting, I again don't think we can reach any sort of closure on = any of the bgpsec-proto work until the Threats and subsequent = Requirements documents are closed. =20 If the WG believes we don't need or should ignore those, then I'd really = like to just state that that's the case and continue as if they don't = matter or simply stop wasting cycles on them. -danny= From christopher.morrow@gmail.com Thu Oct 11 06:58:14 2012 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 783B221F8768 for ; Thu, 11 Oct 2012 06:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0p-x2d-5JaAA for ; Thu, 11 Oct 2012 06:58:14 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CBC7E21F8760 for ; Thu, 11 Oct 2012 06:58:13 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so2465985vcb.31 for ; Thu, 11 Oct 2012 06:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eqTWZvBR41ahz37BmGawZ3Jj3vz4ANvNIU42MNVhQfY=; b=Q4mRkEMXQ8YTWYfkAMj4RahpQ88ccGjWb+kPOg3s/2rXkhJTVzx8VXYfmG9RlvSz8U wjtNHkfJInRVK0URWjAC5RiLXiwR5d6r2q19TtfssFFHshUKYx1S0x2+Zj2Fv4E2iy6/ uxtFvt6qXStCP+yb2ybGw4rb+tg4j6zkqH+zf1taBlEoKaNYNCu2xMaFlUcfGZ6xwEKX YDa24BN2cPat0Tg6sve2ZgbRNxE148HS/5RVqTN8fEIhN8hRsJDrbmscpkxh9e1tSMOq WkLYJDIJjcY0EQ1IRfzON0irnQUMPgDulomJWNCUosMUNrBP0VVJqKo4tsyMgS7FG/aN jUwQ== MIME-Version: 1.0 Received: by 10.58.187.234 with SMTP id fv10mr552757vec.8.1349963893219; Thu, 11 Oct 2012 06:58:13 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.58.216.42 with HTTP; Thu, 11 Oct 2012 06:58:13 -0700 (PDT) In-Reply-To: References: Date: Thu, 11 Oct 2012 09:58:13 -0400 X-Google-Sender-Auth: JoG5ELaxqju8LMUzVlmcB8f8gzU Message-ID: From: Christopher Morrow To: Danny McPherson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] [fixed] Confirming that the last interim reflects working group consensus 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 Oct 2012 13:58:14 -0000 On Thu, Oct 11, 2012 at 9:51 AM, Danny McPherson wrote: > > On Oct 9, 2012, at 11:36 PM, Matthew Lepinski wrote: >> >> I would like to confirm on the list that the discussions at the last int= erim reflect the consensus of the working group. >> In this message, I list for each open issue, my understanding of the sen= se of the room in Amsterdam. If you believe that for any of these issues th= at I may be misunderstanding the consensus of the working group, please sta= rt a discussion on the list as soon as possible. I am currently working on = the -06 version of the protocol draft, therefore, if you have an objection = to anything in this message, please raise it promptly. > > While I have no problem with this reflecting what occurred at the interim= meeting, I again don't think we can reach any sort of closure on any of th= e bgpsec-proto work until the Threats and subsequent Requirements documents= are closed. > i had thought there was agreement at the last interim that threats/requirements needed to get baked before the protocol doc move to the next step in the process. From danny@tcb.net Thu Oct 11 07:59:58 2012 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 CF1E921F86C3 for ; Thu, 11 Oct 2012 07:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZPQ8lU4ZMei for ; Thu, 11 Oct 2012 07:59:58 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 5581221F86C1 for ; Thu, 11 Oct 2012 07:59:58 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 103EE268453; Thu, 11 Oct 2012 08:59:58 -0600 (MDT) Received: from dul1dmcphers-m2.home (pool-71-171-124-149.clppva.fios.verizon.net [71.171.124.149]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 11 Oct 2012 08:59:57 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.171.124.149; client-port=54719; syn-fingerprint=65535:48:1:64:M1460,N,W1,N,N,T,S MacOS 10.4.8; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Danny McPherson In-Reply-To: Date: Thu, 11 Oct 2012 10:59:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <871B5CE6-18DF-48B1-B845-D84F9B813632@tcb.net> References: To: Christopher Morrow X-Mailer: Apple Mail (2.1283) Cc: sidr wg Subject: Re: [sidr] [fixed] Confirming that the last interim reflects working group consensus 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 Oct 2012 14:59:58 -0000 On Oct 11, 2012, at 9:58 AM, Christopher Morrow wrote: > i had thought there was agreement at the last interim that > threats/requirements needed to get baked before the protocol doc move > to the next step in the process. While I am happy to hear this, it's not clear to me from the proceedings = available, can you please provide a pointer? -danny= From christopher.morrow@gmail.com Thu Oct 11 09:12:08 2012 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 147A321F8534 for ; Thu, 11 Oct 2012 09:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oZbplZfED8W for ; Thu, 11 Oct 2012 09:12:07 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 12B8B21F8508 for ; Thu, 11 Oct 2012 09:12:06 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so2230139vbb.31 for ; Thu, 11 Oct 2012 09:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1Nh46SDdvAZD0ZtEsGjgZV1Pqj+uVfJeNUYZsET+EQI=; b=cVyVUkB5Jjiowk7viX3YnV9WKTkJ49efFo5LUOhdDVbqPGP10yiBDkjPx+KgPAdJn5 6auDt3UXodU12ofheiga6BexNVPgJTK0lu8nGuyno/CuhlWWn4iDPU13c5655/RZ4RSO JmS4JXwiaqLD1O+Vlesu5bw5peY9qFn3tR3U7D5m58Qe/qikd3f4fyM5QQgsaUy7uiQp JpWLlvODTimHxKMudGq2Jr/oem2Qati3H1iW2gK2U/UAVVJge0FsslllD0DrRubNRIg2 SEHV/1B5kNkkuZcIgfY+RkefmVt0B/9bZqJXtOAJh4t/YPy/WwTeVq+LRk5ED0t3FYyN xmvw== MIME-Version: 1.0 Received: by 10.220.223.3 with SMTP id ii3mr711502vcb.74.1349971926460; Thu, 11 Oct 2012 09:12:06 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.58.216.42 with HTTP; Thu, 11 Oct 2012 09:12:06 -0700 (PDT) In-Reply-To: <871B5CE6-18DF-48B1-B845-D84F9B813632@tcb.net> References: <871B5CE6-18DF-48B1-B845-D84F9B813632@tcb.net> Date: Thu, 11 Oct 2012 12:12:06 -0400 X-Google-Sender-Auth: N8nBC2rOQZ36JUEbn_Hd8XG7Lfo Message-ID: From: Christopher Morrow To: Danny McPherson Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg Subject: Re: [sidr] [fixed] Confirming that the last interim reflects working group consensus 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 Oct 2012 16:12:08 -0000 On Thu, Oct 11, 2012 at 10:59 AM, Danny McPherson wrote: > > On Oct 11, 2012, at 9:58 AM, Christopher Morrow wrote: > >> i had thought there was agreement at the last interim that >> threats/requirements needed to get baked before the protocol doc move >> to the next step in the process. > > While I am happy to hear this, it's not clear to me from the proceedings available, can you please provide a pointer? sadly I can't find the notes on the interwebs... I'll see if we/chairs forgot to post them, or my search-foo with webcrawler is crap. I do note that there's a new revision ('new' as of 9/14-ish?) of threats: requirements is still june-only: Did you get a chance (I think you had some questions/comments/etc outstanding) to review -threats since 9/14? -chris From aservin@lacnic.net Thu Oct 11 09:25:00 2012 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 4964E21F84CE for ; Thu, 11 Oct 2012 09:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.775 X-Spam-Level: X-Spam-Status: No, score=-2.775 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBHtBa8eD+cN for ; Thu, 11 Oct 2012 09:24:59 -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 90E1921F8203 for ; Thu, 11 Oct 2012 09:24:59 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:5128:c039:a978:d446:9525]) by mail.lacnic.net.uy (Postfix) with ESMTP id 32A3A30846F; Thu, 11 Oct 2012 14:24:51 -0200 (UYST) Message-ID: <5076F2D3.4000000@lacnic.net> Date: Thu, 11 Oct 2012 14:24:51 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121005 Thunderbird/16.0 MIME-Version: 1.0 To: sidr@ietf.org, morrowc.lists@gmail.com References: <871B5CE6-18DF-48B1-B845-D84F9B813632@tcb.net> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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] [fixed] Confirming that the last interim reflects working group consensus 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 Oct 2012 16:25:00 -0000 Chris, I think that you and Sandy mentioned that draft-ietf-sidr-bgpsec-threats and draft-ietf-sidr-bgpsec-threats should be done before draft-ietf-sidr-bgpsec-protocol but it was just by email, I believe. http://www.ietf.org/mail-archive/web/sidr/current/msg05078.html http://www.ietf.org/mail-archive/web/sidr/current/msg05080.html I was not in the interim, so I do not know if you discussed the issue there again. Regards, as On 11/10/2012 14:12, Christopher Morrow wrote: > On Thu, Oct 11, 2012 at 10:59 AM, Danny McPherson wrote: >> >> On Oct 11, 2012, at 9:58 AM, Christopher Morrow wrote: >> >>> i had thought there was agreement at the last interim that >>> threats/requirements needed to get baked before the protocol doc move >>> to the next step in the process. >> >> While I am happy to hear this, it's not clear to me from the proceedings available, can you please provide a pointer? > > sadly I can't find the notes on the interwebs... I'll see if we/chairs > forgot to post them, or my search-foo with webcrawler is crap. > > I do note that there's a new revision ('new' as of 9/14-ish?) of threats: > > > requirements is still june-only: > > > Did you get a chance (I think you had some questions/comments/etc > outstanding) to review -threats since 9/14? > > -chris > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From internet-drafts@ietf.org Thu Oct 11 09:54:19 2012 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 B8BBB21F8629; Thu, 11 Oct 2012 09:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 apuiEZxxhww3; Thu, 11 Oct 2012 09:54:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90F321F852B; Thu, 11 Oct 2012 09:54:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121011165418.10880.66921.idtracker@ietfa.amsl.com> Date: Thu, 11 Oct 2012 09:54:18 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-10.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 16:54:20 -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 Group= of the IETF. Title : BGP Prefix Origin Validation Author(s) : Pradosh Mohapatra John Scudder David Ward Randy Bush Rob Austein Filename : draft-ietf-sidr-pfx-validate-10.txt Pages : 10 Date : 2012-10-11 Abstract: To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination AS of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-pfx-validate There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-pfx-validate-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-pfx-validate-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From eosterweil@verisign.com Thu Oct 11 11:06:58 2012 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 C67FE21F86FC for ; Thu, 11 Oct 2012 11:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvvP39AMc-xc for ; Thu, 11 Oct 2012 11:06:58 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id 0578B21F8685 for ; Thu, 11 Oct 2012 11:06:55 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKUHcKvFVz7aBymbmR8a4koAhB5XWGgiPs@postini.com; Thu, 11 Oct 2012 11:06:58 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q9BI6pmr022851; Thu, 11 Oct 2012 14:06:51 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.113]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Oct 2012 14:06:51 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <5076F2D3.4000000@lacnic.net> Date: Thu, 11 Oct 2012 14:06:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3CED4BB7-87DD-41D0-8491-D8308401B545@verisign.com> References: <871B5CE6-18DF-48B1-B845-D84F9B813632@tcb.net> <5076F2D3.4000000@lacnic.net> To: Arturo Servin X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 11 Oct 2012 18:06:51.0447 (UTC) FILETIME=[3059A470:01CDA7DB] Cc: sidr@ietf.org Subject: Re: [sidr] [fixed] Confirming that the last interim reflects working group consensus 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 Oct 2012 18:06:58 -0000 On Oct 11, 2012, at 12:24 PM, Arturo Servin wrote: > Chris, >=20 > I think that you and Sandy mentioned that > draft-ietf-sidr-bgpsec-threats and draft-ietf-sidr-bgpsec-threats = should > be done before > draft-ietf-sidr-bgpsec-protocol but it was just by email, I believe. >=20 > http://www.ietf.org/mail-archive/web/sidr/current/msg05078.html > http://www.ietf.org/mail-archive/web/sidr/current/msg05080.html >=20 > I was not in the interim, so I do not know if you discussed the = issue > there again. fwiw, I was at the interim, and I do recall the comment being made. =20 That said (and at the risk of stating the obvious), can we not agree = that the protocol draft will almost certainly need changes and/or an = overhaul depending on the scale of the changes that may be coming to the = threats and reqs drafts? I'm just thinking that if we are going to = continue to pursue those drafts as prerequisites, then iterating over = and polishing their derivative work (the protocol draft) now seems like = it may yield text that becomes obsoleted by those prerequisites, right? Eric= From Sandra.Murphy@sparta.com Thu Oct 11 11:20:12 2012 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 105BD11E809A for ; Thu, 11 Oct 2012 11:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.579 X-Spam-Level: X-Spam-Status: No, score=-100.579 tagged_above=-999 required=5 tests=[AWL=-1.780, BAYES_50=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_63=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwzgTOmKemkw for ; Thu, 11 Oct 2012 11:20:09 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA811F0381 for ; Thu, 11 Oct 2012 11:20:08 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q9BIJwdS017647 for ; Thu, 11 Oct 2012 13:19:58 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q9BIJq9T016978 for ; Thu, 11 Oct 2012 13:19:58 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0379.000; Thu, 11 Oct 2012 14:20:01 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: minutes from interim meeting Thread-Index: Ac2n1NHSyyMYEvkySQqhd/dMu4zB4g== Date: Thu, 11 Oct 2012 18:20:00 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F62BF035DC@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] minutes from interim meeting 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 Oct 2012 18:20:12 -0000 We had two minutes takers from the interim meeting on 29 Sep. They had dif= ferent styles of taking minutes. One set of minutes was more summarization= : noting topics and outcome of the discussion. One was more detailed: noti= ng details of the discussion and who made what comment.=0A= =0A= I myself find that both styles have benefit. Luckily the two minutes are p= retty synchronous with match points. I have melded the two, so there is a = topic and summary followed by the detailed discussion. =0A= =0A= I have checked against the recording when the minute taker was uncertain. = Aside from mis-spellings, anything I inserted is noted by .= =0A= =0A= The minutes are below and will be uploaded. Corrections should be sent to = the list.=0A= =0A= --Sandy, speaking as co-chair=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Interim meeting, 29 Sep 2012, Amsterdam, NL.=0A= =0A= Link to recording of meeting: http://www.meetecho.com/ietf-interim/recordin= gs=0A= =0A= =0A= =0A= =0A= Matt: Planning to remove Editor's notes in next ver=0A= =0A= 4. Failure to negotiate BGPSEC successfully with a neighbor should result i= n falling back to negotiating BGP-4.=0A= =0A= Details of discussion:=0A= =0A= Matt: Negotiation errors - RFC5492 says if you fail to negotiate a capabili= ty you might send a bgp notification message and close the session. =0A= If I want bgpsec and my neighbor doesn't we fall back to regular bgp4 - my = proposal is to reccomend falling back to bgp4 and not close the session=0A= Would like feedback if anyone would prefer to fail the session: =0A= Chris: it sounds like an implementation choice - ask for a knob from vendor= - you don't want a situation where you can't have a bgpsec router talk to = a non bgpsec router=0A= Matt: recommend adding a sentence that says fallback recommended, closing i= s fine=0A= Rudiger: I think we need to know when the session comes up, which policy to= push - whether bgpsec came up or regular bgp4=0A= Randy: It's not bidirectional - you should know whether you can send or rec= eive etc Current doc does not document that you can be send only=0A= Matt: I'll fix that=0A= =0A= 5. Non-null SAFI: Matt will take it to the mailing list to see if anyone wa= nts its inclusion. Rob: All rpki implementations are affected if you change= the specification to include non-null SAFI.=0A= =0A= Details of discussion:=0A= =0A= Matt: SAFI - Do we need a safi present flag? =0A= Rob: The actual question is do we need a safi field at all? You are only al= lowed to use v4/v6 unicast with null safi. If we decide we want safi, =0A= then in order to express what's in 3779(?) we need a flag=0A= Matt: is there is a use case for non-null safi in bgpsec ver0=0A= Some guy : Suppose I have non-complement ... from the same AS (mcast?)=0A= Matt: This version does not handle mcast - you have to send without protect= ion your mcast=0A= Rudiger: The origin validation is only for unicast -- protecting the ASpath= perse could be of value for people doing strange address families=0A= Matt: Take to list - unless someone on list comes up with use case, then we= will take it out=0A= =0A= 6. 4-byte ASN: Does negotiating bgpsec mean negotiating 4-byte asn also. No= , you may negotiate 4-byte asn but not bgpsec. So have separate negotiation= s for the two capabilities.=0A= =0A= Details of discussion:=0A= =0A= Matt: Negotiation of 4byte AS=0A= You need to support 4byte AS's - doesn't support 3byte hack=0A= What happens when a speaker does not support 4byte AS? Do we close the sess= ion?=0A= Some guy : If I say bgpsec, and my neighbor says AS4 - then we do really wa= nt to negotiate AS4=0A= Matt: seemed to get it=0A= =0A= 7. BGPSEC capability negotiation: Have 2 separate messages, one for send an= d another for receive. Rob: Do 2unless you are short of capabilities. But d= on=92t do subtyping, i.e. put one under another.=0A= =0A= Details of discussion:=0A= =0A= BGPsec has 2 options - I want to send you bgpsec and I'm willing to receive= bgpsec=0A= I may not want to do sig valid, but do want to generate sigs=0A= I might trust my upstream to do this hard validation stuff and just generat= e my sigs=0A= Is this an ok situation or a fail to negotiate=0A= Randy: why don't we send 2 different capability messages, instead of 1 mess= age with 2 bit flags for send/receive=0A= Wilifred : you should allow this situation=0A= Matt: Currently you send 2 capability msgs (v4/v6) so now you would send =0A= Heather: What is the harm of sending both=0A= Rob: Don't add another one =0A= Matt: proposal is to keep it separate=0A= =0A= 8. BGPSEC_PATH_SIGNATURES attribute name: Simplify to BGPSEC_PATH.=0A= =0A= Details of discussion:=0A= =0A= Name of the attribute: anyone have a prob renaming - No=0A= =0A= 9. Router ID inclusion in the update: Final decision was not to include it = in the BGPSEC update. Discussion: Steve Kent: SKI which is a hash of public= key is extraordinarily likely to be unique. Router ID has significance bet= ween immediate neighbors; irrelevant two hops way. It is not relevant from = a correctness point of view (in BGPSEC updates). Rob agrees with Steve. Con= sensus in the room for not including.=0A= =0A= Details of discussion:=0A= =0A= Router ID's=0A= reccomends that routers have a subject name that includes a router-id ident= ifying a router=0A= do we add router-id as an unsiugned field right next to ski in bgpsec attr?= =0A= if we don't a large number od certs matching a given as must be sifted thro= ugh=0A= Does it make the validation code simpler/faster?=0A= Rudiger: router id is a phrase that is used =0A= Sandy: you can put whatever you want in the router id field if you want to = identify a set of routers=0A= Steve: which fits in the field. There is a subject name which is a charact= er string --- My argument is no we don't need it because the hash of the p= ublic key is likely to be unique to begin with=0A= if at one end the knob says every router gets a different cert with a diffe= rent pub k -- or different keys. On either end there is no problem. It's = very likely to not be a big deal. I think the =0A= likelyhood of collisions is small. =0A= Matt: current text suggests when you talk to cache you should filter by ASN= then by ski. Someone suggested that there was potentional of DoS attack i= f someone generates millions =0A= Steve: described ways to forge=0A= Randy: problem occurs when you are in the middle. (One key in America, one= key in aspac) A router key is compromised in one region - idea is to restr= ict compromise to one continent, and you can't know unless the router id is= in the update=0A= Sriram: ...=0A= Matt: Do I have information in my bgpsession that I can check my router id = against so that I know which one the peer is using=0A= Randy: It's not the peer, because it can be several hops away=0A= Matt: if we put in routerid in the update msg, I can't check to make sure e= veryone in path was using the right router id =0A= Randy: If you glom that up you don't have that assurance=0A= Matt: is that a useful assurance - is it useful to be able to check which k= ey the peer is using =0A= Randy: I would use artificial routerids - in bgp they are only unique to an= AS -- =0A= Chris: whether you are at the 1 key per router, or 1 key per AS, the peer o= nly knows you signed a msg with a key, this is a troubleshooting and later = validation issue=0A= It's misleading to call this router id. Its an identifier for this key and = everything that was signed by it.=0A= Rob: from the cert side, I'm with steve=0A= Steve: idea was when we open a connection between a pair of routers, immedi= ate peer can check the guy who he thinks is configured, once you are more t= han 1 hop away this is irrelevant=0A= you are checking for consistency to the AS, not to a specific router. Imme= diate neighbor stops being interesting when you don't have a 1-to-1 =0A= Matt: signing over routerid isn't useful if....=0A= Steve: you don't have to have routerid in there - its not relevant more tha= n 1 hop away. Once you revoke a key, well you've killed the key and it can= 't be used anymore=0A= Chris: thinking about this as routerid is a problem - think about it as ran= dom number that is 32 bits long=0A= Randy: in the update that I outbound sign, my key in rpki is bound to that = nonce, that allows me to protect a compromise on router A from compromise o= n router B=0A= Matt: there is a compromised router and a good one. the compromised router= can use his comp'd key to sign on behalf of your AS, your concern is that = if my comp in NA you don't want asia to be signing=0A= =0A= Matt: what I have heard is that no one can provide a concrete security bene= fit for putting the router id in this doc - I will make this assertion on t= he mailing list - if anyone finds a usecase on the list, we'll sort it on t= he list=0A= =0A= 10. Reserved field in the Update: Historically it is there because it was o= riginally meant to be used for Expire Time (a method of replay protection).= Its usability is good for protocol extension (expire time or other use) at= the origin only. Jari Arko: You can add one TLV mechanism for one purpose = using this. Randy: =93If you design an extension carefully, it would have a= 25% chance of designing for future. Since this was thought of for a specif= ic purpose, it has much smaller chance.=94 Sriram: =93I am neutral but we m= ay like to wait a few months before removing it until the replay protection= mechanism gets fully finalized. Periodic Key Rollover is something to be c= onsidered for its merits, and it is similar to Expire Time method. He said = he and Doug wrote a document (announced it on the SIDR list on September 21= ) which discusses all the pros and cons in detail about different replay pr= otection method.=94 Matt: Room seems to be leaning towards removing it; we = will take it to the mailing list.=0A= =0A= Details of discussion:=0A= =0A= Additional info - is it useful?=0A= add'l info - signed origin added blob of bits when we took out expire_time.= Some folks though we may in the future want to add expire_time or signing= _time or something to support better protection against replay or other iss= ues=0A= Allows origin to assert something under sig, and allows us to support possi= ble extension mechanism=0A= is this still useful, is the current spec good enough=0A= if we go from ver 0 to ver 1 we lose backward compatibility - =0A= Rob: I don't know if we need ext mechanism - I'm not convinced this is usef= ul. This is only good for originator only, as opposed to a long path. Thi= s is taylor made for 1 ext we may never make. I won't stand in the way but = not seeing a strong argument in favor=0A= Guy w/ pink dot on badge (Jari? Jani?): It's useful that you can add exactly one TLE=0A= Matt: I'm all for making this better if anyone has suggestions=0A= Randy: be honest, this is restrictive extension mechanism not really design= ed as such - it's a vestigal organ, it's dead. If you want an ext mechanis= m, design one=0A= Rob: If you actually want an ext mech, look at the ipv4 header =0A= Matt: 2 things proposed - make it more general or kill it -- Rob and Randy= that says kill it. =0A= Chris: are we sure we never want to add anything more at the origin end. = =0A= Randy: ...that's compatible with this=0A= Matt: anything added needs to be able to be ignored by someone who doesn't = understand this - so if its a security thing we don't want them to ignore= =0A= Sriram: not in favor or against - expire_time in origin made the update exp= ire at a certain time- key rollover replaced this. Periodic key rollover mi= mics this. If someone thinks expire_time is better because it doesn't crea= te churn (key rollover has churn) so maybe=0A= we keep it and see if someone is concerned about the churn. I'm neutral on = this=0A= Matt: No other comments? To the list.. the room is leaning toward kill it= =0A= =0A= 11. =0A= =0A= Non-bgpsec stuff in your AS=0A= =0A= Details of discussion:=0A= =0A= Matt: Attr is currently non-transitive - if you send to a speaker that does= n't understand, they drop it. Will RR strip?=0A= Rudiger: no=0A= Randy: bgpsec ops doc says.. rr must have bgpsec enabled if/oif there are b= gpsec speakers in their client cone=0A= Matt: should this doc need to have a pointer to ops discussion of those con= siderations. It was suggested that this might be a prob=0A= Chris: monitoring comes up - If an rr doesn't accept bgpsec I wouldn't send= them bgpsec data (wouldn't have negotiated) path constructed based on bgps= ec and fwd'd=0A= Matt: if I have a mixture of bgpsec and non-bgpsec speakers in my AS, is th= at a problem=0A= Chris: 2 routers hear same prefix - one may choose it, one may not -- i mig= ht say, I trust my bgpsec speaking routers more than those that dont=0A= Matt: I don't think there is a problem here - Sandy agree (you made the com= ment)=0A= Sandy: Yes=0A= =0A= 12. Length field: Rob: Traditionally the header in included in the length f= ield; keep it that way. Decision: Length field value will include the overh= ead bytes used for the length field itself.=0A= =0A= Details of discussion:=0A= =0A= Does the value of length field inc octets used to express length field=0A= Matt: I want to make them all the same =0A= Rob: 2 obvious right answers - historically these include the length of hea= der, wrong decision 30 years ago, but we kept going with it -- not worth ch= anging=0A= Matt: I will go through and make sure this is consistent in the way rob sug= gested 9 (see slide) include length octets in length calculation=0A= =0A= 13. Null BGP-4 AS_PATH or Null BGPSEC_PATH from originating router to egres= s router: Randy : =93If originating router is BGP-4, then it will send Null= BGP-4 AS_PATH. If it is BGPSEC and knows the egress is BGPSEC, it will sen= d Null BGPSEC_PATH.=94 Question (note taker): How does the originating rout= er know if the egress router does BGPSEC or BGP-4 only?=0A= =0A= Details of discussion:=0A= =0A= Originating an update:=0A= Matt: Inside my AS a router originates a prefix, currently it creates an em= pty AS path, when it hits the edge it creates a aspath --- When bgpsec spea= kers are talkign to each other=0A= using signed update msg. ..... do I want my bgpsec speaker in the middle t= alking to the edge producing an unsigned msg ... reasonable approach: insid= e my AS I send empty aspath until it gets to the edge where it gets added= =0A= Randy: I know who I'm talking to =0A= Chris: Are you sure you are getting the update from them? Isn't the genesi= s the discussion I should be able to know that my AS originated the route. = =0A= Matt: seems silly to sign to yourself=0A= Chris: proxying Danny's question=0A= Sriram: does the msg received by the edge router, is it different if empty = bgpsec path=0A= Matt: semantics aren't different, bits on the wire are diff=0A= Sandy: in one case aspath length =3D 0 and in other case you have bgpsec pa= th =3D0=0A= Randy: gives example - =0A= Sandy: what does something send the edge=0A= Randy: if I am originating and speaking to =0A= if a null aspath reaches the edge and the edge speaks bgpsec, it becomes bg= psec=0A= Rudiger: as long as the optional field is not around=0A= Randy: no it will be done by the edge=0A= Rudiger: in case you are actually putting the time in, if some unknown ext = is put there it might make a difference=0A= Matt: I'll take all to the list. the sense of the room is leaning toward em= pty bgpsec attrib=0A= =0A= 14. Valid-Invalid vs. Good-Not Good: The room leaned towards Valid and Not = Valid. Randy: =93Someone on the SIDR list suggested a not unreasonable thir= d state for bgpsec validation.=0A= =0A= Details of discussion:=0A= =0A= Validation state names=0A= Matt: I would like to call the states valid and invalid. Any probs with th= at?=0A= Randy: Is it verifiably invalid, or couldn't validate=0A= Matt: Couldn't validate is long=0A= Randy: sure, not validated=0A= Sandy: if the origin validation comes up with unknown or invalid, bgpsec co= mes up as not good. If you translate not good to invalid. I think you nee= d separate terms so you aren't overloading=0A= Rob: Valid and not valid works for me --- invalid means something different= in this space=0A= Matt: I will change to Valid and not Valid =0A= Rob: you may actually need to explain binaries (kidding)=0A= Sandy: someone will ask origin has 3 states, this has 2, what happened?=0A= Matt: I could, but doc is already long=0A= Randy: that msg suggested symantics for the 3rd state in bgpsec validation = that wasn't unreasonable =0A= Matt: we can do it there is a good use case=0A= =0A= 15. Error Handling: General consensus was not to drop the bgpsec session if= the parsing failed (i.e. syntax errors). There was difference of opinion w= hether the prefix should be treated as withdrawn or ignore the update (i.e.= simply consider it never occurred). Sriram: If bit flipped in the NLRI, yo= u would be withdrawing the wrong prefix. Ruediger: That is alright. Rob: Ye= s, the protocol document has normative dependency on the error handling dra= ft in IDR.=0A= =0A= Details of discussion:=0A= =0A= Error Handling=0A= Matt: current text log error and drop update -- maybe not the right text. = what can I reference for the right way to handle errors -- 4271 will tell u= s to close the session, which we probably don't want=0A= Randy: draft-idr-handling - a little sarcastic=0A= Chris: there are some errors you can handle because it doesn't affect routi= ng, if bgpsec content is unparsable do I still accept the route or throw it= away=0A= Randy: you are going to have to classify in terms of that document=0A= Jari: if you ever have to deal with both sec and non-sec info - if somethin= g fails you treat the info as insecure and up to policy on whether you acce= pt it or not =0A= Chris: update is formatted properly but a bit gets flipped - in the bgp wor= ld you would notify and restart (bounce) - this is discussion idr is having= - when does it matter and when does it not=0A= Rudger: drop update or treat as withdrawl?=0A= matt/randy: thats the prob=0A= Rob: we dont constantly monitor logs - I saw nothing about mib counters in = the idr doc - =0A= Sriram: problem is we have one bgpsec path which includes path info and sig= natures, if there is an error the whole thing is invalid. We dont have sepe= ration. there are only 3 choices, withdrawl, close session or drop update.= No option for saying=0A= just a security error. Is there a case for seperating path information in = case there is an error and then you atleast still have the path for bgp4=0A= Chris: if the bgpsec attrib is bad - if you believe they are half crazy.. y= ou can't get the aspath and have to treat as a withdrawl.. then they are al= l crazy=0A= Jari: if there is insecure data you don't want to override any secure data = - =0A= Chris: I may choose to take the settlement free path over the secure path = If we fall back to the neighbor is crazy thats what we should worry about= =0A= Jen: I don't think we want to drop bgp -- I don't want to flap, but I don't= trust the update, withdraw=0A= Matt: inform the operator (not notify, not log..) =0A= Eric: how do you know?=0A= Chris: you pack an update =0A= Randy: the flipped bit was in the nlri - treat as withdraw - this is going = on in idr=0A= Rudiger - hopefully they will come up with good language=0A= Matt: 06 ver will say you should inform and treat as withdrawl=0A= Sriram: you can't tell anything about the prefix so how can you treat as wi= thdrawl?=0A= Matt: in the early years it will be more likely that we stumbled into somet= hing untested rather than random bit flip via solar flare=0A= Are you arguing to treat as if update occurred or shut session =0A= Sriram: as if it never happened=0A= Eric: leave this to idr - hate to end up with 2 different results=0A= Rudiger: if we get garbage from idr then we have problems - what kind of er= rors are we covering here - solar flare bit flips should have no impact=0A= Chris: if you put transport security ON then you have to address it=0A= Rudiger: we are looking at format errors in the bgpsec attribute, treat as = withdraw=0A= Rob: we do have a normative dependency on idr=0A= Matt: suggest saying handle as you would any syntax error in bgp -- take it= to the list=0A= =0A= 16. Deferring Validation: Question: Router MUST or SHOULD validate later an= d reevaluate best path? The consensus seemed to be that router MUST reevalu= ate. Ruediger: Change in RIB entry will automatically trigger best path re-= computation.=0A= =0A= Details of discussion:=0A= =0A= Deferring validation=0A= Matt: I got multiple comments on this text: "During exception conditions (e= g the BGPsec speaker receives.....).." suggestion that there should be text= that says you may defer validation if you have to=0A= more text that says "implementation that support such deferment of validati= on..."=0A= Are these reasonable texts on deferring validation state? Are these reason= able MUSTS?=0A= To Rob - I got that you flagged a problem but am not sure what it should sa= y.=0A= Eric: I get the principle that you might need to do this, but this seems to= open an attack vector - so we should describe the requirement to do this= =0A= Rob: must perform validation as soon as possible you could end up with a lo= t of side cases and reasons why it takes to long=0A= Randy: the whole thing is a rat hole=0A= Rob: operators wanted to be able to defer=0A= Rudiger: we can deal with unvalidated stuff, the provision for dealing with= that is a requirement for implementers - going into details is a rat hole,= just stay out=0A= Chris: The original reason was to maintain speed of convergence - if you ba= ck up and say we should just validate and run best path and move on - ops w= ill ask vendors for a knob to defer and rerun. You can unpack and get path= info, =0A= then validate later. =0A= Matt: its the crypto that could be a problem later=0A= Randy: I just got bgpsec updates and don't have a path to rpki=0A= Rob: ask implementers. add text that says, be aware you may want to rerun = =0A= Rudiger: rerun policy and that implies rerunning best path=0A= Sriram: have we made it clear somewhere that we have to check syntax error = first. =0A= Matt: if your length fields are wrong in your tlv's then you arne't going t= o parse this=0A= Matt: we really need to get implementers opinion on this and what you would= like it to be =0A= Heather: don't see what is wrong with the text=0A= Sriram: if you have path info and signatures seperate - if you decide to de= fer validation and it is simple to pick path validation =0A= Rob: lets not reopen that issue again=0A= Rudiger: I think it irrelevent - i feel the language is bad, when we take a= deferred object we run policy and insert result in rib which triggers best= path -- wehn we do validation we have to rerun policy, this may change rib= entry, which triggers best path=0A= =0A= 17. Validation at Edge Only: Sandy: How does the text relate to RR. Matt: R= R should not need to do crypto validation. Chris: =93You can do crypto ever= ywhere; you need no do crypto everywhere. Randy: =93There are no bits in iB= GP to convey validation state. Operator has to devise a way.=94 Heather: = =93That=92s covered if you combine the two sentences in the middle on Matt= =92s slide.=94=0A= =0A= Details of discussion:=0A= =0A= Matt: Edge Validation (see slide for text)=0A= "Bgpsec validation needs only be performed at ebgp edge...." we really need= ed to say something about how you only need to validate at the edge. This = text might say to much? Do I need to say the first sentence? Can I yank th= e entire paragraph.=0A= There were multiple people who read this, who didn't like the message. =0A= Sandy: how does this relate to route reflectors=0A= Matt: no one has suggested that rr's can't - no one is trying to take anyth= ing away=0A= Randy: objected to "may be conveyed via ibgp" so give a hint that its conve= yed by some mechanism --it's a nit on the language =0A= Matt: Combine the middle 2 sentences -- conveyed via some mechanism =0A= =0A= 18. Choosing Valid over Unsigned: Randy suggested leaving that to the bgpse= c-ops document.=0A= =0A= Details of discussion:=0A= =0A= Use of Validation state=0A= Matt: Do we want to mandate that you cannot pick a non-bgpsec best path if = you have bgpsec valid. (everyone agrees?)=0A= Do we want some text that says SHOULD=0A= Randy: its in the ops doc=0A= Matt: remove 1-2 sentences and leave it to the ops doc=0A= =0A= 19. Re-run Validation: Upon receipt of RPKI state update, router will re-ru= n those bgpsec updates that the RPKI updates may affect. Sandy: 4271 mandat= ed re-evaluations if there are any. Rob: Careful about using the word =93im= mediately=94. Matt: References to rpki-rtr doc are informative.=0A= =0A= Details of discussion:=0A= =0A= ReRunning validation=0A= Matt: RPKI state might change, do we need text that says to rerun validatio= n algorithm=0A= Randy: you will receive the withdrawal. periodically is not the term that = applies=0A= Chris: I have a whole rib built and I go out and revalidate and the rpki ca= che does not have an entry for something that I had before. Now Ive gone t= o not found and start sending updates=0A= Matt: when I get a msg from rpki router saying there are certain keys that = are no longer good, I look through rib and see if I am using ski's - you ar= e moving from valid to not valid, so you don't want to treat it as a withdr= awl=0A= Randy: we are quibbling about when --- periodic or when you get the update= =0A= Chris: what if rpki update is no data?=0A= Randy: Then it all gets marked not-valid=0A= Chris: For all the changes I would go see how they affect me. Check at bat= ch of updates?=0A= Sandy: Concentrating on rpki protocol, -- others not running= it would notice a change=0A= Matt: currently we don't have a normative reference on rpki router=0A= Randy: the interesting case is the router itself being a validating cache= =0A= Matt: no one has a problem with everytime I learn of update I immediately r= evaluate those announcements which the update may affect=0A= Sandy: rfc4271 language which tell you to rerun best path algorithm can't r= ecall whats mandated there. If they say you must do it, then its okay for = us to say it. If they have ifier language then we probably shouldn't have = stronger language=0A= Rob: "at earliest convenience" vs "immediately"=0A= =0A= 20. =0A= =0A= RPKI-rtr-keys=0A= =0A= Details of discussion:=0A= =0A= Matt: include informative reference to ymbk-rpki-rtr-keys or says rtr or s= imilar to?=0A= Sandy: origin is mandated so we don't have to wait, it already applies as i= t currently exists - any future decisions don't impact =0A= =0A= Matt: That's it.. to the list=0A= =0A= 21. Confederations: Randy: Confederation has to have its own trust anchor. = Matt: =93Someone from outside confed signs to the public ASN. The first AS = of the confed does not have a technical problem with that; it is configured= to know that the public ASN is. The second AS in the confed sequence along= the update path should know it is an acceptable mismatch.=0A= =0A= Details of discussion:=0A= =0A= Randy: New Item - I am an incoming edge of a confed - I am not the canonic = as of the confed - I am going to pass the received prefix internally observ= e that the confed will have to have a local trust anchor and its own data f= or the ases in the confed=0A= on the left I'm as2, ont he right I'm as65000 I sign forward with as65000 = to another confed member who goes to validate, they find the announcement t= o me is as 2=0A= Matt: .....=0A= Randy: you will allow the mismatched AS?=0A= Matt: there needs to be an exception where the confed flag is set, the firs= t person needs to permit a mismatch. If I'm in your AS I know what the pub= lic AS is for the whole confed. I'll reread it to make sure it's actually = clear The receiver should have=0A= everything to verify the mismatch=0A= =0A= =0A= =0A= =0A= 22. Not obsoleting RF 4271. If you do not negotiate bgpsec with neighbor, b= ehave exactly as a 4271 router. =0A= =0A= 23. Comparison with IDR WG: Sandy: Conformance with IDR-like requirement th= at there must be a working implementation before publishing as an RFC. If = you know implementers of bgpsec, please tell them that they let themselves = be known to the SIDR WG.=0A= =0A= Details of discussion:=0A= =0A= Sandy: Comments on IDR stuff the relationship of this draft to 4271 we're a= dding on a new feature to bgp but also doing something about aspath those p= pl taking an existing implementation and adding bgpsec attr need guidance o= n what to do in code=0A= where code refers to aspath. It's obsoleting 4271, there has to be some la= nguage that is good enough that tells implementers what to do when dealing = with.. when the implementation refers to the aspath. suggesting something = like references to aspath=0A= are to be understood that the aspath is extracted from bgpsec attr. If yo= u do not negotiate bgpsec w/ neighbor you should behave as current=0A= Rudiger: appears to me designing compatibility with existing thing. One sh= ould assume that for reg bgp processing one assumes out of bgpsec path, asp= ath info needs to be extracted and handled - which is a little different wo= rding where we haev said "when=0A= we are talking to someone else who doesn't know the new attribute or symant= ics - atleast have to virtually do the extraction and may have to be done p= hysically." =0A= Sandy: Do we want mandate that they do it or not=0A= Rudiger: we don't want to specific detailed implementation - treat as thoug= h you had=0A= Matt: agreeing with Rudiger -- your implementation should behave as though = you ran the extraction algorithm =0A= Sandy: where aspath modified I think those are cases where you would be add= ing a bgpsec signature block (missed first part) If you do not negotiate b= gpsec with a neighbor operate in accordance with 4271 --- Does that need to= be said or is it understood?=0A= Matt: I understand that whenever you fail to negotiate you fail back to 427= 1=0A= =0A= Sandy: IDR operates under rules stricter than other areas - they require im= plementations in order to advance a draft. We haven't been faith= ful to that, but in this case we think they will be. So if you know of peop= le doing implementations please make =0A= sure they make themselves known. Not sure what the IDR chairs will accept = as evidence -=0A= =0A= Sandy: anything more about confeds=0A= Room: crickets=0A= =0A= Sandy: anything more about bgpsec protocol=0A= Room: crickets=0A= =0A= Sriram: is there a dependency of bgpsec doc on key rollover doc? =0A= Sandy: staleness and freshness - protocol draft does not rely on key rollov= er draft - any other opinions.. none ok=0A= =0A= 24. Router-ID in communication of router key to router: The consensus was t= o not include the router ID in the rpki-rtr-key pdu.=0A= 25. Should Router-ID also be removed from the router cert data: Rob: Proba= bly. Steve Kent: If helpful in debugging cert data, it may worth keeping it= (cost seems small).=0A= =0A= Details of discussion:=0A= =0A= Randy: From this am -- pdu to transport router info from pki to router shou= ld not have router id in it, =0A= Chris: signed you mean?=0A= Randy: rpki router pdu to carry the ecdsa public keys that will be handled = by sig validation since this am we said they are not per router and router = id has no meaning therefor do not transmit router in the pdu - looking for = validation of that=0A= Matt: I don't know whether I agree/dis I don't think that is outcome of thi= s am discussion. No security reason to put router id on the wire -- differ= ent from is it useful for some other reason=0A= Randy: why push if you won't use it=0A= Sandy: some suggested router id is useful in monitoring, debugging=0A= Randy: anyone want to speak for keeping routerid in transport=0A= Steve: When we regionally did cert design for routers, there was the notion= that if you did different cert and key per router and were neighbor of bgp= sec router and received signed update from it - you could check to see if s= ig applied by entity=0A= you thought you were talking to on the other side. Some say they wouldn't = do it - still open question if you want that facility -- =0A= Sandy: do you need it for transport protection=0A= Steve: forget bgpsec - if I configure info about neighbors, then we would h= ave the ability to do this in a secure fashion - with this -- go from secur= e to a more secure. =0A= Randy: routers don't do this today - routerid comes in the open msg today. = Does anyone still want it there today=0A= Rob: I don't know. it could be useful for debugging in the certificate -- = we have gone to lengths to make this difficult to debug by not having perso= nal info it. I hope routerid is not considered personal info. I like steve= 's idea of putting in=0A= the serial field of the RDN. =0A= Sandy: anything else? anything else protocol related from this am=0A= =0A= 26. Linkages to other documents: Chris: Linkage with idr-error-handling for= sure. What else? Rpki-rtr protocol?=0A= =0A= Details of discussion:=0A= =0A= Chris: the protocol doc perhaps can't go fwd w/o threats and reqs docs bein= g finished =0A= Matt: potential linkage to subsequent pdu for rpki-rtr if that spec if late= r extended people will be able to find it=0A= Sandy: I think linkage to that exists without extension(?) of pdu=0A= =0A= 27. =0A= =0A= Details of discussion:=0A= =0A= Steve: 2nd rob's suggestion of avoiding putting meaningful names in certs. = There is some benefit to putting in some info about what kind of cert it i= s. Spelling out router and the AS is worthwhile and should make it unique.= Small cost.=0A= =0A= 28. Number of ASNs per cert: Rob: One cert can contain multiple ASNs. Sandy= : Do we want single ASN per cert (like in the ROA)? Rob: Operator has a cho= ice to put one ASN in the cert if they prefer. Matt: Will replace =93the as= n in cert=94 with =93an asn in cert=94 in the doc.=0A= =0A= Details of discussion:=0A= =0A= Sandy: question about discussion between rob and steve about EE certs havin= g ..language.. checking ee cert asn matching attrib field =0A= Matt: Many to one mapping between AS and certs. 1 cert can contain many AS= numbers - you need to match a ASN. My mistake in the doc, I'll go back an= d fix it=0A= Sandy: ..something about revoking and having single AS numbers..=0A= Rob: as far as protocol leave it to operator - they can shoot themselves in= the foot=0A= Sandy: no protocol change for that needed=0A= =0A= 29. AS-Migration: See Sandy=92s detailed slides =96 she presented them at t= he meeting. She presented how bgpsec with pCount=3D0 technique can try to h= ide (i.e. not contribute to path length) as the operator wishes under vario= us AS migration scenarios. The discussion that followed was as follows. Ran= dy: Wes George=92s I-D is Cisco specific. Juniper doesn=92t have all this. = Ruediger: =93Even if there is org boundary, if there is agreement with your= neighbor, then =93accept pCount=3D0=94 can be negotiated for the migration= .=94 Sandy: In slide #7, CE-1 needs to be configured to accept ASN 200 in t= he AS path. Sandy: Can the trick used for the confederation be reused here = in some form? Matt: This is different. As soon as update leaves, all the in= consistency info is expunged. Here it is not that.=94 Matt: Are the stuff w= ith local AS etc. well documented. Rob: No, it is a vendor hack.=94 Sandy: = Is anything different needed in the protocol document? Stephen: =93Don=92t = just focus on how Cisco implements the hack. Check with other vendors as we= ll.=94 Ruediger: =93One vendor may be liberal, another not so liberal.=94 S= andy: =93They are all trying to eliminate the extra hop.=94 Russ Housley (o= n jabber): =93Since pCount was invented for other reasons, this is useful t= o document.=94=0A= =0A= (summarizing minute taker:) Details of discussion:=0A= =0A= The discussion that followed was as follows. =0A= Randy: Wes George=92s I-D is Cisco specific. Juniper doesn=92t have all thi= s. =0A= Ruediger: =93Even if there is org boundary, if there is agreement with your= neighbor, then =93accept pCount=3D0=94 can be negotiated for the migration= .=94 =0A= Sandy: In slide #7, CE-1 needs to be configured to accept ASN 200 in the AS= path. =0A= Sandy: Can the trick used for the confederation be reused here in some form= ? =0A= Matt: This is different. As soon as update leaves, all the inconsistency in= fo is expunged. Here it is not that.=94 =0A= Matt: Are the stuff with local AS etc. well documented. =0A= Rob: No, it is a vendor hack.=94 =0A= Sandy: Is anything different needed in the protocol document? =0A= Stephen : =93Don=92t just focus on how Cisc= o implements the hack. Check with other vendors as well.=94 =0A= Ruediger: =93One vendor may be liberal, another not so liberal.=94 =0A= Sandy: =93They are all trying to eliminate the extra hop.=94 =0A= Russ Housley (on jabber): =93Since pCount was invented for other reasons, t= his is useful to document.=94=0A= =0A= (detailed minute taker:) Details of discussion:=0A= =0A= Sandy - on to discussion of AS aliasing, migration=0A= Sandy: (see slides)=0A= Provider changes AS - customers aren't so quick to update=0A= opt 1) Local_AS CE-1 doesn't needs to be upgraded but AS300 gets inserted = into AS_Path -- you now have an extra as in the aspath=0A= Do away with side effect by doing no-prepend so then the old-origin drops = off=0A= opt2) Local_as + no prepend gives the effect that ce-1 doesn't have to upgr= ade and 300 is inserted int as_path toward ce-1=0A= opt3) Local_as + no prepend + replace-AS =0A= =0A= Notation sig(originprefix, target, as of signer, pcount)key=0A= adds 2 signatures as if there were 2 peers inside the router -- =0A= In this case the recipient is inside the provider edge - there is no proble= m with the authority, the as that is accepting pcount=3D0 is under the same= authority as the other AS (since they are on the same router) =0A= =0A= Sandy describes/reads slides =0A= ...missed something..=0A= Rudiger: plausible to say we are starting migration, we will be faking for = a bit, if you are rigidly checking pcount 0 - then expect pcount 0 for migr= ation=0A= Sandy: this case came from 1st draft - things outbound from pe1 is sending = things to the customer with new ASN =0A= Randy: its going to puke on open=0A= Sandy: no pe1 and ce1 are using as300 for open Will you check the first AS= . Default is supposed to be do the check, and that ce1 has to be configure= d to do this.=0A= Randy: neighbor as is checked in the open not the path=0A= Some guy : I thi= nk its checked in the path by default =0A= Rudiger: its different between vendors - some are liberal and some are stri= ct. All migrations I came across, faking the AS was always used where the = aspath issued and the neighbor AS were consistent, which is not the case he= re=0A= Sandy: when randy talked about the confed case where you are taking with yo= ur public as externally and your internal as internally=0A= Matt: here is the difference in confed -- in the confed case the only peopl= e who see the inconsistency are within the confed and when you leave the co= nfed the inconsistency gets expunged. =0A= Sandy: is this technique useful to employ in the confed case=0A= Matt: no reason to add this complexity to confeds=0A= Sandy: Wes was going to try to work out how as aliasing impacts- came up wi= th other useful stuff, but not how pcount=3D0 might be useful=0A= Matt: are local_as and replace_as well documented?=0A= Rob: vendor hack=0A= Matt: big question I'd like answered - the tools in the protocol doc are th= ey sufficient to make this migration work or do we need to add some other l= ever to make this work=0A= Sandy: I was not supposing there would be any different protocol behaviour = to occur that isn't in the protocol doc=0A= Matt: text going into 06 that says you really ought to check for pcount=3D0= and drop it if you aren't expecting it=0A= =0A= Russ: since we adopted pcount =3D0 for other reasons this is useful=0A= Sandy: this was not viewed as a change to the protocol=0A= Randy: let Wes continue to document=0A= =0A= Randy: Asked a question about delivering SKI=0A= Sandy: let suppose someone takes of rpki cache and starts sending out ski's= that match different keys=0A= Rob: stop there you're toast. Offload ..Chris messed with the screen could= n't hear.. =0A= why are you giving me both and making me think about this.=0A= don't check for an error condition you don't know how to handle=0A= Matt: cache is just offloading processing, it mgiht as well handle ski. Yo= u absolutely need the key for sig ver. Do you offload the ski calculation t= o the other box or do it on your router? Just ship it over and save me fro= m doing=0A= a few hashes=0A= Sandy: does your answer change if we haven't protected router to cache tran= sport=0A= Rob: agrees with matt=0A= =0A= Sandy: any other items?=0A= room: crickets=0A= =0A= Meeting adjourned=0A= =0A= =0A= From kotikalapudi.sriram@nist.gov Thu Oct 11 13:24:32 2012 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 3811121F858E for ; Thu, 11 Oct 2012 13:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xp1FovKIkBkr for ; Thu, 11 Oct 2012 13:24:30 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id D007021F8589 for ; Thu, 11 Oct 2012 13:24:28 -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.379.0; Thu, 11 Oct 2012 16:23:59 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 11 Oct 2012 16:24:06 -0400 From: "Sriram, Kotikalapudi" To: "Sandra Murphy (Sandra.Murphy@sparta.com)" Date: Thu, 11 Oct 2012 16:24:05 -0400 Thread-Topic: agenda requests for IETF85 Thread-Index: Ac2i/lQFTW+vlS7vTy2YoyvWXeuZGQE7eKxA Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F62BEFE642@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F62BEFE642@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] agenda requests for IETF85 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 Oct 2012 20:24:33 -0000 >If you have a topic that you would like to see discussed at the IETF84 Atlanta >meeting, please send a request to the list. I would like request some time to present a summary of the new draft: http://tools.ietf.org/html/draft-sriram-replay-protection-design-discussion-00 This draft was announced on this mailing list earlier: http://www.ietf.org/mail-archive/web/sidr/current/msg05079.html A set of slides with figures that may be helpful while reading the document: http://www.nist.gov/itl/antd/upload/replay-discussion.pdf Sriram From Sandra.Murphy@sparta.com Thu Oct 11 15:11:24 2012 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 DB35721F8513 for ; Thu, 11 Oct 2012 15:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 swdBvpQU22Hc for ; Thu, 11 Oct 2012 15:11:24 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3F12B21F8510 for ; Thu, 11 Oct 2012 15:11:24 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q9BMBDMr020032 for ; Thu, 11 Oct 2012 17:11:13 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q9BMBDnr024607 for ; Thu, 11 Oct 2012 17:11:13 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0379.000; Thu, 11 Oct 2012 18:11:22 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: WGLC for draft-ietf-sidr-algorithm-agility Thread-Index: Ac2n/C+1RDwWOm9NRT6UCN1uf6EwzQ== Date: Thu, 11 Oct 2012 22:11:21 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F62BF036CD@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] WGLC for draft-ietf-sidr-algorithm-agility 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 Oct 2012 22:11:25 -0000 The WGLC for draft-ietf-sidr-algorithm-agility was posted last October.=0A= =0A= The co-chairs are satisfied that the recently announced version draft-ietf-= sidr-algorithm-agility-07.txt adequately reflects wg comments and consensus= .=0A= =0A= The co-chairs will be requesting publication of this draft very soon.=0A= =0A= --Sandy, speaking as wg co-chair= From internet-drafts@ietf.org Thu Oct 11 17:50:24 2012 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 1C6921F0C5F; Thu, 11 Oct 2012 17:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 NdsqavF3YPnI; Thu, 11 Oct 2012 17:50:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7F61F042B; Thu, 11 Oct 2012 17:50:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121012005023.25199.24019.idtracker@ietfa.amsl.com> Date: Thu, 11 Oct 2012 17:50:23 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-ltamgmt-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 Oct 2012 00:50:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : Local Trust Anchor Management for the Resource Public Ke= y Infrastructure Author(s) : Mark Reynolds Stephen Kent Matthew Lepinski Filename : draft-ietf-sidr-ltamgmt-07.txt Pages : 28 Date : 2012-10-11 Abstract: This document describes a facility to enable a relying party (RP) to manage trust anchors (TAs) in the context of the Resource Public Key Infrastructure (RPKI). It is common in RP software (not just in the RPKI) to allow an RP to import TA material in the form of self-signed certificates. However, this approach to incorporating TAs is potentially dangerous. (These self-signed certificates rarely incorporate any extensions that impose constraints on the scope of the imported public keys, and the RP is not able to impose such constraints.) The facility described in this document allows an RP to impose constraints on such TAs. Because this mechanism is designed to operate in the RPKI context, the most important constraints are the Internet Number Resources (INRs) expressed via RFC 3779 extensions. These extentions bind address spaces and/or autonomous system (AS) numbers to entities. The primary motivation for the facility described in this document is to enable an RP to ensure that INR information that it has acquired via some trusted channel is not overridden by the information acquired from the RPKI repository system or by the putative TAs that the RP imports. Specifically, the mechanism allows an RP to specify a set of overriding bindings between public key identifiers and INR data. These bindings take precedence over any conflicting bindings acquired by the putative TAs and the certificates downloaded from the RPKI repository system. This mechanism is designed for local use by an R= P, but any entity that is accorded administrative control over a set of RPs may use this mechanism to convey its view of the RPKI to RPs within its jurisdiction. The means by which this latter use case is effected is outside the scope of this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-ltamgmt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-ltamgmt-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-ltamgmt-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From christopher.morrow@gmail.com Fri Oct 12 07:13:08 2012 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 9992921F8628 for ; Fri, 12 Oct 2012 07:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rm3dSrQrmU7Y for ; Fri, 12 Oct 2012 07:13:08 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D720021F8622 for ; Fri, 12 Oct 2012 07:13:07 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so1910425wey.31 for ; Fri, 12 Oct 2012 07:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ANiNWmwWkVt2ggBaZXUzMNviKnXt6p9Q7saXERv7QjQ=; b=VGYBa3+kMqpJFLroiW3U+Rg3nQTtpIlOViXOb/tGUjg2p5kM26Wrs1nhSQlhM+Y5l0 qs3DZLcCfCSXCTCTasUymBbSinaIKsHageElAFuIxw/BpESoiTEOdUOxNY5/sB0d4bUx qc0/FxiJoQKd5zs5zkESkbOEMj+nY72XVbzXJYaqzzvcyhgmX7SXxxnvckuXzBrQax1w wIGRGTTGkyenLvPvfSKVSqE73eGdqHLaunbcBDbWmabg/4RtQm6pOzYx0YNB7iB1t/Qf XBr7+5pSrTu2jSMmIihCk1EXsN/Gvd4fkjFNNdZPXviXZfs0f3dKRTwlf7lJmlkmepUP MOcw== MIME-Version: 1.0 Received: by 10.180.88.130 with SMTP id bg2mr6397779wib.22.1350051187029; Fri, 12 Oct 2012 07:13:07 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Fri, 12 Oct 2012 07:13:06 -0700 (PDT) In-Reply-To: <3CED4BB7-87DD-41D0-8491-D8308401B545@verisign.com> References: <871B5CE6-18DF-48B1-B845-D84F9B813632@tcb.net> <5076F2D3.4000000@lacnic.net> <3CED4BB7-87DD-41D0-8491-D8308401B545@verisign.com> Date: Fri, 12 Oct 2012 10:13:06 -0400 X-Google-Sender-Auth: t_zi7En9NO510eKXW96TdxiM7b0 Message-ID: From: Christopher Morrow To: Eric Osterweil Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] [fixed] Confirming that the last interim reflects working group consensus 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 Oct 2012 14:13:08 -0000 On Thu, Oct 11, 2012 at 2:06 PM, Eric Osterweil w= rote: > > On Oct 11, 2012, at 12:24 PM, Arturo Servin wrote: > >> Chris, >> >> I think that you and Sandy mentioned that >> draft-ietf-sidr-bgpsec-threats and draft-ietf-sidr-bgpsec-threats should >> be done before >> draft-ietf-sidr-bgpsec-protocol but it was just by email, I believe. >> >> http://www.ietf.org/mail-archive/web/sidr/current/msg05078.html >> http://www.ietf.org/mail-archive/web/sidr/current/msg05080.html >> >> I was not in the interim, so I do not know if you discussed the is= sue >> there again. > > > fwiw, I was at the interim, and I do recall the comment being made. at least I wasn't misremembering. (and the notes were posted by sandy a bit= ago) > That said (and at the risk of stating the obvious), can we not agree that= the protocol draft will almost certainly need changes and/or an overhaul d= epending on the scale of the changes that may be coming to the threats and = reqs drafts? I'm just thinking that if we are going to continue to pursue = those drafts as prerequisites, then iterating over and polishing their deri= vative work (the protocol draft) now seems like it may yield text that beco= mes obsoleted by those prerequisites, right? > protocol may, indeed, require changes, or not... read threats to make sure it's ok and we can concentrate on the requirements doc now? :) I suppose we'll send a more official 'read the threats doc, kthxbi' today as a reminder. -chris From christopher.morrow@gmail.com Fri Oct 12 07:53:53 2012 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 3347221F8464 for ; Fri, 12 Oct 2012 07:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLoi7V0QSE+G for ; Fri, 12 Oct 2012 07:53:52 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 01D9221F847F for ; Fri, 12 Oct 2012 07:53:51 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so1935395wey.31 for ; Fri, 12 Oct 2012 07:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2lp+d+Cwg0dexYkN+7yizq/noPoYRIyOHFA9fJPF2ZM=; b=asO2i7Cdyq8OxCdqyq5SCEysMGHCCMRs5KIH8V0a1FrID8jaBG6FPHaoXClgHceHHK 13yvpenyHIt2XDiZnjdzZD0WBdLM6Y/3/k5Y1O7fYPmyUdc8h1ILabDcHgFzVVluq6T0 BG626Cxcg6HBNQaauvSsJRpO5sQUB4ayX2UduPE/SudtzHJ63Uq+9+HMmbEnbfAemMtL 5dnxkzHQQtJSIspspHAIufmU9DIIy/Fy5IVjEG+c3FQT5c/XcQhR+SEutdY2WEsMMJjc rx97nk1msx+MQiXmu8qqKMx03KQrCoPXdIk9daZ9kM2RuzEGyFkWwG6JtS1JZsnPPjzP SwZA== MIME-Version: 1.0 Received: by 10.180.80.104 with SMTP id q8mr6732967wix.6.1350053630654; Fri, 12 Oct 2012 07:53:50 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Fri, 12 Oct 2012 07:53:50 -0700 (PDT) In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F68471@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F6733D@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F68471@Hermes.columbia.ads.sparta.com> Date: Fri, 12 Oct 2012 10:53:50 -0400 X-Google-Sender-Auth: 2BJaMb5vN1-aj4Nlk3JA0hZLd58 Message-ID: From: Christopher Morrow To: "Murphy, Sandra" Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org" Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting 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 Oct 2012 14:53:53 -0000 Helo, Since we've been through this for a while (originally) and this has been quiet for ~1 month... let's call this done and move to the next step. 1) there was lots of discussion on the topic at hand 2) lots of that discussion was not about acceptance/rejection of the idea into the WG 3) lots of people contributed I do think we should continue to have this discussion more officially around a draft, the wg discussion leads me to believe this is the right course... can the authors spin a newly named version and we can start discussing the topic / changes? I think if, in the end, the wg decides to abandon the work that's also fine, but we should have a more structured chat about the topic, that happens around a draft. -chris co-chair On Wed, Aug 29, 2012 at 5:06 PM, Murphy, Sandra wrote: > Speaking as wg co-chair > > Of course revision and new request for acceptance is possible. > > Even arguing some more leading to acceptance of draft as is is a possibility. > > Some commentors specifically requested that the discussion be added to some existing draft. > > Trying to judge wg desire of a way to proceed. > > > --Sandy > > > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Andy Newton [andy@arin.net] > > Sent: Wednesday, August 29, 2012 4:56 PM > > To: Murphy, Sandra; Alexey Melnikov; sidr@ietf.org > > Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting > > > > > > > Are the chairs not allowing the draft authors to address the issues and try again? > > > > -andy > > > > > > From: , Sandra > > Date: Wednesday, August 29, 2012 12:10 PM > > To: Alexey Melnikov , "sidr@ietf.org" > > > Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting > > > > > > > > BODY {direction: ltr;font-family: Arial;color: #000000;font-size: 10pt;}P {margin-top:0;margin-bottom:0;} > > Speaking as wg co-chair: > > > > Certainly a very lively acceptance call! > > > > The chairs do not see that there was consensus that the wg should adopt this draft. > > > > But there was ample evidence that the wg was interested in the issue - by the wg spending lots of time discussing the issue. > > > > So that leaves the chairs with an ambivalent message. The wg is very interested in the topic but not in adopting a draft that would record any decisions about the topic. > > > > What would the wg like to do now? Particularly those who disagreed with the content of the draft - if you would dislike the recommendations, are you OK with no recommendations instead? > > > > --Sandy, speaking as wg co-chair > > > > > > From: > > sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Alexey Melnikov [alexey.melnikov@isode.com] > > Sent: Saturday, August 04, 2012 2:12 PM > > To: > sidr@ietf.org > > Subject: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting > > > > > > Hi, > > On behalf of SIDR WG chairs I would like to initiate 2 weeks acceptance call for draft-ymbk-rpki-grandparenting starting from today, August 4th. Please > send your positive or negative feedback to the mailing list or directly to chairs. > > > > > Thank you, > Alexey > > > > > > > > > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From Sandra.Murphy@sparta.com Fri Oct 12 13:50:18 2012 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 6CD1221F87BD for ; Fri, 12 Oct 2012 13:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 PqpnXgLGdCIE for ; Fri, 12 Oct 2012 13:50:17 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE0E21F876C for ; Fri, 12 Oct 2012 13:50:16 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q9CKo2Sj026961 for ; Fri, 12 Oct 2012 15:50:02 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q9CKnwW7023689 for ; Fri, 12 Oct 2012 15:50:04 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0379.000; Fri, 12 Oct 2012 16:50:09 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: upcoming important events Thread-Index: Ac2ouyn+/7aY4oVRTBm3+t829gGGIA== Date: Fri, 12 Oct 2012 20:50:08 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F62BF03947@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] upcoming important events 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 Oct 2012 20:50:18 -0000 =0A= Here are some important dates to keep in mind for IETF85:=0A= =0A= 2012-10-15 (Monday): Internet Draft Cut-off for initial document (-00) sub= mission by UTC 24:00.=0A= 2012-10-22 (Monday): Internet Draft final submission cut-off by UTC 24:00.= =0A= 2012-10-24 (Wednesday): Draft Working Group agendas due by UTC 24:00.=0A= 2012-10-26 (Friday): Early Bird registration and payment cut-off at UTC 24:= 00.=0A= 2012-10-29 (Monday): Revised Working Group agendas due by UTC 24:00.=0A= 2012-10-29 (Monday): Registration cancellation cut-off at UTC 24:00.=0A= =0A= If anyone is proposing submitting a -00 draft with a wg name (draft-ietf-si= dr-yadayada), you should let the co-chairs know. Chairs must approve any -= 00 wg draft. It helps if we know it is coming.=0A= =0A= --Sandy, speaking as wg co-chair=0A= From internet-drafts@ietf.org Fri Oct 12 20:10:04 2012 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 0A00221F866E; Fri, 12 Oct 2012 20:10:04 -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 q+x37GnkHnJ7; Fri, 12 Oct 2012 20:10:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5787D21F865C; Fri, 12 Oct 2012 20:10:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121013031003.29504.80256.idtracker@ietfa.amsl.com> Date: Fri, 12 Oct 2012 20:10:03 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-grandparenting-00.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 Oct 2012 03:10:04 -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 Group= of the IETF. Title : Responsible Grandparenting in the RPKI Author(s) : Randy Bush Filename : draft-ietf-sidr-rpki-grandparenting-00.txt Pages : 4 Date : 2012-10-12 Abstract: There are circumstances in RPKI operations where a resource holder's parent may not be able to, or may not choose to, facilitate full and proper registration of the holder's data. As in real life, the holder may form a relationship with their grandparent who is willing to aid the grandchild. This document describes simple procedures for doing so. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-grandparenting There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rpki-grandparenting-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From christopher.morrow@gmail.com Fri Oct 12 20:13:38 2012 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 5166721F85C3 for ; Fri, 12 Oct 2012 20:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNHzpWfEE+Wi for ; Fri, 12 Oct 2012 20:13:37 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 828CC21F85C2 for ; Fri, 12 Oct 2012 20:13:37 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so68905wib.13 for ; Fri, 12 Oct 2012 20:13:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=EEFOM1+uyGL5SQZiGrKU1ZTUCEb3lO4LA2vpyFPbnuY=; b=ZdSo1oB5VXXdFlcOyLS4cY+Mi1+9y/TjnyVmRLfJyaLRYNm4rlvyqmBkYw5TXbxkH6 XHLnLZ//MJJfCc/iR7+gq54z4pmRObF0ADW8VgzrWscOvaJxkQlDGiNiMaOCcNcWNC0M /itq+yZ09+40BddJCWKftl/KQri1FmxIQQ/vyLoA3Nds3i4Luv05J0G7mc6jlbYo4mgH v0CVCba3XkGFyx/5FA1TsIIZlLhL+Mxcnm7nkf0kd7gykNv03iFI+T8S62PEmfHVymTm UpV/znXFKCXWXtFctC8bfbaMxH3n+hNiLvbvDh8fhbnP3EwGf8OmLx9l4A64DjGT+Bdj MJrA== MIME-Version: 1.0 Received: by 10.216.218.105 with SMTP id j83mr3242240wep.164.1350098016664; Fri, 12 Oct 2012 20:13:36 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Fri, 12 Oct 2012 20:13:36 -0700 (PDT) In-Reply-To: <20121013031003.29504.80256.idtracker@ietfa.amsl.com> References: <20121013031003.29504.80256.idtracker@ietfa.amsl.com> Date: Fri, 12 Oct 2012 23:13:36 -0400 X-Google-Sender-Auth: iw91N7aruDVVFEZ8KzXd7iXl5X0 Message-ID: From: Christopher Morrow To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-grandparenting-00.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 Oct 2012 03:13:38 -0000 thanks author. On Fri, Oct 12, 2012 at 11:10 PM, 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 : Responsible Grandparenting in the RPKI > Author(s) : Randy Bush > Filename : draft-ietf-sidr-rpki-grandparenting-00.txt > Pages : 4 > Date : 2012-10-12 > > Abstract: > There are circumstances in RPKI operations where a resource holder's > parent may not be able to, or may not choose to, facilitate full and > proper registration of the holder's data. As in real life, the > holder may form a relationship with their grandparent who is willing > to aid the grandchild. This document describes simple procedures for > doing so. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-grandparenting > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-rpki-grandparenting-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Fri Oct 12 20:33:00 2012 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 0571721F86B0 for ; Fri, 12 Oct 2012 20:33:00 -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 VQVVmYCSShS1 for ; Fri, 12 Oct 2012 20:32:59 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id B29E121F8568 for ; Fri, 12 Oct 2012 20:32:59 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TMsTC-0005ax-9m; Sat, 13 Oct 2012 03:32:58 +0000 Date: Fri, 12 Oct 2012 17:32:57 -1000 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <20121013031003.29504.80256.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-grandparenting-00.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 Oct 2012 03:33:00 -0000 > thanks author. no extra charge randy From ggm@apnic.net Sun Oct 14 21:48:00 2012 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 7971D21F855E for ; Sun, 14 Oct 2012 21:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.995 X-Spam-Level: X-Spam-Status: No, score=0.995 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RELAY_IS_203=0.994] 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 dQv0YgwmndYs for ; Sun, 14 Oct 2012 21:47:59 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 302CF21F846C for ; Sun, 14 Oct 2012 21:47:58 -0700 (PDT) Received: from dynamic180.apnic.net (dynamic180.apnic.net [203.119.42.180]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id E2825B68B6 for ; Mon, 15 Oct 2012 14:47:54 +1000 (EST) From: George Michaelson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <010952DB-D6E1-4394-97E6-4F8BC844C435@apnic.net> Date: Mon, 15 Oct 2012 14:47:54 +1000 To: "sidr@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [sidr] If you are using APNIC as an RPKI trust anchor, please update your Trust Anchor Set. 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 Oct 2012 04:48:00 -0000 If you are using APNIC as an RPKI trust anchor, please update your Trust Anchor Set. APNIC will be switching to a new RPKI 'split' trust anchor system on the 25th of October. This change is needed to align APNIC administered resources with their allocation hierarchy. These resources will also be certified under each responsible parent registry at the appropriate time. In accordance with RFC6490 the old APNIC Trust Anchor Locator, associated certificate and repository will be removed, when the certificate expires on the 28th of October. 5 new Trust Anchor Locator (TAL) have been published. These will be kept up to date as an independent trust anchor set for resources maintained by APNIC. The production cycle will start on the 25th of October. Relying parties must add these new TAL by the 25th of October in order to maintain continuity of validation. If you have any questions please contact me. George Michaelson (ggm@apnic.net) Please add the following to your trust anchor set: rsync://rpki.apnic.net/repository/apnic-rpki-root-afrinic-origin.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuMLL96YV9pf0rZ4Ow/bk cgpoPfsRzkcgmisyCuMUdotHwrp8pepujhohatScRK09ILRrZYCdpX4121MJhqXC P3u3hy9fF0CeARKX/Q82nJccD4dtUp23UcFys8hwJgNYZI910ajkAxwNT//H/TFw oUYbzZGBR7o2awMc7GdQl/j6dgOkV6AfYy5DyDEgOUNHnUxED2rreefL/E2Fr2ST Esar6bTR4Tg4+nVF1PjAkgN0tKZYe4wZ6VmtqV/VTngSLysim6av7ki+JR3cVgVU OqXeh1vPjH2tNu6u9bX37ZrdVb6NBRer9I99IDbKvyhELb6nzo8+Q74zga9HI+Pf QwIDAQAB rsync://rpki.apnic.net/repository/apnic-rpki-root-arin-origin.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAp6vscYtzhe0CfFk5Ro44 llPhsInXtfAxqfYmK7m9V3khkqK3d3/ZAW6pcJm7qW8XhEGl+F5mUeeLIm5JoIhr kT5B5M6uL0VlCCkZJH4h76ybOa83vWITNZEDy9L3c3nK4S+Basu3vYoE4ICXGG+J 7zg5Iw9saV+p03E2w1g16pt1QI3Cnggp6edkeWClEz3aPw/ULOIHb7YmatWwdERl tL9LsuMSKszQLUY7F4XVpxey/rJYAZgzDUh+b6813WAClCkkydNjsbviuekAWJbx sW7Mcw53u30K4g8MP03CjkDOubyoR4Qo99R1UQJCdrRsFKbSSfN/fOA4y7ikc3xs jQIDAQAB rsync://rpki.apnic.net/repository/apnic-rpki-root-iana-origin.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx9RWSL61YAAYumEiU8z8 qH2ETVIL01ilxZlzIL9JYSORMN5Cmtf8V2JblIealSqgOTGjvSjEsiV73s67zYQI 7C/iSOb96uf3/s86NqbxDiFQGN8qG7RNcdgVuUlAidl8WxvLNI8VhqbAB5uSg/Mr LeSOvXRja041VptAxIhcGzDMvlAJRwkrYK/Mo8P4E2rSQgwqCgae0ebY1CsJ3Cjf i67C1nw7oXqJJovvXJ4apGmEv8az23OLC6Ki54Ul/E6xk227BFttqFV3YMtKx42H cCcDVZZy01n7JjzvO8ccaXmHIgR7utnqhBRNNq5Xc5ZhbkrUsNtiJmrZzVlgU6Ou 0wIDAQAB rsync://rpki.apnic.net/repository/apnic-rpki-root-lacnic-origin.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyoYPp3l3DWyPtLWrmRn4 Oux9hQ5bxd0SX/f6ygHxik+I3eMJP5J0Pr2e500tyXb2uKsX9kDqu/kckr+TUMhV BHd5yAv8OAE3YYEvpz/7uTX7cYy2yUeA76OEP75Y88OIQEzGpPLNpIzDxMggxuDh IhkA5xMiUJgVoEgmWSzR+MuRBjv2422wAGB5GpLgYsOjpwvG0VPmhnE+39+10ucQ CLt0Ny5kOR4an2tkvHjm7rzKDnFm8MWxPzAWESdf+8g7ITzSglqxDNiK5E5rdzNt h1Kvp+9RwaFArw6Ky1A4HhnoplN4EfKwxq0YamuKV0ZTTpWyT2+qDuE6sOfHRbJ0 5QIDAQAB rsync://rpki.apnic.net/repository/apnic-rpki-root-ripe-origin.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwsQlXmEklLYApoDo7GEa NNTEGFPU5wJpi04iXuga2xn+g/TMLOlyJbjuPYRtRm/7VbRnN3m9Ta+WETy03+Fm EbXzB4xxhJKVik/ARHBnrBWhLyURy8Q5/XplE9cJein37IE1mIsbKM7o/90S225w 7GuvW7T4kjPWYmBFOywHWsfQO1EdsgiJrkz+Ab67ZkdSIiKHkf2UE6/MrbDEj+QK 9+s/vKH8BtDhaLmTWY+bVvfJ3+AWDH6roo1ozbl5yamQFbLOl3ns30f3yOJcNSNu /qgMQRRyp2sXXQovhTy8yqm3LFspaCWnTmQtBieWZwibuOa4Z27A1FzTMst2T4wY /wIDAQAB From bje@apnic.net Sun Oct 14 22:36:51 2012 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 7EB8221F855E for ; Sun, 14 Oct 2012 22:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.769 X-Spam-Level: X-Spam-Status: No, score=-0.769 tagged_above=-999 required=5 tests=[AWL=-1.764, BAYES_50=0.001, RELAY_IS_203=0.994] 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 JfJlgUcu3lU6 for ; Sun, 14 Oct 2012 22:36:48 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id F130D21F854F for ; Sun, 14 Oct 2012 22:36:47 -0700 (PDT) Received: from dynamic220.apnic.net (dynamic220.apnic.net [203.119.42.220]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 40BC0B67EA; Mon, 15 Oct 2012 15:36:45 +1000 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_B5011260-27A3-414C-850A-E2BE5644138E"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Byron Ellacott In-Reply-To: Date: Mon, 15 Oct 2012 15:36:45 +1000 Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F6733D@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F68471@Hermes.columbia.ads.sparta.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1498) Cc: sidr@ietf.org Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting 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 Oct 2012 05:36:51 -0000 --Apple-Mail=_B5011260-27A3-414C-850A-E2BE5644138E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Chris, When did the WG reach consensus on adopting this draft? Thanks, Byron On 13/10/2012, at 12:53 AM, Christopher Morrow = wrote: > Helo, > Since we've been through this for a while (originally) and this has > been quiet for ~1 month... let's call this done and move to the next > step. >=20 > 1) there was lots of discussion on the topic at hand > 2) lots of that discussion was not about acceptance/rejection of the > idea into the WG > 3) lots of people contributed >=20 > I do think we should continue to have this discussion more officially > around a draft, the wg discussion leads me to believe this is the > right course... can the authors spin a newly named version and we can > start discussing the topic / changes? >=20 > I think if, in the end, the wg decides to abandon the work that's also > fine, but we should have a more structured chat about the topic, that > happens around a draft. >=20 > -chris > co-chair >=20 > On Wed, Aug 29, 2012 at 5:06 PM, Murphy, Sandra > wrote: >> Speaking as wg co-chair >>=20 >> Of course revision and new request for acceptance is possible. >>=20 >> Even arguing some more leading to acceptance of draft as is is a = possibility. >>=20 >> Some commentors specifically requested that the discussion be added = to some existing draft. >>=20 >> Trying to judge wg desire of a way to proceed. >>=20 >>=20 >> --Sandy >>=20 >>=20 >> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Andy = Newton [andy@arin.net] >>=20 >> Sent: Wednesday, August 29, 2012 4:56 PM >>=20 >> To: Murphy, Sandra; Alexey Melnikov; sidr@ietf.org >>=20 >> Subject: Re: [sidr] WG acceptance call for = draft-ymbk-rpki-grandparenting >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Are the chairs not allowing the draft authors to address the issues = and try again? >>=20 >>=20 >>=20 >> -andy >>=20 >>=20 >>=20 >>=20 >>=20 >> From: , Sandra >>=20 >> Date: Wednesday, August 29, 2012 12:10 PM >>=20 >> To: Alexey Melnikov , "sidr@ietf.org" >> >>=20 >> Subject: Re: [sidr] WG acceptance call for = draft-ymbk-rpki-grandparenting >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> >> BODY {direction: ltr;font-family: Arial;color: #000000;font-size: = 10pt;}P {margin-top:0;margin-bottom:0;} >>=20 >> Speaking as wg co-chair: >>=20 >>=20 >>=20 >> Certainly a very lively acceptance call! >>=20 >>=20 >>=20 >> The chairs do not see that there was consensus that the wg should = adopt this draft. >>=20 >>=20 >>=20 >> But there was ample evidence that the wg was interested in the issue = - by the wg spending lots of time discussing the issue. >>=20 >>=20 >>=20 >> So that leaves the chairs with an ambivalent message. The wg is very = interested in the topic but not in adopting a draft that would record = any decisions about the topic. >>=20 >>=20 >>=20 >> What would the wg like to do now? Particularly those who disagreed = with the content of the draft - if you would dislike the = recommendations, are you OK with no recommendations instead? >>=20 >>=20 >>=20 >> --Sandy, speaking as wg co-chair >>=20 >>=20 >>=20 >>=20 >>=20 >> From: >>=20 >> sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Alexey = Melnikov [alexey.melnikov@isode.com] >>=20 >> Sent: Saturday, August 04, 2012 2:12 PM >>=20 >> To: >> sidr@ietf.org >>=20 >> Subject: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting >>=20 >>=20 >>=20 >>=20 >>=20 >> Hi, >>=20 >> On behalf of SIDR WG chairs I would like to initiate 2 weeks = acceptance call for draft-ymbk-rpki-grandparenting starting from today, = August 4th. Please >> send your positive or negative feedback to the mailing list or = directly to chairs. >>=20 >>=20 >>=20 >>=20 >> Thank you, >> Alexey >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 --Apple-Mail=_B5011260-27A3-414C-850A-E2BE5644138E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEBjCCBAIw ggLqoAMCAQICCCoPITf60ZNDMA0GCSqGSIb3DQEBBQUAMHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMB4XDTExMTEyODAxNTEzNloXDTEy MTEyNzAxNTEzNlowgZIxGTAXBgoJkiaJk/IsZAEBDAliamUtc3RhZmYxEjAQBgNVBAMMCWJqZS1z dGFmZjEOMAwGA1UEKgwFQnlyb24xETAPBgNVBAQMCEVsbGFjb3R0MQ8wDQYDVQQLDAZQZW9wbGUx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxFTATBgoJkiaJk/IsZAEZFgVzdGFmZjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANVQo/BOmY5CCWNeAldlgoWZKOzIZpOsFzD6NB2oAErtclDu uiZsXfl+L97UOwUlhu1eGlY5gKuAhGcrEBvDgTT1eEr3vkdKILhJw78s5n8eLOWrmhPKBnW8gSn9 7MbAxVQx3V1/RpToKAF8cR4il03Z7mveaBQbaivM2jReHcgfJPt9w0qhTVZO2POLuVClRcExaNt1 h+QdMLa6VU5x7rJo9JFqjTAvJzMApW+WY/7oumR9+4a9ZGThlETI2b83XAMrrJ7DHm237Jskgl+X FGILIq8zOhNiAbhEg+gAyJ8bOzwwydDY+ggWQ466duZZq4wxmr1+YhxVf51v2R5MSicCAwEAAaN6 MHgwHQYDVR0OBBYEFIQXSivz3cLpaFy23DdhpGhyyo5pMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw FoAU4D23klvuLqOyPnnbRaswQi8BS6wwDgYDVR0PAQH/BAQDAgHyMBgGA1UdEQQRMA+BDWJqZUBh cG5pYy5uZXQwDQYJKoZIhvcNAQEFBQADggEBAEk9zi8BTUEY4rqDGEIFDNIpmX/yS3fTah39Mele pV93sRsjqLy2G47vhhnkgSTEWV2jJOD7tjzjswxtWUL6KG36dUDVL3XbQ1OObxkiDJbqje4BoWrd a8/5PoIPC0hkSDXGoitvoXkL8Pd9x9Y+kyMlKo1C0lk5bCUG4yjk5wVLuSSm5m+KZ3+YVdPp6dKp C0DRhvFdsrz2zIOT/sWheCQO0HRU300UYngB/xoqc1KWH2dROIUhLqwtyoCQbQKQjW9C+JMMw2Ij vfVXJZGMWjbp5l8RQeUSJ+0vVJXJbIL6PfEsyQupUV3AJsSTRmtllqzCBCz2Abd14xyeqw0eJfwx ggMtMIIDKQIBATB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwxFjAU BgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYC Y2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzAJBgUrDgMCGgUAoIIBgzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjEwMTUwNTM2NDVaMCMGCSqGSIb3DQEJBDEWBBS8 40Tzh6HvyxLiyTnfwsSbupfOXDCBjwYJKwYBBAGCNxAEMYGBMH8wczERMA8GA1UEAwwIc3RhZmYt Y2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwI QnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUCCCoPITf60ZNDMIGRBgsq hkiG9w0BCRACCzGBgaB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQB GRYCY2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzANBgkqhkiG9w0BAQEFAASCAQA6tgqXNzadkdH7 z6cWx19IxeVzFZ7VCQNf7DzbH+qn+eax+oq6bA1CuMZE9evzHYxVH9PUaQMxWc56cFJv0VazBAjI FyZNfEozW1ppY6uE096tkyvgljuEtK0FOObK/Cx6CvxXr7NFzTfo1p1geeZ+taTu/tSb2/uY0t7n QjlmsafYEtYHwoQFc3iEkSAHiSEtuQyQmwKyB2ftWbr1r5Yn/UkOQc/0byW3H9kK3xJMkqBD7ISX 9DbgIwFX88/eVVMDajy8Ki9VTTAoEUJFQo4evw4uU2kCXlhx0Iso6ch9iS/NvgD56f+Q5k6cr1GS r6Exbm0Y6GWCEpifhbKdbzQWAAAAAAAA --Apple-Mail=_B5011260-27A3-414C-850A-E2BE5644138E-- From andy@arin.net Mon Oct 15 06:21:37 2012 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 E6EA521F877C for ; Mon, 15 Oct 2012 06:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 6gWU0Qp14oH1 for ; Mon, 15 Oct 2012 06:21:37 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id C67B821F8779 for ; Mon, 15 Oct 2012 06:21:36 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 3E654213640; Mon, 15 Oct 2012 09:21:34 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id B9D6A213645; Mon, 15 Oct 2012 09:21:33 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.18) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 15 Oct 2012 09:20:59 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.245]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0318.004; Mon, 15 Oct 2012 09:21:33 -0400 From: Andy Newton To: Christopher Morrow , "Murphy, Sandra" Thread-Topic: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting Thread-Index: AQHNcmy8FCcE8Dzhaka0MZcJTJP7npdxX+YAgAAMpICAAEYPAIBEvmMAgARaKAA= Date: Mon, 15 Oct 2012 13:21:32 +0000 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.2.4.120824 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <9EFFCA150F6FC24FBEF88D977EA68B6D@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting 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 Oct 2012 13:21:38 -0000 On 10/12/12 10:53 AM, "Christopher Morrow" wrote: >I think if, in the end, the wg decides to abandon the work that's also >fine, but we should have a more structured chat about the topic, that >happens around a draft. As the person who specifically asked of the chairs that the draft authors be allowed to address the issues raised, I'd like specifics on this more structured chat. I ask because it is not apparent that the normal means of IETF discussion were attempted. Of the 38 messages regarding the draft directly, the draft author only responded 3 times, nor did the author engage in any of the side discussions. And the draft submitted as a working group document addresses NONE of the issues raised (it is just a re-spin with the dates and file name changed). If normal IETF discourse is being set aside especially when it was not fully engaged, we should also be given the exception criteria under which this scenario qualifies when others do not. -andy From internet-drafts@ietf.org Mon Oct 15 10:49:55 2012 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 A513421F8807; Mon, 15 Oct 2012 10:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdM+wbVHE1uu; Mon, 15 Oct 2012 10:49:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF7521F8799; Mon, 15 Oct 2012 10:49:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121015174955.28531.76138.idtracker@ietfa.amsl.com> Date: Mon, 15 Oct 2012 10:49:55 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 17:49:55 -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 Group= of the IETF. Title : A Profile for BGPSEC Router Certificates, Certificate Re= vocation Lists, and Certification Requests Author(s) : Mark Reynolds Sean Turner Steve Kent Filename : draft-ietf-sidr-bgpsec-pki-profiles-04.txt Pages : 12 Date : 2012-10-15 Abstract: This document defines a standard profile for X.509 certificates for the purposes of supporting validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPSEC. BGP is a critical component for the proper operation of the Internet as a whole. The BGPSEC protocol is under development as a component to address the requirement to provide security for the BGP protocol. The goal of BGPSEC is to design a protocol for full AS path validation based on the use of strong cryptographic primitives. The end-entity (EE) certificates specified by this profile are issued under Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificates, containing the AS Identifier Delegation extension, to routers within the Autonomous System (AS). The certificate asserts that the router(s) holding the private key are authorized to send out secure route advertisements on behalf of the specified AS. This document also profiles the Certificate Revocation List (CRL), profiles the format of certification requests, and specifies Relying Party certificate path validation procedures. The document extends the RPKI; therefore, this documents updates the RPKI Resource Certificates Profile (RFC 6487). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-pki-profiles-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From turners@ieca.com Mon Oct 15 10:53:10 2012 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 7AEB221F8829 for ; Mon, 15 Oct 2012 10:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJ0wGbi-H+Db for ; Mon, 15 Oct 2012 10:53:05 -0700 (PDT) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [67.18.59.7]) by ietfa.amsl.com (Postfix) with ESMTP id 8071D21F8826 for ; Mon, 15 Oct 2012 10:53:05 -0700 (PDT) Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id 6E165ED42CD04; Mon, 15 Oct 2012 12:53:09 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway12.websitewelcome.com (Postfix) with ESMTP id 5795FED42CCD3 for ; Mon, 15 Oct 2012 12:53:09 -0500 (CDT) Received: from [96.241.97.104] (port=59985 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TNoqe-0003SI-K2 for sidr@ietf.org; Mon, 15 Oct 2012 12:53:04 -0500 Message-ID: <507C4D85.7010400@ieca.com> Date: Mon, 15 Oct 2012 12:53:09 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: sidr@ietf.org References: <20121015174955.28531.76138.idtracker@ietfa.amsl.com> In-Reply-To: <20121015174955.28531.76138.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.241.97.104]:59985 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 17:53:10 -0000 As the previous version expired, I posted a new version that incorporates two changes (noted in App D): In s2.1, removed the phrase "another BGPSEC Router Certificate (only BGPSEC routers process these)" because the BGPSEC certificates are only ever EE certificates and they're never used to verify another certificate only the PDUs that are signed. Added new s3.1.3.1 to explicitly state that EE certificates are only ever EE certs. Let me know if there's any other comments as there's still a couple of days before the submission window closes. spt On 10/15/12 12:49 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. > > Title : A Profile for BGPSEC Router Certificates, Certificate Revocation Lists, and Certification Requests > Author(s) : Mark Reynolds > Sean Turner > Steve Kent > Filename : draft-ietf-sidr-bgpsec-pki-profiles-04.txt > Pages : 12 > Date : 2012-10-15 > > Abstract: > This document defines a standard profile for X.509 certificates for > the purposes of supporting validation of Autonomous System (AS) paths > in the Border Gateway Protocol (BGP), as part of an extension to that > protocol known as BGPSEC. BGP is a critical component for the proper > operation of the Internet as a whole. The BGPSEC protocol is under > development as a component to address the requirement to provide > security for the BGP protocol. The goal of BGPSEC is to design a > protocol for full AS path validation based on the use of strong > cryptographic primitives. The end-entity (EE) certificates specified > by this profile are issued under Resource Public Key Infrastructure > (RPKI) Certification Authority (CA) certificates, containing the AS > Identifier Delegation extension, to routers within the Autonomous > System (AS). The certificate asserts that the router(s) holding the > private key are authorized to send out secure route advertisements on > behalf of the specified AS. This document also profiles the > Certificate Revocation List (CRL), profiles the format of > certification requests, and specifies Relying Party certificate path > validation procedures. The document extends the RPKI; therefore, > this documents updates the RPKI Resource Certificates Profile (RFC > 6487). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From iesg-secretary@ietf.org Mon Oct 15 13:20:25 2012 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 91CC221F89BA; Mon, 15 Oct 2012 13:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUN2qD71ikLW; Mon, 15 Oct 2012 13:20:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9617121F89F1; Mon, 15 Oct 2012 13:20:24 -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: 4.34 Message-ID: <20121015202024.17206.9583.idtracker@ietfa.amsl.com> Date: Mon, 15 Oct 2012 13:20:24 -0700 Cc: sidr mailing list , sidr chair , RFC Editor Subject: [sidr] Protocol Action: 'BGP Prefix Origin Validation' to Proposed Standard (draft-ietf-sidr-pfx-validate-10.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 20:20:25 -0000 The IESG has approved the following document: - 'BGP Prefix Origin Validation' (draft-ietf-sidr-pfx-validate-10.txt) as 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-pfx-validate/ Technical Summary To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination AS of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. Working Group Summary There were several revisions (8) of this document, there was a fairly lengthy discussion in several in-person meetings as well as on-list. In the end, all of the issues seem to have been dealt with. Document Quality To date, there are 2 implementations in vendor code, one of which brought about the single IPR claim against this document. Personnel Chris Morrow is the Document Shepherd for this document. Stewart Bryant is the Responsible Area Director. From rogaglia@cisco.com Thu Oct 18 06:04:07 2012 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 EA5AE21F8552 for ; Thu, 18 Oct 2012 06:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxD77lILoTv2 for ; Thu, 18 Oct 2012 06:04:05 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A583B21F8546 for ; Thu, 18 Oct 2012 06:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4798; q=dns/txt; s=iport; t=1350565445; x=1351775045; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ySzeIkM+ziYvEJKrtxjGz9gbOOtVKApyCEax7x3lmNI=; b=JCpz+nxrv+kCV/30KKxO+TpJlP01zve/vfwQZvQn84EA9G2fw/g8vsat +DODGXRGcexhtVGFQwjVrh4u1L2fE4fUtGlTa/Dt4jXvC3seUEHqZobPq gLCajMxgbL9IrA1Z22tXmNKZiVyWdNezzGZbPimkdC7K1EaKkZ7/uJmH1 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADH9f1CtJXG9/2dsb2JhbABFwD2BCIIgAQEBAgEBAQEBDwEnMgIIAQIFBwQCAQgRBAEBCxQFBAchBgsUCAEIAgQOBQgBGYdQAwkGC5wollENiVSKcGiFYmADiz6IWIJqhTuEVIMlgWuCb4IX X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="132992864" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 18 Oct 2012 13:04:05 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9ID45Be012436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Oct 2012 13:04:05 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.23]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 08:04:04 -0500 From: "Roque Gagliano (rogaglia)" To: "Sriram, Kotikalapudi" Thread-Topic: [sidr] FW: New Version Notification for draft-sriram-replay-protection-design-discussion-00.txt Thread-Index: AQHNrTENYVfUFBdyXUOH4ZzYAxQB0Q== Date: Thu, 18 Oct 2012 13:04:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.19.24] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--47.312300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <9436B00AC83FEC409FF7A979DD700588@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] FW: New Version Notification for draft-sriram-replay-protection-design-discussion-00.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, 18 Oct 2012 13:04:07 -0000 Sriram, I read your document and I have a some comments. 1) In general I did not understand the objective of this draft as you are b= asically re-stating what is already briefly mentioned at draft-ietf-sidr-bg= psec-rollover-00 and no new elements are there for the WG to take an action= . Particularly, I was surprised that in your assessment for the PKR method = you did not considered the points highlighted in section 4.2 of our draft (= Advantages/Disadvantages). 2) Your summary statement: "The Expire Time (ET) method is best" does not r= epresent the WG consensus when our draft was accepted as WG item and when t= he timestamp field was removed from the Protocol Specification. IMHO, the p= roblem with your comparison between ET and PKR is that you did not mentione= d that implementing ET introduces important changes to current BGP implemen= tations. The design decision is to either maintain states in every BGP spea= ker (having to allocate an expiration time to every update and needing to c= heck if that time is old) vs increase the churn at the RPKI repository syst= em and more admin processes in the RPKI. The group took the second path. 3) Your study of EKR is very bias because the effect of event-driven key ro= llovers will depends on the event that is driving that key rollover. Partic= ularly, and putting it on the same words that our draft uses, in this parti= cular case you are comparing a rollover of the "transit" certificate key vs= a rollover of the "origin" certificate key. As you wrote in the document, when you rollover the transit certificate, yo= u gain the possibility to refresh transit policies which is not the case wi= th either ET or only rolling over the origin certificate key using PKR. But= rolling over the transit certificate key should be very rare because of th= e reasons that you and us mention. Regards, Roque On Sep 22, 2012, at 1:19 AM, Sriram, Kotikalapudi wrote: > This submission is an informative design discussion document that provide= s insights=20 > into the operation of multiple alternative methods for replay-attack prot= ection.=20 > We hope that the SIDR WG will take the insights and trade-offs presented = here as input=20 > for deciding on the choice of a mechanism for protection from replay atta= cks. > It is meant to be a companion document to the standards track=20 > I-D.-ietf-sidr-bgpsec-rollover that will specify a method to be used=20 > with BGPSEC for replay-attack protection. >=20 > A set slides with figures that is referenced in the document can be found= at: > http://www.nist.gov/itl/antd/upload/replay-discussion.pdf=20 > (the figures are helpful but not necessary to read the document). >=20 > Comments welcome. >=20 > Sriram >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: Friday, September 21, 2012 7:01 PM > To: sriram.ietf@gmail.com > Cc: Montgomery, Douglas; Sriram, Kotikalapudi > Subject: New Version Notification for draft-sriram-replay-protection-desi= gn-discussion-00.txt >=20 >=20 > A new version of I-D, draft-sriram-replay-protection-design-discussion-00= .txt > has been successfully submitted by Kotikalapudi Sriram and posted to the = IETF repository. >=20 > Filename: draft-sriram-replay-protection-design-discussion > Revision: 00 > Title: Design Discussion and Comparison of Replay-Attack Protection Mec= hanisms for BGPSEC > Creation date: 2012-09-22 > WG ID: Individual Submission > Number of pages: 17 > URL: http://www.ietf.org/internet-drafts/draft-sriram-replay-= protection-design-discussion-00.txt > Status: http://datatracker.ietf.org/doc/draft-sriram-replay-prot= ection-design-discussion > Htmlized: http://tools.ietf.org/html/draft-sriram-replay-protectio= n-design-discussion-00 >=20 >=20 > Abstract: > The BGPSEC protocol requires a method for protection from replay > attacks, at least to control the window of exposure. In the context > of BGPSEC, a replay attack occurs when an adversary suppresses a > prefix withdrawal (implicit or explicit) or replays a previously > received BGPSEC announcement for a prefix that has since been > withdrawn. This informational document provides design discussion > and comparison of multiple alternative replay-attack protection > mechanisms weighing their pros and cons. It is meant to be a > companion document to the standards track I-D.-ietf-sidr-bgpsec- > rollover that will specify a method to be used with BGPSEC for > replay-attack protection. >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From rogaglia@cisco.com Fri Oct 19 00:55:44 2012 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 5554621F8784 for ; Fri, 19 Oct 2012 00:55:44 -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 gPT1dOZ4M7ll for ; Fri, 19 Oct 2012 00:55:43 -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 1234721F86BB for ; Fri, 19 Oct 2012 00:55:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5272; q=dns/txt; s=iport; t=1350633343; x=1351842943; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wwsLBEiQ01lkSxmfxmQkrSEBatO+N/G81I2+wVzg/PY=; b=ctNbXXKq0Y49sl+WH/bAdNCzCfhpzr7WhsqN9Q8GlBHJzsALb52zNNHa +Suet9uW/HkEPw79CvMgmYRyIARBLciNSSuD7yeJDIf1el+HmqCj+tnFX HbbgJCSdB/8mRy4TXOJR2wK7O1OtkqTMuXA3NWbXsoD7Tf+ueeok0i5KG Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAUGgVCtJXG8/2dsb2JhbABFwFyBCIIgAQEBAgEBAQEBDwEnMgIIAQIFBwQCAQgRBAEBAQoUBQQHIQYLFAgBCAIEDgUIARmHUAMJBgudLJZEDYlUinBohWJgA4s+iFiCaoU7hFSDJYFrgm+BYzQ X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="133324879" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 19 Oct 2012 07:55:42 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9J7tgBu000682 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Oct 2012 07:55:42 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.176]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Fri, 19 Oct 2012 02:55:41 -0500 From: "Roque Gagliano (rogaglia)" To: "Roque Gagliano (rogaglia)" Thread-Topic: [sidr] FW: New Version Notification for draft-sriram-replay-protection-design-discussion-00.txt Thread-Index: AQHNrTENYVfUFBdyXUOH4ZzYAxQB0ZfAl7MA Date: Fri, 19 Oct 2012 07:55:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.19.24] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--51.151300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <3A9C869CEF069A4B811C38EB11927F68@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Sriram, Kotikalapudi" , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] FW: New Version Notification for draft-sriram-replay-protection-design-discussion-00.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, 19 Oct 2012 07:55:44 -0000 Sriram, One thing that did not went out well in my previous email is that I really = appreciate the time you guys took to look into this issue. Regards, Roque On Oct 18, 2012, at 3:04 PM, Roque Gagliano (rogaglia) wrote: > Sriram, >=20 > I read your document and I have a some comments. >=20 > 1) In general I did not understand the objective of this draft as you are= basically re-stating what is already briefly mentioned at draft-ietf-sidr-= bgpsec-rollover-00 and no new elements are there for the WG to take an acti= on. Particularly, I was surprised that in your assessment for the PKR metho= d you did not considered the points highlighted in section 4.2 of our draft= (Advantages/Disadvantages). >=20 > 2) Your summary statement: "The Expire Time (ET) method is best" does not= represent the WG consensus when our draft was accepted as WG item and when= the timestamp field was removed from the Protocol Specification. IMHO, the= problem with your comparison between ET and PKR is that you did not mentio= ned that implementing ET introduces important changes to current BGP implem= entations. The design decision is to either maintain states in every BGP sp= eaker (having to allocate an expiration time to every update and needing to= check if that time is old) vs increase the churn at the RPKI repository sy= stem and more admin processes in the RPKI. The group took the second path. >=20 > 3) Your study of EKR is very bias because the effect of event-driven key = rollovers will depends on the event that is driving that key rollover. Part= icularly, and putting it on the same words that our draft uses, in this par= ticular case you are comparing a rollover of the "transit" certificate key = vs a rollover of the "origin" certificate key. > As you wrote in the document, when you rollover the transit certificate, = you gain the possibility to refresh transit policies which is not the case = with either ET or only rolling over the origin certificate key using PKR. B= ut rolling over the transit certificate key should be very rare because of = the reasons that you and us mention. >=20 > Regards, > Roque >=20 >=20 >=20 > On Sep 22, 2012, at 1:19 AM, Sriram, Kotikalapudi wrote: >=20 >> This submission is an informative design discussion document that provid= es insights=20 >> into the operation of multiple alternative methods for replay-attack pro= tection.=20 >> We hope that the SIDR WG will take the insights and trade-offs presented= here as input=20 >> for deciding on the choice of a mechanism for protection from replay att= acks. >> It is meant to be a companion document to the standards track=20 >> I-D.-ietf-sidr-bgpsec-rollover that will specify a method to be used=20 >> with BGPSEC for replay-attack protection. >>=20 >> A set slides with figures that is referenced in the document can be foun= d at: >> http://www.nist.gov/itl/antd/upload/replay-discussion.pdf=20 >> (the figures are helpful but not necessary to read the document). >>=20 >> Comments welcome. >>=20 >> Sriram >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 >> Sent: Friday, September 21, 2012 7:01 PM >> To: sriram.ietf@gmail.com >> Cc: Montgomery, Douglas; Sriram, Kotikalapudi >> Subject: New Version Notification for draft-sriram-replay-protection-des= ign-discussion-00.txt >>=20 >>=20 >> A new version of I-D, draft-sriram-replay-protection-design-discussion-0= 0.txt >> has been successfully submitted by Kotikalapudi Sriram and posted to the= IETF repository. >>=20 >> Filename: draft-sriram-replay-protection-design-discussion >> Revision: 00 >> Title: Design Discussion and Comparison of Replay-Attack Protection Me= chanisms for BGPSEC >> Creation date: 2012-09-22 >> WG ID: Individual Submission >> Number of pages: 17 >> URL: http://www.ietf.org/internet-drafts/draft-sriram-replay= -protection-design-discussion-00.txt >> Status: http://datatracker.ietf.org/doc/draft-sriram-replay-pro= tection-design-discussion >> Htmlized: http://tools.ietf.org/html/draft-sriram-replay-protecti= on-design-discussion-00 >>=20 >>=20 >> Abstract: >> The BGPSEC protocol requires a method for protection from replay >> attacks, at least to control the window of exposure. In the context >> of BGPSEC, a replay attack occurs when an adversary suppresses a >> prefix withdrawal (implicit or explicit) or replays a previously >> received BGPSEC announcement for a prefix that has since been >> withdrawn. This informational document provides design discussion >> and comparison of multiple alternative replay-attack protection >> mechanisms weighing their pros and cons. It is meant to be a >> companion document to the standards track I-D.-ietf-sidr-bgpsec- >> rollover that will specify a method to be used with BGPSEC for >> replay-attack protection. >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From internet-drafts@ietf.org Fri Oct 19 01:17:58 2012 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 01E5D21F84A2; Fri, 19 Oct 2012 01:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 RaDBhv1Jv7Jm; Fri, 19 Oct 2012 01:17:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05A121F8493; Fri, 19 Oct 2012 01:17: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: 4.34 Message-ID: <20121019081756.28555.32599.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2012 01:17:56 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-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: Fri, 19 Oct 2012 08:17:58 -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 Group= of the IETF. Title : Algorithm Agility Procedure for RPKI. Author(s) : Roque Gagliano Stephen Kent Sean Turner Filename : draft-ietf-sidr-algorithm-agility-08.txt Pages : 30 Date : 2012-10-19 Abstract: This document specifies the process that Certification Authorities (CAs) and Relying Parties (RPs) 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 datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-algorithm-agility There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-algorithm-agility-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-algorithm-agility-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rogaglia@cisco.com Fri Oct 19 04:44:05 2012 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 2E92521F8630; Fri, 19 Oct 2012 04:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDPRvHOV32AQ; Fri, 19 Oct 2012 04:44:04 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 25B8521F862E; Fri, 19 Oct 2012 04:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1919; q=dns/txt; s=iport; t=1350647044; x=1351856644; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=39xZcaHWjj5jSCzVAHBWJkEeOJqgcXNEMXz6Y/QJ88Y=; b=jGuCSXGoTdSpIDi2q6z4r/lS68CH/JCLYl9g6WaD/0D3lq2jJVAhysBK mJcxD7qaRD0xhOmAEvp/gvgJJ/F8tkjsq5t2u5dO1HjKQCsoJebEurQ63 NlQAv3jEaBKRncGPN2ydpx36Ft621aMYLhFkYSUU+ldwAoVr3ShvHFL5a 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD08gVCtJV2Y/2dsb2JhbABFwGGBCIIgAQEBAwEBAQEPASc0CxACAQgiFBAnCyUCBA4FCAEZh1wGC50GoDGLWIYPYAOXBo02gWuCb4IX X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="133377245" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 19 Oct 2012 11:44:03 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9JBi36a026686 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Oct 2012 11:44:03 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.176]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Fri, 19 Oct 2012 06:44:03 -0500 From: "Roque Gagliano (rogaglia)" To: " " Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-08.txt Thread-Index: AQHNre8I1iIvKnSa9EiHT2diBfMc1Q== Date: Fri, 19 Oct 2012 11:44:02 +0000 Message-ID: References: <20121019081756.28555.32599.idtracker@ietfa.amsl.com> In-Reply-To: <20121019081756.28555.32599.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.19.24] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--40.171400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <5DC846C3C1A72F419A9694C4F9D29F7B@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-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: Fri, 19 Oct 2012 11:44:05 -0000 Hi Group, Correcting some nits detected by the WG chairs before sending it to the IES= G. Cheers! Roque On Oct 19, 2012, at 10:17 AM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Secure Inter-Domain Routing Working Grou= p of the IETF. >=20 > Title : Algorithm Agility Procedure for RPKI. > Author(s) : Roque Gagliano > Stephen Kent > Sean Turner > Filename : draft-ietf-sidr-algorithm-agility-08.txt > Pages : 30 > Date : 2012-10-19 >=20 > Abstract: > This document specifies the process that Certification Authorities > (CAs) and Relying Parties (RPs) 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 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-algorithm-agility >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-algorithm-agility-08 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-algorithm-agility-08 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From kotikalapudi.sriram@nist.gov Fri Oct 19 09:36:46 2012 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 5027D21F872E for ; Fri, 19 Oct 2012 09:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqUE+ya927an for ; Fri, 19 Oct 2012 09:36:45 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 0C40E21F8799 for ; Fri, 19 Oct 2012 09:36:44 -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.379.0; Fri, 19 Oct 2012 12:35:55 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 19 Oct 2012 12:36:14 -0400 From: "Sriram, Kotikalapudi" To: "Roque Gagliano (rogaglia)" Date: Fri, 19 Oct 2012 12:36:13 -0400 Thread-Topic: [sidr] FW: New Version Notification for draft-sriram-replay-protection-design-discussion-00.txt Thread-Index: AQHNrTENYVfUFBdyXUOH4ZzYAxQB0ZfAl7MAgAA2IbA= Message-ID: 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" MIME-Version: 1.0 Cc: "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] FW: New Version Notification for draft-sriram-replay-protection-design-discussion-00.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, 19 Oct 2012 16:36:46 -0000 Roque, >One thing that did not went out well in my previous email is that I really appreciate the time you guys took to look into this issue. Amendment gladly accepted! Thank you. We enjoyed putting in the effort as it was a great learning opportunity for us as well. Thanks to you, Brian W. and Keyur for getting the ball rolling initially on this. >On Oct 18, 2012, at 3:04 PM, Roque Gagliano (rogaglia) wrote: > Sriram, > > I read your document and I have a some comments. > Let me make the overarching observation upfront that our document does NOT seek to promote any one method over another. > > 1) In general I did not understand the objective of this draft as you are basically re-stating what is already briefly mentioned at draft-ietf-sidr-bgpsec-rollover-00 and no new elements are there for the WG to take an action. > At first, your observation seemed like a hastily formed opinion. But you seem to have amended it since then. Let me make the following points regarding the above: 1. It is not uncommon to have a rationale / design discussion document that complements a design specification document. In the SIDR WG we did that with draft-lepinski-bgpsec-protocol (the initial individual I-D), when we also submitted draft-sriram-bgpsec-design-choices. 2. The design specification document is normally brief and to-the-point meant for the implementers. The *informational* discussion document should capture things like enumerating the alternative design choices that were proposed/considered, the pros/cons analysis, example scenarios, and evaluation and comparison of design choices under those scenarios, etc. The latter is what we have attempted to do in our document and provided several new insights as well. 3. Even after the design is complete and the WG has finalized a design specification, late comers still tend raise questions about alternatives. The *informational* discussion document is the place to go to for anyone who wants to peruse into history and the design rationale. > >Particularly, I was surprised that in your assessment for the PKR method you did not considered the points highlighted in section 4.2 of our draft (Advantages/Disadvantages). > In your Section 4.2, you have proposed what looks like a hybrid of PKR and EKR methods (without using that specific taxonomy). We consider PKR and EKR as separate design choices, and hence discussed their pros/cons separately. But I think we have captured many of the same advantages/disadvantages you have outlined and some additional ones. We are open to taking in comments and revising the document as needed; so we will be happy to relook at that. I have a question for you on your Section 4.2 regarding why you propose to implement a hybrid of PKR and EKR. Let me take that up in a separate thread. > > 2) Your summary statement: "The Expire Time (ET) method is best" does not represent the WG consensus when our draft was accepted as WG item and when the timestamp field was removed from the Protocol Specification. > We are fully mindful of the WG consensus and we are in no way promoting the ET method in the document. You took a piece of the whole statement and made it appear like that was the summary of our document. The actual statement (in Section 7) in the document is as follows: "1. The Expire Time (ET) method is best (on par with the PKR method) in terms of preventing huge update workloads during peering and policy change events at transit routers with several peers. It has no added RPKI churn. But the ET method has the disadvantage of requiring on-the-wire protocol change if some parameters (e.g., the units of beacon interval) change." The intent here was just to equate the ET and PKR methods in terms of update workload. We would change the first sentence (when revised) to read: "The ET and PKR method are on par in terms of preventing huge update workloads ......" > >IMHO, the problem with your comparison between ET and PKR is that you did not mentioned that implementing ET introduces important changes to current BGP implementations. The design decision is to either maintain states in every BGP speaker (having to allocate an expiration time to every update and needing to check if that time is old) vs increase the churn at the RPKI repository system and more admin processes in the RPKI. The group took the second path. > It depends on how you see it. How would you keep track of the NotValidAfter time of update signatures (as determined by the NotValidAfter time of the respective certs) in the PKR method? If keeping track of this is done in the router, then there is a need to maintain state even in the PKR method. OTOH, if the RPKI cache server is sending a withdraw of the public key when the cert's NotValidAfter time is reached, even then the BGP process needs to scan the update tables and prune out the ones that are affected. I think that also implies changes to the current BGP implementations anyway. However, we did observe that with the ET method we have the disadvantage that the expire-time field is built into on-the-wire BGPSEC protocol and that is not a desirable feature. > > 3) Your study of EKR is very bias because the effect of event-driven key rollovers will depends on the event that is driving that key rollover. Particularly, and putting it on the same words that our draft uses, in this particular case you are comparing a rollover of the "transit" certificate key vs a rollover of the "origin" certificate key. > I think you are referring to slides 6-8 in http://www.nist.gov/itl/antd/upload/replay-discussion.pdf No, we are not comparing apples and oranges here. In these comparisons (see slide 8), we do not focus at all on the rollover of the "origin" certificate key. That actually has a very minor impact on updates (as illustrated in slide 5) and we don't focus on that in the plot in slide 8. Instead, what we consider in slides 6-8 is that when the event occurs, in the PKR method no cert is rolled (by design). But even then a certain amount of BGPSEC updates would be propagated similar to what happens in conventional BGP-4. That is because the router will recompute new best paths for the prefixes affected by the event, and those updates need to be propagated even though no key has been rolled due to the event. In some scenarios such as Scenario 1 in slide #6, no updates are generated in PKR under those circumstances. But in another scenario such as Scenario 2 in slide #7, a moderate burst of updates is generated in PKR (same number as in BGP-4). However, in both scenarios, a huge burst of updates is generated in the EKR method due to the transit key rollover which causes all prefix routes to be propagated or re-propagated at that router. I hope this explanation helps. > > As you wrote in the document, when you rollover the transit certificate, you gain the possibility to refresh transit policies which is not the case with either ET or only rolling over the origin certificate key using PKR. But rolling over the transit certificate key should be very rare because of the reasons that you and us mention. > I agree. Thank you once again for reading and commenting on the document. Regards, Sriram From kotikalapudi.sriram@nist.gov Sun Oct 21 12:43:31 2012 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 89A0D21F8A1B for ; Sun, 21 Oct 2012 12:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, 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 V-+GXyEgAawn for ; Sun, 21 Oct 2012 12:43:28 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id EA21221F8A12 for ; Sun, 21 Oct 2012 12:43:27 -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.421.2; Sun, 21 Oct 2012 15:42:59 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Sun, 21 Oct 2012 15:42:59 -0400 From: "Sriram, Kotikalapudi" To: "Roque Gagliano (rogaglia)" Date: Sun, 21 Oct 2012 15:40:13 -0400 Thread-Topic: Question on Section 4.2 of draft-ietf-sidr-bgpsec-rollover-00 Thread-Index: AQHNr8PjHSOXjoBOGkeUXqCTDpmH7A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "sidr wg list \(sidr@ietf.org\)" Subject: [sidr] Question on Section 4.2 of draft-ietf-sidr-bgpsec-rollover-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 19:43:31 -0000 Roque, I took another look at Section 4.2. Can you please clarify if the method you describe in Sec. 4.2 is purely the PKR method, or if it has elements of both PKR and EKR in it? Do you roll the transit key when an event (peering discontinuation or policy change) happens at a router having transit prefixes? This is not clear from the wording in Section 4.2. Thanks. Sriram From rogaglia@cisco.com Mon Oct 22 01:56:42 2012 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 1559821F872E for ; Mon, 22 Oct 2012 01:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okhFsRBAPX0K for ; Mon, 22 Oct 2012 01:56:40 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id AA00C21F8549 for ; Mon, 22 Oct 2012 01:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9354; q=dns/txt; s=iport; t=1350896201; x=1352105801; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0qSlu9kay82LPOTaDMReOcuIkI9jB8XAeXOVFYXW0X0=; b=l5qdT1G37kpqrZSgjWys5faw/1GTEm03Yg7WFsMtYznfarWX0R7qABUW EQqs8x0m7XGt0hJw4S4nETJumWfrVi1CGH7GLZqaDJ5FinprBUkj9tEaz kfERJStqtlaYIV8XXFO1XEsfq26PzvEQvVg1Yowe2PJYey1VFQZv/OdzZ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIEJhVCtJV2Z/2dsb2JhbABFwQuBCIIgAQEBAgEBEgEnMgoBAgULAgEIIhQFCzIcCQIEDg0ah1wGC5tbnx+RbmADi0ORAId8gWuCb4FaAgUCFwYY X-IronPort-AV: E=Sophos;i="4.80,628,1344211200"; d="scan'208";a="133974162" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 22 Oct 2012 08:56:40 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9M8ueMq005169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Oct 2012 08:56:40 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.176]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 03:56:39 -0500 From: "Roque Gagliano (rogaglia)" To: "Sriram, Kotikalapudi" Thread-Topic: [sidr] FW: New Version Notification for draft-sriram-replay-protection-design-discussion-00.txt Thread-Index: AQHNrTENYVfUFBdyXUOH4ZzYAxQB0Q== Date: Mon, 22 Oct 2012 08:56:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.19.38] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--32.732700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] FW: New Version Notification for draft-sriram-replay-protection-design-discussion-00.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 Oct 2012 08:56:42 -0000 Sriram, Let me re-comment on some of the points. (skip) >>=20 >> Particularly, I was surprised that in your assessment for the PKR method= you did not considered the points highlighted in section 4.2 of our draft = (Advantages/Disadvantages). >>=20 >=20 > In your Section 4.2, you have proposed what looks like a hybrid of PKR an= d EKR methods > (without using that specific taxonomy). We consider PKR and EKR as separa= te design choices,=20 > and hence discussed their pros/cons separately. But I think we have captu= red many of=20 > the same advantages/disadvantages you have outlined and some additional o= nes.=20 > We are open to taking in comments and revising the document as needed;=20 > so we will be happy to relook at that. (Roque) As expressed in our document, there are many reasons to do key roll= over for BGPSEC certificates, just like in any PKI. Using your taxonomy, ca= n we consider EKR as emergency rollovers due to a key been compromised, cha= nges on the certificate information or local policies?=20 In my mind, the only thing that we we need to care about is if we follow th= e periodic scheduled periodic rollover process or an emergency rollover. In= general the difference between the two is that in the emergency case there= may not be the time to wait for the RPKI process to propagate the informat= ion. > I have a question for you on your Section 4.2 regarding why you propose=20 > to implement a hybrid of PKR and EKR. Let me take that up in a separate t= hread. >=20 (Roque) ok, I will take a look at that other email. >>=20 >> 2) Your summary statement: "The Expire Time (ET) method is best" does no= t represent the WG consensus when our draft was accepted as WG item and whe= n the timestamp field was removed from the Protocol Specification.=20 >>=20 >=20 > We are fully mindful of the WG consensus and we are in no way promoting=20 > the ET method in the document. You took a piece of the whole statement=20 > and made it appear like that was the summary of our document.=20 > The actual statement (in Section 7) in the document is as follows: >=20 > "1. The Expire Time (ET) method is best (on par with the PKR method) > in terms of preventing huge update workloads during peering and > policy change events at transit routers with several peers. It > has no added RPKI churn. But the ET method has the disadvantage > of requiring on-the-wire protocol change if some parameters > (e.g., the units of beacon interval) change." >=20 > The intent here was just to equate the ET and PKR methods in terms of upd= ate workload.=20 > We would change the first sentence (when revised) to read:=20 > "The ET and PKR method are on par in terms of preventing huge update work= loads ......" =20 (Roque) Again, the problem that the WG was concerned about when studying th= e ET value (and that was not covered in your document) was not the changes = "on the wire" (although some discussion happened on who had control over th= e expiration time) but rather the changes on the BGP logic that has been ar= ound for decades. This point is not covered in your document. >=20 >>=20 >> IMHO, the problem with your comparison between ET and PKR is that you di= d not mentioned that implementing ET introduces important changes to curren= t BGP implementations. The design decision is to either maintain states in = every BGP speaker (having to allocate an expiration time to every update an= d needing to check if that time is old) vs increase the churn at the RPKI r= epository system and more admin processes in the RPKI. The group took the s= econd path. >>=20 >=20 > It depends on how you see it. How would you keep track of the NotValidAft= er time=20 > of update signatures (as determined by the NotValidAfter time of the resp= ective certs)=20 > in the PKR method? If keeping track of this is done in the router,=20 > then there is a need to maintain state even in the PKR method. OTOH,=20 > if the RPKI cache server is sending a withdraw of the public key=20 > when the cert's NotValidAfter time is reached, even then the BGP process = needs=20 > to scan the update tables and prune out the ones that are affected.=20 > I think that also implies changes to the current BGP implementations anyw= ay.=20 > However, we did observe that with the ET method we have the disadvantage= =20 > that the expire-time field is built into on-the-wire BGPSEC protocol=20 > and that is not a desirable feature. (Roque) The need for the router (if the certificate signing requests are or= iginated by the router) to keep track of the NotValidAfter time is ONLY for= its own certificates. We covered this in our draft, particularly when we e= xpress as an advantage that the AS that wants to protect itself against a r= eplay attacks pays most of the "Administrative cost" (Steve later corrected= us that Relying Parties also pay a tax which will be included in our next = release). Now, to keep track of the "NotValidAfter" time for the rest of th= e BGPSEC certificates you follow the traditional RPKI process: the caches f= etch the repositories, if a certificate is not longer valid, they send a wi= thdrawn to the routers for that SKI. The routers do not need to keep track = of it because the cache will do it. Moreover, we mention in the draft that the automatic process to make this t= o work (certificate provisioning, changes to the RTR protocol and how a rou= ter should react to a SKI withdrawn message) are not yet documented but we = worked under the assumption that it would be shortly. We understand that ot= her members of the SIDR WG are working on this piece and that is why we did= not cover it.=20 >>=20 >> 3) Your study of EKR is very bias because the effect of event-driven key= rollovers will depends on the event that is driving that key rollover. Par= ticularly, and putting it on the same words that our draft uses, in this pa= rticular case you are comparing a rollover of the "transit" certificate key= vs a rollover of the "origin" certificate key. >>=20 >=20 > I think you are referring to slides 6-8 in > http://www.nist.gov/itl/antd/upload/replay-discussion.pdf > No, we are not comparing apples and oranges here. In these comparisons (s= ee slide 8),=20 > we do not focus at all on the rollover of the "origin" certificate key.=20 (Roque) Ok, so you are focussing on the "transit" certificate rollover. Thi= s means that this is a different discussion and has nothing to do with the = re-play attack as the technique we are pushing forward to control the windo= ws of exposure are periodic rollovers of "origin" certificates keys. Is the= goal then to compare the router's behavior when dealing with periodic vs e= mergency rollovers? > That actually has a very minor impact on updates (as illustrated in slide= 5) and=20 > we don't focus on that in the plot in slide 8. Instead, what we consider = in slides 6-8 is that=20 > when the event occurs, in the PKR method no cert is rolled (by design).=20 (Roque) I do not understand your comment " in the PKR method no cert is rol= led (by design)". The transit certificate, as any PKI certificate, will nee= d to be rollover due to two possible reasons: periodically (it has a long v= alidity period but one day it will expire) and emergency (particularly key = compromised). Now, in each of these cases, you need to perform a rollover p= rocess and you want to "do before break" (sometimes in emergency process yo= u do not have this option and you break). > But even then a certain amount of BGPSEC updates would be propagated simi= lar to=20 > what happens in conventional BGP-4. That is because the router will recom= pute new best paths=20 > for the prefixes affected by the event, and those updates need to be prop= agated=20 > even though no key has been rolled due to the event.=20 > In some scenarios such as Scenario 1 in slide #6, no updates are generate= d in PKR=20 > under those circumstances. But in another scenario such as Scenario 2 in = slide #7,=20 > a moderate burst of updates is generated in PKR (same number as in BGP-4)= .=20 > However, in both scenarios, a huge burst of updates is generated in the E= KR method=20 > due to the transit key rollover which causes all prefix routes to be prop= agated=20 > or re-propagated at that router. I hope this explanation helps. (Roque) Sorry but I am still confused. In my view an emergency or a periodi= c key rollover will have the same effect on the BGPSEC layer with the diffe= rence that in the emergency case you may not have the chance to wait for th= e RPKI information to be propagated and thus you risk that the new BGP UPDA= TES do not validate.=20 >=20 >>=20 >> As you wrote in the document, when you rollover the transit certificate,= you gain the possibility to refresh transit policies which is not the case= with either ET or only rolling over the origin certificate key using PKR. = But rolling over the transit certificate key should be very rare because of= the reasons that you and us mention. >>=20 >=20 > I agree. >=20 > Thank you once again for reading and commenting on the document. >=20 > Regards, > Sriram From rogaglia@cisco.com Mon Oct 22 02:17:27 2012 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 B4F0621F89FD for ; Mon, 22 Oct 2012 02:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrMV88T8XVmr for ; Mon, 22 Oct 2012 02:17:27 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id DCD4521F89CE for ; Mon, 22 Oct 2012 02:17:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1673; q=dns/txt; s=iport; t=1350897447; x=1352107047; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CK5EaViEP1HQrfMaSuOn/68F1+CjMNSCimKpuxvuObc=; b=jSmNCmCauUsyQd8GtvBvgcUMJWva1TOrBi1AS11wF5gbJepM1bLh7p3Y +IPFeWzCnwIw5ytxwpeIVIIXQ4BSHXYdDiS6QEU9EVFQ8ZGXgMdJ+aaPm HdMi11WWsj6fxuwLDIjqskagllR5T+91dXrH6+qAAK/btPiGuC6FTsEAs c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAD8OhVCtJV2Z/2dsb2JhbABFwQuBCIIgAQEBAwESASc/BQsCAQgiFBAyJQIEDg0ah1wGm2qfIYtfFYV6YAOkP4Frgm+BWwgXHg X-IronPort-AV: E=Sophos;i="4.80,628,1344211200"; d="scan'208";a="134032949" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 22 Oct 2012 09:17:26 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9M9HQik023896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Oct 2012 09:17:26 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.176]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 04:17:26 -0500 From: "Roque Gagliano (rogaglia)" To: "Sriram, Kotikalapudi" Thread-Topic: Question on Section 4.2 of draft-ietf-sidr-bgpsec-rollover-00 Thread-Index: AQHNsDYM58+XD/2O7Ealm8Ml1avqNA== Date: Mon, 22 Oct 2012 09:17:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.19.38] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--34.204500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <8F04CB1EBF30FC46BF015E439D85B0B7@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] Question on Section 4.2 of draft-ietf-sidr-bgpsec-rollover-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 09:17:27 -0000 Hi Sriram, Thanks for the email. On Oct 21, 2012, at 9:40 PM, Sriram, Kotikalapudi wrote: > Roque, >=20 > I took another look at Section 4.2. > Can you please clarify if the method you describe in Sec. 4.2 is purely t= he PKR method,=20 > or if it has elements of both PKR and EKR in it? (Roque) The proposal in section 4.2 is to use periodic, scheduled key rollo= vers of the "origin" certificate to limit the windows of exposure to replay= attacks. This does not exempt the CA to rollover BGPSEC certificates/keys = for any other reason. > Do you roll the transit key when an event (peering discontinuation or pol= icy change)=20 > happens at a router having transit prefixes? > This is not clear from the wording in Section 4.2. (Roque) No. Section 4.2 introduces the idea of two certificates and rolling= over the "origin" certificate to limit the windows of exposure to replays = attacks. Of course if there are topology changes inside that windows, repla= y attacks would be possible. Section 3, is aimed to document a generic rollover process for both "origin= " and "transit". In the transit case, we did not studied yet what should tr= igger rollover processes. My personal opinion is that transit certificates = should have long lives and should not be, in general, be mandate to be roll= over to enforce topology/policies changes. The origin AS by rolling over it= s "origin" certificate would control the exposure windows for its own BGP U= PDATES. BTW, I am planning to send a new version today adding the comments from Ste= ve and you before WG adoption. Regards, Roque=20 >=20 > Thanks. > Sriram=20 From internet-drafts@ietf.org Mon Oct 22 06:04:40 2012 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 79AF521F8B32; Mon, 22 Oct 2012 06:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 5-c3O9NnZ7R7; Mon, 22 Oct 2012 06:04:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7074921F8A57; Mon, 22 Oct 2012 06:04:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022130438.4630.36839.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 06:04:38 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-rollover-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: Mon, 22 Oct 2012 13:04:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : BGPSEC router key rollover as an alternative to beaconing Author(s) : Roque Gagliano Keyur Patel Brian Weis Filename : draft-ietf-sidr-bgpsec-rollover-01.txt Pages : 14 Date : 2012-10-22 Abstract: BGPSEC will need to address the impact from regular and emergency rollover processes for the BGPSEC End-Entity (EE) certificates that will be performed by Certificate Authorities (CAs) participating at the Resource Public Key Infrastructure (RPKI). This document provides general recommendations for that process and specifies how this process is used to control BGPSEC's window of exposure to replay attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-rollover There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-rollover-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rogaglia@cisco.com Mon Oct 22 06:29:33 2012 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 8D05E21F8ACF for ; Mon, 22 Oct 2012 06:29:33 -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 BPS3mWEXMVCH for ; Mon, 22 Oct 2012 06:29:31 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBF321F8AA2 for ; Mon, 22 Oct 2012 06:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10170; q=dns/txt; s=iport; t=1350912571; x=1352122171; h=from:to:subject:date:message-id:references:mime-version; bh=ujnjSApx24DTU1xMVK0Z2lqDPOfRqQOO8JcwG7lHrAk=; b=mI7zZRgZ2VQp1sxXxCwTtpvx+7ALWaMHvDGOc6KLFl75QaB4877cg3Cu ffGaTgxIwQc6TgjaA8ZLrcYjGO/cLBWuS13tOFgHJ7blNqksJIIPBdRD5 l8oziIGNsEEbll8CpOF6P4Zb2EG3H0pOXhxRfomd8ZEG4dUyZFrJFzzFW E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0HAGRJhVCtJXG8/2dsb2JhbABFiHOmR4hyAYYkgj+BCIIgAQEBBBIBYQMSAgEZAwECCx0HMhQHAggCBBMIARmHYgubcJ9Ki18VBYV1YAOXCI03gWuCb4FbCBce X-IronPort-AV: E=Sophos;i="4.80,629,1344211200"; d="scan'208,217";a="131065347" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 22 Oct 2012 13:29:31 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9MDTVxR011919 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Oct 2012 13:29:31 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.176]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 08:29:30 -0500 From: "Roque Gagliano (rogaglia)" To: "sidr@ietf.org" Thread-Topic: New Version Notification for draft-ietf-sidr-bgpsec-rollover-01.txt Thread-Index: AQHNsFXPxRVnfdfpb0OFDCyBZEGoXw== Date: Mon, 22 Oct 2012 13:29:30 +0000 Message-ID: References: <20121022130439.4630.94227.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.19.38] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--53.848100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_EF4348D391D0334996EE9681630C83F0206CB5BBxmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: [sidr] Fwd: New Version Notification for draft-ietf-sidr-bgpsec-rollover-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: Mon, 22 Oct 2012 13:29:34 -0000 --_000_EF4348D391D0334996EE9681630C83F0206CB5BBxmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG, We created a new version of the BGPSEC key roll-over draft that basically i= ncorporate all corrections/comments from Steve (on: http://www.ietf.org/mai= l-archive/web/sidr/current/msg04770.html) and comments from Sriram here: ht= tp://www.ietf.org/mail-archive/web/sidr/current/msg05170.html and consideri= ng his views here: http://www.ietf.org/mail-archive/web/sidr/current/msg048= 63.html). Thank you both for the detail reviews. There are two "admin" changes that I want to do on a future version: - change the title:"BGPSEC router key rollover as an alternative to beaconi= ng" had the initial intend to propose an alternative to "beaconing" but the= current stage of the draft a title change is needed. An option could be:"B= GPSEC certificate key rollover and its effects to replay attacks protection= " - change document type to BCP. Just like RFC 6489 We do think the changes are significant enough at this time to request a sl= ot in Atlanta as they basically addressed editorial pieces. We believe that the draft at its current stage gives a generic overview on = the rollover process and its use to limit the windows of exposure to replay= attacks. Significant work on this document should be dependent on the adva= nce of the key provisioning specifications (there is still not WG document = yet on this point) and some initial experience. Regards, Roque Begin forwarded message: From: > Date: October 22, 2012 3:04:39 PM GMT+02:00 To: > Cc: >, > Subject: New Version Notification for draft-ietf-sidr-bgpsec-rollover-01.tx= t A new version of I-D, draft-ietf-sidr-bgpsec-rollover-01.txt has been successfully submitted by Roque Gagliano and posted to the IETF repository. Filename: draft-ietf-sidr-bgpsec-rollover Revision: 01 Title: BGPSEC router key rollover as an alternative to beaconing Creation date: 2012-10-22 WG ID: sidr Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec= -rollover-01.txt Status: http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-rol= lover Htmlized: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover= -01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-= rollover-01 Abstract: BGPSEC will need to address the impact from regular and emergency rollover processes for the BGPSEC End-Entity (EE) certificates that will be performed by Certificate Authorities (CAs) participating at the Resource Public Key Infrastructure (RPKI). This document provides general recommendations for that process and specifies how this process is used to control BGPSEC's window of exposure to replay attacks. The IETF Secretariat --_000_EF4348D391D0334996EE9681630C83F0206CB5BBxmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <1B7B2E6E42B90A4BB5C9767F83B6A9D5@cisco.com> Content-Transfer-Encoding: quoted-printable Dear WG,

We created a new version of the BGPSEC key roll-over draft that basica= lly incorporate all corrections/comments from Steve (on: http://www.i= etf.org/mail-archive/web/sidr/current/msg04770.html) and comments from Sriram here: http://www.ietf.org/mail-archive/web/sidr= /current/msg05170.html and considering his views here: http://www.ietf.org/mail-archive/web/sidr/current/msg04863.html). Than= k you both for the detail reviews.

There are two "admin" changes that I want to do on a future = version:
- c= hange the title:"BGPSEC router key rollover as an alternative to beaconing&q= uot; had the initial intend to propose an alternative to "beaconing" but the current stage of the draft a title change= is needed. An option could be:"BGPSEC certificate key rollover and it= s effects to replay attacks protection"
  - change document type to BCP. Just like RFC 6489

We do think the changes are significant enough at this time to request= a slot in Atlanta as they basically addressed editorial pieces. 

We believe that the draft at its current stage gives a generic overvie= w on the rollover process and its use to limit the windows of exposure to r= eplay attacks. Significant work on this document should be dependent on the= advance of the key provisioning specifications (there is still not WG document yet on this point) and some= initial experience.

Regards,
Roque


Begin forwarded message:

From: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=
Date: Octob= er 22, 2012 3:04:39 PM GMT+02:00
To: <<= a href=3D"mailto:rogaglia@cisco.com">rogaglia@cisco.com>
Cc: <<= a href=3D"mailto:keyupate@cisco.com">keyupate@cisco.com>, <bew@cisco.com>
Subject: Ne= w Version Notification for draft-ietf-sidr-bgpsec-rollover-01.txt


A new version of I-D, draft-ietf-sidr-bgpsec-rollover-01.txt
has been successfully submitted by Roque Gagliano and posted to the
IETF repository.

Filename: d= raft-ietf-sidr-bgpsec-rollover
Revision: 0= 1
Title: BGPSEC router k= ey rollover as an alternative to beaconing
Creation date: 2012-10-22
WG ID: sidr
Number of pages: 14
URL:            &nbs= p;http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-ro= llover-01.txt
Status:          http://datat= racker.ietf.org/doc/draft-ietf-sidr-bgpsec-rollover
Htmlized:        http://tools.ietf.org/ht= ml/draft-ietf-sidr-bgpsec-rollover-01
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-rollover-01

Abstract:
  BGPSEC will need to address the impact from regular and emergen= cy
  rollover processes for the BGPSEC End-Entity (EE) certificates = that
  will be performed by Certificate Authorities (CAs) participatin= g at
  the Resource Public Key Infrastructure (RPKI).  This docum= ent
  provides general recommendations for that process and specifies= how
  this process is used to control BGPSEC's window of exposure to = replay
  attacks.




The IETF Secretariat


--_000_EF4348D391D0334996EE9681630C83F0206CB5BBxmbrcdx01ciscoc_-- From internet-drafts@ietf.org Mon Oct 22 08:03:08 2012 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 2A83121F8C42; Mon, 22 Oct 2012 08:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0G-oWHra20D4; Mon, 22 Oct 2012 08:03:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5F721F8C41; Mon, 22 Oct 2012 08:03:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022150307.1824.50258.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 08:03:07 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-reqs-05.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 Oct 2012 15:03:08 -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 Group= of the IETF. Title : Security Requirements for BGP Path Validation Author(s) : Steven M. Bellovin Randy Bush David Ward Filename : draft-ietf-sidr-bgpsec-reqs-05.txt Pages : 8 Date : 2012-10-22 Abstract: This document describes requirements for a future BGP security protocol design to provide cryptographic assurance that the origin AS had the right to announce the prefix and to provide assurance of the AS Path of the announcement. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-reqs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-reqs-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-reqs-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From randy@psg.com Mon Oct 22 08:14:34 2012 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 97DC521F8C71 for ; Mon, 22 Oct 2012 08:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 9uzmG9aGkCDm for ; Mon, 22 Oct 2012 08:14:34 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 7429721F8C7A for ; Mon, 22 Oct 2012 08:14:33 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TQJi4-000Fyy-UG for sidr@ietf.org; Mon, 22 Oct 2012 15:14:33 +0000 Date: Mon, 22 Oct 2012 10:14:32 -0500 Message-ID: From: Randy Bush To: sidr wg list In-Reply-To: <20121022150307.1824.50258.idtracker@ietfa.amsl.com> References: <20121022150307.1824.50258.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-reqs-05.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 Oct 2012 15:14:34 -0000 just added as aliasing. if i missed something, whack me. six and a half hours to dreadline. randy From internet-drafts@ietf.org Mon Oct 22 16:31:33 2012 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 A161311E8107; Mon, 22 Oct 2012 16:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 VG5JuUGNoNpn; Mon, 22 Oct 2012 16:31:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E3711E8103; Mon, 22 Oct 2012 16:31:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022233132.18337.10520.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 16:31:32 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-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: Mon, 22 Oct 2012 23:31:33 -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 Group= of the IETF. Title : BGPSEC Protocol Specification Author(s) : Matthew Lepinski Filename : draft-ietf-sidr-bgpsec-protocol-06.txt Pages : 35 Date : 2012-10-22 Abstract: This document describes BGPSEC, an extension to the Border Gateway Protocol (BGP) that provides security for the path of autonomous systems through which a BGP update message passes. BGPSEC is implemented via a new optional non-transitive BGP path attribute that carries a digital signature produced by each autonomous system that propagates the update message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-protocol-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mlepinski.ietf@gmail.com Mon Oct 22 16:46:01 2012 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 83B5011E810A for ; Mon, 22 Oct 2012 16:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.436 X-Spam-Level: X-Spam-Status: No, score=-3.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0qHvmB-wvAH for ; Mon, 22 Oct 2012 16:46:00 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A708311E80FC for ; Mon, 22 Oct 2012 16:45:57 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so2967299iad.31 for ; Mon, 22 Oct 2012 16:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=wzsbRuHzas1GUamaNSOnuAypFcKE9kS9lEiXsysmZyg=; b=d3g8dRvV39BGeNM7dM7RhD4cnHSHefLohRT1l0/3f+1xIsq/Tj5rXqANgHEWIYpHSC Ap0mexWv7pVPR89Ht1kAJWX/2tPunyfpxOSBmXyE6lg67kulvc0hAFzoA7+hEfXnvB9E IJeNmh9PFFrLcpNhXUz9KH+x/XEq7bOKOSKlK3Zi6yVehHhhlh2R9IK2n5jNJXEUWIR7 UZAc4tg8QzIT8Ppf6ZbMi8P+JdJY7MdIlZ//xcXelYHCidaCp/JXorMX9oxjk4UPX6cL WeGSWsRB8LPSbvajHHUr6ICruEfo0wdeT5S3tr5NrdyUNCLcVU5/XScHG/lerirckU4p 4jFg== MIME-Version: 1.0 Received: by 10.50.57.169 with SMTP id j9mr18120046igq.16.1350949557202; Mon, 22 Oct 2012 16:45:57 -0700 (PDT) Received: by 10.231.76.82 with HTTP; Mon, 22 Oct 2012 16:45:57 -0700 (PDT) In-Reply-To: <20121022233132.18337.10520.idtracker@ietfa.amsl.com> References: <20121022233132.18337.10520.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 19:45:57 -0400 Message-ID: From: Matthew Lepinski To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-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: Mon, 22 Oct 2012 23:46:01 -0000 Greetings. I posted a new -06 version of the BGPSEC protocol specification. This includes all of the changes that we discussed at the interim meeting in Amsterdam last month. Note: I took out Additional_Info. It wasn't clear to me whether or not the working group wanted an extension mechanism to enable to originator to add additional signed data. However, it was clear at the interim that the -05 version of Additional_Info wasn't very useful, so I took it out. If the working group decides that we need a mechanism to fill the role of Additional_Info, I am happy to add one back in. As previously mentioned, I would be quite happy to see discussion of this topic on the list. Also, with regards to error handling, it wasn't clear after the interim what was the correct way forward with regards to error handling. I would love to get some Working Group Chair guidance on how best to proceed with error handling. (The -06 version does NOT have a Normative Reference to the IDR error handling draft, is one required?) Finally, I got a bunch of incredibly detailed reviews with lots of helpful fixes. I believe that I have incorporated almost all of the fixes suggested in those reviews. However, there's a good chance that I missed one or two given the volume of small changes that I was making. I plan to go through each of the recent reviews and double-check that I addressed all of the requested changes. If I find that I missed something, I will issue a small -07 update after Atlanta. In any case, I greatly appreciate the detailed reviews. I am pretty certain that I have incorporated all the major fixes, and I apologize if I missed a small fix that you suggested. On Mon, Oct 22, 2012 at 7:31 PM, 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 : BGPSEC Protocol Specification > Author(s) : Matthew Lepinski > Filename : draft-ietf-sidr-bgpsec-protocol-06.txt > Pages : 35 > Date : 2012-10-22 > > Abstract: > This document describes BGPSEC, an extension to the Border Gateway > Protocol (BGP) that provides security for the path of autonomous > systems through which a BGP update message passes. BGPSEC is > implemented via a new optional non-transitive BGP path attribute that > carries a digital signature produced by each autonomous system that > propagates the update message. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-protocol-06 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Tue Oct 23 08:14:30 2012 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 E193521F8686 for ; Tue, 23 Oct 2012 08:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 jkNA3nqyMa8P for ; Tue, 23 Oct 2012 08:14:30 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 7952621F8673 for ; Tue, 23 Oct 2012 08:14:30 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TQgBX-000KI7-QM for sidr@ietf.org; Tue, 23 Oct 2012 15:14:28 +0000 Date: Tue, 23 Oct 2012 10:14:27 -0500 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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Subject: [sidr] origin attribute 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, 23 Oct 2012 15:14:31 -0000 sandy asked so i investigated. bgp has an origin atttribute. it looks as if we need to protect it. the origin attribute may have three values, unspecified igp egp supposedly denoting from where the route was injected into bgp. jeff haas has a better memory than i, and noted that the key is that 'egp' does not mean an abstract egp, but the old egp protocol which was classful and aggregated. if it aggregated, you had to be careful that this did not suddenly hide things and ignorance thereof could open you up to loops. so the origin attribute was added. but it is in the bgp decision process. it is prettly low down, but could be used for traffic engineering or other, less nice, influencing of the decision process. hence, bgpsec should probably should protect it. randy From Sandra.Murphy@sparta.com Tue Oct 23 08:36:21 2012 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 8F69D11E80DC for ; Tue, 23 Oct 2012 08:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=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 mUcUERAxLU6y for ; Tue, 23 Oct 2012 08:36:20 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0F25411E80CC for ; Tue, 23 Oct 2012 08:36:15 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q9NFaB0O003219; Tue, 23 Oct 2012 10:36:11 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q9NFaAoT006057; Tue, 23 Oct 2012 10:36:10 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Tue, 23 Oct 2012 11:36:10 -0400 From: "Murphy, Sandra" To: "Roque Gagliano (rogaglia)" , "sidr@ietf.org" Thread-Topic: [sidr] Fwd: New Version Notification for draft-ietf-sidr-bgpsec-rollover-01.txt Thread-Index: AQHNsFXPxRVnfdfpb0OFDCyBZEGoX5fHBlUk Date: Tue, 23 Oct 2012 15:36:09 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F63699F6B2@Hermes.columbia.ads.sparta.com> References: <20121022130439.4630.94227.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: multipart/alternative; boundary="_000_24B20D14B2CD29478C8D5D6E9CBB29F63699F6B2Hermescolumbiaa_" MIME-Version: 1.0 Subject: Re: [sidr] Fwd: New Version Notification for draft-ietf-sidr-bgpsec-rollover-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: Tue, 23 Oct 2012 15:36:21 -0000 --_000_24B20D14B2CD29478C8D5D6E9CBB29F63699F6B2Hermescolumbiaa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On nday, October 22, 2012 9:29 AM, Roque said > Significant work on this document should be dependent on the advance of t= he key provisioning >specifications (there is still not WG document yet on this point) and some= initial experience. There is the draft draft-ietf-sidr-rtr-keying which says it is about provisioning routers w= ith the private keys they need. Do you mean something other than that? --Sandy, speaking as regular ol' wg member ________________________________ From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Roque Gagl= iano (rogaglia) [rogaglia@cisco.com] Sent: Monday, October 22, 2012 9:29 AM To: sidr@ietf.org Subject: [sidr] Fwd: New Version Notification for draft-ietf-sidr-bgpsec-ro= llover-01.txt Dear WG, We created a new version of the BGPSEC key roll-over draft that basically i= ncorporate all corrections/comments from Steve (on: http://www.ietf.org/mai= l-archive/web/sidr/current/msg04770.html) and comments from Sriram here: ht= tp://www.ietf.org/mail-archive/web/sidr/current/msg05170.html and consideri= ng his views here: http://www.ietf.org/mail-archive/web/sidr/current/msg048= 63.html). Thank you both for the detail reviews. There are two "admin" changes that I want to do on a future version: - change the title:"BGPSEC router key rollover as an alternative to beaconi= ng" had the initial intend to propose an alternative to "beaconing" but the= current stage of the draft a title change is needed. An option could be:"B= GPSEC certificate key rollover and its effects to replay attacks protection= " - change document type to BCP. Just like RFC 6489 We do think the changes are significant enough at this time to request a sl= ot in Atlanta as they basically addressed editorial pieces. We believe that the draft at its current stage gives a generic overview on = the rollover process and its use to limit the windows of exposure to replay= attacks. Significant work on this document should be dependent on the adva= nce of the key provisioning specifications (there is still not WG document = yet on this point) and some initial experience. Regards, Roque Begin forwarded message: From: > Date: October 22, 2012 3:04:39 PM GMT+02:00 To: > Cc: >, > Subject: New Version Notification for draft-ietf-sidr-bgpsec-rollover-01.tx= t A new version of I-D, draft-ietf-sidr-bgpsec-rollover-01.txt has been successfully submitted by Roque Gagliano and posted to the IETF repository. Filename: draft-ietf-sidr-bgpsec-rollover Revision: 01 Title: BGPSEC router key rollover as an alternative to beaconing Creation date: 2012-10-22 WG ID: sidr Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec= -rollover-01.txt Status: http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-rol= lover Htmlized: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover= -01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-= rollover-01 Abstract: BGPSEC will need to address the impact from regular and emergency rollover processes for the BGPSEC End-Entity (EE) certificates that will be performed by Certificate Authorities (CAs) participating at the Resource Public Key Infrastructure (RPKI). This document provides general recommendations for that process and specifies how this process is used to control BGPSEC's window of exposure to replay attacks. The IETF Secretariat --_000_24B20D14B2CD29478C8D5D6E9CBB29F63699F6B2Hermescolumbiaa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
On nday,= October 22, 2012 9:29 AM, Roque said



>=  Significant work on this document should be dependent on the advance = of the key provisioning
>= specifications (there is still not WG document yet on this point) and some = initial experience.

There is the draft draft-ietf-sidr-rtr-keying whic= h says it is about provisioning routers with the private keys they need. &nb= sp;Do you mean something other than that?

--Sandy, speaking as regular ol' wg member

From: sidr-bounces@ietf.org [sidr-bounce= s@ietf.org] on behalf of Roque Gagliano (rogaglia) [rogaglia@cisco.com]
Sent: Monday, October 22, 2012 9:29 AM
To: sidr@ietf.org
Subject: [sidr] Fwd: New Version Notification for draft-ietf-sidr-bg= psec-rollover-01.txt

Dear WG,

We created a new version of the BGPSEC key roll-over draft that basica= lly incorporate all corrections/comments from Steve (on: http://www.ietf.org/mail-archive/web/sidr/current/msg04770.html)&= nbsp;and comments from Sriram here: http://www.ietf.org/mai= l-archive/web/sidr/current/msg05170.html and considering his views here= : http://www.ietf.org/mail-archive/web/sidr/current/msg04863.html). Thank= you both for the detail reviews.

There are two "admin" changes that I want to do on a future = version:
- chan= ge the title:"BGPSEC router key rollover as an alternative to beaconing"= ; had the initial intend to propose an alternative to "beaconing" but the current stage of the draft a title change= is needed. An option could be:"BGPSEC certificate key rollover and it= s effects to replay attacks protection"
  - change document type to BCP. Just like RFC 6489

We do think the changes are significant enough at this time to request= a slot in Atlanta as they basically addressed editorial pieces. 

We believe that the draft at its current stage gives a generic overvie= w on the rollover process and its use to limit the windows of exposure to r= eplay attacks. Significant work on this document should be dependent on the= advance of the key provisioning specifications (there is still not WG document yet on this point) and some= initial experience.

Regards,
Roque


Begin forwarded message:

Date: October 22, 20= 12 3:04:39 PM GMT+02:00
Subject: <= /span>New Vers= ion Notification for draft-ietf-sidr-bgpsec-rollover-01.txt


A new version of I-D, draft-ietf-sidr-bgpsec-rollover-01.txt
has been successfully submitted by Roque Gagliano and posted to the
IETF repository.

Filename: d= raft-ietf-sidr-bgpsec-rollover
Revision: 0= 1
Title: BGPSEC router k= ey rollover as an alternative to beaconing
Creation date: 2012-10-22
WG ID: sidr
Number of pages: 14
URL:            &nbs= p;http://www.ietf.org/internet-drafts/draft-i= etf-sidr-bgpsec-rollover-01.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-rollover Htmlized:        http:/= /tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-01
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bg= psec-rollover-01

Abstract:
  BGPSEC will need to address the impact from regular and emergen= cy
  rollover processes for the BGPSEC End-Entity (EE) certificates = that
  will be performed by Certificate Authorities (CAs) participatin= g at
  the Resource Public Key Infrastructure (RPKI).  This docum= ent
  provides general recommendations for that process and specifies= how
  this process is used to control BGPSEC's window of exposure to = replay
  attacks.




The IETF Secretariat


--_000_24B20D14B2CD29478C8D5D6E9CBB29F63699F6B2Hermescolumbiaa_-- From hannes@juniper.net Tue Oct 23 08:39:49 2012 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 AD89221F85EE for ; Tue, 23 Oct 2012 08:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 ucvnf2qHGocc for ; Tue, 23 Oct 2012 08:39:49 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id C268621F85B4 for ; Tue, 23 Oct 2012 08:39:48 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUIa6RMKU8gBmkI9dUAqvfHpYZ+gDX5q3@postini.com; Tue, 23 Oct 2012 08:39:48 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 23 Oct 2012 08:37:03 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 23 Oct 2012 08:37:02 -0700 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.13) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 23 Oct 2012 08:43:16 -0700 Received: from mail134-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Tue, 23 Oct 2012 15:37:01 +0000 Received: from mail134-va3 (localhost [127.0.0.1]) by mail134-va3-R.bigfish.com (Postfix) with ESMTP id 604B41A021E for ; Tue, 23 Oct 2012 15:37:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -23 X-BigFish: PS-23(zz98dI9371I1432Izz1202h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h944hd25he5bhf0ah107ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1155h) Received: from mail134-va3 (localhost.localdomain [127.0.0.1]) by mail134-va3 (MessageSwitch) id 1351006618382729_11093; Tue, 23 Oct 2012 15:36:58 +0000 (UTC) Received: from VA3EHSMHS019.bigfish.com (unknown [10.7.14.239]) by mail134-va3.bigfish.com (Postfix) with ESMTP id 5908AC0210; Tue, 23 Oct 2012 15:36:58 +0000 (UTC) Received: from SN2PRD0510HT001.namprd05.prod.outlook.com (157.56.234.117) by VA3EHSMHS019.bigfish.com (10.7.99.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 23 Oct 2012 15:36:57 +0000 Received: from hannes-sslvpn-nc.jnpr.net (66.129.224.51) by pod51010.outlook.com (10.255.116.36) with Microsoft SMTP Server (TLS) id 14.16.224.5; Tue, 23 Oct 2012 15:36:56 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Hannes Gredler In-Reply-To: Date: Tue, 23 Oct 2012 17:36:50 +0200 Content-Transfer-Encoding: 7bit Message-ID: <4B14E6F9-195C-4C1F-97E8-69ECE0F08041@juniper.net> References: To: Randy Bush X-Mailer: Apple Mail (2.1283) X-Originating-IP: [66.129.224.51] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%PSG.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: sidr wg list Subject: Re: [sidr] origin attribute 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, 23 Oct 2012 15:39:49 -0000 randy, do we really want to go down that road: i mean do we want to protect all the attributes which ever could affect BGPs path decision process ? /hannes On Oct 23, 2012, at 5:14 PM, Randy Bush wrote: > sandy asked so i investigated. > > bgp has an origin atttribute. it looks as if we need to protect it. > > the origin attribute may have three values, > unspecified > igp > egp > supposedly denoting from where the route was injected into bgp. > > jeff haas has a better memory than i, and noted that > > the key is that 'egp' does not mean an abstract egp, but the old egp > protocol which was classful and aggregated. > > if it aggregated, you had to be careful that this did not suddenly hide > things and ignorance thereof could open you up to loops. so the origin > attribute was added. > > but it is in the bgp decision process. it is prettly low down, but > could be used for traffic engineering or other, less nice, influencing > of the decision process. > > hence, bgpsec should probably should protect it. > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From rogaglia@cisco.com Tue Oct 23 08:47:13 2012 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 8A67721F86C3 for ; Tue, 23 Oct 2012 08:47:13 -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 l67vCnbF4HOC for ; Tue, 23 Oct 2012 08:47:12 -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 2664721F86C1 for ; Tue, 23 Oct 2012 08:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16416; q=dns/txt; s=iport; t=1351007226; x=1352216826; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3wzwsF+8MEQrkhmP9sQk0w+dzsY8LS+1LIpZBA4gAcQ=; b=FMQP42O55saum56nFCgFB+kJFzQmgzUbSUQy1GztnLDDqLd8bH6dwozb NlDr83XOiedpOn5tpau06Hd5f0s4opjeHuhvfcoc63zATLm/MJ3l4/+Pn WmExkniYtQNgu7eN8/I0CuWKB7mH6CClvzZeYm/xveLtpwfKtg+zlp1O6 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMGAH26hlCtJXG8/2dsb2JhbABEgkqtPohzAYYkgkaBCIIeAQEBAwESAWEDAgULAgEIEQMBAQELHQcyFAkIAgQOBQgBGYdcBgubco9ckDyLXxUFhWRgA5cIjTeBa4JvgVsIFx4 X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208,217";a="134515768" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 23 Oct 2012 15:47:05 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9NFl5EM011204 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 15:47:05 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.176]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 10:47:05 -0500 From: "Roque Gagliano (rogaglia)" To: "Murphy, Sandra" Thread-Topic: [sidr] Fwd: New Version Notification for draft-ietf-sidr-bgpsec-rollover-01.txt Thread-Index: AQHNsFXPxRVnfdfpb0OFDCyBZEGoXw== Date: Tue, 23 Oct 2012 15:47:04 +0000 Message-ID: References: <20121022130439.4630.94227.idtracker@ietfa.amsl.com>, <24B20D14B2CD29478C8D5D6E9CBB29F63699F6B2@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F63699F6B2@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.89.117] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--55.523000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_EF4348D391D0334996EE9681630C83F0206CCE61xmbrcdx01ciscoc_" MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] Fwd: New Version Notification for draft-ietf-sidr-bgpsec-rollover-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: Tue, 23 Oct 2012 15:47:13 -0000 --_000_EF4348D391D0334996EE9681630C83F0206CCE61xmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sandy, On Oct 23, 2012, at 5:36 PM, Murphy, Sandra wrote: On nday, October 22, 2012 9:29 AM, Roque said > Significant work on this document should be dependent on the advance of t= he key provisioning >specifications (there is still not WG document yet on this point) and some= initial experience. There is the draft draft-ietf-sidr-rtr-keying which says it is about provisioning routers w= ith the private keys they need. Do you mean something other than that? That draft mentions formats for the keys/certificates in two scenarios but = not which enrollment protocol would be use. One option mentioned in our dra= ft is to adopt EST (http://tools.ietf.org/html/draft-ietf-pkix-est-03) as a= n option that already has running code. Another activity that the key rollo= ver draft depends on is the RTR protocol extensions. Regards, Roque --Sandy, speaking as regular ol' wg member ________________________________ From: sidr-bounces@ietf.org [sidr-bounces@iet= f.org] on behalf of Roque Gagliano (rogaglia) [rogaglia@cisco.com] Sent: Monday, October 22, 2012 9:29 AM To: sidr@ietf.org Subject: [sidr] Fwd: New Version Notification for draft-ietf-sidr-bgpsec-ro= llover-01.txt Dear WG, We created a new version of the BGPSEC key roll-over draft that basically i= ncorporate all corrections/comments from Steve (on: http://www.ietf.org/mai= l-archive/web/sidr/current/msg04770.html) and comments from Sriram here: ht= tp://www.ietf.org/mail-archive/web/sidr/current/msg05170.html and consideri= ng his views here:http://www.ietf.org/mail-archive/web/sidr/current/msg0486= 3.html). Thank you both for the detail reviews. There are two "admin" changes that I want to do on a future version: - change the title:"BGPSEC router key rollover as an alternative to beaconi= ng" had the initial intend to propose an alternative to "beaconing" but the= current stage of the draft a title change is needed. An option could be:"B= GPSEC certificate key rollover and its effects to replay attacks protection= " - change document type to BCP. Just like RFC 6489 We do think the changes are significant enough at this time to request a sl= ot in Atlanta as they basically addressed editorial pieces. We believe that the draft at its current stage gives a generic overview on = the rollover process and its use to limit the windows of exposure to replay= attacks. Significant work on this document should be dependent on the adva= nce of the key provisioning specifications (there is still not WG document = yet on this point) and some initial experience. Regards, Roque Begin forwarded message: From: > Date: October 22, 2012 3:04:39 PM GMT+02:00 To: > Cc: >, > Subject: New Version Notification for draft-ietf-sidr-bgpsec-rollover-01.tx= t A new version of I-D, draft-ietf-sidr-bgpsec-rollover-01.txt has been successfully submitted by Roque Gagliano and posted to the IETF repository. Filename: draft-ietf-sidr-bgpsec-rollover Revision: 01 Title: BGPSEC router key rollover as an alternative to beaconing Creation date: 2012-10-22 WG ID: sidr Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec= -rollover-01.txt Status: http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-rol= lover Htmlized: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover= -01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-= rollover-01 Abstract: BGPSEC will need to address the impact from regular and emergency rollover processes for the BGPSEC End-Entity (EE) certificates that will be performed by Certificate Authorities (CAs) participating at the Resource Public Key Infrastructure (RPKI). This document provides general recommendations for that process and specifies how this process is used to control BGPSEC's window of exposure to replay attacks. The IETF Secretariat --_000_EF4348D391D0334996EE9681630C83F0206CCE61xmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <4B3AF1557AC0FD4290DC0C77747FB1AE@cisco.com> Content-Transfer-Encoding: quoted-printable Hi Sandy,


On Oct 23, 2012, at 5:36 PM, Murphy, Sandra wrote:

On nday, Octob= er 22, 2012 9:29 AM, Roque said



>=  Significant work on this document should be dependent on the advance = of the key provisioning
>= specifications (there is still not WG document yet on this point) and some = initial experience.

There is the draft draft-ietf-sidr-rtr-keying whic= h says it is about provisioning routers with the private keys they need. &nb= sp;Do you mean something other than that?


That draft mentions formats for the keys/certificates in two scenarios= but not which enrollment protocol would be use. One option mentioned in ou= r draft is to adopt EST (http://tools.ietf.org/html/draft-ietf-pkix-est-03) as an option that already has running code. Another activity that the key = rollover draft depends on is the RTR protocol extensions.

Regards,
Roque


--Sandy, speaking as regular ol' wg member

From: sidr-bounces@ietf.= org [sidr-bounces@iet= f.org] on behalf of Roque Gagliano (rogaglia) [rogaglia@cisco.com]
Sent: Monday, Octo= ber 22, 2012 9:29 AM
To: sidr@ietf.org
Subject: [sidr] Fw= d: New Version Notification for draft-ietf-sidr-bgpsec-rollover-01.txt

Dear WG,

We created a new version of the BGPSEC key roll-over draft that basica= lly incorporate all corrections/comments from Steve (on: http://www.ietf.org/mail-archive/web/sidr/current/msg04770.html)&= nbsp;and comments from Sriram here: http://www.ietf.org/mai= l-archive/web/sidr/current/msg05170.html and considering his views here:http:= //www.ietf.org/mail-archive/web/sidr/current/msg04863.html). Thank you both for the detail reviews.

There are two "admin" changes that I want to do on a future = version:
- c= hange the title:"BGPSEC router key rollover as an alternative to beaconing&q= uot; had the initial intend to propose an alternative to "beaconing" but the current stage of the draft a title change= is needed. An option could be:"BGPSEC certificate key rollover and it= s effects to replay attacks protection"
  - change document type to BCP. Just like RFC 6489

We do think the changes are significant enough at this time to request= a slot in Atlanta as they basically addressed editorial pieces. 

We believe that the draft at its current stage gives a generic overvie= w on the rollover process and its use to limit the windows of exposure to r= eplay attacks. Significant work on this document should be dependent on the= advance of the key provisioning specifications (there is still not WG document yet on this point) and some= initial experience.

Regards,
Roque


Begin forwarded message:

Date: October 22, 2012 3:04:39 PM GMT+= ;02:00
Subject: New Version Notification for = draft-ietf-sidr-bgpsec-rollover-01.txt


A new version of I-D, draft-ietf-sidr-bgpsec-rollover-01.txt
has been successfully submitted by Roque Gagliano and posted to the
IETF repository.

Filename: draft-ietf-sidr-bgpsec-rollover
Revision: 01
Title: <= span class=3D"Apple-tab-span" style=3D"white-space: pre; ">BGPSEC ro= uter key rollover as an alternative to beaconing
Creation date: = 2012-10-22
WG ID: <= span class=3D"Apple-tab-span" style=3D"white-space: pre; ">sidr
Number of pages: 14
URL:            &nbs= p;http://www.ietf.org/internet-drafts/draft-i= etf-sidr-bgpsec-rollover-01.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-rollover Htmlized:        http:/= /tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-01
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bg= psec-rollover-01

Abstract:
  BGPSEC will need to address the impact from regular and emergen= cy
  rollover processes for the BGPSEC End-Entity (EE) certificates = that
  will be performed by Certificate Authorities (CAs) participatin= g at
  the Resource Public Key Infrastructure (RPKI).  This docum= ent
  provides general recommendations for that process and specifies= how
  this process is used to control BGPSEC's window of exposure to = replay
  attacks.




The IETF Secretariat




--_000_EF4348D391D0334996EE9681630C83F0206CCE61xmbrcdx01ciscoc_-- From jakob.heitz@ericsson.com Tue Oct 23 09:14:02 2012 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 69AA121F8200 for ; Tue, 23 Oct 2012 09:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwjvNhRm+vn7 for ; Tue, 23 Oct 2012 09:14:01 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id ABCC611E8192 for ; Tue, 23 Oct 2012 09:14:01 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q9NGGqpr004510; Tue, 23 Oct 2012 11:16:53 -0500 Received: from EUSAAHC007.ericsson.se (147.117.188.93) by eusaamw0712.eamcs.ericsson.se (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 23 Oct 2012 12:13:58 -0400 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 12:13:58 -0400 From: Jakob Heitz To: Hannes Gredler Thread-Topic: [sidr] origin attribute Thread-Index: AQHNsTElXvo55W2JKkeR5AB07V2NxZfHSRsA///HUuU= Date: Tue, 23 Oct 2012 16:13:57 +0000 Message-ID: References: , <4B14E6F9-195C-4C1F-97E8-69ECE0F08041@juniper.net> In-Reply-To: <4B14E6F9-195C-4C1F-97E8-69ECE0F08041@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] origin attribute 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, 23 Oct 2012 16:14:02 -0000 The issue is: once it's signed, it can't be removed. (you could always add = another one, but that would change BGP significantly). "origin" does not seem to be an attribute subject to change. -- Jakob Heitz. On Oct 23, 2012, at 8:40 AM, "Hannes Gredler" wrote: > randy, >=20 > do we really want to go down that road: > i mean do we want to protect all the attributes which ever could > affect BGPs path decision process ? >=20 > /hannes >=20 > On Oct 23, 2012, at 5:14 PM, Randy Bush wrote: >=20 >> sandy asked so i investigated. >>=20 >> bgp has an origin atttribute. it looks as if we need to protect it. >>=20 >> the origin attribute may have three values,=20 >> unspecified >> igp >> egp >> supposedly denoting from where the route was injected into bgp. >>=20 >> jeff haas has a better memory than i, and noted that >>=20 >> the key is that 'egp' does not mean an abstract egp, but the old egp >> protocol which was classful and aggregated. >>=20 >> if it aggregated, you had to be careful that this did not suddenly hide >> things and ignorance thereof could open you up to loops. so the origin >> attribute was added. >>=20 >> but it is in the bgp decision process. it is prettly low down, but >> could be used for traffic engineering or other, less nice, influencing >> of the decision process. >>=20 >> hence, bgpsec should probably should protect it. >>=20 >> randy >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From danny@tcb.net Tue Oct 23 13:05:12 2012 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 CBAC321F862E for ; Tue, 23 Oct 2012 13:05:12 -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 guOluoXXCscM for ; Tue, 23 Oct 2012 13:05:12 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 3676611E80FC for ; Tue, 23 Oct 2012 13:05:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 687C31C55 for ; Tue, 23 Oct 2012 14:05:11 -0600 (MDT) Received: from [192.168.5.209] (ip-64-134-29-132.public.wayport.net [64.134.29.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id E341D1C54 for ; Tue, 23 Oct 2012 14:05:06 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Danny McPherson In-Reply-To: Date: Tue, 23 Oct 2012 16:05:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3C26AA66-B1B1-4DF7-BA78-440E578E289C@tcb.net> References: To: sidr wg list X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Oct 23 14:05:11 2012 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 5086f877102381777994535 X-DSPAM-Factors: 27, To*sidr+wg, 0.40000, been+#+#+here, 0.40000, 1+#+to, 0.40000, down+#+could, 0.40000, could+#+used, 0.40000, the+#+decision, 0.40000, should+protect, 0.40000, g+#+#+#+see, 0.40000, traffic+engineering, 0.40000, way+into, 0.40000, it+#+#+#+hoping, 0.40000, is+#+#+down, 0.40000, at+#+14, 0.40000, 11+#+#+#+Bush, 0.40000, also+#+#+#+has, 0.40000, e+#+#+glad, 0.40000, for+traffic, 0.40000, also+note, 0.40000, been+#+#+#+many, 0.40000, the+decision, 0.40000, but+#+#+in, 0.40000, protect+#+#+I, 0.40000, protect+#+Agreed, 0.40000, hoping+it, 0.40000, traffic+#+#+#+less, 0.40000, see+folks, 0.40000, the+#+#+s, 0.40000 Subject: Re: [sidr] origin attribute 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, 23 Oct 2012 20:05:12 -0000 On Oct 23, 2012, at 11:14 AM, Randy Bush wrote: >=20 > but it is in the bgp decision process. it is prettly low down, but > could be used for traffic engineering or other, less nice, influencing > of the decision process. s/could be/is/ > hence, bgpsec should probably should protect it. Agreed. =20 I would also note that this has been brought up here many times (e.g., = [1]), glad to see folks giving it consideration now, and hoping it can = find it's way into a future threats document. -danny [1] http://www.ietf.org/mail-archive/web/sidr/current/msg03464.html= From warren@kumari.net Tue Oct 23 13:44:25 2012 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 BB4DE11E80F2 for ; Tue, 23 Oct 2012 13:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.173 X-Spam-Level: X-Spam-Status: No, score=-102.173 tagged_above=-999 required=5 tests=[AWL=0.426, 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 ENFbpkfjOXXB for ; Tue, 23 Oct 2012 13:44:25 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CBD11E80F0 for ; Tue, 23 Oct 2012 13:44:24 -0700 (PDT) Received: from [192.168.1.142] (unknown [66.84.81.102]) by vimes.kumari.net (Postfix) with ESMTPSA id A8CBC1B40462; Tue, 23 Oct 2012 16:44:23 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: Date: Tue, 23 Oct 2012 16:44:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <737761C0-53E6-4C7C-B423-9E265A915BD6@kumari.net> References: To: Randy Bush X-Mailer: Apple Mail (2.1499) Cc: sidr wg list Subject: Re: [sidr] origin attribute 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, 23 Oct 2012 20:44:25 -0000 On Oct 23, 2012, at 11:14 AM, Randy Bush wrote: > sandy asked so i investigated. >=20 > bgp has an origin atttribute. it looks as if we need to protect it. >=20 > the origin attribute may have three values,=20 > unspecified > igp > egp > supposedly denoting from where the route was injected into bgp. >=20 > jeff haas has a better memory than i, and noted that >=20 > the key is that 'egp' does not mean an abstract egp, but the old egp > protocol which was classful and aggregated. >=20 > if it aggregated, you had to be careful that this did not suddenly = hide > things and ignorance thereof could open you up to loops. so the = origin > attribute was added. >=20 > but it is in the bgp decision process. it is prettly low down, but > could be used for traffic engineering or other, less nice, influencing > of the decision process. Yes. And it *is* used for TE purposes in simple places... >=20 > hence, bgpsec should probably should protect it. Not sure I agree with this part -- simply because it can be used in the = decision process doesn't automatically mean it needs to be protected. It = (and med and IGP cost and routerID) "feel" to me like they are low = enough down that they can be (and should be) left alone, to allow = operators some flexibility (Yes, Origin is set by the originator, the = rest of these things are more about the local network, but I still don't = think that this automatically means that it needs to be protected). By allowing folk to turn (ok, stomp all over :-)) the setting of Origin = those folk that have networks with more than one AS can influence their = inbound, folk who want the ability to chance things further down in the = decision process still have that, etc=85 W >=20 > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 -- She'd even given herself a middle initial - X - which stood for "someone = who has a cool and exciting middle name". -- (Terry Pratchett, Maskerade) From randy@psg.com Tue Oct 23 14:00:44 2012 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 08A601F0C92 for ; Tue, 23 Oct 2012 14:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 uZAvhkVjGrig for ; Tue, 23 Oct 2012 14:00:43 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id A616E1F0424 for ; Tue, 23 Oct 2012 14:00:43 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TQlac-000Len-GA; Tue, 23 Oct 2012 21:00:42 +0000 Date: Tue, 23 Oct 2012 16:00:42 -0500 Message-ID: From: Randy Bush To: Warren Kumari In-Reply-To: <737761C0-53E6-4C7C-B423-9E265A915BD6@kumari.net> References: <737761C0-53E6-4C7C-B423-9E265A915BD6@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.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] origin attribute 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, 23 Oct 2012 21:00:44 -0000 >> hence, bgpsec should probably should protect it. i should admit to trolling > By allowing folk to turn (ok, stomp all over :-)) the setting of > Origin those folk that have networks with more than one AS can > influence their inbound, folk who want the ability to chance things > further down in the decision process still have that, etc=E2=80=A6 ty for tech arg. makes sense. well, it's kinda how far down a slippery slope we wanna go. i actually have no strong opinion, so just trolling. randy From Sandra.Murphy@sparta.com Tue Oct 23 14:04:42 2012 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 02C0C1F0C91 for ; Tue, 23 Oct 2012 14:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 9Wdr1AIRQ8-n for ; Tue, 23 Oct 2012 14:04:41 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 700131F0424 for ; Tue, 23 Oct 2012 14:04:41 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q9NL4egp007133; Tue, 23 Oct 2012 16:04:40 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q9NL4ZvW016799; Tue, 23 Oct 2012 16:04:40 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Tue, 23 Oct 2012 17:04:34 -0400 From: "Murphy, Sandra" To: Danny McPherson , sidr wg list Thread-Topic: [sidr] origin attribute Thread-Index: AQHNsTEnpmJWHbn2Pkis9TqWcNVEe5fHlCAA///B1XQ= Date: Tue, 23 Oct 2012 21:04:33 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6369A07AB@Hermes.columbia.ads.sparta.com> References: , <3C26AA66-B1B1-4DF7-BA78-440E578E289C@tcb.net> In-Reply-To: <3C26AA66-B1B1-4DF7-BA78-440E578E289C@tcb.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] origin attribute 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, 23 Oct 2012 21:04:42 -0000 >I would also note that this has been brought up here=0A= =0A= Reviewing that was what led to my question to Randy. (something like "what= is the reason for having ORIGIN in the first place".)=0A= =0A= The responses when this came up in the past have been that protecting integ= rity of ORIGIN might be conceivable, but the authenticity of the value was = not. That is, who says that the AS did indeed get the info from EGP. Soun= ds like at one time, that mattered.=0A= =0A= To consider this a threat, we would need to decide what attacks are of inte= rest. Is corruption the only concern? Is spoofing a value (mis-ORIGIN-ing= ) a concern? If authenticity of the value is a concern, who could be an au= thority to attest to the authenticity? And so forth.=0A= =0A= =0A= --Sandy, speaking as regular ol' member=0A= =0A= =0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Danny McPh= erson [danny@tcb.net]=0A= Sent: Tuesday, October 23, 2012 4:05 PM=0A= To: sidr wg list=0A= Subject: Re: [sidr] origin attribute=0A= =0A= On Oct 23, 2012, at 11:14 AM, Randy Bush wrote:=0A= >=0A= > but it is in the bgp decision process. it is prettly low down, but=0A= > could be used for traffic engineering or other, less nice, influencing=0A= > of the decision process.=0A= =0A= s/could be/is/=0A= =0A= > hence, bgpsec should probably should protect it.=0A= =0A= =0A= Agreed.=0A= =0A= I would also note that this has been brought up here many times (e.g., [1])= , glad to see folks giving it consideration now, and hoping it can find it'= s way into a future threats document.=0A= =0A= -danny=0A= =0A= [1] http://www.ietf.org/mail-archive/web/sidr/current/msg03464.html=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From jgs@juniper.net Tue Oct 23 14:06:56 2012 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 8FE491F0C9A for ; Tue, 23 Oct 2012 14:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.72 X-Spam-Level: X-Spam-Status: No, score=-3.72 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 3765cbwiVKrh for ; Tue, 23 Oct 2012 14:06:55 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 9D22B1F0424 for ; Tue, 23 Oct 2012 14:06:50 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUIcG6Lk97ljcTRMD53SDZkjkLhNMN4Ez@postini.com; Tue, 23 Oct 2012 14:06:50 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 23 Oct 2012 14:05:49 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 23 Oct 2012 14:05:49 -0700 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.31) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 23 Oct 2012 14:11:56 -0700 Received: from mail56-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE014.bigfish.com (10.7.40.64) with Microsoft SMTP Server id 14.1.225.23; Tue, 23 Oct 2012 21:05:42 +0000 Received: from mail56-va3 (localhost [127.0.0.1]) by mail56-va3-R.bigfish.com (Postfix) with ESMTP id 1D0AE2A013E for ; Tue, 23 Oct 2012 21:05:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 0 X-BigFish: PS0(zz98dI9371Ic430Izz1202h1d1ah1d2ah1082kzz8275bhz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h1155h) Received: from mail56-va3 (localhost.localdomain [127.0.0.1]) by mail56-va3 (MessageSwitch) id 1351026340103342_25905; Tue, 23 Oct 2012 21:05:40 +0000 (UTC) Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.242]) by mail56-va3.bigfish.com (Postfix) with ESMTP id 0B4C31A003F; Tue, 23 Oct 2012 21:05:40 +0000 (UTC) Received: from CH1PRD0510HT001.namprd05.prod.outlook.com (157.56.244.213) by VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 23 Oct 2012 21:05:37 +0000 Received: from ntatavossian-sslvpn-nc.jnpr.net (66.129.224.54) by pod51010.outlook.com (10.255.150.36) with Microsoft SMTP Server (TLS) id 14.16.224.5; Tue, 23 Oct 2012 21:05:37 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: "John G. Scudder" In-Reply-To: Date: Tue, 23 Oct 2012 17:05:33 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <4EC7E1D2-1385-4BFC-89C6-CCF98B27D734@juniper.net> References: , <4B14E6F9-195C-4C1F-97E8-69ECE0F08041@juniper.net> To: Jakob Heitz X-Mailer: Apple Mail (2.1498) X-Originating-IP: [66.129.224.54] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: sidr wg list Subject: Re: [sidr] origin attribute 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, 23 Oct 2012 21:06:56 -0000 On Oct 23, 2012, at 12:13 PM, Jakob Heitz = wrote: > "origin" does not seem to be an attribute subject to change. In theory you're right, if the attribute were being used as originally = envisioned. In practice, as Warren points out, you're not because it's = not. People do set Origin once the route is in flight, as a handy = low-order policy thing they can fiddle with.=20 BGPSec protecting Origin would stomp on current operational practice, so = it would need to be justified more strongly than "seemed like a good = idea at the time". --John= From danny@tcb.net Tue Oct 23 14:20:49 2012 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 88BF921F85E8 for ; Tue, 23 Oct 2012 14:20:49 -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 E8d2BEDqwUEc for ; Tue, 23 Oct 2012 14:20:49 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFAE21F85E2 for ; Tue, 23 Oct 2012 14:20:47 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 8D56C1C6E for ; Tue, 23 Oct 2012 21:20:46 +0000 (UTC) Received: from [192.168.5.209] (ip-64-134-29-132.public.wayport.net [64.134.29.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 3B6CE1C6C; Tue, 23 Oct 2012 15:20:46 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6369A07AB@Hermes.columbia.ads.sparta.com> Date: Tue, 23 Oct 2012 17:21:05 -0400 Content-Transfer-Encoding: 8bit Message-Id: <0D9E8632-BA11-4B5D-A656-4BE1C5802702@tcb.net> References: , <3C26AA66-B1B1-4DF7-BA78-440E578E289C@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F6369A07AB@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Oct 23 15:20:46 2012 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 50870a2e120619193911432 X-DSPAM-Factors: 27, or+#+BGPSec, 0.40000, not+#+#+#+says, 0.40000, origin+#+#+#+else, 0.40000, very+#+is, 0.40000, question+to, 0.40000, but+#+authenticity, 0.40000, to+#+question, 0.40000, employs+#+#+BGPsec, 0.40000, if+#+#+BGP, 0.40000, to+#+the, 0.40000, such+#+#+#+course, 0.40000, 2012+#+#+04, 0.40000, Of+#+#+the, 0.40000, Certificate+#+sign, 0.40000, concerns+#+#+reasons, 0.40000, me+concerns, 0.40000, Cc*sidr+#+#+#+ietf.org, 0.40000, understand+#+#+origin, 0.40000, might+#+#+but, 0.40000, gives+#+#+for, 0.40000, like+what, 0.40000, Sandra+#+#+that, 0.40000, 04+#+Murphy, 0.40000, one+#+#+#+I, 0.40000, was+not, 0.40000, BGPSec+this, 0.40000, That+is, 0.40000 Cc: sidr wg list Subject: Re: [sidr] origin attribute 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, 23 Oct 2012 21:20:49 -0000 On Oct 23, 2012, at 5:04 PM, Murphy, Sandra wrote: > > Reviewing that was what led to my question to Randy. (something like "what is the reason for having ORIGIN in the first place".) Nice :-) > The responses when this came up in the past have been that protecting integrity of ORIGIN might be conceivable, but the authenticity of the value was not. That is, who says that the AS did indeed get the info from EGP. Sounds like at one time, that mattered. I don't understand, if the origin router employs , say, a BGPsec Router Certificate to sign the origin code attribute, whom else would attest to such a thing? Of course, if the origin BGP router was iBGP only (which _very often is) or non-BGPSec this could be a problem -- that's why we need to start with threats and requirements. This whole "only some BGP speaking routers will be running this extension" gives me concerns for other reasons I suspect will surface as well. -danny !DSPAM:50870a2e120619193911432! From kotikalapudi.sriram@nist.gov Tue Oct 23 14:24:55 2012 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 B7ABE11E80F3 for ; Tue, 23 Oct 2012 14:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxMhal1E3nEZ for ; Tue, 23 Oct 2012 14:24:50 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC3421F861A for ; Tue, 23 Oct 2012 14:24:38 -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.421.2; Tue, 23 Oct 2012 17:24:30 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 23 Oct 2012 17:24:27 -0400 From: "Sriram, Kotikalapudi" To: "Roque Gagliano (rogaglia)" Date: Tue, 23 Oct 2012 17:24:32 -0400 Thread-Topic: [sidr] FW: New Version Notification for draft-sriram-replay-protection-design-discussion-00.txt Thread-Index: AQHNrTENYVfUFBdyXUOH4ZzYAxQB0ZfHZ1Og Message-ID: 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" MIME-Version: 1.0 Cc: "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] FW: New Version Notification for draft-sriram-replay-protection-design-discussion-00.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, 23 Oct 2012 21:24:55 -0000 >(Roque) As expressed in our document, there are many reasons to do key rollover >for BGPSEC certificates, just like in any PKI. Using your taxonomy, can we consider >EKR as emergency rollovers due to a key been compromised, changes on the >certificate information or local policies? [Sriram] I think your description EKR above is different from how we described it in section 5.2 of our document: http://tools.ietf.org/html/draft-sriram-replay-protection-design-discussion-00#section-5.2 EKR is *Event-driven Key Rollover*, and an "event" here is described as peering relationship discontinuation, policy change (e.g., change in how prepending was done for TE purpose, compromised key, etc.). But there is more to clarify about EKR. Please see below. >( Roque) In my mind, the only thing that we we need to care about is if we follow the >periodic scheduled periodic rollover process or an emergency rollover. In general >the difference between the two is that in the emergency case there may not be >the time to wait for the RPKI process to propagate the information. [Sriram] In EKR, there is preparedness for reaction to an "event" so that the affected router can limit the window of exposure to replay attack. In our description of EKR, it is NOT used in combination with PKR. In the EKR, there are always 'Current' and 'Next' transit keys provisioned (in addition to 'Current' and 'Next' origin keys); but this process is not periodic. All these keys have long NotValidAfter time in the EKR method. Since 'Next' transit key is propagated in advance, there is no need to wait for the RPKI process to propagate that information after an event has happened. So in EKR, when an event occurs, the router can immediately start signing with the 'Next' key and the receiving routers already have the corresponding pub key so they can validate the new updates. The router which experienced an event and hence rolled the transit key will propagate a new 'Next' transit key to be prepared for any future event as well. Subsequently, it will also issue a CRL for the previous cert. So EKR is a complete method in itself and can be an alternative to PKR. The trade-off is that EKR produces a churn only when events happen which are presumably rare, but PKR produces update churn and RPKI churn in the background plus it also produces update churn when events happen but less than that for EKR. (Side note: It is true that even in PKR, rollover of transit keys happens for maintenance purpose once in long time (years); but we are focused here on the replay protection issue.) > -- snip -- > >(Roque) Ok, so you are focussing on the "transit" certificate rollover. This means >that this is a different discussion and has nothing to do with the re-play attack as >the technique we are pushing forward to control the windows of exposure are >periodic rollovers of "origin" certificates keys. Is the goal then to compare the >router's behavior when dealing with periodic vs emergency rollovers? > [Sriram] No. We were comparing the amount of update churn that is created when *an event happens* (as described above) in PKR vs. EKR. I hope this should be clear now that I did described "event" and EKR above. What we have shown is that for the same event happening, EKR generally has higher (or much higher in many cases) update churn than PKR for the same event happening. (OTOH, PKR has the downside of producing some update/RPKI churn all the time in the background.) -- snip -- >> what we consider in slides 6-8 is that when the event occurs, in the PKR method >no cert is rolled (by design). > >(Roque) I do not understand your comment " in the PKR method no cert is rolled >(by design)". The transit certificate, as any PKI certificate, will need to be rollover >due to two possible reasons: periodically (it has a long validity period but one day >it will expire) and emergency (particularly key compromised). Now, in each of >these cases, you need to perform a rollover process and you want to "do before >break" (sometimes in emergency process you do not have this option and you >break). > [Sriram] I agree with your observation. But as I said we are focused here on replay protection and events that are of the nature of peering relation discontinuation, policy change, etc. Note that I did say "when the event occurs, in the PKR method no cert is rolled (by design)." You have also stated that the transit cert in not rolled in PKR when these "events" happen. Sriram From danny@tcb.net Tue Oct 23 14:25:34 2012 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 5780A21F8612 for ; Tue, 23 Oct 2012 14:25:34 -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 mW0VuJLqg2u6 for ; Tue, 23 Oct 2012 14:25:33 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA3621F8644 for ; Tue, 23 Oct 2012 14:25:33 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 249A11C6E for ; Tue, 23 Oct 2012 21:25:33 +0000 (UTC) Received: from [192.168.5.209] (ip-64-134-29-132.public.wayport.net [64.134.29.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id C43871C6C; Tue, 23 Oct 2012 15:25:32 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <4EC7E1D2-1385-4BFC-89C6-CCF98B27D734@juniper.net> Date: Tue, 23 Oct 2012 17:25:51 -0400 Content-Transfer-Encoding: 8bit Message-Id: <2EBD8BE2-CFD3-4909-8BF9-9C2826A9BB1C@tcb.net> References: , <4B14E6F9-195C-4C1F-97E8-69ECE0F08041@juniper.net> <4EC7E1D2-1385-4BFC-89C6-CCF98B27D734@juniper.net> To: John G. Scudder X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Oct 23 15:25:33 2012 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 50870b4d120611733092591 X-DSPAM-Factors: 27, would+#+on, 0.40000, What+does, 0.40000, it+#+need, 0.40000, would+#+#+current, 0.40000, need+#+#+justified, 0.40000, To*Scudder+jgs, 0.40000, to+#+justified, 0.40000, more+#+than, 0.40000, Cc*sidr+#+#+#+ietf.org, 0.40000, does+this, 0.40000, seemed+#+#+good, 0.40000, Origin+would, 0.40000, Mime-Version*Message+#+v1283, 0.40000, 23+#+#+#+05, 0.40000, Oct+#+#+#+5, 0.40000, mean+#+operational, 0.40000, To*John+#+#+#+juniper.net, 0.40000, on+current, 0.40000, seemed+#+a, 0.40000, practice+danny, 0.40000, 5+#+PM, 0.40000, so+#+#+#+to, 0.40000, like+a, 0.40000, strongly+#+#+#+a, 0.40000, to+#+#+more, 0.40000, than+#+#+#+good, 0.40000, mean+#+#+practice, 0.40000 Cc: sidr wg list Subject: Re: [sidr] origin attribute 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, 23 Oct 2012 21:25:34 -0000 On Oct 23, 2012, at 5:05 PM, John G. Scudder wrote: > > BGPSec protecting Origin would stomp on current operational practice, so it would need to be justified more strongly than "seemed like a good idea at the time". What does this mean? What operational practice? -danny !DSPAM:50870b4d120611733092591! From danny@tcb.net Tue Oct 23 14:32:58 2012 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 AFF6711E810B for ; Tue, 23 Oct 2012 14:32: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=[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 PpgfCOi1PCO5 for ; Tue, 23 Oct 2012 14:32:58 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB1211E810A for ; Tue, 23 Oct 2012 14:32:58 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 7F7D21C75 for ; Tue, 23 Oct 2012 21:32:57 +0000 (UTC) Received: from [192.168.5.209] (ip-64-134-29-132.public.wayport.net [64.134.29.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 4D0401C74 for ; Tue, 23 Oct 2012 15:32:57 -0600 (MDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1283) From: Danny McPherson In-Reply-To: <737761C0-53E6-4C7C-B423-9E265A915BD6@kumari.net> Date: Tue, 23 Oct 2012 17:33:16 -0400 Content-Transfer-Encoding: 8bit Message-Id: <5998F86B-0156-4A9F-A5C4-E86486B8B807@tcb.net> References: <737761C0-53E6-4C7C-B423-9E265A915BD6@kumari.net> To: sidr wg list X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Oct 23 15:32:57 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50870d09120615471543354 X-DSPAM-Factors: 27, Mime-Version*Message+#+v1283, 0.01000, 2012+at, 0.01000, Subject*Re+#+#+attribute, 0.01000, 23+2012, 0.01000, Mime-Version*Apple+#+framework, 0.01000, Subject*sidr+#+attribute, 0.01000, Mime-Version*1.0+Apple, 0.01000, Mime-Version*1.0+#+Message, 0.01000, Oct+#+#+at, 0.01000, From*Danny+#+danny, 0.01000, From*Danny+#+#+tcb.net, 0.01000, On+#+23, 0.01000, Mime-Version*framework+v1283, 0.01000, Subject*origin+attribute, 0.01000, Subject*Re+sidr, 0.01000, Subject*Re+#+origin, 0.01000, Mime-Version*1.0+#+#+framework, 0.01000, From*Danny+McPherson, 0.01000, Mime-Version*1.0+#+#+#+v1283, 0.01000, Oct+#+2012, 0.01000, On+Oct, 0.01000, 23+#+at, 0.01000, Mime-Version*Apple+#+#+v1283, 0.01000, Mime-Version*Apple+Message, 0.01000, From*McPherson+danny, 0.01000, From*Danny McPherson , 0.01000, From*McPherson+#+tcb.net, 0.01000 Subject: Re: [sidr] origin attribute 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, 23 Oct 2012 21:32:58 -0000 On Oct 23, 2012, at 4:44 PM, Warren Kumari wrote: > Not sure I agree with this part -- simply because it can be used in the decision process doesn't automatically mean it needs to be protected. It (and med and IGP cost and routerID) "feel" to me like they are low enough down that they can be (and should be) left alone, to allow operators some flexibility (Yes, Origin is set by the originator, the rest of these things are more about the local network, but I still don't think that this automatically means that it needs to be protected). Where do you draw that line? Where do you force attackers to move when you draw the line and what's the impact? An origin AS wanting to protect the origin code integrity seems perfectly sensible to me, else upstream ASes can effect not what they meant, but what they said, and drive more traffic across links that they manage, or move traffic, and that's a real problem that exists today that we ought to be able to accommodate. -danny !DSPAM:50870d09120615471543354! From jakob.heitz@ericsson.com Tue Oct 23 14:49:25 2012 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 333831F0C42 for ; Tue, 23 Oct 2012 14:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lY1dTSxXzkVj for ; Tue, 23 Oct 2012 14:49:24 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id A5E2F1F0C3A for ; Tue, 23 Oct 2012 14:49:24 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q9NLnNX1009986 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 16:49:24 -0500 Received: from EUSAAHC004.ericsson.se (147.117.188.84) by eusaamw0711.eamcs.ericsson.se (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 23 Oct 2012 17:49:22 -0400 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 17:49:22 -0400 From: Jakob Heitz To: "John G. Scudder" Thread-Topic: [sidr] origin attribute Thread-Index: AQHNsTElXvo55W2JKkeR5AB07V2NxZfHSRsA///HUuWAAJSGgP//yHJw Date: Tue, 23 Oct 2012 21:49:22 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E0A9C70@EUSAAMB109.ericsson.se> References: , <4B14E6F9-195C-4C1F-97E8-69ECE0F08041@juniper.net> <4EC7E1D2-1385-4BFC-89C6-CCF98B27D734@juniper.net> In-Reply-To: <4EC7E1D2-1385-4BFC-89C6-CCF98B27D734@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] origin attribute 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, 23 Oct 2012 21:49:25 -0000 Thanks John. That's the comment I was fishing for. -- Jakob Heitz. =20 > -----Original Message----- > From: John G. Scudder [mailto:jgs@juniper.net]=20 > Sent: Tuesday, October 23, 2012 2:06 PM > To: Jakob Heitz > Cc: Hannes Gredler; sidr wg list > Subject: Re: [sidr] origin attribute >=20 > On Oct 23, 2012, at 12:13 PM, Jakob Heitz=20 > wrote: > > "origin" does not seem to be an attribute subject to change. >=20 > In theory you're right, if the attribute were being used as=20 > originally envisioned. In practice, as Warren points out,=20 > you're not because it's not. People do set Origin once the=20 > route is in flight, as a handy low-order policy thing they=20 > can fiddle with.=20 >=20 > BGPSec protecting Origin would stomp on current operational=20 > practice, so it would need to be justified more strongly than=20 > "seemed like a good idea at the time". >=20 > --John > = From shane@castlepoint.net Tue Oct 23 15:03:36 2012 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 110D811E8111 for ; Tue, 23 Oct 2012 15:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.285 X-Spam-Level: X-Spam-Status: No, score=-0.285 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=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 ucwQGKn0+znx for ; Tue, 23 Oct 2012 15:03:35 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 84F9111E8112 for ; Tue, 23 Oct 2012 15:03:35 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id BBDF21C7C for ; Tue, 23 Oct 2012 22:03:34 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 84F371C77; Tue, 23 Oct 2012 16:03:34 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: <2EBD8BE2-CFD3-4909-8BF9-9C2826A9BB1C@tcb.net> Date: Tue, 23 Oct 2012 16:03:33 -0600 Content-Transfer-Encoding: 8bit Message-Id: References: , <4B14E6F9-195C-4C1F-97E8-69ECE0F08041@juniper.net> <4EC7E1D2-1385-4BFC-89C6-CCF98B27D734@juniper.net> <2EBD8BE2-CFD3-4909-8BF9-9C2826A9BB1C@tcb.net> To: Danny McPherson X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Oct 23 16:03:34 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50871436120611221711528 X-DSPAM-Factors: 27, 2012+at, 0.01000, 2012+at, 0.01000, at+#+#+PM, 0.01000, at+#+#+PM, 0.01000, Subject*Re+#+#+attribute, 0.01000, 23+2012, 0.01000, 23+2012, 0.01000, Subject*sidr+#+attribute, 0.01000, Oct+#+#+at, 0.01000, Oct+#+#+at, 0.01000, On+#+23, 0.01000, On+#+23, 0.01000, Subject*origin+attribute, 0.01000, 2012+#+#+#+PM, 0.01000, 2012+#+#+#+PM, 0.01000, Subject*Re+sidr, 0.01000, Subject*Re+#+origin, 0.01000, Oct+#+2012, 0.01000, Oct+#+2012, 0.01000, On+Oct, 0.01000, On+Oct, 0.01000, 23+#+at, 0.01000, 23+#+at, 0.01000, Oct+23, 0.01000, Oct+23, 0.01000, On+#+#+#+at, 0.01000, On+#+#+#+at, 0.01000 Cc: "John G. Scudder" , sidr wg list Subject: Re: [sidr] origin attribute 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, 23 Oct 2012 22:03:36 -0000 Danny, On Oct 23, 2012, at 3:25 PM, Danny McPherson wrote: > On Oct 23, 2012, at 5:05 PM, John G. Scudder wrote: >> BGPSec protecting Origin would stomp on current operational practice, so it would need to be justified more strongly than "seemed like a good idea at the time". > > What does this mean? What operational practice? I suspect John is referring to the operational practice employed by some networks, right now, whereby they overwrite ORIGIN during receipt of an UPDATE into their network to 'normalize' ORIGIN to a consistent value. This is especially valuable in cases where one network, A, is multi-homed to an adjacent network, B, and network A may not be announcing a consistent set of BGP path attributes associated with a set of IP prefixes at all locations. Ultimately, this practice allows network B to consistently skip over ORIGIN and, instead, evaluate more well-understood BGP Path Selection criteria like MED's, IGP metric, etc. across the full set of "common" BGP routes, (i.e.: those with the same AS_PATH, LOCAL_PREF, etc.), learned across all exit points to network B. Oh, and FWIW, I agree with the sentiment that "securing" BGP ORIGIN in BGPSEC is a bad idea, for the very reason that I've stated above and others have provided on the list. -shane P.S. -- I would like to coin the saying: "The difference between theory and practice in BGP is, in practice, BGP works in today's Internet, because it's not confined by any theory." :-) > -danny > > > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > > > !DSPAM:50871436120611221711528! From rogaglia@cisco.com Wed Oct 24 01:08:41 2012 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 A59AD21F85B1 for ; Wed, 24 Oct 2012 01:08:41 -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 J7tnLMsKu-6H for ; Wed, 24 Oct 2012 01:08:40 -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 A0ABE21F8592 for ; Wed, 24 Oct 2012 01:08:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5427; q=dns/txt; s=iport; t=1351066120; x=1352275720; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DQkRQNnW8s993Sk0iYrefnu6cXSWFIkzVNga625cq4k=; b=Mu1ASa3liNJXXy46Q06WkPFt4LufTUXnjJ+DW8zarA+9gAQ/8T6tjUWv HSZVtiFnf4UUuL0dc0+S9chgDPpEHrVu1Nb7BW7OXNJ57GGNKyplU6lzq Hos1N1UStydd7SCmnTs1pTMl713DyYGhgI0bQQEDlf6Z7qL814+XueVJm E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAL+gh1CtJV2Z/2dsb2JhbABEwXyBCIIeAQEBBBIBJzgFAhACAQgiFAULMhwJAgQODRqHYgubEKAAi2AVhXZgA5cKjTeBa4JvgVsBBxcGGA X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="134786165" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 24 Oct 2012 08:08:35 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9O88ZoL024253 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Oct 2012 08:08:35 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.176]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Wed, 24 Oct 2012 03:08:35 -0500 From: "Roque Gagliano (rogaglia)" To: "Sriram, Kotikalapudi" Thread-Topic: [sidr] FW: New Version Notification for draft-sriram-replay-protection-design-discussion-00.txt Thread-Index: AQHNrTENYVfUFBdyXUOH4ZzYAxQB0Q== Date: Wed, 24 Oct 2012 08:08:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.19.21] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19302.000 x-tm-as-result: No--42.873700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] FW: New Version Notification for draft-sriram-replay-protection-design-discussion-00.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, 24 Oct 2012 08:08:41 -0000 Hi Sriram, Thanks for your email. The problem I have with the way you described EKR is that it suppose that t= here is some sort of "coordination" between ASes in a way that an origin AS= has to "trust" that whenever there is a topology change in a path, there w= ill be a rollover by the ASes involved in those changes. This sort of cooperation assumptions is a non-started IMHO. All in all, I think we agreed on the path forward. Roque On Oct 23, 2012, at 11:24 PM, Sriram, Kotikalapudi wrote: >> (Roque) As expressed in our document, there are many reasons to do key r= ollover >> for BGPSEC certificates, just like in any PKI. Using your taxonomy, can = we consider >> EKR as emergency rollovers due to a key been compromised, changes on the >> certificate information or local policies? >=20 > [Sriram] I think your description EKR above is different from how we desc= ribed it=20 > in section 5.2 of our document: > http://tools.ietf.org/html/draft-sriram-replay-protection-design-discussi= on-00#section-5.2 =20 > EKR is *Event-driven Key Rollover*, and an "event" here is described as > peering relationship discontinuation, policy change (e.g., change in how > prepending was done for TE purpose, compromised key, etc.).=20 > But there is more to clarify about EKR. Please see below. >=20 >> ( Roque) In my mind, the only thing that we we need to care about is if = we follow the >> periodic scheduled periodic rollover process or an emergency rollover. I= n general >> the difference between the two is that in the emergency case there may n= ot be >> the time to wait for the RPKI process to propagate the information. >=20 > [Sriram] In EKR, there is preparedness for reaction to an "event" so that= the affected router=20 > can limit the window of exposure to replay attack.=20 > In our description of EKR, it is NOT used in combination with PKR.=20 > In the EKR, there are always 'Current' and 'Next' transit keys provisione= d=20 > (in addition to 'Current' and 'Next' origin keys); but this process is no= t periodic. > All these keys have long NotValidAfter time in the EKR method.=20 > Since 'Next' transit key is propagated in advance, there is no need to wa= it=20 > for the RPKI process to propagate that information after an event has hap= pened. > So in EKR, when an event occurs, the router can immediately start > signing with the 'Next' key and the receiving routers already have > the corresponding pub key so they can validate the new updates.=20 > The router which experienced an event and hence rolled the transit key > will propagate a new 'Next' transit key to be prepared for any future eve= nt as well.=20 > Subsequently, it will also issue a CRL for the previous cert.=20 > So EKR is a complete method in itself and can be an alternative to PKR.=20 > The trade-off is that EKR produces a churn only when events happen which = are presumably rare, =20 > but PKR produces update churn and RPKI churn in the background=20 > plus it also produces update churn when events happen but less than that = for EKR. > (Side note: It is true that even in PKR, rollover of transit keys happens= for maintenance=20 > purpose once in long time (years); but we are focused here on the replay = protection issue.) =20 >>=20 > -- snip -- >>=20 >> (Roque) Ok, so you are focussing on the "transit" certificate rollover. = This means >> that this is a different discussion and has nothing to do with the re-pl= ay attack as >> the technique we are pushing forward to control the windows of exposure = are >> periodic rollovers of "origin" certificates keys. Is the goal then to co= mpare the >> router's behavior when dealing with periodic vs emergency rollovers? >>=20 > [Sriram] No. We were comparing the amount of update churn that is created= when=20 > *an event happens* (as described above) in PKR vs. EKR.=20 > I hope this should be clear now that I did described "event" and EKR abov= e.=20 > What we have shown is that for the same event happening, EKR generally ha= s=20 > higher (or much higher in many cases) update churn than PKR=20 > for the same event happening. (OTOH, PKR has the downside of producing=20 > some update/RPKI churn all the time in the background.)=20 >=20 > -- snip -- >=20 >>> what we consider in slides 6-8 is that when the event occurs, in the PK= R method >> no cert is rolled (by design). >>=20 >> (Roque) I do not understand your comment " in the PKR method no cert is = rolled >> (by design)". The transit certificate, as any PKI certificate, will need= to be rollover >> due to two possible reasons: periodically (it has a long validity period= but one day >> it will expire) and emergency (particularly key compromised). Now, in ea= ch of >> these cases, you need to perform a rollover process and you want to "do = before >> break" (sometimes in emergency process you do not have this option and y= ou >> break). >>=20 > [Sriram] I agree with your observation. But as I said we are focused here= on replay protection > and events that are of the nature of peering relation discontinuation, po= licy change, etc. > Note that I did say "when the event occurs, in the PKR method no cert is = rolled (by design)." > You have also stated that the transit cert in not rolled in PKR when thes= e "events" happen. >=20 > Sriram >=20 From rogaglia@cisco.com Wed Oct 24 01:11:37 2012 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 C180321F87DB for ; Wed, 24 Oct 2012 01:11:37 -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 xaVeSULwPOcE for ; Wed, 24 Oct 2012 01:11:35 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 733EF21F85BF for ; Wed, 24 Oct 2012 01:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2376; q=dns/txt; s=iport; t=1351066295; x=1352275895; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7FPcqu1QBfJJPv1BxKPDsZBSPVmzoMd9GqsEb9gYgOc=; b=UeZ/QPezqvbmRdVn/j25h6hAKhqe6SAol2QdRtuGzQbAYS+3TVGUba/J m+wNQVP4XW95jMQ7FvddFJR8jfs7iAmEDfCPJniDshrVQlRirZejK+9f6 f9x8l3wRKCMl4OWh94PGmO0//eeyh2Ikt6zplO/j2Znx6VAJgU5RtsgS/ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABOih1CtJXG8/2dsb2JhbAAqGsF8gQiCHgEBAQMBAQEBDwEnNAsFCwIBCBgKFBAnCyUCBA4FCAEZh1wGCy2aaqAAi2CGC2ADpEGBa4Jvghg X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="134766525" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 24 Oct 2012 08:11:33 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9O8BW2B006580 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Oct 2012 08:11:32 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.176]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Wed, 24 Oct 2012 03:11:32 -0500 From: "Roque Gagliano (rogaglia)" To: Shane Amante Thread-Topic: [sidr] origin attribute Thread-Index: AQHNsb8tFnfek1iZ+EWQUOc4UU6pAQ== Date: Wed, 24 Oct 2012 08:11:32 +0000 Message-ID: References: , <4B14E6F9-195C-4C1F-97E8-69ECE0F08041@juniper.net> <4EC7E1D2-1385-4BFC-89C6-CCF98B27D734@juniper.net> <2EBD8BE2-CFD3-4909-8BF9-9C2826A9BB1C@tcb.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.19.21] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19302.000 x-tm-as-result: No--31.599100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <3CC246914C7F6644BE7FB96B68A34987@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "John G. Scudder" , sidr wg list Subject: Re: [sidr] origin attribute 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 Oct 2012 08:11:37 -0000 Hi Shane, I always found this presentation very instructive to educate on the practic= e you are describing: http://www.nanog.org/meetings/nanog45/abstracts.php?p= t=3DMTIwMCZuYW5vZzQ1&nm=3Dnanog45 I agree that this is common practice, particularly between content operator= s. Roque On Oct 24, 2012, at 12:03 AM, Shane Amante wrote: > Danny, >=20 > On Oct 23, 2012, at 3:25 PM, Danny McPherson wrote: >> On Oct 23, 2012, at 5:05 PM, John G. Scudder wrote: >>> BGPSec protecting Origin would stomp on current operational practice, s= o it would need to be justified more strongly than "seemed like a good idea= at the time". >>=20 >> What does this mean? What operational practice? =20 >=20 > I suspect John is referring to the operational practice employed by some = networks, right now, whereby they overwrite ORIGIN during receipt of an UPD= ATE into their network to 'normalize' ORIGIN to a consistent value. This i= s especially valuable in cases where one network, A, is multi-homed to an a= djacent network, B, and network A may not be announcing a consistent set of= BGP path attributes associated with a set of IP prefixes at all locations.= Ultimately, this practice allows network B to consistently skip over ORIG= IN and, instead, evaluate more well-understood BGP Path Selection criteria = like MED's, IGP metric, etc. across the full set of "common" BGP routes, (i= .e.: those with the same AS_PATH, LOCAL_PREF, etc.), learned across all exi= t points to network B. >=20 > Oh, and FWIW, I agree with the sentiment that "securing" BGP ORIGIN in BG= PSEC is a bad idea, for the very reason that I've stated above and others h= ave provided on the list. =20 >=20 > -shane >=20 > P.S. -- I would like to coin the saying: "The difference between theory a= nd practice in BGP is, in practice, BGP works in today's Internet, because = it's not confined by any theory." :-) >=20 >=20 >=20 >> -danny >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 >>=20 >>=20 >>=20 >=20 >=20 > !DSPAM:50871436120611221711528! >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From danny@tcb.net Wed Oct 24 08:10:53 2012 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 BAF2221F8783 for ; Wed, 24 Oct 2012 08:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 9D1QaLhG7IFr for ; Wed, 24 Oct 2012 08:10:53 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 0C85A21F8829 for ; Wed, 24 Oct 2012 08:10:53 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 7B57D1C28 for ; Wed, 24 Oct 2012 15:10:52 +0000 (UTC) Received: from [172.17.44.208] (unknown [66.18.5.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id DB9311C15; Wed, 24 Oct 2012 09:10:51 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Wed, 24 Oct 2012 11:11:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <4B14E6F9-195C-4C1F-97E8-69ECE0F08041@juniper.net> <4EC7E1D2-1385-4BFC-89C6-CCF98B27D734@juniper.net> <2EBD8BE2-CFD3-4909-8BF9-9C2826A9BB1C@tcb.net> To: Shane Amante X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Oct 24 09:10:52 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 508804fc199631440096932 X-DSPAM-Factors: 27, Cc*sidr+#+#+#+ietf.org, 0.01000, Mime-Version*Message+#+v1283, 0.01000, 2012+at, 0.01000, at+#+#+PM, 0.01000, Cc*sidr+wg, 0.01000, Subject*Re+#+#+attribute, 0.01000, 23+2012, 0.01000, Mime-Version*Apple+#+framework, 0.01000, Subject*sidr+#+attribute, 0.01000, Cc*wg+#+sidr, 0.01000, Mime-Version*1.0+Apple, 0.01000, Mime-Version*1.0+#+Message, 0.01000, Cc*sidr+#+list, 0.01000, Cc*wg+list, 0.01000, to+#+#+to, 0.01000, in+the, 0.01000, Oct+#+#+at, 0.01000, From*Danny+#+danny, 0.01000, From*Danny+#+#+tcb.net, 0.01000, On+#+23, 0.01000, Mime-Version*framework+v1283, 0.01000, Subject*origin+attribute, 0.01000, 2012+#+#+#+PM, 0.01000, Subject*Re+sidr, 0.01000, Subject*Re+#+origin, 0.01000, Mime-Version*1.0+#+#+framework, 0.01000, From*Danny+McPherson, 0.01000 Cc: sidr wg list Subject: Re: [sidr] origin attribute 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 Oct 2012 15:10:53 -0000 On Oct 23, 2012, at 6:03 PM, Shane Amante wrote: > I suspect John is referring to the operational practice employed by = some networks, right now, whereby they overwrite ORIGIN during receipt = of an UPDATE into their network to 'normalize' ORIGIN to a consistent = value. Ironically, if "normalize[ing] ORIGIN to a consistent value" at an = upstream AS results in a change to the ORIGIN code for a given path, = you've _created INconsistent ORIGIN codes for the prefix in the routing = system. I suppose I understand why this might be desirable for a = transit network provider, but as an edge AS I'd prefer to not have = intermediate networks changing the values I set. =20 > This is especially valuable in cases where one network, A, is = multi-homed to an adjacent network, B, and network A may not be = announcing a consistent set of BGP path attributes associated with a set = of IP prefixes at all locations. Ultimately, this practice allows = network B to consistently skip over ORIGIN and, instead, evaluate more = well-understood BGP Path Selection criteria like MED's, IGP metric, etc. > across the full set of "common" BGP routes, (i.e.: those with the same = AS_PATH, LOCAL_PREF, etc.), learned across all exit points to network B. I'm pretty sure MEDs and "IGP metric" are far more ambiguous and broken = in practice than ORIGIN code (e.g., [1]), especially when comparing = across paths learned from different adjacent ASes. -danny [1] = = From kotikalapudi.sriram@nist.gov Wed Oct 24 08:48:17 2012 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 BFE2E21F8C58 for ; Wed, 24 Oct 2012 08:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c86c0UHSihb6 for ; Wed, 24 Oct 2012 08:48:17 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 9131E21F8C81 for ; Wed, 24 Oct 2012 08:48:15 -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.421.2; Wed, 24 Oct 2012 11:48:10 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 24 Oct 2012 11:48:06 -0400 From: "Sriram, Kotikalapudi" To: "Roque Gagliano (rogaglia)" Date: Wed, 24 Oct 2012 11:48:12 -0400 Thread-Topic: [sidr] FW: New Version Notification for draft-sriram-replay-protection-design-discussion-00.txt Thread-Index: AQHNrTENYVfUFBdyXUOH4ZzYAxQB0ZfIl8/g Message-ID: 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" MIME-Version: 1.0 Cc: "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] FW: New Version Notification for draft-sriram-replay-protection-design-discussion-00.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, 24 Oct 2012 15:48:17 -0000 Roque, Thanks. Some new observations below. Sriram > >The problem I have with the way you described EKR is that it suppose that there is > The description of EKR is based how it was discussed at the Feb. 2012 SIDR interim in San Diego. The meeting notes didn't capture the description well, but it is there (also didn't refer to it as EKR at the time): http://www.ietf.org/mail-archive/web/sidr/current/msg04000.html >some sort of "coordination" between ASes in a way that an origin AS has to >"trust" that whenever there is a topology change in a path, there will be a rollover >by the ASes involved in those changes. > You are right, but there is a reverse trust issue as well (with PKR). I suspect that PKR and EKR may co-exist in the BGPSEC network for the following reasons: It is known that 84% of all ASes are stubs. Over some time initially (during BGPSEC adoption), some or many of the stub ASes may participate in BGPSEC but not operate PKR as expected of them. They may be wary or clueless about rolling their certs every 24 hours or so. So they might just set their cert NotValidAfter time to some large value, and perhaps not want to be bothered with doing the rollover frequently. If a transit provider suspects that may be happening, then they would want to play it safe (i.e., avoid liability) and rollover their transit cert (i.e., perform EKR) whenever they have topology change or policy change in their AS that affects transit prefixes. This way they can be sure they are doing what is in their control to provide some protection from replay attacks for their transit prefixes even if some origin ASes may be negligent. It seems to me that the hooks needed to implement EKR are a subset of those needed for PKR. So the operators may choose to do EKR anyway until they are certain that there is close to full participation in PKR by origin ASes. Sriram From shane@castlepoint.net Wed Oct 24 09:54:05 2012 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 E99C421F86F8 for ; Wed, 24 Oct 2012 09:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.375 X-Spam-Level: X-Spam-Status: No, score=0.375 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=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 FqI3SGYUdLDG for ; Wed, 24 Oct 2012 09:54:01 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id ED62821F86D9 for ; Wed, 24 Oct 2012 09:54:00 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 6DB421CEA for ; Wed, 24 Oct 2012 16:53:59 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 0466D1CA7; Wed, 24 Oct 2012 10:53:59 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: Date: Wed, 24 Oct 2012 10:53:58 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <4B14E6F9-195C-4C1F-97E8-69ECE0F08041@juniper.net> <4EC7E1D2-1385-4BFC-89C6-CCF98B27D734@juniper.net> <2EBD8BE2-CFD3-4909-8BF9-9C2826A9BB1C@tcb.net> To: Danny McPherson X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Oct 24 10:53:59 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50881d27199633604875165 X-DSPAM-Factors: 27, to+#+the, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, the+#+code, 0.01000, 2012+at, 0.01000, 2012+at, 0.01000, at+#+#+PM, 0.01000, Cc*sidr+wg, 0.01000, Subject*Re+#+#+attribute, 0.01000, 23+2012, 0.01000, Subject*sidr+#+attribute, 0.01000, is+#+#+the, 0.01000, Cc*wg+#+sidr, 0.01000, PM+#+#+wrote, 0.01000, Cc*sidr+#+list, 0.01000, Cc*wg+list, 0.01000, to+#+#+to, 0.01000, in+the, 0.01000, in+the, 0.01000, Oct+#+#+at, 0.01000, Oct+#+#+at, 0.01000, On+#+23, 0.01000, need+to, 0.01000, Subject*origin+attribute, 0.01000, 2012+#+#+#+PM, 0.01000, Subject*Re+sidr, 0.01000, Subject*Re+#+origin, 0.01000, Cc*sidr+#+#+sidr, 0.01000 Cc: sidr wg list Subject: Re: [sidr] origin attribute 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 Oct 2012 16:54:05 -0000 Danny, On Oct 24, 2012, at 9:11 AM, Danny McPherson wrote: > On Oct 23, 2012, at 6:03 PM, Shane Amante wrote: >=20 >> I suspect John is referring to the operational practice employed by = some networks, right now, whereby they overwrite ORIGIN during receipt = of an UPDATE into their network to 'normalize' ORIGIN to a consistent = value. >=20 > Ironically, if "normalize[ing] ORIGIN to a consistent value" at an = upstream AS results in a change to the ORIGIN code for a given path, = you've _created INconsistent ORIGIN codes for the prefix in the routing = system. I suppose I understand why this might be desirable for a = transit network provider, but as an edge AS I'd prefer to not have = intermediate networks changing the values I set. Fair enough. In my defense :-), RFC 4271 does state that ORIGIN code = "SHOULD NOT" be changed by any other speaker = . Fortunately, it = doesn't say: "MUST NOT". :-) Perhaps a better question should be: is ORIGIN code still required, = particularly from a BGP path selection perspective, in today's networks? = I would say "no". (If you wanted to know the 'source' of a BGP route, = there are already a plethora of BGP communities to help operators narrow = this down ... but, this is more for convenience of troubleshooting, it = doesn't need to be in path selection). IOW, instead of "securing" ORIGIN, maybe folks should be looking at = deprecating it? IMO, this would have likely been a far more productive = use of time than the deprecation of AS_SET's, (the latter of which I = still maintain was a bad idea, done primarily for convenience w/out = adequate consideration of it's _long-term_ usefulness). >> This is especially valuable in cases where one network, A, is = multi-homed to an adjacent network, B, and network A may not be = announcing a consistent set of BGP path attributes associated with a set = of IP prefixes at all locations. Ultimately, this practice allows = network B to consistently skip over ORIGIN and, instead, evaluate more = well-understood BGP Path Selection criteria like MED's, IGP metric, etc. >> across the full set of "common" BGP routes, (i.e.: those with the = same AS_PATH, LOCAL_PREF, etc.), learned across all exit points to = network B. >=20 > I'm pretty sure MEDs and "IGP metric" are far more ambiguous and = broken in practice than ORIGIN code (e.g., [1]), especially when = comparing across paths learned from different adjacent ASes. FWIW, I wasn't actually referring to to MED or IGP metric comparison = across different AS_PATHs, rather MED or IGP metric comparison across = same AS_PATHs. Regardless, your point is valid that comparison of MED's, even just = across the same AS_PATH, is oftentimes fraught with operational = headaches/brokenness. However, in defense of MED's :-), I believe that = the root cause problem here is, most likely, an inability (or, worse, = unwillingness) for the network sending MED's to continually fine-tune = not only the MED value(s), but at the same time (just as importantly) to = __intelligently__, (i.e.: only when necessary), deaggregate [very] large = prefixes in order that more relevant MED values can be targeted at those = more specifics resulting in better 'signals' toward upstream networks. = Then again, we might agree to disagree on this. :) To the larger point of going back to actual requirements for this work, = then why hasn't there been discussion in the requirements or threats = documents about 'securing': - ORIGIN - NEXT_HOP: third-party NEXT_HOP at IXP's anyone? BTW, I would note that the above would be an extremely clever way to = divert traffic through a bad guy's network that would be completely = invisible within the AS_PATH, (but could show up in traceroutes). w00t! - MED's - BGP communities: which are quite commonly used to manipulate an = upstream's BGP path selection algorithm (i.e.: raise/lower LOCAL_PREF) = and/or _scope_ the announcement toward adjacent ASN's/routers, (i.e.: = no-export, no-advertise, being the two standards-based ones)? ... not even a mention of being "out-of-scope" and for what reason(s), = even though draft-ietf-sidr-bgpsec-reqs-05 states: "As noted in the = threat model, [I-D.ietf-sidr-bgpsec-threats], this work is limited to = threats to the BGP protocol." =20 Then again, there still isn't a serious acknowledgement that 'route = leaks' are, in fact, a much more serious "threat to the BGP protocol", = than manipulation of most of those BGP attributes even though the = route-leaks problem has been crisply defined in 1.5 pages: = http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-hel= p-01 ... with further elaboration in this and associated drafts: http://tools.ietf.org/html/draft-dickson-sidr-route-leak-def-03 -shane > -danny >=20 >=20 > [1] = From heas@shrubbery.net Wed Oct 24 09:58:07 2012 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 DA63F21F8855 for ; Wed, 24 Oct 2012 09:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.745 X-Spam-Level: X-Spam-Status: No, score=-4.745 tagged_above=-999 required=5 tests=[AWL=1.854, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHZFzaPDifsg for ; Wed, 24 Oct 2012 09:58:06 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A61221F880B for ; Wed, 24 Oct 2012 09:58:06 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 2A0C79A6C8; Wed, 24 Oct 2012 16:58:07 +0000 (UTC) Date: Wed, 24 Oct 2012 16:58:07 +0000 From: heasley To: Shane Amante Message-ID: <20121024165807.GP79235@shrubbery.net> References: <4B14E6F9-195C-4C1F-97E8-69ECE0F08041@juniper.net> <4EC7E1D2-1385-4BFC-89C6-CCF98B27D734@juniper.net> <2EBD8BE2-CFD3-4909-8BF9-9C2826A9BB1C@tcb.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.5.21 (2010-09-15) Cc: sidr wg list Subject: Re: [sidr] origin attribute 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 Oct 2012 16:58:08 -0000 Wed, Oct 24, 2012 at 10:53:58AM -0600, Shane Amante: > Danny, > > On Oct 24, 2012, at 9:11 AM, Danny McPherson wrote: > > On Oct 23, 2012, at 6:03 PM, Shane Amante wrote: > > > >> I suspect John is referring to the operational practice employed by some networks, right now, whereby they overwrite ORIGIN during receipt of an UPDATE into their network to 'normalize' ORIGIN to a consistent value. > > > > Ironically, if "normalize[ing] ORIGIN to a consistent value" at an upstream AS results in a change to the ORIGIN code for a given path, you've _created INconsistent ORIGIN codes for the prefix in the routing system. I suppose I understand why this might be desirable for a transit network provider, but as an edge AS I'd prefer to not have intermediate networks changing the values I set. > > Fair enough. In my defense :-), RFC 4271 does state that ORIGIN code "SHOULD NOT" be changed by any other speaker . Fortunately, it doesn't say: "MUST NOT". :-) > > Perhaps a better question should be: is ORIGIN code still required, particularly from a BGP path selection perspective, in today's networks? I would say "no". (If you wanted to know the 'source' of a BGP route, there are already a plethora of BGP communities to help operators narrow this down ... but, this is more for convenience of troubleshooting, it doesn't need to be in path selection). > > IOW, instead of "securing" ORIGIN, maybe folks should be looking at deprecating it? IMO, this would have likely been a far more productive use of time than the deprecation of AS_SET's, (the latter of which I still maintain was a bad idea, done primarily for convenience w/out adequate consideration of it's _long-term_ usefulness). its used as a "TE" knob, whether danny likes it or not. given the lack of TE knobs, a lot of hatred should be expected if its taken away (deprecated or "secured"). > > >> This is especially valuable in cases where one network, A, is multi-homed to an adjacent network, B, and network A may not be announcing a consistent set of BGP path attributes associated with a set of IP prefixes at all locations. Ultimately, this practice allows network B to consistently skip over ORIGIN and, instead, evaluate more well-understood BGP Path Selection criteria like MED's, IGP metric, etc. > >> across the full set of "common" BGP routes, (i.e.: those with the same AS_PATH, LOCAL_PREF, etc.), learned across all exit points to network B. > > > > I'm pretty sure MEDs and "IGP metric" are far more ambiguous and broken in practice than ORIGIN code (e.g., [1]), especially when comparing across paths learned from different adjacent ASes. > > FWIW, I wasn't actually referring to to MED or IGP metric comparison across different AS_PATHs, rather MED or IGP metric comparison across same AS_PATHs. > > Regardless, your point is valid that comparison of MED's, even just across the same AS_PATH, is oftentimes fraught with operational headaches/brokenness. However, in defense of MED's :-), I believe that the root cause problem here is, most likely, an inability (or, worse, unwillingness) for the network sending MED's to continually fine-tune not only the MED value(s), but at the same time (just as importantly) to __intelligently__, (i.e.: only when necessary), deaggregate [very] large prefixes in order that more relevant MED values can be targeted at those more specifics resulting in better 'signals' toward upstream networks. Then again, we might agree to disagree on this. :) > > > To the larger point of going back to actual requirements for this work, then why hasn't there been discussion in the requirements or threats documents about 'securing': > - ORIGIN > - NEXT_HOP: third-party NEXT_HOP at IXP's anyone? > BTW, I would note that the above would be an extremely clever way to divert traffic through a bad guy's network that would be completely invisible within the AS_PATH, (but could show up in traceroutes). w00t! > - MED's > - BGP communities: which are quite commonly used to manipulate an upstream's BGP path selection algorithm (i.e.: raise/lower LOCAL_PREF) and/or _scope_ the announcement toward adjacent ASN's/routers, (i.e.: no-export, no-advertise, being the two standards-based ones)? > > ... not even a mention of being "out-of-scope" and for what reason(s), even though draft-ietf-sidr-bgpsec-reqs-05 states: "As noted in the threat model, [I-D.ietf-sidr-bgpsec-threats], this work is limited to threats to the BGP protocol." > > Then again, there still isn't a serious acknowledgement that 'route leaks' are, in fact, a much more serious "threat to the BGP protocol", than manipulation of most of those BGP attributes even though the route-leaks problem has been crisply defined in 1.5 pages: > http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-help-01 > ... with further elaboration in this and associated drafts: > http://tools.ietf.org/html/draft-dickson-sidr-route-leak-def-03 > > > > -shane > > > > > -danny > > > > > > [1] > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From danny@tcb.net Wed Oct 24 10:09:38 2012 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 9AE6E21F85A6 for ; Wed, 24 Oct 2012 10:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.05 X-Spam-Level: X-Spam-Status: No, score=-102.05 tagged_above=-999 required=5 tests=[AWL=0.549, 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 BtafoNni3gyN for ; Wed, 24 Oct 2012 10:09:38 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 35E3021F85ED for ; Wed, 24 Oct 2012 10:09:38 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id C0B7C1CF7 for ; Wed, 24 Oct 2012 17:09:37 +0000 (UTC) Received: from [172.17.44.208] (unknown [66.18.5.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 9E1041CEE for ; Wed, 24 Oct 2012 11:09:37 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Danny McPherson In-Reply-To: <20121024165807.GP79235@shrubbery.net> Date: Wed, 24 Oct 2012 13:09:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B14E6F9-195C-4C1F-97E8-69ECE0F08041@juniper.net> <4EC7E1D2-1385-4BFC-89C6-CCF98B27D734@juniper.net> <2EBD8BE2-CFD3-4909-8BF9-9C2826A9BB1C@tcb.net> <20121024165807.GP79235@shrubbery.net> To: sidr wg list X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Oct 24 11:09:37 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 508820d1199631012520429 X-DSPAM-Factors: 27, Mime-Version*Message+#+v1283, 0.01000, the+#+#+the, 0.01000, 2012+at, 0.01000, at+#+#+PM, 0.01000, Subject*Re+#+#+attribute, 0.01000, Mime-Version*Apple+#+framework, 0.01000, Subject*sidr+#+attribute, 0.01000, Mime-Version*1.0+Apple, 0.01000, Mime-Version*1.0+#+Message, 0.01000, the+#+of, 0.01000, in+the, 0.01000, Oct+#+#+at, 0.01000, From*Danny+#+danny, 0.01000, From*Danny+#+#+tcb.net, 0.01000, Mime-Version*framework+v1283, 0.01000, Subject*origin+attribute, 0.01000, 2012+#+#+#+PM, 0.01000, Subject*Re+sidr, 0.01000, Subject*Re+#+origin, 0.01000, Mime-Version*1.0+#+#+framework, 0.01000, From*Danny+McPherson, 0.01000, Mime-Version*1.0+#+#+#+v1283, 0.01000, Oct+#+2012, 0.01000, On+Oct, 0.01000, Mime-Version*Apple+#+#+v1283, 0.01000, a+#+of, 0.01000, Mime-Version*Apple+Message, 0.01000 Subject: Re: [sidr] origin attribute 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 Oct 2012 17:09:38 -0000 On Oct 24, 2012, at 12:58 PM, heasley wrote: > its used as a "TE" knob, whether danny likes it or not. =20 I didn't say I disliked it. I said that I disliked intermediate ASNs = manipulating the values an originating AS configured, because it has = system wide implications and could impact things that were expressly = intended by the originator of the route. As a matter of fact, a mandatory transitive attribute provides a nice = capability for an operator to influence ingress traffic from upstream = ASes multiple hops away -- and I certainly have realized utility from = that in the past. -danny= From brian.peter.dickson@gmail.com Wed Oct 24 10:46:39 2012 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 204F021F884A for ; Wed, 24 Oct 2012 10:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOCG1kfOJbwZ for ; Wed, 24 Oct 2012 10:46:38 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF2821F880B for ; Wed, 24 Oct 2012 10:46:37 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so369177bkc.31 for ; Wed, 24 Oct 2012 10:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dAExp8VVm/XO6kAUb6GlGbSKfItWvydFDn+Ey/ZG9M0=; b=ZlnVq60XuCeGnV7JapzKIABiTECTULkGlizju28onbPibSfL3+kwNkctrUjFL0O6zm ZHMPfTzb4XGAKIOloh6fcG6ug7Ec/QOvjaZE9vPQ0B8KE7dmdWWLUfAl5ReJQZ2HIU1t eGMKVuT8XUL72arpsa7yIcTrPgQTrksXmBMvvqoo2T65OG9pRhEtJDSgq0GmBT4MoiJ2 T+H5c9qytpDyOKhdBrg3GWcYedUzIwUYGb5RgA/QEpx2Rb4kuTuLq9XBVrG5yTunZM9E mln/cesSuKU0wBeVS9C2jQrYZB2CjIsP8Y4A+why8F7biCKzsvm1FyFfIYilmxZ3zU37 Eceg== MIME-Version: 1.0 Received: by 10.204.9.9 with SMTP id j9mr5182775bkj.12.1351100797123; Wed, 24 Oct 2012 10:46:37 -0700 (PDT) Received: by 10.204.231.197 with HTTP; Wed, 24 Oct 2012 10:46:37 -0700 (PDT) In-Reply-To: <20121024165807.GP79235@shrubbery.net> References: <4B14E6F9-195C-4C1F-97E8-69ECE0F08041@juniper.net> <4EC7E1D2-1385-4BFC-89C6-CCF98B27D734@juniper.net> <2EBD8BE2-CFD3-4909-8BF9-9C2826A9BB1C@tcb.net> <20121024165807.GP79235@shrubbery.net> Date: Wed, 24 Oct 2012 13:46:37 -0400 Message-ID: From: Brian Dickson To: heasley Content-Type: multipart/alternative; boundary=00151758f42c117d5c04ccd1ab5b Cc: sidr wg list Subject: Re: [sidr] origin attribute 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 Oct 2012 17:46:39 -0000 --00151758f42c117d5c04ccd1ab5b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 24, 2012 at 12:58 PM, heasley wrote: > > its used as a "TE" knob... [snip]. given the lack of > TE knobs, a lot of hatred should be expected if its taken away (deprecated > or > "secured"). Just to educate anyone who is not familiar with *why* it is used, I'll explain the most common *how*: Since it has 3 possible values, and is used immediately after as-path-length in the BGP path selection process, it can be treated as a "fractional" as-path-length value (0/3, 1/3, or 2/3) for breaking ties in as-path-length. If two received routes for the same prefix/length have the same as-path-length, and the same ORIGIN attribute, the ORIGIN is effectively ignored. If the ORIGIN attribute differs, then ORIGIN breaks the tie, and no other attributes are compared (only with respect to those two routes, of course). One way I've seen it used, is in an attempt to influence return traffic along the same path as sent traffic, e.g. to achieve non-asymmetric traffic flows. These are helpful in identifying (and avoiding) high latency/loss links not directly under one's control. The places this is most commonly done are: By the originator By the originator's upstream transit provider(s) (or their providers, etc.), who is/are not default-free By the recipients' upstream transit provider(s). By the recipient In the case of the recipient, he/she is clearly free to munge it *after* all BGPSEC validation is done. So only the other three cases need to be taken into consideration. Maybe there should be a way to optionally include attributes to sign & protect? This would be a good candidate. First one to stomp on it and sign it wins. Brian --00151758f42c117d5c04ccd1ab5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Oct 24, 2012 at 12:58 PM, heasle= y <heas@shrubbery.net> wrote:
its used as a "TE" knob...=A0
[snip].=A0
=A0given the lack of
TE knobs, a lot of hatred should be expected if its taken away (deprecated = or
"secured").

Just to educate anyon= e who is not familiar with *why* it is used, I'll explain the most comm= on *how*:

Since it has 3 possible values, and is u= sed immediately after as-path-length in the BGP path selection process,
it can be treated as a "fractional" as-path-length value (0/= 3, 1/3, or 2/3) for breaking ties in as-path-length.

If two received routes for the same prefix/length have the same as-path-= length, and the same ORIGIN attribute, the ORIGIN is effectively ignored.
If the ORIGIN attribute differs, then ORIGIN breaks the tie, and no ot= her attributes are compared (only with respect to those two routes, of cour= se).

One way I've seen it used, is in an attem= pt to influence return traffic along the same path as sent traffic, e.g. to= achieve non-asymmetric traffic flows.
These are helpful in identifying (and avoiding) high latency/loss link= s not directly under one's control.

The places this= is most commonly done are:
By the originator
By the or= iginator's upstream transit provider(s) (or their providers, etc.), who= is/are not default-free
By the recipients' upstream transit provider(s).
By the = recipient

In the case of the recipient, he/she is = clearly free to munge it *after* all BGPSEC validation is done.
So only the other three cases need to be taken into consideration.

Maybe there should be a way to optionally include attribut= es to sign & protect?
This would be a good candidate.
First one to stomp on it and sign it wins.

Br= ian
--00151758f42c117d5c04ccd1ab5b-- From Sandra.Murphy@sparta.com Thu Oct 25 08:15:19 2012 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 54B7821F902E for ; Thu, 25 Oct 2012 08:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 Qpceb4Y8vvdx for ; Thu, 25 Oct 2012 08:15:18 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id A617421F902C for ; Thu, 25 Oct 2012 08:15:18 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q9PFFHcL020588 for ; Thu, 25 Oct 2012 10:15:17 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q9PFFHqX023524 for ; Thu, 25 Oct 2012 10:15:17 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Thu, 25 Oct 2012 11:15:17 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: draft agenda uploaded Thread-Index: Ac2yw4m+TxhWv4puSoe/ouxbYjuZyg== Date: Thu, 25 Oct 2012 15:15:16 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6369A2C97@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] draft agenda uploaded 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 Oct 2012 15:15:19 -0000 The draft sidr agenda was uploaded yesterday. If you requested time at the= upcoming meeting, but you were not added to the agenda, please do poke the= chairs. This is a draft agenda. If you have topics you wish to discuss at the meet= ing, please do make a request. We have a lot of time in total, so please do bring up what you would like t= o discuss. --Sandy= From Sandra.Murphy@sparta.com Thu Oct 25 08:25:07 2012 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 4BF6721F892D for ; Thu, 25 Oct 2012 08:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 vwLHNSFpgDM2 for ; Thu, 25 Oct 2012 08:25:06 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id EB04221F88A9 for ; Thu, 25 Oct 2012 08:25:05 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q9PFP3MW020688 for ; Thu, 25 Oct 2012 10:25:03 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q9PFP2gS023824 for ; Thu, 25 Oct 2012 10:25:02 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Thu, 25 Oct 2012 11:25:02 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: neglected topics Thread-Index: Ac2u9W5JqshnzyuNSxecWu4uTmgeaQ== Date: Thu, 25 Oct 2012 15:25:01 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F634705E02@CMA-MB003.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] neglected topics 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 Oct 2012 15:25:07 -0000 There are a few topics that had an initial flurry of energetic discussion, = were adopted by the working group, and then had little if any further discu= ssion. These could be a part of the agenda for the upcoming meeting, but p= rep for the discussion by at least looking at the drafts would be good. One was the topic of local trust anchor management. This was discussed as = an individual draft and saw some strong exchanges. It was refreshed at the= last meeting, but there's been no subsequent discussion. This is a featur= e that gets mentioned from time to time and seems important to deployment. = The presentations at meetings show that this is a complex feature, so it n= eeds serious consideration. The authors have requested a wglc, but the cha= irs are balking due to the lack of discussion and the complexity. WG, please take a moment to review the draft. Newest version is: http://tools.ietf.org/html/draft-ietf-sidr-ltamgmt-07 Topic 2: Getting the appropriate key pair into a router. This was a hot topic for a while, but has seen little actions since. There= is a draft, but again, not much discussion. Newest verison is: http://tools.ietf.org/html/draft-ietf-sidr-rtr-keying Others? --Sandy, speaking as co-chair= From carlosm3011@gmail.com Thu Oct 25 09:08:27 2012 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 6186521F89BF for ; Thu, 25 Oct 2012 09:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmgYjwEnkAts for ; Thu, 25 Oct 2012 09:08:26 -0700 (PDT) Received: from mail-ye0-f172.google.com (mail-ye0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B996E21F89BE for ; Thu, 25 Oct 2012 09:08:26 -0700 (PDT) Received: by mail-ye0-f172.google.com with SMTP id l13so326346yen.31 for ; Thu, 25 Oct 2012 09:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=p1k/j1JMWTPEhBSTtcRo8t1/efxc06iFcQfWAFQKwCY=; b=MxjyNgYsffQttduUKxRVavHiuYBKSZt9ExowkPPbJIBFclanxKmLWnJbBfQGhl6gmU qE3kVo25FY7aytTuUyIjqteXUEAPjpK1D5+haNeG5F8kyCG5DKACN9jXlboc0w7Os1uf tggwfV8dQo2URrs9MSdb1UQmzWu577bmL3OfbDYl8i25tsIFROel2xZzTZU8yGkbKon/ duGKjcAldCjilbqaBLbwRPDwVPsjqOoH46tewayViOXAPldSVyw41r2I0VAntfUBWE1B MiqjhXVmeAqTYwI7JLLsHYu81NlzCBhYOOPZeQy3TxKXNdpFTReHUzI//klnPY2pmYAY Rxnw== Received: by 10.236.73.161 with SMTP id v21mr19365586yhd.103.1351181306247; Thu, 25 Oct 2012 09:08:26 -0700 (PDT) Received: from europa.local ([2001:13c7:7001:2128:b86d:fd23:db09:e494]) by mx.google.com with ESMTPS id l16sm16341432anm.6.2012.10.25.09.08.24 (version=SSLv3 cipher=OTHER); Thu, 25 Oct 2012 09:08:25 -0700 (PDT) Message-ID: <508963F6.1030501@gmail.com> Date: Thu, 25 Oct 2012 14:08:22 -0200 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "sidr@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [sidr] LACNIC 18 / LACNOG 2012 conference network 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 Oct 2012 16:08:27 -0000 Hello, We will be running origin validation on our conference routers (hopefully) starting this Saturday. We have already tested the configuration in the ISPs testbed and the equipment is currently being moved to the conference venue. We'll be using dual instances of RIPE's validator app as the RTR server. For starters we will be accepting invalids anyways (yes, yes, I know :-) ), but we plan on switching to fully paranoid mode over the week. If there is interest in running / performing some experiment(s) we can talk about it. cheers! ~Carlos From carlosm3011@gmail.com Thu Oct 25 09:09:48 2012 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 3153321F8789 for ; Thu, 25 Oct 2012 09:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PubbBFUlJs7V for ; Thu, 25 Oct 2012 09:09:46 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7B21821F875A for ; Thu, 25 Oct 2012 09:09:46 -0700 (PDT) Received: by mail-gh0-f172.google.com with SMTP id g10so382075ghb.31 for ; Thu, 25 Oct 2012 09:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-forwarded-message-id:content-type; bh=qiF1IswVO7q+yBLWJJIeech8hKP4GyMkhahormmyrTo=; b=ADMe/xghAxix1fXtlhdz5D4v+fB3CpdcYtAcs4ZgcEPyRwtyAs3A8FQshFysNke8pS W8n+lfezshPWU4yuXtKWdncg9FuAGl/7b6LTs8fa5zpXHIRY/mMZ9p/AcpuB3gUdl3BX QS2006F11oxghXM7iMJMwWkwYFHoJW4Upo+nsTZjpSytPrBydgAcvWrIn2afxTAavX1g bKk9lYbwq3bkmWiCnBrzQo0kkStEdvt8fkYOS229aZFEuy3O9YuG03Bxnsyd3p2SHMwn EgsThflUhKz5cwwKJL6MWwAFI0ZByLMy4wWaeKB6ggz4eWs8reiuGBtVegswQHWr3xu7 sAcw== Received: by 10.100.245.12 with SMTP id s12mr6058506anh.62.1351181373687; Thu, 25 Oct 2012 09:09:33 -0700 (PDT) Received: from europa.local ([2001:13c7:7001:2128:b86d:fd23:db09:e494]) by mx.google.com with ESMTPS id u49sm18080324yhd.18.2012.10.25.09.09.31 (version=SSLv3 cipher=OTHER); Thu, 25 Oct 2012 09:09:32 -0700 (PDT) Message-ID: <50896439.8080803@gmail.com> Date: Thu, 25 Oct 2012 14:09:29 -0200 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "sidr@ietf.org" References: <20121015191824.4680.48268.idtracker@ietfa.amsl.com> In-Reply-To: <20121015191824.4680.48268.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121015191824.4680.48268.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------030800020209060209070406" Subject: [sidr] Fwd: New Version Notification for draft-rogaglia-sidr-multiple-publication-points-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: Thu, 25 Oct 2012 16:09:48 -0000 This is a multi-part message in MIME format. --------------030800020209060209070406 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit FYI, added new co-author, added empty line between URIs and key. regards, ~Carlos -------- Original Message -------- Subject: New Version Notification for draft-rogaglia-sidr-multiple-publication-points-01.txt Date: Mon, 15 Oct 2012 12:18:24 -0700 From: internet-drafts@ietf.org To: carlos@lacnic.net CC: rogaglia@cisco.com, terry.manderson@icann.org A new version of I-D, draft-rogaglia-sidr-multiple-publication-points-01.txt has been successfully submitted by Carlos Martinez and posted to the IETF repository. Filename: draft-rogaglia-sidr-multiple-publication-points Revision: 01 Title: Multiple Repository Publication Points support in the Resource Public Key Infrastructure (RPKI) Creation date: 2012-10-15 WG ID: Individual Submission Number of pages: 12 URL: http://www.ietf.org/internet-drafts/draft-rogaglia-sidr-multiple-publication-points-01.txt Status: http://datatracker.ietf.org/doc/draft-rogaglia-sidr-multiple-publication-points Htmlized: http://tools.ietf.org/html/draft-rogaglia-sidr-multiple-publication-points-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-rogaglia-sidr-multiple-publication-points-01 Abstract: The Resource Public Key Infrastructure (RPKI) depends on Relying Parties (RP) ability to access its Trust Anchors' certificate specified in the different "Trust Anchor Locator (TAL)" files and the Repository Objects located at the Certificate Authorities (CA) repositories hosted in its respective publication point. This document updates [RFC6490] by allowing multiple URI associated to a single public key in a TAL file and introduces the concept of multiple repository publication point operators for every CA in the RPKI. This document provides also recommendation for the RP behavior when analyzing signed objects that include multiple publications points. The IETF Secretariat --------------030800020209060209070406 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit FYI,

added new co-author, added empty line between URIs and key.

regards,

~Carlos


-------- Original Message --------
Subject: New Version Notification for draft-rogaglia-sidr-multiple-publication-points-01.txt
Date: Mon, 15 Oct 2012 12:18:24 -0700
From: internet-drafts@ietf.org
To: carlos@lacnic.net
CC: rogaglia@cisco.com, terry.manderson@icann.org 


A new version of I-D, draft-rogaglia-sidr-multiple-publication-points-01.txt
has been successfully submitted by Carlos Martinez and posted to the
IETF repository.

Filename:	 draft-rogaglia-sidr-multiple-publication-points
Revision:	 01
Title:		 Multiple Repository Publication Points support in the Resource Public Key Infrastructure (RPKI)
Creation date:	 2012-10-15
WG ID:		 Individual Submission
Number of pages: 12
URL:             http://www.ietf.org/internet-drafts/draft-rogaglia-sidr-multiple-publication-points-01.txt
Status:          http://datatracker.ietf.org/doc/draft-rogaglia-sidr-multiple-publication-points
Htmlized:        http://tools.ietf.org/html/draft-rogaglia-sidr-multiple-publication-points-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-rogaglia-sidr-multiple-publication-points-01

Abstract:
   The Resource Public Key Infrastructure (RPKI) depends on Relying
   Parties (RP) ability to access its Trust Anchors' certificate
   specified in the different "Trust Anchor Locator (TAL)" files and the
   Repository Objects located at the Certificate Authorities (CA)
   repositories hosted in its respective publication point.  This
   document updates [RFC6490] by allowing multiple URI associated to a
   single public key in a TAL file and introduces the concept of
   multiple repository publication point operators for every CA in the
   RPKI.  This document provides also recommendation for the RP behavior
   when analyzing signed objects that include multiple publications
   points.

                                                                                  


The IETF Secretariat



--------------030800020209060209070406-- From Sandra.Murphy@sparta.com Thu Oct 25 09:46:30 2012 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 44F0E21F8661 for ; Thu, 25 Oct 2012 09:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 2el-23JR2X2n for ; Thu, 25 Oct 2012 09:46:29 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1C28921F86B0 for ; Thu, 25 Oct 2012 09:46:29 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q9PGkReA021636; Thu, 25 Oct 2012 11:46:27 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q9PGkR1W026496; Thu, 25 Oct 2012 11:46:27 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Thu, 25 Oct 2012 12:46:26 -0400 From: "Murphy, Sandra" To: "Carlos M. Martinez" , "sidr@ietf.org" Thread-Topic: [sidr] LACNIC 18 / LACNOG 2012 conference network Thread-Index: AQHNsssK7CrvxQlzXUqE4xgzdqVTSZfKOHh4 Date: Thu, 25 Oct 2012 16:46:26 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6369A2D07@Hermes.columbia.ads.sparta.com> References: <508963F6.1030501@gmail.com> In-Reply-To: <508963F6.1030501@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] LACNIC 18 / LACNOG 2012 conference network 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 Oct 2012 16:46:30 -0000 Congratulations! As far as I know, this makes you the very first network t= o do origin validation with RPKI data.=0A= =0A= I think hearing the details of your experience would be of interest to the = wg. Would it be possible for you to discuss? I realize that your meeting = is the week before IETF, and you might be taking a rest when it is over, bu= t remote presentations are possible. And the sidr session is Friday.=0A= =0A= --Sandy=0A= =0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Carlos M. = Martinez [carlosm3011@gmail.com]=0A= Sent: Thursday, October 25, 2012 12:08 PM=0A= To: sidr@ietf.org=0A= Subject: [sidr] LACNIC 18 / LACNOG 2012 conference network=0A= =0A= Hello,=0A= =0A= We will be running origin validation on our conference routers=0A= (hopefully) starting this Saturday. We have already tested the=0A= configuration in the ISPs testbed and the equipment is currently being=0A= moved to the conference venue.=0A= =0A= We'll be using dual instances of RIPE's validator app as the RTR server.=0A= =0A= For starters we will be accepting invalids anyways (yes, yes, I know :-)=0A= ), but we plan on switching to fully paranoid mode over the week.=0A= =0A= If there is interest in running / performing some experiment(s) we can=0A= talk about it.=0A= =0A= cheers!=0A= =0A= ~Carlos=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From aservin@lacnic.net Thu Oct 25 09:59:09 2012 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 817DF21F8695 for ; Thu, 25 Oct 2012 09:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=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 LFUqoYJw5O-F for ; Thu, 25 Oct 2012 09:59:09 -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 E815D21F8531 for ; Thu, 25 Oct 2012 09:59:08 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (unknown [200.7.85.140]) by mail.lacnic.net.uy (Postfix) with ESMTP id 8D1D0308453 for ; Thu, 25 Oct 2012 14:58:59 -0200 (UYST) Message-ID: <50896FCF.4040604@lacnic.net> Date: Thu, 25 Oct 2012 14:58:55 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: sidr@ietf.org References: <508963F6.1030501@gmail.com> <24B20D14B2CD29478C8D5D6E9CBB29F6369A2D07@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6369A2D07@Hermes.columbia.ads.sparta.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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] LACNIC 18 / LACNOG 2012 conference network 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 Oct 2012 16:59:09 -0000 Carlos and I we will be there in Atlanta and will be happy to talk about the experience. Regards, as On 25/10/2012 14:46, Murphy, Sandra wrote: > Congratulations! As far as I know, this makes you the very first network to do origin validation with RPKI data. > > I think hearing the details of your experience would be of interest to the wg. Would it be possible for you to discuss? I realize that your meeting is the week before IETF, and you might be taking a rest when it is over, but remote presentations are possible. And the sidr session is Friday. > > --Sandy > > > ________________________________________ > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Carlos M. Martinez [carlosm3011@gmail.com] > Sent: Thursday, October 25, 2012 12:08 PM > To: sidr@ietf.org > Subject: [sidr] LACNIC 18 / LACNOG 2012 conference network > > Hello, > > We will be running origin validation on our conference routers > (hopefully) starting this Saturday. We have already tested the > configuration in the ISPs testbed and the equipment is currently being > moved to the conference venue. > > We'll be using dual instances of RIPE's validator app as the RTR server. > > For starters we will be accepting invalids anyways (yes, yes, I know :-) > ), but we plan on switching to fully paranoid mode over the week. > > If there is interest in running / performing some experiment(s) we can > talk about it. > > cheers! > > ~Carlos > _______________________________________________ > 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 carlosm3011@gmail.com Thu Oct 25 10:06:31 2012 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 5CB7421F8592 for ; Thu, 25 Oct 2012 10:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amA0o4SnWV02 for ; Thu, 25 Oct 2012 10:06:30 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B187121F89BC for ; Thu, 25 Oct 2012 10:06:30 -0700 (PDT) Received: by mail-gg0-f172.google.com with SMTP id i4so392663ggn.31 for ; Thu, 25 Oct 2012 10:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=wNBzGMnnCffgvkK2QpkXBCsILaqzw9tq1e6T2jkWo4w=; b=yUdIF32ie3WJ6cn2TxF1SgGQJkwit1hhbMm5wyvT7qKgdhx0DaTU9CBZUBc8XrRxnW iql5JijGpdhrExvjzJwuspRUUhxyOCU4OIUjBLCjE5YTuxMEGpAotF2jldgV/svGON08 sj5ZN7Cg+FjI/q7rvCt/Rq5UIG1ErcM76MYGglfDTDdjIw4xSCFk0scidKFJP8pKjlNX ffWSX62x8k+RI5nWXAz9OBFqXepWhH0Z+rZcog6cqGw0OHz4wPbgvnVNtejaUnMffUdZ NAacT+WBxzg/LuPDws+pCM4nB1+H8dLkyV7rt9ep/o86ZyeZJ1UWNDlclfYmaOWBZHdw LeDQ== Received: by 10.236.151.99 with SMTP id a63mr19934711yhk.120.1351184790240; Thu, 25 Oct 2012 10:06:30 -0700 (PDT) Received: from europa.local ([2001:13c7:7001:2128:b86d:fd23:db09:e494]) by mx.google.com with ESMTPS id x6sm16469313anj.19.2012.10.25.10.06.28 (version=SSLv3 cipher=OTHER); Thu, 25 Oct 2012 10:06:29 -0700 (PDT) Message-ID: <50897192.8070105@gmail.com> Date: Thu, 25 Oct 2012 15:06:26 -0200 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Murphy, Sandra" References: <508963F6.1030501@gmail.com> <24B20D14B2CD29478C8D5D6E9CBB29F6369A2D07@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6369A2D07@Hermes.columbia.ads.sparta.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org" Subject: Re: [sidr] LACNIC 18 / LACNOG 2012 conference network 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 Oct 2012 17:06:31 -0000 Sandy, Arturo and I will be in ATL, so yes, we could have a little chat about the experiencie. So far, the outcomes I see as possible are: - Everything crashes down on Sunday/Monday and we have to disable OV (I don't really think this will happen, but ya never know :-) - We find software instabilities on part of the validators, or on the router platform requiring significant operator support to keep OV running. - Users complaints that can be traced back to invalids being dropped (staring Tuesday probably) - Nothing happens (AKA World IPv6 Day Effect) We currently have 450 registered participants, although from past experience we know that about 70% - 80% will actually show up. Also from past experience we expect people to use about 1.5 IP addresses per attendee. The conference AS is 28002, and we are currently announcing 190.64.16.0/22, 190.64.20.0/24 (sub allocated from ANTEL Uruguay) and 2001:13c7:7003::/48 (from our own allocations). We created the ROAs for the IPv6 block and ANTEL Uruguay created the ROAs for the sub-allocated blocks. Warm regards, ~Carlos On 10/25/12 2:46 PM, Murphy, Sandra wrote: > Congratulations! As far as I know, this makes you the very first network to do origin validation with RPKI data. > > I think hearing the details of your experience would be of interest to the wg. Would it be possible for you to discuss? I realize that your meeting is the week before IETF, and you might be taking a rest when it is over, but remote presentations are possible. And the sidr session is Friday. > > --Sandy > > > ________________________________________ > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Carlos M. Martinez [carlosm3011@gmail.com] > Sent: Thursday, October 25, 2012 12:08 PM > To: sidr@ietf.org > Subject: [sidr] LACNIC 18 / LACNOG 2012 conference network > > Hello, > > We will be running origin validation on our conference routers > (hopefully) starting this Saturday. We have already tested the > configuration in the ISPs testbed and the equipment is currently being > moved to the conference venue. > > We'll be using dual instances of RIPE's validator app as the RTR server. > > For starters we will be accepting invalids anyways (yes, yes, I know :-) > ), but we plan on switching to fully paranoid mode over the week. > > If there is interest in running / performing some experiment(s) we can > talk about it. > > cheers! > > ~Carlos > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From Sandra.Murphy@sparta.com Thu Oct 25 10:14:15 2012 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 BE3FF21F8847 for ; Thu, 25 Oct 2012 10:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 TsS4qVa0yqlJ for ; Thu, 25 Oct 2012 10:14:15 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD7F21F8695 for ; Thu, 25 Oct 2012 10:14:15 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q9PHEDHD021990; Thu, 25 Oct 2012 12:14:13 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q9PHEDrW027355; Thu, 25 Oct 2012 12:14:13 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Thu, 25 Oct 2012 13:14:07 -0400 From: "Murphy, Sandra" To: "Carlos M. Martinez" Thread-Topic: [sidr] LACNIC 18 / LACNOG 2012 conference network Thread-Index: AQHNsssK7CrvxQlzXUqE4xgzdqVTSZfKOHh4gABLIgD//77M0g== Date: Thu, 25 Oct 2012 17:14:06 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6369A2D58@Hermes.columbia.ads.sparta.com> References: <508963F6.1030501@gmail.com> <24B20D14B2CD29478C8D5D6E9CBB29F6369A2D07@Hermes.columbia.ads.sparta.com>, <50897192.8070105@gmail.com> In-Reply-To: <50897192.8070105@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] LACNIC 18 / LACNOG 2012 conference network 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 Oct 2012 17:14:15 -0000 Every possible outcome would be interesting. Just what you used, what/how = you set up,=0A= =0A= And of course anything missing in specs that the wg should address.=0A= =0A= --Sandy=0A= =0A= =0A= ________________________________________=0A= From: Carlos M. Martinez [carlosm3011@gmail.com]=0A= Sent: Thursday, October 25, 2012 1:06 PM=0A= To: Murphy, Sandra=0A= Cc: sidr@ietf.org=0A= Subject: Re: [sidr] LACNIC 18 / LACNOG 2012 conference network=0A= =0A= Sandy,=0A= =0A= Arturo and I will be in ATL, so yes, we could have a little chat about=0A= the experiencie.=0A= =0A= So far, the outcomes I see as possible are:=0A= =0A= - Everything crashes down on Sunday/Monday and we have to disable OV (I=0A= don't really think this will happen, but ya never know :-)=0A= =0A= - We find software instabilities on part of the validators, or on the=0A= router platform requiring significant operator support to keep OV running.= =0A= =0A= - Users complaints that can be traced back to invalids being dropped=0A= (staring Tuesday probably)=0A= =0A= - Nothing happens (AKA World IPv6 Day Effect)=0A= =0A= We currently have 450 registered participants, although from past=0A= experience we know that about 70% - 80% will actually show up. Also from=0A= past experience we expect people to use about 1.5 IP addresses per attendee= .=0A= =0A= The conference AS is 28002, and we are currently announcing=0A= 190.64.16.0/22, 190.64.20.0/24 (sub allocated from ANTEL Uruguay) and=0A= 2001:13c7:7003::/48 (from our own allocations). We created the ROAs for=0A= the IPv6 block and ANTEL Uruguay created the ROAs for the sub-allocated=0A= blocks.=0A= =0A= Warm regards,=0A= =0A= ~Carlos=0A= =0A= On 10/25/12 2:46 PM, Murphy, Sandra wrote:=0A= > Congratulations! As far as I know, this makes you the very first network= to do origin validation with RPKI data.=0A= >=0A= > I think hearing the details of your experience would be of interest to th= e wg. Would it be possible for you to discuss? I realize that your meetin= g is the week before IETF, and you might be taking a rest when it is over, = but remote presentations are possible. And the sidr session is Friday.=0A= >=0A= > --Sandy=0A= >=0A= >=0A= > ________________________________________=0A= > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Carlos M= . Martinez [carlosm3011@gmail.com]=0A= > Sent: Thursday, October 25, 2012 12:08 PM=0A= > To: sidr@ietf.org=0A= > Subject: [sidr] LACNIC 18 / LACNOG 2012 conference network=0A= >=0A= > Hello,=0A= >=0A= > We will be running origin validation on our conference routers=0A= > (hopefully) starting this Saturday. We have already tested the=0A= > configuration in the ISPs testbed and the equipment is currently being=0A= > moved to the conference venue.=0A= >=0A= > We'll be using dual instances of RIPE's validator app as the RTR server.= =0A= >=0A= > For starters we will be accepting invalids anyways (yes, yes, I know :-)= =0A= > ), but we plan on switching to fully paranoid mode over the week.=0A= >=0A= > If there is interest in running / performing some experiment(s) we can=0A= > talk about it.=0A= >=0A= > cheers!=0A= >=0A= > ~Carlos=0A= > _______________________________________________=0A= > sidr mailing list=0A= > sidr@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/sidr=0A= >=0A= From randy@psg.com Thu Oct 25 10:17:53 2012 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 CC14D21F899B for ; Thu, 25 Oct 2012 10:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 yZsKmQda4H-V for ; Thu, 25 Oct 2012 10:17:53 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 05D8521F8893 for ; Thu, 25 Oct 2012 10:17:53 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TRR40-0005X0-VE; Thu, 25 Oct 2012 17:17:49 +0000 Date: Thu, 25 Oct 2012 10:17:45 -0700 Message-ID: From: Randy Bush To: "Murphy, Sandra" In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6369A2D07@Hermes.columbia.ads.sparta.com> References: <508963F6.1030501@gmail.com> <24B20D14B2CD29478C8D5D6E9CBB29F6369A2D07@Hermes.columbia.ads.sparta.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org" Subject: Re: [sidr] LACNIC 18 / LACNOG 2012 conference network 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 Oct 2012 17:17:53 -0000 > Congratulations! As far as I know, this makes you the very first > network to do origin validation with RPKI data. possibly as far as you know. but not true. a bunch of stubs, like conferences and other more stable stubs, have and continue to run cisco and juniper origin validation implementstions against various caches, ncc's, rpki.net, etc. i do not know of any transit backbone routers running origin validations, though euro-transit might be. randy From Sandra.Murphy@sparta.com Thu Oct 25 11:21:43 2012 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 7455221F86F6 for ; Thu, 25 Oct 2012 11:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 3PFmMUIecREh for ; Thu, 25 Oct 2012 11:21:40 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2715121F8661 for ; Thu, 25 Oct 2012 11:21:39 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q9PILdhD022912; Thu, 25 Oct 2012 13:21:39 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q9PILdqT029720; Thu, 25 Oct 2012 13:21:39 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Thu, 25 Oct 2012 14:21:35 -0400 From: "Murphy, Sandra" To: Randy Bush Thread-Topic: [sidr] LACNIC 18 / LACNOG 2012 conference network Thread-Index: AQHNsssK7CrvxQlzXUqE4xgzdqVTSZfKOHh4gABOS4D//8yyZg== Date: Thu, 25 Oct 2012 18:21:34 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6369A2D98@Hermes.columbia.ads.sparta.com> References: <508963F6.1030501@gmail.com> <24B20D14B2CD29478C8D5D6E9CBB29F6369A2D07@Hermes.columbia.ads.sparta.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] LACNIC 18 / LACNOG 2012 conference network 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 Oct 2012 18:21:43 -0000 =0A= >> Congratulations! As far as I know, this makes you the very first=0A= >> network to do origin validation with RPKI data.=0A= >=0A= >possibly as far as you know. but not true. =0A= =0A= Exactly why I phrased that as I did. Congrats are still due.=0A= =0A= >a bunch of stubs, like=0A= >conferences and other more stable stubs, have and continue to run cisco=0A= >and juniper origin validation implementstions against various caches,=0A= >ncc's, rpki.net, etc.=0A= >=0A= >i do not know of any transit backbone routers running origin=0A= 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 49EAC21F845E for ; Fri, 26 Oct 2012 06:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cnd1OU+MDXCk for ; Fri, 26 Oct 2012 06:30:46 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA9A21F845C for ; Fri, 26 Oct 2012 06:30:46 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TRjzm-0005rY-IU; Fri, 26 Oct 2012 15:30:44 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=[IPv6:::1]) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1TRjzm-0003Ch-6m; Fri, 26 Oct 2012 15:30:42 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_9FEAA4A5-931E-4ED5-974F-D84A06E3BCFC" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Bruijnzeels In-Reply-To: <50896439.8080803@gmail.com> Date: Fri, 26 Oct 2012 15:30:43 +0200 Message-Id: <09EE26F8-35B6-46A9-91E7-F36E553F9A13@ripe.net> References: <20121015191824.4680.48268.idtracker@ietfa.amsl.com> <50896439.8080803@gmail.com> To: Carlos M. Martinez X-Mailer: Apple Mail (2.1499) X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20121026 clean X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.6 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719dc2661638b41b829b367bc82b7b1b22b Cc: "sidr@ietf.org" Subject: Re: [sidr] New Version Notification for draft-rogaglia-sidr-multiple-publication-points-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: Fri, 26 Oct 2012 13:30:47 -0000 --Apple-Mail=_9FEAA4A5-931E-4ED5-974F-D84A06E3BCFC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Carlos, WG, I like the idea, but I think 4.1 (Rules for Relying Parties) needs more = work. I will try to come up with some text from my perspective. Tim On Oct 25, 2012, at 6:09 PM, Carlos M. Martinez = wrote: > FYI, >=20 > added new co-author, added empty line between URIs and key. >=20 > regards, >=20 > ~Carlos >=20 >=20 > -------- Original Message -------- > Subject: New Version Notification for = draft-rogaglia-sidr-multiple-publication-points-01.txt > Date: Mon, 15 Oct 2012 12:18:24 -0700 > From: internet-drafts@ietf.org > To: carlos@lacnic.net > CC: rogaglia@cisco.com, terry.manderson@icann.org >=20 > A new version of I-D, = draft-rogaglia-sidr-multiple-publication-points-01.txt > has been successfully submitted by Carlos Martinez and posted to the > IETF repository. >=20 > Filename: draft-rogaglia-sidr-multiple-publication-points > Revision: 01 > Title: Multiple Repository Publication Points support = in the Resource Public Key Infrastructure (RPKI) > Creation date: 2012-10-15 > WG ID: Individual Submission > Number of pages: 12 > URL: = http://www.ietf.org/internet-drafts/draft-rogaglia-sidr-multiple-publicati= on-points-01.txt > Status: = http://datatracker.ietf.org/doc/draft-rogaglia-sidr-multiple-publication-p= oints > Htmlized: = http://tools.ietf.org/html/draft-rogaglia-sidr-multiple-publication-points= -01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-rogaglia-sidr-multiple-publicatio= n-points-01 >=20 > Abstract: > The Resource Public Key Infrastructure (RPKI) depends on Relying > Parties (RP) ability to access its Trust Anchors' certificate > specified in the different "Trust Anchor Locator (TAL)" files and = the > Repository Objects located at the Certificate Authorities (CA) > repositories hosted in its respective publication point. This > document updates [RFC6490] by allowing multiple URI associated to a > single public key in a TAL file and introduces the concept of > multiple repository publication point operators for every CA in the > RPKI. This document provides also recommendation for the RP = behavior > when analyzing signed objects that include multiple publications > points. >=20 > = =20 >=20 >=20 > The IETF Secretariat >=20 >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_9FEAA4A5-931E-4ED5-974F-D84A06E3BCFC Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi Carlos, WG,

I like the idea, but I think 4.1 (Rules for Relying Parties) needs more work. I will try to come up with some text from my perspective.

Tim



On Oct 25, 2012, at 6:09 PM, Carlos M. Martinez <carlosm3011@gmail.com> wrote:

FYI,

added new co-author, added empty line between URIs and key.

regards,

~Carlos


-------- Original Message --------
Subject: New Version Notification for draft-rogaglia-sidr-multiple-publication-points-01.txt
Date: Mon, 15 Oct 2012 12:18:24 -0700
From: internet-drafts@ietf.org
To: carlos@lacnic.net
CC: rogaglia@cisco.com, terry.manderson@icann.org 


A new version of I-D, draft-rogaglia-sidr-multiple-publication-points-01.txt
has been successfully submitted by Carlos Martinez and posted to the
IETF repository.

Filename:	 draft-rogaglia-sidr-multiple-publication-points
Revision:	 01
Title:		 Multiple Repository Publication Points support in the Resource Public Key Infrastructure (RPKI)
Creation date:	 2012-10-15
WG ID:		 Individual Submission
Number of pages: 12
URL:             http://www.ietf.org/internet-drafts/draft-rogaglia-sidr-multiple-publication-points-01.txt
Status:          http://datatracker.ietf.org/doc/draft-rogaglia-sidr-multiple-publication-points
Htmlized:        http://tools.ietf.org/html/draft-rogaglia-sidr-multiple-publication-points-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-rogaglia-sidr-multiple-publication-points-01

Abstract:
   The Resource Public Key Infrastructure (RPKI) depends on Relying
   Parties (RP) ability to access its Trust Anchors' certificate
   specified in the different "Trust Anchor Locator (TAL)" files and the
   Repository Objects located at the Certificate Authorities (CA)
   repositories hosted in its respective publication point.  This
   document updates [RFC6490] by allowing multiple URI associated to a
   single public key in a TAL file and introduces the concept of
   multiple repository publication point operators for every CA in the
   RPKI.  This document provides also recommendation for the RP behavior
   when analyzing signed objects that include multiple publications
   points.

                                                                                  


The IETF Secretariat



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

--Apple-Mail=_9FEAA4A5-931E-4ED5-974F-D84A06E3BCFC--