From timbru@ripe.net Sat Oct 1 02:39:34 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B2C21F8AA9 for ; Sat, 1 Oct 2011 02:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PExSR0NfYmPJ for ; Sat, 1 Oct 2011 02:39:33 -0700 (PDT) Received: from beaver.ripe.net (beaver.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:131d]) by ietfa.amsl.com (Postfix) with ESMTP id 48E5E21F8906 for ; Sat, 1 Oct 2011 02:39:33 -0700 (PDT) Received: from [2001:67c:2e8:11::c100:1356] (helo=pony.ripe.net) by beaver.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1R9w5Q-0000s1-S7; Sat, 01 Oct 2011 11:42:25 +0200 Received: from apache by pony.ripe.net with local (Exim 4.63) (envelope-from ) id 1R9w5Q-0008EW-Ho; Sat, 01 Oct 2011 11:42:24 +0200 Received: from 80.57.195.122 (SquirrelMail authenticated user timbru) by webmail.ripe.net with HTTP; Sat, 1 Oct 2011 11:42:24 +0200 (CEST) Message-ID: <49638.80.57.195.122.1317462144.squirrel@webmail.ripe.net> Date: Sat, 1 Oct 2011 11:42:24 +0200 (CEST) From: timbru@ripe.net To: randy@psg.com, sra@hactrn.net User-Agent: SquirrelMail/1.4.8-5.el5.centos.10 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: sidr@ietf.org Subject: [sidr] some comments and questions regarding rpki-rtr X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2011 09:55:45 -0000 Hi Randy, Rob, wg, We have been working on rpki-rtr support in our validator at RIPE NCC over the past weeks. I found the 6.x sections describing typical scenario exchanges particularly useful. I have read the document in the past as well, but as we all know: with actual implementation come actual questions... so I have a couple: A = No changes B = Nonce and cache reset C = Duplicate announcements / withdrawals D = Keep alive timeout E = Cache shutdown A = No changes ============= So if I read 5.2 correctly the cache should respond with just 1 end-of-data pdu if there are no updates since the serial included in a serial request. But if read 5.4 I can also interpret this that we should respond with 2 pdus: 1 cache response, 0 data records, 1 end-of-data Can you please tell me which is correct? Like this? Cache Router ~ ~ | <----- Serial Query ------- | R requests data | | | ----- Cache Response -----> | C confirms request | ------ End of Data ------> | C sends End of Data | | and sends *same* serial ~ ~ This is what we are doing now.. In any case I think it would be useful to have this somewhere in 6.2, or a separate 6.x section. B = Nonce and cache reset ===================== When I read 5.10 the nonce is generated when the cache starts. And reading 6.3 the cache may send a cache reset reply to the client when there are no incremental updates available. Does this imply that a new cache nonce should be generated? I assumed that it did not. The nonce is made when the process starts. So when a client sends a reset query the same nonce may be kept. The client just gets a new, full, data set, up to the current serial for that same nonce. If not, then we would have to keep track of nonce-s and serials for each connected child, or reset them all.. I am afraid that would not scale very well. Part of the reason I am asking is that we are currently not yet able to send incremental updates. So our cache always replies as described in 6.3. We are not resetting the nonce though, and we are seeing duplicate announcement errors from the routers. So: is our cache wrong not to reset the nonce? Can section 6.3 be amended to be explicit about this? C = Duplicate announcements / withdrawals =================================== As described in 5.5: The cache server MUST ensure that it has told the router client to have one and only one IPvX PDU for a unique {prefix, len, max-len, asn} at any one point in time. So this means that cache should exclude duplicates in a full update even if the same unique {prefix, len, max-len, asn} exists more than once (same ROA, multiple prefixes, or different ROAs). I probably missed the discussion on this, but can you explain why this is? I don't see a conflict. If I get the same announce twice, it's still just announce? I am also wondering what this means wrt serial updates. Let me clarify by example: 10/16 is announced in serial 2, withdrawn in 3, announced again in 4. The router has serial 1. Should the cache then work out the exact delta between 1 and 4, or can it send 1-2, followed by 2-3, followed by 3-4. I can imagine that from the routers perspective it's very useful if the cache takes care of duplicates and sends just one big delta, and not the full history since the router last asked. I am afraid though, that this may cause scaling issues when a potentially large number of routers use the same cache (cpu), or a large number of pre-computed deltas need to be kept (memory). I think that if this responsibility were just handled by the routers we would have much better scaling on the cache side, and it would be much easier for caches to keep incremental updates without having to resort to no-incremental-updates like 6.3 describes. D = Keep alive timeout =============== As described in 6.1: To limit the length of time a cache must keep the data necessary to generate incremental updates, a router MUST send either a Serial Query or a Reset Query no less frequently than once an hour. This also acts as a keep alive at the application layer. So, we have interpreted this to say that it's probably good on our side to drop the connection after 1 hour. It's must likely dead and we want our resource back... When we do this, do you think it would be good if we tried to send an error pdu just before closure? With a new error code indicating session timeout? E = Cache shutdown ============== When the cache is stopped for whatever reason. Server restart, cache had irrecoverable internal error, anything else... Should we send a new type of notify / error (with new specific code) to all children so that they can gracefully switch over to another cache -- or wait until we are back? Or should we just close the connections? Thanks, Tim PS: If you are a rpki-rtr router implementer and you want to do interop testing with us: please contact me. From sra@hactrn.net Sat Oct 1 09:06:39 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3779821F947E for ; Sat, 1 Oct 2011 09:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.4 X-Spam-Level: X-Spam-Status: No, score=-102.4 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxKHEemVmwsq for ; Sat, 1 Oct 2011 09:06:38 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by ietfa.amsl.com (Postfix) with ESMTP id 272C821F9483 for ; Sat, 1 Oct 2011 09:06:34 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 4123F2845C; Sat, 1 Oct 2011 16:09:22 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id F10A31704E; Sat, 1 Oct 2011 12:09:21 -0400 (EDT) Date: Sat, 01 Oct 2011 12:09:21 -0400 From: Rob Austein To: Tim Bruijnzeels In-Reply-To: <49638.80.57.195.122.1317462144.squirrel@webmail.ripe.net> References: <49638.80.57.195.122.1317462144.squirrel@webmail.ripe.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/23.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20111001160921.F10A31704E@thrintun.hactrn.net> Cc: sidr@ietf.org Subject: Re: [sidr] some comments and questions regarding rpki-rtr X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2011 16:06:39 -0000 At Sat, 1 Oct 2011 11:42:24 +0200 (CEST), Tim Bruijnzeels wrote: > > A = No changes > ============= > So if I read 5.2 correctly the cache should respond with just 1 > end-of-data pdu if there are no updates since the serial included in a > serial request. > But if read 5.4 I can also interpret this that we should respond with 2 > pdus: 1 cache response, 0 data records, 1 end-of-data > > Can you please tell me which is correct? The intent is to send an empty update, ie, a normal update that happens to have no data records because nothing has changed. So it should be cache response followed by end of data. > Like this? > > Cache Router > ~ ~ > | <----- Serial Query ------- | R requests data > | | > | ----- Cache Response -----> | C confirms request > | ------ End of Data ------> | C sends End of Data > | | and sends *same* serial > ~ ~ Yes. This is what my implementation does. > B = Nonce and cache reset > ===================== > > When I read 5.10 the nonce is generated when the cache starts. And reading > 6.3 the cache may send a cache reset reply to the client when there are no > incremental updates available. > > Does this imply that a new cache nonce should be generated? No. Server should generate a new nonce if and only if the serial numbers it has been using up until now have become meaningless (technical term used in the draft is "commensurate" -- nonce changes when something happens that prevents serial numbers before and after the event from being "commensurate", ie, measuring the same thing). The cache nonce is really a light-weight session identifier. Generating a new nonce is equivalent to terminating any existing sessions that were using the old nonce. Serial numbers are not meaningful across sessions, so serial query across a nonce change is not possible, router must do a cache reset. > I assumed that it did not. The nonce is made when the process starts. So > when a client sends a reset query the same nonce may be kept. The client > just gets a new, full, data set, up to the current serial for that same > nonce. The server doesn't even have to generate a new nonce when it starts, so long as the serial numbers are still commensurate. My server generates a new nonce when it starts up if and only if it has no record of what nonce and serial numbers it was using when it was last running. > Part of the reason I am asking is that we are currently not yet able to > send incremental updates. So our cache always replies as described in 6.3. > We are not resetting the nonce though, and we are seeing duplicate > announcement errors from the routers. You should not need to reset the nonce unless something has whacked the serial numbers. At least one of the router images currently under test is known to generate spurious complaints about duplicate announcements, that may be what you're seeing. Check with whoever got you that image. > C = Duplicate announcements / withdrawals > =================================== > > As described in 5.5: > The cache server MUST ensure that it has told the router client to > have one and only one IPvX PDU for a unique {prefix, len, max-len, > asn} at any one point in time. > > So this means that cache should exclude duplicates in a full update even > if the same unique {prefix, len, max-len, asn} exists more than once (same > ROA, multiple prefixes, or different ROAs). > > I probably missed the discussion on this, but can you explain why this is? > I don't see a conflict. If I get the same announce twice, it's still just > announce? I don't entirely get the urgency behind this one myself, but my understanding is that Randy and the router guys were concerned that duplicates meant that the router and cache disagreed on current state, therefore duplicates were an indication that something is wrong. > I am also wondering what this means wrt serial updates. Let me clarify by > example: 10/16 is announced in serial 2, withdrawn in 3, announced again > in 4. The router has serial 1. Should the cache then work out the exact > delta between 1 and 4, or can it send 1-2, followed by 2-3, followed by > 3-4. I work out the exact delta. It's not that hard, just a bit tedious, and I pre-compute it once when new updates come in from my validation code rather than doing it on the fly in the server. > I am afraid though, that this may cause scaling issues when a potentially > large number of routers use the same cache (cpu), or a large number of > pre-computed deltas need to be kept (memory). I think that if this > responsibility were just handled by the routers we would have much better > scaling on the cache side, and it would be much easier for caches to keep > incremental updates without having to resort to no-incremental-updates > like 6.3 describes. Well, it's not necessarily memory. I keep the pre-computed deltas on disk. How much data that works out to be depends on how far back one is willing to keep the deltas. The general assumption, though, is that servers are cheaper than routers. Server for this protocol can be a 600 USD 1U BSD or Linux box; my understanding is that you're not likely to find serious routers in that price range anytime soon. :) Also, routers are supposed to spend their time moving packets, not performing unnecessarily complex internal database manipulations. So anything we can do on the server to make the router code simpler is probably a win for the operator who has to pay for all this kit. > D = Keep alive timeout > =============== > > As described in 6.1: > To limit the length of time a cache must keep the data necessary to > generate incremental updates, a router MUST send either a Serial > Query or a Reset Query no less frequently than once an hour. This > also acts as a keep alive at the application layer. > > So, we have interpreted this to say that it's probably good on our side to > drop the connection after 1 hour. It's must likely dead and we want our > resource back... > > When we do this, do you think it would be good if we tried to send an > error pdu just before closure? With a new error code indicating session > timeout? Um, the error PDU would almost certainly not get through, pretty much by definition, because if all is well we would be seeing serial or reset queries before the keep alive timer expires. > E = Cache shutdown > ============== > > When the cache is stopped for whatever reason. Server restart, cache had > irrecoverable internal error, anything else... > > Should we send a new type of notify / error (with new specific code) to > all children so that they can gracefully switch over to another cache -- > or wait until we are back? > > Or should we just close the connections? I think just closing connections is sufficient. Router has to cope with connection just closing, what would it do differently here? From internet-drafts@ietf.org Sat Oct 1 09:39:59 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD2721F93B1; Sat, 1 Oct 2011 09:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjFGRyTNQJPU; Sat, 1 Oct 2011 09:39:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF1321F939C; Sat, 1 Oct 2011 09:39:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111001163959.11213.35009.idtracker@ietfa.amsl.com> Date: Sat, 01 Oct 2011 09:39:59 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-17.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2011 16:39:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : The RPKI/Router Protocol Author(s) : Randy Bush Rob Austein Filename : draft-ietf-sidr-rpki-rtr-17.txt Pages : 25 Date : 2011-10-01 In order to formally validate the origin ASs of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-17.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-17.txt From randy@psg.com Sat Oct 1 09:59:12 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CE321F913D for ; Sat, 1 Oct 2011 09:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8F460bsYkhp for ; Sat, 1 Oct 2011 09:59:11 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id BB98121F9134 for ; Sat, 1 Oct 2011 09:59:08 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RA2wt-0007RL-Ry; Sat, 01 Oct 2011 17:02:04 +0000 Date: Sun, 02 Oct 2011 02:02:02 +0900 Message-ID: From: Randy Bush To: Tim Bruijnzeels In-Reply-To: <49638.80.57.195.122.1317462144.squirrel@webmail.ripe.net> References: <49638.80.57.195.122.1317462144.squirrel@webmail.ripe.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] some comments and questions regarding rpki-rtr X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2011 16:59:12 -0000 > So if I read 5.2 correctly the cache should respond with just 1 > end-of-data pdu if there are no updates since the serial included in a > serial request. > But if read 5.4 I can also interpret this that we should respond with 2 > pdus: 1 cache response, 0 data records, 1 end-of-data i added a hammer to 5.2. it now says The cache replies to this query with a Cache Response PDU (Section 5.4) if the cache has a, possibly null, record of the changes since the serial number specified by the router. If there have been no changes since the router last queried, the cache then sends an End Of Data PDU. > When I read 5.10 the nonce is generated when the cache starts. And reading > 6.3 the cache may send a cache reset reply to the client when there are no > incremental updates available. while it certainly may send a cache reset, i recommend it not. the reset is not a normal condition. read the text The cache may respond to a Serial Query with a Cache Reset, informing the router that the cache cannot supply an incremental update from the serial number specified by the router. This might be because the cache has lost state, or because the router has waited too long between polls and the cache has cleaned up old data that it no longer believes it needs, or because the cache has run out of storage space and had to expire some old data early. > Does this imply that a new cache nonce should be generated? no it does not > The nonce is made when the process starts. So when a client sends a > reset query the same nonce may be kept. The client just gets a new, > full, data set, up to the current serial for that same nonce. yes > If not, then we would have to keep track of nonce-s and serials for each > connected child if you could keep track of serial and nonces, then we would not need nonces. > As described in 5.5: > The cache server MUST ensure that it has told the router client to > have one and only one IPvX PDU for a unique {prefix, len, max-len, > asn} at any one point in time. > > So this means that cache should exclude duplicates in a full update > even if the same unique {prefix, len, max-len, asn} exists more than > once (same ROA, multiple prefixes, or different ROAs). i was fine until that last parenthetical. i simply do not understand it. > I probably missed the discussion on this, but can you explain why this > is? relieve the router of baroque checks involving counting of announces and withdraws. > I don't see a conflict. If I get the same announce twice, it's still > just announce? is it? or is it two roas? how many withdraws to remove it? > I am also wondering what this means wrt serial updates. Let me clarify > by example: 10/16 is announced in serial 2, withdrawn in 3, announced > again in 4. The router has serial 1. Should the cache then work out > the exact delta between 1 and 4, or can it send 1-2, followed by 2-3, > followed by 3-4. it can do either. i recommend the former. > I can imagine that from the routers perspective it's very useful if > the cache takes care of duplicates and sends just one big delta, and > not the full history since the router last asked. yep > I am afraid though, that this may cause scaling issues when a > potentially large number of routers use the same cache (cpu), or a > large number of pre-computed deltas need to be kept (memory). I think > that if this responsibility were just handled by the routers we would > have much better scaling on the cache side, and it would be much > easier for caches to keep incremental updates without having to resort > to no-incremental-updates like 6.3 describes. routers cost many hundreds of thousands of euros, have five year old cpus in the control plane, and are supposed to be moving packets. when it comes to a question of who does the extra work, guess who wins. > As described in 6.1: > To limit the length of time a cache must keep the data necessary to > generate incremental updates, a router MUST send either a Serial > Query or a Reset Query no less frequently than once an hour. This > also acts as a keep alive at the application layer. > > So, we have interpreted this to say that it's probably good on our > side to drop the connection after 1 hour. It's must likely dead and we > want our resource back... otoh you might think that the client might have been otherwise occupied and be patient for some amount of time. your choice. > When we do this, do you think it would be good if we tried to send an > error pdu just before closure? With a new error code indicating > session timeout? we have avoided asynchronous pdus from the cache. > When the cache is stopped for whatever reason. Server restart, cache had > irrecoverable internal error, anything else... > > Should we send a new type of notify / error (with new specific code) to > all children so that they can gracefully switch over to another cache -- > or wait until we are back? > > Or should we just close the connections? we have avoided asynchronous pdus from the cache. a client will see the close or an error when they next send a query. randy From Sandra.Murphy@cobham.com Mon Oct 3 01:51:31 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4778021F8AF8 for ; Mon, 3 Oct 2011 01:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.222 X-Spam-Level: X-Spam-Status: No, score=-102.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taMTXgdk3ke2 for ; Mon, 3 Oct 2011 01:51:30 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 46F8121F8B09 for ; Mon, 3 Oct 2011 01:51:29 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p938sSt7029715; Mon, 3 Oct 2011 03:54:28 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p938sS9b020440; Mon, 3 Oct 2011 03:54:28 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([192.168.0.104]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 04:54:27 -0400 Date: Mon, 3 Oct 2011 04:54:26 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Randy Bush In-Reply-To: Message-ID: References: <20110930101754.GB10004@juniper.net> <20110930122831.GA10176@juniper.net> <3B65FD95-2E66-4D1F-B630-976ECE99050A@ericsson.com> <7309FCBCAE981B43ABBE69B31C8D213914A3308B30@EUSAACMS0701.eamcs.ericsson.se> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 03 Oct 2011 08:54:27.0982 (UTC) FILETIME=[0ECFBAE0:01CC81AA] Cc: sidr wg list Subject: Re: [sidr] is a longer announce invalid or not found? X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 03 Oct 2011 08:51:31 -0000 speaking as a regular ol' member On Sat, 1 Oct 2011, Randy Bush wrote: >>> cool hack 14.3: the router itself can gen the public/private key pair >>> a la ssh, the person configuring can extract the public key and send >>> it to the rpki goddesses to be signed by the appropriate cert and put >>> in the rpki. the private key never leaves the router! >> I believe that Steve Kent says that usually a certificate request is >> required to present Proof Of Possession (of the private key). So just >> discovering the public key somehow would not be sufficient to be able >> to request a cert with that public key. > > dear dr nit pick, > > when dealing with goddesses, one always frames things as a request I am not at all sure what you mean. Cautiously, I'll try to say what I meant again. You say "the person configuring" could extract the public key and get a cert created for that public key. The request would have to be accompanied by Proof of Possesssion of the private key - e.g., something like a signature might do. Unless the "person configuring" has access to the private key on the router, there would be no way to produce the Proof of Possession. I read what you were suggesting as the customer router gen-ing the key pair and the "person configuring" sitting at the provider, off-router. Maybe you meant the provider was doing the configuration of the customer router, in which case the provider would have access to the private key for the proof of possession for the request. (Of course, if the provider has that much access to the customer router, the line blurs between the key-gen-ing happening on the provider side or the customer side.) --Sandy, speaking as regular ol' member > > randy > From randy@psg.com Mon Oct 3 02:03:52 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2087221F8AD8 for ; Mon, 3 Oct 2011 02:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrhnYnJ4hWJl for ; Mon, 3 Oct 2011 02:03:51 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id B98ED21F8AC9 for ; Mon, 3 Oct 2011 02:03:51 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RAeU8-000CkS-MI; Mon, 03 Oct 2011 09:06:52 +0000 Date: Mon, 03 Oct 2011 18:06:51 +0900 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: References: <20110930101754.GB10004@juniper.net> <20110930122831.GA10176@juniper.net> <3B65FD95-2E66-4D1F-B630-976ECE99050A@ericsson.com> <7309FCBCAE981B43ABBE69B31C8D213914A3308B30@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] is a longer announce invalid or not found? X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 03 Oct 2011 09:03:52 -0000 you don't think a router can sign a pks42 or whatever request without the private key leaving the router? or is it that, as a plain old wg member, are you really asking for an email beating this into the ground with every twitch specified to the finest detail? randy From tim@ripe.net Mon Oct 3 02:15:38 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434F621F8B01 for ; Mon, 3 Oct 2011 02:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KY4wql+9dZj9 for ; Mon, 3 Oct 2011 02:15:37 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 5C54921F8AF9 for ; Mon, 3 Oct 2011 02:15:37 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RAefV-0001hC-4Q; Mon, 03 Oct 2011 11:18:38 +0200 Received: from timbru.vpn.ripe.net ([193.0.21.62]) by ayeaye.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1RAefU-0004An-TL; Mon, 03 Oct 2011 11:18:36 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: Date: Mon, 3 Oct 2011 11:18:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <49638.80.57.195.122.1317462144.squirrel@webmail.ripe.net> To: Randy Bush X-Mailer: Apple Mail (2.1084) X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.4 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.5 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] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071987821b0be669947e1fdf55a511bfd8ae Cc: sidr wg list , Tim Bruijnzeels Subject: Re: [sidr] some comments and questions regarding rpki-rtr X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 09:15:38 -0000 Randy, Rob, thank you both for your explanations. regarding my questions > A =3D No changes > B =3D Nonce and cache reset I think that reading your responses we were on the right track, but I = wasn't 100% sure. I am happy to see your responses confirming this. > C =3D Duplicate announcements / withdrawals Points taken about difficulty on client to know how many withdrawals it = would take to negate an announce seen more than once ;and that = computational power being lots cheaper on the box running the validator = (compared to routers) > D =3D Keep alive timeout > E =3D Cache shutdown I wasn't sure about these, but I am not particularly looking for extra = complexity. If just closing the channel is okay, that's what we'll do. = We'll probably up the time-out threshold a bit (say 90 mins) to avoid = cutting the connection on a client router the minute before it would = send another serial. Thanks, Tim From Sandra.Murphy@cobham.com Mon Oct 3 04:15:08 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3722721F8B14 for ; Mon, 3 Oct 2011 04:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.233 X-Spam-Level: X-Spam-Status: No, score=-102.233 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSvGGI4-Wjrx for ; Mon, 3 Oct 2011 04:15:07 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9092A21F8B0A for ; Mon, 3 Oct 2011 04:15:07 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p93BI9Cv030599; Mon, 3 Oct 2011 06:18:09 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p93BI9wB022249; Mon, 3 Oct 2011 06:18:09 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([192.168.0.104]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 07:18:06 -0400 Date: Mon, 3 Oct 2011 07:18:06 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Randy Bush In-Reply-To: Message-ID: References: <20110930101754.GB10004@juniper.net> <20110930122831.GA10176@juniper.net> <3B65FD95-2E66-4D1F-B630-976ECE99050A@ericsson.com> <7309FCBCAE981B43ABBE69B31C8D213914A3308B30@EUSAACMS0701.eamcs.ericsson.se> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 03 Oct 2011 11:18:06.0395 (UTC) FILETIME=[1FC930B0:01CC81BE] Cc: sidr wg list Subject: Re: [sidr] is a longer announce invalid or not found? X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 03 Oct 2011 11:15:08 -0000 No, just trying to figure out what you were saying. With my first interpretation of you message, what you were suggesting was not possible. That's hardly a twitch or fine detail. I think I've got you straight now. --Sandy, speaking as regular ol' member On Mon, 3 Oct 2011, Randy Bush wrote: > you don't think a router can sign a pks42 or whatever request without > the private key leaving the router? or is it that, as a plain old wg > member, are you really asking for an email beating this into the ground > with every twitch specified to the finest detail? > > randy > From kotikalapudi.sriram@nist.gov Mon Oct 3 10:20:58 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA69F21F8C70 for ; Mon, 3 Oct 2011 10:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVBPzQpKPWgA for ; Mon, 3 Oct 2011 10:20:58 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id B3E8321F8C3F for ; Mon, 3 Oct 2011 10:20:57 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 3 Oct 2011 13:23:51 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 3 Oct 2011 13:23:54 -0400 From: "Sriram, Kotikalapudi" To: sidr wg list Date: Mon, 3 Oct 2011 13:23:53 -0400 Thread-Topic: [sidr] is a longer announce invalid or not found? Thread-Index: Acx/Hw2RLMAZtozmSV2Ax3OT7xaxPgCz+oKA 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] is a longer announce invalid or not found? X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 03 Oct 2011 17:20:58 -0000 For the benefit of the WG members, I would like to point out that the Use Cases and Interpretation doc (draft-ietf-sidr-usecases-02) should also be quite useful in the context of this discussion (complementing Pradosh's/Randy's=20 explanations (below) and Section 3 in draft-ietf-sidr-origin-ops-10). In Sections 3.3 and 3.4 in the Use Cases doc - http://tools.ietf.org/html/draft-ietf-sidr-usecases-02#section-3.3 =20 it is pointed out by examples that max-length should be used in a restrained manner (similar to Randy's example below) when more specific prefixes are intended to be originated from=20 the same AS or a different (say, customer) AS. Also, if you are interested in enumeration of use cases pertaining to validation outcomes vis-=E0-vis existence of certain ROAs and max-length in the ROAs, then Section 7.1 is worth a read as well. http://tools.ietf.org/html/draft-ietf-sidr-usecases-02#section-7.1=20 Sriram > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of P= radosh > Mohapatra > Sent: Thursday, September 29, 2011 11:21 PM > To: Randy Bush > Cc: sidr wg list > Subject: Re: [sidr] is a longer announce invalid or not found? >=20 > > there has been a bit of confusion over whether announcement of a longer > > prefix than is covered by a roa is valid, invalid, or not found. so le= t > > me try to clarify the underlying decision process for valid, invalid, > > and not found so we are all on the same page. i believe this is as it > > is documented in pfx-validate. >=20 >=20 > I concur. >=20 > From a partial deployment perspective, it does mean that once a ROA is > published for an address block (and follows the ops guideline of being pr= ecise), > further sub-allocations NEED to have the ROA published. Otherwise, they > would be marked invalid and risk being not routed. >=20 > - Pradosh >=20 > > > > --- > > > > if i publish a roa for 10.0.0.0/16-16 for AS 42 (and there are no other > > roas for 10/...) > > > > no announcement of 10.0.0.0/16 or any longer prefix thereof from any AS > > may be marked NOT FOUND, after all, a covering roa is there. > > > > any announcement of any prefixes in that space, from /16 to /32, from a= n > > AS other than 42 are INVALID. this is the purpose of the exercise. > > > > and, an announcement of 10.0.666.0/24 from AS 42 is INVALID, as it has = a > > prefix length not specified by the roa. someone is trying to punch a > > hole, not allowed. this could be an origin forger trying to punch a /2= 4 > > in my /16. > > > > but if i publish a roa for 10.0.0.0/16-24 for AS 42, then an > > announcement for 10.0.666.0/24 from AS 42, would be marked VALID. > > > > randy From kent@bbn.com Mon Oct 3 11:01:32 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A1821F8CEA for ; Mon, 3 Oct 2011 11:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.607 X-Spam-Level: X-Spam-Status: No, score=-106.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67nHExMiH1ER for ; Mon, 3 Oct 2011 11:01:31 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAC621F8CE6 for ; Mon, 3 Oct 2011 11:01:31 -0700 (PDT) Received: from dhcp89-089-239.bbn.com ([128.89.89.239]:49156) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RAmsR-000NnC-6c; Mon, 03 Oct 2011 14:04:31 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20110930101754.GB10004@juniper.net> <20110930122831.GA10176@juniper.net> <3B65FD95-2E66-4D1F-B630-976ECE99050A@ericsson.com> <7309FCBCAE981B43ABBE69B31C8D213914A3308B30@EUSAACMS0701.eamcs.ericsson.se > Date: Mon, 3 Oct 2011 14:04:27 -0400 To: Sandra Murphy From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org" Subject: Re: [sidr] is a longer announce invalid or not found? X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 03 Oct 2011 18:01:32 -0000 At 4:56 PM -0400 9/30/11, Sandra Murphy wrote: >S... > >I await correction in quoting Steve. > >--Sandy, speaking as regular ol' member you are correct. All good cert request protocols require PoP, as you noted. But it's not too hard to send the public key and a signed blob. We currently are working on a new PKIX standard, EST, that is intended to offer a simpler enrollment protocol that the other 2 PKIX standards. It might be a good choice for the BGPSEC context. The principle doc author is Max Pritkin at Cisco. Steve From Sandra.Murphy@cobham.com Wed Oct 5 11:37:08 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFBB21F8CEE for ; Wed, 5 Oct 2011 11:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.314 X-Spam-Level: X-Spam-Status: No, score=-101.314 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2OWpeIfLcJs for ; Wed, 5 Oct 2011 11:37:07 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id BDE7F21F8C98 for ; Wed, 5 Oct 2011 11:37:07 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p95IeEmp021831 for ; Wed, 5 Oct 2011 13:40:14 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p95IeEP4031311 for ; Wed, 5 Oct 2011 13:40:15 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.164]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 14:39:53 -0400 Date: Wed, 5 Oct 2011 14:39:52 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 05 Oct 2011 18:39:53.0539 (UTC) FILETIME=[2C19E130:01CC838E] Subject: [sidr] agenda item request X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 05 Oct 2011 18:37:08 -0000 It is time to start assembling our agenda to the IETF82 meeting in Taipei. Please send requests for a time slot to the list. --Sandy From Sandra.Murphy@cobham.com Wed Oct 5 11:41:11 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 681731F0C71 for ; Wed, 5 Oct 2011 11:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.228 X-Spam-Level: X-Spam-Status: No, score=-102.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WHXI6BkTarG for ; Wed, 5 Oct 2011 11:41:10 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB4E1F0C6C for ; Wed, 5 Oct 2011 11:41:10 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p95IiItB021867 for ; Wed, 5 Oct 2011 13:44:18 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p95IiIkF031431 for ; Wed, 5 Oct 2011 13:44:18 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.164]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 14:44:18 -0400 Date: Wed, 5 Oct 2011 14:44:17 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 05 Oct 2011 18:44:18.0148 (UTC) FILETIME=[C9D20240:01CC838E] Subject: [sidr] important dates for IETF82 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 05 Oct 2011 18:41:11 -0000 Below is the list of important dates for the IETF82 meeting in Taipei. For draft authors, the ones to pay particular attention to are the Oct 24 date for -00 drafts and the Oct 31 date for revised drafts. --Sandy 2011-10-13 (Thursday): Preliminary agenda published for comment. 2011-10-17 (Monday): Cutoff date for requests to reschedule Working Group and BOF meetings 17:00 PT (00:00 UTC). 2011-10-17 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by 17:00 PT (00:00 UTC). 2011-10-21 (Friday): Final agenda to be published. 2011-10-24 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (00:00 UTC). 2011-10-31 (Monday): Internet Draft final submission cut-off by 17:00 PT (00:00 UTC). 2011-11-02 (Wednesday): Draft Working Group agendas due by 17:00 PT (00:00 UTC). 2011-11-04 (Friday): Early Bird registration and payment cut-off at 17:00 PT (00:00 UTC). 2011-11-07 (Monday): Revised Working Group agendas due by 17:00 PT (00:00 UTC). From wesley.george@twcable.com Thu Oct 6 13:25:51 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A7021F8E23 for ; Thu, 6 Oct 2011 13:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.256 X-Spam-Level: X-Spam-Status: No, score=-0.256 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8VpReXayzPe for ; Thu, 6 Oct 2011 13:25:50 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id C589821F8E21 for ; Thu, 6 Oct 2011 13:25:50 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,644,1309752000"; d="scan'208";a="267474909" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 06 Oct 2011 16:26:09 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Thu, 6 Oct 2011 16:28:58 -0400 From: "George, Wes" To: Sandra Murphy , "sidr@ietf.org" Date: Thu, 6 Oct 2011 16:28:57 -0400 Thread-Topic: [sidr] important dates for IETF82 Thread-Index: AcyDjsz1DCbSSsvUSQiVE5cR6ZSu7AA0ibHQ Message-ID: <34E4F50CAFA10349A41E0756550084FB115E4DD5@PRVPEXVS04.corp.twcable.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] important dates for IETF82 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 06 Oct 2011 20:25:51 -0000 Are revisions pending for any of the ietf-sidr-bgpsec-* drafts prior to the= submission cutoff? Current -00 versions are pre-QC vintage (and IIRC mostl= y unchanged from the non-WG versions). I'm trying to allocate cycles to rev= iew drafts I know are important before the standard deadline draft crush, a= nd it'll help if I know whether to expect them. I assume it'll help our cha= irs, resplendent in their various WG Chair Regalia, to plan the agenda as w= ell... Thanks, Wes -----Original Message----- From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of San= dra Murphy Sent: Wednesday, October 05, 2011 2:44 PM To: sidr@ietf.org Subject: [sidr] important dates for IETF82 Below is the list of important dates for the IETF82 meeting in Taipei. For draft authors, the ones to pay particular attention to are the Oct 24 date for -00 drafts and the Oct 31 date for revised drafts. --Sandy 2011-10-13 (Thursday): Preliminary agenda published for comment. 2011-10-17 (Monday): Cutoff date for requests to reschedule Working Group and BOF meetings 17:00 PT (00:00 UTC). 2011-10-17 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by 17:00 PT (00:00 UTC). 2011-10-21 (Friday): Final agenda to be published. 2011-10-24 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (00:00 UTC). 2011-10-31 (Monday): Internet Draft final submission cut-off by 17:00 PT (00:00 UTC). 2011-11-02 (Wednesday): Draft Working Group agendas due by 17:00 PT (00:00 UTC). 2011-11-04 (Friday): Early Bird registration and payment cut-off at 17:00 PT (00:00 UTC). 2011-11-07 (Monday): Revised Working Group agendas due by 17:00 PT (00:00 UTC). _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From ietfc@btconnect.com Fri Oct 7 07:21:17 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934B921F8BAB for ; Fri, 7 Oct 2011 07:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.73 X-Spam-Level: X-Spam-Status: No, score=-1.73 tagged_above=-999 required=5 tests=[AWL=-0.423, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdEVQM+pLnWy for ; Fri, 7 Oct 2011 07:21:17 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by ietfa.amsl.com (Postfix) with ESMTP id B077921F8BA4 for ; Fri, 7 Oct 2011 07:21:16 -0700 (PDT) Received: from host86-163-147-122.range86-163.btcentralplus.com (HELO pc6) ([86.163.147.122]) by c2bthomr13.btconnect.com with SMTP id EQY98770; Fri, 07 Oct 2011 15:21:57 +0100 (BST) Message-ID: <003f01cc84f3$72b22a60$4001a8c0@gateway.2wire.net> From: "t.petch" Cc: References: <20111001163959.11213.35009.idtracker@ietfa.amsl.com> Date: Fri, 7 Oct 2011 15:17:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4E8F0B05.014B, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.10.7.133314:17:7.586, ip=86.163.147.122, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, MISSING_HEADERS, __ANY_URI, __CP_URI_IN_BODY, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_1600_1699, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, __PHISH_SPEAR_STRUCTURE_1, RDNS_SUSP, BODY_SIZE_2000_LESS, __PHISH_SPEAR_STRUCTURE_2, BODY_SIZE_7000_LESS, TO_MALFORMED X-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.4E8F0B9D.0004,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-17.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 14:21:17 -0000 When this says, in s.7.2, that the CN field should be used to denote the router's identity, is there any underlying idea what form that should take? serial number, sysName, iPAddress or is it open to anything? Tom Petch ----- Original Message ----- From: To: Cc: Sent: Saturday, October 01, 2011 6:39 PM Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-17.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. > > Title : The RPKI/Router Protocol > Author(s) : Randy Bush > Rob Austein > Filename : draft-ietf-sidr-rpki-rtr-17.txt > Pages : 25 > Date : 2011-10-01 > > In order to formally validate the origin ASs of BGP announcements, > routers need a simple but reliable mechanism to receive RPKI > [I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This > document describes a protocol to deliver validated prefix origin data > to routers. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-17.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-17.txt > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From christopher.morrow@gmail.com Sun Oct 9 07:01:09 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F5F21F8A96 for ; Sun, 9 Oct 2011 07:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9+NOSqw7XsL for ; Sun, 9 Oct 2011 07:01:08 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D448C21F8A6C for ; Sun, 9 Oct 2011 07:01:08 -0700 (PDT) Received: by iaby26 with SMTP id y26so7796866iab.31 for ; Sun, 09 Oct 2011 07:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=aYmxtKf9pCJmZr2CxXeC3dxdYA2qpyV3uRiLALDzjVE=; b=lyQ/f0ArEQe5M/S1A4J6c7uF2DLu9DOVygz9KGc/NgeOkLt0MGiPmqUXDDNM8MxgC2 J46mvwTowe/kHSFiWI+h3mgqBSdUEE8qXDnVpjEbcS5O2KN6CYOfvvV8uftJF/1a0dKp 2VBRQwJG37ScnSRYhDRVtZBf5luGhUkWn0h5Q= MIME-Version: 1.0 Received: by 10.231.20.218 with SMTP id g26mr2792848ibb.88.1318168867433; Sun, 09 Oct 2011 07:01:07 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.59.206 with HTTP; Sun, 9 Oct 2011 07:01:07 -0700 (PDT) In-Reply-To: <003f01cc84f3$72b22a60$4001a8c0@gateway.2wire.net> References: <20111001163959.11213.35009.idtracker@ietfa.amsl.com> <003f01cc84f3$72b22a60$4001a8c0@gateway.2wire.net> Date: Sun, 9 Oct 2011 10:01:07 -0400 X-Google-Sender-Auth: AtUfYiwr7sCUweU7n6_m3ICQMUI Message-ID: From: Christopher Morrow To: "t.petch" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-17.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2011 14:01:09 -0000 On Fri, Oct 7, 2011 at 9:17 AM, t.petch wrote: > When this says, in s.7.2, that the CN field should be used to denote the > router's identity, is there any underlying idea what form that should tak= e? > serial number, sysName, iPAddress or is it open to anything? > after a long discussion ... err, 'open to anything' seems like the right an= swer. you only care about it from cache -> router or router -> cache, so you can know sally's talking to bob, not jane. -chris > Tom Petch > > > ----- Original Message ----- > From: > To: > Cc: > Sent: Saturday, October 01, 2011 6:39 PM > Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-17.txt > > >> 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 =A0 =A0 =A0 =A0 =A0 : The RPKI/Router Protocol >> Author(s) =A0 =A0 =A0 : Randy Bush >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rob Austein >> Filename =A0 =A0 =A0 =A0: draft-ietf-sidr-rpki-rtr-17.txt >> Pages =A0 =A0 =A0 =A0 =A0 : 25 >> Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-10-01 >> >> =A0 =A0In order to formally validate the origin ASs of BGP announcements= , >> =A0 =A0routers need a simple but reliable mechanism to receive RPKI >> =A0 =A0[I-D.ietf-sidr-arch] prefix origin data from a trusted cache. =A0= This >> =A0 =A0document describes a protocol to deliver validated prefix origin = data >> =A0 =A0to routers. >> >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-17.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-17.txt >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From randy@psg.com Sun Oct 9 07:10:54 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D925C21F8906 for ; Sun, 9 Oct 2011 07:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGRyhOVqYnQk for ; Sun, 9 Oct 2011 07:10:54 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 8808C21F8A80 for ; Sun, 9 Oct 2011 07:10:53 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RCu5c-0007IJ-F5 for sidr@ietf.org; Sun, 09 Oct 2011 14:10:52 +0000 Date: Sun, 09 Oct 2011 10:10:51 -0400 Message-ID: From: Randy Bush To: sidr wg list User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: [sidr] draft-ietf-sidr-rpki-rtr-17.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2011 14:10:55 -0000 could the chairs please pass $subject to the iesg? i am only aware of one possible issue raised in wglc, tp asked for a hyphen somewhere but did not respond to my asking him to be specific where. if this mystery is solved, i presume it can be handled in the iesg or auth48. randy From internet-drafts@ietf.org Sun Oct 9 07:13:49 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9D021F8AD9; Sun, 9 Oct 2011 07:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.181 X-Spam-Level: X-Spam-Status: No, score=-102.181 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrVOXUefMBOt; Sun, 9 Oct 2011 07:13:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55DC121F8906; Sun, 9 Oct 2011 07:13:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111009141349.27876.44077.idtracker@ietfa.amsl.com> Date: Sun, 09 Oct 2011 07:13:49 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-origin-ops-11.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2011 14:13:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : RPKI-Based Origin Validation Operation Author(s) : Randy Bush Filename : draft-ietf-sidr-origin-ops-11.txt Pages : 9 Date : 2011-10-09 Deployment of RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present them. It is expected to evolve as RPKI-based origin validation is deployed and the dynamics are better understood. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-origin-ops-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-origin-ops-11.txt From randy@psg.com Sun Oct 9 07:32:29 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E74521F8AD8 for ; Sun, 9 Oct 2011 07:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZPe-9-rqs2E for ; Sun, 9 Oct 2011 07:32:28 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id CCDCF21F8AD6 for ; Sun, 9 Oct 2011 07:32:28 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RCuQV-0007Ly-IW for sidr@ietf.org; Sun, 09 Oct 2011 14:32:28 +0000 Date: Sun, 09 Oct 2011 10:32:26 -0400 Message-ID: From: Randy Bush To: sidr wg list User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: [sidr] draft-ietf-sidr-origin-ops-11.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2011 14:32:29 -0000 chairs, please status(draft-ietf-sidr-origin-ops-11.txt)++ randy From dougm@nist.gov Sun Oct 9 09:19:54 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F70F21F8AA9 for ; Sun, 9 Oct 2011 09:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpkGuOWMW74E for ; Sun, 9 Oct 2011 09:19:53 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7E621F8A69 for ; Sun, 9 Oct 2011 09:19:52 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 9 Oct 2011 12:19:50 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Sun, 9 Oct 2011 12:19:16 -0400 From: "Montgomery, Douglas" To: LIST NANOG Date: Sun, 9 Oct 2011 12:19:48 -0400 Thread-Topic: Announcing BGP Secure Router Extension (BGP-SRx) Prototype Implementation Thread-Index: AcyGnzBP/PWui+wPSXOwOmL3Rv4RrQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CAB741E468CB7dougmnistgov_" MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: [sidr] Announcing BGP Secure Router Extension (BGP-SRx) Prototype Implementation X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 09 Oct 2011 16:19:54 -0000 --_000_CAB741E468CB7dougmnistgov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Announcing BGP Secure Router Extension (BGP-SRx) Prototype Implementation IETF SIDR working group is developing standards for BGP origin validation and AS path validation to strengthen the inter-domain routing infrastructure. At the IETF 80 in March 2011, NIST made an introductory presentation on a prototyping effort called BGP Secure Router Extension (BGP-SRx). SRx is an open source reference implementation and research platform for investigating emerging BGP security extensions and supporting protocols. BGP-SRx has three parts: SRx Server, SRx API, and Quagga SRx (integrates SRx API into Quagga router). The current focus in the BGP-SRx prototype is on origin validation, although it is designed to be be extended to path validation in the future (some stub functionality is already included in this version). The current release implements: The RPKI/Router Protocol and a variety of BGP policies for enforcing Route Origin Authorizations (ROAs) conveyed from RPKI validating caches. Also included in the release are test client/server test harnesses for RPKI/Router and WireShark modules for debugging. For more information on BGP-SRx, and to download the prototype and tools, see: http://www-x.antd.nist.gov/bgpsrx/ For those wanting an easy way to experiment with BGP-SRx, in June we made an announcement about the BRITE system (BGPSEC/RPKI Interoperability Test & Evaluation): http://mailman.nanog.org/pipermail/nanog/2011-June/038063.html You can use BRITE (http://brite.antd.nist.gov/= ) to run BGP-SRx (or any other implementation) through aseries of test scripts that exercise numerous interesting scenarios for BGP ROA processing under different polic= y assumptions. We will make a presentation at NANOG-53 on Monday (9/10/11) in the ISP Secu= rity BoF where we will briefly explain the functionalities of both BGP-SRx and BRITE and also give demos. Please attend the BoF if you are interested to learn more. Comments and feedback about SRx and BRITE are welcome. See the project pag= e For details. dougm -- Doug Montgomery =96 Mgr. Internet & Scalable Systems Research / ITL / NIST --_000_CAB741E468CB7dougmnistgov_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Announcing BGP Secure Router Extension= (BGP-SRx) Prototype Implementation

IETF SIDR working group is developing standards for BGP or= igin validation
and AS path validation to strengthen the inter-domain routing
infrastructure. At th= e IETF 80 in March 2011, NIST made an introductory
presentation on a prototyping effort= called BGP Secure Router Extension
(BGP-SRx). SRx is an open source reference implemen= tation and research
platform for investigating emerging BGP security extensions and sup= porting
prot= ocols.

<= /div>
BGP-SRx has = three parts: SRx Server, SRx API, and Quagga SRx (integrates
SRx API into Quagga router= ). The current focus in the BGP-SRx prototype is
on origin validation, although it is d= esigned to be be extended to path
validation in the future (some stub functionality is = already included in
this version).

The current release implements: The RPKI/Router Protocol and a variety = of
BGP polic= ies for enforcing Route Origin Authorizations (ROAs) conveyed
from RPKI validating cach= es.  Also included in the release are test
client/server test harnesses for R= PKI/Router and WireShark modules for
debugging.

For more information on BGP-SRx, and to download the proto= type and tools,

For those wanting an easy way to experiment with BGP-SRx, in Ju= ne we made
a= n announcement about the BRITE system (BGPSEC/RPKI Interoperability Test &a= mp;

=
(or any other implementation) through aseries of test scripts that= exercise 
numerous interesting scenarios for BGP ROA processing under differ= ent policy 
assumptions.

W= e will make a presentation at NANOG-53 on Monday (9/10/11) in the= ISP Security
BRITE and a= lso give demos. Please attend the BoF if you are interested to
learn more.

Comments and feedback about SRx= and BRITE are welcome.  See the project page
For details.

dougm
-- =
Doug Montgomery =96 Mgr. Internet & Scalable Systems Researc= h / ITL / NIST

--_000_CAB741E468CB7dougmnistgov_-- From ietfc@btconnect.com Mon Oct 10 09:17:04 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB1121F8C61 for ; Mon, 10 Oct 2011 09:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbH+3-KH9-se for ; Mon, 10 Oct 2011 09:17:04 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by ietfa.amsl.com (Postfix) with ESMTP id C4DB821F8B8E for ; Mon, 10 Oct 2011 09:17:02 -0700 (PDT) Received: from host86-163-147-122.range86-163.btcentralplus.com (HELO pc6) ([86.163.147.122]) by c2bthomr14.btconnect.com with SMTP id ERL82575; Mon, 10 Oct 2011 17:14:20 +0100 (BST) Message-ID: <003801cc875e$a2ae28a0$4001a8c0@gateway.2wire.net> From: "t.petch" To: Date: Mon, 10 Oct 2011 17:09:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4E9319DB.01FE, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.10.10.143315:17:7.586, ip=86.163.147.122, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __CP_URI_IN_BODY, BODY_SIZE_1900_1999, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0201.4E931A7D.014D,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Subject: [sidr] Fw: Protocol Action: 'Recommendation for Not Using AS_SETand AS_CONFED_SET in BGP' to BCP(draft-ietf-idr-deprecate-as-sets-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, 10 Oct 2011 16:17:05 -0000 Good news, AS_SET are 'deprecated' Tom Petch ----- Original Message ----- From: "The IESG" To: "IETF-Announce" Cc: "idr mailing list" ; "idr chair" ; "RFC Editor" Sent: Monday, October 10, 2011 6:06 PM Subject: [Idr] Protocol Action: 'Recommendation for Not Using AS_SETand AS_CONFED_SET in BGP' to BCP(draft-ietf-idr-deprecate-as-sets-06.txt) > The IESG has approved the following document: > - 'Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP' > (draft-ietf-idr-deprecate-as-sets-06.txt) as a BCP > > This document is the product of the 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-idr-deprecate-as-sets/ > > > > > Technical Summary > > This document provides advice to operators. It deprecates > the use of the AS_SET and AS_CONFED_SET types of > the AS_PATH in BGPv4. This is done to simplify the > design and implementation of the BGP protocol and to make > the semantics of the originator of a route more clear. > > Working Group Summary > > This document was adopted as a WG item on > Oct 25th, 2010. There was an initial WGLC > that concluded on April 13th, 2010. Comments > from the initial WGLC were integrated and a > second WGLC held, which concluded on May17, 2011. > > Document Quality > > This note provides advice to operators proposing that > they cease using a current BGP protocol feature. > > Personnel > > John Scudder (jgs@juniper.net) is the document shepherd. > Stewart Bryant (stbryant@cisco.com) is the responsible AD. > > RFC Editor Note > > There is no RFC2119 language used in the draft. > > Please remove section 2 - the RFC2119 section and the > RFC2119 reference. From Sandra.Murphy@cobham.com Thu Oct 13 15:50:27 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA01D21F8B75 for ; Thu, 13 Oct 2011 15:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15MwkazesSxb for ; Thu, 13 Oct 2011 15:50:27 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id BEDA321F8B72 for ; Thu, 13 Oct 2011 15:50:26 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p9DMoPRv006982 for ; Thu, 13 Oct 2011 17:50:25 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p9DMoPlG025839 for ; Thu, 13 Oct 2011 17:50:25 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([12.53.162.50]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Oct 2011 18:50:24 -0400 Date: Thu, 13 Oct 2011 18:50:17 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 13 Oct 2011 22:50:25.0200 (UTC) FILETIME=[7EF95300:01CC89FA] Subject: [sidr] IETF 82 draft agenda announced X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 13 Oct 2011 22:50:27 -0000 The draft agenda has been published. https://datatracker.ietf.org/meeting/82/agenda.html The sidr slot is presently Friday morning. That is subject to change as conflicts are resolved. --Sandy From christopher.morrow@gmail.com Fri Oct 14 06:32:46 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3A321F8B89 for ; Fri, 14 Oct 2011 06:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Viu+HYYIuuh8 for ; Fri, 14 Oct 2011 06:32:41 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 64D1D21F8B25 for ; Fri, 14 Oct 2011 06:32:41 -0700 (PDT) Received: by iabn5 with SMTP id n5so2649499iab.31 for ; Fri, 14 Oct 2011 06:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=dVbNb24TtHRgAVGLGQF0kMBUvasw0IEKXCFp9cNBceY=; b=hWXwSaQqTD6rDT3SIKwOtW7lEBnMhb25mi3/AvVo/XMDNtVDdtRgolSI/hUWhTbGTV TMF3t64w10KKz+kZcA3GqhSFtubkPsEoIlWRSLlRvRobFkuAW47S45p9ztsXckT+vKeV e/xmmsWJV9S/XZiCB/HaCyThLQN5rMMoAIjRU= MIME-Version: 1.0 Received: by 10.231.6.102 with SMTP id 38mr3686535iby.62.1318599161063; Fri, 14 Oct 2011 06:32:41 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.160.201 with HTTP; Fri, 14 Oct 2011 06:32:40 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Oct 2011 09:32:40 -0400 X-Google-Sender-Auth: CMzpe8f1C9hw9pPTeNXQefKlY2w Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] draft-ietf-sidr-origin-ops-11.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 13:32:46 -0000 Seems that this doc should go through WGLC, please hold onto your seat as this will be sent shortly. Thanks! On Sun, Oct 9, 2011 at 10:32 AM, Randy Bush wrote: > chairs, please status(draft-ietf-sidr-origin-ops-11.txt)++ > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From christopher.morrow@gmail.com Fri Oct 14 06:36:51 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCAF021F886A; Fri, 14 Oct 2011 06:36:51 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XywJYT0ne2fw; Fri, 14 Oct 2011 06:36:51 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3C47B21F8B25; Fri, 14 Oct 2011 06:36:48 -0700 (PDT) Received: by gyh20 with SMTP id 20so1310931gyh.31 for ; Fri, 14 Oct 2011 06:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=d1VGyKL7FeJ2VxGDpvTDGJl8rsaZoIbGFIqF/xF2CzA=; b=aV/2EWHRiUDlPl3lj+DpAp93UO5GkTREPd7Fuik5ytJcwBT825+5jLMRjGap2TyfDn NLzasllmX3E3Li1Aan1SGjToDadrWr6fGxPuBL6FdB9QmrNuTF5KtV1J/6F+aiNwVrFu a0arCvi1qMRHSuD94UBiznZxwrTd2lLiAVkXg= MIME-Version: 1.0 Received: by 10.43.52.136 with SMTP id vm8mr16492884icb.26.1318599407742; Fri, 14 Oct 2011 06:36:47 -0700 (PDT) Received: by 10.231.160.201 with HTTP; Fri, 14 Oct 2011 06:36:47 -0700 (PDT) Date: Fri, 14 Oct 2011 09:36:47 -0400 Message-ID: From: Christopher Morrow To: sidr@ietf.org, sidr-chairs@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 14 Oct 2011 13:36:51 -0000 SIDR Folk, Please see the subject, draft-ietf-sidr-origin-ops is at version 11, it's gotten some significant feedback over it's lifetime and is now stabilized. Let's re-read and consider passing this up to the IESG for their review, eh? Tools page for doc: Draft link: Please consider this draft in WGLC at this time, we'll end that in 2 weeks time (10/28/2011). -Chris From Sandra.Murphy@cobham.com Fri Oct 14 07:07:24 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3152E21F8BAE; Fri, 14 Oct 2011 07:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLkLZrGBNy24; Fri, 14 Oct 2011 07:07:23 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id EA1B521F8B7D; Fri, 14 Oct 2011 07:07:22 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p9EE7M5p013261; Fri, 14 Oct 2011 09:07:22 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p9EE7LKA004530; Fri, 14 Oct 2011 09:07:21 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([199.187.222.67]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 10:07:20 -0400 Date: Fri, 14 Oct 2011 10:07:29 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 14 Oct 2011 14:07:21.0072 (UTC) FILETIME=[96FD2F00:01CC8A7A] Cc: draft-ietf-sidr-rpsl-sig@tools.ietf.org, sidr-chairs@ietf.org Subject: [sidr] status of draft-ietf-sidr-rpsl-sig X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 14 Oct 2011 14:07:24 -0000 The draft draft-ietf-sidr-rpsl-sig has been expired for awhile. The editor indicates that he is willing to continue progressing this work as long as the wg is still interested. This work was first submitted as a wg draft in Dec 2008. Could the wg please indicate that there is still willingness to continue this work? Please respond as to your continued support for this draft by 28 Oct 2011. --Sandy, speaking as wg chair with regalia in place From Sandra.Murphy@cobham.com Fri Oct 14 07:43:51 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2AA221F8CA8 for ; Fri, 14 Oct 2011 07:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMz10WW5m-1Z for ; Fri, 14 Oct 2011 07:43:51 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 54E7021F8B21 for ; Fri, 14 Oct 2011 07:43:51 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p9EEhonv013649 for ; Fri, 14 Oct 2011 09:43:50 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p9EEhnsx005658 for ; Fri, 14 Oct 2011 09:43:49 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([199.187.222.67]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 10:43:49 -0400 Date: Fri, 14 Oct 2011 10:43:57 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org In-Reply-To: Message-ID: References: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 14 Oct 2011 14:43:49.0244 (UTC) FILETIME=[AF3DBBC0:01CC8A7F] Subject: Re: [sidr] wg adoption for draft-ymbk-bgp-origin-validation-mib and draft-ymbk-rpki-rtr-protocol-mib X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 14:43:51 -0000 There was sufficient positive response to this call, both before and after the official call, for the wg chairs to judge that the wg is interested in adopting these drafts as work itmes. Would the draft authors please submit new versions of these drafts as wg drafts draft-ietf-sidr-bgp-origin-validation-mib draft-ietf-sidr-rpki-rtr-protocol-mib --Sandy, speaking as wg chair with wg chair regalia donned On Fri, 5 Aug 2011, Sandra Murphy wrote: > The working group has been requested to adopt > draft-ymbk-bgp-origin-validation-mib > draft-ymbk-rpki-rtr-protocol-mib > > as working group drafts. > > As these are drafts are so similar in topic, I am running the adoption call > for both simultaneously. > > Please respond to the list with your opinion as to whether you accept these > drafts as working group drafts and are willing to work on them. Remember that > you do not need to accept all content in a draft to adopt, as draft editors > are required to reflect the consensus of the working group. > > This call will end 19 Aug 2011 > > Those who anticipated this call for adoption and have already responded do > not need to respond again. > > --Sandy, speaking as wg co-chair > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From Sandra.Murphy@cobham.com Fri Oct 14 07:44:52 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B3921F8CBF for ; Fri, 14 Oct 2011 07:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyqaFGU14yE2 for ; Fri, 14 Oct 2011 07:44:52 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7F621F8CB9 for ; Fri, 14 Oct 2011 07:44:51 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p9EEioV0013653 for ; Fri, 14 Oct 2011 09:44:50 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p9EEioK0005681 for ; Fri, 14 Oct 2011 09:44:50 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([199.187.222.67]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 10:44:50 -0400 Date: Fri, 14 Oct 2011 10:44:58 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org In-Reply-To: Message-ID: References: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 14 Oct 2011 14:44:50.0071 (UTC) FILETIME=[D37F3270:01CC8A7F] Subject: Re: [sidr] call for wg adoption of draft-turner-sidr-bgpsec-pki-profiles X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 14:44:52 -0000 The chairs did not see sufficient response to this call for adoption to indicate that the wg is willing to adopt this as a work item. --Sandy, speaking as wg chair with wg ceremonial garb donned On Tue, 9 Aug 2011, Sandra Murphy wrote: > The working group has been requested to adopt > draft-turner-sidr-bgpsec-pki-profiles as a working group draft. > > The draft is available at > http://tools.ietf.org/html/draft-turner-sidr-bgpsec-pki-profiles > > Please respond to the list to say whether you accept this draft as a working > group draft and are willing to work on it. Remember that you do not need to > accept all content in a draft to adopt, as draft editors are required to > reflect the consensus of the working group. > > This call will end 23 Aug 2011 > > --Sandy, speaking as wg co-chair > > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From jgs@juniper.net Fri Oct 14 07:47:45 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9A021F8CC1 for ; Fri, 14 Oct 2011 07:47:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0qqnHN0eIZz for ; Fri, 14 Oct 2011 07:47:45 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 9456C21F8CC3 for ; Fri, 14 Oct 2011 07:47:44 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Fri, 14 Oct 2011 07:47:45 PDT Received: from P-EMHUB11-HQ.jnpr.net (172.24.192.58) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.83.0; Fri, 14 Oct 2011 07:46:20 -0700 Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB11-HQ.jnpr.net ([::1]) with mapi; Fri, 14 Oct 2011 07:46:20 -0700 From: John Scudder To: Sandra Murphy Date: Fri, 14 Oct 2011 07:46:19 -0700 Thread-Topic: [sidr] call for wg adoption of draft-turner-sidr-bgpsec-pki-profiles Thread-Index: AcyKgAlWMIuLQj33QhO2vliK5SWioA== 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] call for wg adoption of draft-turner-sidr-bgpsec-pki-profiles X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 14:47:45 -0000 Oops. Belated support. --John On Oct 14, 2011, at 10:44 AM, Sandra Murphy wrote: > The chairs did not see sufficient response to this call for adoption to i= ndicate that the wg is willing to adopt this as a work item. >=20 > --Sandy, speaking as wg chair with wg ceremonial garb donned >=20 > On Tue, 9 Aug 2011, Sandra Murphy wrote: >=20 >> The working group has been requested to adopt draft-turner-sidr-bgpsec-p= ki-profiles as a working group draft. >>=20 >> The draft is available at http://tools.ietf.org/html/draft-turner-sidr-b= gpsec-pki-profiles >>=20 >> Please respond to the list to say whether you accept this draft as a wor= king group draft and are willing to work on it. Remember that you do not ne= ed to accept all content in a draft to adopt, as draft editors are required= to reflect the consensus of the working group. >>=20 >> This call will end 23 Aug 2011 >>=20 >> --Sandy, speaking as wg co-chair >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From Sandra.Murphy@cobham.com Fri Oct 14 07:50:14 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FB821F8CC9 for ; Fri, 14 Oct 2011 07:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cwshaFVKiKL for ; Fri, 14 Oct 2011 07:50:13 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 630F321F8CC7 for ; Fri, 14 Oct 2011 07:50:13 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p9EEoC8j013695 for ; Fri, 14 Oct 2011 09:50:12 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p9EEoCWS005809 for ; Fri, 14 Oct 2011 09:50:12 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([199.187.222.67]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 10:50:11 -0400 Date: Fri, 14 Oct 2011 10:50:20 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 14 Oct 2011 14:50:11.0848 (UTC) FILETIME=[934A7880:01CC8A80] Subject: [sidr] about a router AS-related certificate X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 14 Oct 2011 14:50:14 -0000 The wg has just demonstrated a lack of support for adoption of a suggested cert profile for routers in draft-turner-sidr-bgpsec-pki-profiles. Unfortunately, a router certificate is already mentioned in existing wg drafts. The bgpsec-overview draft says: BGPSEC extends the RPKI by adding an additional type of certificate, referred to as a BGPSEC router certificate, that binds an AS number to a public signature verification key, the corresponding private key of which is held by one or more BGP speakers within this AS. The bgpsec-ops drafts says: AS/Router Certificates A site/operator MAY use a single certificate/key in all their routers, one certificate/key per router, or any granularity in between. A large operator, concerned that a compromise of one router's key would make many routers vulnerable, MAY accept a more complex certificate/key distribution burden to reduce this exposure. On the other extreme, an edge site with one or two routers MAY use a single certificate/key. Is there an alternative router certificate that the wg would like to adopt? If the wg did not realize that the router certificate was needed to fulfill existing wg drafts, please speak up. At any rate, the wg needs to indicate how to proceed here. --Sandy, speaking as wg chair From Sandra.Murphy@cobham.com Fri Oct 14 07:50:51 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4578E21F8495 for ; Fri, 14 Oct 2011 07:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qul+PcA8Wd33 for ; Fri, 14 Oct 2011 07:50:50 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id A7A4521F848E for ; Fri, 14 Oct 2011 07:50:50 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p9EEonbG013705 for ; Fri, 14 Oct 2011 09:50:49 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p9EEon6C005820 for ; Fri, 14 Oct 2011 09:50:49 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([199.187.222.67]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 10:50:28 -0400 Date: Fri, 14 Oct 2011 10:50:36 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org In-Reply-To: Message-ID: References: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 14 Oct 2011 14:50:28.0473 (UTC) FILETIME=[9D333E90:01CC8A80] Subject: Re: [sidr] call for wg adoption of draft-turner-sidr-bgpsec-algs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 14:50:51 -0000 This call for adoption did not get sufficient support to judge the wg as willing to adopt this draft. --Sandy, speaking as wg chair with wg ceremonial garb donned On Tue, 9 Aug 2011, Sandra Murphy wrote: > The working group has been requested to adopt > draft-turner-sidr-bgpsec-algs as a working group draft. > > The draft is available at > http://tools.ietf.org/html/draft-turner-sidr-bgpsec-algs > > Please respond to the list to say whether you accept this draft as a > working group draft and are willing to work on it. Remember that you do > not need to accept all content in a draft to adopt, as draft editors are > required to reflect the consensus of the working group. > > This call will end 23 Aug 2011 > > --Sandy, speaking as wg co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From christopher.morrow@gmail.com Fri Oct 14 07:52:43 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E084B21F8C7E for ; Fri, 14 Oct 2011 07:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.499 X-Spam-Level: X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2hKnICeX9F1 for ; Fri, 14 Oct 2011 07:52:43 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE4721F8C7F for ; Fri, 14 Oct 2011 07:52:43 -0700 (PDT) Received: by iabn5 with SMTP id n5so2743861iab.31 for ; Fri, 14 Oct 2011 07:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Y24QRndUOSNfVDZIHhhpNJaMliV0vwECFA7uDQxQXeQ=; b=oldoS7IkTe8Cm31mF03UUdpBDa62IG9hHRwMZAEIdJyR3Vfr4Rlqx4bxHZAE/WCPnL Aa0fuGPWqw2cRArsy2B925+7VY306CfisjwPqH634ACAq3EyMJATpkzf4vxqc/nfmTMx Z2fmLc6DnVDpDZbldCQbxWUnyrMOl2hqR6wk0= MIME-Version: 1.0 Received: by 10.231.20.218 with SMTP id g26mr3843593ibb.88.1318603963057; Fri, 14 Oct 2011 07:52:43 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.160.201 with HTTP; Fri, 14 Oct 2011 07:52:42 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Oct 2011 10:52:42 -0400 X-Google-Sender-Auth: uzfbn8D7jrxKnjtCP0Q2wVj6ZXc Message-ID: From: Christopher Morrow To: Randy Bush , "t.petch" , Samuel Weiler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] draft-ietf-sidr-rpki-rtr-17.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 14:52:44 -0000 On Sun, Oct 9, 2011 at 10:10 AM, Randy Bush wrote: > could the chairs please pass $subject to the iesg? =A0i am only aware of > one possible issue raised in wglc, tp asked for a hyphen somewhere but > did not respond to my asking him to be specific where. =A0if this mystery > is solved, i presume it can be handled in the iesg or auth48. I believe Tom's issue was addressed in conversation (with mr weiler?), but if not probably we can catch the problem in IESG review comment recovery :) I'll forward on the document to the IESG today + the writeup, of course. -Chris (If the authors could wrangle: ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Downref: Normative reference to an Informational RFC: RFC 4808 that'd be helpful to the process, again these can be caught in the IESG review fixups as well) From wesley.george@twcable.com Fri Oct 14 08:19:31 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D2821F8C90; Fri, 14 Oct 2011 08:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[AWL=1.114, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtD7fh+6VOr6; Fri, 14 Oct 2011 08:19:30 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5BA21F8C8E; Fri, 14 Oct 2011 08:19:30 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,345,1315195200"; d="scan'208";a="285516156" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 14 Oct 2011 11:16:00 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Fri, 14 Oct 2011 11:19:28 -0400 From: "George, Wes" To: Christopher Morrow , "sidr@ietf.org" , "sidr-chairs@ietf.org" Date: Fri, 14 Oct 2011 11:19:27 -0400 Thread-Topic: [sidr] WGLC: draft-ietf-sidr-origin-ops Thread-Index: AcyKdlZb/JgGWqt+Q3qThe0HbJr6IgACOr/Q 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 14 Oct 2011 15:19:31 -0000 I'm not sure I am following the rationale here: "As RPKI-based origin validation relies on the availability of RPKI data, operators SHOULD locate caches close to routers that require these data and services. ... Peering with two or more, at least one local and others remote, is recommended." I agree with the recommendation of using more than one cache for redundancy= . Further, I understand the idea of close proximity when we're talking abou= t things like route-reflectors, but the data associated with an origin vali= dation cache is pretty geographically independent, and I wouldn't think tha= t propagation delay would have a material impact on the performance of the = system. If there's additional rationale behind recommending the use of a lo= cal cache over a remote one, I'm not finding it in the document. I think we= maybe could get away with simply noting that operators SHOULD ensure prope= r geographic redundancy of the caches, perhaps with a comment similar to wh= at I said above regarding the relative insensitivity of distance between th= e cache and the router, if indeed that is accurate. In other words, if ther= e is a reason why a provider should NOT use simply an east and a west cache= (suitably sized, of course), or one per region of the country/world, pleas= e explain it in this section. "While a an operator using RPKI data MAY choose any polling frequency they wish for ensuring they have a fresh RPKI cache. However, if they use RPKI data as an input to operational routing decisions, they SHOULD ensure local cache freshness at least every four to six hours." If we're going to make a recommendation (even as a should) of a minimum ref= resh time, should we also be making a recommendation as to a maximum stalen= ess that is considered acceptable before the router should simply ignore th= e data from that cache and treat any routes it doesn't have a better set of= information about (from another cache) as unknown? I would figure it would= be something like a multiple of the refresh time. Note that I am not talki= ng about declaring a cache dead because the router can't talk to it, but th= e router making a decision as to the validity of the data it is receiving f= rom the cache. For example - cache has lost connectivity to the outside wor= ld, but is still reachable from the router, and the appropriate software is= running. It continues to respond, but its data is getting more and more st= ale as time goes on. That may be something better handled within rpki-route= r (6.4 talks about "cache has no data"), but that section implies that this= is primarily because the cache has just reset and hasn't recovered a compl= ete picture yet, not necessarily the case where the cache has what it belie= ves to be a complete picture, but it happens to be 24 hours out of date. If we're going to mention staleness here, it's perhaps worth also saying so= mething within this document. Also, there appears to be an editing error in= that first sentence. Other than those two items, I say ship it. Thanks, Wes > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Christopher Morrow > Sent: Friday, October 14, 2011 9:37 AM > To: sidr@ietf.org; sidr-chairs@ietf.org > Subject: [sidr] WGLC: draft-ietf-sidr-origin-ops > > SIDR Folk, > Please see the subject, draft-ietf-sidr-origin-ops is at version 11, > it's gotten some significant feedback over it's lifetime and is now > stabilized. Let's re-read and consider passing this up to the IESG for > their review, eh? > > Tools page for doc: > > Draft link: 11.txt> > > Please consider this draft in WGLC at this time, we'll end that in 2 > weeks time (10/28/2011). > > -Chris > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From randy@psg.com Fri Oct 14 09:28:18 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4283321F8C9E for ; Fri, 14 Oct 2011 09:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKx1Jo92m3d1 for ; Fri, 14 Oct 2011 09:28:17 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id DEBC921F8C9D for ; Fri, 14 Oct 2011 09:28:17 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1REkcH-000OVD-6z; Fri, 14 Oct 2011 16:28:13 +0000 Date: Fri, 14 Oct 2011 09:28:16 -0700 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Samuel Weiler , sidr wg list Subject: Re: [sidr] draft-ietf-sidr-rpki-rtr-17.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 16:28:18 -0000 >> could the chairs please pass $subject to the iesg? =A0i am only aware of >> one possible issue raised in wglc, tp asked for a hyphen somewhere but >> did not respond to my asking him to be specific where. =A0if this mystery >> is solved, i presume it can be handled in the iesg or auth48. >=20 > I believe Tom's issue was addressed in conversation (with mr weiler?), > but if not probably we can catch the problem in IESG review comment > recovery :) cool > (If the authors could wrangle: > ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) >=20 > ** Downref: Normative reference to an Informational RFC: RFC 4808 >=20 > that'd be helpful to the process, again these can be caught in the > IESG review fixups as well) see -18 going up now randy From internet-drafts@ietf.org Fri Oct 14 09:28:27 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAADC21F8CAA; Fri, 14 Oct 2011 09:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3tnyTDMhP+p; Fri, 14 Oct 2011 09:28:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739C921F8CA4; Fri, 14 Oct 2011 09:28:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111014162827.28764.94115.idtracker@ietfa.amsl.com> Date: Fri, 14 Oct 2011 09:28:27 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-18.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, 14 Oct 2011 16:28:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : The RPKI/Router Protocol Author(s) : Randy Bush Rob Austein Filename : draft-ietf-sidr-rpki-rtr-18.txt Pages : 25 Date : 2011-10-14 In order to formally validate the origin ASs of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-18.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-18.txt From christopher.morrow@gmail.com Fri Oct 14 09:53:21 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA01521F8B0F for ; Fri, 14 Oct 2011 09:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.524 X-Spam-Level: X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kh+EnE9ePbOK for ; Fri, 14 Oct 2011 09:53:21 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 58B4E21F8B09 for ; Fri, 14 Oct 2011 09:53:21 -0700 (PDT) Received: by iabn5 with SMTP id n5so2876830iab.31 for ; Fri, 14 Oct 2011 09:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uCNY4ObFLqQKxZzmc2OnJZKMy2QAR6+pY8LLga3lGQQ=; b=ZTAM5K43sh9EFxeYTwnyJYnp7uKUWq0XiVCPnBfKSw5bmpBhQc22StudAs/gvD3bTj WPJkCWCdsX/ich+ttTCC3ILgKQ/pmHgHCReMr8XMzbbWeSMFGD6G4zRYHymY0XorAjB7 jqQtK817NuT6smHmRz0HGH/UEpLJaneJ60uVA= MIME-Version: 1.0 Received: by 10.231.6.102 with SMTP id 38mr3970701iby.62.1318611201023; Fri, 14 Oct 2011 09:53:21 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.160.201 with HTTP; Fri, 14 Oct 2011 09:53:20 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Oct 2011 12:53:20 -0400 X-Google-Sender-Auth: 2D1lg1vVTxMUATXe5__-2X3slrk Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Samuel Weiler , sidr wg list Subject: Re: [sidr] draft-ietf-sidr-rpki-rtr-17.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 16:53:21 -0000 On Fri, Oct 14, 2011 at 12:28 PM, Randy Bush wrote: >> (If the authors could wrangle: >> =A0 ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) >> >> =A0 ** Downref: Normative reference to an Informational RFC: RFC 4808 >> >> that'd be helpful to the process, again these can be caught in the >> IESG review fixups as well) > > see -18 going up now ok, thanks! though I suspect you'd also have some stuff to pick at when iesg starts making noise... so was happy to just wait until then. -chris From randy@psg.com Fri Oct 14 10:34:16 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434EC21F8BDC for ; Fri, 14 Oct 2011 10:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mToVUvJBUmZL for ; Fri, 14 Oct 2011 10:34:15 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id D408F21F8BAA for ; Fri, 14 Oct 2011 10:34:15 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1REleA-000Oea-U4; Fri, 14 Oct 2011 17:34:15 +0000 Date: Fri, 14 Oct 2011 10:34:13 -0700 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] wg adoption for draft-ymbk-bgp-origin-validation-mib and draft-ymbk-rpki-rtr-protocol-mib X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 17:34:16 -0000 > Would the draft authors please submit new versions of these drafts as wg > drafts > > draft-ietf-sidr-bgp-origin-validation-mib > draft-ietf-sidr-rpki-rtr-protocol-mib in process among authors. but it may end up as only one draft. randy From randy@psg.com Fri Oct 14 10:34:56 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799F221F8BAA for ; Fri, 14 Oct 2011 10:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBtkyyO8ShGl for ; Fri, 14 Oct 2011 10:34:56 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id F32A321F8BA7 for ; Fri, 14 Oct 2011 10:34:55 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RElep-000Oem-Nj; Fri, 14 Oct 2011 17:34:55 +0000 Date: Fri, 14 Oct 2011 10:34:54 -0700 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] call for wg adoption of draft-turner-sidr-bgpsec-pki-profiles X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 17:34:56 -0000 > The chairs did not see sufficient response to this call for adoption to > indicate that the wg is willing to adopt this as a work item. yikes! this would be a mess. support From randy@psg.com Fri Oct 14 10:35:37 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9568321F8C3A for ; Fri, 14 Oct 2011 10:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCEzVb0A0kDi for ; Fri, 14 Oct 2011 10:35:37 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 48E5321F8BAA for ; Fri, 14 Oct 2011 10:35:37 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RElfR-000Oez-PZ; Fri, 14 Oct 2011 17:35:34 +0000 Date: Fri, 14 Oct 2011 10:35:32 -0700 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] call for wg adoption of draft-turner-sidr-bgpsec-algs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 17:35:37 -0000 > This call for adoption did not get sufficient support to judge the wg as > willing to adopt this draft. oh pfui. wtf is going on here? support From brian.peter.dickson@gmail.com Fri Oct 14 10:49:10 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F1F21F8CB2 for ; Fri, 14 Oct 2011 10:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBJjY4RP8edT for ; Fri, 14 Oct 2011 10:49:10 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C017221F8CA5 for ; Fri, 14 Oct 2011 10:49:09 -0700 (PDT) Received: by bkas6 with SMTP id s6so559537bka.31 for ; Fri, 14 Oct 2011 10:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=hNdSqH+6OCMRmXsUsck5CKhvvdAjia+K5CYQvuDzLPQ=; b=YxRVPtDxE9de6R8rKmWGeAZ2xodjGQpDyCFfU9VJpVvRZb1zMj8DTVZ8kxWk6G2zzw Ns56DAHOtrPBzkXVqMqYjCbtSqjI1Tn+3TvL131wRgoZdM75UiJe7IcBB0qS1EoIZgtq 4Moc1X3HanJdLlmaRd253+ZkdF9FeaZCgzy48= MIME-Version: 1.0 Received: by 10.204.130.9 with SMTP id q9mr7711732bks.43.1318614544211; Fri, 14 Oct 2011 10:49:04 -0700 (PDT) Received: by 10.204.157.27 with HTTP; Fri, 14 Oct 2011 10:49:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Oct 2011 13:49:04 -0400 Message-ID: From: Brian Dickson To: Sandra Murphy , sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [sidr] call for wg adoption of draft-turner-sidr-bgpsec-pki-profiles X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 17:49:10 -0000 Ditto. Support. Brian On Fri, Oct 14, 2011 at 1:34 PM, Randy Bush wrote: >> The chairs did not see sufficient response to this call for adoption to >> indicate that the wg is willing to adopt this as a work item. > > yikes! =A0this would be a mess. > > support > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From brian.peter.dickson@gmail.com Fri Oct 14 10:50:42 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959B421F8549; Fri, 14 Oct 2011 10:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEkdrRdLgEwi; Fri, 14 Oct 2011 10:50:42 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B63B621F8540; Fri, 14 Oct 2011 10:50:41 -0700 (PDT) Received: by bkas6 with SMTP id s6so560719bka.31 for ; Fri, 14 Oct 2011 10:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+9n3OrxftEVZz9AT9lMre0c6aP5YfTXOL5+G0EB7WSA=; b=pocAE80o56+6iul/jU9jb0mQ5iEiqOwvri//elfGIMltiGJMwMI4m4kNmqDPCN+TmE WDiqyepE3RI/C7mWGjPwNYMeHR+EsORt2gJnZePp93OLUNb/EHEtx6aojvO+vUJP1t6a QFbBNYVezs1IS4M6FPnCTO6WrEUsp7svWHD8A= MIME-Version: 1.0 Received: by 10.204.140.73 with SMTP id h9mr7590475bku.30.1318614619687; Fri, 14 Oct 2011 10:50:19 -0700 (PDT) Received: by 10.204.157.27 with HTTP; Fri, 14 Oct 2011 10:50:19 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Oct 2011 13:50:19 -0400 Message-ID: From: Brian Dickson To: Sandra Murphy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-sidr-rpsl-sig@tools.ietf.org, sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] status of draft-ietf-sidr-rpsl-sig X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 14 Oct 2011 17:50:42 -0000 Support. Brian On Fri, Oct 14, 2011 at 10:07 AM, Sandra Murphy wrote: > The draft draft-ietf-sidr-rpsl-sig has been expired for awhile. =A0The ed= itor > indicates that he is willing to continue progressing this work as long as > the wg is still interested. =A0This work was first submitted as a wg draf= t in > Dec 2008. > > Could the wg please indicate that there is still willingness to continue > this work? > > Please respond as to your continued support for this draft by 28 Oct 2011= . > > --Sandy, speaking as wg chair with regalia in place > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From brian.peter.dickson@gmail.com Fri Oct 14 10:53:34 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F5021F88B7 for ; Fri, 14 Oct 2011 10:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3YmkoHUzYTS for ; Fri, 14 Oct 2011 10:53:34 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id CFB3421F8C3A for ; Fri, 14 Oct 2011 10:53:33 -0700 (PDT) Received: by bkas6 with SMTP id s6so563734bka.31 for ; Fri, 14 Oct 2011 10:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PRijtOB06w/QluUFDkK/gA81bOEE6VUe14kchCN33bo=; b=FPx/S2cEyOCrBvj+Tpsl4uUsydFLd05suc2hgDJrx5pmC8C+G0wxKvLahY3x55OsC9 gbKI3OA5d9l7Ut+lePf7pVjOUPFhpLHYi7maejX/IfyhQeRRSlOb9CliIZ5TwYed5CW3 C4Alf0YwQldepRDu34u2W0xUaqSZfIqfEBf44= MIME-Version: 1.0 Received: by 10.204.140.73 with SMTP id h9mr7598073bku.30.1318614811972; Fri, 14 Oct 2011 10:53:31 -0700 (PDT) Received: by 10.204.157.27 with HTTP; Fri, 14 Oct 2011 10:53:31 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Oct 2011 13:53:31 -0400 Message-ID: From: Brian Dickson To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Sandra Murphy , sidr@ietf.org Subject: Re: [sidr] call for wg adoption of draft-turner-sidr-bgpsec-algs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 17:53:34 -0000 Maybe everyone was on vacation, or otherwise engaged? (I was not yet on the list to see the adoption call. Mea culpa.) Support, retroactively. Brian On Fri, Oct 14, 2011 at 1:35 PM, Randy Bush wrote: >> This call for adoption did not get sufficient support to judge the wg as >> willing to adopt this draft. > > oh pfui. =A0wtf is going on here? > > support > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From ietfc@btconnect.com Fri Oct 14 10:57:47 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4EE321F8C60 for ; Fri, 14 Oct 2011 10:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o80wrxb68jep for ; Fri, 14 Oct 2011 10:57:47 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD1E21F8C57 for ; Fri, 14 Oct 2011 10:57:46 -0700 (PDT) Received: from host86-163-147-122.range86-163.btcentralplus.com (HELO pc6) ([86.163.147.122]) by c2bthomr14.btconnect.com with SMTP id ETB04073; Fri, 14 Oct 2011 18:57:44 +0100 (BST) Message-ID: <02b301cc8a91$bb397e20$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Christopher Morrow" References: Date: Fri, 14 Oct 2011 18:52:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4E987817.004A, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.10.14.145715:17:7.586, ip=86.163.147.122, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_WWW, __URI_NO_PATH, __FRAUD_REFNUM, BODY_SIZE_1300_1399, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020B.4E987819.0063,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: sidr wg list Subject: Re: [sidr] draft-ietf-sidr-rpki-rtr-17.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 17:57:47 -0000 ----- Original Message ----- From: "Christopher Morrow" To: "Randy Bush" ; "t.petch" ; "Samuel Weiler" Cc: "sidr wg list" Sent: Friday, October 14, 2011 4:52 PM On Sun, Oct 9, 2011 at 10:10 AM, Randy Bush wrote: > could the chairs please pass $subject to the iesg? i am only aware of > one possible issue raised in wglc, tp asked for a hyphen somewhere but > did not respond to my asking him to be specific where. if this mystery > is solved, i presume it can be handled in the iesg or auth48. I believe Tom's issue was addressed in conversation (with mr weiler?), but if not probably we can catch the problem in IESG review comment recovery :) Chris I raised the problem but the solution, replacement text, was supplied by Joe in an e-mail to yourself (and the list) 27Sep2011. Tom Petch I'll forward on the document to the IESG today + the writeup, of course. -Chris (If the authors could wrangle: ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Downref: Normative reference to an Informational RFC: RFC 4808 that'd be helpful to the process, again these can be caught in the IESG review fixups as well) From jgs@bgp.nu Fri Oct 14 10:58:58 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FB721F8C77 for ; Fri, 14 Oct 2011 10:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.043 X-Spam-Level: X-Spam-Status: No, score=-102.043 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_IS_SMALL6=0.556, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYgQAZCa5znP for ; Fri, 14 Oct 2011 10:58:57 -0700 (PDT) Received: from bgp.nu (bgp.nu [147.28.0.53]) by ietfa.amsl.com (Postfix) with ESMTP id B40F921F8C74 for ; Fri, 14 Oct 2011 10:58:57 -0700 (PDT) Received: from [172.16.13.201] (75-151-14-10-Michigan.hfc.comcastbusiness.net [75.151.14.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id CD6F266CF2F; Fri, 14 Oct 2011 13:58:56 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: "John G. Scudder" In-Reply-To: Date: Fri, 14 Oct 2011 13:58:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7BA89613-FB83-440C-915A-945BFBEFC1A5@bgp.nu> References: To: Sandra Murphy X-Mailer: Apple Mail (2.1251.1) Cc: sidr@ietf.org Subject: Re: [sidr] call for wg adoption of draft-turner-sidr-bgpsec-algs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 17:58:58 -0000 Retro-support. --John On Oct 14, 2011, at 10:50 AM, Sandra Murphy wrote: > This call for adoption did not get sufficient support to judge the wg = as willing to adopt this draft. >=20 > --Sandy, speaking as wg chair with wg ceremonial garb donned >=20 > On Tue, 9 Aug 2011, Sandra Murphy wrote: >=20 >> The working group has been requested to adopt >> draft-turner-sidr-bgpsec-algs as a working group draft. >>=20 >> The draft is available at >> http://tools.ietf.org/html/draft-turner-sidr-bgpsec-algs >>=20 >> Please respond to the list to say whether you accept this draft as a >> working group draft and are willing to work on it. Remember that you = do >> not need to accept all content in a draft to adopt, as draft editors = are >> required to reflect the consensus of the working group. >>=20 >> This call will end 23 Aug 2011 >>=20 >> --Sandy, speaking as wg co-chair >> _______________________________________________ >> 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 christopher.morrow@gmail.com Fri Oct 14 11:28:23 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868B221F8CD1 for ; Fri, 14 Oct 2011 11:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.239 X-Spam-Level: X-Spam-Status: No, score=-103.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfx9PCjf-SsR for ; Fri, 14 Oct 2011 11:28:23 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E8D9621F8CC7 for ; Fri, 14 Oct 2011 11:28:22 -0700 (PDT) Received: by qadb12 with SMTP id b12so1402814qad.31 for ; Fri, 14 Oct 2011 11:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rzQTlxvHsQ+78rkIFGlTMiuwPA06bFoRLFTnOJRMQsQ=; b=k9iyG5c3u6TGPqxJiQX+2yMe/3ivUYAWeNBOvg+WaPYellJQMBQerBw3b681CGgSfA cbe3LMaqSCaQ5rrtF2YeTD/NC66BUG8zk+WYuuStxYOyj8L5UadwtkQqpQq3Aq4lG9Yf cp2+GVbDluHBk5w6WufvbKjP2IpUAf9kHREHc= MIME-Version: 1.0 Received: by 10.68.12.71 with SMTP id w7mr18684124pbb.53.1318616901975; Fri, 14 Oct 2011 11:28:21 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.68.42.6 with HTTP; Fri, 14 Oct 2011 11:28:21 -0700 (PDT) In-Reply-To: <02b301cc8a91$bb397e20$4001a8c0@gateway.2wire.net> References: <02b301cc8a91$bb397e20$4001a8c0@gateway.2wire.net> Date: Fri, 14 Oct 2011 14:28:21 -0400 X-Google-Sender-Auth: rrzxpk37tl6_DCcFjgzOkk3ePYw Message-ID: From: Christopher Morrow To: "t.petch" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] draft-ietf-sidr-rpki-rtr-17.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 18:28:23 -0000 On Fri, Oct 14, 2011 at 12:52 PM, t.petch wrote: > ----- Original Message ----- > From: "Christopher Morrow" > To: "Randy Bush" ; "t.petch" ; "Samue= l > Weiler" > Cc: "sidr wg list" > Sent: Friday, October 14, 2011 4:52 PM > On Sun, Oct 9, 2011 at 10:10 AM, Randy Bush wrote: >> could the chairs please pass $subject to the iesg? i am only aware of >> one possible issue raised in wglc, tp asked for a hyphen somewhere but >> did not respond to my asking him to be specific where. if this mystery >> is solved, i presume it can be handled in the iesg or auth48. > > I believe Tom's issue was addressed in conversation (with mr weiler?), > but if not probably we can catch the problem in IESG review comment > recovery :) > > > Chris > > I raised the problem but the solution, replacement text, was supplied by = Joe in > an e-mail to yourself (and the list) 27Sep2011. > ah! I skipped that.. I'll send that along to randy if he's not already caught the fix. > Tom Petch > > > I'll forward on the document to the IESG today + the writeup, of course. > > -Chris > > (If the authors could wrangle: > =A0** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) > > =A0** Downref: Normative reference to an Informational RFC: RFC 4808 > > that'd be helpful to the process, again these can be caught in the > IESG review fixups as well) > > > From touch@isi.edu Fri Oct 14 13:55:23 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645C421F8D5A for ; Fri, 14 Oct 2011 13:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22icAb4XDgIH for ; Fri, 14 Oct 2011 13:55:23 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id E136D21F8D59 for ; Fri, 14 Oct 2011 13:55:22 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p9EKspvc011298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 14 Oct 2011 13:54:51 -0700 (PDT) Message-ID: <4E98A19B.2060301@isi.edu> Date: Fri, 14 Oct 2011 13:54:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Randy Bush References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Samuel Weiler , sidr wg list Subject: Re: [sidr] draft-ietf-sidr-rpki-rtr-17.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 20:55:23 -0000 On 10/14/2011 9:28 AM, Randy Bush wrote: >>> could the chairs please pass $subject to the iesg? i am only aware of >>> one possible issue raised in wglc, tp asked for a hyphen somewhere but >>> did not respond to my asking him to be specific where. if this mystery >>> is solved, i presume it can be handled in the iesg or auth48. >> >> I believe Tom's issue was addressed in conversation (with mr weiler?), >> but if not probably we can catch the problem in IESG review comment >> recovery :) > > cool > >> (If the authors could wrangle: >> ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) >> >> ** Downref: Normative reference to an Informational RFC: RFC 4808 >> >> that'd be helpful to the process, again these can be caught in the >> IESG review fixups as well) > > see -18 going up now RFC 2385 references should not be replaced with RFC 5925; they're incorrect as currently written (in -18); they refer to sections and text that don't exist in RFC 5925 (e.g., how to configure TCP MD5)y. This doc deliberately cites an obsoleted doc; the best solution would be to ask the RFC-Editor whether it's preferable to leave it in the normative section or move it to informative. Either way, the reference should remain directly to 2385 when TCP MD5 is discussed. Joe From sra@hactrn.net Fri Oct 14 14:24:36 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C2721F8C60 for ; Fri, 14 Oct 2011 14:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.618 X-Spam-Level: X-Spam-Status: No, score=-99.618 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, IP_NOT_FRIENDLY=0.334, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yd-iOXJkVt7V for ; Fri, 14 Oct 2011 14:24:35 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD5E21F8BB3 for ; Fri, 14 Oct 2011 14:24:35 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-69-249-171-88.hsd1.nj.comcast.net [69.249.171.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 94D6FB848 for ; Fri, 14 Oct 2011 21:24:34 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 0EBB76016C6 for ; Fri, 14 Oct 2011 17:24:33 -0400 (EDT) Date: Fri, 14 Oct 2011 17:24:33 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20111014212433.0EBB76016C6@minas-ithil.hactrn.net> Subject: Re: [sidr] call for wg adoption of draft-turner-sidr-bgpsec-pki-profiles X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 21:24:36 -0000 At Fri, 14 Oct 2011 10:34:54 -0700, Randy Bush wrote: > > > The chairs did not see sufficient response to this call for adoption to > > indicate that the wg is willing to adopt this as a work item. > > yikes! this would be a mess. > > support +1 From sra@hactrn.net Fri Oct 14 14:25:20 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F3F21F8C6F for ; Fri, 14 Oct 2011 14:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.618 X-Spam-Level: X-Spam-Status: No, score=-99.618 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, IP_NOT_FRIENDLY=0.334, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2C6-wnxBHnfg for ; Fri, 14 Oct 2011 14:25:20 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) by ietfa.amsl.com (Postfix) with ESMTP id 4867F21F8BB3 for ; Fri, 14 Oct 2011 14:25:20 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-69-249-171-88.hsd1.nj.comcast.net [69.249.171.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id E4820B848 for ; Fri, 14 Oct 2011 21:25:19 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 81F0D6016E7 for ; Fri, 14 Oct 2011 17:25:19 -0400 (EDT) Date: Fri, 14 Oct 2011 17:25:19 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20111014212519.81F0D6016E7@minas-ithil.hactrn.net> Subject: Re: [sidr] call for wg adoption of draft-turner-sidr-bgpsec-algs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 21:25:20 -0000 At Fri, 14 Oct 2011 10:35:32 -0700, Randy Bush wrote: > > > This call for adoption did not get sufficient support to judge the wg as > > willing to adopt this draft. > > oh pfui. wtf is going on here? > > support +1 From Sandra.Murphy@cobham.com Fri Oct 14 14:50:47 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6273E21F8753 for ; Fri, 14 Oct 2011 14:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DBtZstwHWdN for ; Fri, 14 Oct 2011 14:50:46 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id AD8B821F8726 for ; Fri, 14 Oct 2011 14:50:46 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p9ELojQX017743 for ; Fri, 14 Oct 2011 16:50:45 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p9ELojXp017594 for ; Fri, 14 Oct 2011 16:50:46 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.149]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 17:50:45 -0400 Date: Fri, 14 Oct 2011 17:50:45 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; boundary="108376495-18642-1318628647=:4820" X-OriginalArrivalTime: 14 Oct 2011 21:50:45.0823 (UTC) FILETIME=[53E97CF0:01CC8ABB] Subject: Re: [sidr] about a router AS-related certificate (fwd) X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 14 Oct 2011 21:50:47 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --108376495-18642-1318628647=:4820 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sorry, somehow did NOT reply all. --Sandy ---------- Forwarded message ---------- Date: Fri, 14 Oct 2011 17:44:07 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Brian Dickson Subject: Re: [sidr] about a router AS-related certificate On Fri, 14 Oct 2011, Brian Dickson wrote: > Hi, Sandy, >=20 > Would it be too much to ask, to get a brief summary email sent to the > list, of recent last-calls or adoption-calls, and pro/con responses > levels? Not sure if you mean on a regular periodic basis or right now for the recen= t=20 flurry of wg calls. The summary of the recent flurry can be constructed well enough. (If you w= ant=20 a rough immediate idea, the mail archive can display a thread index of the= =20 mail.) A periodic message is also possible, if people would find that useful. You= =20 indicate that you just recently joined the list, so maybe you don't realize= =20 that this wg is particularly bursty, but obviously there's reasonable=20 periodicity that could be used. >=20 > This would be to get an idea of whether some might have been missed, > and which need support to progress? > Some care would be wise. A message from the wg chairs to say "hey, wg, you= =20 haven't demonstrated support for draft X" might be construed as undue chair influence on the wg consensus. The periodic summary you suggest is objective enough that it could/might pa= ss=20 muster. > And I'd suggest that if there were not-many pros, and none or much > fewer than normal cons, that asking again to boost the pro responses, > may be all that is needed. IMHO, the wg chairs taking steps to boost the pro response would be truly= =20 skating too close to the edge of undue influence. OVer the edge, maybe. >=20 > The inter-dependencies of some of these drafts, makes it pretty important= =2E >=20 > BTW, I would be more than happy to contribute to the WG in whatever way I= =20 > can. > Great! --Sandy > Thanks, >=20 > Brian Dickson >=20 > On Fri, Oct 14, 2011 at 10:50 AM, Sandra Murphy > wrote: >> The wg has just demonstrated a lack of support for adoption of a suggest= ed >> cert profile for routers in draft-turner-sidr-bgpsec-pki-profiles. >>=20 >> Unfortunately, a router certificate is already mentioned in existing wg >> drafts. >>=20 >>=20 >> The bgpsec-overview draft says: >>=20 >> =A0 BGPSEC extends the RPKI by adding an additional type of certificate, >> =A0 referred to as a BGPSEC router certificate, that binds an AS number >> =A0 to a public signature verification key, the corresponding private ke= y >> =A0 of which is held by one or more BGP speakers within this AS. >>=20 >>=20 >> The bgpsec-ops drafts says: >>=20 >> =A0 AS/Router Certificates >>=20 >>=20 >> =A0 A site/operator MAY use a single certificate/key in all their >> =A0 routers, one certificate/key per router, or any granularity in >> =A0 between. >>=20 >> =A0 A large operator, concerned that a compromise of one router's key >> =A0 would make many routers vulnerable, MAY accept a more complex >> =A0 certificate/key distribution burden to reduce this exposure. >>=20 >> =A0 On the other extreme, an edge site with one or two routers MAY use a >> =A0 single certificate/key. >>=20 >>=20 >> Is there an alternative router certificate that the wg would like to ado= pt? >>=20 >> If the wg did not realize that the router certificate was needed to fulf= ill >> existing wg drafts, please speak up. >>=20 >> At any rate, the wg needs to indicate how to proceed here. >>=20 >> --Sandy, speaking as wg chair >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> --108376495-18642-1318628647=:4820-- From shane@castlepoint.net Fri Oct 14 17:51:33 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD68821F8B62; Fri, 14 Oct 2011 17:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5JvKqBHCvGw; Fri, 14 Oct 2011 17:51:33 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 4EED821F8B5E; Fri, 14 Oct 2011 17:51:33 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id EBDE33681A4; Fri, 14 Oct 2011 18:51:25 -0600 (MDT) Received: from mbpw.castlepoint.net (65-102-206-76.hlrn.qwest.net [65.102.206.76]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Fri, 14 Oct 2011 18:51:25 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.102.206.76; client-port=56643; syn-fingerprint=65535:54:1:64:M1452,N,W2,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Fri, 14 Oct 2011 18:51:10 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <56054AD9-F37F-4CB8-A8D0-9C6D906BEFFD@castlepoint.net> References: To: Sandra Murphy X-Mailer: Apple Mail (2.1244.3) Cc: draft-ietf-sidr-rpsl-sig@tools.ietf.org, sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] status of draft-ietf-sidr-rpsl-sig X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 15 Oct 2011 00:51:33 -0000 Support. -shane On Oct 14, 2011, at 8:07 AM, Sandra Murphy wrote: > The draft draft-ietf-sidr-rpsl-sig has been expired for awhile. The = editor indicates that he is willing to continue progressing this work as = long as the wg is still interested. This work was first submitted as a = wg draft in Dec 2008. >=20 > Could the wg please indicate that there is still willingness to = continue this work? >=20 > Please respond as to your continued support for this draft by 28 Oct = 2011. >=20 > --Sandy, speaking as wg chair with regalia in place > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From gih@apnic.net Fri Oct 14 17:58:14 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1386921F8BBE; Fri, 14 Oct 2011 17:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KOEXPL6Y8Wh; Fri, 14 Oct 2011 17:58:13 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 89FA321F8B9B; Fri, 14 Oct 2011 17:58:13 -0700 (PDT) Received: from [192.168.1.69] (unknown [12.185.65.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 870E2B66B3; Sat, 15 Oct 2011 10:58:08 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Sat, 15 Oct 2011 11:58:08 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sandra Murphy X-Mailer: Apple Mail (2.1251.1) Cc: draft-ietf-sidr-rpsl-sig@tools.ietf.org, sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] status of draft-ietf-sidr-rpsl-sig X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 15 Oct 2011 00:58:14 -0000 support On 15/10/2011, at 1:07 AM, Sandra Murphy wrote: > The draft draft-ietf-sidr-rpsl-sig has been expired for awhile. The = editor indicates that he is willing to continue progressing this work as = long as the wg is still interested. This work was first submitted as a = wg draft in Dec 2008. >=20 > Could the wg please indicate that there is still willingness to = continue this work? >=20 > Please respond as to your continued support for this draft by 28 Oct = 2011. >=20 > --Sandy, speaking as wg chair with regalia in place > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr -- Geoff Huston Chief Scientist, APNIC +61 7 3858 3100 gih@apnic.net From aservin@lacnic.net Fri Oct 14 18:53:42 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B75621F8CD4; Fri, 14 Oct 2011 18:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.91 X-Spam-Level: X-Spam-Status: No, score=0.91 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_DIALUP=0.862, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Su88vASclN2; Fri, 14 Oct 2011 18:53:42 -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 EE32821F8BE9; Fri, 14 Oct 2011 18:53:41 -0700 (PDT) Received: from [192.168.1.103] (r186-48-192-106.dialup.adsl.anteldata.net.uy [186.48.192.106]) by mail.lacnic.net.uy (Postfix) with ESMTP id F0ED8308458; Fri, 14 Oct 2011 23:53:38 -0200 (UYST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: Date: Fri, 14 Oct 2011 23:53:35 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Christopher Morrow X-Mailer: Apple Mail (2.1244.3) 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 Cc: sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 15 Oct 2011 01:53:42 -0000 I just have one comment. What's the rationale of this change from version 10 to 11? 10 "Announcements with Invalid origins MAY be used, but SHOULD be=20 less preferred than those with Valid or NotFound." 11 "Announcements with Invalid origins SHOULD NOT be used, but MAY be used to meet special operational needs. In such circumstances, the announcement SHOULD have a lower preference than that given to Valid or NotFound." I thought that the "common understanding" was to be more = flexible as version 10 indicates. For various reasons I think that = recommending version 11 would end up with some problems because initial = inexperience in RPKI (configuration, operation, etc.) and people being = very strict in their policies. Regards, as On 14 Oct 2011, at 11:36, Christopher Morrow wrote: > SIDR Folk, > Please see the subject, draft-ietf-sidr-origin-ops is at version 11, > it's gotten some significant feedback over it's lifetime and is now > stabilized. Let's re-read and consider passing this up to the IESG for > their review, eh? >=20 > Tools page for doc: > > Draft link: = >=20 > Please consider this draft in WGLC at this time, we'll end that in 2 > weeks time (10/28/2011). >=20 > -Chris > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From eosterweil@verisign.com Fri Oct 14 19:03:32 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BA321F8B5C; Fri, 14 Oct 2011 19:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSpnjFKMuqRX; Fri, 14 Oct 2011 19:03:31 -0700 (PDT) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id A249821F8C77; Fri, 14 Oct 2011 19:03:09 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP; Fri, 14 Oct 2011 19:03:31 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p9F22fCA011498; Fri, 14 Oct 2011 22:02:41 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.1.96]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 22:02:41 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Fri, 14 Oct 2011 22:02:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1DC11029-DCBE-4FBA-803F-5DA4225AA267@verisign.com> References: To: Sandra Murphy X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 15 Oct 2011 02:02:41.0571 (UTC) FILETIME=[85999730:01CC8ADE] Cc: draft-ietf-sidr-rpsl-sig@tools.ietf.org, sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] status of draft-ietf-sidr-rpsl-sig X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 15 Oct 2011 02:03:32 -0000 Support Eric On Oct 14, 2011, at 10:07 AM, Sandra Murphy wrote: > The draft draft-ietf-sidr-rpsl-sig has been expired for awhile. The = editor indicates that he is willing to continue progressing this work as = long as the wg is still interested. This work was first submitted as a = wg draft in Dec 2008. >=20 > Could the wg please indicate that there is still willingness to = continue this work? >=20 > Please respond as to your continued support for this draft by 28 Oct = 2011. >=20 > --Sandy, speaking as wg chair with regalia in place > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From danny@tcb.net Fri Oct 14 19:06:41 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D65021F8B36; Fri, 14 Oct 2011 19:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIVBnHHzjEro; Fri, 14 Oct 2011 19:06:40 -0700 (PDT) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id F140321F8B1E; Fri, 14 Oct 2011 19:06:34 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP; Fri, 14 Oct 2011 19:06:40 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p9F26Xoo011756; Fri, 14 Oct 2011 22:06:33 -0400 Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com ([10.100.0.219]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 22:06:33 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Fri, 14 Oct 2011 22:06:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <243D9B1F-D6AC-48CE-89EE-C8E518838B6B@tcb.net> References: To: Sandra Murphy X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 15 Oct 2011 02:06:33.0810 (UTC) FILETIME=[10067320:01CC8ADF] Cc: draft-ietf-sidr-rpsl-sig@tools.ietf.org, sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] status of draft-ietf-sidr-rpsl-sig X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 15 Oct 2011 02:06:41 -0000 Support... -danny On Oct 14, 2011, at 10:07 AM, Sandra Murphy wrote: > The draft draft-ietf-sidr-rpsl-sig has been expired for awhile. The = editor indicates that he is willing to continue progressing this work as = long as the wg is still interested. This work was first submitted as a = wg draft in Dec 2008. >=20 > Could the wg please indicate that there is still willingness to = continue this work? >=20 > Please respond as to your continued support for this draft by 28 Oct = 2011. >=20 > --Sandy, speaking as wg chair with regalia in place > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Fri Oct 14 21:18:40 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C361121F8BB9 for ; Fri, 14 Oct 2011 21:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4wbPuGBJkh0 for ; Fri, 14 Oct 2011 21:18:40 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 78C5821F8B77 for ; Fri, 14 Oct 2011 21:18:40 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1REvhm-0001Hh-I6; Sat, 15 Oct 2011 04:18:38 +0000 Date: Fri, 14 Oct 2011 21:18:38 -0700 Message-ID: From: Randy Bush To: Arturo Servin In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 15 Oct 2011 04:18:40 -0000 > What's the rationale of this change from version 10 to 11? after much discussion with ops and security folk, it is the purpose of the whole exercise randy From randy@psg.com Fri Oct 14 21:22:58 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED4221F8BCB for ; Fri, 14 Oct 2011 21:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1rYz2drsGkf for ; Fri, 14 Oct 2011 21:22:58 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id A030221F8B1F for ; Fri, 14 Oct 2011 21:22:58 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1REvly-0001IC-Cd; Sat, 15 Oct 2011 04:22:58 +0000 Date: Fri, 14 Oct 2011 21:22:57 -0700 Message-ID: From: Randy Bush To: Arturo Servin In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 15 Oct 2011 04:22:59 -0000 >> What's the rationale of this change from version 10 to 11? > after much discussion with ops and security folk, it is the purpose of > the whole exercise. you wanna stop 7007? fwiw, it has swung back and forth a few times randy From tim@ripe.net Sat Oct 15 03:01:30 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B9521F8593 for ; Sat, 15 Oct 2011 03:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44pmBIi2rVC3 for ; Sat, 15 Oct 2011 03:01:29 -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 9358E21F8541 for ; Sat, 15 Oct 2011 03:01:29 -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 1RF13S-0005h1-Md; Sat, 15 Oct 2011 12:01:26 +0200 Received: from timbru.vpn.ripe.net ([193.0.21.62]) by ayeaye.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1RF13S-0003uP-6m; Sat, 15 Oct 2011 12:01:22 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: Date: Sat, 15 Oct 2011 12:01:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sandra Murphy X-Mailer: Apple Mail (2.1084) X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.4 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.5 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] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719c50fae89d33e1937ea9249c78650dc73 Cc: sidr wg list Subject: Re: [sidr] status of draft-ietf-sidr-rpsl-sig X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 15 Oct 2011 10:01:30 -0000 support On Oct 14, 2011, at 4:07 PM, Sandra Murphy wrote: > The draft draft-ietf-sidr-rpsl-sig has been expired for awhile. The = editor indicates that he is willing to continue progressing this work as = long as the wg is still interested. This work was first submitted as a = wg draft in Dec 2008. >=20 > Could the wg please indicate that there is still willingness to = continue this work? >=20 > Please respond as to your continued support for this draft by 28 Oct = 2011. >=20 > --Sandy, speaking as wg chair with regalia in place > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From kent@bbn.com Mon Oct 17 07:54:07 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5FB21F8C1D for ; Mon, 17 Oct 2011 07:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.338 X-Spam-Level: X-Spam-Status: No, score=-106.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrfPuPamhemx for ; Mon, 17 Oct 2011 07:53:54 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7809221F8C19 for ; Mon, 17 Oct 2011 07:53:51 -0700 (PDT) Received: from dhcp89-089-093.bbn.com ([128.89.89.93]:49167) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RFoZa-000D8D-L8; Mon, 17 Oct 2011 10:53:50 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 17 Oct 2011 10:47:03 -0400 To: Sandra Murphy From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] about a router AS-related certificate X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 17 Oct 2011 14:54:07 -0000 At 10:50 AM -0400 10/14/11, Sandra Murphy wrote: >The wg has just demonstrated a lack of support for adoption of a >suggested cert profile for routers in >draft-turner-sidr-bgpsec-pki-profiles. > >Unfortunately, a router certificate is already mentioned in existing >wg drafts. Sandy, Since the WG is proceeding with the BGPSEC protocol and architecture, there is a need for a cert profile for routers. It also makes sense to have these certs be tied to the RPLI, since theses certs are linked to the AS# of the net with which the router is associated. So, I believe that WG members (including me?) were not paying attention for this call for adoption. Can we have a do over :-)? Steve From kent@bbn.com Mon Oct 17 07:54:08 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E33721F8C1E for ; Mon, 17 Oct 2011 07:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.39 X-Spam-Level: X-Spam-Status: No, score=-106.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQtFfmxYkXHh for ; Mon, 17 Oct 2011 07:54:07 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D239F21F8C19 for ; Mon, 17 Oct 2011 07:54:07 -0700 (PDT) Received: from dhcp89-089-093.bbn.com ([128.89.89.93]:49167) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RFoZb-000D8D-JW; Mon, 17 Oct 2011 10:53:51 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 17 Oct 2011 10:49:21 -0400 To: Sandra Murphy From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] call for wg adoption of draft-turner-sidr-bgpsec-algs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 14:54:08 -0000 At 10:50 AM -0400 10/14/11, Sandra Murphy wrote: >This call for adoption did not get sufficient support to judge the >wg as willing to adopt this draft. > >--Sandy, speaking as wg chair with wg ceremonial garb donned > As with the router cert profile, I think work on the topic specified by this doc needs to be pursued, as part of the BGPSEC activity that has already been approved. Can we poll WG again, now that summer is over? Steve From warren@kumari.net Mon Oct 17 10:06:58 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9126B21F8B2B for ; Mon, 17 Oct 2011 10:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCsVQoUkEvUf for ; Mon, 17 Oct 2011 10:06:58 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3B921F8586 for ; Mon, 17 Oct 2011 10:06:57 -0700 (PDT) Received: from [192.168.1.8] (83-103-81-66.ip.fastwebnet.it [83.103.81.66]) by vimes.kumari.net (Postfix) with ESMTPSA id B828F1B4041E; Mon, 17 Oct 2011 13:06:55 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: Date: Mon, 17 Oct 2011 13:06:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5CB5FCB9-1C72-4F4A-A517-D7457D132149@kumari.net> References: To: Sandra Murphy X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: Re: [sidr] about a router AS-related certificate X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 17 Oct 2011 17:06:58 -0000 On Oct 17, 2011, at 10:47 AM, Stephen Kent wrote: > At 10:50 AM -0400 10/14/11, Sandra Murphy wrote: >> The wg has just demonstrated a lack of support for adoption of a = suggested cert profile for routers in = draft-turner-sidr-bgpsec-pki-profiles. >>=20 >> Unfortunately, a router certificate is already mentioned in existing = wg drafts. >=20 > Sandy, >=20 > Since the WG is proceeding with the BGPSEC protocol and architecture, > there is a need for a cert profile for routers. It also makes sense to = have > these certs be tied to the RPLI, since theses certs are linked to the > AS# of the net with which the router is associated. So, I believe = that > WG members (including me?) were not paying attention for this call for = adoption. I for one completely missed the CfA[0]=85. and, had I not, would have = supported adoption=85. >=20 > Can we have a do over :-)? >=20 Yah, please=85 W [0]: Sorry, I've been reading too many of the OAM discussions and = figured I wasn't cool if I didn't unnecessarily abbreviate=85. > Steve > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From warren@kumari.net Mon Oct 17 10:08:16 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B8321F8C73 for ; Mon, 17 Oct 2011 10:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6WBFAPMu2Ly for ; Mon, 17 Oct 2011 10:08:15 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id D4B8121F8C72 for ; Mon, 17 Oct 2011 10:08:15 -0700 (PDT) Received: from [192.168.1.8] (83-103-81-66.ip.fastwebnet.it [83.103.81.66]) by vimes.kumari.net (Postfix) with ESMTPSA id 9BF231B4041E; Mon, 17 Oct 2011 13:08:14 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <7BA89613-FB83-440C-915A-945BFBEFC1A5@bgp.nu> Date: Mon, 17 Oct 2011 13:08:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4B7BF0D4-7A85-46AF-9B46-0255654C68DF@kumari.net> References: <7BA89613-FB83-440C-915A-945BFBEFC1A5@bgp.nu> To: John G. Scudder X-Mailer: Apple Mail (2.1084) Cc: Sandra Murphy , sidr@ietf.org Subject: Re: [sidr] call for wg adoption of draft-turner-sidr-bgpsec-algs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 17:08:16 -0000 Retro-support as well=85 W=20 P.S: Is there a way to retro-trade as well? how about retro-betting?=20 On Oct 14, 2011, at 1:58 PM, John G. Scudder wrote: > Retro-support. >=20 > --John >=20 > On Oct 14, 2011, at 10:50 AM, Sandra Murphy wrote: >=20 >> This call for adoption did not get sufficient support to judge the wg = as willing to adopt this draft. >>=20 >> --Sandy, speaking as wg chair with wg ceremonial garb donned >>=20 >> On Tue, 9 Aug 2011, Sandra Murphy wrote: >>=20 >>> The working group has been requested to adopt >>> draft-turner-sidr-bgpsec-algs as a working group draft. >>>=20 >>> The draft is available at >>> http://tools.ietf.org/html/draft-turner-sidr-bgpsec-algs >>>=20 >>> Please respond to the list to say whether you accept this draft as a >>> working group draft and are willing to work on it. Remember that you = do >>> not need to accept all content in a draft to adopt, as draft editors = are >>> required to reflect the consensus of the working group. >>>=20 >>> This call will end 23 Aug 2011 >>>=20 >>> --Sandy, speaking as wg co-chair >>> _______________________________________________ >>> 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 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From warren@kumari.net Mon Oct 17 10:37:11 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2772221F8BC5 for ; Mon, 17 Oct 2011 10:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VR4yMUSgcgXp for ; Mon, 17 Oct 2011 10:37:10 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id ACECD21F8BB5 for ; Mon, 17 Oct 2011 10:37:10 -0700 (PDT) Received: from [192.168.1.8] (83-103-81-66.ip.fastwebnet.it [83.103.81.66]) by vimes.kumari.net (Postfix) with ESMTPSA id A990E1B407D7; Mon, 17 Oct 2011 13:37:00 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: Date: Mon, 17 Oct 2011 13:36:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <39A91CFA-54BE-44DC-9178-A1A2A71485E6@kumari.net> References: To: Sandra Murphy X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: Re: [sidr] call for wg adoption of draft-turner-sidr-bgpsec-pki-profiles X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 17:37:11 -0000 On Oct 14, 2011, at 10:46 AM, John Scudder wrote: > Oops. Belated support. Me too=85.=20 [ I'm reading mail (from a hotel with no in room Internet :-() all out = of order, so=85 ]=20 W >=20 > --John >=20 > On Oct 14, 2011, at 10:44 AM, Sandra Murphy wrote: >=20 >> The chairs did not see sufficient response to this call for adoption = to indicate that the wg is willing to adopt this as a work item. >>=20 >> --Sandy, speaking as wg chair with wg ceremonial garb donned >>=20 >> On Tue, 9 Aug 2011, Sandra Murphy wrote: >>=20 >>> The working group has been requested to adopt = draft-turner-sidr-bgpsec-pki-profiles as a working group draft. >>>=20 >>> The draft is available at = http://tools.ietf.org/html/draft-turner-sidr-bgpsec-pki-profiles >>>=20 >>> Please respond to the list to say whether you accept this draft as a = working group draft and are willing to work on it. Remember that you do = not need to accept all content in a draft to adopt, as draft editors are = required to reflect the consensus of the working group. >>>=20 >>> This call will end 23 Aug 2011 >>>=20 >>> --Sandy, speaking as wg co-chair >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>>=20 >> _______________________________________________ >> 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 >=20 From internet-drafts@ietf.org Mon Oct 17 13:53:19 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDDE1F0C3F; Mon, 17 Oct 2011 13:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eff0L7njHWQK; Mon, 17 Oct 2011 13:53:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001CA1F0C44; Mon, 17 Oct 2011 13:53: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: 3.60 Message-ID: <20111017205318.16765.81353.idtracker@ietfa.amsl.com> Date: Mon, 17 Oct 2011 13:53:18 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-ghostbusters-15.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 20:53:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : The RPKI Ghostbusters Record Author(s) : Randy Bush Filename : draft-ietf-sidr-ghostbusters-15.txt Pages : 9 Date : 2011-10-17 In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information which might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This draft describes the RPKI Ghostbusters Record containing human contact information which may be verified (indirectly) by a CA certificate. The data in the record are those of a severely profiled vCard. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-ghostbusters-15.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-ghostbusters-15.txt From internet-drafts@ietf.org Wed Oct 19 15:03:56 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DBD1F0C5D; Wed, 19 Oct 2011 15:03:56 -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.099, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4O5+AwHETqr; Wed, 19 Oct 2011 15:03:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685A11F0C4B; Wed, 19 Oct 2011 15:03:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111019220356.16573.20187.idtracker@ietfa.amsl.com> Date: Wed, 19 Oct 2011 15:03:56 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-reqs-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 22:03:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : Security Requirements for BGP Path Validation Author(s) : Steven M. Bellovin Randy Bush Dave Ward Filename : draft-ietf-sidr-bgpsec-reqs-01.txt Pages : 9 Date : 2011-10-19 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-reqs-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-reqs-01.txt From randy@psg.com Wed Oct 19 15:19:49 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A0A11E8096 for ; Wed, 19 Oct 2011 15:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TROqqPwvdhHi for ; Wed, 19 Oct 2011 15:19:49 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 90F2911E808A for ; Wed, 19 Oct 2011 15:19:49 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RGeUG-000EVP-MJ for sidr@ietf.org; Wed, 19 Oct 2011 22:19:48 +0000 Date: Wed, 19 Oct 2011 15:19:48 -0700 Message-ID: From: Randy Bush To: sidr wg list User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: [sidr] request to last call draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Oct 2011 22:19:49 -0000 chairs, i think draft-ietf-sidr-bgpsec-reqs-01.txt is ready for wglc randy From internet-drafts@ietf.org Wed Oct 19 15:45:23 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D23611E80B3; Wed, 19 Oct 2011 15:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIvZ3J56Qo5P; Wed, 19 Oct 2011 15:45:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB8221F8A6C; Wed, 19 Oct 2011 15:45:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111019224523.16220.18338.idtracker@ietfa.amsl.com> Date: Wed, 19 Oct 2011 15:45:23 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 22:45:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : BGPsec Operational Considerations Author(s) : Randy Bush Filename : draft-ietf-sidr-bgpsec-ops-01.txt Pages : 10 Date : 2011-10-19 Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present them. It is expected to evolve as BGPsec is formalized and initially deployed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-ops-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-ops-01.txt From Sandra.Murphy@cobham.com Thu Oct 20 07:50:12 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDD721F8BA4 for ; Thu, 20 Oct 2011 07:50: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oQ2dQfbXqWt for ; Thu, 20 Oct 2011 07:50:12 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 20BEF21F8B66 for ; Thu, 20 Oct 2011 07:50:11 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p9KEoAIV003381 for ; Thu, 20 Oct 2011 09:50:10 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p9KEoAZP012483 for ; Thu, 20 Oct 2011 09:50:11 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.187]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Oct 2011 10:50:10 -0400 Date: Thu, 20 Oct 2011 10:50:09 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 20 Oct 2011 14:50:10.0530 (UTC) FILETIME=[90FBDC20:01CC8F37] Subject: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 20 Oct 2011 14:50:12 -0000 The authors have requested a WG LC for draft "Algorithm Agility Procedure for RPKI." The document and the draft version history are available at http://tools.ietf.org/html/draft-ietf-sidr-algorithm-agility-03 The last call will end Thu, 3 Nov 2011 (AOE). As usual, please address all comments to the WG mailing list, and please be clear in your comments to this last call if you are supporting the document's submission to the IESG or if you are opposed. If you are opposed, please indicate why. --Sandy, speaking as wg chair with appropriate ceremonial garb donned (and covered with ashes for having neglected this) From Sandra.Murphy@cobham.com Fri Oct 21 17:24:51 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8790921F87C9 for ; Fri, 21 Oct 2011 17:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZf7RCD153Wd for ; Fri, 21 Oct 2011 17:24:51 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0787A21F87C5 for ; Fri, 21 Oct 2011 17:24:50 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p9M0Oolt019525 for ; Fri, 21 Oct 2011 19:24:50 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p9M0Om5K021724 for ; Fri, 21 Oct 2011 19:24:50 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.187]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 21 Oct 2011 20:24:47 -0400 Date: Fri, 21 Oct 2011 20:24:47 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 22 Oct 2011 00:24:48.0109 (UTC) FILETIME=[01A2A9D0:01CC9051] Subject: [sidr] support for draft-turner-sidr-bgpsec-algs and draft-turner-sidr-bgpsec-pki-profiles X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 00:24:51 -0000 There has been much more retro-support for these two drafts than there was during in the wglc timeframe. I suppose it just escaped everyone's attention. There is now sufficient support for these two documents to consider the wg interested in adopting them as wg items. If the author could please resubmit these as draft-ietf-sidr-bgpsec-pki-profiles-00 draft-ietf-sidr-bgpsec-algs --Sandy Murphy, speaking as wg chair. From turners@ieca.com Sun Oct 23 15:25:14 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D289B21F8AF7 for ; Sun, 23 Oct 2011 15:25:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEz87pmg9XvV for ; Sun, 23 Oct 2011 15:25:06 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.56.170.20]) by ietfa.amsl.com (Postfix) with SMTP id A5DED21F8AF2 for ; Sun, 23 Oct 2011 15:25:06 -0700 (PDT) Received: (qmail 24367 invoked from network); 23 Oct 2011 21:24:39 -0000 Received: from gator1743.hostgator.com (184.173.253.227) by gateway02.websitewelcome.com with SMTP; 23 Oct 2011 21:24:39 -0000 Received: from [71.191.15.80] (port=47934 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RI6TX-0004Mt-T6; Sun, 23 Oct 2011 17:25:04 -0500 Message-ID: <4EA4943F.80106@ieca.com> Date: Sun, 23 Oct 2011 18:25:03 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Roque Gagliano References: <20110802092022.13671.96567.idtracker@ietfa.amsl.com> <1C1A5E2A-1C8A-4023-B2BA-A2D340470649@cisco.com> <4E3A9A65.4010207@ieca.com> <4E3C503D.2050004@ieca.com> In-Reply-To: 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: pool-71-191-15-80.washdc.east.verizon.net (thunderfish.local) [71.191.15.80]:47934 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: Sandra Murphy , sidr@ietf.org Subject: Re: [sidr] Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 22:25:14 -0000 Roque, The algorithms used to issue and validate BGPSEC certificates are the same as those for RPKI res-certs. This bit is in Section 2: Further, the algorithms used to generate RPKI CA certificates that issue the BGPSEC Router Certificates and the CRLs necessary to check the validity of the BGPSEC Router Certificates remain unchanged (i.e., they are as specified in [ID.sidr-rpki-algs]). What that means is that a BGPSEC certs could be validated by a RP compliant with res-cert (modulo the things noted in Sec 3.3). Now if that same RP wants to do BGPSEC it's got to support the bgpsec-prtocol, bgpsec-pki-profile, and bgpsec-pki-algs drafts too. The other way to think about this is that if a BGPSEC RP is going to validate a BGPSEC signature - it's going to need to validate the BGPSEC protocol signature with the public key in the BGPSEC router's certificate using the algs in bgpsec-pki-algs, then the RP is going to need to validate the signature on the BGPSEC router's certificate with the public key and algs in rpki-certs and rpki-algs, and then repeat until it gets to a TA. I also made sure to put in the bgpsec-algs document that the algs used to sign the BGPSEC certs are found in rpki-algs. I could see changing the following in Section 3.1: OLD: A BGPSEC Router Certificate is a valid X.509 public key certificate, consistent with the PKIX profile [RFC5280] and [ID.sidr-res-cert- profile], containing the fields listed in this section. Only the differences between this profile and the profile in [ID.sidr-res- cert-profile] are listed. NEW: A BGPSEC Router Certificate is a valid X.509 public key certificate, consistent with the PKIX profile [RFC5280], containing the fields listed in this section. This profile is based on [ID.sidr- res-cert-profile] and only the differences between this profile and the profile in [ID.sidr-res-cert-profile] are listed. Section 3.1.2 points to the bgpsec-algs draft only for the key/alg in the EE certificate. The signature alg is still as specified in draft-ietf-sidr-rpki-algs-05 because the bgpsec-algs draft is only listing the differences. Section 3.2 also points to the bgpsec-algs draft because the BGPSEC router is going to request the certificate using the algorithms specified in that draft. But, I could see adding something like the following to Sec 3.3: NOTE: The cryptographic algorithms used by BGPSEC routers are found in [ID.sidr-bgpsec-algs]. Currently, the algorithms specified in [ID.sidr-bgpsec-algs] and [ID.sidr-rpki-algs] are different. BGPSEC RPs will need to support algorithms that are needed to validate BGPSEC signatures as well as the algorithms that are needed to validate signatures on BGPSEC certificates, RPKI CA certificates, and RPKI CRLs. I rambled a bit so let me know if this makes sense. spt On 8/9/11 11:59 AM, Roque Gagliano wrote: > Sean, > > In Section 3.3 of http://datatracker.ietf.org/doc/draft-turner-sidr-bgpsec-pki-profiles/, you are missing to mention that one of the difference from draft-ietf-sidr-res-cert-profile is that your document refers a different algorithm suite document. Consequently, a BGPSEC certificate will not validate draft-ietf-res-cert-profile, as long as the two algorithm suites are different, correct? If that is the case, I believe you should clarify it and probably remove the references that the new profile is consistent with draft-ietf-sidr-res-cert-profile certificates. > > Roque > > > > On Aug 5, 2011, at 10:19 PM, Sean Turner wrote: > >> On 8/5/11 2:11 PM, Sandra Murphy wrote: >>> >>> >>> On Thu, 4 Aug 2011, Sean Turner wrote: >>> >>>> On 8/3/11 8:43 PM, Randy Bush wrote: >>>>>> The intention was to focus on the use case for the proposed changes >>>>>> (BGPSEC certs). >>>>> >>>>> what is a "BGPSEC cert?" >>>> >>>> What Mark and I are currently proposing in >>>> draft-turner-sidr-bgpsec-pki-profiles is that a BGPSEC certificate is a >>> >>> >>> >>>> >>>> PS Technically, the EKU is defined in >>>> draft-turner-bpgsec-pki-profiles. It's >>> >>> >>> >>>> If the WG decides to adopt this approach, then we'll go through the >>>> appropriate procedures to request an OID and include it in the draft. >>> >>> Sean, would you like to request wg adoption for these two drafts? >> >> Yes I would like the wg to consider adoption of: >> >> http://datatracker.ietf.org/doc/draft-turner-sidr-bgpsec-pki-profiles/ >> http://datatracker.ietf.org/doc/draft-turner-sidr-bgpsec-algs/ >> >> as the starting point for certificates and algorithms for BGPSEC. >> >> spt >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > From internet-drafts@ietf.org Mon Oct 24 09:50:39 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDDF21F8D66; Mon, 24 Oct 2011 09:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9NTmbiID5CK; Mon, 24 Oct 2011 09:50:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F60521F8D5E; Mon, 24 Oct 2011 09:50:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111024165038.20684.30249.idtracker@ietfa.amsl.com> Date: Mon, 24 Oct 2011 09:50:38 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-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, 24 Oct 2011 16:50:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : A Profile for BGPSEC Router Certificates, Certificate Re= vocation Lists, and Certification Requests Author(s) : Mark Reynolds Sean Turner Filename : draft-ietf-sidr-bgpsec-pki-profiles-00.txt Pages : 10 Date : 2011-10-24 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 (draft- ietf-sidr-res-cert-profile). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-00.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-00.t= xt From internet-drafts@ietf.org Mon Oct 24 09:50:53 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4691621F8D08; Mon, 24 Oct 2011 09:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9P7IMH+IutY; Mon, 24 Oct 2011 09:50:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E432B21F8BCB; Mon, 24 Oct 2011 09:50:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111024165048.21623.87317.idtracker@ietfa.amsl.com> Date: Mon, 24 Oct 2011 09:50:48 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-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, 24 Oct 2011 16:50:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : BGP Algorithms, Key Formats, & Signature Formats Author(s) : Sean Turner Filename : draft-ietf-sidr-bgpsec-algs-00.txt Pages : 7 Date : 2011-10-24 This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size and signature format used in BGPSEC (Border Gateway Protocol Security). This document updates the Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure (draft-ietf-sidr-rpki-algs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-algs-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-algs-00.txt From turners@ieca.com Mon Oct 24 09:55:24 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDC021F8D6D for ; Mon, 24 Oct 2011 09:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9+rKqiaLgoY for ; Mon, 24 Oct 2011 09:55:24 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.93.164.18]) by ietfa.amsl.com (Postfix) with SMTP id E7AFB21F8D61 for ; Mon, 24 Oct 2011 09:55:23 -0700 (PDT) Received: (qmail 24014 invoked from network); 24 Oct 2011 17:04:21 -0000 Received: from gator1743.hostgator.com (184.173.253.227) by gateway14.websitewelcome.com with SMTP; 24 Oct 2011 17:04:21 -0000 Received: from [71.191.2.238] (port=34499 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RINo2-0007Wz-88; Mon, 24 Oct 2011 11:55:22 -0500 Message-ID: <4EA5987A.1070001@ieca.com> Date: Mon, 24 Oct 2011 12:55:22 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Sandra Murphy References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-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: pool-71-191-2-238.washdc.east.verizon.net (thunderfish.local) [71.191.2.238]:34499 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: sidr@ietf.org Subject: Re: [sidr] support for draft-turner-sidr-bgpsec-algs and draft-turner-sidr-bgpsec-pki-profiles X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 16:55:24 -0000 Sandy, I just submitted these drafts to the repository. spt On 10/21/11 8:24 PM, Sandra Murphy wrote: > There has been much more retro-support for these two drafts than there > was during in the wglc timeframe. I suppose it just escaped everyone's > attention. > > There is now sufficient support for these two documents to consider the > wg interested in adopting them as wg items. > > If the author could please resubmit these as > draft-ietf-sidr-bgpsec-pki-profiles-00 > draft-ietf-sidr-bgpsec-algs > > --Sandy Murphy, speaking as wg chair. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From turners@ieca.com Mon Oct 24 10:13:47 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3C321F8DA0 for ; Mon, 24 Oct 2011 10:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.349 X-Spam-Level: X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExmvUrHjUjvj for ; Mon, 24 Oct 2011 10:13:47 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [67.18.65.19]) by ietfa.amsl.com (Postfix) with SMTP id BFBE021F8D8A for ; Mon, 24 Oct 2011 10:13:46 -0700 (PDT) Received: (qmail 22228 invoked from network); 24 Oct 2011 17:09:14 -0000 Received: from gator1743.hostgator.com (184.173.253.227) by gateway01.websitewelcome.com with SMTP; 24 Oct 2011 17:09:14 -0000 Received: from [71.191.2.238] (port=33567 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RIO5c-0003vW-IY for sidr@ietf.org; Mon, 24 Oct 2011 12:13:32 -0500 Message-ID: <4EA59CBC.5050705@ieca.com> Date: Mon, 24 Oct 2011 13:13:32 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sidr@ietf.org References: <20111024165048.21623.87317.idtracker@ietfa.amsl.com> In-Reply-To: <20111024165048.21623.87317.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: pool-71-191-2-238.washdc.east.verizon.net (thunderfish.local) [71.191.2.238]:33567 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 7 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-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, 24 Oct 2011 17:13:48 -0000 The only change between this version and the individual version (modulo the name/dates) is the addition of a new paragraph Section 1 at Roque's suggestion. It explains which bits of sidr-rpki-algs gets updated and how a BGPSEC cert is differentiated from other RPKI certificates. I thought the addition was a good suggestion because it allows a reader, who gets to this draft through the header updates meta-data as opposed to the bgpsec-pki-profiles draft, to understand which bits are getting updated (no doubt also avoiding an IESG discuss ;). I'll obviously amend/remove this paragraph at the WG's request. spt On 10/24/11 12:50 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 : BGP Algorithms, Key Formats,& Signature Formats > Author(s) : Sean Turner > Filename : draft-ietf-sidr-bgpsec-algs-00.txt > Pages : 7 > Date : 2011-10-24 > > This document specifies the algorithms, algorithms' parameters, > asymmetric key formats, asymmetric key size and signature format used > in BGPSEC (Border Gateway Protocol Security). This document updates > the Profile for Algorithms and Key Sizes for use in the Resource > Public Key Infrastructure (draft-ietf-sidr-rpki-algs). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-algs-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-algs-00.txt > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From iesg-secretary@ietf.org Mon Oct 24 11:16:58 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A5D21F8C66; Mon, 24 Oct 2011 11:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkCB8hHbjE44; Mon, 24 Oct 2011 11:16:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B319521F8C69; Mon, 24 Oct 2011 11:16:54 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111024181654.20960.51543.idtracker@ietfa.amsl.com> Date: Mon, 24 Oct 2011 11:16:54 -0700 Cc: sidr mailing list , sidr chair , RFC Editor Subject: [sidr] Protocol Action: 'The RPKI Ghostbusters Record' to Proposed Standard (draft-ietf-sidr-ghostbusters-15.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 18:16:58 -0000 The IESG has approved the following document: - 'The RPKI Ghostbusters Record' (draft-ietf-sidr-ghostbusters-15.txt) as a Proposed Standard This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sidr-ghostbusters/ Technical Summary In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information which might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This draft describes the RPKI Ghostbusters Record containing human contact information which may be verified (indirectly) by a CA certificate. The data in the record are those of a severely profiled vCard. Working Group Summary There was no outstanding notable action from the WG work on this document. Document Quality There are two vendors providing support and software for this solution. Personnel Chris Morrow (morrowc@ops-netman.net) is the document shepherd. Stewart Bryant is the Responsible Area Director. From turners@ieca.com Mon Oct 24 13:49:52 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2B511E8141 for ; Mon, 24 Oct 2011 13:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upxMY0spSMgY for ; Mon, 24 Oct 2011 13:49:51 -0700 (PDT) Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [67.18.21.16]) by ietfa.amsl.com (Postfix) with SMTP id 8314211E8138 for ; Mon, 24 Oct 2011 13:49:51 -0700 (PDT) Received: (qmail 27713 invoked from network); 24 Oct 2011 20:58:19 -0000 Received: from gator1743.hostgator.com (184.173.253.227) by gateway11.websitewelcome.com with SMTP; 24 Oct 2011 20:58:19 -0000 Received: from [71.191.2.238] (port=44331 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RIRSv-0004rf-DO for sidr@ietf.org; Mon, 24 Oct 2011 15:49:49 -0500 Message-ID: <4EA5CF6D.1000503@ieca.com> Date: Mon, 24 Oct 2011 16:49:49 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sidr@ietf.org References: <20111024165038.20684.30249.idtracker@ietfa.amsl.com> In-Reply-To: <20111024165038.20684.30249.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: pool-71-191-2-238.washdc.east.verizon.net (thunderfish.local) [71.191.2.238]:44331 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-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, 24 Oct 2011 20:49:52 -0000 The difference between the individual submission and wg submission can be found here: http://tools.ietf.org//rfcdiff?url1=http://www.ietf.org/id/draft-turner-sidr-bgpsec-pki-profiles-02.txt&url2=http://www.ietf.org/id/draft-ietf-sidr-bgpsec-pki-profiles-00.txt We'll amend/remove text at the WG's request. spt On 10/24/11 12:50 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 > Filename : draft-ietf-sidr-bgpsec-pki-profiles-00.txt > Pages : 10 > Date : 2011-10-24 > > 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 (draft- > ietf-sidr-res-cert-profile). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-00.txt > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From ietfc@btconnect.com Tue Oct 25 03:35:59 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBC621F85DB for ; Tue, 25 Oct 2011 03:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f390SjQzKOS1 for ; Tue, 25 Oct 2011 03:35:58 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by ietfa.amsl.com (Postfix) with ESMTP id 7818D21F85C7 for ; Tue, 25 Oct 2011 03:35:57 -0700 (PDT) Received: from host86-163-151-98.range86-163.btcentralplus.com (HELO pc6) ([86.163.151.98]) by c2bthomr13.btconnect.com with SMTP id EWQ45150; Tue, 25 Oct 2011 11:35:51 +0100 (BST) Message-ID: <041b01cc92f8$c9a3c640$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Sean Turner" References: <20110802092022.13671.96567.idtracker@ietfa.amsl.com><1C1A5E2A-1C8A-4023-B2BA-A2D340470649@cisco.com> <4E3A9A65.4010207@ieca.com><4E3C503D.2050004@ieca.com> <4EA4943F.80106@ieca.com> Date: Tue, 25 Oct 2011 11:30:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4EA69106.00A9, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.10.25.93015:17:7.586, ip=86.163.151.98, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_1200_1299, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0202.4EA6910B.00CF,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: sidr@ietf.org Subject: Re: [sidr] Fwd: New Version Notificationfor draft-ietf-sidr-bgpsec-pki-profiles X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 10:35:59 -0000 Sean I would get less confused if you referred to draft-ietf-sidr-res-certs as [ID.sidr-res-certs] and not as [ID.sidr-res-cert-profile] ; there are so many sidr I-Ds and name changes and I lose track of what is which even without two similar but different names for one of them:-( "o BGPSEC Router Certificates MUST include the BGPSEC EKU defined in Section 3.9.5." Should that be 3.1.3.1? (or is it a section in draft-ietf-sidr-res-cert-profile:-) And I find it hard to parse ' The validation procedure used for BGPSEC Router Certificates is identical to the validation procedure described in Section 7 of [ID.sidr-res-cert-profile] except that where "this specification" refers to [ID.sidr-res-cert-profile] in that profile in this profile "this specification" is this document.' Perhaps ' The validation procedure used for BGPSEC Router Certificates is identical to the validation procedure described in Section 7 of [ID.sidr-res-cert-profile] except that "this specification" should be taken as referring to this document.' I would find it clearer still if draft-ietf-sidr-res-certs section 7 used 'this profile' instead of 'this specification' Tom Petch ----- Original Message ----- From: "Sean Turner" From randy@psg.com Wed Oct 26 10:01:05 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05DB21F8497 for ; Wed, 26 Oct 2011 10:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suQioPk+Cnwj for ; Wed, 26 Oct 2011 10:01:05 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF5F21F848E for ; Wed, 26 Oct 2011 10:01:05 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RJ6qd-000FzW-7B for sidr@ietf.org; Wed, 26 Oct 2011 17:01:03 +0000 Date: Wed, 26 Oct 2011 10:01:02 -0700 Message-ID: From: Randy Bush To: sidr wg list User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: [sidr] rpki-rtr v2 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 26 Oct 2011 17:01:05 -0000 apologies, but we missed the dreadline with the spec for rpki-rtr v2, which handles the extra pdu needed for path validation. as it is pretty boring, and i did not get the draft out by the dreadline, i am not asking for time in taipei. but i'll probably drop it out once the i-d process opens in taipei week. randy From Sandra.Murphy@cobham.com Wed Oct 26 10:19:43 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF96B21F8B10 for ; Wed, 26 Oct 2011 10:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXOuaplsNV8J for ; Wed, 26 Oct 2011 10:19:42 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id E984221F84A5 for ; Wed, 26 Oct 2011 10:19:41 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p9QHJeXt031059; Wed, 26 Oct 2011 12:19:40 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p9QHJeAs025338; Wed, 26 Oct 2011 12:19:40 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.187]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Oct 2011 13:19:40 -0400 Date: Wed, 26 Oct 2011 13:19:40 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Randy Bush In-Reply-To: Message-ID: References: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 26 Oct 2011 17:19:40.0328 (UTC) FILETIME=[71E0EA80:01CC9403] Cc: sidr wg list Subject: Re: [sidr] rpki-rtr v2 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 26 Oct 2011 17:19:43 -0000 Unless you were doing a -00 version, you did not miss the deadline. Deadlines for non-initial versions is next Monday. --Sandy, speaking as regular ol' member On Wed, 26 Oct 2011, Randy Bush wrote: > apologies, but we missed the dreadline with the spec for rpki-rtr v2, > which handles the extra pdu needed for path validation. as it is pretty > boring, and i did not get the draft out by the dreadline, i am not > asking for time in taipei. but i'll probably drop it out once the i-d > process opens in taipei week. > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From randy@psg.com Wed Oct 26 11:03:13 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE37821F8A97 for ; Wed, 26 Oct 2011 11:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqjBizzpd1lw for ; Wed, 26 Oct 2011 11:03:13 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDFE21F8A58 for ; Wed, 26 Oct 2011 11:03:13 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RJ7ol-000G8v-Nq; Wed, 26 Oct 2011 18:03:12 +0000 Date: Wed, 26 Oct 2011 11:03:10 -0700 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] rpki-rtr v2 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 26 Oct 2011 18:03:14 -0000 > Unless you were doing a -00 version, you did not miss the deadline. it is a -00. rpki-rtr as it is needs to keep moving down the funnel. this is a follow-on next version for path randy From Sandra.Murphy@cobham.com Wed Oct 26 11:25:32 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D15A21F8B43 for ; Wed, 26 Oct 2011 11:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1FgprwDq3dF for ; Wed, 26 Oct 2011 11:25:31 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9C021F8B09 for ; Wed, 26 Oct 2011 11:25:30 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p9QIPAUj031945; Wed, 26 Oct 2011 13:25:10 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p9QIP83R027591; Wed, 26 Oct 2011 13:25:10 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.187]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Oct 2011 14:25:07 -0400 Date: Wed, 26 Oct 2011 14:25:06 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Randy Bush In-Reply-To: Message-ID: References: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 26 Oct 2011 18:25:07.0965 (UTC) FILETIME=[96EEC2D0:01CC940C] Cc: sidr wg list Subject: Re: [sidr] rpki-rtr v2 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 26 Oct 2011 18:25:32 -0000 Ah. OK. --Sandy On Wed, 26 Oct 2011, Randy Bush wrote: >> Unless you were doing a -00 version, you did not miss the deadline. > > it is a -00. rpki-rtr as it is needs to keep moving down the funnel. > this is a follow-on next version for path > > randy > From christopher.morrow@gmail.com Fri Oct 28 06:59:46 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F54321F8491 for ; Fri, 28 Oct 2011 06:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.499 X-Spam-Level: X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLP-d23lFQmG for ; Fri, 28 Oct 2011 06:59:45 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id CC51E21F844D for ; Fri, 28 Oct 2011 06:59:45 -0700 (PDT) Received: by ggnv1 with SMTP id v1so4347507ggn.31 for ; Fri, 28 Oct 2011 06:59:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1OmBVl9JaoJopOcb/eVDTo+7tUXlPRYDfAdJPITGqxo=; b=hA2fYIOcrec3qTRCzZrzwk8YraKxn0BQt3h1Q26UdNNw8WRuXmFoh/dNcur+BfJIqy w8lS+wIwDSitahZaTmGxQsPKP7CrXj2Gj1KdrgZ8PFW3lHHnWlnIMEx7reLceKrzYru4 dD+JdgMpOkli07lK3jv3r/xuu2CZkuG3eMbJc= MIME-Version: 1.0 Received: by 10.42.197.73 with SMTP id ej9mr4638059icb.2.1319810385188; Fri, 28 Oct 2011 06:59:45 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.160.201 with HTTP; Fri, 28 Oct 2011 06:59:45 -0700 (PDT) In-Reply-To: References: Date: Fri, 28 Oct 2011 09:59:45 -0400 X-Google-Sender-Auth: 1irR7pIKeQlxopdX6Xa_O2z0RvY Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 28 Oct 2011 13:59:46 -0000 Two folks seem to have given this a read-through, is that all the interest that exists? is documenting how originators of routes ought to think/use/abuse RPKI not something we should do here? please chime in if you've given this a read and are onboard with it moving forward. -chris On Sat, Oct 15, 2011 at 12:22 AM, Randy Bush wrote: >>> What's the rationale of this change from version 10 to 11? >> after much discussion with ops and security folk, it is the purpose of >> the whole exercise. =A0you wanna stop 7007? > > fwiw, it has swung back and forth a few times > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From christopher.morrow@gmail.com Fri Oct 28 07:00:51 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5072321F84D8 for ; Fri, 28 Oct 2011 07:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.513 X-Spam-Level: X-Spam-Status: No, score=-103.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQyPmP6Ej103 for ; Fri, 28 Oct 2011 07:00:50 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 799AE21F8497 for ; Fri, 28 Oct 2011 07:00:50 -0700 (PDT) Received: by iabn5 with SMTP id n5so5199837iab.31 for ; Fri, 28 Oct 2011 07:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zH3JVjToXyxitDmYK/W1eG9A38YGLYc5c7Edd8ohQ+M=; b=IiXNannUVyvohlGOytCs9o3LwLHvzCY+L4SJ14qBnv5KUBGoxHGz/pnMynbvfsn5dG QHXfKgMelbAs8l4KIsEe0GKlzO6B+gQf6ZSBqoiSr5bVjXw4hu1vvZOjK1QqBzVxPHjX pkJa1yOawCwu++wzA5RwMzRsNK0HcqhcBTbco= MIME-Version: 1.0 Received: by 10.231.0.221 with SMTP id 29mr1008521ibc.75.1319810447381; Fri, 28 Oct 2011 07:00:47 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.160.201 with HTTP; Fri, 28 Oct 2011 07:00:47 -0700 (PDT) In-Reply-To: References: Date: Fri, 28 Oct 2011 10:00:47 -0400 X-Google-Sender-Auth: vLw_qJnhmkSg25GffMksXrTZI_w Message-ID: From: Christopher Morrow To: Sandra Murphy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 28 Oct 2011 14:00:51 -0000 On Thu, Oct 20, 2011 at 10:50 AM, Sandra Murphy wrote: > The authors have requested a WG LC for draft "Algorithm Agility Procedure > for RPKI." > > The document and the draft version history are available at > http://tools.ietf.org/html/draft-ietf-sidr-algorithm-agility-03 > > The last call will end Thu, 3 Nov 2011 (AOE). > > As usual, please address all comments to the WG mailing list, and > please be clear in your comments to this last call if you are > supporting the document's submission to the IESG or if you are > opposed. If you are opposed, please indicate why. > I have read this and support it (as a regular joe/jane/dog/cat) thanks! -chris (regular-chris, not co-chair-chris) > --Sandy, speaking as wg chair with appropriate ceremonial garb donned > =A0 =A0 =A0 =A0 (and covered with ashes for having neglected this) > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From bertietf@bwijnen.net Fri Oct 28 07:30:26 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3686521F863E for ; Fri, 28 Oct 2011 07:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gJh7E6nYFul for ; Fri, 28 Oct 2011 07:30:25 -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 99ECA21F8560 for ; Fri, 28 Oct 2011 07:30:25 -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 1RJnRn-0005GF-2B; Fri, 28 Oct 2011 16:30:24 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest114.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RJnRm-0001zL-Tf; Fri, 28 Oct 2011 16:30:15 +0200 Message-ID: <4EAABC76.9080906@bwijnen.net> Date: Fri, 28 Oct 2011 16:30:14 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christopher Morrow References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd476a07162c795e95152fe4d22445219e0 Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 28 Oct 2011 14:30:26 -0000 As a WG participant who reads this with a "writing a MIB module for RPKI" I have no issues with this document. Bert On 10/28/11 3:59 PM, Christopher Morrow wrote: > Two folks seem to have given this a read-through, is that all the > interest that exists? is documenting how originators of routes ought > to think/use/abuse RPKI not something we should do here? > > please chime in if you've given this a read and are onboard with it > moving forward. > > -chris > > On Sat, Oct 15, 2011 at 12:22 AM, Randy Bush wrote: >>>> What's the rationale of this change from version 10 to 11? >>> after much discussion with ops and security folk, it is the purpose of >>> the whole exercise. you wanna stop 7007? >> >> fwiw, it has swung back and forth a few times >> >> randy >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From brian.peter.dickson@gmail.com Fri Oct 28 07:40:20 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7335F21F899F for ; Fri, 28 Oct 2011 07:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.537 X-Spam-Level: X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQN5wCv2wMLB for ; Fri, 28 Oct 2011 07:40:19 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9C25E21F86EC for ; Fri, 28 Oct 2011 07:40:19 -0700 (PDT) Received: by faas12 with SMTP id s12so4263429faa.31 for ; Fri, 28 Oct 2011 07:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/mUSVLmrDCREaeUwMQF0fJREZQvKM7dJYerPOnpLelU=; b=aGU49tB0wxY+ItuDzOzXxa/H6MCpBDHoo5SKMeFUkbkNjUVZWNpfBCcly3d+T6r0vt CqvfoPgGRwKOv8wdyjpVcL/CITDT+qbjS7ueiau/AHaFL8JrImQ6SW4DJPFCt4bVUAjj HoGxuDWpkJR6YmyKeKZn07mV39bJQIcVybkrk= MIME-Version: 1.0 Received: by 10.223.16.82 with SMTP id n18mr6613158faa.2.1319812816975; Fri, 28 Oct 2011 07:40:16 -0700 (PDT) Received: by 10.223.54.15 with HTTP; Fri, 28 Oct 2011 07:40:16 -0700 (PDT) In-Reply-To: References: Date: Fri, 28 Oct 2011 10:40:16 -0400 Message-ID: From: Brian Dickson To: Christopher Morrow Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 28 Oct 2011 14:40:20 -0000 I have read the document, like what it says and how it says it. I support it moving forward, as it is. Brian On Fri, Oct 28, 2011 at 9:59 AM, Christopher Morrow wrote: > Two folks seem to have given this a read-through, is that all the > interest that exists? is documenting how originators of routes ought > to think/use/abuse RPKI not something we should do here? > > please chime in if you've given this a read and are onboard with it > moving forward. > > -chris > > On Sat, Oct 15, 2011 at 12:22 AM, Randy Bush wrote: >>>> What's the rationale of this change from version 10 to 11? >>> after much discussion with ops and security folk, it is the purpose of >>> the whole exercise. =A0you wanna stop 7007? >> >> fwiw, it has swung back and forth a few times >> >> randy >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From Sandra.Murphy@cobham.com Fri Oct 28 10:44:21 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68A721F888A for ; Fri, 28 Oct 2011 10:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kyn5CYr-2cXp for ; Fri, 28 Oct 2011 10:44:21 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 424FD21F86A1 for ; Fri, 28 Oct 2011 10:44:20 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p9SHiJwP019529 for ; Fri, 28 Oct 2011 12:44:19 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p9SHiKJp024747 for ; Fri, 28 Oct 2011 12:44:20 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.248.12]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Oct 2011 13:37:56 -0400 Date: Fri, 28 Oct 2011 13:37:55 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@hermes.columbia.ads.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 28 Oct 2011 17:37:56.0502 (UTC) FILETIME=[54134B60:01CC9598] Subject: [sidr] possible wg time slot change X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 28 Oct 2011 17:44:22 -0000 To accommodate our Tech Advisor, we are investigating a sidr move to an early day in the week. There's a good possibility that we'll move to Mon afternoon in place of cuss or opsec. That would mean that an hour of the agenda would still be on Fri. There's a remote possibility that we'll move the entire agenda to Tue at 1pm if another wg cancels. Moving pends approval of respective ADs etc. But thought you might like notice. --Sandy From christopher.morrow@gmail.com Fri Oct 28 11:33:08 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAF821F8A56 for ; Fri, 28 Oct 2011 11:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.41 X-Spam-Level: X-Spam-Status: No, score=-103.41 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UXHhSrIfe+l for ; Fri, 28 Oct 2011 11:33:08 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBAE21F8494 for ; Fri, 28 Oct 2011 11:33:08 -0700 (PDT) Received: by qyk31 with SMTP id 31so4639948qyk.10 for ; Fri, 28 Oct 2011 11:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=cbJTgxnf1l4GzEZ96F1NSG7tdzEorIkY4ghKfB8FMWE=; b=NH0q2kJPSvmwa/YNT8YGojivs7IYa1AWSsN7w8FMtTNv0quUzuq1Hu34SHdro+BxXd eNKNWZCaBUln2ULVr0kZjz0Eht0FjL0iC5hXOVwIbEUB1SvmOHxSfD4PT7sjbPqlYpEu i7QeQtHliTICgaeoNw3FpdmbHXcZ06ecBjT3I= MIME-Version: 1.0 Received: by 10.68.36.37 with SMTP id n5mr5407811pbj.105.1319826787546; Fri, 28 Oct 2011 11:33:07 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.68.63.230 with HTTP; Fri, 28 Oct 2011 11:33:07 -0700 (PDT) In-Reply-To: References: Date: Fri, 28 Oct 2011 14:33:07 -0400 X-Google-Sender-Auth: 7kgz2lsXzlRKUKAAvQZYlw04NgQ Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] request to last call draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 28 Oct 2011 18:33:09 -0000 hey, good plan. On Wed, Oct 19, 2011 at 6:19 PM, Randy Bush wrote: > draft-ietf-sidr-bgpsec-reqs-01.txt From christopher.morrow@gmail.com Fri Oct 28 11:40:45 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C0821F86A1; Fri, 28 Oct 2011 11:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.486 X-Spam-Level: X-Spam-Status: No, score=-103.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyjHMfhqWBQQ; Fri, 28 Oct 2011 11:40:45 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E62DC21F8669; Fri, 28 Oct 2011 11:40:41 -0700 (PDT) Received: by qadc10 with SMTP id c10so4946096qad.31 for ; Fri, 28 Oct 2011 11:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=4+00NwIm2AMv14MFdXSN/L7giYZYabKHNUA/cdIHjFk=; b=Z4ZIuM/kQRzP1qY2fpSU87XkXZoS2iIbJ9KPsZuQ/BD2RMGWRFdvKWO6luSNqr4+DZ 1K8IEY1Qcd4QtCM9Wzvg3bI/FTAOvfFMaTNoUhv3uRCQN89faRd8bT2pyzw23zLNJIZt szBwl/geQGjsdxkB8LLiNXmid2Dv22vLYI5Yo= MIME-Version: 1.0 Received: by 10.68.42.39 with SMTP id k7mr5515888pbl.71.1319827241045; Fri, 28 Oct 2011 11:40:41 -0700 (PDT) Received: by 10.68.63.230 with HTTP; Fri, 28 Oct 2011 11:40:41 -0700 (PDT) Date: Fri, 28 Oct 2011 14:40:41 -0400 Message-ID: From: Christopher Morrow To: sidr@ietf.org, sidr-chairs@ietf.org, draft-ietf-sidr-bgpsec-reqs@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 28 Oct 2011 18:40:45 -0000 Seems that the authors, at least, expect this doc to be prepared for WGLC, could we do that concluding 11/11/11 please? Draft link: 01 link: diff link: 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." Thanks! -Chris From jayb@zoe.braeburn.org Fri Oct 28 13:57:48 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7300111E80A3 for ; Fri, 28 Oct 2011 13:57:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuXibVRotewB for ; Fri, 28 Oct 2011 13:57:47 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 72D4711E809F for ; Fri, 28 Oct 2011 13:57:47 -0700 (PDT) X-Env-Sender: jayb@zoe.braeburn.org X-Msg-Ref: server-2.tower-119.messagelabs.com!1319835465!33500288!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7832 invoked from network); 28 Oct 2011 20:57:45 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-2.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Oct 2011 20:57:45 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p9SKwCqv017185 for ; Fri, 28 Oct 2011 16:58:12 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p9SKw9DM017136 for ; Fri, 28 Oct 2011 16:58:10 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p9SKvful003900 for ; Fri, 28 Oct 2011 16:57:41 -0400 Received: from oz.mt.att.com (oz.mt.att.com [135.16.165.23]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p9SKvYv4003522 for ; Fri, 28 Oct 2011 16:57:34 -0400 Received: by oz.mt.att.com (Postfix, from userid 500) id DAE7C2BF2C; Fri, 28 Oct 2011 16:57:33 -0400 (EDT) X-Mailer: emacs 21.2.1 (via feedmail 8 I); VM 7.18 under Emacs 21.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <20139.5946.308162.267635@oz.mt.att.com> Date: Fri, 28 Oct 2011 16:57:30 -0400 From: Jay Borkenhagen To: Christopher Morrow In-Reply-To: References: X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0 Sender: jayb@zoe.braeburn.org Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jay Borkenhagen List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 20:57:48 -0000 Hi, I have read, and I support moving this forward. =09 =09=09=09Jay B. Christopher Morrow writes: > Two folks seem to have given this a read-through, is that all the > interest that exists=3F is documenting how originators of routes oug= ht > to think/use/abuse RPKI not something we should do here=3F >=20 > please chime in if you've given this a read and are onboard with it > moving forward. >=20 > -chris >=20 > On Sat, Oct 15, 2011 at 12:22 AM, Randy Bush wrote: > >>> What's the rationale of this change from version 10 to 11=3F > >> after much discussion with ops and security folk, it is the purpo= se of > >> the whole exercise. =A0you wanna stop 7007=3F > > > > fwiw, it has swung back and forth a few times > > > > randy > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From danny@tcb.net Fri Oct 28 19:03:45 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C8011E8098 for ; Fri, 28 Oct 2011 19:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoXHe8Hp3VTq for ; Fri, 28 Oct 2011 19:03:44 -0700 (PDT) Received: from uu.ops-netman.net (morrowc-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:36e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 754EE11E8091 for ; Fri, 28 Oct 2011 19:03:44 -0700 (PDT) Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [208.76.12.119]) by uu.ops-netman.net (Postfix) with ESMTP id A94821900F1 for ; Sat, 29 Oct 2011 02:03:39 +0000 (UTC) Received: from dul1dmcphers-m2.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (Authenticated sender: danny@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id 5D4E8320283 for ; Sat, 29 Oct 2011 02:03:39 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Danny McPherson In-Reply-To: Date: Fri, 28 Oct 2011 22:03:38 -0400 Content-Transfer-Encoding: 7bit Message-Id: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> References: To: sidr wg list X-Mailer: Apple Mail (2.1084) Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 29 Oct 2011 02:03:46 -0000 On Oct 28, 2011, at 2:40 PM, Christopher Morrow wrote: > Seems that the authors, at least, expect this doc to be prepared for > WGLC, could we do that concluding 11/11/11 please? I've got a couple of comments. Some high-level bits captured with specific comments below include: 1) this appears to largely be a backwards-engineered requirements set for the BGPSEC drafts submitted. If that's the intention then it should says it's for BGPSEC and not constrain other solutions. 2) from a mechanics and processing perspective, this appears to largely focus only on external BGP. It would be useful if the requirements considered what behaviors and recommendations are applicable to internal BGP speakers as well. 2) This document seems to allude to a solution that only protects NLRI and AS_PATH, and ignores ORIGIN and other attributes. This concerns me a great deal given that most (all?) path selection today is largely based on policy derived from and applied based upon all those other attributes. 3) as a WG we need to agree on what constitutes a reasonable solution for minimizing an exposure window. If we're going to build such a heavy solution I find it hard to justify new hardware and tons of complexity if we can't get the window to seconds or minutes, rather than 8+ hours or more best case with what we've seen proposed to date, and that's with periodic updates (ala beacons) that have the scaling properties of RIP. Some specific comments inline below. ----- 3.1 A BGPsec design must allow the receiver of a BGP announcement to determine, to a strong level of certainty, that the received PATH attribute accurately represents the sequence of eBGP exchanges that propagated the prefix from the origin AS to the receiver. By "eBGP exchanges" do you mean some identifier (e.g., BGP Identifiers) associated with the set of eBGP speakers that exchanged a given prefix, or simply the ordered sequence of AS adjacencies the prefix traversed? Would "to the receiver" exclude the local AS, given that it's not added to the AS_PATH until advertised to an eBGP peer? What does the "received PATH attribute" mean here? Do you mean the set of "Path Attributes" contained in an UDPATE message (plural and covering all path attributes, not just the AS_PATH), or did you only mean the AS_PATH attribute made up of the sequence of AS path segments? Irrespective of your answer to the previous question, given that the ORIGIN attribute is distinct from AS_PATH, do you foresee BGPsec adding a strong level of certainty to it as well? It would be useful to clarify what constitutes "announcement" in the draft. E.g., an UPDATE message that carries only withdrawn routes would be announced, but doesn't have any path attributes. If only referring to AS_APTH above, why it not a requirement of BGPSEC to enable some strong level of certainty to this? ----- 3.2 A BGPsec design must allow the receiver of an announcement to detect if an AS has added or deleted any AS number other than its own in the path attribute. This includes modification to the number of AS prepends. Is the point of "other than its own" here to reflect the fact that the local AS isn't added to the path until advertised to eBGP peer? If it's own is there, should it be able to identify that it was added and validates before pruning, or should it be ignored and pruned without validation first? ----- 3.3 A BGPsec design MUST be amenable to incremental deployment. Any incompatible protocol capabilities MUST be negotiated. 3.4 A BGPsec design MUST provide analysis of the operational considerations for deployment and particularly of incremental deployment, e.g, contiguous islands, non-contiguous islands, universal deployment, etc.. 3.5 As cryptographic payloads and memory requirements on routers are likely to increase, a BGPsec design MAY require use of new hardware. I.e. compatibility with current hardware abilities is not a requirement that this document imposes on a solution. As BGPsec will likely not be rolled out for some years, this should not be a major problem. While I understand the "spirit" of this, it seems to be largely in conflict with requirement 3.3 above. e.g., I wouldn't consider required use of new hardware fully "amenable to incremental deployment" unless you have the capability to selectively apply BGPsec on a per prefix basis. Given that new hardware MAY be required, do you anticipate that "hardware abilities" to be conveyed to a peer, or do you believe this will be a system level setting? E.g., with current hardware if I can only handle processing of n BGPsec prefixes without an upgrade and I want that to be for the 13 root servers, and m TLD prefixes, and google, can I do that, and then plan old BGP for everything else -- or is this all or nothing? If we're decoupling all the transport and most path attributes, why can't I do this on a per-prefix basis? ----- 3.6 A BGPsec design need not prevent attacks on data plane traffic. It need not provide assurance that the data plane even follows the control plane. 3.7 A BGPsec design MUST resist attacks by an enemy who has access to the link layer, per Section 3.1.1.2 of [RFC4593]. In particular, such a design must provide mechanisms for authentication of all data, including protecting against message insertion, deletion, modification, or replay. Mechanisms that suffice include TCP sessions authenticated with IPsec [RFC4301] or TLS [RFC5246]. Given the current text, BGPsec itself isn't resisting these vectors, it's simply utilizing lower layer mechanisms that do - perhaps we should say that instead? Else perhaps we expand beyond "link layer" such that broader attacks for which TLS and IPsec provide protections are also covered? ----- 3.8 A BGPsec design MAY make use of a security infrastructure (e.g., a PKI) to distribute authenticated data used as input to routing decisions. Such data include information about holdings of address space and ASNs, and assertions about binding of address space to ASNs. 3.9 If message signing increases message size, the 4096 byte limit on BGP PDU size MAY be removed. "message signing" is ambiguous? I think you mean "attribute signing"? And while I understand the objective here and the necessity given the BGPSEC protocol that's been put forth, if we're writing general requirements here shouldn't this impose some upper bound, or are we simply using a requirements document to remove previous requirements defined elsewhere and prescribe solutions? ----- 3.10 It is entirely OPTIONAL to secure AS SETs and prefix aggregation. The long range solution to this is the deprecation of AS-SETs, see [I-D.ietf-idr-deprecate-as-sets]. What does "and prefix aggregation" mean here? I assume it simply means prefix aggregation via AS_SETs? ----- 3.11 If a BGPsec design uses signed prefixes, given the difficulty of splitting a signed message while preserving the signature, it need NOT handle multiple prefixes in a single UPDATE PDU. Can you clarify what "signed prefix" means? Also, what about withdrawn routes in the same UDPATE message? Also, I don't see "need NOT" in RFC 2119 keywords, and would hate to think such a general requirement would keep folks from including multiple NLRI in a single update, if they had the capability. ----- 3.12 A BGPsec design MUST enable each BGPsec speaker to configure use of the security mechanism on a per-peer basis. How about a per-prefix basis? ----- 3.13 A BGPsec design MUST provide backward compatibility in the message formatting, transmission, and processing of routing information carried through a mixed security environment. Message formatting in a fully secured environment MAY be handled in a non-backward compatible manner. Can you define "mixed security environment" and "fully secured environment"? ----- 3.14 While the trust level of an NLRI should be determined by the BGPsec protocol, local routing preference and policy MUST then be applied to best path and other decisions. Such mechanisms MUST conform with [I-D.ietf-sidr-ltamgmt]. I don't understand this. sidr-ltamgmt talks about accommodating other "trusted channels" but only in the context of "TA material". Can you explain your intention here, as neither accommodate local or other functions that may well intentionally override RPKI or Local TA material. Also, what about other attributes that impact BGP best path and other decisions, are they to be protected via BGPsec? ----- 3.15 A BGPsec design MUST support 'transparent' route servers, meaning that the AS of the route server is not counted in downstream BGP AS-path-length tie-breaking decisions. This requirement is essentially rewriting what a transparent route server is. Is this a requirement that is intended to be supported globally in incremental deployment and non-contiguous islands mode (e.g., we introduce new BGPsec attributes that influence path selection and subsequent packet forwarding, but non-BGPsec speakers don't know about or factor them)? And what if I want to factor them, seems reasonable to me? ------ 3.16 If a BGPsec design makes use of a security infrastructure, that infrastructure SHOULD enable each network operator to select the entities it will trust when authenticating data in the security infrastructure. See, for example, [I-D.ietf-sidr-ltamgmt]. 3.17 A BGPsec design MUST NOT require operators to reveal more than is currently revealed in the operational inter-domain routing environment, other than the inclusion of necessary security credentials to allow others to ascertain for themselves the necessary degree of assurance regarding the validity of NLRI received via BGPsec. This includes peering, customer, and provider relationships, an ISP's internal infrastructure, etc. It is understood that some data are revealed to the savvy seeker by BGP, traceroute, etc. today. Hrmm, isn't this in direct conflict with 3.5 above? I.e., transparent route servers are transparent outside the local adjacencies. Without defining what constitutes "necessary security credentials" I can't understand this requirement as is. For example, I might consider it necessary to know that ISP b is NOT a transit for Enterprise E. If BGPsec in this case is anything beyond the operational messaging system then this requirement seems misplaced to me. ----- 3.18 A BGPsec design SHOULD flag security exceptions which are significant enough to be logged. The specific data to be logged are an implementation matter. "... unless otherwise indicated in the relevant protocol specifications."? Surely we're going to indicate in the specs some things that MUST be logged? ----- 3.19 Any routing information database MAY be re-authenticated periodically or in an event-driven manner, especially in response to events such as, for example, PKI updates. Are we simply justifying periodic updates (i.e., beaconing) with this? Shouldn't the general requirement be to minimize the exposure window, rather than prescribing a solution? And if we're going to state that we must provide the capability to minimize the exposure window, then having a discussion on what a reasonable exposure window is would seem to be in order, as this has significant implications on the architecture chosen. ----- 3.20 Should a BGPsec design use hashes or signatures, it should provide mechanisms for algorithm agility. "should", "SHOULD", or "MUST"? I would think the latter of these. ----- 3.21 A BGPsec design SHOULD NOT presume to know the intent of the originator of a NLRI, nor that of any AS on the AS Path. Isn't the intent to convey destination reachability? I honestly don't know what this requirement is aiming to accommodate, can you explain? ----- 3.22 A BGP listener SHOULD NOT trust non-BGPsec markings, such as communities, across trust boundaries. This is a requirements document, why are we presupposing what constitutes a BGPsec "marking" here? If we must, then we need to detail what *attributes* are and are not in scope -- or is that what you're trying to do in the next section? ----- 4. BGP UPDATE Security Requirements The following requirements MUST be met in the processing of BGP UPDATE messages: 4.1 A BGPsec design MUST enable each recipient of an UPDATE to formally validate that the origin AS in the message is authorized to originate a route to the prefix(es) in the message. Including an iBGP speaker within the origin AS, where there is no origin AS as of yet? I don't see any text in these requirements on internal BGPisms, is this deemed out of scope? ----- 4.2 A BGPsec design MUST enable the recipient of an UPDATE to formally determine that the NLRI has traversed the AS path indicated in the UPDATE. Note that this is more stringent than showing that the path is merely not impossible. In this case, are you referring to the normal AS_PATH attribute, or the path that might be conveyed in a BGPSEC protocol (e.g., to accommodate "transparent route servers"? ----- 4.3 Replay of BGP UPDATE messages need not be completely prevented, but a BGPsec design MUST provide a mechanism to control the window of exposure to replay attacks. To control them to within what size window? I'd certainly think something in the low "minutes" period needs to be accommodated if we're going to add a huge amount of machinery to mitigate accidents and attacks? Some express guidance on what constitutes a reasonably scoped window needs to be provided here. ----- 4.4 A BGPsec design SHOULD provide some level of assurance that the origin of a prefix is still 'alive', i.e. that a monkey in the middle has not withheld a WITHDRAW message or the effects thereof. "origin" meaning origin AS, or something else? Also, to accomplish this I assume you envision the design accommodating some strong level of certainty that the ORIGIN attribute is accurately represented? Also, I assume you mean "WITHDRAWN ROUTES" field in an UPDATE message? ----- 4.5 NLRI of the UPDATE message SHOULD be able to be authenticated in real-time as the message is processed. Shouldn't this also apply to WITHDRAWN ROUTES? And AS_PATH and other attributes as well, for that matter? ----- 4.6 Normal sanity checks of received announcements MUST be done, e.g. verification that the first element of the AS_PATH list corresponds to the locally configured AS of the peer from which the UPDATE was received. This assumes external BGP only? ----- 4.7 The output of a router applying BGPsec to a received signed UPDATE MUST be either Valid or Unverified. There should be no shades of grey. Are we prescribing here that UPDATE messaging will be signed, and not specific attributes within those messages? :-) From danny@tcb.net Sat Oct 29 13:20:25 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D593521F853B for ; Sat, 29 Oct 2011 13:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dccFMWZb5fIt for ; Sat, 29 Oct 2011 13:20:25 -0700 (PDT) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id A0F5B21F8512 for ; Sat, 29 Oct 2011 13:20:24 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP; Sat, 29 Oct 2011 13:20:24 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p9TKK8ZL028195 for ; Sat, 29 Oct 2011 16:20:08 -0400 Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com ([10.100.0.13]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 29 Oct 2011 16:20:08 -0400 From: Danny McPherson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 29 Oct 2011 16:20:07 -0400 Message-Id: To: sidr wg list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 29 Oct 2011 20:20:08.0091 (UTC) FILETIME=[26F7AEB0:01CC9678] Subject: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 29 Oct 2011 20:20:26 -0000 Some comments on sidr-bgpsec-threats-00 below.. Most substantial of my concerns is Section 5's "Residual Vulnerabilities", specifically: "BGPSEC has a separate set of residual vulnerabilities: - BGPSEC is not able to prevent what is usually referred to as route leaks, because BGP itself does not distinguish between transit and non-transit ASes- BGPSEC signatures do not protect all attributes associated with an AS_path. Some of these attributes are employed as inputs to routing decisions. Thus attacks that modify (or strip) these other attributes are not detected by BGPSEC." Do we really consider it acceptable that the solution and machinery we're recommending will NOT prevent "route leaks", and also does NOT protect the integrity of the very path attributes that are used to apply preferences (i.e., policy derived from business logic that dictates most routing decisions on the Internet today)? I'm having a really hard time subscribing to this as being an acceptable residual threat after we reach full deployment, particularly without a clear path outlining the development of controls that mitigate that risk. More comments below.... --- s/to determine of/to determine if/ --- In terminology section include "(AS)" after "Authonomous System" per subsequent use of acronym. --- s/AS Number (ANS)/AS Number (ASN)/ --- "False Origination" should probably be "network operator", not ISP, in particular given the subsequent definition of ISP. --- s/Local Internet registries/Local Internet Registries/ --- The definition of "Route" seems to be missing the full set of path attributes associated with the NLRI, it currently only focuses on the AS_PATH attribute, and even omits the ORIGIN code of the path. --- Regarding your definition of "Threat": Threat - A threat is a motivated, capable adversary. An adversary that is not motivated to launch an attack is not a threat. An adversary that is motivated but not capable of launching an attack also is not a threat. With many "route leaks" and similar incidents, the network operator may not have been motivated to launch an attack, but the impact of a leak is the same and it is certainly still a "threat". --- In "Threat Characterization" it would seem that for simplicity we should refer to BGP speakers as "network operators", not just ISPs as the current text suggests, particuarly in the case where an attacker may well be a subscriber that intentionally interconnects between two ISPs (in order to exploit business logic and derived preferences), or leaks routes unintentionally as is commonly the case today? --- "Hackers might be recruited, without their knowledge, by criminals or by nations, to act on their behalf." are you referring to social engineering or other attacks here that would be employed to gain access to a network operator's systems? If so, that doesn't make the victim a "hacker"? --- Wouldn't "attacker" be a better term here, "hacker" is fairly ambiguous. Also, from a threat model perspective here I see little difference between "criminals" and "nations", can you explain the difference and why it's called out expressly anywhere beyond the discussion of jurisdictional issues dictating network operator or CA/INR functions? --- Regarding "Registries", an attack on a registry in this case (e.g., social engineering) could have the same or broader impacts as an attack on an ISP (network operator), I think you capture this in later sections but this text does not adequately represents this. --- s/act as a rogue capacity/act in a rogue capacity/ ? --- The end of Section 3 seems to be incomplete, i.e.: "A manifest associated with a CA's repository publication point contains a list of: 4. Attacks" --- Regarding Section 4.1, passive attacks, and "confidentiality" from MITM as a non-goal, shouldn't protections there be an objective in order to minimize the exposure of data that could lead to replay and other similar attacks -- in order to further minimize that exposure window we're trying to address with periodic updates? --- This discusses TCP-AO or IPSec, whereas the rquirements draft avoids TCP-AO and talks about TLS? --- S 4.3: "This type of behavior cannot be externally detected as an attack." /cannot/may not/ --- "PA allocation" - Define PA here. --- My read of most of the attacks in S 4.3 is about DoS-esque functions, not certificate issuance that might be employed at a later time. Perhaps we should capture this more clearly in this section, as it's certainly one of the more obvious issues we're seeing with the CA sieve today...? --- S 4.4 Regarding this text: "An RP can continue to use the last valid instance of the deleted object as a local policy option), thus minimizing the impact of such an attack." Such guidance and implementation may be precisely what an attacker was hoping to instigate, no? Further: "An RP cannot know the content of the new certificates or ROAs that are not present, but it can continue to use what it has cached." and S 5's Residual Vulnerabilities: - the RPKI repository system may be attacked in ways that make its contents unavailable, or not current. It is anticipated that RPs will cope with this vulnerability through local caching of repository data, and through local settings that tolerate expired or stale repository data. I think we should be clear that expired information should not be used? --- In the cases where notifying a CA of the error in order to remedy the problem is the recommended action, what threats arise if the CA cannot be reached or authenticated? Should those be enumerated here? --- S 5. s/were been discussed in the/were discussed in the/ --- I'm surprised I don't see anything here about timing dependencies between RPKI and BGPSEC routers, and variances across a BGPSEC system having considerable potential impacts. I think some discussion of this is in order in a threats draft. --- Shouldn't there also be some discussion of coherency the RPKI repository system? I.e., timing dependencies can result in some amount of considerable exposure if a manifest or CRL regarding a particular certificate have not been refreshed yet? From Sandra.Murphy@cobham.com Sat Oct 29 18:10:43 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303911F0C36 for ; Sat, 29 Oct 2011 18:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6ucSZsvMRkB for ; Sat, 29 Oct 2011 18:10:42 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1781F0C38 for ; Sat, 29 Oct 2011 18:10:41 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p9U1AeWP027735 for ; Sat, 29 Oct 2011 20:10: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 p9U1Ae7O014162 for ; Sat, 29 Oct 2011 20:10:40 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0339.001; Sat, 29 Oct 2011 21:10:28 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 Thread-Index: AcyUe6udCx2p0PZ7Tu6Ty5HU0UcysQCJJuTK Date: Sun, 30 Oct 2011 01:10:28 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6025FEE@Hermes.columbia.ads.sparta.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.61.23] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 30 Oct 2011 01:10:43 -0000 This is a reminder that the last call is in progress and is ending soon.=0A= =0A= I have encouraged people to comment on this in the past. I think it is an = important feature of what we are building and deserves some careful attenti= on. It would not be good to be faced in the future with the need to change= the algorithms and discover we had missed something.=0A= =0A= There is still time to read and comment. Please do.=0A= =0A= --Sandy, speaking as wg chair=0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Sandra Mur= phy [Sandra.Murphy@sparta.com]=0A= Sent: Thursday, October 20, 2011 10:50 AM=0A= To: sidr@ietf.org=0A= Subject: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03=0A= =0A= The authors have requested a WG LC for draft "Algorithm Agility Procedure= =0A= for RPKI."=0A= =0A= The document and the draft version history are available at=0A= http://tools.ietf.org/html/draft-ietf-sidr-algorithm-agility-03=0A= =0A= The last call will end Thu, 3 Nov 2011 (AOE).=0A= =0A= As usual, please address all comments to the WG mailing list, and=0A= please be clear in your comments to this last call if you are=0A= supporting the document's submission to the IESG or if you are=0A= opposed. If you are opposed, please indicate why.=0A= =0A= --Sandy, speaking as wg chair with appropriate ceremonial garb donned=0A= (and covered with ashes for having neglected this)=0A= =0A= =0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From Sandra.Murphy@cobham.com Sat Oct 29 18:41:36 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782471F0C36 for ; Sat, 29 Oct 2011 18:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53Q9Fi3ZlU+y for ; Sat, 29 Oct 2011 18:41:36 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id E9CEE1F0C34 for ; Sat, 29 Oct 2011 18:41:35 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p9U1fY5I027828 for ; Sat, 29 Oct 2011 20:41:34 -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 p9U1fUaj014347 for ; Sat, 29 Oct 2011 20:41:34 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0339.001; Sat, 29 Oct 2011 21:41:30 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: reminders and synopsis Thread-Index: AcyWoGb01HtKevCYS12/GGLJcoJZhQ== Date: Sun, 30 Oct 2011 01:41:30 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6025FF1@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.61.23] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] reminders and synopsis X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 30 Oct 2011 01:41:36 -0000 Reminders of some recently completed and ongoing activity. (Brian suggest= ed reminders and it seems like a good idea to me - comments on the usefulne= ss encouraged.)=0A= =0A= =0A= Reminder: Notice the two ongoing requests for your response:=0A= =0A= draft-ietf-sidr-algorithm-agility-03 wglc to end 3 Nov=0A= =0A= draft-ietf-sidr-bgpsec-reqs wglc to end 11 Nov.=0A= =0A= =0A= =0A= Synopsis=0A= =0A= draft-ietf-sidr-origin-ops wglc started 14 Oct, to end 28 Oct. Chris nagge= d about it on 28 Oct and got a couple more reviews.=0A= =0A= draft-ietf-sidr-rpsl-sig support was requested on 14 Oct, to end 28 Oct.=0A= =0A= draft-ietf-sidr-algorithm-agility-03 wglc started 20 Oct, to end 3 Nov. Sa= ndy nagged about it on 29 Oct.=0A= =0A= draft-turner-sidr-bgpsec-algs and draft-turner-sidr-bgpsec-pki-profiles wgl= cs were judged as indicating a lack of support, but a rash of retro-support= resulted in a reversal of that decision on 21 Oct. wg versions of those d= rafts have been submitted.=0A= =0A= draft-ietf-sidr-ghostbusters-15.txt was approved for publication on 24 Oct.= =0A= =0A= draft-ietf-sidr-rpki-rtr-18 publication was requested 27 Oct.=0A= =0A= draft-ietf-sidr-bgpsec-reqs wglc started on 28 Oct, to end 11 Nov.=0A= =0A= --Sandy, speaking as wg chair=0A= =0A= =0A= =0A= From shane@castlepoint.net Sat Oct 29 22:38:09 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038D41F0C35 for ; Sat, 29 Oct 2011 22:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrsucnLcztRd for ; Sat, 29 Oct 2011 22:38:07 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id B487D1F0C34 for ; Sat, 29 Oct 2011 22:38:07 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 312C1268063; Sat, 29 Oct 2011 23:38:05 -0600 (MDT) Received: from mbpw.castlepoint.net (65-102-206-76.hlrn.qwest.net [65.102.206.76]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Sat, 29 Oct 2011 23:38:04 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.102.206.76; client-port=58938; syn-fingerprint=65535:54:1:64:M1452,N,W2,N,N,T,S; data-bytes=0 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1251.1) From: Shane Amante In-Reply-To: Date: Sat, 29 Oct 2011 23:37:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <805B0799-7026-4532-A53C-4CFE3E863A33@castlepoint.net> References: To: sidr wg list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 30 Oct 2011 05:38:09 -0000 I have some questions that pertain to this document, specifically = around: - whether it's intended or 'safe' to use BGP Attributes, (MED, = communities), to convey validity of prefixes from one ASN to another ASN - better guidance/recommendations around the number, placement and = synchronization characteristics of RPKI caches within a SP. 1) =46rom Section 3: ---snip--- A local valid cache containing all RPKI data may be gathered from the global distributed database using the rsync protocol, [RFC5781], and a validation tool such as rcynic [rcynic]. ---snip--- Would it be possible to mention and/or point to how the above process is = supposed to be bootstrapped? IOW, is it expected that, eventually?, the = RIR's are going to publish to their end-users and maintain URI's of RPKI = publication points? Since this is an Ops guidelines document, some = guidance and/or pointers are likely to save [lots of] questions down the = road. I'm not expecting this to be a tutorial document, but some idea = on the theory of how a new SP bootstraps their cache(s) would be = helpful. 2) Given that, to my knowledge, the RPKI is [very] loosely synchronized = in a "pull-only" fashion, shouldn't there be some text added below to = that effect that: a) It may not be best to go more than, say, 2 levels of RPKI caches = deep inside a single organization/ASN to avoid RPKI caches from being = out of sync with each other? IOW, there are likely a small set of = 1st/top-level RPKI caches that speak externally to fetch RPKI cache = information, (similar to 'hidden' authoritative DNS servers), then a = second tier of RPKI caches that synchronize (only) from the top-level = RPKI caches, (similar to external, anycast authoritative DNS servers).=20= b) Operators should look at running more aggressive synchronization = intervals _internally_ within their organization/ASN, from "children" = (2nd-level) RPKI caches to the 'parent' (top-level) RPKI cache in their = organization/ASN, compared to more "relaxed" synchronization intervals = to RPKI caches external to their organization (top-level RPKI caches in = their ASN to RIR's)? ---snip--- Validated caches may also be created and maintained from other validated caches. Network operators SHOULD take maximum advantage of this feature to minimize load on the global distributed RPKI database. Of course, the recipient SHOULD re-validate the data. ---snip--- While I'm here, I don't think the text in Section 6, "Notes", addresses = the above concerns, at all. In fact, I find it extremely unhelpful to = just dismiss this concern, out of hand, with the text: "There is no = 'fix' for this, it is the nature of distributed data with distributed = caches". We know what the answer is here: you tune the synchronization = intervals to strike the appropriate balance between [very] tight = synchronization vs. increased load on the systems being synchronized. I = find it hard to believe a simple suggestion such as this is not proposed = in the text, even including the phrase "the suggested values for such = synchronization are outside the scope of this document, but will likely = be subject to further studies to determine optimal values based on field = experience". 3) Granted, the following text is only a "SHOULD", but the text offers = no reasoning as to why caches should be placed close to routers, i.e.: = are there latency concerns (for the RPKI <-> cache protocol), or is it = that a geographically distributed system is one way to avoid a = single-point-of-failure, or something else entirely? As a start, just = defining "close" would help, e.g.: same POP, same (U.S.) state, same = country, same timezone =85 but, then a statement as to any latency or = resiliency requirement for geographic deployment of RPKI caches wold be = useful. Furthermore, given the [very] loosely synchronized nature of the = RPKI, should the text point out that the number of RPKI caches (internal = to the organization) be balanced against the potential need of an = organization to maintain a more tightly synchronized view, across their = entire network, of validated routing information? A concern might be = that if routers in Continent A pull information from their RPKI caches = that tell them that ROA is not "Invalid", but other routers in Continent = B are still using 'older' information in RPKI caches in Continent B that = says the same ROA is either "Not Found" or "Valid", then the result = might be that BGP Path Selection swings all traffic from Continent A to = Continent B. At a minimum, this could lead to substantially increased = latency or, at worst, congestion, packet-loss or a unintended DoS. =20 ---snip--- As RPKI-based origin validation relies on the availability of RPKI data, operators SHOULD locate caches close to routers that require these data and services. A router can peer with one or more nearby caches. ---snip--- In Section 5, "Routing Policy": 4) =46rom a practical standpoint, LOCAL_PREF is already widely used to = influence Traffic Engineering, both by an SP as well as by the SP's = customers (through the use of "TE communities" sent by a downstream = customer to the SP) -- the latter of which is done in order so the = customer can influence traffic from the SP toward themselves, (e.g.: one = example where a customer prefers a circuit be 'backup' for another = circuit only if their other SP is not announcing that same prefix). In = reality, I think that there will have to be significant re-work of an = SP's existing BGP policies to encode dual-meanings inside a single = LOCAL_PREF attribute, (route validity + TE preference). It may be good = to acknowledge this by recommending that in the text, above, something = like: =3D=3D=3D=3D In the short-term, the LOCAL_PREF Attribute may be used to carry = both the validity state of a prefix along with it's Traffic Engineering = characteristic(s). It is likely that the SP will have to change their = BGP policies such that they can encode these two, separate = characteristics in the same BGP attribute without negatively impacting = their existing use or leading to accidental privilege escalation = attacks.=20 =3D=3D=3D=3D ---snip--- Some may choose to use the large Local-Preference hammer. ---snip--- 5) I have three comments on the below: a) It's not clear, to me, what is meant by "internal metric" below. = Do you mean MED or IGP metric or something else? I don't see IGP = metric as being practical, so I'm assuming you mean additively altering = MED (up|down) based on validity state. Regardless, I would recommend = you state more precisely which BGP Path Attribute you're referring to = below. b) Since MED is passed from one ASN to (only) a second, downstream = ASN to influence ingress TE policy, is it "OK" from a security PoV that = MED is a *trusted* means to convey ROA validity information from one ASN = to a second? Presumably, the answer should be "heck, no", right? If = that's the case, then wouldn't it be wise to state that: i) MED's, encoded with any ROA validity information, should get = reset on egress from an ASN to remove said validity information and only = carry TE information, as appropriate; and, ii) MED's should not be trusted on ingress to convey any meaning = with respect to validity information? c) What is meant by the statement, "might choose to let AS-Path = rule"? Is your intent to state that an SP may choose to just use MED, = which follows after LOCAL_PREF & AS_PATH in the BGP Path Selection = Algorithm, as a means to determining validity of a particular prefix? = If so, then it would be much more clear if you just stated that, e.g.: =3D=3D=3D=3D If LOCAL_PREF is not used to convey validity information, then MED = is likely the next best candidate BGP Attribute that can be used to = influence path selection based on the validity of a particular prefix. = As with LOCAL_PREF, care must be taken to avoid changing the MED = attribute and creating privilege escalation attacks. =3D=3D=3D=3D ---snip--- [=85] Others might choose to let AS-Path rule and set their internal metric, which comes after AS-Path in the BGP decision process. ---snip--- Other Comments: 6) Related to #5, above, BGP Communities are another transitive = attribute that /might/ be used to convey validity information of a = prefix, or lack thereof, from one ASN to a second ASN (or, more). = However, as we know, there is no means to authenticate BGP Attributes, = from one ASN to the next. So, from a security hygiene perspective, = would it be best to say something along the lines of: =3D=3D=3D=3D The validity state of routes MUST NOT be transmitted beyond the borders = of an SP's ASN, since: a) there is no authenticity of BGP Attributes; = and, b) this would place hidden dependencies on the ability of the = upstream ASN to validate routes and pass them along to others, which = would increase the fragility of the overall system. Finally, ASN's MUST = NOT rely on BGP Attributes received on an eBGP session, to convey any = meaning with respect to validity of a particular prefix for the reasons = just stated. =3D=3D=3D=3D 7) Is this document only intended (scoped?) to cover PE's that can (or, = eventually, will) speak the RPKI-RTR protocol for validation? Or is = this document intended to also cover PE's that do not speak RPKI-RTR, = but those PE's would obviously need some other mechanism, (e.g.: = periodically pushing an updated config to them based on RPKI validated = data), in order that they could influence the policy applied to valid = routes in such a way that is consistent with other more modern routers = that do run RPKI-RTR protocol? If so, wouldn't it be good to suggest = this, even if only as a means to increase the deployment speed? Or, to = at least let readers know that this needs to be considered during their = deployment so that they can factor in the load on their [existing] = systems that might do this work as well as the effects of the 'loosely = synchronized' aspects of the RPKI? -shane On Oct 28, 2011, at 7:59 AM, Christopher Morrow wrote: > Two folks seem to have given this a read-through, is that all the > interest that exists? is documenting how originators of routes ought > to think/use/abuse RPKI not something we should do here? >=20 > please chime in if you've given this a read and are onboard with it > moving forward. >=20 > -chris >=20 > On Sat, Oct 15, 2011 at 12:22 AM, Randy Bush wrote: >>>> What's the rationale of this change from version 10 to 11? >>> after much discussion with ops and security folk, it is the purpose = of >>> the whole exercise. you wanna stop 7007? >>=20 >> fwiw, it has swung back and forth a few times >>=20 >> randy >> _______________________________________________ >> 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 randy@psg.com Sun Oct 30 03:57:50 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE2D21F8B00 for ; Sun, 30 Oct 2011 03:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlNAZZ-LiHm2 for ; Sun, 30 Oct 2011 03:57:49 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id DF0C421F8AFF for ; Sun, 30 Oct 2011 03:57:48 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RKT5G-0004K4-4y; Sun, 30 Oct 2011 10:57:46 +0000 Date: Sun, 30 Oct 2011 11:57:44 +0100 Message-ID: From: Randy Bush To: Shane Amante In-Reply-To: <805B0799-7026-4532-A53C-4CFE3E863A33@castlepoint.net> References: <805B0799-7026-4532-A53C-4CFE3E863A33@castlepoint.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 30 Oct 2011 10:57:50 -0000 thanks for the review! > - whether it's intended or 'safe' to use BGP Attributes, (MED, communitie= s), to convey validity of prefixes from one ASN to another ASN what is valid for you may not be valid for me, see draft-ietf-sidr-ltamgmt. > - better guidance/recommendations around the number, placement and > - synchronization characteristics of RPKI caches within a SP. this is a complex net design issue and has way too much dependency on your architecture. if you have a simple bit of guidance you would suggest, do send text. in general, we tried to give high level guidance as opposed to delving deeply into your net design. aside from the latter being far too prescriptive, the discussion would explode into thousands of micro-considerations as net designs are quite diverse. no proof of termination. luckily, as you demonstrate with your message, a good net eng will perceive the issues that affect them. we assume they will then design accordingly. > 1) From Section 3: > ---snip--- > A local valid cache containing all RPKI data may be gathered from the > global distributed database using the rsync protocol, [RFC5781], and > a validation tool such as rcynic [rcynic]. > ---snip--- >=20 > Would it be possible to mention and/or point to how the above process is = supposed to be bootstrapped? IOW, is it expected that, eventually?, the RI= R's are going to publish to their end-users and maintain URI's of RPKI publ= ication points? Since this is an Ops guidelines document, some guidance an= d/or pointers are likely to save [lots of] questions down the road. I'm no= t expecting this to be a tutorial document, but some idea on the theory of = how a new SP bootstraps their cache(s) would be helpful. uh, i am not clear on what you actually want here. in the minimal case, the op should just run rcynic or some equivalent relying party tool, as it says. in the more complex/large case, good quality RP cache code should be able to feed from other RP caches. > 2) Given that, to my knowledge, the RPKI is [very] loosely synchronized = in a "pull-only" fashion, shouldn't there be some text added below to that = effect that: > a) It may not be best to go more than, say, 2 levels of RPKI caches = deep inside a single organization/ASN to avoid RPKI caches from being out o= f sync with each other? IOW, there are likely a small set of 1st/top-level= RPKI caches that speak externally to fetch RPKI cache information, (simila= r to 'hidden' authoritative DNS servers), then a second tier of RPKI caches= that synchronize (only) from the top-level RPKI caches, (similar to extern= al, anycast authoritative DNS servers).=20 > b) Operators should look at running more aggressive synchronization = intervals _internally_ within their organization/ASN, from "children" (2nd-= level) RPKI caches to the 'parent' (top-level) RPKI cache in their organiza= tion/ASN, compared to more "relaxed" synchronization intervals to RPKI cach= es external to their organization (top-level RPKI caches in their ASN to RI= R's)? > ---snip--- > Validated caches may also be created and maintained from other > validated caches. Network operators SHOULD take maximum advantage of > this feature to minimize load on the global distributed RPKI > database. Of course, the recipient SHOULD re-validate the data. > ---snip--- does b not address a, for those who want very tight synch. note that the RIRs were talking 24 hour publication cycles, last i heard (long ago, i admit). [ i thought this was nutso ] so a lot of this has yet to play out. > While I'm here, I don't think the text in Section 6, "Notes", addresses t= he above concerns, at all. In fact, I find it extremely unhelpful to just = dismiss this concern, out of hand, with the text: "There is no 'fix' for th= is, it is the nature of distributed data with distributed caches". We know= what the answer is here: you tune the synchronization intervals to strike = the appropriate balance between [very] tight synchronization vs. increased = load on the systems being synchronized. I find it hard to believe a simple= suggestion such as this is not proposed in the text, even including the ph= rase "the suggested values for such synchronization are outside the scope o= f this document, but will likely be subject to further studies to determine= optimal values based on field experience". sorry, dns taught us that the answer is not in just running it more frequently. you can narrow the windows, but you can not eliminate them. i wish we could, but the protocols which could provide a globally synchronized database would be extremely complex and just do not seem worth the effort in this case. your suggested text seems useful, and i will steal and modify if you do not mind. but i suspect we would find tuning has topological and delay sensitivities which will prevent optimal recipies. Timing of inter-cache synchronization is outside the scope of this document, but depends on things such as how often routers feed from the caches, how often the operator feels the global RPKI changes significantly, etc. > 3) Granted, the following text is only a "SHOULD", but the text offers n= o reasoning as to why caches should be placed close to routers, i.e.: are t= here latency concerns (for the RPKI <-> cache protocol), or is it that a ge= ographically distributed system is one way to avoid a single-point-of-failu= re, or something else entirely? As a start, just defining "close" would he= lp, e.g.: same POP, same (U.S.) state, same country, same timezone =E2=80= =A6 but, then a statement as to any latency or resiliency requirement for g= eographic deployment of RPKI caches wold be useful. we tried to go down this path and found it just got more and more complex with no real improvement. you probably want them in some diameter of transport trust. you probably want them in some diameter of routing bootstrap reach. you probably want them with reasonable latency characteristics. and there are probably more concerns. that's why you get the big bucks. :) As RPKI-based origin validation relies on the availability of RPKI data, operators SHOULD locate caches close to routers that require these data and services. 'Close' is, of course, complex. One should consider trust boundaries, routing bootstrap reachability, latency, etc. > Furthermore, given the [very] loosely synchronized nature of the RPKI= , should the text point out that the number of RPKI caches (internal to the= organization) be balanced against the potential need of an organization to= maintain a more tightly synchronized view, across their entire network, of= validated routing information? A concern might be that if routers in Cont= inent A pull information from their RPKI caches that tell them that ROA is = not "Invalid", but other routers in Continent B are still using 'older' inf= ormation in RPKI caches in Continent B that says the same ROA is either "No= t Found" or "Valid", then the result might be that BGP Path Selection swing= s all traffic from Continent A to Continent B. At a minimum, this could le= ad to substantially increased latency or, at worst, congestion, packet-loss= or a unintended DoS. =20 > ---snip--- > As RPKI-based origin validation relies on the availability of RPKI > data, operators SHOULD locate caches close to routers that require > these data and services. A router can peer with one or more nearby > caches. > ---snip--- see above > In Section 5, "Routing Policy": > 4) From a practical standpoint, LOCAL_PREF is already widely used to inf= luence Traffic Engineering, both by an SP as well as by the SP's customers = (through the use of "TE communities" sent by a downstream customer to the S= P) -- the latter of which is done in order so the customer can influence tr= affic from the SP toward themselves, (e.g.: one example where a customer pr= efers a circuit be 'backup' for another circuit only if their other SP is n= ot announcing that same prefix). In reality, I think that there will have = to be significant re-work of an SP's existing BGP policies to encode dual-m= eanings inside a single LOCAL_PREF attribute, (route validity + TE preferen= ce). It may be good to acknowledge this by recommending that in the text, = above, something like: > =3D=3D=3D=3D > In the short-term, the LOCAL_PREF Attribute may be used to carry both= the validity state of a prefix along with it's Traffic Engineering charact= eristic(s). It is likely that the SP will have to change their BGP policie= s such that they can encode these two, separate characteristics in the same= BGP attribute without negatively impacting their existing use or leading t= o accidental privilege escalation attacks.=20 > =3D=3D=3D=3D > ---snip--- > Some may choose to use the large Local-Preference hammer. > ---snip--- i would hesitate to tell you *how* to deal with local policy matters. the whole point of pfx-validate and this document is that you are free to do whatever is appropriate to your needs. we definitely do not want to tell you if or how you should complicate your use of local-pref. we did our best to avoid assuming you will affect local-pref at all. > 5) I have three comments on the below: > a) It's not clear, to me, what is meant by "internal metric" below. = Do you mean MED or IGP metric or something else? I don't see IGP metric a= s being practical, so I'm assuming you mean additively altering MED (up|dow= n) based on validity state. Regardless, I would recommend you state more p= recisely which BGP Path Attribute you're referring to below. we meant MED. jay caught this the other day, and it is fixed in the draft in my edit buffer. Some providers may choose to set Local-Preference based on the RPKI validation result. Other providers may not want the RPKI validation result to be more important than AS-path length -- these providers would need to map RPKI validation result to some BGP attribute that is evaluated in BGP's path selection process after AS-path is evaluated. Routers implementing RPKI-based origin validation MUST provide such options to operators. > b) Since MED is passed from one ASN to (only) a second, downstream A= SN to influence ingress TE policy, is it "OK" from a security PoV that MED = is a *trusted* means to convey ROA validity information from one ASN to a s= econd? Presumably, the answer should be "heck, no", right? If that's the = case, then wouldn't it be wise to state that: > i) MED's, encoded with any ROA validity information, should get = reset on egress from an ASN to remove said validity information and only ca= rry TE information, as appropriate; and, > ii) MED's should not be trusted on ingress to convey any meaning = with respect to validity information? > c) What is meant by the statement, "might choose to let AS-Path rule= "? Is your intent to state that an SP may choose to just use MED, which fo= llows after LOCAL_PREF & AS_PATH in the BGP Path Selection Algorithm, as a = means to determining validity of a particular prefix? If so, then it would= be much more clear if you just stated that, e.g.: > =3D=3D=3D=3D > If LOCAL_PREF is not used to convey validity information, then MED is= likely the next best candidate BGP Attribute that can be used to influence= path selection based on the validity of a particular prefix. As with LOCA= L_PREF, care must be taken to avoid changing the MED attribute and creating= privilege escalation attacks. > =3D=3D=3D=3D > ---snip--- > [=E2=80=A6] Others > might choose to let AS-Path rule and set their internal metric, which > comes after AS-Path in the BGP decision process. > ---snip--- if you trust MEDs from a neighbor you are either a fool or have a, likely rather complex, contractual and technical agreement. far be it from us to get into such matters. we abjure general inter-provider hygenic practices. this is not an inter-operator best practices document, we're just trying to inform you of where origin-validation may affect your design. > Other Comments: > 6) Related to #5, above, BGP Communities are another transitive attribut= e that /might/ be used to convey validity information of a prefix, or lack = thereof, from one ASN to a second ASN (or, more). However, as we know, the= re is no means to authenticate BGP Attributes, from one ASN to the next. S= o, from a security hygiene perspective, would it be best to say something a= long the lines of: > =3D=3D=3D=3D > The validity state of routes MUST NOT be transmitted beyond the borders o= f an SP's ASN, since: a) there is no authenticity of BGP Attributes; and, b= ) this would place hidden dependencies on the ability of the upstream ASN t= o validate routes and pass them along to others, which would increase the f= ragility of the overall system. Finally, ASN's MUST NOT rely on BGP Attrib= utes received on an eBGP session, to convey any meaning with respect to val= idity of a particular prefix for the reasons just stated. > =3D=3D=3D=3D ok, since you keep banging your head against this wall, it is clear that something saying "do not listen to validity information from another AS" is needed. Validity state signialing SHOULD NOT be accepted from a neighbor AS. The validity state of a received announcement has only local scope due to issues such as scope of trust, RPKI synchrony and . > 7) Is this document only intended (scoped?) to cover PE's that can (or, = eventually, will) speak the RPKI-RTR protocol for validation? Or is this d= ocument intended to also cover PE's that do not speak RPKI-RTR, but those P= E's would obviously need some other mechanism, (e.g.: periodically pushing = an updated config to them based on RPKI validated data), in order that they= could influence the policy applied to valid routes in such a way that is c= onsistent with other more modern routers that do run RPKI-RTR protocol? If= so, wouldn't it be good to suggest this, even if only as a means to increa= se the deployment speed? Or, to at least let readers know that this needs = to be considered during their deployment so that they can factor in the loa= d on their [existing] systems that might do this work as well as the effect= s of the 'loosely synchronized' aspects of the RPKI? the former randy From danny@tcb.net Sun Oct 30 06:41:16 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E749D21F8B2A for ; Sun, 30 Oct 2011 06:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kN8RJDLAH--V for ; Sun, 30 Oct 2011 06:41:16 -0700 (PDT) Received: from uu.ops-netman.net (morrowc-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:36e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7783F21F8B1C for ; Sun, 30 Oct 2011 06:41:16 -0700 (PDT) Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [208.76.12.119]) by uu.ops-netman.net (Postfix) with ESMTP id C8C4F190194; Sun, 30 Oct 2011 13:41:15 +0000 (UTC) Received: from dul1dmcphers-m2.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (Authenticated sender: danny@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id BA7973201C8; Sun, 30 Oct 2011 13:41:14 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Sun, 30 Oct 2011 09:41:14 -0400 Content-Transfer-Encoding: 7bit Message-Id: <39878AC4-65F0-429A-AF56-665598D6F383@tcb.net> References: <805B0799-7026-4532-A53C-4CFE3E863A33@castlepoint.net> To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 30 Oct 2011 13:41:17 -0000 On Oct 30, 2011, at 6:57 AM, Randy Bush wrote: > > note that the RIRs were talking 24 hour publication cycles, last i heard > (long ago, i admit). [ i thought this was nutso ] so a lot of this has > yet to play out. I see 4-6 hours in the document, but what do you really think is reasonable here for RIRs or other participants Randy? One of the concerns I have is publication or download delays for new information resulting in operational issues we all experienced with IRR object publication and mirroring that led to a slew of manual IRR [repository] downloads, routing policy updates, and route "bounces" or session resets. Given, we're in a far better place than this today with incrementally updated prefix filters and route refresh offsetting BGP/TCP statefulness, and prefix-validation with rpki-rtr to delivery origin validation data to routers helps with where we're going, but I'm still concerned that if we don't expressly aim to understand publication and synchronization dynamics issues can arise that lead to considerable delays in getting even "business day" resolution to a problem. -danny From aservin@lacnic.net Sun Oct 30 12:45:43 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F37C21F8B16 for ; Sun, 30 Oct 2011 12:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.91 X-Spam-Level: X-Spam-Status: No, score=0.91 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_DIALUP=0.862, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftE+jqMNJjtF for ; Sun, 30 Oct 2011 12:45:42 -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 B423321F8AED for ; Sun, 30 Oct 2011 12:45:42 -0700 (PDT) Received: from [192.168.1.103] (r186-48-252-23.dialup.adsl.anteldata.net.uy [186.48.252.23]) by mail.lacnic.net.uy (Postfix) with ESMTP id 0F930308427; Sun, 30 Oct 2011 17:45:34 -0200 (UYST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: Date: Sun, 30 Oct 2011 17:45:33 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0D73F66F-2A83-41E4-83D4-29F1A0893E1D@lacnic.net> References: To: Sandra Murphy X-Mailer: Apple Mail (2.1084) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: sidr@ietf.org Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 30 Oct 2011 19:45:43 -0000 I have read and support. /as On 20 Oct 2011, at 12:50, Sandra Murphy wrote: > The authors have requested a WG LC for draft "Algorithm Agility = Procedure for RPKI." >=20 > The document and the draft version history are available at > http://tools.ietf.org/html/draft-ietf-sidr-algorithm-agility-03 >=20 > The last call will end Thu, 3 Nov 2011 (AOE). >=20 > As usual, please address all comments to the WG mailing list, and > please be clear in your comments to this last call if you are > supporting the document's submission to the IESG or if you are > opposed. If you are opposed, please indicate why. >=20 > --Sandy, speaking as wg chair with appropriate ceremonial garb donned > (and covered with ashes for having neglected this) >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From paul.hoffman@vpnc.org Sun Oct 30 13:34:26 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8880221F850B for ; Sun, 30 Oct 2011 13:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPczyFHizaXh for ; Sun, 30 Oct 2011 13:34:26 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7D921F8488 for ; Sun, 30 Oct 2011 13:34:25 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p9UKYOi1066805 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 30 Oct 2011 13:34:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Sun, 30 Oct 2011 13:34:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5ED8776F-7757-4FED-8677-5C45349145CD@vpnc.org> References: To: Sandra Murphy X-Mailer: Apple Mail (2.1251.1) Cc: sidr@ietf.org Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 30 Oct 2011 20:34:26 -0000 I have read this document and think it should be published as a = standards-track RFC. It is fairly complex, but I could not find places = to reduce the complexity without removing scenarios that seem reasonably = likely to pop-up in real-world transitions. --Paul Hoffman= From danny@tcb.net Sun Oct 30 17:59:42 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67F721F84A6 for ; Sun, 30 Oct 2011 17:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x86rLvwIEWib for ; Sun, 30 Oct 2011 17:59:41 -0700 (PDT) Received: from uu.ops-netman.net (morrowc-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:36e::2]) by ietfa.amsl.com (Postfix) with ESMTP id AE2F221F849D for ; Sun, 30 Oct 2011 17:59:41 -0700 (PDT) Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [208.76.12.119]) by uu.ops-netman.net (Postfix) with ESMTP id 5BA771900B8; Mon, 31 Oct 2011 00:59:38 +0000 (UTC) Received: from dul1dmcphers-m2.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (Authenticated sender: danny@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id 8589D320283; Mon, 31 Oct 2011 00:59:37 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Sun, 30 Oct 2011 20:59:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7041B49A-6675-4010-B506-435AE2B7BF4C@tcb.net> References: To: Sandra Murphy , Steve Kent X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 31 Oct 2011 00:59:42 -0000 On Oct 20, 2011, at 10:50 AM, Sandra Murphy wrote: > The authors have requested a WG LC for draft "Algorithm Agility = Procedure for RPKI." >=20 > The document and the draft version history are available at > http://tools.ietf.org/html/draft-ietf-sidr-algorithm-agility-03 >=20 > The last call will end Thu, 3 Nov 2011 (AOE). --------------------------------------- Substantial; --- In S 4.6 (Phase 3) you state that all signed product sets are available using both algorithms and all RPs MUST be able to validate using either=20= suite. Further, you state that an object that validates using either=20 Algorithm Suite A or Algorithm Suite B MUST be considered valid,=20 but in the subsequent sentence it is "RECOMMENDED" that RPs utilize only Suite B for validation [throughout Phase 3]. =20 Is the recommendation you're making that if product sets are available=20= via both Algorithm Suite A and Algorithm Suite B then the Suite A = product sets SHOULD NOT be validated by RPs in order to minimize processing=20 overhead and the probability of cryptographic vulnerabilities resulting in downgrade attacks?=20 Or SHOULD NOT be validated by RPs unless Algorithm Suite B validation=20 failure occurs, then fallback to the Algorithm Suite A product set =20 should be considered? Or something else? S.6 guidelines provide "As=20 a general rule, the validation of signed objects using different=20 algorithm suites are independent and the RP MUST NOT keep any=20 relationship between the different hierarchies", which seems to be=20 in conflict with the recommendation above unless some implementation=20 optimization or minimization of vulnerability to downgrade attacks=20 is being contemplated? --- Whatever the recommended behavior, how would it also change in Phase 4 (Twilight), where a RP MAY continue to validate signed product sets using Suite C (old)? If there's a failure in validation of the=20 current algorithm then should it use the "old" objects? You seem to=20 suggest in S.6 that this is fine, but not in S.4.7? I think some more explicit guidelines about what to do and what not=20 to do would be useful in both Phase 3 and Phase 4 behavior that aligns with S.6 and clarifies the above issues would be of benefit. --- Also, in S.6 it's not clear to me what you mean by "instance of a=20 product" and "instances of such products", did you mean "signed=20 product sets" or something else? If the former, which I think you=20 did, then it would be really useful if this "MUST contain the same resources" was provided much earlier in the document.=20 "A failure to validate one instance of a product, under either=20 algorithm Suite MUST NOT cause the RP to reject the other instance=20 of the product. Because both instances of such products MUST contain=20 the same resources, relying on either instance will yield the same outcome." Whereas in Phase 4 both may not even exist, correct? =20 --- And given the above, if they "MUST contain the same resource", yet=20 S.7 says revocations are handled independently (even though during=20 phase 2 and phase 3 the "two certificate hierarchies are designed to=20 carry identical information" -- what does this mean?), how do you \ accomplish all of this in practice? --- Perhaps it should be that if two hierarchies exist they should be=20 identical - however, this diverges from the guidance that algorithm suites must be independent and the RPs MUST NOT keep any relationship between the different hierarchies. This applies to "fallback"=20 implementation behaviors as well, I guess... Also, general guidance that as long as "old" or Algorithm Suite C=20 data is considered in parallel to or IF "current" algorithm fails,=20 the cryptographic vulnerabilities that triggered the rollover in the=20 first place may well result in downgrade attacks. --------------------------------------- Minor nits: --- S 3 Terminology=20 - s/conventions use din examples/conventions used in examples/ - Two occurrences of this ("CA Y" & "CA Z"): s/used in examples this document/used in examples in this document/ --- S 4.2 Process Overview - s/prohibit a CA issuing/prohibit a CA from issuing/ --- S 4.7 Phase 4 s/figure describe a possible/figure describes a possible/ --- S 5 s/implementing a different resource classes/implementing different = resource classes/ --- S 11 s/set will not longer be valid/set will no longer be valid/ From terry.manderson@icann.org Sun Oct 30 19:18:53 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E27111E80A2 for ; Sun, 30 Oct 2011 19:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pvsintgsrXu for ; Sun, 30 Oct 2011 19:18:52 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9606A11E809F for ; Sun, 30 Oct 2011 19:18:52 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Sun, 30 Oct 2011 19:18:48 -0700 From: Terry Manderson To: "sidr@ietf.org" Date: Sun, 30 Oct 2011 19:18:46 -0700 Thread-Topic: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 Thread-Index: AcyPN6DKanq91Yz1QWmcfdgUHGAbjAIO8pB8 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-sidr-algorithm-agility@tools.ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 31 Oct 2011 02:18:53 -0000 Some comments. Section 4.3. Phase 0 I'm still struggling to see the necessity to put in the operational dates for a Alg shift in [I-D.ietf-sidr-rpki-algs]. I concur that the future Alg suite and to be EOL's suite should be identified once suitable candidates have been selected in rpki-algs. But the dates in which the ALGs come into effect[1], and are twiglighted/EOL'd seems like a operational CA/RP concern= , in a hierarchical manner, and would probably end up in the CA's CPS. As suc= h I question the viability, and validity, of fixing dates in the IETF. [1] I would think that as soon at the document is updated and published the= y are able to be used. Phase 3 This section confuses me, the draft says that the RF MUST be able to do bot= h algorithms, but its recommended to only use Suite B. The first sentence seems superfluous to me. Why not just: " Phase 3 starts at the RP Ready Algorithm B Date. During this phase, all signed product sets are available using both algorithm suites. It is RECOMMENDED that RPs utilize only Suite B for validation throughout this phase, in preparation for Phase 4. RPs MAY use Suite A if operationally necessary" ? (ie similar wording as used in the Phase 4 Suite A/C observation.) If that first sentence part " RPs MUST be able to .." is a necessity, it makes me start thinking about a matrix decision process of using Suite A (and|or) Suite B - which isn't described here. or perhaps not even mention the RP's responsibility to Suite A in Phase 3?? ... Phase 4. The ordering of the sentences could be shuffled I think. The important statement is that the "CAs MUST neither issue nor publish signed products using Algorithm Suite C" ... therefore any erroneous issuance of suite C products MUST be considered invalid. =20 Section 5. I think some discussion of the dates, and for communicating twilight and EO= L dates between the parent and the child should be here. I don't quite hold the belief that it's a unidirectional downward assertion from parent to child. In may well be in PKI - there there is a raft of operational interaction that surrounds that. Section 6. Can you spell out what you technically mean by "keep any relationship between " in para 1? Section 7. Can you expand the recommendation in keeping the parallel certificate hierarchies in sync by also identifying the Alg A/Alg C mix? (phase 4) Twilight doesn't necessarily mean "dead wood is o.k".. since products MAY still be constructed. .. If these concerns can be addressed, then I think the document is ready t= o move on. Cheers Terry On 21/10/11 12:50 AM, "Sandra Murphy" wrote: > The authors have requested a WG LC for draft "Algorithm Agility Procedure > for RPKI." >=20 > The document and the draft version history are available at > http://tools.ietf.org/html/draft-ietf-sidr-algorithm-agility-03 >=20 > The last call will end Thu, 3 Nov 2011 (AOE). >=20 > As usual, please address all comments to the WG mailing list, and > please be clear in your comments to this last call if you are > supporting the document's submission to the IESG or if you are > opposed. If you are opposed, please indicate why. >=20 > --Sandy, speaking as wg chair with appropriate ceremonial garb donned > (and covered with ashes for having neglected this) >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From shane@castlepoint.net Sun Oct 30 22:20:45 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8161A21F8C8F for ; Sun, 30 Oct 2011 22:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, MANGLED_STOP=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feDMcJ2Ar+kP for ; Sun, 30 Oct 2011 22:20:44 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id E7EBA21F8B04 for ; Sun, 30 Oct 2011 22:20:43 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 9FFD1268063; Sun, 30 Oct 2011 23:20:38 -0600 (MDT) Received: from mbpw.castlepoint.net (65-102-206-76.hlrn.qwest.net [65.102.206.76]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sun, 30 Oct 2011 23:20:38 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.102.206.76; client-port=64388; syn-fingerprint=65535:54:1:64:M1452,N,W2,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Shane Amante In-Reply-To: Date: Sun, 30 Oct 2011 23:20:21 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6054A2B1-40D3-49E6-8972-946D426E830B@castlepoint.net> References: <805B0799-7026-4532-A53C-4CFE3E863A33@castlepoint.net> To: Randy Bush X-Mailer: Apple Mail (2.1251.1) Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 31 Oct 2011 05:20:45 -0000 Hi Randy, On Oct 30, 2011, at 4:57 AM, Randy Bush wrote: [--snip--] >> 1) =46rom Section 3: >> ---snip--- >> A local valid cache containing all RPKI data may be gathered from = the >> global distributed database using the rsync protocol, [RFC5781], = and >> a validation tool such as rcynic [rcynic]. >> ---snip--- >>=20 >> Would it be possible to mention and/or point to how the above process = is supposed to be bootstrapped? IOW, is it expected that, eventually?, = the RIR's are going to publish to their end-users and maintain URI's of = RPKI publication points? Since this is an Ops guidelines document, some = guidance and/or pointers are likely to save [lots of] questions down the = road. I'm not expecting this to be a tutorial document, but some idea = on the theory of how a new SP bootstraps their cache(s) would be = helpful. >=20 > uh, i am not clear on what you actually want here. in the minimal = case, > the op should just run rcynic or some equivalent relying party tool, = as > it says. in the more complex/large case, good quality RP cache code > should be able to feed from other RP caches. Let me try again. :-) Assume that I'm Joe Random Operator and I'm new = to this SIDR thing. I've just installed my first RPKI cache and would = like to bootstrap it with a full set of RPKI data from "the world". To = what RIR's or RP's (or, both) do I go to bootstrap my RPKI cache for the = very first time? >> 2) Given that, to my knowledge, the RPKI is [very] loosely = synchronized in a "pull-only" fashion, shouldn't there be some text = added below to that effect that: >> a) It may not be best to go more than, say, 2 levels of RPKI = caches deep inside a single organization/ASN to avoid RPKI caches from = being out of sync with each other? IOW, there are likely a small set of = 1st/top-level RPKI caches that speak externally to fetch RPKI cache = information, (similar to 'hidden' authoritative DNS servers), then a = second tier of RPKI caches that synchronize (only) from the top-level = RPKI caches, (similar to external, anycast authoritative DNS servers).=20= >> b) Operators should look at running more aggressive = synchronization intervals _internally_ within their organization/ASN, = from "children" (2nd-level) RPKI caches to the 'parent' (top-level) RPKI = cache in their organization/ASN, compared to more "relaxed" = synchronization intervals to RPKI caches external to their organization = (top-level RPKI caches in their ASN to RIR's)? >> ---snip--- >> Validated caches may also be created and maintained from other >> validated caches. Network operators SHOULD take maximum advantage = of >> this feature to minimize load on the global distributed RPKI >> database. Of course, the recipient SHOULD re-validate the data. >> ---snip--- >=20 > does b not address a, for those who want very tight synch. I don't believe so: (a) attempts to address the concern in the draft = that you don't want, potentially, dozens of RPKI caches inside a single = operator hammering the same set of _external_ RPKI caches "constantly"; = (b) suggests that since you've got a hierarchy of RPKI caches in your = own ASN, that you most likely _can_ and _should_ keep the 2nd-level of = RPKI caches in sync to each other, as best as possible, in order that = when that when RPKI information is pushed/pulled into the routers, via = RPKI-RTR, that you're hopefully affecting routing policy in your control = plane and, hence, forwarding of traffic through your whole AS in a = consistent way at nearly the same time. I view them as two, separate, = but related matters. I would be fine if you suggested that for it is envisioned that a tiered = approach to RPKI caches makes sense for "large backbones" and that for = "small stub/enterprise/edge networks", (to quote the classification of = networks already in Section 1), they may be fine with a single-tier of a = handful of RPKI caches. =20 > note that the RIRs were talking 24 hour publication cycles, last i = heard > (long ago, i admit). [ i thought this was nutso ] so a lot of this = has > yet to play out. Re: RIR's + 24 hours =85 IMO, that mainly affects the interval at which = it is reasonable for an operator's "top-level" set of RPKI caches go = after a "fresh" set of RPKI data. Again, once the 'top-level' RPKI = caches get that data, then I would strongly prefer the "window of time" = (IOW, the 'duration') that it takes to cascade that fresh set of data = out to my 2nd-level of RPKI caches is as narrow as possible in order = that when RPKI-RTR pushes or routers pull that data from their RPKI = caches, they're doing so in a very short window of time. That way, = if/when BGP policy is affected by new information in the RPKI, it's not = leading to [very] long-lived improper/inconsistent forwarding in the = network. >> While I'm here, I don't think the text in Section 6, "Notes", = addresses the above concerns, at all. In fact, I find it extremely = unhelpful to just dismiss this concern, out of hand, with the text: = "There is no 'fix' for this, it is the nature of distributed data with = distributed caches". We know what the answer is here: you tune the = synchronization intervals to strike the appropriate balance between = [very] tight synchronization vs. increased load on the systems being = synchronized. I find it hard to believe a simple suggestion such as = this is not proposed in the text, even including the phrase "the = suggested values for such synchronization are outside the scope of this = document, but will likely be subject to further studies to determine = optimal values based on field experience". >=20 > sorry, dns taught us that the answer is not in just running it more > frequently. you can narrow the windows, but you can not eliminate = them. > i wish we could, but the protocols which could provide a globally > synchronized database would be extremely complex and just do not seem > worth the effort in this case. To be clear, I recognize that perfect synchronization is hard; however, = I'm asking you to acknowledge that one needs to attain much better than = lackadaisical synchronization so that there isn't, potentially, massive = sloshing of traffic around the network due to new RPKI data showing up = in routers at vastly different times. See just below where I hope you = can find additional text that might satisfy my concern. > your suggested text seems useful, and i will steal and modify if you = do > not mind. but i suspect we would find tuning has topological and = delay > sensitivities which will prevent optimal recipies. >=20 > Timing of inter-cache synchronization is outside the scope of > this document, but depends on things such as how often routers > feed from the caches, how often the operator feels the global = RPKI > changes significantly, etc. I would appreciate it if you could also acknowledge that cache = synchronization intervals also has a very important dependency on = ensuring that all routers in an operator's ASN get updated in as short a = time-interval (duration) as possible to ensure there is consistent = application of BGP policy and, hence, forwarding of traffic. =20 >> 3) Granted, the following text is only a "SHOULD", but the text = offers no reasoning as to why caches should be placed close to routers, = i.e.: are there latency concerns (for the RPKI <-> cache protocol), or = is it that a geographically distributed system is one way to avoid a = single-point-of-failure, or something else entirely? As a start, just = defining "close" would help, e.g.: same POP, same (U.S.) state, same = country, same timezone =85 but, then a statement as to any latency or = resiliency requirement for geographic deployment of RPKI caches wold be = useful. >=20 > we tried to go down this path and found it just got more and more > complex with no real improvement. you probably want them in some > diameter of transport trust. you probably want them in some diameter = of > routing bootstrap reach. you probably want them with reasonable = latency > characteristics. and there are probably more concerns. that's why = you > get the big bucks. :) I'm more concerned for the 100's or 1000's of engineers that were not = participating in this initial development effort and will be left = wondering what, at a high-level, the thinking/background/concerns were = that went into these guidelines. With that information, future = engineers can then weigh those criteria for themselves to decide if they = are applicable to their environment, how they are applicable to their = environment, etc.=20 Remember, ultimately what you're laying out here is going to be read by = engineers who are going to look at buying actual server HW, and network = ports to attach them to, to set-up an RPKI in their network. The more = background material you give them the more confident they will be on = putting together a budget estimate to start such a project =85=20 > As RPKI-based origin validation relies on the availability of > RPKI data, operators SHOULD locate caches close to routers that > require these data and services. 'Close' is, of course, complex. > One should consider trust boundaries, routing bootstrap > reachability, latency, etc. While I appreciate the attempt, I don't think the above satisfies my = concern. What 'trust boundaries' are you referring to, e.g.: within = your ASN, not within your ASN but within your organization or = neither/other? With respect to latency, is what you're attempting to = say that it's recommended to engineer for a high BW x low delay product, = in order to achieve fast xfers of data between RPKI caches and also data = between the RPKI cache to the routers? If so, then aren't you conceding = that low latency is necessary in order to _strive_ to attain "good = [enough]" synchronization between all RPKI caches in the network so that = 'new' RPKI data that affects BGP policy gets uniformly applied across = all routers in the network at roughly the same time?=20 Also, you mention 'routing bootstrap reachability'. That's actually a = very good point and I don't recall seeing anything about that in this = document anywhere. (If it already is, I apologize). Assuming there's = nothing about that in here, then wouldn't it be good to state some = guidelines around this in Section 7, Security Considerations, like: =3D=3D=3D=3D It is recommended that operators SHOULD log _and_ exclude *new* RPKI = data that downgrades the previous state of ROA's, (e.g.: from Valid -> = Invalid or Valid -> Not Found), associated with external RPKI caches, = root DNS servers and ccTLD DNS servers so as not to cause a DoS that = would lead to an inability to gather fresh, accurate RPKI data. This = information should be evaluated by a human and manually pushed out to = RPKI caches and routers in the network after it has been validated as = correct. =3D=3D=3D=3D Speaking of which, is it possible to use anything in ghostbusters to = 'aid' in the recognition of those critical infrastructure ROA's? Anyway, the point is we are supposed to be avoiding (automated) circular = dependencies here and it would be worth pointing those out to operators, = when they read this, so they don't forget to take them into account. >> Furthermore, given the [very] loosely synchronized nature of the = RPKI, should the text point out that the number of RPKI caches (internal = to the organization) be balanced against the potential need of an = organization to maintain a more tightly synchronized view, across their = entire network, of validated routing information? A concern might be = that if routers in Continent A pull information from their RPKI caches = that tell them that ROA is not "Invalid", but other routers in Continent = B are still using 'older' information in RPKI caches in Continent B that = says the same ROA is either "Not Found" or "Valid", then the result = might be that BGP Path Selection swings all traffic from Continent A to = Continent B. At a minimum, this could lead to substantially increased = latency or, at worst, congestion, packet-loss or a unintended DoS. =20 >> ---snip--- >> As RPKI-based origin validation relies on the availability of RPKI >> data, operators SHOULD locate caches close to routers that require >> these data and services. A router can peer with one or more nearby >> caches. >> ---snip--- >=20 > see above This didn't address my concern, which is primarily about consistent = policy across the network at any given moment in time. >> In Section 5, "Routing Policy": >> 4) =46rom a practical standpoint, LOCAL_PREF is already widely used = to influence Traffic Engineering, both by an SP as well as by the SP's = customers (through the use of "TE communities" sent by a downstream = customer to the SP) -- the latter of which is done in order so the = customer can influence traffic from the SP toward themselves, (e.g.: one = example where a customer prefers a circuit be 'backup' for another = circuit only if their other SP is not announcing that same prefix). In = reality, I think that there will have to be significant re-work of an = SP's existing BGP policies to encode dual-meanings inside a single = LOCAL_PREF attribute, (route validity + TE preference). It may be good = to acknowledge this by recommending that in the text, above, something = like: >> =3D=3D=3D=3D >> In the short-term, the LOCAL_PREF Attribute may be used to carry = both the validity state of a prefix along with it's Traffic Engineering = characteristic(s). It is likely that the SP will have to change their = BGP policies such that they can encode these two, separate = characteristics in the same BGP attribute without negatively impacting = their existing use or leading to accidental privilege escalation = attacks.=20 >> =3D=3D=3D=3D >> ---snip--- >> Some may choose to use the large Local-Preference hammer. >> ---snip--- >=20 > i would hesitate to tell you *how* to deal with local policy matters. > the whole point of pfx-validate and this document is that you are free > to do whatever is appropriate to your needs. we definitely do not = want > to tell you if or how you should complicate your use of local-pref. > we did our best to avoid assuming you will affect local-pref at all. I understand, but since the document has waved its hands that LOCAL_PREF = is a potentially viable method that has a very low-bar to deployment, = you could at least acknowledge that fact with a little more detail that = there are existing uses of LOCAL_PREF and how to accommodate those + = this new validity data. >> 5) I have three comments on the below: >> a) It's not clear, to me, what is meant by "internal metric" = below. Do you mean MED or IGP metric or something else? I don't see = IGP metric as being practical, so I'm assuming you mean additively = altering MED (up|down) based on validity state. Regardless, I would = recommend you state more precisely which BGP Path Attribute you're = referring to below. >=20 > we meant MED. jay caught this the other day, and it is fixed in the > draft in my edit buffer. >=20 > Some providers may choose to set Local-Preference based on the > RPKI validation result. Other providers may not want the RPKI > validation result to be more important than AS-path length -- > these providers would need to map RPKI validation result to some > BGP attribute that is evaluated in BGP's path selection process > after AS-path is evaluated. Routers implementing RPKI-based > origin validation MUST provide such options to operators. That looks good. >> b) Since MED is passed from one ASN to (only) a second, = downstream ASN to influence ingress TE policy, is it "OK" from a = security PoV that MED is a *trusted* means to convey ROA validity = information from one ASN to a second? Presumably, the answer should be = "heck, no", right? If that's the case, then wouldn't it be wise to = state that: >> i) MED's, encoded with any ROA validity information, should = get reset on egress from an ASN to remove said validity information and = only carry TE information, as appropriate; and, >> ii) MED's should not be trusted on ingress to convey any = meaning with respect to validity information? >> c) What is meant by the statement, "might choose to let AS-Path = rule"? Is your intent to state that an SP may choose to just use MED, = which follows after LOCAL_PREF & AS_PATH in the BGP Path Selection = Algorithm, as a means to determining validity of a particular prefix? = If so, then it would be much more clear if you just stated that, e.g.: >> =3D=3D=3D=3D >> If LOCAL_PREF is not used to convey validity information, then MED = is likely the next best candidate BGP Attribute that can be used to = influence path selection based on the validity of a particular prefix. = As with LOCAL_PREF, care must be taken to avoid changing the MED = attribute and creating privilege escalation attacks. >> =3D=3D=3D=3D >> ---snip--- >> [=85] Others >> might choose to let AS-Path rule and set their internal metric, = which >> comes after AS-Path in the BGP decision process. >> ---snip--- >=20 > if you trust MEDs from a neighbor you are either a fool or have a, > likely rather complex, contractual and technical agreement. far be it > from us to get into such matters. we abjure general inter-provider > hygenic practices. this is not an inter-operator best practices > document, we're just trying to inform you of where origin-validation > may affect your design. I believe you've acknowledged this concern with the text just below re: = the more general statement about passing validity information on to = third-parties via BGP attributes. >> Other Comments: >> 6) Related to #5, above, BGP Communities are another transitive = attribute that /might/ be used to convey validity information of a = prefix, or lack thereof, from one ASN to a second ASN (or, more). = However, as we know, there is no means to authenticate BGP Attributes, = from one ASN to the next. So, from a security hygiene perspective, = would it be best to say something along the lines of: >> =3D=3D=3D=3D >> The validity state of routes MUST NOT be transmitted beyond the = borders of an SP's ASN, since: a) there is no authenticity of BGP = Attributes; and, b) this would place hidden dependencies on the ability = of the upstream ASN to validate routes and pass them along to others, = which would increase the fragility of the overall system. Finally, = ASN's MUST NOT rely on BGP Attributes received on an eBGP session, to = convey any meaning with respect to validity of a particular prefix for = the reasons just stated. >> =3D=3D=3D=3D >=20 > ok, since you keep banging your head against this wall, it is clear = that > something saying "do not listen to validity information from another = AS" > is needed. >=20 > Validity state signialing SHOULD NOT be accepted from a neighbor > AS. The validity state of a received announcement has only local > scope due to issues such as scope of trust, RPKI synchrony and > . That looks good, but I would suggest a minor change to the latter part = of the first sentence: s/from a neighbor AS/from a neighbor AS that is not under your = organization's direct control/ >> 7) Is this document only intended (scoped?) to cover PE's that can = (or, eventually, will) speak the RPKI-RTR protocol for validation? Or = is this document intended to also cover PE's that do not speak RPKI-RTR, = but those PE's would obviously need some other mechanism, (e.g.: = periodically pushing an updated config to them based on RPKI validated = data), in order that they could influence the policy applied to valid = routes in such a way that is consistent with other more modern routers = that do run RPKI-RTR protocol? If so, wouldn't it be good to suggest = this, even if only as a means to increase the deployment speed? Or, to = at least let readers know that this needs to be considered during their = deployment so that they can factor in the load on their [existing] = systems that might do this work as well as the effects of the 'loosely = synchronized' aspects of the RPKI? >=20 > the former OK. So, then in Section 1, would it be prudent to say something to the = affect of: =3D=3D=3D=3D The scope of this document is intended to discuss application of RPKI = cache data to routers that speak the RPKI-RTR protocol. Other uses, = such pushing RPKI data into routers through a Service Provider's = existing management systems or software are outside the scope of this = document. =3D=3D=3D=3D Thanks, -shane= From shane@castlepoint.net Sun Oct 30 23:02:09 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31CAB21F8C99 for ; Sun, 30 Oct 2011 23:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5e8H6r1tHPx for ; Sun, 30 Oct 2011 23:02:08 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 8D70321F8C9C for ; Sun, 30 Oct 2011 23:02:08 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id C6A2B268063; Mon, 31 Oct 2011 00:02:03 -0600 (MDT) Received: from mbpw.castlepoint.net (65-102-206-76.hlrn.qwest.net [65.102.206.76]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Mon, 31 Oct 2011 00:02:03 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.102.206.76; client-port=64722; syn-fingerprint=65535:54:1:64:M1452,N,W2,N,N,T,S; data-bytes=0 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Shane Amante In-Reply-To: Date: Mon, 31 Oct 2011 00:01:46 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <18DE49F0-AAC3-4C02-A122-6B9EF5F6C445@castlepoint.net> References: To: sidr wg list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 31 Oct 2011 06:02:09 -0000 I do have one question about this draft. In looking at all of the = requirements for BGPSec, are AS migration scenarios in- or out-of-scope = for BGPSec? IOW, when one SP (AS A) buys/merges with another SP (AS B) = what typically happens is they will consolidate to a single ASN, e.g.: = either AS A or AS B. The primary goal is to (try to) do that rapidly = _without_ requiring /any/ coordination and as little disruption as = possible across a very large set of the SP's customers. As such, = several years ago [several] vendors have implemented features that = satisfy this requirement: = http://www.cisco.com/en/US/docs/ios/12_3t/12_3t11/feature/guide/gtbgpdas.h= tml = http://www.juniper.net/techpubs/en_US/junos11.3/topics/reference/configura= tion-statement/local-as-edit-protocols-bgp.html There are several permutations of the aforementioned feature; however, = the overall goal of these features is to NOT alter the AS_PATH length, = either on receipt or transmission of the AS_PATH (during the length of = time of the migration), since AS_PATH length plays a crucial role in = BGP's path selection algorithm and, ultimately, the amount of traffic = sent or received to that SP. I am unaware of any draft or RFC within the IETF that one could refer to = with more detail on the above features, but I may be misinformed. = However, I will state (emphatically) that these features are currently = being used now and will continue to be used in the future. If ASN migrations are not going to be accounted for in BGPSEC, then = would it be prudent to explicitly say so in Req #3.4 wrt "operational = considerations for deployment" in the "e.g." part: ---snip--- 3.4 A BGPsec design MUST provide analysis of the operational considerations for deployment and particularly of incremental deployment, e.g, contiguous islands, non-contiguous islands, universal deployment, etc.. ---snip--- Thanks, -shane On Oct 28, 2011, at 12:40 PM, Christopher Morrow wrote: > Seems that the authors, at least, expect this doc to be prepared for > WGLC, could we do that concluding 11/11/11 please? >=20 > Draft link: = > 01 link: > diff link: = >=20 > 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." >=20 > Thanks! > -Chris > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From internet-drafts@ietf.org Mon Oct 31 03:18:52 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C5021F8D1A; Mon, 31 Oct 2011 03:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kd49rGtSFojI; Mon, 31 Oct 2011 03:18:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C45C21F8D16; Mon, 31 Oct 2011 03:18:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031101852.11663.83080.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 03:18:52 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-origin-ops-12.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 10:18:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : RPKI-Based Origin Validation Operation Author(s) : Randy Bush Filename : draft-ietf-sidr-origin-ops-12.txt Pages : 9 Date : 2011-10-31 Deployment of RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present them. It is expected to evolve as RPKI-based origin validation is deployed and the dynamics are better understood. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-origin-ops-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-origin-ops-12.txt From internet-drafts@ietf.org Mon Oct 31 03:21:49 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF9821F8D4C; Mon, 31 Oct 2011 03:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFQJqUBl1fmX; Mon, 31 Oct 2011 03:21:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F360021F8D32; Mon, 31 Oct 2011 03:21:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031102148.12694.37211.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 03:21:48 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-19.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, 31 Oct 2011 10:21:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : The RPKI/Router Protocol Author(s) : Randy Bush Rob Austein Filename : draft-ietf-sidr-rpki-rtr-19.txt Pages : 25 Date : 2011-10-31 In order to formally validate the origin ASs of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-19.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-19.txt From kent@bbn.com Mon Oct 31 03:57:07 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078EB21F8D84 for ; Mon, 31 Oct 2011 03:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.358 X-Spam-Level: X-Spam-Status: No, score=-106.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bo6QTZQ+sYS7 for ; Mon, 31 Oct 2011 03:57:06 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 59E9221F8D82 for ; Mon, 31 Oct 2011 03:57:06 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:47077 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RKpY6-000Czw-Ta; Mon, 31 Oct 2011 06:57:03 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 31 Oct 2011 06:57:00 -0400 To: Terry Manderson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "draft-ietf-sidr-algorithm-agility@tools.ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 31 Oct 2011 10:57:07 -0000 At 7:18 PM -0700 10/30/11, Terry Manderson wrote: >Some comments. > >Section 4.3. Phase 0 > >I'm still struggling to see the necessity to put in the operational dates >for a Alg shift in [I-D.ietf-sidr-rpki-algs]. I concur that the future Alg >suite and to be EOL's suite should be identified once suitable candidates >have been selected in rpki-algs. But the dates in which the ALGs come into >effect[1], and are twiglighted/EOL'd seems like a operational CA/RP concern, >in a hierarchical manner, and would probably end up in the CA's CPS. As such >I question the viability, and validity, of fixing dates in the IETF. We have included dates for alg start an EOL because they affect all RPs, and we want to make life predictable for RPs. Also, because the WG agreed that alg transition will be top-down (to avoid geometric growth in the repository system), it is necessary to set alg transition dates, for the benefit of CAs as well. >[1] I would think that as soon at the document is updated and published they >are able to be used. The top tier CAs have to be ready to issue certs under the new alg before any lower tier CAs can do so, so we need a set date, agreed upon, in the future, to start the transition. >Phase 3 > >This section confuses me, the draft says that the RF MUST be able to do both >algorithms, but its recommended to only use Suite B. > >The first sentence seems superfluous to me. Why not just: >" Phase 3 starts at the RP Ready Algorithm B Date. During this phase, > all signed product sets are available using both algorithm suites. > It is RECOMMENDED that RPs utilize only > Suite B for validation throughout this phase, in preparation for > Phase 4. RPs MAY use Suite A if operationally necessary" ? (ie similar >wording as used in the Phase 4 Suite A/C observation.) > >If that first sentence part " RPs MUST be able to .." is a necessity, it >makes me start thinking about a matrix decision process of using Suite A >(and|or) Suite B - which isn't described here. > >or perhaps not even mention the RP's responsibility to Suite A in Phase 3?? >... We want to encourage RPs to verify their ability to use the new Suite, but we also realize that, during transition, there may be problems. So, we RECOMMEND use of Suite B, but require that if either Suite works, the RP MUST accept the data as valid. That provides a fall back position in case a CA doesn't get it right. >Phase 4. > >The ordering of the sentences could be shuffled I think. > >The important statement is that the "CAs MUST neither issue nor publish >signed products using Algorithm Suite C" ... therefore any erroneous >issuance of suite C products MUST be considered invalid. we can revisit this text to try to make it clearer, if others agree with your observation. > Section 5. > >I think some discussion of the dates, and for communicating twilight and EOL >dates between the parent and the child should be here. I don't quite hold >the belief that it's a unidirectional downward assertion from parent to >child. In may well be in PKI - there there is a raft of operational >interaction that surrounds that. The dates for alg transition are published and accessible to everyone, so there is no need for pairwise communication of the dates. Because the alg transition affects ALL RPs, not just the children of a given CA, it is important to mandate the transitions on a global basis. >Section 6. > >Can you spell out what you technically mean by "keep any relationship >between " in para 1? We will revise this sentence. The text is intended to note that the data extracted from the repository, signed under each alg, are treated separately. Thus one gets a compete, valid chain of data via Suite A or Suite B, but not a mix of data under A and B. The next paragraph explains this. >Section 7. > >Can you expand the recommendation in keeping the parallel certificate >hierarchies in sync by also identifying the Alg A/Alg C mix? (phase 4) In phase 4, Suite C products MAY be present, which means that they also may be absent. So, we cannot say that the hierarchies are parallel any more. >Twilight doesn't necessarily mean "dead wood is o.k".. since products MAY >still be constructed. Not sure what you mean by the above sentence. Steve From terry.manderson@icann.org Mon Oct 31 05:31:51 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD57721F8CD3 for ; Mon, 31 Oct 2011 05:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1JKuNvdxo-b for ; Mon, 31 Oct 2011 05:31:51 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 52B6021F84A8 for ; Mon, 31 Oct 2011 05:31:51 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 31 Oct 2011 05:31:47 -0700 From: Terry Manderson To: Stephen Kent Date: Mon, 31 Oct 2011 05:31:44 -0700 Thread-Topic: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 Thread-Index: AcyXv0aDq1+UnVixQh+dNSLgVoq5/AACcXyY Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-sidr-algorithm-agility@tools.ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 31 Oct 2011 12:31:52 -0000 On 31/10/11 8:57 PM, "Stephen Kent" wrote: > At 7:18 PM -0700 10/30/11, Terry Manderson wrote: >=20 > We have included dates for alg start an EOL because they affect all > RPs, and we want to make life predictable for RPs. Also, because the > WG agreed that alg transition will be top-down (to avoid geometric > growth in the repository system), it is necessary to set alg > transition dates, for the benefit of > CAs as well. >=20 I understand why you want to, but don't come to the same conclusion as to the mechanism. Is that really the IETF's job? Is there prior art in the IETF where this has been done in such a date specific manner? >> [1] I would think that as soon at the document is updated and published = they >> are able to be used. >=20 > The top tier CAs have to be ready to issue certs under the new alg before > any lower tier CAs can do so, so we need a set date, agreed upon, in > the future, > to start the transition. Call me a dirty rotten cynic but I just don't see this operational aspect o= f one or more running RPKI hierarchies as part of the IETF. Although you can prove me wrong, and I'll concede to an already enacted example where dates were set for some artifact. >=20 > We want to encourage RPs to verify their ability to use the new Suite, bu= t > we also realize that, during transition, there may be problems. So, > we RECOMMEND use of Suite B, but require that if either Suite works, > the RP MUST accept the data as valid. That provides a fall back > position in case a CA doesn't get it right. >=20 In which case some clarification to the text could go a long way. I suspect in the effort to simplify a complex process the text became too brief. >> issuance of suite C products MUST be considered invalid. >=20 > we can revisit this text to try to make it clearer, if others agree with > your observation. >=20 >> Section 5. >>=20 >> I think some discussion of the dates, and for communicating twilight and= EOL >> dates between the parent and the child should be here. I don't quite hol= d >> the belief that it's a unidirectional downward assertion from parent to >> child. In may well be in PKI - there there is a raft of operational >> interaction that surrounds that. >=20 > The dates for alg transition are published and accessible to > everyone, so there is no need for pairwise communication of the > dates. Because the alg transition affects ALL RPs, not just the > children of a given CA, it is important to mandate the transitions on > a global basis. >=20 I'm still not with you on this - I understand that it makes life easy to sa= y "the IETF said 12/12/2018 is D-Day, get with it" .. ... buuuutt I see that as a step beyond what the IETF should do. Noting the "fun" had with 6to4. >> Section 6. >>=20 >> Can you spell out what you technically mean by "keep any relationship >> between " in para 1? >=20 > We will revise this sentence. The text is intended to note that the > data extracted from the repository, signed under each alg, are > treated separately. Thus one gets a compete, valid chain of data via > Suite A or Suite B, but not a mix of data under A and B. The next > paragraph explains this. right, there is a discontinuous leap there that I didn't get. Clarification would be appreciated. >=20 >> Section 7. >>=20 >> Can you expand the recommendation in keeping the parallel certificate >> hierarchies in sync by also identifying the Alg A/Alg C mix? (phase 4) >=20 > In phase 4, Suite C products MAY be present, which means that they > also may be absent. So, we cannot say that the hierarchies are > parallel any more. So perhaps suggest to the RP/Child CA that in the situation where a revocation is issued for Suite A, _if_ there are products with matching information for the Suite A revocation, a Suite C revocation should also be issued. >=20 >> Twilight doesn't necessarily mean "dead wood is o.k".. since products MA= Y >> still be constructed. >=20 > Not sure what you mean by the above sentence. I think the above clarifies my meaning. Cheers Terry From wesley.george@twcable.com Mon Oct 31 06:53:30 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A83821F8CFC for ; Mon, 31 Oct 2011 06:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.646 X-Spam-Level: X-Spam-Status: No, score=-0.646 tagged_above=-999 required=5 tests=[AWL=0.817, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9i6wuROJkyf for ; Mon, 31 Oct 2011 06:53:30 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6289121F8CF5 for ; Mon, 31 Oct 2011 06:53:29 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,432,1315195200"; d="scan'208";a="291525210" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 31 Oct 2011 09:49:27 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Mon, 31 Oct 2011 09:53:28 -0400 From: "George, Wes" To: Shane Amante , Randy Bush Date: Mon, 31 Oct 2011 09:53:27 -0400 Thread-Topic: [sidr] WGLC: draft-ietf-sidr-origin-ops Thread-Index: AcyXjNrgiF+Gy75TRJWd7RU7BsN3FAARLCdA Message-ID: References: <805B0799-7026-4532-A53C-4CFE3E863A33@castlepoint.net> <6054A2B1-40D3-49E6-8972-946D426E830B@castlepoint.net> In-Reply-To: <6054A2B1-40D3-49E6-8972-946D426E830B@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 31 Oct 2011 13:53:30 -0000 Randy, I think I know why you keep calling me Shane - we tend to raise simi= lar concerns on your drafts ;-) See also http://www.ietf.org/mail-archive/web/sidr/current/msg03408.html Shane articulates it better, but consider this a +1 on his comments regardi= ng the -12 proposed text. The only other place I could see this background = info being is in the design rationale draft, which could then be referenced= from this document. Otherwise, this is critical guidance for operators try= ing to determine the best way to implement this in their networks. Ditto for the 4-6 hour recommendation and Danny's comments. Rationale, plea= se. Wes > >> 3) Granted, the following text is only a "SHOULD", but the text > offers no reasoning as to why caches should be placed close to routers, > i.e.: are there latency concerns (for the RPKI <-> cache protocol), or > is it that a geographically distributed system is one way to avoid a > single-point-of-failure, or something else entirely? As a start, just > defining "close" would help, e.g.: same POP, same (U.S.) state, same > country, same timezone ... but, then a statement as to any latency or > resiliency requirement for geographic deployment of RPKI caches wold be > useful. > > > > we tried to go down this path and found it just got more and more > > complex with no real improvement. you probably want them in some > > diameter of transport trust. you probably want them in some diameter > > of routing bootstrap reach. you probably want them with reasonable > > latency characteristics. and there are probably more concerns. > > that's why you get the big bucks. :) > > I'm more concerned for the 100's or 1000's of engineers that were not > participating in this initial development effort and will be left > wondering what, at a high-level, the thinking/background/concerns were > that went into these guidelines. With that information, future > engineers can then weigh those criteria for themselves to decide if > they are applicable to their environment, how they are applicable to > their environment, etc. > > Remember, ultimately what you're laying out here is going to be read by > engineers who are going to look at buying actual server HW, and network > ports to attach them to, to set-up an RPKI in their network. The more > background material you give them the more confident they will be on > putting together a budget estimate to start such a project ... > > > As RPKI-based origin validation relies on the availability of > > RPKI data, operators SHOULD locate caches close to routers that > > require these data and services. 'Close' is, of course, > complex. > > One should consider trust boundaries, routing bootstrap > > reachability, latency, etc. > > While I appreciate the attempt, I don't think the above satisfies my > concern. What 'trust boundaries' are you referring to, e.g.: within > your ASN, not within your ASN but within your organization or > neither/other? With respect to latency, is what you're attempting to > say that it's recommended to engineer for a high BW x low delay > product, in order to achieve fast xfers of data between RPKI caches and > also data between the RPKI cache to the routers? If so, then aren't > you conceding that low latency is necessary in order to _strive_ to > attain "good [enough]" synchronization between all RPKI caches in the > network so that 'new' RPKI data that affects BGP policy gets uniformly > applied across all routers in the network at roughly the same time? > This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From wesley.george@twcable.com Mon Oct 31 10:23:55 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D0D21F8B04; Mon, 31 Oct 2011 10:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 tagged_above=-999 required=5 tests=[AWL=0.670, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RrC6Thf9aYT; Mon, 31 Oct 2011 10:23:54 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6BE21F87C9; Mon, 31 Oct 2011 10:23:54 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,432,1315195200"; d="scan'208";a="291640538" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 31 Oct 2011 13:19:52 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Mon, 31 Oct 2011 13:23:53 -0400 From: "George, Wes" To: "sidr@ietf.org" , "sidr-chairs@ietf.org" , "draft-ietf-sidr-bgpsec-reqs@tools.ietf.org" Date: Mon, 31 Oct 2011 13:23:52 -0400 Thread-Topic: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs Thread-Index: AcyVoR1weVrJnk0OTFGbsct8GAZWNACR0dKA 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 31 Oct 2011 17:23:55 -0000 > From: Christopher Morrow > > Seems that the authors, at least, expect this doc to be prepared for > WGLC > -Chris > [WEG]] So should we expect you to have "SIDR" or "WGCHAIR" shaved into your= hair when we see you in Taipei? ;-) More seriously, some comments... Editorial nit: This document uses RFC2119 language inconsistently (at least= as far as capitalization is concerned) I think that we need some clearer documentation about prepends and support = for them. Specifically, right now the way that 3.2 is worded, it almost sou= nds like the aim is to detect and prevent *all* prepends, rather than ackno= wledging that this is a common TE practice that will need to be supported b= y BGPSec implementations. It may be that I'm simply misinterpreting the lan= guage in 3.2 and that was the intent to start with, but it may be useful to= clarify legitimate prepends (prepending ones own ASN) vs those generally v= iewed as unacceptable (prepending someone else's ASN). And while we're on the subject of prepends, I also would like to see this d= ocument explicitly require a few of the more obvious optimizations... somet= hing like, "a BGPSEC design SHOULD NOT require [signature] data to be linea= rly duplicated when an AS-path contains multiple valid instances of the sam= e ASN." Regarding 3.5 - I think that this is inadequate as currently written. First= , this is a static document, especially once it becomes an RFC, therefore o= ver the life of the document, the concept of "current hardware abilities" c= hanges pretty drastically. Adding a modifier akin to "at the time of this d= ocument's writing" would clarify. I would also avoid the editorializing "..= .should not be a major problem" within the requirement, and leave that to t= he discussion within the solution drafts of how they meet this requirement. However, even when this requirement is combined with 4.5 it represents a re= ally low bar when it comes to performance requirements. I'd be far more comfortable if this document set a design target as to what= percentage of increase in convergence times or update processing times is = viewed as generally adequate. i.e. "A BGPSec design MUST provide sufficient= optimization (through a combination of hardware capabilities and algorithm= ) such that BGP convergence (or possibly update processing?) times are with= in NN% of those in a similar system without the BGPSec design in place." It= might also make sense for similar targets to be set for things like memory= utilization for table storage, update frequency (due to the possibility of= beaconing), etc. I realize that some of these things are going to be imple= mentation specific, but providing those requirements to implementers up-fro= nt would ensure that the thing which they implement will actually be usable= and will help them to characterize what the hardware requirements actually= should be. It has to be a design consideration, because we don't want impl= ementers to work on their implementation only to have it be rejected becaus= e it represents too much of a performance tax. I think that fundamentally, this is one of the larger tradeoffs that we nee= d to be acknowledging, in terms of what you give up in order to gain better= route security. If it doesn't work with acceptable performance, the bar (c= ost) for deployment is much higher, and this design becomes an example of t= he old joke about how the only secure server is the one that's not connecte= d to the network. I'm not suggesting "something for nothing" as much as I a= m suggesting that we be very clear about the interconnection between perfor= mance expectations, hardware requirements, and the security benefits repres= ented by this enhancement. It may also be a good idea to explicitly note "performance impacts" as a pa= rt of 3.4. Section 4 (somewhere), 3.13 - Is it a requirement that all boxes participat= ing in the BGPSec design support 4-byte ASNs natively, or is this expected = to "validate" instances of AS23456 in the ASpath to maintain backward compa= tibility with non 4-byte ASN speakers? What about any considerations around the choice of using ASPlain vs ASDOT n= otation? I think it's probably sufficient to simply require that any soluti= on supports both forms without a change being required in the update data (= i.e. in the current design, there shouldn't be a different signature requir= ed for a 4-byte ASN represented in ASPLAIN notation vs ASDOT). 4.7 - what about invalid? I view unverified as unknown, which is different.= Is this supposed to align with the states defined in origin validation? Thanks, Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From wesley.george@twcable.com Mon Oct 31 10:44:44 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC82D1F0C8C for ; Mon, 31 Oct 2011 10:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.705 X-Spam-Level: X-Spam-Status: No, score=-0.705 tagged_above=-999 required=5 tests=[AWL=0.758, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SN0OL+Of2Xi3 for ; Mon, 31 Oct 2011 10:44:44 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 36F8C1F0C67 for ; Mon, 31 Oct 2011 10:44:44 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,432,1315195200"; d="scan'208";a="291651275" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 31 Oct 2011 13:40:40 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Mon, 31 Oct 2011 13:44:41 -0400 From: "George, Wes" To: "sidr@ietf.org" Date: Mon, 31 Oct 2011 13:44:40 -0400 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-01.txt Thread-Index: AcyOsOPUGs3OYPpdTl+wZ42afk8AigJQgpRw Message-ID: References: <20111019224523.16220.18338.idtracker@ietfa.amsl.com> In-Reply-To: <20111019224523.16220.18338.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-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, 31 Oct 2011 17:44:45 -0000 Intro: I'm wondering whether instead of specifically saying "may require la= rge memory and crypto assist" it would make more sense to discuss this more= in terms of the hardware catching up with the software to ensure minimal p= erformance impacts. Especially given that current crypto hardware isn't rea= lly designed to accelerate the types of operations BGPSec would require of = it, I'm not sure it makes sense to be that specific right now. Section 3 reuses a good bit of text from sidr-origin-ops regarding placemen= t of caches (local vs remote, "close", etc). Same comments apply here. More= to the point, perhaps simply referencing the other document and leaving th= is one to document things that are specific to BGPSec would be cleaner. Bgpsec-reqs 3.4 provides a list of operational considerations to discuss. W= ould probably make sense to ensure that the document covers all of the list= ed items, perhaps even using those items as section headings for continuity= 's sake. As I recommended in my comments on design-reqs, I think that a performance = impacts section would be helpful in any discussion of operational considera= tions. This is especially important for BGPSec since much more of the proce= ssing has to happen on-box vs being farmed out to external commodity server= hardware. Thanks Wes George > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Wednesday, October 19, 2011 6:45 PM > To: i-d-announce@ietf.org > Cc: sidr@ietf.org > Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-01.txt > > 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 Operational Considerations > Author(s) : Randy Bush > Filename : draft-ietf-sidr-bgpsec-ops-01.txt > Pages : 10 > Date : 2011-10-19 > > Deployment of the BGPsec architecture and protocols has many > operational considerations. This document attempts to collect and > present them. It is expected to evolve as BGPsec is formalized and > initially deployed. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-ops-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-ops-01.txt > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From internet-drafts@ietf.org Mon Oct 31 11:02:36 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B0C1F0CAF; Mon, 31 Oct 2011 11:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVcIaCugVuS1; Mon, 31 Oct 2011 11:02:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481891F0CA0; Mon, 31 Oct 2011 11:02:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031180236.14850.43978.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 11:02:36 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-overview-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, 31 Oct 2011 18:02:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : An Overview of BGPSEC Author(s) : Matt Lepinski Sean Turner Filename : draft-ietf-sidr-bgpsec-overview-01.txt Pages : 10 Date : 2011-10-31 This document provides an overview of a security extension to the Border Gateway Protocol (BGP) referred to as BGPSEC. BGPSEC improves security for BGP routing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-overview-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-overview-01.txt From internet-drafts@ietf.org Mon Oct 31 11:20:59 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004B711E80E4; Mon, 31 Oct 2011 11:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m935mx5tUYnP; Mon, 31 Oct 2011 11:20:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9425021F8DCF; Mon, 31 Oct 2011 11:20:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031182058.24592.70473.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 11:20:58 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 18:20:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : BGP Prefix Origin Validation Author(s) : Pradosh Mohapatra John Scudder David Ward Randy Bush Rob Austein Filename : draft-ietf-sidr-pfx-validate-03.txt Pages : 13 Date : 2011-10-31 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-pfx-validate-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-pfx-validate-03.txt From internet-drafts@ietf.org Mon Oct 31 12:38:04 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDDC011E8187; Mon, 31 Oct 2011 12:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yQj5MISbLEa; Mon, 31 Oct 2011 12:38:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3F811E8175; Mon, 31 Oct 2011 12:38: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: 3.62 Message-ID: <20111031193803.30761.81234.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 12:38:03 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-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, 31 Oct 2011 19:38: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 G= roup of the IETF. Title : BGPSEC Protocol Specification Author(s) : Matthew Lepinski Filename : draft-ietf-sidr-bgpsec-protocol-01.txt Pages : 28 Date : 2011-10-31 This document describes BGPSEC, an extension to the Border Gateway Protocol (BGP) that provides security for the AS-PATH attribute in BGP update messages. BGPSEC is implemented via a new optional non- transitive BGP path attribute that carries a digital signature produced by each autonomous system on the AS-PATH. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-protocol-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-protocol-01.txt From randy@psg.com Mon Oct 31 14:58:53 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEA711E82F7 for ; Mon, 31 Oct 2011 14:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbquqSwVuzte for ; Mon, 31 Oct 2011 14:58:52 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 941A611E82F5 for ; Mon, 31 Oct 2011 14:58:52 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RKzsS-0008MC-OC; Mon, 31 Oct 2011 21:58:45 +0000 Date: Mon, 31 Oct 2011 22:58:43 +0100 Message-ID: From: Randy Bush To: "George, Wes" In-Reply-To: References: <20111019224523.16220.18338.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-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, 31 Oct 2011 21:58:53 -0000 > given that current crypto hardware isn't really designed to accelerate > the types of operations BGPSec would require of it the extended instructions in westmere and sandy bridge are good for ecdsa > Section 3 reuses a good bit of text from sidr-origin-ops regarding > placement of caches (local vs remote, "close", etc). Same comments > apply here. More to the point, perhaps simply referencing the other > document and leaving this one to document things that are specific to > BGPSec would be cleaner. good point > Bgpsec-reqs 3.4 provides a list of operational considerations to > discuss. Would probably make sense to ensure that the document covers > all of the listed items, perhaps even using those items as section > headings for continuity's sake. probably more appropriate in the protocol document, or an adjunct to it randy From internet-drafts@ietf.org Mon Oct 31 16:20:22 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A3D1F0D5C; Mon, 31 Oct 2011 16:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUNgYyJiB3XD; Mon, 31 Oct 2011 16:20:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4759921F8E38; Mon, 31 Oct 2011 16:20:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031232022.26304.78773.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 16:20:22 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 23:20:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : Use Cases and Interpretation of RPKI Objects for Issuers= and Relying Parties Author(s) : Terry Manderson Kotikalapudi Sriram Russ White Filename : draft-ietf-sidr-usecases-03.txt Pages : 30 Date : 2011-10-31 This document provides use cases, directions, and interpretations for organizations and relying parties when creating or encountering RPKI object scenarios in the public RPKI. All of the above are discussed here in relation to the Internet routing system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-usecases-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-usecases-03.txt From kotikalapudi.sriram@nist.gov Mon Oct 31 16:57:32 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D2711E840D for ; Mon, 31 Oct 2011 16:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xs5QS5o+TGye for ; Mon, 31 Oct 2011 16:57:29 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 3E40A11E83E8 for ; Mon, 31 Oct 2011 16:57:28 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 31 Oct 2011 19:57:22 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 31 Oct 2011 19:56:53 -0400 From: "Sriram, Kotikalapudi" To: Warren Kumari , Randy Bush Date: Mon, 31 Oct 2011 19:56:53 -0400 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt Thread-Index: AcyYI5pCXkp8NHxHTdyAcyM8B3VyXgAAV1ie Message-ID: References: <20111031232022.26304.78773.idtracker@ietfa.amsl.com> In-Reply-To: <20111031232022.26304.78773.idtracker@ietfa.amsl.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@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 23:57:32 -0000 In this revised version, we (authors) have made changes with careful consideration of all the comments (mostly of editorial nature) received from Warren and Randy. http://www.ietf.org/mail-archive/web/sidr/current/msg03349.html http://www.ietf.org/mail-archive/web/sidr/current/msg03306.html http://www.ietf.org/mail-archive/web/sidr/current/msg03305.html http://www.ietf.org/mail-archive/web/sidr/current/msg03304.html We have also made many other edits throughout the doc to improve clarity and readability. Sriram ________________________________________ Title : Use Cases and Interpretation of RPKI Objects for Issuers and Relying Parties Author(s) : Terry Manderson Kotikalapudi Sriram Russ White Filename : draft-ietf-sidr-usecases-03.txt Pages : 30 Date : 2011-10-31 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-usecases-03.txt