From touch@isi.edu Wed Jun 1 09:08:00 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8D8E07EC for ; Wed, 1 Jun 2011 09:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.083 X-Spam-Level: X-Spam-Status: No, score=-103.083 tagged_above=-999 required=5 tests=[AWL=-0.484, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZJVW1pliPHM for ; Wed, 1 Jun 2011 09:07:58 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by ietfa.amsl.com (Postfix) with ESMTP id F0A29E0820 for ; Wed, 1 Jun 2011 09:07:57 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p51G7UR9016486 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 1 Jun 2011 09:07:30 -0700 (PDT) Message-ID: <4DE663C2.4050304@isi.edu> Date: Wed, 01 Jun 2011 09:07:30 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Hannes Gredler References: <8A7BEFB8FCD25A43BB73B1D879B82F770457B0AF@xmb-sjc-239.amer.cisco.com> <4167B366-02DE-4637-9CA1-175E3A1BB321@vpnc.org> <4DE52BE4.3040900@isi.edu> <20110531181909.GB18034@juniper.net> <4DE532BD.5030805@isi.edu> <20110601065753.GC18752@juniper.net> In-Reply-To: <20110601065753.GC18752@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p51G7UR9016486 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Paul Hoffman , sidr@ietf.org Subject: Re: [sidr] rpki-rtr protocol maximum message length X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 16:08:00 -0000 Hi, all, On 5/31/2011 11:57 PM, Hannes Gredler wrote: > On Tue, May 31, 2011 at 11:26:05AM -0700, Joe Touch wrote: > | > | > | On 5/31/2011 11:19 AM, Hannes Gredler wrote: > |>On Tue, May 31, 2011 at 10:56:52AM -0700, Joe Touch wrote: > |>| > |>| > |>| On 5/31/2011 10:52 AM, Paul Hoffman wrote: > |>|>On May 31, 2011, at 10:23 AM, Randy Bush wrote: > |>|> > |>|>>>1. Maybe add to section 5.9 "An Error Report PDU MUST NOT be sent for > |>|>>>an Error Report PDU.". > |>|>> > |>|>>makes sense > |>|>> > |>|>>>To answer the initial request, it seems reasonable to specify "the > |>|>>>length of the Arbitrary Text of Error Diagnostic Message MUST NOT be > |>|>>>longer than 200 octets". That keeps the length of the entire PDU under > |>|>>>the semi-magic 256 octets for the current version of the protocol > |>|>> > |>|>>in what way is 256 octets semi-magic? > |>|> > |>|>C or assembly-based implementations will need to malloc (etc.) the > |>|>buffer for the incoming message. Having that fit into 256 octets could > |>|>easily have some value to some implementations. There is no security > |>|>problem if the cache ignores such a MUST and makes the message longer > |>|>because the length is given the PDU. (Having said that, I hope router > |>|>implementers of this protocol are being robust in checking the lengths > |>|>in this PDU; I can already see ways to craft malicious versions of this > |>|>PDU that might trigger a buffer overflow...) > |>| > |>| These are good reasons for robust implementations to check for the > |>| message length and read only as much as the currently allocated > |>| buffer allows, reading more in as needed. > |> > |>wonder what the normative procedure is for "too-large" messages ? > |> > |>my pre-standard implementation has an inbound buffer of 4K > |>and resets the session if it encounters a PDU length of> 4K. > | > | That makes an easy DOS attack. > > i fail to see why max-PDU size spelled out in a protocol-spec is > a pre-cursor to a DOS attack. as long as the message integrity of > your TCP session is preserved (e.g. MD5, AO) its perfectly letigimate > to flap a session if i do not like what i see. The potential for a DOS attack comes from apps thinking 'max-PDU' is enforced somewhere other than at the app. They write apps reading the entire socket into a (fixed-size) buffer, and that's how we get buffer overflow attacks. If every app designer (and kernel protocol designer too) limited reads to the size of the incoming buffer, there would never be such an attack, yet they persist. My concern with claiming a "max PDU" is that it encourages such complacency. Finally, there's a misplaced notion that PDUs correspond to packets on the wire. In TCP, socket write boundaries don't correspond to segment boundaries anyway, so there's no real point in claiming such a limit as a "PDU" issue. > | It's better to: > | > | - allocate a 4K (or whatever value you want) buffer > | - read up to the first 4K > | - check to see if there's more to read, and allocate more buffer > | space or read it into the first buffer (after the first 4K has been > | parsed) > > i am not so sure about wether the above is really "better", since > there is a price to pay. in the above you are assuming that each > input parser is a true "stream parser" such that the entire parsing > context is saved when e.g. a PDU is scattered across two buffers. > > e.g. consider an IPV4 Prefix where the first part is in buffer #1 and the > reminder is in buffer #2. When you read from a TCP socket, you need to be prepared to deal with such boundaries anyway. As I note above, TCP doesn't preserve boundaries. If you're parsing a bytestream (TCP) for an application protocol, yes, you need a parser anyway. > lets further assume that between reading buffer 1 and buffer 2 there is > a time lag (e.g. the socket just got flow blocked). now you need to save your > previous parsing results up until the socket becomes readable again. Yes. That's true anyway if you do nonblocking reads. > with max-PDU sized recv buffers the whole story gets a whole lot simpler, > as you can avoid the context saving for each and every input parser: > > you just need to ask. > > 1. do i have enough data in the buffer for reading the PDU header ? > 2. if so does the message exceed the recv buffer ? > 3. do i have enough data in the buffer for parsing an entire PDU ? And what happens when you read more than the application PTU? You can't exactly put it back on the socket to read later. There's no way around this - even if the message says "I'm 240 bytes", you can't know that the 240 bytes are there; the source could have errd. You still need to grab data from the socket into an intermediate space - which will be a few PDUs in length - and parse that, so you can get around such boundary issues and grab data off the socket without needing to put it back. > | Either way, there's no reason for a *protocol action* to deal with a > | receiver buffering issue. > > i find less code-complexity in input parsers a quite compelling argument. If you think you're getting around this complexity issue, you have a parser that has a security hole. Joe From paul.hoffman@vpnc.org Wed Jun 1 09:18:03 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A97E07A9 for ; Wed, 1 Jun 2011 09:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vf2L27nm1QN2 for ; Wed, 1 Jun 2011 09:18:03 -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 D3C41E0709 for ; Wed, 1 Jun 2011 09:17:57 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p51GHt1D042874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 1 Jun 2011 09:17:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Jun 2011 09:17:54 -0700 Message-Id: <8FAA0F26-2256-4D96-BFAC-4FCB6397361B@vpnc.org> To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [sidr] rpki-rtr: caches announcing new serial numbers X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 16:18:03 -0000 Greetings again. Reading through the -12 draft and the mailing list = archives, I cannot figure out what a cache is supposed to do when it has = new data and thus a new serial number. Does it have to send a Serial = Notify PDU? I'm pretty sure that the draft says all of "yes", "no", and = "maybe" in different places. There should be one clear answer. My personal choice would be "no" because the client router is already = polling with Serial Query whenever it feels like it. In fact, it looks = like Serial Notify can be completely eliminated and greatly simplify the = implementation of the protocol, because then the protocol would be truly = client-server with the client always initiating contact inside the = transport. Yes, I know that it is late to redesign the protocol, but = such a change is easy to make and would clarify the cache server's role = significantly. The "do you have anything since serial number X" / "Nope" = dance is very small, so I strongly suspect that even if a router client = polls every minute, that traffic will be insignificant. I question the need for "yes", given that a router is required to be = polling anyway. I don't think that "maybe" makes sense at all, but could = be convinced otherwise. --Paul Hoffman From randy@psg.com Wed Jun 1 09:25: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 49446E08A1 for ; Wed, 1 Jun 2011 09:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvAn3v9W6SRr for ; Wed, 1 Jun 2011 09:25:25 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id BF6E6E08A0 for ; Wed, 1 Jun 2011 09:25:25 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QRoDJ-000HLO-JN; Wed, 01 Jun 2011 16:24:10 +0000 Date: Wed, 01 Jun 2011 19:23:57 +0300 Message-ID: From: Randy Bush To: Paul Hoffman In-Reply-To: <8FAA0F26-2256-4D96-BFAC-4FCB6397361B@vpnc.org> References: <8FAA0F26-2256-4D96-BFAC-4FCB6397361B@vpnc.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] rpki-rtr: caches announcing new serial numbers X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 16:25:26 -0000 > Greetings again. Reading through the -12 draft and the mailing list > archives, I cannot figure out what a cache is supposed to do when it > has new data and thus a new serial number. Does it have to send a > Serial Notify PDU? I'm pretty sure that the draft says all of "yes", > "no", and "maybe" in different places. There should be one clear > answer. should be a MAY or a SHOULD. read up on dns notify. please point out where it is ambiguous and i will fix. randy From paul.hoffman@vpnc.org Wed Jun 1 09:55:02 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AC6E07F2 for ; Wed, 1 Jun 2011 09:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id id8EBQnb-A+B for ; Wed, 1 Jun 2011 09:55:02 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D4412E07C7 for ; Wed, 1 Jun 2011 09:55:01 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p51Gsx2H044171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Jun 2011 09:54:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Wed, 1 Jun 2011 09:54:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <49D9AB57-3223-467B-88F7-C373F91292D5@vpnc.org> References: <8FAA0F26-2256-4D96-BFAC-4FCB6397361B@vpnc.org> To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: Re: [sidr] rpki-rtr: caches announcing new serial numbers X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 16:55:03 -0000 On Jun 1, 2011, at 9:23 AM, Randy Bush wrote: >> Greetings again. Reading through the -12 draft and the mailing list >> archives, I cannot figure out what a cache is supposed to do when it >> has new data and thus a new serial number. Does it have to send a >> Serial Notify PDU? I'm pretty sure that the draft says all of "yes", >> "no", and "maybe" in different places. There should be one clear >> answer. >=20 > should be a MAY or a SHOULD. =20 There is a big difference. The WG should pick one (or none, if they like = my idea of getting rid of "sometimes the server speaks without being = spoken to"). What do you see as the purpose of "MAY" or "SHOULD", given that the = client router is already polling as often as it likes (with a minimum of = once an hour)? > read up on dns notify. Did that a very long time ago and a few times since then. Googling for = it now shows how unclear it is to developers and users. :-( > please point out where it is ambiguous and i will fix. Section 4: When the cache updates its database, it sends a Notify message to every currently connected router. Section 5.1: The cache notifies the router that the cache has new data. Section 6.2: | -------- Notify ----------> | (optional) . . . The cache server SHOULD send a notify PDU with its current serial number when the cache's serial changes, with the expectation that the router MAY then issue a serial query earlier than it otherwise might. This is analogous to DNS NOTIFY in [RFC1996]. The cache SHOULD rate limit Serial Notifies to no more frequently than one per minute. The first two indicates "MUST", the third indicates "MAY", the fourth = indicates "SHOULD", but then modifies that with SHOULD-level rate = limiting. --Paul Hoffman From kent@bbn.com Wed Jun 1 10:54:03 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002A5E0959; Wed, 1 Jun 2011 10:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.448 X-Spam-Level: X-Spam-Status: No, score=-105.448 tagged_above=-999 required=5 tests=[AWL=-1.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XE0WnEVe9MCW; Wed, 1 Jun 2011 10:54:02 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 58878E0957; Wed, 1 Jun 2011 10:54:01 -0700 (PDT) Received: from dhcp89-089-178.bbn.com ([128.89.89.178]:49366 helo=[192.168.1.12]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QRpcB-000At2-EA; Wed, 01 Jun 2011 13:53:55 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4DD381B6.8060100@bwijnen.net> References: <000701cc0ec1$e552d630$aff88290$@com> <4DD381B6.8060100@bwijnen.net> Date: Wed, 1 Jun 2011 13:53:49 -0400 To: "Bert (IETF) Wijnen" , stbryant@cisco.com, elwynd@dial.pipex.com From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-905171661==_ma============" Cc: ops-dir@ietf.org, Ron Bonica , "Romascanu, Dan \(Dan\)" , sidr@ietf.org, ggm@apnic.net Subject: Re: [sidr] Operations Directorate Review of draft-ietf-sidr-keyroll-06 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 17:54:03 -0000 --============_-905171661==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Elwyn, >Nits/editorial comments: >s4, s4.1 and s4.2: >The term 're-issue' is used in this section regarding the new >certificates that the CA creates, e.g. in s4.1: >>When a CA, as part of the key rollover process, re-issues a CA >> certificate, >The term 're-issues' might be slightly confusing. Its a new certificate >but with lots of fields the same. I would be inclined to go with >'issues new' but its a quibble. There is not uniform terminology for describing this sort of process in the PKI world, but the term "reissue" (or re-issue) is reasonable. (It is distinct from cert "renewal," which implies a new cert with the same key and all attributes remaining constant except for the validity interval and serial number. Cert "re-key" refers to issuing a new cert with a new key, new serial number, maybe a new validity interval, but the same Subject name and other attributes remaining constant.) Also, we use the same terminology in several other SIDR docs, e.g., draft-ietf-sidr-repos-struct-07.txt, draft-ietf-sidr-ta-07, draft-ietf-sidr-res-certs-18, and in an analogous context in draft-ietf-sidr-rpki-manifests-11.txt. Steve --------------------- Bert, Responses to your comments below: >... > >RFC5706 suggests but does not require a separate >"operational considerations section". > >The draft-ietf-sidr-keyroll-06 discusses the operational considerations >in the "Security Considerations" section. I can live with that and leave it >to the OPS ADs if they rather see that split out in a separate section >or not. Thanks. > >Substantive comments/questions: > >- last para on page 4 > > During the transition of the "current" and "new" CA instances it is > necessary for the "new" CA instance to re-issue all subordinate > products of the "current" CA. The procedure described here requires > > I wonder if the "requires" should be a "REQUIRES" (yep, I know that > rfc2119 does not have that exact capitalized form of require, but I > think that a MUST or REQUIRED is intended here, no?)? How about: During the transition of the "current" and "new" CA instances the "new" CA instance MUST re-issue all subordinate products of the "current" CA. >- page 6 > 4. The NEW CA enters a Staging Period. This duration of the > Staging Period is determined by the CA, but it SHOULD be no > less than 24 hours. > Does/would it make sense to also suggest/recommend a max period? > Would 48 hours make sense? A recommended max period is probably a good idea, since relying parties are burdened by having to deal with two sets of signed objects. If my co-author does not object, I would revise the text as follows: 4. The NEW CA enters a Staging Period. This duration of the Staging Period is determined by the CA, but it SHOULD be no less than 24 hours. (It is RECOMMENDED that the staging period be no longer than 48 hours.) ... > >- given the first para in sect 1, I wonder if ID.ietf-sidr-arch should be > a normative instead of a informative reference. OK, that's an easy change. >Editorial/nits: > >- sect 1. 1st sentence > This document describes an algorithm to by employed by a > > s/by/be/ (the first occurrence of "by") OK. >- page 4, at top: > CURRENT: > The CURRENT CA is the active CA instance used to accept and > process certificate issuance and revocation requests The starting > > s/requests/requests./ OK. >- page 5 > expand acronym CPS on its first use in this document. used in the CURRENT CA certificate. The Certificate Practice Statement (CPS) for the issuer of the NEW CA certificate will indicate the time frame within which a certificate request is expected to be processed. >- same for AIA acronym on page 6. - Generate a new key pair, and generate an associated EE certificate request with an Authority Information Access (AIA) value of the NEW CA's repository publication point. >- page 6: > 4. The NEW CA enters a Staging Period. This duration of the > > s/This duration of the/The duration of this/ OK >- page 8 > expand acronym CMS on its first use in this document. (If the signing time or binary signing time values in the Cryptograpic Message Syntax (CMS) wrapper are non-null, they MAY be updated to reflect the current time.) Steve --============_-905171661==_ma============ Content-Type: text/html; charset="us-ascii" Re: Operations Directorate Review of draft-ietf-sidr-keyro
Elwyn,


Nits/editorial comments:
s4, s4.1 and s4.2:
The  term 're-issue' is used in this section regarding the new
certificates that the CA creates, e.g. in s4.1:
When a CA, as part of the key rollover process, re-issues a CA
   certificate,
The term 're-issues' might be slightly confusing. Its a new certificate
but with lots of fields the same.  I would be inclined to go with
'issues new' but its a quibble.

There is not uniform terminology for describing this sort of process in the PKI world, but the term "reissue" (or re-issue) is reasonable.  (It is distinct from cert "renewal," which implies a new cert with the same key and all attributes remaining constant except for the validity interval and serial number. Cert "re-key" refers to issuing a new cert with a new key, new serial number, maybe a new validity interval, but the same Subject name and other attributes remaining constant.)  Also, we use the same terminology in several other SIDR docs, e.g., draft-ietf-sidr-repos-struct-07.txt, draft-ietf-sidr-ta-07,  draft-ietf-sidr-res-certs-18, and in an analogous context in draft-ietf-sidr-rpki-manifests-11.txt.

Steve

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

Bert,

Responses to your comments below:

...

RFC5706 suggests but does not require a separate
"operational considerations section".

The draft-ietf-sidr-keyroll-06 discusses the operational considerations
in the "Security Considerations" section. I can live with that and leave it
to the OPS ADs if they rather see that split out in a separate section
or not.

Thanks.


Substantive comments/questions:

- last para on page 4

   During the transition of the "current" and "new" CA instances it is
   necessary for the "new" CA instance to re-issue all subordinate
   products of the "current" CA.  The procedure described here requires

   I wonder if the "requires" should be a "REQUIRES" (yep, I know that
   rfc2119 does not have that exact capitalized form of require, but I
   think that a MUST or REQUIRED is intended here, no?)?

How about:

    During the transition of the "current" and "new" CA instances the "new"
    CA instance MUST re-issue all subordinate products of the "current" CA. 


- page 6
      4.  The NEW CA enters a Staging Period.  This duration of the
          Staging Period is determined by the CA, but it SHOULD be no
          less than 24 hours.
   Does/would it make sense to also suggest/recommend a max period?
   Would 48 hours make sense?

A recommended max period is probably a good idea, since relying parties are
burdened by having to deal with two sets of signed objects. If my co-author does not object, I would revise the text as follows:

4.        The NEW CA enters a Staging Period.  This duration of the
          Staging Period is determined by the CA, but it SHOULD be no
          less than 24 hours.  (It is RECOMMENDED that the staging period
          be no longer than 48 hours.) ...



- given the first para in sect 1, I wonder if ID.ietf-sidr-arch should be
   a normative instead of a informative reference.

OK, that's an easy change.

Editorial/nits:

- sect 1. 1st sentence
   This document describes an algorithm to by employed by a

   s/by/be/  (the first occurrence of "by")

OK.
- page 4, at top:
  CURRENT:
      The CURRENT CA is the active CA instance used to accept and
      process certificate issuance and revocation requests The starting

  s/requests/requests./

OK.
- page 5
   expand acronym CPS on its first use in this document.

     used in the CURRENT CA certificate.  The Certificate Practice
     Statement  (CPS) for the issuer of the NEW CA certificate will
     indicate the time frame within which a certificate request is
     expected to be processed.



- same for AIA acronym on page 6.

      -  Generate a new key pair, and generate an associated EE
         certificate request with an Authority Information Access (AIA)
         value of the NEW CA's repository publication point. 


- page 6:
  4.  The NEW CA enters a Staging Period.  This duration of the

  s/This duration of the/The duration of this/

OK
- page 8
   expand acronym CMS on its first use in this document.

     (If the signing time or binary signing time values in the Cryptograpic
     Message Syntax (CMS) wrapper are non-null, they MAY be updated to
     reflect the current time.)


Steve
--============_-905171661==_ma============-- From randy@psg.com Wed Jun 1 11:26: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 0E89B13003F for ; Wed, 1 Jun 2011 11:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0W8rqLv-fBZF for ; Wed, 1 Jun 2011 11:26:32 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 75C7E13002A for ; Wed, 1 Jun 2011 11:26:32 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QRq7j-000Hc8-E9; Wed, 01 Jun 2011 18:26:31 +0000 Date: Wed, 01 Jun 2011 21:26:28 +0300 Message-ID: From: Randy Bush To: Paul Hoffman In-Reply-To: <49D9AB57-3223-467B-88F7-C373F91292D5@vpnc.org> References: <8FAA0F26-2256-4D96-BFAC-4FCB6397361B@vpnc.org> <49D9AB57-3223-467B-88F7-C373F91292D5@vpnc.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] rpki-rtr: caches announcing new serial numbers X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 18:26:33 -0000 >> read up on dns notify. > Did that a very long time ago and a few times since then. Googling for > it now shows how unclear it is to developers and users. :-( it is why your dns updates propagate in a minute or two, not hours or days. randy From hannes@juniper.net Wed Jun 1 11:45: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 C5F1FE08C8 for ; Wed, 1 Jun 2011 11:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ee8NKBx1iRKN for ; Wed, 1 Jun 2011 11:45:22 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id A0965E06C0 for ; Wed, 1 Jun 2011 11:45:21 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTeaItMCgaUcjTegcbWcTgZANYpBPXK5h@postini.com; Wed, 01 Jun 2011 11:45:21 PDT Received: from hannes-755.juniper.net (172.30.152.52) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.2.254.0; Wed, 1 Jun 2011 11:44:31 -0700 Received: by hannes-755.juniper.net (Postfix, from userid 1000) id 3F29D22413; Wed, 1 Jun 2011 20:44:11 +0200 (CEST) Date: Wed, 1 Jun 2011 20:44:11 +0200 From: Hannes Gredler To: Joe Touch Message-ID: <20110601184409.GA21723@juniper.net> References: <8A7BEFB8FCD25A43BB73B1D879B82F770457B0AF@xmb-sjc-239.amer.cisco.com> <4167B366-02DE-4637-9CA1-175E3A1BB321@vpnc.org> <4DE52BE4.3040900@isi.edu> <20110531181909.GB18034@juniper.net> <4DE532BD.5030805@isi.edu> <20110601065753.GC18752@juniper.net> <4DE663C2.4050304@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <4DE663C2.4050304@isi.edu> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Paul Hoffman , sidr@ietf.org Subject: Re: [sidr] rpki-rtr protocol maximum message length X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 18:45:22 -0000 On Wed, Jun 01, 2011 at 09:07:30AM -0700, Joe Touch wrote: | Hi, all, | | On 5/31/2011 11:57 PM, Hannes Gredler wrote: | >On Tue, May 31, 2011 at 11:26:05AM -0700, Joe Touch wrote: | >| | >| | >| On 5/31/2011 11:19 AM, Hannes Gredler wrote: | >|>On Tue, May 31, 2011 at 10:56:52AM -0700, Joe Touch wrote: | >|>| | >|>| | >|>| On 5/31/2011 10:52 AM, Paul Hoffman wrote: | >|>|>On May 31, 2011, at 10:23 AM, Randy Bush wrote: | >|>|> | >|>|>>>1. Maybe add to section 5.9 "An Error Report PDU MUST NOT be sent for | >|>|>>>an Error Report PDU.". | >|>|>> | >|>|>>makes sense | >|>|>> | >|>|>>>To answer the initial request, it seems reasonable to specify "the | >|>|>>>length of the Arbitrary Text of Error Diagnostic Message MUST NOT be | >|>|>>>longer than 200 octets". That keeps the length of the entire PDU under | >|>|>>>the semi-magic 256 octets for the current version of the protocol | >|>|>> | >|>|>>in what way is 256 octets semi-magic? | >|>|> | >|>|>C or assembly-based implementations will need to malloc (etc.) the | >|>|>buffer for the incoming message. Having that fit into 256 octets could | >|>|>easily have some value to some implementations. There is no security | >|>|>problem if the cache ignores such a MUST and makes the message longer | >|>|>because the length is given the PDU. (Having said that, I hope router | >|>|>implementers of this protocol are being robust in checking the lengths | >|>|>in this PDU; I can already see ways to craft malicious versions of this | >|>|>PDU that might trigger a buffer overflow...) | >|>| | >|>| These are good reasons for robust implementations to check for the | >|>| message length and read only as much as the currently allocated | >|>| buffer allows, reading more in as needed. | >|> | >|>wonder what the normative procedure is for "too-large" messages ? | >|> | >|>my pre-standard implementation has an inbound buffer of 4K | >|>and resets the session if it encounters a PDU length of> 4K. | >| | >| That makes an easy DOS attack. | > | >i fail to see why max-PDU size spelled out in a protocol-spec is | >a pre-cursor to a DOS attack. as long as the message integrity of | >your TCP session is preserved (e.g. MD5, AO) its perfectly letigimate | >to flap a session if i do not like what i see. | | The potential for a DOS attack comes from apps thinking 'max-PDU' is | enforced somewhere other than at the app. They write apps reading | the entire socket into a (fixed-size) buffer, and that's how we get | buffer overflow attacks. | | If every app designer (and kernel protocol designer too) limited | reads to the size of the incoming buffer, there would never be such | an attack, yet they persist. hence my point explicit spelling out what the maximum PDU size should be; the seasoned implementer will size its input buffer accordingly. | My concern with claiming a "max PDU" is that it encourages such complacency. | | Finally, there's a misplaced notion that PDUs correspond to packets | on the wire. In TCP, socket write boundaries don't correspond to | segment boundaries anyway, so there's no real point in claiming such | a limit as a "PDU" issue. | | >| It's better to: | >| | >| - allocate a 4K (or whatever value you want) buffer | >| - read up to the first 4K | >| - check to see if there's more to read, and allocate more buffer | >| space or read it into the first buffer (after the first 4K has been | >| parsed) | > | >i am not so sure about wether the above is really "better", since | >there is a price to pay. in the above you are assuming that each | >input parser is a true "stream parser" such that the entire parsing | >context is saved when e.g. a PDU is scattered across two buffers. | > | >e.g. consider an IPV4 Prefix where the first part is in buffer #1 and the | >reminder is in buffer #2. | | When you read from a TCP socket, you need to be prepared to deal | with such boundaries anyway. As I note above, TCP doesn't preserve | boundaries. the properties of stream based protocols is understood; | If you're parsing a bytestream (TCP) for an application protocol, | yes, you need a parser anyway. | | >lets further assume that between reading buffer 1 and buffer 2 there is | >a time lag (e.g. the socket just got flow blocked). now you need to save your | >previous parsing results up until the socket becomes readable again. | | Yes. That's true anyway if you do nonblocking reads. | | >with max-PDU sized recv buffers the whole story gets a whole lot simpler, | >as you can avoid the context saving for each and every input parser: | > | >you just need to ask. | > | >1. do i have enough data in the buffer for reading the PDU header ? | >2. if so does the message exceed the recv buffer ? | >3. do i have enough data in the buffer for parsing an entire PDU ? | | And what happens when you read more than the application PTU? You | can't exactly put it back on the socket to read later. one implementation choice could be to: parse your input buffer up until you reach the "incomplete" PDU which does not yet have enough payload. finally the incomplete part gets copied back to the beginning of the buffer; for the rpki protocol (with its small PDUs) that rebasing is a relatively cheap operation. | There's no way around this - even if the message says "I'm 240 | bytes", you can't know that the 240 bytes are there; usually my buffer struct is a the buffer itself and two pointers (start and end) for housekeeping purposes. therefore i know how full my buffer is (buffer pointer get updated after every read and parser call) | the source could have errd. You still need to grab data from the socket into an | intermediate space - which will be a few PDUs in length - and parse | that, so you can get around such boundary issues and grab data off | the socket without needing to put it back. exactly .. all i am asking for is a constant for storing 1 PDU such that i can appropriately size the "intermediate space" | >| Either way, there's no reason for a *protocol action* to deal with a | >| receiver buffering issue. | > | >i find less code-complexity in input parsers a quite compelling argument. | | If you think you're getting around this complexity issue, | you have a parser that has a security hole. i have running (security audited) I/O code which works like described above for more than a decade in the internet. IOW i have proof point that your assertion is not correct; From elwynd@dial.pipex.com Wed Jun 1 14:03: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 87407E0994; Wed, 1 Jun 2011 14:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.397 X-Spam-Level: X-Spam-Status: No, score=-97.397 tagged_above=-999 required=5 tests=[AWL=-3.230, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFpsOFysSWYj; Wed, 1 Jun 2011 14:03:08 -0700 (PDT) Received: from a.painless.aaisp.net.uk (c.5.0.d.2.7.e.f.f.f.8.4.0.3.2.0.0.3.0.0.0.0.0.0.0.b.8.0.1.0.0.2.ip6.arpa [IPv6:2001:8b0:0:30:230:48ff:fe72:d05c]) by ietfa.amsl.com (Postfix) with ESMTP id 6B569E0993; Wed, 1 Jun 2011 14:03:07 -0700 (PDT) Received: from 251.254.187.81.in-addr.arpa ([81.187.254.251]) by a.painless.aaisp.net.uk with esmtp (Exim 4.72) (envelope-from ) id 1QRsZ8-00060P-FX; Wed, 01 Jun 2011 22:02:58 +0100 Message-ID: <4DE6A8E4.7040906@dial.pipex.com> Date: Wed, 01 Jun 2011 22:02:28 +0100 From: Elwyn Davies User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: Stephen Kent References: <000701cc0ec1$e552d630$aff88290$@com> <4DD381B6.8060100@bwijnen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ops-dir@ietf.org, Ron Bonica , "Romascanu, Dan \(Dan\)" , sidr@ietf.org, "Bert \(IETF\) Wijnen" , ggm@apnic.net Subject: Re: [sidr] Operations Directorate Review of draft-ietf-sidr-keyroll-06 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: elwynd@dial.pipex.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 21:03:08 -0000 Hi. Stephen Kent wrote: > Elwyn, > > >> Nits/editorial comments: >> s4, s4.1 and s4.2: >> The term 're-issue' is used in this section regarding the new >> certificates that the CA creates, e.g. in s4.1: >>> When a CA, as part of the key rollover process, re-issues a CA >>> certificate, >> The term 're-issues' might be slightly confusing. Its a new certificate >> but with lots of fields the same. I would be inclined to go with >> 'issues new' but its a quibble. > > There is not uniform terminology for describing this sort of process > in the PKI world, but the term "reissue" (or re-issue) is reasonable. > (It is distinct from cert "renewal," which implies a new cert with the > same key and all attributes remaining constant except for the validity > interval and serial number. Cert "re-key" refers to issuing a new cert > with a new key, new serial number, maybe a new validity interval, but > the same Subject name and other attributes remaining constant.) Also, > we use the same terminology in several other SIDR docs, e.g., > draft-ietf-sidr-repos-struct-07.txt, draft-ietf-sidr-ta-07, > draft-ietf-sidr-res-certs-18, and in an analogous context in > draft-ietf-sidr-rpki-manifests-11.txt. > > Steve > OK. Stick with what you've used.. consistency is wise. Regards, Elwyn From touch@isi.edu Wed Jun 1 14:13: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 4AF7FE098E for ; Wed, 1 Jun 2011 14:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.908 X-Spam-Level: X-Spam-Status: No, score=-102.908 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBSYsOJLOjrj for ; Wed, 1 Jun 2011 14:13:43 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by ietfa.amsl.com (Postfix) with ESMTP id C0522E098C for ; Wed, 1 Jun 2011 14:13:13 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p51LCo0M019956 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 1 Jun 2011 14:12:50 -0700 (PDT) Message-ID: <4DE6AB52.5020802@isi.edu> Date: Wed, 01 Jun 2011 14:12:50 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Hannes Gredler References: <8A7BEFB8FCD25A43BB73B1D879B82F770457B0AF@xmb-sjc-239.amer.cisco.com> <4167B366-02DE-4637-9CA1-175E3A1BB321@vpnc.org> <4DE52BE4.3040900@isi.edu> <20110531181909.GB18034@juniper.net> <4DE532BD.5030805@isi.edu> <20110601065753.GC18752@juniper.net> <4DE663C2.4050304@isi.edu> <20110601184409.GA21723@juniper.net> In-Reply-To: <20110601184409.GA21723@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p51LCo0M019956 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Paul Hoffman , sidr@ietf.org Subject: Re: [sidr] rpki-rtr protocol maximum message length X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 21:13:44 -0000 Hi, Hannes, On 6/1/2011 11:44 AM, Hannes Gredler wrote: ... > one implementation choice could be to: > parse your input buffer up until you reach the "incomplete" PDU > which does not yet have enough payload. finally the incomplete part > gets copied back to the beginning of the buffer; > for the rpki protocol (with its small PDUs) that rebasing is a relatively > cheap operation. > > | There's no way around this - even if the message says "I'm 240 > | bytes", you can't know that the 240 bytes are there; > > usually my buffer struct is a the buffer itself and two pointers > (start and end) for housekeeping purposes. therefore i know how > full my buffer is (buffer pointer get updated after every read > and parser call) (see below) > | the source could have errd. You still need to grab data from the socket into an > | intermediate space - which will be a few PDUs in length - and parse > | that, so you can get around such boundary issues and grab data off > | the socket without needing to put it back. > > exactly .. all i am asking for is a constant for storing 1 PDU such that > i can appropriately size the "intermediate space" OK, so we're talking about the same thing. I was objecting to the concept of "PDU" - what we're talking about is the maximum length of a self-contained parseable message. (PDUs tend to mean "packet" at L1-L4). > > |>| Either way, there's no reason for a *protocol action* to deal with a > |>| receiver buffering issue. > |> > |>i find less code-complexity in input parsers a quite compelling argument. > | > | If you think you're getting around this complexity issue, > | you have a parser that has a security hole. > > i have running (security audited) I/O code which works like described > above for more than a decade in the internet. > IOW i have proof point that your assertion is not correct; Your example above *is* the complexity you claimed you were trying to avoid... Joe From gih@apnic.net Wed Jun 1 15:04:35 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8E0E08E8; Wed, 1 Jun 2011 15:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.605 X-Spam-Level: X-Spam-Status: No, score=-101.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-KCX-7XC6Ya; Wed, 1 Jun 2011 15:04:35 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id B3CEDE082A; Wed, 1 Jun 2011 15:04:34 -0700 (PDT) Received: from dhcp130.potaroo.net (eth143.act.adsl.internode.on.net [203.16.208.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id C5C96B68F7; Thu, 2 Jun 2011 08:04:31 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: <4DE6A8E4.7040906@dial.pipex.com> Date: Thu, 2 Jun 2011 08:04:26 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <000701cc0ec1$e552d630$aff88290$@com> <4DD381B6.8060100@bwijnen.net> <4DE6A8E4.7040906@dial.pipex.com> To: elwynd@dial.pipex.com X-Mailer: Apple Mail (2.1084) Cc: ops-dir@ietf.org, Ron Bonica , "Romascanu, Dan \(Dan\)" , sidr@ietf.org, "Bert \(IETF\) Wijnen" , ggm@apnic.net Subject: Re: [sidr] Operations Directorate Review of draft-ietf-sidr-keyroll-06 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 22:04:35 -0000 On 02/06/2011, at 7:02 AM, Elwyn Davies wrote: > Hi. >=20 > Stephen Kent wrote: >> Elwyn, >>=20 >>=20 >>> Nits/editorial comments: >>> s4, s4.1 and s4.2: >>> The term 're-issue' is used in this section regarding the new >>> certificates that the CA creates, e.g. in s4.1: >>>> When a CA, as part of the key rollover process, re-issues a CA >>>> certificate, >>> The term 're-issues' might be slightly confusing. Its a new = certificate >>> but with lots of fields the same. I would be inclined to go with >>> 'issues new' but its a quibble. >>=20 >> There is not uniform terminology for describing this sort of process = in the PKI world, but the term "reissue" (or re-issue) is reasonable. = (It is distinct from cert "renewal," which implies a new cert with the = same key and all attributes remaining constant except for the validity = interval and serial number. Cert "re-key" refers to issuing a new cert = with a new key, new serial number, maybe a new validity interval, but = the same Subject name and other attributes remaining constant.) Also, = we use the same terminology in several other SIDR docs, e.g., = draft-ietf-sidr-repos-struct-07.txt, draft-ietf-sidr-ta-07, = draft-ietf-sidr-res-certs-18, and in an analogous context in = draft-ietf-sidr-rpki-manifests-11.txt. >>=20 >> Steve >>=20 >=20 > OK. >=20 > Stick with what you've used.. consistency is wise. ok - thanks Geoff From bertietf@bwijnen.net Wed Jun 1 15:32: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 DDA54E091E; Wed, 1 Jun 2011 15:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.203 X-Spam-Level: X-Spam-Status: No, score=-98.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g05ryZ27cO26; Wed, 1 Jun 2011 15:32:45 -0700 (PDT) Received: from relay61.tele2.vuurwerk.nl (relay61.tele2.vuurwerk.nl [62.250.3.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3A623E06D1; Wed, 1 Jun 2011 15:32:27 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.69) (envelope-from ) id 1QRtxT-0005rZ-6L; Thu, 02 Jun 2011 00:32:11 +0200 Message-ID: <641B5F549F994CA1866542905B1D9429@BertLaptop> From: "Bert Wijnen \(IETF\)" To: , , "Stephen Kent" References: <000701cc0ec1$e552d630$aff88290$@com> <4DD381B6.8060100@bwijnen.net> In-Reply-To: Date: Thu, 2 Jun 2011 00:21:28 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_21E2_01CC20BB.04183410" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.6002.18417 Cc: ops-dir@ietf.org, Ron Bonica , "Romascanu, Dan \(Dan\)" , sidr@ietf.org, ggm@apnic.net Subject: Re: [sidr] Operations Directorate Review of draft-ietf-sidr-keyroll-06 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 22:32:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_21E2_01CC20BB.04183410 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Operations Directorate Review of draft-ietf-sidr-keyroThanks, and = your suggested changes do address al my comments/concerns/questions, bert ----- Original Message -----=20 From: Stephen Kent=20 To: Bert (IETF) Wijnen ; stbryant@cisco.com ; elwynd@dial.pipex.com=20 Cc: Geoff Huston ; ggm@apnic.net ; sidr@ietf.org ; Romascanu, Dan = (Dan) ; Ron Bonica ; ops-dir@ietf.org=20 Sent: Wednesday, June 01, 2011 7:53 PM Subject: Re: Operations Directorate Review of = draft-ietf-sidr-keyroll-06 Elwyn, Nits/editorial comments: s4, s4.1 and s4.2: The term 're-issue' is used in this section regarding the new certificates that the CA creates, e.g. in s4.1:=20 When a CA, as part of the key rollover process, re-issues a CA certificate, The term 're-issues' might be slightly confusing. Its a new = certificate but with lots of fields the same. I would be inclined to go with 'issues new' but its a quibble. There is not uniform terminology for describing this sort of process = in the PKI world, but the term "reissue" (or re-issue) is reasonable. = (It is distinct from cert "renewal," which implies a new cert with the = same key and all attributes remaining constant except for the validity = interval and serial number. Cert "re-key" refers to issuing a new cert = with a new key, new serial number, maybe a new validity interval, but = the same Subject name and other attributes remaining constant.) Also, = we use the same terminology in several other SIDR docs, e.g., = draft-ietf-sidr-repos-struct-07.txt, draft-ietf-sidr-ta-07, = draft-ietf-sidr-res-certs-18, and in an analogous context in = draft-ietf-sidr-rpki-manifests-11.txt. Steve --------------------- Bert, Responses to your comments below: ... RFC5706 suggests but does not require a separate "operational considerations section". The draft-ietf-sidr-keyroll-06 discusses the operational = considerations in the "Security Considerations" section. I can live with that and = leave it to the OPS ADs if they rather see that split out in a separate = section or not. Thanks. Substantive comments/questions: - last para on page 4 During the transition of the "current" and "new" CA instances it = is necessary for the "new" CA instance to re-issue all subordinate products of the "current" CA. The procedure described here = requires I wonder if the "requires" should be a "REQUIRES" (yep, I know = that rfc2119 does not have that exact capitalized form of require, but = I think that a MUST or REQUIRED is intended here, no?)? How about: During the transition of the "current" and "new" CA instances the = "new" CA instance MUST re-issue all subordinate products of the = "current" CA.=20 - page 6 4. The NEW CA enters a Staging Period. This duration of the Staging Period is determined by the CA, but it SHOULD be = no less than 24 hours. Does/would it make sense to also suggest/recommend a max period? Would 48 hours make sense? A recommended max period is probably a good idea, since relying = parties are burdened by having to deal with two sets of signed objects. If my = co-author does not object, I would revise the text as follows: 4. The NEW CA enters a Staging Period. This duration of the Staging Period is determined by the CA, but it SHOULD be no less than 24 hours. (It is RECOMMENDED that the staging = period be no longer than 48 hours.) ... - given the first para in sect 1, I wonder if ID.ietf-sidr-arch = should be a normative instead of a informative reference. OK, that's an easy change. Editorial/nits: - sect 1. 1st sentence This document describes an algorithm to by employed by a s/by/be/ (the first occurrence of "by") OK. - page 4, at top: CURRENT: The CURRENT CA is the active CA instance used to accept and process certificate issuance and revocation requests The = starting s/requests/requests./ OK. - page 5 expand acronym CPS on its first use in this document. used in the CURRENT CA certificate. The Certificate Practice Statement (CPS) for the issuer of the NEW CA certificate will indicate the time frame within which a certificate request is expected to be processed. - same for AIA acronym on page 6. - Generate a new key pair, and generate an associated EE certificate request with an Authority Information Access = (AIA) value of the NEW CA's repository publication point.=20 - page 6: 4. The NEW CA enters a Staging Period. This duration of the s/This duration of the/The duration of this/ OK - page 8 expand acronym CMS on its first use in this document. (If the signing time or binary signing time values in the = Cryptograpic Message Syntax (CMS) wrapper are non-null, they MAY be updated to reflect the current time.) Steve ------=_NextPart_000_21E2_01CC20BB.04183410 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Operations Directorate Review of = draft-ietf-sidr-keyro
Thanks, and your suggested changes do = address al my=20 comments/concerns/questions,
 
bert
----- Original Message -----
From:=20 Stephen Kent =
To: Bert (IETF) Wijnen ; stbryant@cisco.com ; elwynd@dial.pipex.com
Sent: Wednesday, June 01, 2011 = 7:53=20 PM
Subject: Re: Operations = Directorate=20 Review of draft-ietf-sidr-keyroll-06

Elwyn,


Nits/editorial comments:
s4, s4.1 and=20 s4.2:
The  term 're-issue' is used in this section regarding = the=20 new
certificates that the CA creates, e.g. in s4.1:=20
When a CA, as part of the key rollover = process,=20 re-issues a CA
   = certificate,
The term 're-issues' might be slightly = confusing.=20 Its a new certificate
but with lots of fields the same.  I = would be=20 inclined to go with
'issues new' but its a quibble.

There is not uniform terminology for describing this sort of = process in=20 the PKI world, but the term "reissue" (or re-issue) is = reasonable.  (It=20 is distinct from cert "renewal," which implies a new cert with the = same key=20 and all attributes remaining constant except for the validity interval = and=20 serial number. Cert "re-key" refers to issuing a new cert with a new = key, new=20 serial number, maybe a new validity interval, but the same Subject = name and=20 other attributes remaining constant.)  Also, we use the same = terminology=20 in several other SIDR docs, e.g., draft-ietf-sidr-repos-struct-07.txt, = draft-ietf-sidr-ta-07,  draft-ietf-sidr-res-certs-18, and in an = analogous=20 context in draft-ietf-sidr-rpki-manifests-11.txt.

Steve

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

Bert,

Responses to your comments below:

...

RFC5706 suggests but does not require a=20 separate
"operational considerations section".

The=20 draft-ietf-sidr-keyroll-06 discusses the operational = considerations
in=20 the "Security Considerations" section. I can live with that and = leave=20 it
to the OPS ADs if they rather see that split out in a separate = section
or not.

Thanks.


Substantive comments/questions:

- = last=20 para on page 4

   During the transition of the = "current"=20 and "new" CA instances it is
   necessary for the "new" = CA=20 instance to re-issue all subordinate
   products of the = "current" CA.  The procedure described here=20 requires

   I wonder if the "requires" should be a=20 "REQUIRES" (yep, I know that
   rfc2119 does not have = that=20 exact capitalized form of require, but I
   think that = a MUST=20 or REQUIRED is intended here, no?)?

How about:

    During the transition of = the=20 "current" and "new" CA instances the "new"
    CA instance MUST = re-issue all=20 subordinate products of the "current" CA. 


- page 6
      = 4. =20 The NEW CA enters a Staging Period.  This duration of=20 the
          = Staging Period=20 is determined by the CA, but it SHOULD be=20 no
          less = than 24=20 hours.
   Does/would it make sense to also = suggest/recommend a=20 max period?
   Would 48 hours make sense?

A recommended max period is probably a good idea, since relying = parties=20 are
burdened by having to deal with two sets of signed objects. If my = co-author does not object, I would revise the text as follows:

4.        The NEW=20 CA enters a Staging Period.  This duration of=20 the
          Staging = Period=20 is determined by the CA, but it SHOULD be no
          = less than=20 24 hours.  (It is RECOMMENDED that the staging = period
       =20   be no longer than 48 hours.) ...



- given the first para in sect 1, I = wonder if=20 ID.ietf-sidr-arch should be
   a normative instead of a = informative reference.

OK, that's an easy change.

Editorial/nits:

- sect 1. 1st=20 sentence
   This document describes an algorithm to by = employed=20 by a

   s/by/be/  (the first occurrence of=20 "by")

OK.
- page 4, at top:
 =20 CURRENT:
      The CURRENT CA is the = active CA=20 instance used to accept and
      = process=20 certificate issuance and revocation requests The = starting

 =20 s/requests/requests./

OK.
- page 5
   expand acronym CPS on its first = use in=20 this document.

     used in the = CURRENT CA=20 certificate.  The Certificate Practice
     Statement  (CPS) for=20 the issuer of the NEW CA certificate will
     indicate the time = frame=20 within which a certificate request is
     expected to be=20 processed.



- same for AIA acronym on page = 6.

      - =20 Generate a new key pair, and generate an associated EE
        =20 certificate request with an Authority Information Access = (AIA)
        =20 value of the NEW CA's repository publication point. 


- page 6:
  4.  The NEW CA = enters a=20 Staging Period.  This duration of the

  s/This = duration of=20 the/The duration of this/

OK
- page 8
   expand acronym CMS on its first = use in=20 this document.

     (If the signing = time or=20 binary signing time values in the Cryptograpic
     Message Syntax = (CMS) wrapper=20 are non-null, they MAY be updated to
     reflect the = current=20 time.)


Steve
------=_NextPart_000_21E2_01CC20BB.04183410-- From gih@apnic.net Wed Jun 1 21:51: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 54DA9E07C4; Wed, 1 Jun 2011 21:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.605 X-Spam-Level: X-Spam-Status: No, score=-101.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIbhEDWgNw3S; Wed, 1 Jun 2011 21:51:26 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 32FF9E0910; Wed, 1 Jun 2011 21:49:35 -0700 (PDT) Received: from dhcp130.potaroo.net (eth143.act.adsl.internode.on.net [203.16.208.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 62C08B68E6; Thu, 2 Jun 2011 14:49:31 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Geoff Huston X-Priority: 3 In-Reply-To: <641B5F549F994CA1866542905B1D9429@BertLaptop> Date: Thu, 2 Jun 2011 14:49:26 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <000701cc0ec1$e552d630$aff88290$@com> <4DD381B6.8060100@bwijnen.net> <641B5F549F994CA1866542905B1D9429@BertLaptop> To: Stephen Kent X-Mailer: Apple Mail (2.1084) Cc: ops-dir@ietf.org, Ron Bonica , "Romascanu, Dan \(Dan\)" , "sidr@ietf.org wg" , elwynd@dial.pipex.com, "Bert Wijnen \(IETF\)" , George Michaelson Subject: Re: [sidr] Operations Directorate Review of draft-ietf-sidr-keyroll-06 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 04:51:27 -0000 I will make all the noted changes to -07 of this document - except the = following, which I would like to discuss: >> - page 6 >> 4. The NEW CA enters a Staging Period. This duration of the >> Staging Period is determined by the CA, but it SHOULD be no >> less than 24 hours. >> Does/would it make sense to also suggest/recommend a max period? >> Would 48 hours make sense? >=20 > A recommended max period is probably a good idea, since relying = parties are > burdened by having to deal with two sets of signed objects. If my = co-author does not object, I would revise the text as follows: 4. The NEW CA enters a Staging Period. This duration of the Staging Period is determined by the CA, but it SHOULD be no less than 24 hours. (It is RECOMMENDED that the staging = period be no longer than 48 hours.) ... Given that during the staging period the only things that are published = are the CA, the CRL and the Manifest for the new CA (sobordinate = products are only published on the expiration of the staging period when = the actual cutover happens), then relying parties are not burdened by = having to deal with two sets of signed products. In many ways the = staging period is a "pre-loaded new key in waiting" and in theory could = be held in this state indefinitely.=20 So I wonder: a) why a max period is necessary to stipulate, and=20 b) if it is necessarily a good idea, then is this a substantive change = that means that the document should head back to the WG for a review? My personal opinion is that this is harmless and it is not necessary to = alter the document to specify a max period. Geoff From hannes@juniper.net Thu Jun 2 00:45:41 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F101E06E4 for ; Thu, 2 Jun 2011 00:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pj720bIoZccn for ; Thu, 2 Jun 2011 00:45:40 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7CCE065D for ; Thu, 2 Jun 2011 00:45:40 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTec/l9w2KKoh/eeoPr2XmDZtMIBBI/G1@postini.com; Thu, 02 Jun 2011 00:45:40 PDT Received: from hannes-755.juniper.net (172.30.152.52) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.2.254.0; Thu, 2 Jun 2011 00:43:03 -0700 Received: by hannes-755.juniper.net (Postfix, from userid 1000) id 4069A2844C; Thu, 2 Jun 2011 09:42:42 +0200 (CEST) Date: Thu, 2 Jun 2011 09:42:42 +0200 From: Hannes Gredler To: Joe Touch Message-ID: <20110602074240.GA22969@juniper.net> References: <4167B366-02DE-4637-9CA1-175E3A1BB321@vpnc.org> <4DE52BE4.3040900@isi.edu> <20110531181909.GB18034@juniper.net> <4DE532BD.5030805@isi.edu> <20110601065753.GC18752@juniper.net> <4DE663C2.4050304@isi.edu> <20110601184409.GA21723@juniper.net> <4DE6AB52.5020802@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <4DE6AB52.5020802@isi.edu> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Paul Hoffman , sidr@ietf.org Subject: Re: [sidr] rpki-rtr protocol maximum message length X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 07:45:41 -0000 On Wed, Jun 01, 2011 at 02:12:50PM -0700, Joe Touch wrote: | Hi, Hannes, | | On 6/1/2011 11:44 AM, Hannes Gredler wrote: | ... | >one implementation choice could be to: | >parse your input buffer up until you reach the "incomplete" PDU | >which does not yet have enough payload. finally the incomplete part | >gets copied back to the beginning of the buffer; | >for the rpki protocol (with its small PDUs) that rebasing is a relatively | >cheap operation. | > | >| There's no way around this - even if the message says "I'm 240 | >| bytes", you can't know that the 240 bytes are there; | > | >usually my buffer struct is a the buffer itself and two pointers | >(start and end) for housekeeping purposes. therefore i know how | >full my buffer is (buffer pointer get updated after every read | >and parser call) | | (see below) | | >| the source could have errd. You still need to grab data from the socket into an | >| intermediate space - which will be a few PDUs in length - and parse | >| that, so you can get around such boundary issues and grab data off | >| the socket without needing to put it back. | > | >exactly .. all i am asking for is a constant for storing 1 PDU such that | >i can appropriately size the "intermediate space" | | OK, so we're talking about the same thing. I was objecting to the | concept of "PDU" - what we're talking about is the maximum length of | a self-contained parseable message. (PDUs tend to mean "packet" at | L1-L4). good :-) | >|>| Either way, there's no reason for a *protocol action* to deal with a | >|>| receiver buffering issue. | >|> | >|>i find less code-complexity in input parsers a quite compelling argument. | >| | >| If you think you're getting around this complexity issue, | >| you have a parser that has a security hole. | > | >i have running (security audited) I/O code which works like described | >above for more than a decade in the internet. | >IOW i have proof point that your assertion is not correct; | | Your example above *is* the complexity you claimed you were trying | to avoid... even with the the above i cannot handle cases like processing a 4100 byte message as it never fits into the "intermediate" space of 4K; that is the main reason i was asking for a max-PDU size constant in the spec; (alternatively i continue what i do (flap the session) and write an error PDU with some more descriptive text to tell the operator whats going on) tx, /hannes From bertietf@bwijnen.net Thu Jun 2 03:00: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 97BA1E072C; Thu, 2 Jun 2011 03:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.353 X-Spam-Level: X-Spam-Status: No, score=-99.353 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9wvbuwcfKIx; Thu, 2 Jun 2011 03:00:23 -0700 (PDT) Received: from relay61.tele2.vuurwerk.nl (relay61.tele2.vuurwerk.nl [62.250.3.61]) by ietfa.amsl.com (Postfix) with ESMTP id DB5BBE071C; Thu, 2 Jun 2011 03:00:21 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.69) (envelope-from ) id 1QS4h4-0000sV-N5; Thu, 02 Jun 2011 11:59:58 +0200 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Geoff Huston" , "Stephen Kent" References: <000701cc0ec1$e552d630$aff88290$@com> <4DD381B6.8060100@bwijnen.net> <641B5F549F994CA1866542905B1D9429@BertLaptop> In-Reply-To: Date: Thu, 2 Jun 2011 11:59:39 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.6002.18417 Cc: ops-dir@ietf.org, Ron Bonica , "Romascanu, Dan \(Dan\)" , sidr@ietf.org, elwynd@dial.pipex.com, George Michaelson Subject: Re: [sidr] Operations Directorate Review of draft-ietf-sidr-keyroll-06 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 10:00:23 -0000 Ok Geoff, thanks for the explanation. I am not as intimately familiar with the technical details here as you guys are, so I hope Stephen and you can come to agreement on that. If nothing else, maybe add that explanation that you gave below in one form or another. It shows that you've thought about it and explains why you do list a minimum time but not a max. Bert ----- Original Message ----- From: "Geoff Huston" To: "Stephen Kent" Cc: ; ; "George Michaelson" ; ; "Romascanu, Dan (Dan)" ; "Ron Bonica" ; ; "Bert Wijnen (IETF)" Sent: Thursday, June 02, 2011 6:49 AM Subject: Re: Operations Directorate Review of draft-ietf-sidr-keyroll-06 I will make all the noted changes to -07 of this document - except the following, which I would like to discuss: >> - page 6 >> 4. The NEW CA enters a Staging Period. This duration of the >> Staging Period is determined by the CA, but it SHOULD be no >> less than 24 hours. >> Does/would it make sense to also suggest/recommend a max period? >> Would 48 hours make sense? > > A recommended max period is probably a good idea, since relying parties are > burdened by having to deal with two sets of signed objects. If my co-author > does not object, I would revise the text as follows: 4. The NEW CA enters a Staging Period. This duration of the Staging Period is determined by the CA, but it SHOULD be no less than 24 hours. (It is RECOMMENDED that the staging period be no longer than 48 hours.) ... Given that during the staging period the only things that are published are the CA, the CRL and the Manifest for the new CA (sobordinate products are only published on the expiration of the staging period when the actual cutover happens), then relying parties are not burdened by having to deal with two sets of signed products. In many ways the staging period is a "pre-loaded new key in waiting" and in theory could be held in this state indefinitely. So I wonder: a) why a max period is necessary to stipulate, and b) if it is necessarily a good idea, then is this a substantive change that means that the document should head back to the WG for a review? My personal opinion is that this is harmless and it is not necessary to alter the document to specify a max period. Geoff From ietfc@btconnect.com Thu Jun 2 03:04: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 434F0E0797 for ; Thu, 2 Jun 2011 03:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=-0.952, BAYES_20=-0.74, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEFPri1D4db4 for ; Thu, 2 Jun 2011 03:04:41 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by ietfa.amsl.com (Postfix) with ESMTP id 65C89E0794 for ; Thu, 2 Jun 2011 03:04:40 -0700 (PDT) Received: from host217-43-155-221.range217-43.btcentralplus.com (HELO pc6) ([217.43.155.221]) by c2beaomr10.btconnect.com with SMTP id DAL03441; Thu, 02 Jun 2011 11:04:35 +0100 (BST) Message-ID: <001301cc2103$d5452a00$4001a8c0@gateway.2wire.net> From: "t.petch" To: "John Scudder" References: <00f301cc1c85$dabc3fa0$4001a8c0@gateway.2wire.net> Date: Thu, 2 Jun 2011 11:02:38 +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.4DE76032.00CD, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.6.2.91216:17:7.586, ip=217.43.155.221, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, __SUBJECT_ENDING_IN_LATIN_OR_NUMERALS, __STOCK_PHRASE_6, 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=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020C.4DE76034.0030,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: "Sriram, Kotikalapudi" , sidr wg list Subject: Re: [sidr] RIB Size Estimation for BGPSEC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 10:04:42 -0000 ----- Original Message ----- From: "John Scudder" To: "t.petch" Cc: "Sriram, Kotikalapudi" ; "sidr wg list" Sent: Tuesday, May 31, 2011 7:47 PM > On May 27, 2011, at 11:50 AM, t.petch wrote: > > > RRG, before looking for some architectures that would solve the world's routing > > problems, did discuss the expected capacity of DFZ routers, given the expected > > rate of growth of technology, so as to work out how long the IETF has got to > > come up with something new. > > > > The consensus was that routers could not be expected to support more than 1M > > entries in the RIB > [...] > > Really? I wouldn't put too much stock in that, given that current routers support substantially more than 1M. > > > which is somewhat less than the 2.7M you expect in 2025. > > More than that too. > > Possibly you meant FIB and not RIB? The reported numbers are wrong for that too, though not as egregiously. John Thanks for the correction. I was commenting on 15% yearly growth for # unique eBGP prefixes (377K in 2011 to 2.7M in 2025). for which FIB would be a better acronym:-) In the data that Philip Smith sends out, I see a current figure of 357k or 360k and the RRG certainly saw a figure of 1M as a practical maximum, with technology projected to go on evolving, so I am unclear which numbers you see as wrong. As to IPv6, I surmise that this will be a disaster area, with 60% growth perhaps an underestimate. On IPv6 lists, in the IETF and RIPE, there seems to be no concept that handing out /48s to all and sundry could lead to an explosive and untenable growth in the table. Time and again I see comments to the effect that IPv6 effectively removes the constraints on the assignment of prefixes with no caveat about the impact on routers. I just hope that IPv6 never catches on:-) Tom Petch > --John > From kent@bbn.com Thu Jun 2 06:49: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 840D7E074D; Thu, 2 Jun 2011 06:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.369 X-Spam-Level: X-Spam-Status: No, score=-106.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kqf7SZzXePh; Thu, 2 Jun 2011 06:49:53 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id B7DCCE0726; Thu, 2 Jun 2011 06:49:53 -0700 (PDT) Received: from dhcp89-089-178.bbn.com ([128.89.89.178]:49420) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QS8HW-000MJ6-VV; Thu, 02 Jun 2011 09:49:51 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <000701cc0ec1$e552d630$aff88290$@com> <4DD381B6.8060100@bwijnen.net> <641B5F549F994CA1866542905B1D9429@BertLaptop> Date: Thu, 2 Jun 2011 09:48:34 -0400 To: Geoff Huston From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: ops-dir@ietf.org, Ron Bonica , "Romascanu, Dan \(Dan\)" , "sidr@ietf.org wg" , elwynd@dial.pipex.com, "Bert Wijnen \(IETF\)" , George Michaelson Subject: Re: [sidr] Operations Directorate Review of draft-ietf-sidr-keyroll-06 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 13:49:54 -0000 >... > >4. The NEW CA enters a Staging Period. This duration of the > Staging Period is determined by the CA, but it SHOULD be no > less than 24 hours. (It is RECOMMENDED that the staging period > be no longer than 48 hours.) ... > > >Given that during the staging period the only things that are >published are the CA, the CRL and the Manifest for the new CA >(sobordinate products are only published on the expiration of the >staging period when the actual cutover happens), then relying >parties are not burdened by having to deal with two sets of signed >products. In many ways the staging period is a "pre-loaded new key >in waiting" and in theory could be held in this state indefinitely. > >So I wonder: > > a) why a max period is necessary to stipulate, and > > b) if it is necessarily a good idea, then is this a substantive >change that means that the document should head back to the WG for a >review? > >My personal opinion is that this is harmless and it is not necessary >to alter the document to specify a max period. > > Geoff Upon further reflection, I agree with Geoff's observation that the burden on RPs is pretty minimal, since we're talking about only 3 objects (CA cert, a null CRL, and a trivial manifest). So, I am less inclined to stipulate a max period, although I don't think it would be bad to suggest (as implementation guidance) that a few days (as Terry suggested) is probably sufficient. Steve From internet-drafts@ietf.org Thu Jun 2 10:06: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 E763CE0803; Thu, 2 Jun 2011 10:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4E-ag5FXBx8W; Thu, 2 Jun 2011 10:06:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CB3E07FC; Thu, 2 Jun 2011 10:06: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.55 Message-ID: <20110602170627.11510.45472.idtracker@ietfa.amsl.com> Date: Thu, 02 Jun 2011 10:06:27 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-ltamgmt-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 17:06: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 : Local Trust Anchor Management for the Resource Public Ke= y Infrastructure Author(s) : Mark Reynolds Stephen Kent Filename : draft-ietf-sidr-ltamgmt-01.txt Pages : 28 Date : 2011-06-02 This document describes a facility to enable a relying party (RP) to manage trust anchors (TAs) in the context of the Resource Public Key Infrastructure (RPKI). It is common to allow an RP to import TA material in the form of self-signed certificates. The facility described in this document allows an RP to impose constraints on such TAs. Because this mechanism is designed to operate in the RPKI context, the relevant constraints are the RFC 3779 extensions that bind address spaces and/or autonomous system (AS) numbers to entities. The primary motivation for this facility is to enable an RP to ensure that resource allocation information that it has acquired via some trusted channel is not overridden by the information acquired from the RPKI repository system or by the putative TAs that the RP imports. Specifically, the mechanism allows an RP to specify a set of bindings between public key identifiers and RFC 3779 extension data and will override any conflicting bindings expressed via the putative TAs and the certificates downloaded from the RPKI repository system. Although this mechanism is designed for local use by an RP, an entity that is accorded administrative control over a set of RPs may use this mechanism to convey its view of the RPKI to a set of RPs within its jurisdiction. The means by which this latter use case is effected is outside the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-ltamgmt-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-ltamgmt-01.txt From internet-drafts@ietf.org Thu Jun 2 11:23: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 643FCE0849; Thu, 2 Jun 2011 11:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovt8rZbuOz+u; Thu, 2 Jun 2011 11:23:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67FFE06FB; Thu, 2 Jun 2011 11:23:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110602182324.11556.6545.idtracker@ietfa.amsl.com> Date: Thu, 02 Jun 2011 11:23:24 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-ltamgmt-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 18:23:25 -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 : Local Trust Anchor Management for the Resource Public Ke= y Infrastructure Author(s) : Mark Reynolds Stephen Kent Filename : draft-ietf-sidr-ltamgmt-02.txt Pages : 28 Date : 2011-06-02 This document describes a facility to enable a relying party (RP) to manage trust anchors (TAs) in the context of the Resource Public Key Infrastructure (RPKI). It is common to allow an RP to import TA material in the form of self-signed certificates. The facility described in this document allows an RP to impose constraints on such TAs. Because this mechanism is designed to operate in the RPKI context, the relevant constraints are the RFC 3779 extensions that bind address spaces and/or autonomous system (AS) numbers to entities. The primary motivation for this facility is to enable an RP to ensure that resource allocation information that it has acquired via some trusted channel is not overridden by the information acquired from the RPKI repository system or by the putative TAs that the RP imports. Specifically, the mechanism allows an RP to specify a set of bindings between public key identifiers and RFC 3779 extension data and will override any conflicting bindings expressed via the putative TAs and the certificates downloaded from the RPKI repository system. Although this mechanism is designed for local use by an RP, an entity that is accorded administrative control over a set of RPs may use this mechanism to convey its view of the RPKI to a set of RPs within its jurisdiction. The means by which this latter use case is effected is outside the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-ltamgmt-02.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-ltamgmt-02.txt From gih@apnic.net Thu Jun 2 17:05: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 0DA0FE06FC; Thu, 2 Jun 2011 17:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.605 X-Spam-Level: X-Spam-Status: No, score=-101.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrSjzkVPyhoN; Thu, 2 Jun 2011 17:05:29 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id DB356E06D7; Thu, 2 Jun 2011 17:05:28 -0700 (PDT) Received: from dhcp130.potaroo.net (eth143.act.adsl.internode.on.net [203.16.208.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 8D3B5B68C8; Fri, 3 Jun 2011 10:05:26 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Geoff Huston X-Priority: 3 In-Reply-To: Date: Fri, 3 Jun 2011 10:05:20 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <7CE9DF31-5EF0-4D91-937F-ED0C671FB587@apnic.net> References: <000701cc0ec1$e552d630$aff88290$@com> <4DD381B6.8060100@bwijnen.net> <641B5F549F994CA1866542905B1D9429@BertLaptop> To: Bert Wijnen (IETF) X-Mailer: Apple Mail (2.1084) Cc: ops-dir@ietf.org, Ron Bonica , "Romascanu, Dan \(Dan\)" , sidr@ietf.org, elwynd@dial.pipex.com, George Michaelson Subject: Re: [sidr] Operations Directorate Review of draft-ietf-sidr-keyroll-06 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 00:05:30 -0000 Thanks Bdert, I'll add the text: "As the Staging Period imposes no additional burden on Relying Parties, = there is no stipulated or recommended maximum Staging Period." Geoff On 02/06/2011, at 7:59 PM, Bert Wijnen (IETF) wrote: > Ok Geoff, thanks for the explanation. > I am not as intimately familiar with the technical details here as you = guys are, > so I hope Stephen and you can come to agreement on that. >=20 > If nothing else, maybe add that explanation that you gave below in one = form or > another. It shows that you've thought about it and explains why you do = list > a minimum time but not a max. >=20 > Bert > ----- Original Message ----- From: "Geoff Huston" > To: "Stephen Kent" > Cc: ; ; "George Michaelson" = ; ; "Romascanu, Dan (Dan)" = ; "Ron Bonica" ; = ; "Bert Wijnen (IETF)" > Sent: Thursday, June 02, 2011 6:49 AM > Subject: Re: Operations Directorate Review of = draft-ietf-sidr-keyroll-06 >=20 >=20 > I will make all the noted changes to -07 of this document - except the = following, which I would like to discuss: >=20 >=20 >>> - page 6 >>> 4. The NEW CA enters a Staging Period. This duration of the >>> Staging Period is determined by the CA, but it SHOULD be no >>> less than 24 hours. >>> Does/would it make sense to also suggest/recommend a max period? >>> Would 48 hours make sense? >>=20 >> A recommended max period is probably a good idea, since relying = parties are >> burdened by having to deal with two sets of signed objects. If my = co-author does not object, I would revise the text as follows: >=20 > 4. The NEW CA enters a Staging Period. This duration of the > Staging Period is determined by the CA, but it SHOULD be no > less than 24 hours. (It is RECOMMENDED that the staging = period > be no longer than 48 hours.) ... >=20 >=20 > Given that during the staging period the only things that are = published are the CA, the CRL and the Manifest for the new CA = (sobordinate products are only published on the expiration of the = staging period when the actual cutover happens), then relying parties = are not burdened by having to deal with two sets of signed products. In = many ways the staging period is a "pre-loaded new key in waiting" and in = theory could be held in this state indefinitely. >=20 > So I wonder: >=20 > a) why a max period is necessary to stipulate, and >=20 > b) if it is necessarily a good idea, then is this a substantive change = that means that the document should head back to the WG for a review? >=20 > My personal opinion is that this is harmless and it is not necessary = to alter the document to specify a max period. >=20 > Geoff >=20 >=20 -- Geoff Huston Chief Scientist, APNIC +61 7 3858 3100 gih@apnic.net From internet-drafts@ietf.org Thu Jun 2 17:11: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 80F5EE07B6; Thu, 2 Jun 2011 17:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMvsgBJxOs8K; Thu, 2 Jun 2011 17:11:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9AA7E06D7; Thu, 2 Jun 2011 17:11:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110603001135.31089.47719.idtracker@ietfa.amsl.com> Date: Thu, 02 Jun 2011 17:11:35 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-keyroll-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 00:11: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 : CA Key Rollover in the RPKI Author(s) : Geoff Huston George Michaelson Stephen Kent Filename : draft-ietf-sidr-keyroll-07.txt Pages : 10 Date : 2011-06-02 This document describes how a Certification Authority (CA) in the Resource Public Key Infrastructure (RPKI) performs a planned rollover of its key pair. This document also notes the implications of this key rollover procedure for Relying Parties (RPs). In general, RPs are expected to maintain a local cache of the objects that have been published in the RPKI repository, and thus the way in which a CA performs key rollover impacts RPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-keyroll-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-keyroll-07.txt From christopher.morrow@gmail.com Thu Jun 2 21:52: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 4D199E06C6 for ; Thu, 2 Jun 2011 21:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WB8Y5Ka0ViwM for ; Thu, 2 Jun 2011 21:52:44 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3F5E0690 for ; Thu, 2 Jun 2011 21:52:44 -0700 (PDT) Received: by pxi20 with SMTP id 20so1122263pxi.27 for ; Thu, 02 Jun 2011 21:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=MqEgevCH9fJSSDGemJa+aRt3ekQD0Vzmcon4SiYLXGY=; b=cLttOtdXtz6BggDpCos/yiiOgkoRdSM0PG8B5LRgG/n/8/HEq/OQFKmi6pgNVf3paV RoKIOnaQ/wyn4deOurIDSVwcmuNWlYKzcyj7GGyNoSPEwRz64ttgmsrXeerca2T97UTZ D+ag8BKQwWUU8qzsqundbXQdLyXazVFzO83go= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=XRCAKQ8l6CP7uiQ98ykw73JjoQtPHTbuwSHwo7iWTn3E1stW+aIMPnF/PDELc5YXDs V1setarxXrT6tZeiDjJ/Vl/OlS7VZ343/c8GsIdoAtLasMEVVPsW0atyyW+N8AzFNZX8 G8jV/KjPAhDFfuxG9NvH20XhD5DddNN35QHAA= MIME-Version: 1.0 Received: by 10.68.35.72 with SMTP id f8mr657504pbj.83.1307076764233; Thu, 02 Jun 2011 21:52:44 -0700 (PDT) Received: by 10.68.56.133 with HTTP; Thu, 2 Jun 2011 21:52:44 -0700 (PDT) Date: Fri, 3 Jun 2011 00:52:44 -0400 Message-ID: From: Christopher Morrow To: sidr@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [sidr] Answering a question at the mic in Prague: Peter Lothberg's "what about vpn providers?" X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 03 Jun 2011 04:52:45 -0000 Peter asked at the mic about how SIDR/BGPSEC could/would/etc deal with VPN providers. I believe he meant something like MPLS VPN (RFC2547) providers. I think that after some discussion about this with a few of the document authors a summary of direction is: A set of questions about the problem space (again, assuming 2547-type vpn deployment was the target of the question) o =93what are you trying to secure?=94 i vpn-provider to vpn-provider routing domain? ii single-customer routing domain? o not all customer routes are picked up by BGP in VPN scenarios i ospf/rip/eigrp/static routes ii lack of origin by the AS-Owner (ROAs would be required to the VPN provider, not a problem) o not all customers have unique ip space across a single provider, never mind multiple providers o not all customers have unique ASNs across a single provider o route-targets are only unique across a single vpn-provider Of the above the only open question was as to what the scope of =91secure=92 would be, we decided (in the discussion) that the scope we would apply to the discussion is the: vpn-provider to vpn-provider security Given a scenario that looks like: vpn-provider BOB with vpns: A - route-target A - prefix 10.0.0.0/8 B - route-target B - prefix 10.0.0.0/8 C - route-target C - prefix 10.0.0.0/8 vpn-provider SALLY with vpns: Z - route-target Z - prefix 10.0.0.0/8 Y - route-target Y - prefix 10.0.0.0/8 X - route-target X - prefix 10.0.0.0/8 Each provider has their own Trust Anchor: TA-BOB and TA-SALLY these Trust Anchors contain (notionally) the following routing/roa informat= ion: TA-BOB: AS-A:RT-A:10.0.0.0/8 AS-B:RT-B:10.0.0.0/8 AS-C:RT-C:10.0.0.0/8 AS-D:RT-D:10.0.0.0/8 TA-SALLY: AS-Z:RT-Z:10.0.0.0/8 AS-Y:RT-Y:10.0.0.0/8 AS-X:RT-X:10.0.0.0/8 AS-D:RT-V:10.0.0.0/8 The two vpn-providers are connected together in order that their customers can have a vpn extending across both networks, for the case where a single provider (BOB) needs to extend their VPN service reach/territory into a region where they do not have (for reasons unimportant to the discussion) presence/facilities. If the intent is to secure vpn-provider to vpn-provider route exchange, some service must exist that translates: AS-D:RT-D:10.0.0.0/8 vs AS-D:RT-V:10.0.0.0/8 A proposed mapping service would accomplish this translation between the vpn-providers that participate in the single-customer, multi-provider network scenario. An open question, is whether this is necessary in a single provider deployment. It seems that the mechanisms being proposed for BGPSEC can be extended to support the vpn-provider solution with the addition of a RouteTarget extension to the ROA End Entity Cert. This would require updating the certificate profile [draft-ietf-sidr-cp], and running the algorithm change process [draft-ietf-sidr-algorithm-agility], in order to flood proper certificates out with the new extension. We could, of course, choose to change the cert profile today (except that it is in rfc editor queue at this time) and decide that RT=3D0 (for instance) is the =93Internet=94. It seems that the other mechanisms (mapping service) still need to be better defined, so revising the certificate profile later shouldn=92t be a show stopper. I hope the above helps some with Peter's question? Also, I'm really just the note taker on the above, the authors were more involved with the thought process (which makes sense to me, I do admit). Thanks for your indulgence! -Chris From christopher.morrow@gmail.com Thu Jun 2 23:06: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 57094E06A1; Thu, 2 Jun 2011 23:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIuXiqR7Jdnq; Thu, 2 Jun 2011 23:06:10 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC934E071F; Thu, 2 Jun 2011 23:06:07 -0700 (PDT) Received: by pzk5 with SMTP id 5so804974pzk.31 for ; Thu, 02 Jun 2011 23:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wzlkSM+jP06jZFl+cJiR94m498si+HvClnMigLlyB5g=; b=HJ4Qvxw7YugckrhT8UNTeA2IrTzgePOi3yA0HD7Su2fR2gh98YhjhVXMoSVib+/aRC Bbu7xIQANZnTn+n2MYGPOUvkeelsqAPhK5P3V3qYGFR2AROSIf19727V8TI8qroT5uGh 1TcleM1Kf/ahehtnmhiMAgMK17j4GtjjetNyA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=nQ0t0XqrEuETuwOr+uZU3RpPKy708Z6OsvSJYvpVl89Yy35n+bza26vwTln/5oMzdC 6eeTGRKJFik0B4ceNfEqyOdF177MzXN+CJ7AeCYFREKdOHthTqUQBZ5BotGdqvFfnZt3 +h13G/HyaaIwe6NOTJeqm2kvuJe4vGZ8+srRY= MIME-Version: 1.0 Received: by 10.68.35.102 with SMTP id g6mr627199pbj.16.1307081167275; Thu, 02 Jun 2011 23:06:07 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.68.56.133 with HTTP; Thu, 2 Jun 2011 23:06:07 -0700 (PDT) In-Reply-To: References: <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> Date: Fri, 3 Jun 2011 02:06:07 -0400 X-Google-Sender-Auth: iZN4wH1VtYQQAMWlbiTbwCu9P-8 Message-ID: From: Christopher Morrow To: sidr@ietf.org, sidr-chairs@ietf.org, Sean Turner , stephen.farrell@cs.tcd.ie Content-Type: text/plain; charset=ISO-8859-1 Cc: Rob Austein Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 06:06:11 -0000 Security-AD folks, Over here in the SIDR WG we've been batting around a problem related to secure authentication of TCP endpoints, essentially how can we specify TODAY something to use in implementations of a (we think) important protocol when the underlying technology we need isn't available (TCP-AO). Some background: Looking to close the issue of MD5/TCP-AO/SSH/etc out again, The doc: Seems to be stuck on this text: (From the abstract) " This document describes a protocol to deliver validated prefix origin data to routers over ssh." or a more in depth version of that text at: Essentially there is a need to validate that a cache and a router are talking to the right opposite entity. The authors and test-implementors enabled this connection over SSH with a fallback (for debugging I suppose?) over plain-text TCP originally. For a host of reasons SSH is now considered overkill and likely detrimental to the cause. The WG discussed on-list (in this thread): and at the in-person meeting in Prague (IETF80) the fact that SSH was probably overkill. The two endpoints want simply to authenticate the other endpoint, transport security isn't required here because the content in the stream is already encypted. The 2 methods approved today for use in IETF protocols are: o tcp-AO o ipsec AH one deprecated method is available as well: o tcp-MD5 Of the two approved methods, AO has no implementations on the routers (yet), nor server side to speak of, AH is relatively heavy weight and isn't always available on routers today. Talking to routing equipment implementors (two vendors) there was a feeling that AO will arrive shortly while AH is still too complex (for router deployments) and is not going to be available in all of the platforms which will require this functionality. On the server side of the equation there is no support for AO, some for AH (which is nice actually). In short, we don't have a good direction or belief that there is going to be one with respect to AO in the near term. What options are there for this problem? How can we motivate vendors with a spec that clearly has problems in implementation (no AO, not full reach for AH)? Are there folks who are tracking availability of AO? Could we start with something like: MAY support authentication of nodes with TCP-MD5 MAY support authentication of nodes with IPSEC-AH MUST support authentication of nodes with TCP-AO Or is mentioning TCP-MD5 verboten? Essentially it seems that the WG has gotten wedged and is looking for some guidance from the Security Area Directors :) -chris From bertietf@bwijnen.net Fri Jun 3 01:35: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 DFA1AE070C; Fri, 3 Jun 2011 01:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.928 X-Spam-Level: X-Spam-Status: No, score=-99.928 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qnn+4ppUSqBU; Fri, 3 Jun 2011 01:35:55 -0700 (PDT) Received: from relay61.tele2.vuurwerk.nl (relay61.tele2.vuurwerk.nl [62.250.3.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDDFE06F1; Fri, 3 Jun 2011 01:35:55 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.69) (envelope-from ) id 1QSPr8-0007NG-BD; Fri, 03 Jun 2011 10:35:46 +0200 Message-ID: <685D697C20CE484CBBB75FB25D5DB843@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Geoff Huston" References: <000701cc0ec1$e552d630$aff88290$@com> <4DD381B6.8060100@bwijnen.net> <641B5F549F994CA1866542905B1D9429@BertLaptop> <7CE9DF31-5EF0-4D91-937F-ED0C671FB587@apnic.net> In-Reply-To: <7CE9DF31-5EF0-4D91-937F-ED0C671FB587@apnic.net> Date: Fri, 3 Jun 2011 10:35:41 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.6002.18417 Cc: ops-dir@ietf.org, Ron Bonica , "Romascanu, Dan \(Dan\)" , sidr@ietf.org, Elwyn Davies , George Michaelson Subject: Re: [sidr] Operations Directorate Review of draft-ietf-sidr-keyroll-06 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 08:35:56 -0000 Great and thanks. Bert ----- Original Message ----- From: "Geoff Huston" To: "Bert Wijnen (IETF)" Cc: "Stephen Kent" ; ; ; "George Michaelson" ; ; "Romascanu, Dan (Dan)" ; "Ron Bonica" ; Sent: Friday, June 03, 2011 2:05 AM Subject: Re: Operations Directorate Review of draft-ietf-sidr-keyroll-06 Thanks Bdert, I'll add the text: "As the Staging Period imposes no additional burden on Relying Parties, there is no stipulated or recommended maximum Staging Period." Geoff On 02/06/2011, at 7:59 PM, Bert Wijnen (IETF) wrote: > Ok Geoff, thanks for the explanation. > I am not as intimately familiar with the technical details here as you guys > are, > so I hope Stephen and you can come to agreement on that. > > If nothing else, maybe add that explanation that you gave below in one form or > another. It shows that you've thought about it and explains why you do list > a minimum time but not a max. > > Bert > ----- Original Message ----- From: "Geoff Huston" > To: "Stephen Kent" > Cc: ; ; "George Michaelson" > ; ; "Romascanu, Dan (Dan)" ; > "Ron Bonica" ; ; "Bert Wijnen (IETF)" > > Sent: Thursday, June 02, 2011 6:49 AM > Subject: Re: Operations Directorate Review of draft-ietf-sidr-keyroll-06 > > > I will make all the noted changes to -07 of this document - except the > following, which I would like to discuss: > > >>> - page 6 >>> 4. The NEW CA enters a Staging Period. This duration of the >>> Staging Period is determined by the CA, but it SHOULD be no >>> less than 24 hours. >>> Does/would it make sense to also suggest/recommend a max period? >>> Would 48 hours make sense? >> >> A recommended max period is probably a good idea, since relying parties are >> burdened by having to deal with two sets of signed objects. If my co-author >> does not object, I would revise the text as follows: > > 4. The NEW CA enters a Staging Period. This duration of the > Staging Period is determined by the CA, but it SHOULD be no > less than 24 hours. (It is RECOMMENDED that the staging period > be no longer than 48 hours.) ... > > > Given that during the staging period the only things that are published are > the CA, the CRL and the Manifest for the new CA (sobordinate products are only > published on the expiration of the staging period when the actual cutover > happens), then relying parties are not burdened by having to deal with two > sets of signed products. In many ways the staging period is a "pre-loaded new > key in waiting" and in theory could be held in this state indefinitely. > > So I wonder: > > a) why a max period is necessary to stipulate, and > > b) if it is necessarily a good idea, then is this a substantive change that > means that the document should head back to the WG for a review? > > My personal opinion is that this is harmless and it is not necessary to alter > the document to specify a max period. > > Geoff > > -- Geoff Huston Chief Scientist, APNIC +61 7 3858 3100 gih@apnic.net From rogaglia@cisco.com Fri Jun 3 03:08: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 8AD7DE06EE for ; Fri, 3 Jun 2011 03:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZDpZv+mieL3 for ; Fri, 3 Jun 2011 03:08:04 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 35762E06D5 for ; Fri, 3 Jun 2011 03:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=19887; q=dns/txt; s=iport; t=1307095683; x=1308305283; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=QGUUjiCzy5OyoxQsMAekCKZ8DRgIJw2RJVR6kRFt2Rc=; b=ih5fqPA/xkCA0Bg+4esN6dIHZB8eKGus+939xjwiVqJ2QJ/2tYLAZyTU jw3EXFdeREtc3025FqUI24ujXWSnyq+G2Ff3M32kQNMJqnnx4O08Vep/I FJP7KYle1UmXSLTSDMz+ccd1IbCHX+BF6zAqKajp4t2BJQiR2dGTmYH+L 4=; X-Files: smime.p7s : 4389 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPKx6E2Q/khN/2dsb2JhbABTpjh3iHGlBZ19hiEEkHSPOw X-IronPort-AV: E=Sophos;i="4.65,314,1304294400"; d="p7s'?scan'208,217";a="33573459" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 03 Jun 2011 10:08:02 +0000 Received: from dhcp-10-55-94-226.cisco.com (dhcp-10-55-94-226.cisco.com [10.55.94.226]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p53A81fK002217; Fri, 3 Jun 2011 10:08:01 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-1259-223483648; protocol="application/pkcs7-signature"; micalg=sha1 From: Roque Gagliano In-Reply-To: Date: Fri, 3 Jun 2011 12:08:01 +0200 Message-Id: <88ABF155-348D-4FCB-B8DD-D257FC98689A@cisco.com> References: To: Christopher Morrow X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: Re: [sidr] Answering a question at the mic in Prague: Peter Lothberg's "what about vpn providers?" X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 03 Jun 2011 10:08:05 -0000 --Apple-Mail-1259-223483648 Content-Type: multipart/alternative; boundary=Apple-Mail-1258-223483279 --Apple-Mail-1258-223483279 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Chris, Thank you for open this issue to the list. =46rom you email I did not get which is the security threat that you are = trying to address. Is it just "fat fingers"?=20 Also, I believe you may have a typo in your implementation comment as = you cannot represent the RT in a certificate as it is not supported in = the X.509 specification (i.e. RFC3779) . So, I guess you were referring = to modify the ROA signed object to include the RT information. In this = case, what if you just define a new signed object for VPN = interconnections? We do not change anything of what has be done up to = now and we do not need to wait for any roll-over. Then, each RP can = store their locally define objects, use local policies (based on the = ta-local draft) on its validators and an extension to the rtr protocol = to transmit the RTs-prefixes to the BGP speakers. Finally, please note that the current agility draft only addresses the = process for an algorithm suite change. Not for a change in the = certificate profile or any change in basic RPKI certificates or signed = objects.=20 Roque. On Jun 3, 2011, at 6:52 AM, Christopher Morrow wrote: > Peter asked at the mic about how SIDR/BGPSEC could/would/etc deal with > VPN providers. I believe he meant something like MPLS VPN (RFC2547) > providers. I think that after some discussion about this with a few of > the document authors a summary of direction is: >=20 > A set of questions about the problem space (again, assuming 2547-type > vpn deployment was the target of the question) > o =93what are you trying to secure?=94 > i vpn-provider to vpn-provider routing domain? > ii single-customer routing domain? > o not all customer routes are picked up by BGP in VPN scenarios > i ospf/rip/eigrp/static routes > ii lack of origin by the AS-Owner (ROAs would be required to the > VPN provider, not a problem) > o not all customers have unique ip space across a single provider, > never mind multiple providers > o not all customers have unique ASNs across a single provider > o route-targets are only unique across a single vpn-provider >=20 >=20 > Of the above the only open question was as to what the scope of > =91secure=92 would be, we decided (in the discussion) that the scope = we > would apply to the discussion is the: > vpn-provider to vpn-provider security >=20 > Given a scenario that looks like: > vpn-provider BOB with vpns: > A - route-target A - prefix 10.0.0.0/8 > B - route-target B - prefix 10.0.0.0/8 > C - route-target C - prefix 10.0.0.0/8 >=20 > vpn-provider SALLY with vpns: > Z - route-target Z - prefix 10.0.0.0/8 > Y - route-target Y - prefix 10.0.0.0/8 > X - route-target X - prefix 10.0.0.0/8 >=20 > Each provider has their own Trust Anchor: TA-BOB and TA-SALLY > these Trust Anchors contain (notionally) the following routing/roa = information: > TA-BOB: > AS-A:RT-A:10.0.0.0/8 > AS-B:RT-B:10.0.0.0/8 > AS-C:RT-C:10.0.0.0/8 > AS-D:RT-D:10.0.0.0/8 >=20 > TA-SALLY: > AS-Z:RT-Z:10.0.0.0/8 > AS-Y:RT-Y:10.0.0.0/8 > AS-X:RT-X:10.0.0.0/8 > AS-D:RT-V:10.0.0.0/8 >=20 >=20 > The two vpn-providers are connected together in order that their > customers can have a vpn extending across both networks, for the case > where a single provider (BOB) needs to extend their VPN service > reach/territory into a region where they do not have (for reasons > unimportant to the discussion) presence/facilities. If the intent is > to secure vpn-provider to vpn-provider route exchange, some service > must exist that translates: > AS-D:RT-D:10.0.0.0/8 vs AS-D:RT-V:10.0.0.0/8 >=20 > A proposed mapping service would accomplish this translation between > the vpn-providers that participate in the single-customer, > multi-provider network scenario. An open question, is whether this is > necessary in a single provider deployment. >=20 > It seems that the mechanisms being proposed for BGPSEC can be extended > to support the vpn-provider solution with the addition of a > RouteTarget extension to the ROA End Entity Cert. This would require > updating the certificate profile [draft-ietf-sidr-cp], and running the > algorithm change process [draft-ietf-sidr-algorithm-agility], in order > to flood proper certificates out with the new extension. We could, of > course, choose to change the cert profile today (except that it is in > rfc editor queue at this time) and decide that RT=3D0 (for instance) = is > the =93Internet=94. It seems that the other mechanisms (mapping = service) > still need to be better defined, so revising the certificate profile > later shouldn=92t be a show stopper. >=20 > I hope the above helps some with Peter's question? Also, I'm really > just the note taker on the above, the authors were more involved with > the thought process (which makes sense to me, I do admit). Thanks for > your indulgence! >=20 > -Chris > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-1258-223483279 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Chris,

Thank you for open this issue to the = list.

=46rom you email I did not get which is = the security threat that you are trying to address. Is it just "fat = fingers"? 

Also, I believe you may have a = typo in your implementation comment as you cannot represent the RT in a = certificate as it is not supported in the X.509 specification (i.e. = RFC3779) . So, I guess you were referring to modify the ROA signed = object to include the RT information.  In this case, what if you = just define a new signed object for VPN interconnections? We do not = change anything of what has be done up to now and we do not need to wait = for any roll-over. Then, each RP can store their locally define objects, = use local policies (based on the ta-local draft) on its validators =  and an extension to the rtr protocol to transmit the RTs-prefixes = to the BGP speakers.

Finally, please = note that the current agility draft only addresses the process for an = algorithm suite change. Not for a change in the certificate profile or = any change in basic RPKI certificates or signed = objects. 

Roque.


On Jun 3, 2011, at 6:52 AM, Christopher Morrow wrote:

Peter = asked at the mic about how SIDR/BGPSEC could/would/etc deal with
VPN = providers. I believe he meant something like MPLS VPN = (RFC2547)
providers. I think that after some discussion about this = with a few of
the document authors a summary of direction = is:

A set of questions about the problem space (again, assuming = 2547-type
vpn deployment was the target of the question)
 o =  =93what are you trying to secure?=94
=      i  vpn-provider to vpn-provider = routing domain?
     ii =  single-customer routing domain?
 o  not all customer = routes are picked up by BGP in VPN scenarios
=      i ospf/rip/eigrp/static routes
=      ii lack of origin by the AS-Owner (ROAs = would be required to the
VPN provider, not a problem)
 o =  not all customers have unique ip space across a single = provider,
never mind multiple providers
 o  not all = customers have unique ASNs across a single provider
 o =  route-targets are only unique across a single = vpn-provider


Of the above the only open question was as to = what the scope of
=91secure=92 would be, we decided (in the = discussion) that the scope we
would apply to the discussion is = the:
 vpn-provider to vpn-provider security

Given a = scenario that looks like:
vpn-provider BOB with vpns:
A - = route-target A - prefix 10.0.0.0/8
B - route-target B - prefix = 10.0.0.0/8
C - route-target C - prefix = 10.0.0.0/8

vpn-provider SALLY with vpns:
Z - route-target Z - = prefix 10.0.0.0/8
Y - route-target Y - prefix 10.0.0.0/8
X - = route-target X - prefix 10.0.0.0/8

Each provider has their own = Trust Anchor: TA-BOB and TA-SALLY
these Trust Anchors contain = (notionally) the following routing/roa information:
TA-BOB:
=     AS-A:RT-A:10.0.0.0/8
=     AS-B:RT-B:10.0.0.0/8
=     AS-C:RT-C:10.0.0.0/8
=     AS-D:RT-D:10.0.0.0/8

TA-SALLY:
=     AS-Z:RT-Z:10.0.0.0/8
=     AS-Y:RT-Y:10.0.0.0/8
=     AS-X:RT-X:10.0.0.0/8
=    AS-D:RT-V:10.0.0.0/8


The two vpn-providers = are connected together in order that their
customers can have a vpn = extending across both networks, for the case
where a single provider = (BOB) needs to extend their VPN service
reach/territory into a region = where they do not have (for reasons
unimportant to the discussion) = presence/facilities. If the intent is
to secure vpn-provider to = vpn-provider route exchange, some service
must exist that = translates:
AS-D:RT-D:10.0.0.0/8 vs AS-D:RT-V:10.0.0.0/8

A = proposed mapping service would accomplish this translation = between
the vpn-providers that participate in the = single-customer,
multi-provider network scenario. An open question, = is whether this is
necessary in a single provider = deployment.

It seems that the mechanisms being proposed for = BGPSEC can be extended
to support the vpn-provider solution with the = addition of a
RouteTarget extension to the ROA End Entity Cert. This = would require
updating the certificate profile [draft-ietf-sidr-cp], = and running the
algorithm change process = [draft-ietf-sidr-algorithm-agility], in order
to flood proper = certificates out with the new extension. We could, of
course, choose = to change the cert profile today (except that it is in
rfc editor = queue at this time) and decide that RT=3D0 (for instance) is
the = =93Internet=94. It seems that the other mechanisms (mapping = service)
still need to be better defined, so revising the certificate = profile
later shouldn=92t be a show stopper.

I hope the above = helps some with Peter's question? Also, I'm really
just the note = taker on the above, the authors were more involved with
the thought = process (which makes sense to me, I do admit). Thanks for
your = indulgence!

-Chris
_____________________________________________= __
sidr mailing list
sidr@ietf.org
https://www.ietf.org/ma= ilman/listinfo/sidr

= --Apple-Mail-1258-223483279-- --Apple-Mail-1259-223483648 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXDCCBWYw ggROoAMCAQICEFyqcUyRFrhvN5s0SHw/EO4wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA1MTAwMDAwMDBaFw0x MjA1MTEyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5Sb3F1ZSBHYWdsaWFubzEhMB8GCSqGSIb3DQEJARYScm9nYWdsaWFAY2lz Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxIp28SUiJ/fiFYD/Nct8MUbG WJuPqSnhkfBYMFbbWfDDrHR8OXzK2LkWIuHY5aeAo1nalAQCO40oeTYt0cp9W++a7USNCEDQzgVN Rg0YMYL27YSQoVJnecO3u9wi0jjwhJGblWWxphaztdaMbqiChgND1PHqf7dcs4UjeUOhhKFk0/61 mTmduV721jrxj6ABIlUHAc7nXhKANtDbKdBZzEhM4dbzp6STKq65EQ3xRLVFIuapTgNVckvXtc1e Cyu4xLOLZgaD2aLq9JzBn9y/rFRMtf2euP/Nmzl7QRjAUjpPdo1n6NXWGDtNyR0lUrcJ/x1leccZ Gfj0eaqe+tpJmQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAG A1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29t L0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAsvqKrlga/tU0vyBtnBOj 4miDAZxou0/fN2wVEK7dRLzIQLYEJD35sELVhiP8v8wVHtgOeVHz9FyBEVqXmJ0RKy4kMC7gdQxj +t1MlqSTDShEaPMmiwaK6M1iJ9jpBL4JvoiirpHnQYGukkgvTUeqITWZ5ecg03nB3QHuab91Gc+n RZ1OKL4D4p5IkvzWhRlIAlxW9yGZyB8r9V6iu3+1SYEpPPUN3AYCxXeXrn8fJjkOoEodybRiGyfW pMpShpTZg2tHB7ZX162Ti3sRvwA2mktDMnBtEm1pXo15z7yieDUPmjVybMA4byV7AQcbIrjQj0eq c/biBsueC2KWoJY7TDCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEF BQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBG b3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5 MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwT j+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliW B6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGce dAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69s sQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOM Wev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0 cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtg hkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoG CCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCeg JYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4G CCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNV HREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN 7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqT OtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih /1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0D uFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRIfD8Q7jAJBgUr DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA2 MDMxMDA4MDJaMCMGCSqGSIb3DQEJBDEWBBSGjoexE0gbQZOq9ZVfHVaULsLUKDCCAQMGCSsGAQQB gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBcqnFMkRa4bzebNEh8PxDuMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRI fD8Q7jANBgkqhkiG9w0BAQEFAASCAQCRzLkmzIiqvB3FuszVtp4VWark7r6h/p3GzCb1YIU6tbDP z+iG8l2cTD4CIwpiA3CpAu7uZMqvzliETx9xsgyqlMZ/EnrZYHWzkUb/X50+I2v4fmtPjOtOR++v 7A5EIpx9w+ZA/zuZTkLQGwwEOfTj7rX0J51TBI/WgkPmMUwcbQ14vg257XGdk3qu/2ZLxffWXMLW ikZbH8sWWS6yvBi2pL1tynTtok4X01DJkoRV0AGTWa6o8rT8WpHjk0sSsO+jgQIaZ9sivhv/vT6c 1ku6XwYmf77sX0mWJKsqRf2yYNDkdM6F2LHglp9SBtmtmZ/s7MA19yAT9Rp5PcuWSjv9AAAAAAAA --Apple-Mail-1259-223483648-- From kotikalapudi.sriram@nist.gov Fri Jun 3 08:31: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 EF94DE077D for ; Fri, 3 Jun 2011 08:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+7+FeMTQt5s for ; Fri, 3 Jun 2011 08:31:06 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 0F33DE0776 for ; Fri, 3 Jun 2011 08:31:05 -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.289.1; Fri, 3 Jun 2011 11:31:12 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Fri, 3 Jun 2011 11:30:31 -0400 From: "Sriram, Kotikalapudi" To: "sidr@ietf.org" Date: Fri, 3 Jun 2011 11:31:03 -0400 Thread-Topic: BGPSEC RIB estimation including IPv4 and IPv6 Thread-Index: Acwh/+PO2jOUwegUQDSpB+dT6EWJVAAAIHXg Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: [sidr] BGPSEC RIB estimation including IPv4 and IPv6 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 03 Jun 2011 15:31:07 -0000 I have updated the RIB estimation model to include growth rates for IPv4 and IPv6 individually. Link for an updated set of slides based on this refinement is: http://www.antd.nist.gov/~ksriram/BGPSEC_RIB_Estimation_v4_v6.pdf Tony has suggested 60% or higher growth rate for IPv6 prefixes. Currently, I am assuming 100%, 90%, 80%, etc. in the initial years with gradual decline to 30% and then keep it steady at 30% yearly growth. This amounts to a cumulative growth of nearly 25000% from 2011 to 2025 for eBGP IPv6 prefixes. For IPv4, I am using a steady 12% yearly growth rate, which is slightly more aggressive than what is suggested by Geoff Huston's measurement data over the 2008-2011 period. The above assumptions can be revised based on updated measurements as they become available (including any effects of IPv4 deaggregation due to IPv4 exhaustion). Chris mentioned that operators and vendors should play with the Excel spreadsheet model to have conversations about planning for the RIB requirements. I am happy to share the spreadsheet. Here is the link for it: http://www.antd.nist.gov/~ksriram/BGPSEC_RIB.xls The spreadsheet is very amenable to inputting your view of the IPv4, IPv6 growth rates and BGPSEC adoption curve, and you can see the resulting RIB estimates for route reflectors and PE routers. You can also observe the RIB size comparisons between RSA-2048 and ECDSA-256 signature algorithms for your various growth assumptions. Thanks for the discussion and comments so far. Further comments/suggestions are very welcome. Sriram NIST From christopher.morrow@gmail.com Fri Jun 3 09:44:46 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40583E0780; Fri, 3 Jun 2011 09:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVVUW6EYcImK; Fri, 3 Jun 2011 09:44:45 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 790E5E0776; Fri, 3 Jun 2011 09:44:45 -0700 (PDT) Received: by pwi5 with SMTP id 5so1205128pwi.31 for ; Fri, 03 Jun 2011 09:44:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kBLH9rk83MXwtQcNRr/gEPjoplEcwFyYudY8jFJGV58=; b=dFlrTQHvKZHLjaPZlangpWdh1usVJZGPd/tSJ3eirsxiFmP/HgjaNVZp/O7NZoAjeW +Tdt3Fq3oA2plVMI/YpZ2erpLsKHNgnJwUWgswnxrb739DCll5T75qY1NrGsTT21WHbs xZSZHOafVrEnSyAtZj5VndR7XmP1Sd4Gmlkkk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=bZoZrHBl664scb814mjR2WWORBRIkxBUNZEtanmv5vzi9nqOq6mbt0apSbWPYxEpQw 65gUUWipZORg6wI4pzi5B3e7uuNRhCLPtqy9yZGU+k1UzGx6K3Z/n7+hvmrkbvNy5TUR GPsw0n9vDS2fTej/16vQAU8n0I2fYw9wH/wZY= MIME-Version: 1.0 Received: by 10.68.0.227 with SMTP id 3mr915758pbh.284.1307119485067; Fri, 03 Jun 2011 09:44:45 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.68.56.133 with HTTP; Fri, 3 Jun 2011 09:44:44 -0700 (PDT) In-Reply-To: References: <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> Date: Fri, 3 Jun 2011 12:44:44 -0400 X-Google-Sender-Auth: ialyd5VWqmwEsO0Uq81qAyYvIc0 Message-ID: From: Christopher Morrow To: sidr@ietf.org, sidr-chairs@ietf.org, Sean Turner , stephen.farrell@cs.tcd.ie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rob Austein Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 16:44:46 -0000 a kind reader thunked me on the noggin'... On Fri, Jun 3, 2011 at 2:06 AM, Christopher Morrow wrote: > Security-AD folks, > Over here in the SIDR WG we've been batting around a problem related > to secure authentication of TCP endpoints, essentially how can we > specify TODAY something to use in implementations of a (we think) > important protocol when the underlying technology we need isn't > available (TCP-AO). Some background: > > Looking to close the issue of MD5/TCP-AO/SSH/etc out again, The doc: > > > Seems to be stuck on this text: > > (From the abstract) > " This document describes a protocol to deliver validated > =A0 prefix origin data to routers over ssh." > > or a more in depth version of that text at: > > > Essentially there is a need to validate that a cache and a router are > talking to the right opposite entity. The authors and > test-implementors enabled this connection over SSH with a fallback > (for debugging I suppose?) over plain-text TCP originally. For a host > of reasons SSH is now considered overkill and likely detrimental to > the cause. > > The WG discussed on-list (in this thread): > > > and at the in-person meeting in Prague (IETF80) the fact that SSH was > probably overkill. The two endpoints want simply =A0to authenticate the > other endpoint, transport security isn't required here because the > content in the stream is already encypted. The 2 methods approved > today for use in IETF protocols are: 'the content in the stream is public data, so privacy isn't warranted here.' Essentially make sure you talk to the right end point and no one fiddled bits during transport (which AO and MD5 and AH all do just fine, modulo the 'md5 is deprecated' discussion, of course) apologies for the confusion, and... for not ending with: -Chris > =A0o tcp-AO > =A0o ipsec AH > > one deprecated method is available as well: > =A0o tcp-MD5 > > Of the two approved methods, AO has no implementations on the routers > (yet), nor server side to speak of, AH is relatively heavy weight and > isn't always available on routers today. Talking to routing equipment > implementors (two vendors) there was a feeling that AO will arrive > shortly while AH is still too complex (for router deployments) and is > not going to be available in all of the platforms which will require > this functionality. > > On the server side of the equation there is no support for AO, some > for AH (which is nice actually). In short, we don't have a good > direction or belief that there is going to be one with respect to AO > in the near term. > > What options are there for this problem? How can we motivate vendors > with a spec that clearly has problems in implementation (no AO, not > full reach for AH)? Are there folks who are tracking availability of > AO? Could we start with something like: > > MAY support authentication of nodes with TCP-MD5 > MAY support authentication of nodes with IPSEC-AH > MUST support authentication of nodes with TCP-AO > > Or is mentioning TCP-MD5 verboten? Essentially it seems that the WG > has gotten wedged and is looking for some guidance from the Security > Area Directors :) > > -chris > From uma.chunduri@ericsson.com Fri Jun 3 13:24:06 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C10E07B3; Fri, 3 Jun 2011 13:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRi-GL4n+Ape; Fri, 3 Jun 2011 13:24:05 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 74B00E07AB; Fri, 3 Jun 2011 13:24:05 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p53KNodE021005; Fri, 3 Jun 2011 15:23:51 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 3 Jun 2011 16:23:45 -0400 From: Uma Chunduri To: Christopher Morrow , "sidr@ietf.org" , "sidr-chairs@ietf.org" , Sean Turner , "stephen.farrell@cs.tcd.ie" Date: Fri, 3 Jun 2011 16:23:44 -0400 Thread-Topic: [sidr] WGLC draft-sidr-rpki-rtr - take 2? Thread-Index: AcwiDZxR5nfH7zXzRXybjGKcwupOPAAGwNrg Message-ID: References: <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> 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 Cc: Rob Austein Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 20:24:06 -0000 > Over here in the SIDR WG we've been batting around a problem related=20 > to secure authentication of TCP endpoints, essentially how can we=20 > specify TODAY something to use in implementations of a (we think)=20 > important protocol when the underlying technology we need isn't=20 > available (TCP-AO). Some background: > > Looking to close the issue of MD5/TCP-AO/SSH/etc out again, The doc: > > > Seems to be stuck on this text: > > (From the abstract) > " This document describes a protocol to deliver validated > =A0 prefix origin data to routers over ssh." > > or a more in depth version of that text at: > > =A0o tcp-AO > =A0o ipsec AH > > one deprecated method is available as well: > =A0o tcp-MD5 > > Of the two approved methods, AO has no implementations on the routers=20 > (yet), nor server side to speak of, AH is relatively heavy weight and=20 > isn't always available on routers today. Talking to routing equipment=20 > implementors (two vendors) there was a feeling that AO will arrive=20 > shortly while AH is still too complex (for router deployments) and is=20 > not going to be available in all of the platforms which will require=20 > this functionality. > > On the server side of the equation there is no support for AO, some=20 > for AH (which is nice actually). In short, we don't have a good=20 > direction or belief that there is going to be one with respect to AO=20 > in the near term. > > What options are there for this problem? How can we motivate vendors=20 > with a spec that clearly has problems in implementation (no AO, not=20 > full reach for AH)? Are there folks who are tracking availability of=20 > AO? Could we start with something like: > > MAY support authentication of nodes with TCP-MD5 MAY support=20 > authentication of nodes with IPSEC-AH MUST support authentication of=20 > nodes with TCP-AO True, privacy through SSH is overkill but strong AUTH is *critical*, I feel= : - TCP-MD5 should not be considered (as it is any ways deprecated and it'= s MD5) - TCP-AO has only slight advantage as it has less overhead than ipsec-AH= even when=20 deployed with manual keys - but it's better if it is "MUST support authentication of nodes with TC= P-AO or ipsec-AH" because as both support=20 - strong auth algos - algo agility - can be deployed with manual and auto key management=20 (auto key probably required eventually, once with lot of connec= tions at=20 cache/global RPKI/server side and for automatic key=20 changes periodically) - key changes for existing sessions =20 One would get flexibility with this. Also Section 7 (page 16) "It is assumed that the router and cache have exchanged keys out of ban= d by some reasonably secured means" This will be still applicable but only if TCP-AO/ipsce-AH are deployed = with manual keys. 2 cents, -Uma =20 From christopher.morrow@gmail.com Fri Jun 3 13:41: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 4CF1EE07AB for ; Fri, 3 Jun 2011 13:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.979 X-Spam-Level: X-Spam-Status: No, score=-102.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpG96+2u+MlD for ; Fri, 3 Jun 2011 13:41:44 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 87BDAE0670 for ; Fri, 3 Jun 2011 13:41:44 -0700 (PDT) Received: by pzk5 with SMTP id 5so1061587pzk.31 for ; Fri, 03 Jun 2011 13:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oo7JhNfqgdFg5UrNTov1rVEdcAEr44oMYlr6UfLOJI0=; b=I+aun+hfn6UD9mqxETl05gVvlszdN2j0MGYL1Tu4W0Ik0oAVrM3VdfQ0uzmO0mekj5 67mCL6xYevNpcPdM5ykDEBxwgohYXynYF/Xtvze+pap7RunCYBc5BxvdxCMEaWfLAP67 mUG7k0nhvnpF3E4SutHyD9Wu657s2+DXy9Sq8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LUQkBRJQx8xU06Jhzw5KISl3BnxVrCQF8v/qVo8PyuWTycxsYq8azWh/zQpccK2Xu9 K+tsgzn/B7CWFSOTzLJ345RZwJJiGGgiKymJaL95fdYykEtlgLN1QEaopQ6SrfvEPDqN WWTVqX5XI+sGhHhn4s3dRWrkjr0jK/omBt3Jo= MIME-Version: 1.0 Received: by 10.68.35.102 with SMTP id g6mr946733pbj.16.1307133704250; Fri, 03 Jun 2011 13:41:44 -0700 (PDT) Received: by 10.68.56.133 with HTTP; Fri, 3 Jun 2011 13:41:44 -0700 (PDT) In-Reply-To: <88ABF155-348D-4FCB-B8DD-D257FC98689A@cisco.com> References: <88ABF155-348D-4FCB-B8DD-D257FC98689A@cisco.com> Date: Fri, 3 Jun 2011 16:41:44 -0400 Message-ID: From: Christopher Morrow To: Roque Gagliano Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] Answering a question at the mic in Prague: Peter Lothberg's "what about vpn providers?" X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 03 Jun 2011 20:41:45 -0000 On Fri, Jun 3, 2011 at 6:08 AM, Roque Gagliano wrote: > Hi Chris, > Thank you for open this issue to the list. > From you email I did not get which is the security threat that you are > trying to address. Is it just "fat fingers"? That's a great question... which I hope Peter will clarify, but I think one stab at an answer may be: "Stop one VPN provider from announcing space inside a VPN that shouldn't be there." So, some of this is likely fat-fingers, yes... across vpn boundaries where RT's and such are not necessarily the same, and there is a level of indirection at play between end-users and providers, some assurance that the customer can have an impact on the provider (mis-)behaviour I think is good. Peter? > Also, I believe you may have a typo in your implementation comment as you > cannot represent the RT in a certificate as it is not supported in the X.= 509 > specification (i.e. RFC3779) . So, I guess you were referring to modify t= he > ROA signed object to include the RT information. =A0In this case, what if= you I'd defer to someone who's profession is certs... (dr. kent? as a simple first guess) The thinking may have been to overload some other field in a EECert with RT content. That's likely a poor choice long term though ("lets use that spare bit in the ip header for pet-project-123!!" ...no) > just define a new signed object for VPN interconnections? We do not chang= e what would the interconnection object say/contain? > anything of what has be done up to now and we do not need to wait for any > roll-over. Then, each RP can store their locally define objects, use loca= l Roll over would only be required if this idea has merit, work is done to flesh it out and roll it out... in fact, it's only REALLY required if there are networks that would share VPN and "public" routing data, but that's neither here nor there right now. > policies (based on the ta-local draft) on its validators =A0and an extens= ion this requires each RP to have a local-TA configured for each VPN peer they talk to, no? I imagine that's goign to get complicated, and there's no simple guarantee that RTA in VPNA is the same as RTA in VPNB... so some map still has to happen (I think). > to the rtr protocol to transmit the RTs-prefixes to the BGP speakers. > Finally, please note that the current agility draft only addresses the > process for an algorithm suite change. Not for a change in the certificat= e > profile or any change in basic RPKI certificates or signed objects. Sure, but in the short term that would look almost like an algorithm change... or close enough for gov't work :) (discussion on list, details later) THanks for the read so far though :) -chris > Roque. > > On Jun 3, 2011, at 6:52 AM, Christopher Morrow wrote: > > Peter asked at the mic about how SIDR/BGPSEC could/would/etc deal with > VPN providers. I believe he meant something like MPLS VPN (RFC2547) > providers. I think that after some discussion about this with a few of > the document authors a summary of direction is: > > A set of questions about the problem space (again, assuming 2547-type > vpn deployment was the target of the question) > =A0o =A0=93what are you trying to secure?=94 > =A0=A0=A0=A0=A0i =A0vpn-provider to vpn-provider routing domain? > =A0=A0=A0=A0=A0ii =A0single-customer routing domain? > =A0o =A0not all customer routes are picked up by BGP in VPN scenarios > =A0=A0=A0=A0=A0i ospf/rip/eigrp/static routes > =A0=A0=A0=A0=A0ii lack of origin by the AS-Owner (ROAs would be required = to the > VPN provider, not a problem) > =A0o =A0not all customers have unique ip space across a single provider, > never mind multiple providers > =A0o =A0not all customers have unique ASNs across a single provider > =A0o =A0route-targets are only unique across a single vpn-provider > > > Of the above the only open question was as to what the scope of > =91secure=92 would be, we decided (in the discussion) that the scope we > would apply to the discussion is the: > =A0vpn-provider to vpn-provider security > > Given a scenario that looks like: > vpn-provider BOB with vpns: > A - route-target A - prefix 10.0.0.0/8 > B - route-target B - prefix 10.0.0.0/8 > C - route-target C - prefix 10.0.0.0/8 > > vpn-provider SALLY with vpns: > Z - route-target Z - prefix 10.0.0.0/8 > Y - route-target Y - prefix 10.0.0.0/8 > X - route-target X - prefix 10.0.0.0/8 > > Each provider has their own Trust Anchor: TA-BOB and TA-SALLY > these Trust Anchors contain (notionally) the following routing/roa > information: > TA-BOB: > =A0=A0=A0=A0AS-A:RT-A:10.0.0.0/8 > =A0=A0=A0=A0AS-B:RT-B:10.0.0.0/8 > =A0=A0=A0=A0AS-C:RT-C:10.0.0.0/8 > =A0=A0=A0=A0AS-D:RT-D:10.0.0.0/8 > > TA-SALLY: > =A0=A0=A0=A0AS-Z:RT-Z:10.0.0.0/8 > =A0=A0=A0=A0AS-Y:RT-Y:10.0.0.0/8 > =A0=A0=A0=A0AS-X:RT-X:10.0.0.0/8 > =A0=A0=A0AS-D:RT-V:10.0.0.0/8 > > > The two vpn-providers are connected together in order that their > customers can have a vpn extending across both networks, for the case > where a single provider (BOB) needs to extend their VPN service > reach/territory into a region where they do not have (for reasons > unimportant to the discussion) presence/facilities. If the intent is > to secure vpn-provider to vpn-provider route exchange, some service > must exist that translates: > AS-D:RT-D:10.0.0.0/8 vs AS-D:RT-V:10.0.0.0/8 > > A proposed mapping service would accomplish this translation between > the vpn-providers that participate in the single-customer, > multi-provider network scenario. An open question, is whether this is > necessary in a single provider deployment. > > It seems that the mechanisms being proposed for BGPSEC can be extended > to support the vpn-provider solution with the addition of a > RouteTarget extension to the ROA End Entity Cert. This would require > updating the certificate profile [draft-ietf-sidr-cp], and running the > algorithm change process [draft-ietf-sidr-algorithm-agility], in order > to flood proper certificates out with the new extension. We could, of > course, choose to change the cert profile today (except that it is in > rfc editor queue at this time) and decide that RT=3D0 (for instance) is > the =93Internet=94. It seems that the other mechanisms (mapping service) > still need to be better defined, so revising the certificate profile > later shouldn=92t be a show stopper. > > I hope the above helps some with Peter's question? Also, I'm really > just the note taker on the above, the authors were more involved with > the thought process (which makes sense to me, I do admit). Thanks for > your indulgence! > > -Chris > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > From Sandra.Murphy@cobham.com Fri Jun 3 13:43:02 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388A8E06BF for ; Fri, 3 Jun 2011 13:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.726 X-Spam-Level: X-Spam-Status: No, score=-102.726 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRVjEf0xLp7f for ; Fri, 3 Jun 2011 13:43:01 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2B40BE0670 for ; Fri, 3 Jun 2011 13:43:01 -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 p53Kgo9H020406; Fri, 3 Jun 2011 15:42:51 -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 p53KgpUn014580; Fri, 3 Jun 2011 15:42:51 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.134]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Jun 2011 16:42:51 -0400 Date: Fri, 3 Jun 2011 16:42:50 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Uma Chunduri In-Reply-To: Message-ID: References: <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 03 Jun 2011 20:42:51.0078 (UTC) FILETIME=[CE3BFE60:01CC222E] Cc: "stephen.farrell@cs.tcd.ie" , "sidr@ietf.org" Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 20:43:02 -0000 On Fri, 3 Jun 2011, Uma Chunduri wrote: > > .... > > True, privacy through SSH is overkill but strong AUTH is *critical*, I feel: > - TCP-MD5 should not be considered (as it is any ways deprecated and it's MD5) > - TCP-AO has only slight advantage as it has less overhead than ipsec-AH even when > deployed with manual keys > - but it's better if it is "MUST support authentication of nodes with TCP-AO or ipsec-AH" because Just to be sure: Did you understand the part about implementations of TCP-AO and ipsec-AH not being available at present? I.e., you recognize this forces a delay in implementation of the protocol (and accept the consequent impact on deployment of the RPKI)? --Sandy, speaking as wg co-chair > as both support > - strong auth algos > - algo agility > - can be deployed with manual and auto key management > (auto key probably required eventually, once with lot of connections at > cache/global RPKI/server side and for automatic key > changes periodically) > - key changes for existing sessions > > One would get flexibility with this. > Also Section 7 (page 16) > "It is assumed that the router and cache have exchanged keys out of band by some reasonably secured means" > This will be still applicable but only if TCP-AO/ipsce-AH are deployed with manual keys. > > 2 cents, > -Uma > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From jgs@juniper.net Fri Jun 3 13:53: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 74365E07C8; Fri, 3 Jun 2011 13:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uK1+nwOiVeqE; Fri, 3 Jun 2011 13:53:40 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id A2327E0670; Fri, 3 Jun 2011 13:53:35 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTelJyhg9B+d2fC1Bjm5S/5BiK8IU5xy1@postini.com; Fri, 03 Jun 2011 13:53:39 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 3 Jun 2011 13:53:30 -0700 From: John Scudder To: Uma Chunduri Date: Fri, 3 Jun 2011 13:53:28 -0700 Thread-Topic: [sidr] WGLC draft-sidr-rpki-rtr - take 2? Thread-Index: AcwiMErQWDGCNIGNSASnLL88Mu7B7A== Message-ID: <46A19095-4B42-4470-9143-9305D6F7EF04@juniper.net> References: <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> 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: Rob Austein , "sidr-chairs@ietf.org" , "sidr@ietf.org" , "stephen.farrell@cs.tcd.ie" Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 20:53:40 -0000 On Jun 3, 2011, at 4:23 PM, Uma Chunduri wrote: > True, privacy through SSH is overkill but strong AUTH is *critical*, I fe= el: > - TCP-MD5 should not be considered (as it is any ways deprecated and it= 's MD5) What specifically do you mean by "should not be considered"? =20 > - TCP-AO has only slight advantage as it has less overhead than ipsec-A= H even when=20 > deployed with manual keys > - but it's better if it is "MUST support authentication of nodes with T= CP-AO or ipsec-AH" because The drawback of saying "MUST support A or B" is that two implementations ma= y be formally compliant yet not interoperable. That would obviously be und= esirable (to say the least). IMO the spec should pick one mandatory one wh= ile leaving open the option to support others. --John= From uma.chunduri@ericsson.com Fri Jun 3 14:28: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 A1F5AE07E0 for ; Fri, 3 Jun 2011 14:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.014 X-Spam-Level: X-Spam-Status: No, score=-6.014 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GZ5UvyYawxx for ; Fri, 3 Jun 2011 14:28:53 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 00F02E07D4 for ; Fri, 3 Jun 2011 14:28:51 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p53LSLqc031617; Fri, 3 Jun 2011 16:28:38 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 3 Jun 2011 17:28:29 -0400 From: Uma Chunduri To: Sandra Murphy Date: Fri, 3 Jun 2011 17:28:27 -0400 Thread-Topic: [sidr] WGLC draft-sidr-rpki-rtr - take 2? Thread-Index: AcwiLt/WWgxuU3zlTy+Cx17eu5auSwABTLRw Message-ID: References: <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> 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: "stephen.farrell@cs.tcd.ie" , "sidr@ietf.org" Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 21:28:54 -0000 =20 -----Original Message----- From: Sandra Murphy [mailto:Sandra.Murphy@sparta.com]=20 Sent: Friday, June 03, 2011 1:43 PM To: Uma Chunduri Cc: sidr@ietf.org; Sean Turner; stephen.farrell@cs.tcd.ie Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? On Fri, 3 Jun 2011, Uma Chunduri wrote: > > .... > > True, privacy through SSH is overkill but strong AUTH is *critical*, I fe= el: > - TCP-MD5 should not be considered (as it is any ways deprecated and it= 's MD5) > - TCP-AO has only slight advantage as it has less overhead than ipsec-A= H even when > deployed with manual keys > - but it's better if it is "MUST support authentication of nodes=20 > with TCP-AO or ipsec-AH" because Just to be sure: Did you understand the part about implementations of TCP-AO and ipsec-AH no= t being available at present? I.e., you recognize this forces a delay in implementation of the protocol (= and accept the consequent impact on deployment of the RPKI)? [Uma] Yes, I did. Even though operators don't like ipsec-AH today, it is s= till deployed for OSPFv3 protection as that=20 (of course now there are other drafts to mitigate complexity with reasonabl= e trade-off). Problem with MD5 is, it can present the *weakest* link for the whole RPKI i= nfa. At least new infrastructure like RPKI should avoid deprecated stuff. -Uma --Sandy, speaking as wg co-chair > as both support > - strong auth algos > - algo agility > - can be deployed with manual and auto key management > (auto key probably required eventually, once with lot of conne= ctions at > cache/global RPKI/server side and for automatic key > changes periodically) > - key changes for existing sessions > > One would get flexibility with this. > Also Section 7 (page 16) > "It is assumed that the router and cache have exchanged keys out of ba= nd by some reasonably secured means" > This will be still applicable but only if TCP-AO/ipsce-AH are deployed= with manual keys. > > 2 cents, > -Uma > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From uma.chunduri@ericsson.com Fri Jun 3 14:33: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 87FE2E07D4; Fri, 3 Jun 2011 14:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.067 X-Spam-Level: X-Spam-Status: No, score=-6.067 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIdQecZf2wH4; Fri, 3 Jun 2011 14:33:18 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id B9429E07CA; Fri, 3 Jun 2011 14:33:17 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p53LWi5u016170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Jun 2011 16:33:13 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 3 Jun 2011 17:33:03 -0400 From: Uma Chunduri To: John Scudder Date: Fri, 3 Jun 2011 17:33:01 -0400 Thread-Topic: [sidr] WGLC draft-sidr-rpki-rtr - take 2? Thread-Index: AcwiMErQWDGCNIGNSASnLL88Mu7B7AABPUNQ Message-ID: References: <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> <46A19095-4B42-4470-9143-9305D6F7EF04@juniper.net> In-Reply-To: <46A19095-4B42-4470-9143-9305D6F7EF04@juniper.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: Rob Austein , "sidr-chairs@ietf.org" , "sidr@ietf.org" , "stephen.farrell@cs.tcd.ie" Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 21:33:19 -0000 =20 -----Original Message----- From: John Scudder [mailto:jgs@juniper.net]=20 Sent: Friday, June 03, 2011 1:53 PM To: Uma Chunduri Cc: Christopher Morrow; sidr@ietf.org; sidr-chairs@ietf.org; Sean Turner; s= tephen.farrell@cs.tcd.ie; Rob Austein Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? On Jun 3, 2011, at 4:23 PM, Uma Chunduri wrote: > True, privacy through SSH is overkill but strong AUTH is *critical*, I fe= el: > - TCP-MD5 should not be considered (as it is any ways deprecated and=20 > it's MD5) What specifically do you mean by "should not be considered"? =20 [Uma] I responded in other e-mail. No protection is better than weak protec= tion. > - TCP-AO has only slight advantage as it has less overhead than ipsec-A= H even when=20 > deployed with manual keys > - but it's better if it is "MUST support authentication of nodes=20 > with TCP-AO or ipsec-AH" because The drawback of saying "MUST support A or B" is that two implementations ma= y be formally compliant yet not interoperable. That would obviously be und= esirable (to say the least). IMO the spec should pick one mandatory one wh= ile leaving open the option to support others. [Uma] True. Then probably TCP-AO. But ipsec-AH can give tough challenge as = it's relatively=20 old and more readily available than AO (also understood better as it i= s already deployed=20 else where). -Uma --John= From christopher.morrow@gmail.com Fri Jun 3 18:11: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 BF71DE06C7 for ; Fri, 3 Jun 2011 18:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zd7qCLyVKhWO for ; Fri, 3 Jun 2011 18:11:31 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B56DCE06C4 for ; Fri, 3 Jun 2011 18:11:30 -0700 (PDT) Received: by eye13 with SMTP id 13so1101100eye.31 for ; Fri, 03 Jun 2011 18:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5sNVVaMnwvKQIy3uOjztmkAsHz/ClV7VMygY/A4XYKE=; b=htaUC3jOeGq7Em+TvQETbaqPFge6ORTxNs3Ba7B545fUX/EWc6vjXGqNB2lvWmQaCF Fg2HzjWN0MTruWJjNmE809KchGjUy/m3bJ9/iUltC4F2XOxgKRBcq13F5XKfp7TV77z8 QxAFsUfRgcd00ywkY6VbmeiO84DeAfBBqscU8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=AvGU7uzUmmqnejwE+XdfcjM7h9+GVdF6nfREuIwSbKemXQvZBeDRp+HiFdnZw8cp6L 8MP7sY+uJagQpqMCnnUFPC+LKbz7KIDwTahJ3SQdU/LgibjnK0zaZBHkJHZl9Ab2k8yZ hDBxz1fKyfoLlGNBBRXMm6CAHA2g+j21KARUs= MIME-Version: 1.0 Received: by 10.213.26.82 with SMTP id d18mr984398ebc.123.1307149889584; Fri, 03 Jun 2011 18:11:29 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.213.20.71 with HTTP; Fri, 3 Jun 2011 18:11:29 -0700 (PDT) In-Reply-To: References: <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> Date: Fri, 3 Jun 2011 21:11:29 -0400 X-Google-Sender-Auth: esj6wHmnWV7Qs9JFFlnaVtmZZDE Message-ID: From: Christopher Morrow To: Uma Chunduri Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sidr@ietf.org" , Sandra Murphy , "stephen.farrell@cs.tcd.ie" Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 01:11:31 -0000 On Fri, Jun 3, 2011 at 5:28 PM, Uma Chunduri wr= ote: > > > -----Original Message----- > From: Sandra Murphy [mailto:Sandra.Murphy@sparta.com] > Sent: Friday, June 03, 2011 1:43 PM > To: Uma Chunduri > Cc: sidr@ietf.org; Sean Turner; stephen.farrell@cs.tcd.ie > Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? > > > On Fri, 3 Jun 2011, Uma Chunduri wrote: > >> >> > .... > >> >> True, privacy through SSH is overkill but strong AUTH is *critical*, I f= eel: >> =A0 - TCP-MD5 should not be considered (as it is any ways deprecated and= it's MD5) >> =A0 - TCP-AO has only slight advantage as it has less overhead than ipse= c-AH even when >> =A0 =A0 deployed with manual keys >> =A0 - but it's better if it is "MUST support authentication of nodes >> with TCP-AO or ipsec-AH" because > > Just to be sure: > > Did you understand the part about implementations of TCP-AO and ipsec-AH = not being available at present? > > I.e., you recognize this forces a delay in implementation of the protocol= (and accept the consequent impact on deployment of the RPKI)? > > [Uma] Yes, I did. Even though operators don't like =A0ipsec-AH today, it = is still deployed for OSPFv3 protection as that > (of course now there are other drafts to mitigate complexity with reasona= ble trade-off). > So, speaking as just another guy on the bus here... it's not about 'dont like it' it's about "THE CODE ON THE ROUTER DOES NOT DO IPSEC" Keep in mind that a router is not a generic CPU + intel ethernet PCI card, and often the OS on it is optomized for a particular duty, in large iron routers it's NOT ipsec. > Problem with MD5 is, it can present the *weakest* link for the whole RPKI= infa. > At least new infrastructure like RPKI should avoid deprecated =A0stuff. exactly how is MD5 the weakest link here? some particular words about the threat model + ability to subvert a running session which ships a few megabytes/minute around would be in order here. -chris > -Uma > > > --Sandy, speaking as wg co-chair > > >> =A0 =A0 as both support >> =A0 =A0 =A0 =A0 =A0 - strong auth algos >> =A0 =A0 =A0 =A0 =A0 - algo agility >> =A0 =A0 =A0 =A0 =A0 - can be deployed with manual and auto key managemen= t >> =A0 =A0 =A0 =A0 =A0 =A0(auto key probably required eventually, once with= lot of connections at >> =A0 =A0 =A0 =A0 =A0 =A0 cache/global RPKI/server side and for automatic = key >> =A0 =A0 =A0 =A0 =A0 =A0 changes periodically) >> =A0 =A0 =A0 =A0 =A0 - key changes for existing sessions >> >> =A0 =A0One would get flexibility with this. >> =A0 =A0Also Section 7 (page 16) >> =A0 =A0"It is assumed that the router and cache have exchanged keys out = of band by some reasonably secured means" >> =A0 =A0This will be still applicable but only if TCP-AO/ipsce-AH are dep= loyed with manual keys. >> >> 2 cents, >> -Uma >> >> >> _______________________________________________ >> 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 christopher.morrow@gmail.com Fri Jun 3 18:12: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 82945E070E; Fri, 3 Jun 2011 18:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Q5zme7zJofg; Fri, 3 Jun 2011 18:12:20 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8F511E06FA; Fri, 3 Jun 2011 18:12:16 -0700 (PDT) Received: by ewy19 with SMTP id 19so1099573ewy.31 for ; Fri, 03 Jun 2011 18:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bf9kSyef+9eR/w2FT/z6iPJC1aZJUFKJDf93e8pvjIs=; b=oA++J7htFfTqsWCBKGuGkruMf5l5F+lOKLZzsk64nGv4pA8BMxvGfd7DeMjwEtjOue wHxSNvWF9syjaXydgvU0QjQ4DzfPDKTQ3b9YMVu5Vl9DvoieuCPXaYz+tAOeitGGQebb pLrYwQqS9R1Kxl/ThSehBgD+wssaHojFsFnpI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=DNwgxCrq/a0QmY/pVZ/4XjCoLtKK74vOj7RhHRtfz1qyQaXFHL+LI8CnR2iRsJNTag cfGk/tsOHfVUT4G00/+2zoxlKXhiG9VSFmJjyn3gEE6NLqmyys2+iX1G1q1mss0+FaHH 4PU/DX5dS0U72JGFfeSLXUGElYS9xtX3dsWrI= MIME-Version: 1.0 Received: by 10.213.99.81 with SMTP id t17mr988936ebn.85.1307149935596; Fri, 03 Jun 2011 18:12:15 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.213.20.71 with HTTP; Fri, 3 Jun 2011 18:12:15 -0700 (PDT) In-Reply-To: References: <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> <46A19095-4B42-4470-9143-9305D6F7EF04@juniper.net> Date: Fri, 3 Jun 2011 21:12:15 -0400 X-Google-Sender-Auth: ohfYEl9rdzDD1Ia4LFTeQdCbktA Message-ID: From: Christopher Morrow To: Uma Chunduri Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rob Austein , "sidr-chairs@ietf.org" , "sidr@ietf.org" , John Scudder , "stephen.farrell@cs.tcd.ie" Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 01:12:20 -0000 On Fri, Jun 3, 2011 at 5:33 PM, Uma Chunduri wr= ote: > > > -----Original Message----- > From: John Scudder [mailto:jgs@juniper.net] > Sent: Friday, June 03, 2011 1:53 PM > To: Uma Chunduri > Cc: Christopher Morrow; sidr@ietf.org; sidr-chairs@ietf.org; Sean Turner;= stephen.farrell@cs.tcd.ie; Rob Austein > Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? > > On Jun 3, 2011, at 4:23 PM, Uma Chunduri wrote: >> True, privacy through SSH is overkill but strong AUTH is *critical*, I f= eel: >> =A0 - TCP-MD5 should not be considered (as it is any ways deprecated and >> it's MD5) > > What specifically do you mean by "should not be considered"? > > [Uma] I responded in other e-mail. No protection is better than weak prot= ection. to keep the thread clear: "Define Weak" -chris >> =A0 - TCP-AO has only slight advantage as it has less overhead than ipse= c-AH even when >> =A0 =A0 deployed with manual keys >> =A0 - but it's better if it is "MUST support authentication of nodes >> with TCP-AO or ipsec-AH" because > > The drawback of saying "MUST support A or B" is that two implementations = may be formally compliant yet not interoperable. =A0That would obviously be= undesirable (to say the least). =A0IMO the spec should pick one mandatory = one while leaving open the option to support others. > > [Uma] True. Then probably TCP-AO. But ipsec-AH can give tough challenge a= s it's relatively > =A0 =A0 old and more readily available than AO (also understood better as= it is already deployed > =A0 =A0 else where). > -Uma > > --John From uma.chunduri@ericsson.com Fri Jun 3 19:15:57 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499E9E0709 for ; Fri, 3 Jun 2011 19:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.111 X-Spam-Level: X-Spam-Status: No, score=-6.111 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+t-kt01ASmf for ; Fri, 3 Jun 2011 19:15:48 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 254BCE06EC for ; Fri, 3 Jun 2011 19:15:47 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p542FeJL016777; Fri, 3 Jun 2011 21:15:41 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 3 Jun 2011 22:15:34 -0400 From: Uma Chunduri To: Christopher Morrow Date: Fri, 3 Jun 2011 22:15:33 -0400 Thread-Topic: [sidr] WGLC draft-sidr-rpki-rtr - take 2? Thread-Index: AcwiVFcUUDhf+ZFfR7asFKma/QyrggABY7hw Message-ID: References: <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> 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 Cc: "sidr@ietf.org" , Sandra Murphy , "stephen.farrell@cs.tcd.ie" Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 02:15:57 -0000 =20 -----Original Message----- From: christopher.morrow@gmail.com [mailto:christopher.morrow@gmail.com] On= Behalf Of Christopher Morrow Sent: Friday, June 03, 2011 6:11 PM To: Uma Chunduri Cc: Sandra Murphy; stephen.farrell@cs.tcd.ie; sidr@ietf.org Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? On Fri, Jun 3, 2011 at 5:28 PM, Uma Chunduri wr= ote: > > > -----Original Message----- > From: Sandra Murphy [mailto:Sandra.Murphy@sparta.com] > Sent: Friday, June 03, 2011 1:43 PM > To: Uma Chunduri > Cc: sidr@ietf.org; Sean Turner; stephen.farrell@cs.tcd.ie > Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? > > > On Fri, 3 Jun 2011, Uma Chunduri wrote: > >> >> > .... > >> >> True, privacy through SSH is overkill but strong AUTH is *critical*, I f= eel: >> =A0 - TCP-MD5 should not be considered (as it is any ways deprecated=20 >> and it's MD5) >> =A0 - TCP-AO has only slight advantage as it has less overhead than=20 >> ipsec-AH even when >> =A0 =A0 deployed with manual keys >> =A0 - but it's better if it is "MUST support authentication of nodes=20 >> with TCP-AO or ipsec-AH" because > > Just to be sure: > > Did you understand the part about implementations of TCP-AO and ipsec-AH = not being available at present? > > I.e., you recognize this forces a delay in implementation of the protocol= (and accept the consequent impact on deployment of the RPKI)? > > [Uma] Yes, I did. Even though operators don't like =A0ipsec-AH today, it= =20 > is still deployed for OSPFv3 protection as that (of course now there are = other drafts to mitigate complexity with reasonable trade-off). > So, speaking as just another guy on the bus here... it's not about 'dont li= ke it' it's about "THE CODE ON THE ROUTER DOES NOT DO IPSEC" Keep in mind that a router is not a generic CPU + intel ethernet PCI card, = and often the OS on it is optomized for a particular duty, in large iron ro= uters it's NOT ipsec. > Problem with MD5 is, it can present the *weakest* link for the whole RPKI= infa. > At least new infrastructure like RPKI should avoid deprecated =A0stuff. exactly how is MD5 the weakest link here? some particular words about the t= hreat model + ability to subvert a running session which ships a few megaby= tes/minute around would be in order here. [Uma]=20 1. Wang, X., H. Yu, "How to break MD5 and other hash functions", Proc. IACR Eurocrypt 2005, Denmark 2. RFC 4270 3. long back even OSPF, ISIS etc.. moved away from MD5 4. ... For that matter SHA1 is getting deprecated http://securitymusings.com/artic= le/1587/algorithm-and-key-length-deprecation =20 Getting public keys from a server with a deprecated auth mechanism to veri= fy RSA signature?=20 it's obscure..and not sure why it's not considered weak. Well, one can still use and design systems around this if this is still see= n adequate. -Uma -chris > -Uma > > > --Sandy, speaking as wg co-chair > > >> =A0 =A0 as both support >> =A0 =A0 =A0 =A0 =A0 - strong auth algos >> =A0 =A0 =A0 =A0 =A0 - algo agility >> =A0 =A0 =A0 =A0 =A0 - can be deployed with manual and auto key managemen= t >> =A0 =A0 =A0 =A0 =A0 =A0(auto key probably required eventually, once with= lot of=20 >> connections at >> =A0 =A0 =A0 =A0 =A0 =A0 cache/global RPKI/server side and for automatic = key >> =A0 =A0 =A0 =A0 =A0 =A0 changes periodically) >> =A0 =A0 =A0 =A0 =A0 - key changes for existing sessions >> >> =A0 =A0One would get flexibility with this. >> =A0 =A0Also Section 7 (page 16) >> =A0 =A0"It is assumed that the router and cache have exchanged keys out = of band by some reasonably secured means" >> =A0 =A0This will be still applicable but only if TCP-AO/ipsce-AH are dep= loyed with manual keys. >> >> 2 cents, >> -Uma >> >> >> _______________________________________________ >> 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 christopher.morrow@gmail.com Fri Jun 3 19:26:37 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70EAE06EC for ; Fri, 3 Jun 2011 19:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7YYIWlM0fcr for ; Fri, 3 Jun 2011 19:26:36 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id BB2A0E0752 for ; Fri, 3 Jun 2011 19:26:36 -0700 (PDT) Received: by pxi20 with SMTP id 20so1801956pxi.27 for ; Fri, 03 Jun 2011 19:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jbyTYRTB4LwbN4k009aazvve60cJnRPz6fEk8ro/y+k=; b=XR4XHUwAV6mtinuLIavYInjUhFbyUdpWnc2CTRw5GXApxL+xO06k5huSSYQBFVYx/m oGA9J9soXJeGoIK4+Kr9jYCjVqPC3GDLGZdKGClS+4+jgX1f0sRn34DlATZ7Gs9McDec kFbDUMsJt26GMBh4fAfpsE/sHvITOVOKy+vlM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=PrKXjNteN3fNEHKtXVBUKp8CyIuxHSLjCor4lBZhh+VmiJotib4O0OcBX997SJpi00 cD7pNHdayLXfP+jcvjtItqk++CX8F75OiPj+utV59py9xrO5nwmcW0Jp5zIURzB+EB6a oRTJqmzqb6BOq6a9GU9utIv0YUh1Bwmkz8CQ0= MIME-Version: 1.0 Received: by 10.68.35.72 with SMTP id f8mr1106899pbj.83.1307154395408; Fri, 03 Jun 2011 19:26:35 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.68.44.106 with HTTP; Fri, 3 Jun 2011 19:26:35 -0700 (PDT) In-Reply-To: References: <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> Date: Fri, 3 Jun 2011 22:26:35 -0400 X-Google-Sender-Auth: S4NTtbQHB1EWoGvhKbj4B7ZzIx4 Message-ID: From: Christopher Morrow To: Uma Chunduri Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sidr@ietf.org" , Sandra Murphy , "stephen.farrell@cs.tcd.ie" Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 02:26:38 -0000 On Fri, Jun 3, 2011 at 10:15 PM, Uma Chunduri w= rote: > > > -----Original Message----- > From: christopher.morrow@gmail.com [mailto:christopher.morrow@gmail.com] = On Behalf Of Christopher Morrow > Sent: Friday, June 03, 2011 6:11 PM > To: Uma Chunduri > Cc: Sandra Murphy; stephen.farrell@cs.tcd.ie; sidr@ietf.org > Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? > > On Fri, Jun 3, 2011 at 5:28 PM, Uma Chunduri = wrote: >> >> >> -----Original Message----- >> From: Sandra Murphy [mailto:Sandra.Murphy@sparta.com] >> Sent: Friday, June 03, 2011 1:43 PM >> To: Uma Chunduri >> Cc: sidr@ietf.org; Sean Turner; stephen.farrell@cs.tcd.ie >> Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? >> >> >> On Fri, 3 Jun 2011, Uma Chunduri wrote: >> >>> >>> >> .... >> >>> >>> True, privacy through SSH is overkill but strong AUTH is *critical*, I = feel: >>> =A0 - TCP-MD5 should not be considered (as it is any ways deprecated >>> and it's MD5) >>> =A0 - TCP-AO has only slight advantage as it has less overhead than >>> ipsec-AH even when >>> =A0 =A0 deployed with manual keys >>> =A0 - but it's better if it is "MUST support authentication of nodes >>> with TCP-AO or ipsec-AH" because >> >> Just to be sure: >> >> Did you understand the part about implementations of TCP-AO and ipsec-AH= not being available at present? >> >> I.e., you recognize this forces a delay in implementation of the protoco= l (and accept the consequent impact on deployment of the RPKI)? >> >> [Uma] Yes, I did. Even though operators don't like =A0ipsec-AH today, it >> is still deployed for OSPFv3 protection as that (of course now there are= other drafts to mitigate complexity with reasonable trade-off). >> > > So, speaking as just another guy on the bus here... it's not about 'dont = like it' it's about "THE CODE ON THE ROUTER DOES NOT DO IPSEC" > > Keep in mind that a router is not a generic CPU + intel ethernet PCI card= , and often the OS on it is optomized for a particular duty, in large iron = routers it's NOT ipsec. > >> Problem with MD5 is, it can present the *weakest* link for the whole RPK= I infa. >> At least new infrastructure like RPKI should avoid deprecated =A0stuff. > > exactly how is MD5 the weakest link here? some particular words about the= threat model + ability to subvert a running session which ships a few mega= bytes/minute around would be in order here. > > [Uma] > > 1. Wang, X., H. Yu, "How to break MD5 and other hash > =A0 =A0 =A0 =A0 =A0 =A0 functions", Proc. IACR Eurocrypt 2005, Denmark depends on creating 2 items to hash I believe? shows that if you do the right thing for 2 very large items you create you can get a collision in some instances. not picking random bits off the wire, not relevant, move on. > 2. RFC 4270 talks about the above, not relevant. > > 3. long back even OSPF, ISIS etc.. moved away from MD5 fear, uncertainty, doubt. we aren't talking about a permanent use of md5, we're talking about: Use something that provides authentication/assurance NOW so we can move forward, knowing full well we'll change to the better/required solution when it's available in the right places. There's not a single AO implementation available today... it's DOA until there is. (frankly it's kind of a failure that there aren't widely deployed implementations of this... given all the time to invent it and all) > 4. ... > > For that matter SHA1 is getting deprecated http://securitymusings.com/art= icle/1587/algorithm-and-key-length-deprecation > again, not relevant. please find something relevant that's not just fear mongering. Or, alternately, find implementations of AO in the servers and routers that matter. (if there are AO implementations w00t! we all win, until then we spin) -chris > > Getting public keys from a server with a =A0deprecated auth mechanism to = verify RSA signature? > it's obscure..and not sure why it's not considered weak. > Well, one can still use and design systems around this if this is still s= een adequate. > > -Uma > > > > > -chris > > >> -Uma >> >> >> --Sandy, speaking as wg co-chair >> >> >>> =A0 =A0 as both support >>> =A0 =A0 =A0 =A0 =A0 - strong auth algos >>> =A0 =A0 =A0 =A0 =A0 - algo agility >>> =A0 =A0 =A0 =A0 =A0 - can be deployed with manual and auto key manageme= nt >>> =A0 =A0 =A0 =A0 =A0 =A0(auto key probably required eventually, once wit= h lot of >>> connections at >>> =A0 =A0 =A0 =A0 =A0 =A0 cache/global RPKI/server side and for automatic= key >>> =A0 =A0 =A0 =A0 =A0 =A0 changes periodically) >>> =A0 =A0 =A0 =A0 =A0 - key changes for existing sessions >>> >>> =A0 =A0One would get flexibility with this. >>> =A0 =A0Also Section 7 (page 16) >>> =A0 =A0"It is assumed that the router and cache have exchanged keys out= of band by some reasonably secured means" >>> =A0 =A0This will be still applicable but only if TCP-AO/ipsce-AH are de= ployed with manual keys. >>> >>> 2 cents, >>> -Uma >>> >>> >>> _______________________________________________ >>> 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 Fri Jun 3 22:54: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 E6BFBE06A7 for ; Fri, 3 Jun 2011 22:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.458 X-Spam-Level: X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fexFh-wotyQK for ; Fri, 3 Jun 2011 22:54:17 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 85218E06A6 for ; Fri, 3 Jun 2011 22:54:17 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QSjn3-0000vw-Rs; Sat, 04 Jun 2011 05:52:54 +0000 Date: Sat, 04 Jun 2011 07:52:51 +0200 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: References: <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org" , "stephen.farrell@cs.tcd.ie" Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 05:54:18 -0000 > Did you understand the part about implementations of TCP-AO and ipsec-AH > not being available at present? and not likely to be available on servers, one side of the connection, for a looooong time. after all, from the server stack hacker pov, where is the customer demand? randy From stephen.farrell@cs.tcd.ie Sat Jun 4 09:38: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 6AE7BE06C3 for ; Sat, 4 Jun 2011 09:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sJ1-Vz2vOI5 for ; Sat, 4 Jun 2011 09:38:39 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 30324E06C1 for ; Sat, 4 Jun 2011 09:38:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 78E84171C03; Sat, 4 Jun 2011 17:38:38 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1307205516; bh=/+WO3slI9HQl1C yMLmH8A0cM5kWUMWT7JYY7yipA3QA=; b=iz0fnAeXY5Sul8l9OB4JMnqWnhJuh9 kCdh8e+l93YYpnxO9t0qUOc1triUsO26pbeuWVOiOVmrAsIXpAzGBVsQdb9DTrKG CAHU7Hp0jROWGjXHMSZiGNj8mHkdkcw7+UTj7EThJxsVMSpBaaEALPMdS9n5M+ys W+3OJoqHH0Vs4dAGO9P0M3E8vVxwgFKwdJqOyVgR1TWbFP9lgAiUeIxRirjCyQhc uQfIF0C7Oh5w7Ple8FNWNP735kHDqzAvh/UXQdh6EuItTptANc85kGJyBGC1jyCV OYPnPzMzCM6uzTAo238X8+AG+uWrdO6ZPtwLdvAQTaiqtezOgnL+Vqxw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id U3YgL90s8hw2; Sat, 4 Jun 2011 17:38:36 +0100 (IST) Received: from [10.87.48.9] (unknown [86.45.54.169]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 7C663171D0D; Sat, 4 Jun 2011 17:38:35 +0100 (IST) Message-ID: <4DEA5F8B.8060804@cs.tcd.ie> Date: Sat, 04 Jun 2011 17:38:35 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Christopher Morrow References: <4DAF44AC.8060408@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 16:38:40 -0000 Hi all, Trying to catch up with you all here. >From reading the mail thread it seems to me that: - tcp-md5 is available but undesirable - tcp-ao is desirable but unavailable so far - ssh is available and slightly undesirable for performance reasons but desirable in security terms That would imply that an answer might be: MUST implement SSH; SHOULD implement TCP-AO and MUST/SHOULD prefer TCP-AO over SSH if both available Would that garner (rough) consensus? We really do want to deprecate tcp-md5. Cheers, Stephen. On 04/06/11 03:26, Christopher Morrow wrote: > On Fri, Jun 3, 2011 at 10:15 PM, Uma Chunduri wrote: >> >> >> -----Original Message----- >> From: christopher.morrow@gmail.com [mailto:christopher.morrow@gmail.com] On Behalf Of Christopher Morrow >> Sent: Friday, June 03, 2011 6:11 PM >> To: Uma Chunduri >> Cc: Sandra Murphy; stephen.farrell@cs.tcd.ie; sidr@ietf.org >> Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? >> >> On Fri, Jun 3, 2011 at 5:28 PM, Uma Chunduri wrote: >>> >>> >>> -----Original Message----- >>> From: Sandra Murphy [mailto:Sandra.Murphy@sparta.com] >>> Sent: Friday, June 03, 2011 1:43 PM >>> To: Uma Chunduri >>> Cc: sidr@ietf.org; Sean Turner; stephen.farrell@cs.tcd.ie >>> Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? >>> >>> >>> On Fri, 3 Jun 2011, Uma Chunduri wrote: >>> >>>> >>>> >>> .... >>> >>>> >>>> True, privacy through SSH is overkill but strong AUTH is *critical*, I feel: >>>> - TCP-MD5 should not be considered (as it is any ways deprecated >>>> and it's MD5) >>>> - TCP-AO has only slight advantage as it has less overhead than >>>> ipsec-AH even when >>>> deployed with manual keys >>>> - but it's better if it is "MUST support authentication of nodes >>>> with TCP-AO or ipsec-AH" because >>> >>> Just to be sure: >>> >>> Did you understand the part about implementations of TCP-AO and ipsec-AH not being available at present? >>> >>> I.e., you recognize this forces a delay in implementation of the protocol (and accept the consequent impact on deployment of the RPKI)? >>> >>> [Uma] Yes, I did. Even though operators don't like ipsec-AH today, it >>> is still deployed for OSPFv3 protection as that (of course now there are other drafts to mitigate complexity with reasonable trade-off). >>> >> >> So, speaking as just another guy on the bus here... it's not about 'dont like it' it's about "THE CODE ON THE ROUTER DOES NOT DO IPSEC" >> >> Keep in mind that a router is not a generic CPU + intel ethernet PCI card, and often the OS on it is optomized for a particular duty, in large iron routers it's NOT ipsec. >> >>> Problem with MD5 is, it can present the *weakest* link for the whole RPKI infa. >>> At least new infrastructure like RPKI should avoid deprecated stuff. >> >> exactly how is MD5 the weakest link here? some particular words about the threat model + ability to subvert a running session which ships a few megabytes/minute around would be in order here. >> >> [Uma] >> >> 1. Wang, X., H. Yu, "How to break MD5 and other hash >> functions", Proc. IACR Eurocrypt 2005, Denmark > > depends on creating 2 items to hash I believe? shows that if you do > the right thing for 2 very large items you create you can get a > collision in some instances. not picking random bits off the wire, not > relevant, move on. > >> 2. RFC 4270 > > talks about the above, not relevant. > >> >> 3. long back even OSPF, ISIS etc.. moved away from MD5 > > fear, uncertainty, doubt. > > we aren't talking about a permanent use of md5, we're talking about: > Use something that provides authentication/assurance NOW so we can > move forward, knowing full well we'll change to the better/required > solution when it's available in the right places. > > There's not a single AO implementation available today... it's DOA > until there is. (frankly it's kind of a failure that there aren't > widely deployed implementations of this... given all the time to > invent it and all) > >> 4. ... >> >> For that matter SHA1 is getting deprecated http://securitymusings.com/article/1587/algorithm-and-key-length-deprecation >> > > again, not relevant. > > please find something relevant that's not just fear mongering. Or, > alternately, find implementations of AO in the servers and routers > that matter. (if there are AO implementations w00t! we all win, until > then we spin) > > -chris > > >> >> Getting public keys from a server with a deprecated auth mechanism to verify RSA signature? >> it's obscure..and not sure why it's not considered weak. >> Well, one can still use and design systems around this if this is still seen adequate. >> >> -Uma >> >> >> >> >> -chris >> >> >>> -Uma >>> >>> >>> --Sandy, speaking as wg co-chair >>> >>> >>>> as both support >>>> - strong auth algos >>>> - algo agility >>>> - can be deployed with manual and auto key management >>>> (auto key probably required eventually, once with lot of >>>> connections at >>>> cache/global RPKI/server side and for automatic key >>>> changes periodically) >>>> - key changes for existing sessions >>>> >>>> One would get flexibility with this. >>>> Also Section 7 (page 16) >>>> "It is assumed that the router and cache have exchanged keys out of band by some reasonably secured means" >>>> This will be still applicable but only if TCP-AO/ipsce-AH are deployed with manual keys. >>>> >>>> 2 cents, >>>> -Uma >>>> >>>> >>>> _______________________________________________ >>>> 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 paul.hoffman@vpnc.org Sat Jun 4 13:06:06 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3651121F84D4 for ; Sat, 4 Jun 2011 13:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4loZMwIoN74 for ; Sat, 4 Jun 2011 13:06:05 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3C10621F84D3 for ; Sat, 4 Jun 2011 13:06:05 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p54K4Y8u081444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 4 Jun 2011 13:04:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Sat, 4 Jun 2011 13:04:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8FFA5FF6-317C-4433-8629-369563A384FD@vpnc.org> References: <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> To: Uma Chunduri , Stephen Farrell X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 20:06:06 -0000 On Jun 3, 2011, at 7:15 PM, Uma Chunduri wrote: > exactly how is MD5 the weakest link here? some particular words about = the threat model + ability to subvert a running session which ships a = few megabytes/minute around would be in order here. >=20 > [Uma]=20 >=20 > 1. Wang, X., H. Yu, "How to break MD5 and other hash > functions", Proc. IACR Eurocrypt 2005, Denmark > 2. RFC 4270 Wearing my co-author-of-4270 hat, let me state forcefully: invoking RFC = 4270 or *any* current published work on MD5 does not answer the question = of how MD5 is the weakest link here. Those are *unrelated* to an attack = on the integrity of communication in draft-sidr-rpki-rtr. Collision = attacks on MD5 and SHA-1 are, to date, unrelated to preimage attacks, = and it is preimage attacks that you care about. On Jun 4, 2011, at 9:38 AM, Stephen Farrell wrote: > Trying to catch up with you all here. >=20 >> =46rom reading the mail thread it seems to me that: >=20 > - tcp-md5 is available but undesirable > - tcp-ao is desirable but unavailable so far > - ssh is available and slightly undesirable for > performance reasons but desirable in > security terms >=20 > That would imply that an answer might be: >=20 > MUST implement SSH; SHOULD implement TCP-AO and > MUST/SHOULD prefer TCP-AO over SSH if both > available >=20 > Would that garner (rough) consensus? Another proposal that might be more likely to garner rough consensus = would be: MUST implement TCP-MD5 [RFC2385]; SHOULD implement TCP-AO = [RFC5925] (the official successor to TCP-MD5) as soon as possible; if = both parties in the protocol support TCP-AO, they SHOULD use TCP-AO and = SHOULD NOT use TCP-MD5. After we believe that there is lots of TCP-AO = adoption, we revise the document and remove TCP-MD5 as an option. > We really do want to deprecate tcp-md5. We already have: RFC 5925 obsoletes RFC 2385. The question is whether we = want to prevent new protocols from using it and instead force them to = use something else that doesn't work as well operationally while TCP-MD5 = is still considered safe. Saying "MUST implement SSH" is tantamount to = saying "many systems will run unprotected", which might be acceptable = until TCP-AO is deployed. However, using TCP-MD5, but only until TCP-AO = is deployed, seems like a better idea. --Paul Hoffman From touch@isi.edu Sat Jun 4 14:40: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 2A10421F84DA for ; Sat, 4 Jun 2011 14:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.181 X-Spam-Level: X-Spam-Status: No, score=-98.181 tagged_above=-999 required=5 tests=[MIME_QP_LONG_LINE=1.819, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uf5xt2kt8E14 for ; Sat, 4 Jun 2011 14:40:41 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 84C8D21F84D9 for ; Sat, 4 Jun 2011 14:40:38 -0700 (PDT) Received: from [10.48.163.99] (166-205-138-147.mobile.mymmode.com [166.205.138.147] (may be forged)) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p54E2W2A016265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 4 Jun 2011 07:02:49 -0700 (PDT) References: <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8J2) Content-Type: text/plain; charset=us-ascii Message-Id: <1F1804CA-BC0D-4231-B83B-1F3DAE29CDC1@isi.edu> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8J2) From: Joe Touch Date: Sat, 4 Jun 2011 07:02:27 -0700 To: Christopher Morrow X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "stephen.farrell@cs.tcd.ie" , Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 21:40:42 -0000 So basically the problem is that: - routers don't all support IPsec for the control plane - servers don't yet implement AO I repeat that there's a known solution that is already being used for BGP: Use AO if available Use MD5 in the meantime Yes, servers will support AO, if for no other reason than they support BGP a= nd MD5 now.=20 Joe On Jun 3, 2011, at 7:26 PM, Christopher Morrow wro= te: > On Fri, Jun 3, 2011 at 10:15 PM, Uma Chunduri w= rote: >>=20 >>=20 >> -----Original Message----- >> From: christopher.morrow@gmail.com [mailto:christopher.morrow@gmail.com] O= n Behalf Of Christopher Morrow >> Sent: Friday, June 03, 2011 6:11 PM >> To: Uma Chunduri >> Cc: Sandra Murphy; stephen.farrell@cs.tcd.ie; sidr@ietf.org >> Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? >>=20 >> On Fri, Jun 3, 2011 at 5:28 PM, Uma Chunduri w= rote: >>>=20 >>>=20 >>> -----Original Message----- >>> From: Sandra Murphy [mailto:Sandra.Murphy@sparta.com] >>> Sent: Friday, June 03, 2011 1:43 PM >>> To: Uma Chunduri >>> Cc: sidr@ietf.org; Sean Turner; stephen.farrell@cs.tcd.ie >>> Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? >>>=20 >>>=20 >>> On Fri, 3 Jun 2011, Uma Chunduri wrote: >>>=20 >>>>=20 >>>>=20 >>> .... >>>=20 >>>>=20 >>>> True, privacy through SSH is overkill but strong AUTH is *critical*, I f= eel: >>>> - TCP-MD5 should not be considered (as it is any ways deprecated >>>> and it's MD5) >>>> - TCP-AO has only slight advantage as it has less overhead than >>>> ipsec-AH even when >>>> deployed with manual keys >>>> - but it's better if it is "MUST support authentication of nodes >>>> with TCP-AO or ipsec-AH" because >>>=20 >>> Just to be sure: >>>=20 >>> Did you understand the part about implementations of TCP-AO and ipsec-AH= not being available at present? >>>=20 >>> I.e., you recognize this forces a delay in implementation of the protoco= l (and accept the consequent impact on deployment of the RPKI)? >>>=20 >>> [Uma] Yes, I did. Even though operators don't like ipsec-AH today, it >>> is still deployed for OSPFv3 protection as that (of course now there are= other drafts to mitigate complexity with reasonable trade-off). >>>=20 >>=20 >> So, speaking as just another guy on the bus here... it's not about 'dont l= ike it' it's about "THE CODE ON THE ROUTER DOES NOT DO IPSEC" >>=20 >> Keep in mind that a router is not a generic CPU + intel ethernet PCI card= , and often the OS on it is optomized for a particular duty, in large iron r= outers it's NOT ipsec. >>=20 >>> Problem with MD5 is, it can present the *weakest* link for the whole RPK= I infa. >>> At least new infrastructure like RPKI should avoid deprecated stuff. >>=20 >> exactly how is MD5 the weakest link here? some particular words about the= threat model + ability to subvert a running session which ships a few megab= ytes/minute around would be in order here. >>=20 >> [Uma] >>=20 >> 1. Wang, X., H. Yu, "How to break MD5 and other hash >> functions", Proc. IACR Eurocrypt 2005, Denmark >=20 > depends on creating 2 items to hash I believe? shows that if you do > the right thing for 2 very large items you create you can get a > collision in some instances. not picking random bits off the wire, not > relevant, move on. >=20 >> 2. RFC 4270 >=20 > talks about the above, not relevant. >=20 >>=20 >> 3. long back even OSPF, ISIS etc.. moved away from MD5 >=20 > fear, uncertainty, doubt. >=20 > we aren't talking about a permanent use of md5, we're talking about: > Use something that provides authentication/assurance NOW so we can > move forward, knowing full well we'll change to the better/required > solution when it's available in the right places. >=20 > There's not a single AO implementation available today... it's DOA > until there is. (frankly it's kind of a failure that there aren't > widely deployed implementations of this... given all the time to > invent it and all) >=20 >> 4. ... >>=20 >> For that matter SHA1 is getting deprecated http://securitymusings.com/art= icle/1587/algorithm-and-key-length-deprecation >>=20 >=20 > again, not relevant. >=20 > please find something relevant that's not just fear mongering. Or, > alternately, find implementations of AO in the servers and routers > that matter. (if there are AO implementations w00t! we all win, until > then we spin) >=20 > -chris > >=20 >>=20 >> Getting public keys from a server with a deprecated auth mechanism to ve= rify RSA signature? >> it's obscure..and not sure why it's not considered weak. >> Well, one can still use and design systems around this if this is still s= een adequate. >>=20 >> -Uma >>=20 >>=20 >>=20 >>=20 >> -chris >> >>=20 >>> -Uma >>>=20 >>>=20 >>> --Sandy, speaking as wg co-chair >>>=20 >>>=20 >>>> as both support >>>> - strong auth algos >>>> - algo agility >>>> - can be deployed with manual and auto key management >>>> (auto key probably required eventually, once with lot of >>>> connections at >>>> cache/global RPKI/server side and for automatic key >>>> changes periodically) >>>> - key changes for existing sessions >>>>=20 >>>> One would get flexibility with this. >>>> Also Section 7 (page 16) >>>> "It is assumed that the router and cache have exchanged keys out of b= and by some reasonably secured means" >>>> This will be still applicable but only if TCP-AO/ipsce-AH are deploy= ed with manual keys. >>>>=20 >>>> 2 cents, >>>> -Uma >>>>=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 >>=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From christopher.morrow@gmail.com Sat Jun 4 17:56: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 C014B11E8072 for ; Sat, 4 Jun 2011 17:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101 X-Spam-Level: X-Spam-Status: No, score=-101 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgPyQ8b-97Hp for ; Sat, 4 Jun 2011 17:56:38 -0700 (PDT) Received: from mail-px0-f170.google.com (mail-px0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 335BC11E8071 for ; Sat, 4 Jun 2011 17:56:38 -0700 (PDT) Received: by pxi19 with SMTP id 19so1879930pxi.15 for ; Sat, 04 Jun 2011 17:56:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Xr8F0TtWRYbf8uxKkd4r3bHy4x25UgZeBz7XKm016oE=; b=ewiP79vtf522sPWxuKntEs5runwxVLouKjU4FKMHkpUpsY7xj8ToDt6hctcaPPs8E7 WqZ1Cfs3T5cFRDPlYDvLdLx5RPf/0NUAm+jcPdSKzI9TkNIfn+88VV4nOc2Sey0Me8Gl P0BiBbQdWjN+ZQWQTYPPisv/WybSTqjlyVk6s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=VAOCiXFz7qbfmcm03yBmyQaJ+jI3DdwyhJbtju5+qJbiDVfmAmbt1Oi4g4MI4W/b4O K3U/cas7E3qTn29FOnsPSWXuKcNCweL/Jz2E/u6ZIgsIdvTYu47E6F2j5Qaez1BIHrYh KCAlu18RYRVFgllvPmsHWfYkBjIrNZlP0I/kQ= MIME-Version: 1.0 Received: by 10.68.35.102 with SMTP id g6mr1312102pbj.16.1307235397541; Sat, 04 Jun 2011 17:56:37 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.68.44.106 with HTTP; Sat, 4 Jun 2011 17:56:37 -0700 (PDT) In-Reply-To: <1F1804CA-BC0D-4231-B83B-1F3DAE29CDC1@isi.edu> References: <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> <1F1804CA-BC0D-4231-B83B-1F3DAE29CDC1@isi.edu> Date: Sat, 4 Jun 2011 20:56:37 -0400 X-Google-Sender-Auth: ud1N1__maRnHK6iXBYTb10LcD2A Message-ID: From: Christopher Morrow To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "stephen.farrell@cs.tcd.ie" , Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 00:56:42 -0000 On Sat, Jun 4, 2011 at 10:02 AM, Joe Touch wrote: > So basically the problem is that: > > - routers don't all support IPsec for the control plane > > - servers don't yet implement AO routers don't yet support AO either :( at least not in juniper 10.x code nor cisco 12.2(S) or 15 code... (or not that I've seen and been able to configure, though at least 1 of the 2 there say 'coming RSN!') > I repeat that there's a known solution that is already being used for BGP= : > > Use AO if available > > Use MD5 in the meantime > ok, I think that's kind of where the implementors got in offline discussions. I think people (me at least) are hoping the security AD folks find this sort of wording/direction palatable though. > Yes, servers will support AO, if for no other reason than they support BG= P and MD5 now. agreed, some heat is required to make this happen (heat =3D=3D 'gosh I'd love my Oracle/fbsd/linux server(s) to be able to run quagga to my new and old IOS boxes...') -chris > Joe > > On Jun 3, 2011, at 7:26 PM, Christopher Morrow = wrote: > >> On Fri, Jun 3, 2011 at 10:15 PM, Uma Chunduri wrote: >>> >>> >>> -----Original Message----- >>> From: christopher.morrow@gmail.com [mailto:christopher.morrow@gmail.com= ] On Behalf Of Christopher Morrow >>> Sent: Friday, June 03, 2011 6:11 PM >>> To: Uma Chunduri >>> Cc: Sandra Murphy; stephen.farrell@cs.tcd.ie; sidr@ietf.org >>> Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? >>> >>> On Fri, Jun 3, 2011 at 5:28 PM, Uma Chunduri wrote: >>>> >>>> >>>> -----Original Message----- >>>> From: Sandra Murphy [mailto:Sandra.Murphy@sparta.com] >>>> Sent: Friday, June 03, 2011 1:43 PM >>>> To: Uma Chunduri >>>> Cc: sidr@ietf.org; Sean Turner; stephen.farrell@cs.tcd.ie >>>> Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? >>>> >>>> >>>> On Fri, 3 Jun 2011, Uma Chunduri wrote: >>>> >>>>> >>>>> >>>> .... >>>> >>>>> >>>>> True, privacy through SSH is overkill but strong AUTH is *critical*, = I feel: >>>>> =A0 - TCP-MD5 should not be considered (as it is any ways deprecated >>>>> and it's MD5) >>>>> =A0 - TCP-AO has only slight advantage as it has less overhead than >>>>> ipsec-AH even when >>>>> =A0 =A0 deployed with manual keys >>>>> =A0 - but it's better if it is "MUST support authentication of nodes >>>>> with TCP-AO or ipsec-AH" because >>>> >>>> Just to be sure: >>>> >>>> Did you understand the part about implementations of TCP-AO and ipsec-= AH not being available at present? >>>> >>>> I.e., you recognize this forces a delay in implementation of the proto= col (and accept the consequent impact on deployment of the RPKI)? >>>> >>>> [Uma] Yes, I did. Even though operators don't like =A0ipsec-AH today, = it >>>> is still deployed for OSPFv3 protection as that (of course now there a= re other drafts to mitigate complexity with reasonable trade-off). >>>> >>> >>> So, speaking as just another guy on the bus here... it's not about 'don= t like it' it's about "THE CODE ON THE ROUTER DOES NOT DO IPSEC" >>> >>> Keep in mind that a router is not a generic CPU + intel ethernet PCI ca= rd, and often the OS on it is optomized for a particular duty, in large iro= n routers it's NOT ipsec. >>> >>>> Problem with MD5 is, it can present the *weakest* link for the whole R= PKI infa. >>>> At least new infrastructure like RPKI should avoid deprecated =A0stuff= . >>> >>> exactly how is MD5 the weakest link here? some particular words about t= he threat model + ability to subvert a running session which ships a few me= gabytes/minute around would be in order here. >>> >>> [Uma] >>> >>> 1. Wang, X., H. Yu, "How to break MD5 and other hash >>> =A0 =A0 =A0 =A0 =A0 =A0 functions", Proc. IACR Eurocrypt 2005, Denmark >> >> depends on creating 2 items to hash I believe? =A0shows that if you do >> the right thing for 2 very large items you create you can get a >> collision in some instances. not picking random bits off the wire, not >> relevant, move on. >> >>> 2. RFC 4270 >> >> talks about the above, not relevant. >> >>> >>> 3. long back even OSPF, ISIS etc.. moved away from MD5 >> >> fear, uncertainty, doubt. >> >> we aren't talking about a permanent use of md5, we're talking about: >> Use something that provides authentication/assurance NOW so we can >> move forward, knowing full well we'll change to the better/required >> solution when it's available in the right places. >> >> There's not a single AO implementation available today... it's DOA >> until there is. (frankly it's kind of a failure that there aren't >> widely deployed implementations of this... given all the time to >> invent it and all) >> >>> 4. ... >>> >>> For that matter SHA1 is getting deprecated http://securitymusings.com/a= rticle/1587/algorithm-and-key-length-deprecation >>> >> >> again, not relevant. >> >> please find something relevant that's not just fear mongering. Or, >> alternately, find implementations of AO in the servers and routers >> that matter. (if there are AO implementations w00t! we all win, until >> then we spin) >> >> -chris >> >> >>> >>> Getting public keys from a server with a =A0deprecated auth mechanism t= o verify RSA signature? >>> it's obscure..and not sure why it's not considered weak. >>> Well, one can still use and design systems around this if this is still= seen adequate. >>> >>> -Uma >>> >>> >>> >>> >>> -chris >>> >>> >>>> -Uma >>>> >>>> >>>> --Sandy, speaking as wg co-chair >>>> >>>> >>>>> =A0 =A0 as both support >>>>> =A0 =A0 =A0 =A0 =A0 - strong auth algos >>>>> =A0 =A0 =A0 =A0 =A0 - algo agility >>>>> =A0 =A0 =A0 =A0 =A0 - can be deployed with manual and auto key manage= ment >>>>> =A0 =A0 =A0 =A0 =A0 =A0(auto key probably required eventually, once w= ith lot of >>>>> connections at >>>>> =A0 =A0 =A0 =A0 =A0 =A0 cache/global RPKI/server side and for automat= ic key >>>>> =A0 =A0 =A0 =A0 =A0 =A0 changes periodically) >>>>> =A0 =A0 =A0 =A0 =A0 - key changes for existing sessions >>>>> >>>>> =A0 =A0One would get flexibility with this. >>>>> =A0 =A0Also Section 7 (page 16) >>>>> =A0 =A0"It is assumed that the router and cache have exchanged keys o= ut of band by some reasonably secured means" >>>>> =A0 =A0This will be still applicable but only if TCP-AO/ipsce-AH are = deployed with manual keys. >>>>> >>>>> 2 cents, >>>>> -Uma >>>>> >>>>> >>>>> _______________________________________________ >>>>> sidr mailing list >>>>> sidr@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sidr >>>>> >>>> _______________________________________________ >>>> sidr mailing list >>>> sidr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sidr >>>> >>> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > From randy@psg.com Sat Jun 4 23:21: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 1FC7D11E8077 for ; Sat, 4 Jun 2011 23:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjIYO58yO1FL for ; Sat, 4 Jun 2011 23:21:29 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id A79E611E8072 for ; Sat, 4 Jun 2011 23:21:26 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QT6h0-0003bh-M7; Sun, 05 Jun 2011 06:20:11 +0000 Date: Sun, 05 Jun 2011 06:20:09 +0000 Message-ID: From: Randy Bush To: Joe Touch In-Reply-To: <1F1804CA-BC0D-4231-B83B-1F3DAE29CDC1@isi.edu> References: <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 06:21:30 -0000 > Yes, servers will support AO, if for no other reason than they support > BGP and MD5 now. the problem is that they don't really. check out, for example, the freebsd md5 hack. it is send-only, does not check on receive. i am told there are similar messes elsewhere. basically this is a mess. o ipsec is not fully supported to the control plane, and it is a masters project to specify compatible parameters. a sad ietf disaster. o md5 is not fully supported (on servers), but might be fixed more easily than AO. it is weak in theory and widely deployed and deployable in practice. o ssh is not fully supported _as a library_ in routers, hacking is possible and is being done. o AO is nice paperware but does not have significant running code on servers or routers. it tells us something about the ietf to have it push so hard on something with so little running code. which is why we're pretty much using cleartext tcp today. this is ok for early deployment. and it will definitely encourage ops to put the cache servers close to the routers, which is good :). but it is not a good mid-term solution. we'd really like to see a mandatory-to-implement so that ops have a clear deployment scenario. but ssh is the only strong candidate for that at the moment, and it's not pretty. at least one router vendor has implemented. and we have ssh implementation across a wide variety of servers. AO is the likely long term mandatory-to-implement, but could be a long way out on servers. sigh. randy From touch@isi.edu Sun Jun 5 15:20: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 E84BB21F84E5 for ; Sun, 5 Jun 2011 15:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dhc7hDvTrZPb for ; Sun, 5 Jun 2011 15:20:30 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by ietfa.amsl.com (Postfix) with ESMTP id 3555721F84E4 for ; Sun, 5 Jun 2011 15:20:29 -0700 (PDT) Received: from [172.20.0.222] (pc2.kyotoint1-unet.ocn.ne.jp [211.123.99.34]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p55MJt7O007481 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sun, 5 Jun 2011 15:20:07 -0700 (PDT) Message-ID: <4DEC010B.1090107@isi.edu> Date: Sun, 05 Jun 2011 15:19:55 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Christopher Morrow References: <4DAF44AC.8060408@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> <1F1804CA-BC0D-4231-B83B-1F3DAE29CDC1@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p55MJt7O007481 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "stephen.farrell@cs.tcd.ie" , Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 22:20:32 -0000 Hi, all, On 6/4/2011 5:56 PM, Christopher Morrow wrote: > On Sat, Jun 4, 2011 at 10:02 AM, Joe Touch wrote: >> So basically the problem is that: >> >> - routers don't all support IPsec for the control plane >> >> - servers don't yet implement AO > > routers don't yet support AO either :( at least not in juniper 10.x > code nor cisco 12.2(S) or 15 code... > (or not that I've seen and been able to configure, though at least 1 > of the 2 there say 'coming RSN!') One other thing to keep in mind is whether this doc (and to some extent, the IETF as a whole) should follow or lead. If we're followers, then the answer is clear - watch what the hackers implement. If we're leaders, we should focus on the goal state, recognizing that all issued requirements are - at best - goals anyway. >> Yes, servers will support AO, if for no other reason than they support BGP and MD5 now. > > agreed, some heat is required to make this happen (heat == 'gosh I'd > love my Oracle/fbsd/linux server(s) to be able to run quagga to my new > and old IOS boxes...') Again, follow vs. lead. If we're leading, then we should recognize that we're talking about a very small amount of resources need to accomplish this task. I'm already working with the funding agencies and a few companies with similar 'rfp' processes to access those resources. If anyone wants to help with any resources, please let me know. Joe From touch@isi.edu Sun Jun 5 15:29: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 A79399E8004 for ; Sun, 5 Jun 2011 15:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOzfFnwXTzzK for ; Sun, 5 Jun 2011 15:29:05 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by ietfa.amsl.com (Postfix) with ESMTP id 251D59E8006 for ; Sun, 5 Jun 2011 15:29:05 -0700 (PDT) Received: from [172.20.0.222] (pc2.kyotoint1-unet.ocn.ne.jp [211.123.99.34]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p55MSLFj008507 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sun, 5 Jun 2011 15:28:32 -0700 (PDT) Message-ID: <4DEC0305.1020102@isi.edu> Date: Sun, 05 Jun 2011 15:28:21 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Paul Hoffman References: <4DAF44AC.8060408@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> <8FFA5FF6-317C-4433-8629-369563A384FD@vpnc.org> In-Reply-To: <8FFA5FF6-317C-4433-8629-369563A384FD@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p55MSLFj008507 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: sidr@ietf.org, Stephen Farrell Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 22:29:05 -0000 Hi, all, +1, with a caveat below... On 6/4/2011 1:04 PM, Paul Hoffman wrote: > On Jun 3, 2011, at 7:15 PM, Uma Chunduri wrote: > >> exactly how is MD5 the weakest link here? some particular words about the threat model + ability to subvert a running session which ships a few megabytes/minute around would be in order here. >> >> [Uma] >> >> 1. Wang, X., H. Yu, "How to break MD5 and other hash >> functions", Proc. IACR Eurocrypt 2005, Denmark >> 2. RFC 4270 > >> Wearing my co-author-of-4270 hat, let me state forcefully: invoking > RFC 4270 or *any* current published work on MD5 does not answer the > question of how MD5 is the weakest link here. Those are *unrelated* to > an attack on the integrity of communication in draft-sidr-rpki-rtr. > Collision attacks on MD5 and SHA-1 are, to date, unrelated to preimage > attacks, and it is preimage attacks that you care about. > > On Jun 4, 2011, at 9:38 AM, Stephen Farrell wrote: > >> Trying to catch up with you all here. >> >>> From reading the mail thread it seems to me that: >> >> - tcp-md5 is available but undesirable >> - tcp-ao is desirable but unavailable so far >> - ssh is available and slightly undesirable for >> performance reasons but desirable in >> security terms >> >> That would imply that an answer might be: >> >> MUST implement SSH; SHOULD implement TCP-AO and >> MUST/SHOULD prefer TCP-AO over SSH if both >> available >> >> Would that garner (rough) consensus? > > Another proposal that might be more likely to garner rough consensus > would be: MUST implement TCP-MD5 [RFC2385]; SHOULD implement TCP-AO > [RFC5925] (the official successor to TCP-MD5) as soon as possible; if > both parties in the protocol support TCP-AO, they SHOULD use TCP-AO and > SHOULD NOT use TCP-MD5. After we believe that there is lots of TCP-AO > adoption, we revise the document and remove TCP-MD5 as an option. IMO, "MUST AO, MAY MD5 if AO is not available" achieves this *without* a "MUST" that overrides the existing AO/MD5 advice in the AO RFC . The net effect is, AFAICT, identical, and more like what you state above. FWIW, I also thing it's a lot more tractable to expect a MD5/AO use than an SSH/AO use; the APIs of the former two are likley to be very similar, but not the latter. Joe From raszuk@cisco.com Sun Jun 5 15:29:15 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10C111E807E for ; Sun, 5 Jun 2011 15:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7rCv0hFM1UK for ; Sun, 5 Jun 2011 15:29:14 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7465411E8080 for ; Sun, 5 Jun 2011 15:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=342; q=dns/txt; s=iport; t=1307312954; x=1308522554; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=BCCceq7yK6OCpntxDcbk6bwkU6p67vIdJZ7Ns7dNfX8=; b=aLOfa5oaU5UtM0UPbxdmPqogdMSbmB94WPvyHNu/tRFiAoWBsDlCrlU/ 01h6zyeGwZ+dxxJWKIIEg2Of8fw0O41rONIC4Qt+FyJlk3Fa+pSMTx/Q9 1VSRa3jsSd/ZTEAB4KmOm4xq7RIqiNjRf7Cj8jrB8PIyyHMf0uBOTEvcO g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIHAFgC7E1Io8UT/2dsb2JhbABTmBeOH3eIcaEEgnwPAZlWhiEEkHmESIp0 X-IronPort-AV: E=Sophos;i="4.65,324,1304294400"; d="scan'208";a="33756946" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-2.cisco.com with ESMTP; 05 Jun 2011 22:29:12 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p55MT9sq008647 for ; Sun, 5 Jun 2011 22:29:11 GMT Message-ID: <4DEC0344.20407@cisco.com> Date: Mon, 06 Jun 2011 00:29:24 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: sidr@ietf.org References: <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 22:29:15 -0000 Randy, > o AO is nice paperware but does not have significant running code on > servers or routers. I don't understand your line of argument. If vendor X is providing support of AO on his equipment what is a problem to provide downloadable linux kernel module to be able to establish such session end to end ? Thx, R. From randy@psg.com Mon Jun 6 02:03: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 8DC5C11E80D8 for ; Mon, 6 Jun 2011 02:03: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+YSyP8l9DYh for ; Mon, 6 Jun 2011 02:03:48 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3AC11E80DA for ; Mon, 6 Jun 2011 02:03:47 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QTVhQ-0007CR-HA; Mon, 06 Jun 2011 09:02:17 +0000 Date: Mon, 06 Jun 2011 09:02:13 +0000 Message-ID: From: Randy Bush To: Joe Touch In-Reply-To: <4DEC010B.1090107@isi.edu> References: <4DAF44AC.8060408@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> <1F1804CA-BC0D-4231-B83B-1F3DAE29CDC1@isi.edu> <4DEC010B.1090107@isi.edu> 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: Sandra Murphy , "sidr@ietf.org" , "stephen.farrell@cs.tcd.ie" Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 09:03:48 -0000 > One other thing to keep in mind is whether this doc (and to some extent, > the IETF as a whole) should follow or lead. > > If we're followers, then the answer is clear - watch what the hackers > implement. > > If we're leaders, we should focus on the goal state, recognizing that > all issued requirements are - at best - goals anyway. rough consensus AND running code. code, not powerpoint. randy From randy@psg.com Mon Jun 6 02:04: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 1027611E80D5 for ; Mon, 6 Jun 2011 02:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxW7rkPbzkFX for ; Mon, 6 Jun 2011 02:04:39 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 9D88611E8093 for ; Mon, 6 Jun 2011 02:04:39 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QTViV-0007Ca-4X; Mon, 06 Jun 2011 09:03:23 +0000 Date: Mon, 06 Jun 2011 09:03:21 +0000 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: <4DEC0344.20407@cisco.com> References: <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> <4DEC0344.20407@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 09:04:40 -0000 >> o AO is nice paperware but does not have significant running code on >> servers or routers. > I don't understand your line of argument. If vendor X is providing > support of AO on his equipment what is a problem to provide > downloadable linux kernel module to be able to establish such session > end to end ? this may come as a shock, but a linux kernel module does not work well on unix, solaris, ... randy From raszuk@cisco.com Mon Jun 6 03:50: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 215C011E80D6 for ; Mon, 6 Jun 2011 03:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.066 X-Spam-Level: X-Spam-Status: No, score=-10.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuyEkPQwcAs0 for ; Mon, 6 Jun 2011 03:50:06 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id A3DBA11E80ED for ; Mon, 6 Jun 2011 03:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=943; q=dns/txt; s=iport; t=1307357406; x=1308567006; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=d6ZEHmXgCBZbbn5Qa7Ht/o12qtJEjqwms27gl5zp7/g=; b=kJUNzii/bsNkgxIFeLchNEjEji8WyzS+j9PLT98PCW5jn7je5HlrvX6+ NCAD5pEK/vr0MTVK7WP7DB7qGARxVbWwORX/FvMQ4g17xQi2ySDMUrkk2 veXLCC74OIfOz38X7V/p6qV4g+gsE2v5dUTpQmWyGrO4WnYy2wTarGLp+ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOmv7E2rRDoG/2dsb2JhbABTpjp3iHGkQoJ8DwGaIoYhBJB5hEiKdA X-IronPort-AV: E=Sophos;i="4.65,325,1304294400"; d="scan'208";a="330868383" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 06 Jun 2011 10:50:06 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p56Ao4dX004416; Mon, 6 Jun 2011 10:50:05 GMT Message-ID: <4DECB0DC.4000902@cisco.com> Date: Mon, 06 Jun 2011 12:50:04 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Randy Bush References: <4DAF44AC.8060408@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> <4DEC0344.20407@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 10:50:07 -0000 What I am actually more shocked about is that you did not point out need to support this on AIX, SunOS, SCO and few others dated ones ;) *** If indeed requirement is to support decent authentication on wide spectrum of operating systems why not consider application level approach of SSL/TLS and leave the need for TCP kernel hacking alone ? rfc5246 ? Routers support it today so would any unix flavor as it will come with the application if not already there. r. >>> o AO is nice paperware but does not have significant running code on >>> servers or routers. >> I don't understand your line of argument. If vendor X is providing >> support of AO on his equipment what is a problem to provide >> downloadable linux kernel module to be able to establish such session >> end to end ? > > this may come as a shock, but a linux kernel module does not work well > on unix, solaris, ... > > randy > From hannes@juniper.net Mon Jun 6 04:03:03 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9959D11E80F8 for ; Mon, 6 Jun 2011 04:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9EBy+XgYh8q for ; Mon, 6 Jun 2011 04:03:03 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 383F511E80D6 for ; Mon, 6 Jun 2011 04:03:02 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTeyz4wf80OjfMjzm7qKCJmLQRae8Tnd3@postini.com; Mon, 06 Jun 2011 04:03:02 PDT Received: from hannes-755.juniper.net (172.23.4.62) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.2.254.0; Mon, 6 Jun 2011 04:00:35 -0700 Received: by hannes-755.juniper.net (Postfix, from userid 1000) id 2FA2028FD2; Mon, 6 Jun 2011 13:00:34 +0200 (CEST) Date: Mon, 6 Jun 2011 13:00:34 +0200 From: Hannes Gredler To: Robert Raszuk Message-ID: <20110606110032.GA3117@juniper.net> References: <4DEC0344.20407@cisco.com> <4DECB0DC.4000902@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <4DECB0DC.4000902@cisco.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: sidr@ietf.org Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 11:03:03 -0000 On Mon, Jun 06, 2011 at 12:50:04PM +0200, Robert Raszuk wrote: | If indeed requirement is to support decent authentication on wide | spectrum of operating systems why not consider application level | approach of SSL/TLS and leave the need for TCP kernel hacking alone | ? rfc5246 ? | | Routers support it today so would any unix flavor as it will come | with the application if not already there. hi robert, --- quoting from rfc 5246: The primary goal of the TLS protocol is to provide privacy and data ^^^^^^^^^^^^^^^^^^^^^^^^ integrity between two communicating applications. The protocol is ^^^^^^^^^ composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol. At the lowest level, layered on top of some reliable transport protocol (e.g., TCP [TCP]), is the TLS Record Protocol. The TLS Record Protocol provides connection security that has two basic properties: --- we are just looking for a protocol which ensures data-integrity, privacy is not of concern; /hannes From randy@psg.com Mon Jun 6 04:15: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 2A92D11E8120 for ; Mon, 6 Jun 2011 04:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7P-ovKFbOBqH for ; Mon, 6 Jun 2011 04:15:09 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 7744E11E80FD for ; Mon, 6 Jun 2011 04:15:09 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QTXlz-0007Sn-Ij; Mon, 06 Jun 2011 11:15:08 +0000 Date: Mon, 06 Jun 2011 11:15:05 +0000 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: <4DECB0DC.4000902@cisco.com> References: <4DAF44AC.8060408@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> <4DEC0344.20407@cisco.com> <4DECB0DC.4000902@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 11:15:10 -0000 > What I am actually more shocked about is that you did not point out need > to support this on AIX, SunOS, SCO and few others dated ones ;) i know this will come as a shock to a vendor marketeer, but we want to support what operators actually use > If indeed requirement is to support decent authentication on wide > spectrum of operating systems why not consider application level > approach of SSL/TLS privacy is not the requirement randy From raszuk@cisco.com Mon Jun 6 04:17: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 5D59711E80FD for ; Mon, 6 Jun 2011 04:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RAUz2JGpDox for ; Mon, 6 Jun 2011 04:17:40 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 210E311E80D6 for ; Mon, 6 Jun 2011 04:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=483; q=dns/txt; s=iport; t=1307359060; x=1308568660; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=7B+53SA7HHHHyene58zF24XIoduwUmyovWIZQjYCKM8=; b=C0rmfqIQlG9wps2SerFvNX8ZvEmtauRViGZhDRWtGS33e0At6RAhpl19 ykr84+3byhG1XEIEla5F4an39HOl5ZqsVeRlHvjfn8cG4rmvUuWPsZqa9 l7TJbZCDzOtXmdPaLsNECccVTTyZeAk0uYrhQEPBSIbRJ77/ffwKNdPTJ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGi27E2rRDoH/2dsb2JhbABTpjp3iHGkKIJ8DwGaIYYhBJB5hEiKdA X-IronPort-AV: E=Sophos;i="4.65,325,1304294400"; d="scan'208";a="708712828" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 06 Jun 2011 11:17:38 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p56BHaXq013080; Mon, 6 Jun 2011 11:17:37 GMT Message-ID: <4DECB74F.6040406@cisco.com> Date: Mon, 06 Jun 2011 13:17:35 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Hannes Gredler References: <4DEC0344.20407@cisco.com> <4DECB0DC.4000902@cisco.com> <20110606110032.GA3117@juniper.net> In-Reply-To: <20110606110032.GA3117@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 11:17:41 -0000 Hi Hannes, > privacy is not of concern; Are you really sure about that ? One of the deployment models I have heard is the remote reception of prefixes/origins pairs which are found to be invalid by for example subscribing to CYMRU database. If I would pay $20 per month for such feed which will relax me from even keeping a local RPKI cache in my network why would I not be concern that you will intercept my feed and use it without paying CYMRU? Cheers, R. From randy@psg.com Mon Jun 6 04:27:01 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A1E11E80F1 for ; Mon, 6 Jun 2011 04:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+akfZUH+AoA for ; Mon, 6 Jun 2011 04:27:01 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 29AD611E80D6 for ; Mon, 6 Jun 2011 04:27:01 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QTXxO-0007U9-Fi; Mon, 06 Jun 2011 11:26:55 +0000 Date: Mon, 06 Jun 2011 11:26:52 +0000 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: <4DECB74F.6040406@cisco.com> References: <4DEC0344.20407@cisco.com> <4DECB0DC.4000902@cisco.com> <20110606110032.GA3117@juniper.net> <4DECB74F.6040406@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 11:27:01 -0000 >> privacy is not of concern; > Are you really sure about that ? yes randy From stephen.farrell@cs.tcd.ie Mon Jun 6 04:33: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 6E2E811E80F3 for ; Mon, 6 Jun 2011 04:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBtFQS+W+73b for ; Mon, 6 Jun 2011 04:33:41 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3004411E80FA for ; Mon, 6 Jun 2011 04:33:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 31734171C2B; Mon, 6 Jun 2011 12:33:38 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1307360017; bh=fgs8SSCm4mhe0j SEJoT36UFXZgA1mJmaSR07J1aFzlc=; b=arx7kTOZpGEykArhdV5gr8wZNvolwK 0LPAX76h85mfTJJNDh6Uvfc+Hq1VplYujNZFQuxM21vtyVqy8ibK5k4RBY4Jhrrh J254TSdALSh4OXCcfxENrbh0qPp4lU7PdSAfTTn01dm0WlNF/fQ7bTP27sVrEieO y9pBqyxpGd/g9qpHXjBRzdPTrsPjhObmjwNdkETt3YCCQ8RbCS2sc5w20LZNJehb 4hO+4NpBJuBGk1sOQKryfN6GOpkH+46LjvYKSFwf3rQCXxM+0jrOU8+d+GiudmYd vF2sE0sl0Pi4bGnad3oBWiUOZJHwNcV7gOvAVS0MIcknj8l/Of9Ff0DQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id twW9mnG4IprW; Mon, 6 Jun 2011 12:33:37 +0100 (IST) Received: from [10.87.48.9] (unknown [86.42.182.86]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id E3CEB171C17; Mon, 6 Jun 2011 12:33:34 +0100 (IST) Message-ID: <4DECBB0E.3090001@cs.tcd.ie> Date: Mon, 06 Jun 2011 12:33:34 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Paul Hoffman References: <4DAF44AC.8060408@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> <8FFA5FF6-317C-4433-8629-369563A384FD@vpnc.org> In-Reply-To: <8FFA5FF6-317C-4433-8629-369563A384FD@vpnc.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 11:33:42 -0000 On 04/06/11 21:04, Paul Hoffman wrote: > On Jun 3, 2011, at 7:15 PM, Uma Chunduri wrote: > >> exactly how is MD5 the weakest link here? some particular words about the threat model + ability to subvert a running session which ships a few megabytes/minute around would be in order here. >> >> [Uma] >> >> 1. Wang, X., H. Yu, "How to break MD5 and other hash >> functions", Proc. IACR Eurocrypt 2005, Denmark >> 2. RFC 4270 > > Wearing my co-author-of-4270 hat, let me state forcefully: invoking RFC 4270 or *any* current published work on MD5 does not answer the question of how MD5 is the weakest link here. Those are *unrelated* to an attack on the integrity of communication in draft-sidr-rpki-rtr. Collision attacks on MD5 and SHA-1 are, to date, unrelated to preimage attacks, and it is preimage attacks that you care about. So I've been thinking a little about this. First, I do not know of any practical md5 preimage attacks so far, however, if we allow tcp-md5 in this spec, we're effectively betting that that will remain the case for a few years at least and that's not a bet with which I'd be happy when we do have stronger options that are already specified. Second, and perhaps more importantly, given that md5 is broken for collisions, there may be other attacks on this protocol using tcp-md5 that are enabled by that fact and that do not require a preimage break for md5. For example, if an attacker generates two colliding values t2 and t2' and gets a value related to t2 injected into the rpki so that at some later point a cache response message will have the value t1|t2|t3, then our (now on-path) attacker sees t1|t2|t3|MD5(t1|t2|t3|secret) and can substitute t2' for t2 and have that work. I'm making many assumptions here about encodings, lengths and the amount of work involved all working out for an attacker who can inject values into the rpki and be on-path, but I think those are not necessarily unreasonable given the rapidssl attack of a few years ago. [1] [1] http://www.win.tue.nl/hashclash/rogue-ca/ So, unless I'm off the mark on this point, (which is quite possible), I think that tcp-md5 is simply unacceptable here. Stephen. > > > On Jun 4, 2011, at 9:38 AM, Stephen Farrell wrote: > >> Trying to catch up with you all here. >> >>> From reading the mail thread it seems to me that: >> >> - tcp-md5 is available but undesirable >> - tcp-ao is desirable but unavailable so far >> - ssh is available and slightly undesirable for >> performance reasons but desirable in >> security terms >> >> That would imply that an answer might be: >> >> MUST implement SSH; SHOULD implement TCP-AO and >> MUST/SHOULD prefer TCP-AO over SSH if both >> available >> >> Would that garner (rough) consensus? > > Another proposal that might be more likely to garner rough consensus would be: MUST implement TCP-MD5 [RFC2385]; SHOULD implement TCP-AO [RFC5925] (the official successor to TCP-MD5) as soon as possible; if both parties in the protocol support TCP-AO, they SHOULD use TCP-AO and SHOULD NOT use TCP-MD5. After we believe that there is lots of TCP-AO adoption, we revise the document and remove TCP-MD5 as an option. > >> We really do want to deprecate tcp-md5. > > We already have: RFC 5925 obsoletes RFC 2385. The question is whether we want to prevent new protocols from using it and instead force them to use something else that doesn't work as well operationally while TCP-MD5 is still considered safe. Saying "MUST implement SSH" is tantamount to saying "many systems will run unprotected", which might be acceptable until TCP-AO is deployed. However, using TCP-MD5, but only until TCP-AO is deployed, seems like a better idea. > > --Paul Hoffman > > From randy@psg.com Mon Jun 6 06:54:53 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAC911E813E for ; Mon, 6 Jun 2011 06:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qp8cEieT11vh for ; Mon, 6 Jun 2011 06:54:52 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id AEB8211E813C for ; Mon, 6 Jun 2011 06:54:52 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QTaGW-0007pP-H6; Mon, 06 Jun 2011 13:54:49 +0000 Date: Mon, 06 Jun 2011 13:54:46 +0000 Message-ID: From: Randy Bush To: Stephen Farrell In-Reply-To: <4DECBB0E.3090001@cs.tcd.ie> References: <4DAF44AC.8060408@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 13:54:53 -0000 > So I've been thinking a little about this. First, I do not > know of any practical md5 preimage attacks so far, however, > if we allow tcp-md5 in this spec, we're effectively betting > that that will remain the case for a few years at least and > that's not a bet with which I'd be happy when we do have > stronger options that are already specified. let me try again. while i agree with you philosophically, packets do not move very well on 'specified.' and unless someone throws a lot of cash at it, AO looks as if is likely not to be available for a long on the set of platforms operators use for services, *BSD, Linux, and Solaris. randy From paul.hoffman@vpnc.org Mon Jun 6 06:58: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 D8B0F11E8140 for ; Mon, 6 Jun 2011 06:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Fzf+XxhEa5t for ; Mon, 6 Jun 2011 06:58:32 -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 7591B11E80F7 for ; Mon, 6 Jun 2011 06:58:31 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p56DwQs8001212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 Jun 2011 06:58:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20110606110032.GA3117@juniper.net> Date: Mon, 6 Jun 2011 06:58:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <612FD080-DEDE-4BD3-BAB3-45B091D8B544@vpnc.org> References: <4DEC0344.20407@cisco.com> <4DECB0DC.4000902@cisco.com> <20110606110032.GA3117@juniper.net> To: Hannes Gredler X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: [sidr] TLS (Was: Re: WGLC draft-sidr-rpki-rtr - take 2?) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 13:58:33 -0000 On Jun 6, 2011, at 4:00 AM, Hannes Gredler wrote: > On Mon, Jun 06, 2011 at 12:50:04PM +0200, Robert Raszuk wrote: > | If indeed requirement is to support decent authentication on wide > | spectrum of operating systems why not consider application level > | approach of SSL/TLS and leave the need for TCP kernel hacking alone > | ? rfc5246 ? > |=20 > | Routers support it today so would any unix flavor as it will come > | with the application if not already there. >=20 > hi robert, >=20 > --- >=20 > quoting from rfc 5246: >=20 > The primary goal of the TLS protocol is to provide privacy and data > ^^^^^^^^^^^^^^^^^^^^^^^^ > integrity between two communicating applications. The protocol is > ^^^^^^^^^ > composed of two layers: the TLS Record Protocol and the TLS = Handshake > Protocol. At the lowest level, layered on top of some reliable > transport protocol (e.g., TCP [TCP]), is the TLS Record Protocol. > The TLS Record Protocol provides connection security that has two > basic properties: >=20 > --- >=20 > we are just looking for a protocol which ensures data-integrity, > privacy is not of concern; >=20 TLS is exactly like SSH and IPsec in this case. It is easy to configure = TLS to be doing integrity-only. The overhead for encrypting, if you are = doing so, is extremely low. --Paul Hoffman From stephen.farrell@cs.tcd.ie Mon Jun 6 07:09: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 CB3D811E811E for ; Mon, 6 Jun 2011 07:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ub94-Loxxg1P for ; Mon, 6 Jun 2011 07:09:38 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id A0E6411E80F7 for ; Mon, 6 Jun 2011 07:09:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 586D0153D31; Mon, 6 Jun 2011 15:09:37 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1307369377; bh=XAL+G5n4+3WE1r IVHeJE0X2Pcp/w52DhlODZg7SPM2I=; b=4ZcKr0HyLuhLVNMo+OxSrZRPHe9Rl8 T9ljIHRxbmhHE1IM4NTaPtn13PuRT/yEHM4amU4Fw4src6hwSQ8pQYoiGGs+P1fX JrUPw4yG/Ho5cJTe/SDdMTNP+Xem9DiOGBCdmVpHjrUR91Hmb1dALk6pNKlfVox0 o/svP/xDYoxEygB1yRiMZuQrmc0a+N10I/uXReVl70zlC+caXmxEPWpiepwOBeDS KTRwZmmaOBoCi9UbzB1MUHySPYpLfWoNy6Fb3X4lNwTUz4LF8iZU4SFBW11vgi9i F47im/0p1LllyvQE82TlgvGNnO0uioB4+NBNRU/kV73CjTUD2kA8vFuw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id VVsYOAl3T6yi; Mon, 6 Jun 2011 15:09:37 +0100 (IST) Received: from [10.87.48.9] (unknown [86.42.182.86]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id DDA13153D2F; Mon, 6 Jun 2011 15:09:36 +0100 (IST) Message-ID: <4DECDFA0.9080109@cs.tcd.ie> Date: Mon, 06 Jun 2011 15:09:36 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Randy Bush References: <4DAF44AC.8060408@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 14:09:39 -0000 On 06/06/11 14:54, Randy Bush wrote: >> So I've been thinking a little about this. First, I do not >> know of any practical md5 preimage attacks so far, however, >> if we allow tcp-md5 in this spec, we're effectively betting >> that that will remain the case for a few years at least and >> that's not a bet with which I'd be happy when we do have >> stronger options that are already specified. > > let me try again. > > while i agree with you philosophically, packets do not move very well on > 'specified.' That's a fair point and is why I said the 2nd point is more important. The 2nd point being that it looks to me like tcp-md5 is just broken for this use case. If I'm wrong there I'll happily admit that. > and unless someone throws a lot of cash at it, AO looks as > if is likely not to be available for a long on the set of platforms > operators use for services, *BSD, Linux, and Solaris. I do understand that that's a problem. I don't however understand fully why SSH is being ruled out. All I saw on the list were a couple of mails saying that you can't use epoll which I'd have thought was a bit of a bummer but not a showstopper. But maybe picking SSH has more issues than that? That's why I suggested "MUST implement SSH; SHOULD implement TCP-AO; MUST prefer TCP-AO if both available" S. > > randy From randy@psg.com Mon Jun 6 07:37: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 5F6EC11E8154 for ; Mon, 6 Jun 2011 07:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdAK+g8uNhhG for ; Mon, 6 Jun 2011 07:37:52 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id D992111E8146 for ; Mon, 6 Jun 2011 07:37:51 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QTawA-0007v3-Aj; Mon, 06 Jun 2011 14:37:50 +0000 Date: Mon, 06 Jun 2011 14:37:48 +0000 Message-ID: From: Randy Bush To: Stephen Farrell In-Reply-To: <4DECDFA0.9080109@cs.tcd.ie> References: <4DAF44AC.8060408@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> <4DECDFA0.9080109@cs.tcd.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 14:37:52 -0000 > I don't however understand fully why SSH is being ruled out. it has not yet been. for some router platforms, while they have ssh server code, the ssh code is not a library with an api. and the bgp hackers are not empowered to touch that side of the code. > That's why I suggested "MUST implement SSH; SHOULD implement TCP-AO; > MUST prefer TCP-AO if both available" indeed, we may have to fall back to this. we still do not have for sure committments that all vendors can do this. but we're working it. folk such as russ and sean are more tuned to timing and constraints than i. my job here is just to hammer on the operational realities of delivery. but anything that folk can do to move AO from the powerpoint platform to the *BSD, Linux, and Solaris platforms will have long-term pay-off for both BGP and RPKI-Rtr. randy From paul.hoffman@vpnc.org Mon Jun 6 07:42: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 5118311E814F for ; Mon, 6 Jun 2011 07:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyEbWQrfVvEa for ; Mon, 6 Jun 2011 07:42:30 -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 6C10211E814D for ; Mon, 6 Jun 2011 07:42:29 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p56EgOR6003364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 Jun 2011 07:42:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <612FD080-DEDE-4BD3-BAB3-45B091D8B544@vpnc.org> Date: Mon, 6 Jun 2011 07:42:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5EBEAF8C-FB13-4965-BB73-EF524DD4F5E4@vpnc.org> References: <4DEC0344.20407@cisco.com> <4DECB0DC.4000902@cisco.com> <20110606110032.GA3117@juniper.net> <612FD080-DEDE-4BD3-BAB3-45B091D8B544@vpnc.org> To: Hannes Gredler X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: Re: [sidr] TLS (Was: Re: WGLC draft-sidr-rpki-rtr - take 2?) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 14:42:30 -0000 And, just to close the loop: do the TLS libraries have the same = limitations that the SSH libraries do that prevent them from being used = with kqueue/epoll? If not, specifying TLS would then solve the problem = here. --Paul Hoffman= From stephen.farrell@cs.tcd.ie Mon Jun 6 07:57: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 D405711E8158 for ; Mon, 6 Jun 2011 07:57: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnqoMeEHRV9V for ; Mon, 6 Jun 2011 07:57:58 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDB311E8145 for ; Mon, 6 Jun 2011 07:57:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A4842153D30; Mon, 6 Jun 2011 15:57:57 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1307372277; bh=s1bYwuWnvVYuiS FJ/fImbAmu37lquWP27QJ+nRj0CN8=; b=ulf5Q9kaGM3sh2l6VGp2F2djcD3B2o YwNuc5Aol+ZGRIvp+n5xOoZ3ASjnDMF5KD2a7XIwQgrAcbJ7oLhpb6mamuiUDJ0a vPXmAM2Zyw6Z5JKlsRp+XutKmdb0AoXT457xCslZE2OLXC+SAc8VFrxRJnHHITQL ZdPDCYU3Z69tL86Y5qZvQ3GTbFlTVIam6esM0x0TIrq4jdvP3WYi6JHi8tCdPAgX cNJ4qbZhumf2HxXbfe28WecXP/yWSPVKqXlGfCJgubFwpSm1jp9BJFf47LhOSAAG Qrvat0BqSLZhhfelrAjuxVjam75z+pckZXuVKoj4X1vZeFmpeX7OAYMw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id sivl18R+rZnE; Mon, 6 Jun 2011 15:57:57 +0100 (IST) Received: from [10.87.48.9] (unknown [86.42.182.86]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id C24B2153D2F; Mon, 6 Jun 2011 15:57:56 +0100 (IST) Message-ID: <4DECEAEF.9080103@cs.tcd.ie> Date: Mon, 06 Jun 2011 15:57:51 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Randy Bush References: <4DAF44AC.8060408@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> <4DECDFA0.9080109@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 14:57:58 -0000 On 06/06/11 15:37, Randy Bush wrote: >> That's why I suggested "MUST implement SSH; SHOULD implement TCP-AO; >> MUST prefer TCP-AO if both available" > > indeed, we may have to fall back to this. we still do not have for sure > committments that all vendors can do this. but we're working it. Cool. I'm happy to help with that to the extent that I can. > folk such as russ and sean are more tuned to timing and constraints than > i. my job here is just to hammer on the operational realities of > delivery. I fully agree that delivery is very important in this case. > but anything that folk can do to move AO from the powerpoint platform to > the *BSD, Linux, and Solaris platforms will have long-term pay-off for > both BGP and RPKI-Rtr. Agreed again. S. From Sandra.Murphy@cobham.com Mon Jun 6 09:48: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 4813911E8178 for ; Mon, 6 Jun 2011 09:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqFm0FEWbuCm for ; Mon, 6 Jun 2011 09:48:15 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9AB11E8177 for ; Mon, 6 Jun 2011 09:48:14 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p56GmDfZ015856; Mon, 6 Jun 2011 11:48:13 -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 p56GmDiP031206; Mon, 6 Jun 2011 11:48:13 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.109]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Jun 2011 12:48:13 -0400 Date: Mon, 6 Jun 2011 12:48:13 -0400 (Eastern Daylight Time) From: Sandra Murphy To: draft-ietf-sidr-iana-objects@tools.ietf.org, sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 06 Jun 2011 16:48:13.0790 (UTC) FILETIME=[86C18FE0:01CC2469] Subject: [sidr] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC (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: Mon, 06 Jun 2011 16:48:16 -0000 I'm curious. Could the authors of draft-ietf-sidr-iana-objects comment on whether the action mentioned below would have any effect on the rules for IANA issued objects wrt RFC3068 prefixes? --Sandy, speaking as wg chair ---------- Forwarded message ---------- Date: Mon, 6 Jun 2011 09:23:26 -0700 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce Cc: v6ops@ietf.org Subject: Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Experience with the "Connection of IPv6 Domains via IPv4 Clouds (6to4)" IPv6 transitioning mechanism has shown that the mechanism is unsuitable for widespread deployment and use in the Internet. This document requests that RFC3056 and the companion document "An Anycast Prefix for 6to4 Relay Routers" RFC3068 are moved to historic status. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From terry.manderson@icann.org Mon Jun 6 17:36: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 C2E2A21F85B1 for ; Mon, 6 Jun 2011 17:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiF8yIa6-u3H for ; Mon, 6 Jun 2011 17:36:23 -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 755E021F8583 for ; Mon, 6 Jun 2011 17:36:23 -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, 6 Jun 2011 17:36:18 -0700 From: Terry Manderson To: Sandra Murphy , "draft-ietf-sidr-iana-objects@tools.ietf.org" , "sidr@ietf.org" Date: Mon, 6 Jun 2011 17:36:17 -0700 Thread-Topic: [sidr] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC Thread-Index: AcwkaZajUyYKFuFRSOywGeRZjy5dIQAQVMES 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 Subject: Re: [sidr] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 07 Jun 2011 00:36:24 -0000 Hi Sandy, Wearing just the iana-objects author hat. It would require a small amount of editing, which in turn will ultimately result in the prefixes (as termed 'deprecated') being considered unallocate= d - and therefore an AS0-ROA SHOULD (eventually) be issued for 2002::/16 and 192.88.99.0/24. The question I have is about trying to intrude on the RFC-Editor queue now, while the iana-objects is having all the boxes ticked and is well ahead of draft-ietf-v6ops-6to4-to-historic-04, or wait for publication of v6ops-6to4-to-historic and (as already covered in iana-objects) issue an update. Cheers Terry On 7/06/11 2:48 AM, "Sandra Murphy" wrote: > I'm curious. >=20 > Could the authors of draft-ietf-sidr-iana-objects comment on whether the > action mentioned below would have any effect on the rules for IANA issued > objects wrt RFC3068 prefixes? >=20 > --Sandy, speaking as wg chair >=20 > ---------- Forwarded message ---------- > Date: Mon, 6 Jun 2011 09:23:26 -0700 > From: The IESG > Reply-To: ietf@ietf.org > To: IETF-Announce > Cc: v6ops@ietf.org > Subject: Last Call: (Request t= o > move > Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status= ) to > Informational RFC >=20 >=20 > The IESG has received a request from the IPv6 Operations WG (v6ops) to > consider the following document: > - 'Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to > Historic status' > as an Informational RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-06-20. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > Experience with the "Connection of IPv6 Domains via IPv4 Clouds > (6to4)" IPv6 transitioning mechanism has shown that the mechanism is > unsuitable for widespread deployment and use in the Internet. This > document requests that RFC3056 and the companion document "An Anycast > Prefix for 6to4 Relay Routers" RFC3068 are moved to historic status. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Mon Jun 6 23:38: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 7590C21F85CE for ; Mon, 6 Jun 2011 23:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+j-roTBt3WO for ; Mon, 6 Jun 2011 23:38:52 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 10D1121F85CF for ; Mon, 6 Jun 2011 23:38:51 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=hbn-eduroam-0034.rhi.hi.is.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QTptr-000APj-81; Tue, 07 Jun 2011 06:36:27 +0000 Date: Tue, 07 Jun 2011 06:36:25 +0000 Message-ID: From: Randy Bush To: Terry Manderson 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: "draft-ietf-sidr-iana-objects@tools.ietf.org" , Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 07 Jun 2011 06:38:52 -0000 > The question I have is about trying to intrude on the RFC-Editor queue > now, while the iana-objects is having all the boxes ticked and is well > ahead of draft-ietf-v6ops-6to4-to-historic-04, or wait for publication > of v6ops-6to4-to-historic and (as already covered in iana-objects) > issue an update. if you are asking this question, perhaps you should be asking why it is not a registry. randy From internet-drafts@ietf.org Tue Jun 7 00:58: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 6E5FD11E8075; Tue, 7 Jun 2011 00:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYcw1EyCeSLl; Tue, 7 Jun 2011 00:58:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAACB11E8081; Tue, 7 Jun 2011 00:58:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110607075843.5071.14069.idtracker@ietfa.amsl.com> Date: Tue, 07 Jun 2011 00:58:43 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-manifests-13.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 07:58:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : Manifests for the Resource Public Key Infrastructure Author(s) : Rob Austein Geoff Huston Stephen Kent Matt Lepinski Filename : draft-ietf-sidr-rpki-manifests-13.txt Pages : 19 Date : 2011-06-07 This document defines a "manifest" for use in the Resource Pub= lic Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority, that are published at this repository publication point, the manifest contains both the name of the file containing the object, and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (= valid) data and deletion of signed objects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-manifests-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-rpki-manifests-13.txt From internet-drafts@ietf.org Tue Jun 7 15:10: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 BACA811E80A7; Tue, 7 Jun 2011 15:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0N8YqcqcCAwu; Tue, 7 Jun 2011 15:10:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5830711E8072; Tue, 7 Jun 2011 15:10:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110607221044.2687.51459.idtracker@ietfa.amsl.com> Date: Tue, 07 Jun 2011 15:10:44 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-manifests-14.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 22:10:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : Manifests for the Resource Public Key Infrastructure Author(s) : Rob Austein Geoff Huston Stephen Kent Matt Lepinski Filename : draft-ietf-sidr-rpki-manifests-14.txt Pages : 19 Date : 2011-06-07 This document defines a "manifest" for use in the Resource Pub= lic Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority, that are published at this repository publication point, the manifest contains both the name of the file containing the object, and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (= valid) data and deletion of signed objects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-manifests-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-rpki-manifests-14.txt From internet-drafts@ietf.org Tue Jun 7 15:15: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 5C1D611E80B5; Tue, 7 Jun 2011 15:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGCuUwMnYq-n; Tue, 7 Jun 2011 15:15:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE3111E8071; Tue, 7 Jun 2011 15:15:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110607221544.31254.47222.idtracker@ietfa.amsl.com> Date: Tue, 07 Jun 2011 15:15:44 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-repos-struct-08.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 22:15:45 -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 Resource Certificate Repository Structure Author(s) : Geoff Huston Robert Loomans George Michaelson Filename : draft-ietf-sidr-repos-struct-08.txt Pages : 15 Date : 2011-06-07 This document defines a profile for the structure of the Resource PKI distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509 / PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile defines the recommended object (file) naming scheme, the recommended contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and facilitate certification path construction. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-repos-struct-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-repos-struct-08.txt From terry.manderson@icann.org Tue Jun 7 16:48: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 EC45621F84EE for ; Tue, 7 Jun 2011 16:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfYywNJJwhMZ for ; Tue, 7 Jun 2011 16:48:34 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCBA21F84ED for ; Tue, 7 Jun 2011 16:48:34 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 7 Jun 2011 16:48:34 -0700 From: Terry Manderson To: Randy Bush Date: Tue, 7 Jun 2011 16:48:31 -0700 Thread-Topic: [sidr] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC Thread-Index: Acwk3WRrWyyxTcJVRwi+iakv9Was+wAkANg6 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-iana-objects@tools.ietf.org" , Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 07 Jun 2011 23:48:35 -0000 It was an IETF process question, not a document structure question. .T On 7/06/11 4:36 PM, "Randy Bush" wrote: >> The question I have is about trying to intrude on the RFC-Editor queue >> now, while the iana-objects is having all the boxes ticked and is well >> ahead of draft-ietf-v6ops-6to4-to-historic-04, or wait for publication >> of v6ops-6to4-to-historic and (as already covered in iana-objects) >> issue an update. >=20 > if you are asking this question, perhaps you should be asking why it is > not a registry. >=20 > randy From randy@psg.com Wed Jun 8 00:22: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 0B37011E809F for ; Wed, 8 Jun 2011 00:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JifiEPIdzl-s for ; Wed, 8 Jun 2011 00:22:19 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 1E23A11E807B for ; Wed, 8 Jun 2011 00:22:19 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=hbn-eduroam-0034.rhi.hi.is.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QUD3u-000DyU-Tl; Wed, 08 Jun 2011 07:20:23 +0000 Date: Wed, 08 Jun 2011 07:20:21 +0000 Message-ID: From: Randy Bush To: Terry Manderson 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: "draft-ietf-sidr-iana-objects@tools.ietf.org" , Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 08 Jun 2011 07:22:20 -0000 > It was an IETF process question, not a document structure question. >>> The question I have is about trying to intrude on the RFC-Editor queue >>> now, while the iana-objects is having all the boxes ticked and is well >>> ahead of draft-ietf-v6ops-6to4-to-historic-04, or wait for publication >>> of v6ops-6to4-to-historic and (as already covered in iana-objects) >>> issue an update. >> >> if you are asking this question, perhaps you should be asking why it is >> not a registry. the question may have been about spacecraft fuel. but it made pretty clear that there was a problem with the document structure which will reappear. randy From terry.manderson@icann.org Wed Jun 8 00:49: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 08B0421F850A for ; Wed, 8 Jun 2011 00:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3IQgwdkEsW5 for ; Wed, 8 Jun 2011 00:49:22 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 899F621F8508 for ; Wed, 8 Jun 2011 00:49:22 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 8 Jun 2011 00:49:21 -0700 From: Terry Manderson To: Randy Bush Date: Wed, 8 Jun 2011 00:50:17 -0700 Thread-Topic: [sidr] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC Thread-Index: AcwlsJP6nUYgyztcRd6hktkJhnBFzA== Message-ID: <1550D23E-DFC6-4B7D-B5F0-AA02432C6FF1@icann.org> 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: "draft-ietf-sidr-iana-objects@tools.ietf.org" , Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 08 Jun 2011 07:49:23 -0000 Perhaps, but the issue you allude to is more about calling out routing inte= ntion in each and every RFC that requests a reservation or special use allo= cation from IANA. This has ramifications elsewhere, so for now I firmly bel= ieve that the document structure is sound for what is required for the time= ly deployment of RPKI. Cheers, Terry On 08/06/2011, at 5:21 PM, "Randy Bush" wrote: >> It was an IETF process question, not a document structure question. >>>> The question I have is about trying to intrude on the RFC-Editor queue >>>> now, while the iana-objects is having all the boxes ticked and is well >>>> ahead of draft-ietf-v6ops-6to4-to-historic-04, or wait for publication >>>> of v6ops-6to4-to-historic and (as already covered in iana-objects) >>>> issue an update. >>>=20 >>> if you are asking this question, perhaps you should be asking why it is >>> not a registry. >=20 > the question may have been about spacecraft fuel. but it made pretty > clear that there was a problem with the document structure which will > reappear. >=20 > randy From randy@psg.com Wed Jun 8 00:56: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 49D4E21F855B for ; Wed, 8 Jun 2011 00:56: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bq38UHA0p7tU for ; Wed, 8 Jun 2011 00:56:44 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id CFB3A21F855C for ; Wed, 8 Jun 2011 00:56:44 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=hbn-eduroam-0034.rhi.hi.is.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QUDcv-000ERp-6o; Wed, 08 Jun 2011 07:56:33 +0000 Date: Wed, 08 Jun 2011 07:56:31 +0000 Message-ID: From: Randy Bush To: Terry Manderson In-Reply-To: <1550D23E-DFC6-4B7D-B5F0-AA02432C6FF1@icann.org> References: <1550D23E-DFC6-4B7D-B5F0-AA02432C6FF1@icann.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "draft-ietf-sidr-iana-objects@tools.ietf.org" , Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 08 Jun 2011 07:56:45 -0000 > Perhaps, but the issue you allude to is more about calling out routing > intention in each and every RFC that requests a reservation or special > use allocation from IANA. not really. it's about the mess that is about to be made by (from the document) If IANA is directed to issue additional RPKI objects in future, this document will be revised and a new version issued. and before it is even published, a new version is needed. this is a problem. we have a standard way of solving this problem, and iana registry. > I firmly believe that the document structure is sound for what is > required for the timely deployment of RPKI. this entire doc is pretty irrelevant to timely deployment of the rpki, as can be seen by running code. randy From Sandra.Murphy@cobham.com Wed Jun 8 07:18: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 9F20521F85B8 for ; Wed, 8 Jun 2011 07:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVTVY0I7Vy3A for ; Wed, 8 Jun 2011 07:18:14 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 71F5021F85B3 for ; Wed, 8 Jun 2011 07:18:14 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p58EID5m013283; Wed, 8 Jun 2011 09:18:13 -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 p58EICBo006119; Wed, 8 Jun 2011 09:18:13 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([192.168.0.106]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Jun 2011 10:18:12 -0400 Date: Wed, 8 Jun 2011 10:18:11 -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: 08 Jun 2011 14:18:12.0468 (UTC) FILETIME=[E6605340:01CC25E6] Cc: "draft-ietf-sidr-iana-objects@tools.ietf.org" Subject: Re: [sidr] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 08 Jun 2011 14:18:16 -0000 OK, folks, so I see two possibilities mentioned here. (1) Retract the iana-objects draft, update it wrt prefix status changes, and send it back to the RFC-Editor to wait until and if the IESG approves the 6to4-to-historic draft. (2) Let the iana-objects draft progress, begin work on a -bis immediately. (The -bis could introduce a registry, if that looks like a good option.) As I see it, process wise: (1) eliminates the half-skip step of publishing an RFC known to be facing obsolesence in short order but induces a delay in IANA actions for these iana objects. (2) avoids the planned obsolesence but does not impede IANA actions for these iana objects. Comments from the group, please, as soon as possible. --Sandy, speaking as wg chair P.S. Note that there is an option (2+) which would produce the -bis so fast (and with care to be compatible with any IESG decision on 6to4) that it would overtake the iana-objects draft on the RFC Editor queue. :-) On Tue, 7 Jun 2011, Randy Bush wrote: >> The question I have is about trying to intrude on the RFC-Editor queue >> now, while the iana-objects is having all the boxes ticked and is well >> ahead of draft-ietf-v6ops-6to4-to-historic-04, or wait for publication >> of v6ops-6to4-to-historic and (as already covered in iana-objects) >> issue an update. > > if you are asking this question, perhaps you should be asking why it is > not a registry. > > randy > From gih@apnic.net Wed Jun 8 08:02:49 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C97321F84EF for ; Wed, 8 Jun 2011 08:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.278 X-Spam-Level: X-Spam-Status: No, score=-95.278 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, RELAY_IS_220=2.118, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKvtud1Ejf5y for ; Wed, 8 Jun 2011 08:02:48 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id CA4B221F8531 for ; Wed, 8 Jun 2011 08:02:45 -0700 (PDT) Received: from [10.40.102.245] (unknown [220.241.199.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 69B14B673D; Thu, 9 Jun 2011 01:02:42 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Thu, 9 Jun 2011 01:02:40 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <76A9C9D8-3BC3-4A00-8F2E-7461C3DF59B1@apnic.net> References: <1550D23E-DFC6-4B7D-B5F0-AA02432C6FF1@icann.org> To: Randy Bush , "sidr@ietf.org wg" X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-sidr-iana-objects@tools.ietf.org, Sandra Murphy Subject: Re: [sidr] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 08 Jun 2011 15:02:49 -0000 On 08/06/2011, at 5:56 PM, Randy Bush wrote: >> Perhaps, but the issue you allude to is more about calling out = routing >> intention in each and every RFC that requests a reservation or = special >> use allocation from IANA. >=20 > not really. it's about the mess that is about to be made by (from the > document) >=20 > If IANA is directed to issue additional RPKI objects in future, this > document will be revised and a new version issued. >=20 > and before it is even published, a new version is needed. this is a > problem. we have a standard way of solving this problem, and iana > registry. >=20 +1 In my opinion, it would be better to amend this doc to direct the IANA = to set up a registry and then use the registry update processes to make = amendments as and when required as distinct from pumping out -bis -bis = bis etc etc cruft in the RFCs >> I firmly believe that the document structure is sound for what is >> required for the timely deployment of RPKI. >=20 -1 Geoff From Sandra.Murphy@cobham.com Wed Jun 8 08: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 A3DED11E80E3 for ; Wed, 8 Jun 2011 08:13: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8aIgH02sQJc for ; Wed, 8 Jun 2011 08:13:46 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id E8E2311E80AD for ; Wed, 8 Jun 2011 08:13:45 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p58FDgdo014488; Wed, 8 Jun 2011 10:13:42 -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 p58FDd0c009052; Wed, 8 Jun 2011 10:13:39 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([192.168.0.106]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Jun 2011 11:13:39 -0400 Date: Wed, 8 Jun 2011 11:13:38 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Geoff Huston In-Reply-To: <76A9C9D8-3BC3-4A00-8F2E-7461C3DF59B1@apnic.net> Message-ID: References: <1550D23E-DFC6-4B7D-B5F0-AA02432C6FF1@icann.org> <76A9C9D8-3BC3-4A00-8F2E-7461C3DF59B1@apnic.net> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 08 Jun 2011 15:13:39.0259 (UTC) FILETIME=[A54C58B0:01CC25EE] Cc: draft-ietf-sidr-iana-objects@tools.ietf.org, "sidr@ietf.org wg" Subject: Re: [sidr] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 08 Jun 2011 15:13:47 -0000 Geoff, I think you are voting for my option (1): retract draft and amend. Correct? --Sandy On Thu, 9 Jun 2011, Geoff Huston wrote: > > On 08/06/2011, at 5:56 PM, Randy Bush wrote: > >>> Perhaps, but the issue you allude to is more about calling out routing >>> intention in each and every RFC that requests a reservation or special >>> use allocation from IANA. >> >> not really. it's about the mess that is about to be made by (from the >> document) >> >> If IANA is directed to issue additional RPKI objects in future, this >> document will be revised and a new version issued. >> >> and before it is even published, a new version is needed. this is a >> problem. we have a standard way of solving this problem, and iana >> registry. >> > > +1 > > In my opinion, it would be better to amend this doc to direct the IANA to set up a registry and then use the registry update processes to make amendments as and when required as distinct from pumping out -bis -bis bis etc etc cruft in the RFCs > >>> I firmly believe that the document structure is sound for what is >>> required for the timely deployment of RPKI. >> > > -1 > > > Geoff > > From gih@apnic.net Wed Jun 8 08:36: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 A549011E80F0 for ; Wed, 8 Jun 2011 08:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.278 X-Spam-Level: X-Spam-Status: No, score=-95.278 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, RELAY_IS_220=2.118, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5yGpa1TbKaR for ; Wed, 8 Jun 2011 08:36:07 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id A2F6A11E8095 for ; Wed, 8 Jun 2011 08:36:06 -0700 (PDT) Received: from [10.40.102.245] (unknown [220.241.199.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 23D1DB66C9; Thu, 9 Jun 2011 01:36:00 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Thu, 9 Jun 2011 01:35:59 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <8ACC6C58-ECA3-4821-9144-CDC25B5206AA@apnic.net> References: <1550D23E-DFC6-4B7D-B5F0-AA02432C6FF1@icann.org> <76A9C9D8-3BC3-4A00-8F2E-7461C3DF59B1@apnic.net> To: Sandra Murphy X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-sidr-iana-objects@tools.ietf.org, "sidr@ietf.org wg" Subject: Re: [sidr] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 08 Jun 2011 15:36:07 -0000 On 09/06/2011, at 1:13 AM, Sandra Murphy wrote: > Geoff, I think you are voting for my option (1): retract draft and = amend. >=20 > Correct? If an offered opinion can be construed as a "vote", then yes.=20 (And I've offered a gratuitous suggestion as to what would be a = productive form of amendment, in my opinion.) Geoff From paul.hoffman@vpnc.org Wed Jun 8 08:43: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 3C4C211E819D for ; Wed, 8 Jun 2011 08:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7g0jAor-uZ-t for ; Wed, 8 Jun 2011 08:43:25 -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 0510F11E8158 for ; Wed, 8 Jun 2011 08:43:24 -0700 (PDT) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p58FhJsA073380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Jun 2011 08:43:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Wed, 8 Jun 2011 08:43:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sandra Murphy X-Mailer: Apple Mail (2.1084) Cc: "draft-ietf-sidr-iana-objects@tools.ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 08 Jun 2011 15:43:26 -0000 On Jun 8, 2011, at 7:18 AM, Sandra Murphy wrote: > OK, folks, so I see two possibilities mentioned here. >=20 > (1) Retract the iana-objects draft, update it wrt prefix status = changes, and send it back to the RFC-Editor to wait until and if the = IESG approves the 6to4-to-historic draft. >=20 > (2) Let the iana-objects draft progress, begin work on a -bis = immediately. (The -bis could introduce a registry, if that looks like a = good option.) >=20 > As I see it, process wise: >=20 > (1) eliminates the half-skip step of publishing an RFC known to be = facing obsolesence in short order but induces a delay in IANA actions = for these iana objects. >=20 > (2) avoids the planned obsolesence but does not impede IANA actions = for these iana objects. >=20 > Comments from the group, please, as soon as possible. Those of us following the discussion on the ietf@ietf.org list know that = it is far from clear that draft-ietf-v6ops-6to4-to-historic is going to = be adopted by the IETF. It has gotten a lot of push-back. Given that, #2 seems like the better option. The new draft simply needs = to pull all the data from the in-queue RFC and make a registry for it. = Developers follow the RFC-to-be for now, then follow the registry when = it is created. > P.S. Note that there is an option (2+) which would produce the -bis = so fast (and with care to be compatible with any IESG decision on 6to4) = that it would overtake the iana-objects draft on the RFC Editor queue. = :-) Which IETF have you been participating in where that kind of speed seems = even remotely possible? :-( --Paul Hoffman From Sandra.Murphy@cobham.com Wed Jun 8 08:46: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 ABC4E11E81B5 for ; Wed, 8 Jun 2011 08:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbM9cbq4d5pv for ; Wed, 8 Jun 2011 08:46:15 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF9711E81D1 for ; Wed, 8 Jun 2011 08:46:00 -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 p58FjwPd015171; Wed, 8 Jun 2011 10:45:58 -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 p58FjwUh010776; Wed, 8 Jun 2011 10:45:59 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([192.168.0.106]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Jun 2011 11:45:57 -0400 Date: Wed, 8 Jun 2011 11:45:56 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Paul Hoffman 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: 08 Jun 2011 15:45:57.0763 (UTC) FILETIME=[28BC9530:01CC25F3] Cc: "draft-ietf-sidr-iana-objects@tools.ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 08 Jun 2011 15:46:16 -0000 On Wed, 8 Jun 2011, Paul Hoffman wrote: > On Jun 8, 2011, at 7:18 AM, Sandra Murphy wrote: > >> OK, folks, so I see two possibilities mentioned here. >> >> (1) Retract the iana-objects draft, update it wrt prefix status changes, and send it back to the RFC-Editor to wait until and if the IESG approves the 6to4-to-historic draft. >> >> (2) Let the iana-objects draft progress, begin work on a -bis immediately. (The -bis could introduce a registry, if that looks like a good option.) >> >> As I see it, process wise: >> >> (1) eliminates the half-skip step of publishing an RFC known to be facing obsolesence in short order but induces a delay in IANA actions for these iana objects. >> >> (2) avoids the planned obsolesence but does not impede IANA actions for these iana objects. >> >> Comments from the group, please, as soon as possible. > > Those of us following the discussion on the ietf@ietf.org list know that it is far from clear that draft-ietf-v6ops-6to4-to-historic is going to be adopted by the IETF. It has gotten a lot of push-back. > > Given that, #2 seems like the better option. The new draft simply needs to pull all the data from the in-queue RFC and make a registry for it. Developers follow the RFC-to-be for now, then follow the registry when it is created. > >> P.S. Note that there is an option (2+) which would produce the -bis so fast (and with care to be compatible with any IESG decision on 6to4) that it would overtake the iana-objects draft on the RFC Editor queue. :-) > > Which IETF have you been participating in where that kind of speed seems even remotely possible? :-( Hence the smiley. --Sandy, as wg member only. > > --Paul Hoffman > > From jgs@juniper.net Wed Jun 8 11:31: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 0E63521F8599 for ; Wed, 8 Jun 2011 11:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yARZWa99yf3y for ; Wed, 8 Jun 2011 11:31:55 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id CEE8521F8598 for ; Wed, 8 Jun 2011 11:31:54 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTe/AFZqAMXNQBnjzeDXL8weqX3MFxTxG@postini.com; Wed, 08 Jun 2011 11:31:54 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 8 Jun 2011 11:30:18 -0700 From: John Scudder To: Stephen Farrell Date: Wed, 8 Jun 2011 11:30:16 -0700 Thread-Topic: [sidr] WGLC draft-sidr-rpki-rtr - take 2? Thread-Index: AcwmCh4GwUUVgfSTTkSQpJ9Bzo3rsg== Message-ID: <5B8DC276-52BF-4D33-852F-61CE520B3C74@juniper.net> References: <4DAF44AC.8060408@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> <4DECDFA0.9080109@cs.tcd.ie> In-Reply-To: <4DECDFA0.9080109@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 18:31:56 -0000 On Jun 6, 2011, at 10:09 AM, Stephen Farrell wrote: ... > That's why I suggested "MUST implement SSH; SHOULD implement > TCP-AO; MUST prefer TCP-AO if both available" The penny finally dropped and I realized there is a better reason why SSH i= sn't desirable, and neither is TLS or any other solution layered on top of = TCP: they don't protect the transport. Recall why TCP-MD5 was introduced (= from RFC 2385): The primary motivation for this option is to allow BGP to protect itself against the introduction of spoofed TCP segments into the connection stream. Of particular concern are TCP resets. Any protocol layered over TCP can't address this concern. =20 While authentication of peer identity and integrity of the transported data= are even more important than transport protection per se for RPKI-RTR, it = would seem prudent to assume that any threats that affect BGP may also affe= ct RPKI-RTR. That means protecting the transport from reset attacks, and t= hat means AO, IPSec or MD5. =20 --John= From terry.manderson@icann.org Wed Jun 8 16:35: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 3E4A821F8504 for ; Wed, 8 Jun 2011 16:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+Bu87aEaCFz for ; Wed, 8 Jun 2011 16:35:34 -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 5E9D721F8505 for ; Wed, 8 Jun 2011 16:35:34 -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; Wed, 8 Jun 2011 16:35:33 -0700 From: Terry Manderson To: Paul Hoffman , Sandra Murphy Date: Wed, 8 Jun 2011 16:35:32 -0700 Thread-Topic: [sidr] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC Thread-Index: Acwl8uPgRwHuD0VITvmaCAtB7tUxYwAQd4Dy 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-iana-objects@tools.ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 08 Jun 2011 23:35:36 -0000 Interesting thread... I think it is unwise to retract the iana-objects draft. It says precisely what it needs to in that it describes the RPKI objects that need to be issued by IANA under the current implied routing assertions. I do not believe this document should create a new registry. What I have already drafted, but not uploaded as I am vacillating between target workgroups is a new (not -bis) small draft that: 1) Requests that IANA _extend_ all the existing IPv4/v6 registries to include an explicit global routing assertion. 2) Advises what language to put in future IANA considerations sections of drafts that request an allocation/reservation of prefixes. (..and probably updating rfc5226.) 3) Defines the rules for the existing allocations/reservations based on iana-objects. The reason I am flip-flopping between where to target this draft is that I'= m comfortable that quite a number of workgroups will want to provide input, a= s well as authors from previous drafts which have requested v4/v6 registry action. At this stage I thing GROW is the most appropriate workgroup for such a document as it doesn't specifically sit in the SIDR bailiwick. That said, I am more than happy to take the co-chair's guidance (noting Chris is also co-chair of GROW) on this topic. Cheers Terry On 9/06/11 1:43 AM, "Paul Hoffman" wrote: > On Jun 8, 2011, at 7:18 AM, Sandra Murphy wrote: >=20 >> OK, folks, so I see two possibilities mentioned here. >>=20 >> (1) Retract the iana-objects draft, update it wrt prefix status changes,= and >> send it back to the RFC-Editor to wait until and if the IESG approves th= e >> 6to4-to-historic draft. >>=20 >> (2) Let the iana-objects draft progress, begin work on a -bis immediatel= y. >> (The -bis could introduce a registry, if that looks like a good option.) >>=20 >> As I see it, process wise: >>=20 >> (1) eliminates the half-skip step of publishing an RFC known to be facin= g >> obsolesence in short order but induces a delay in IANA actions for these= iana >> objects. >>=20 >> (2) avoids the planned obsolesence but does not impede IANA actions for = these >> iana objects. >>=20 >> Comments from the group, please, as soon as possible. >=20 > Those of us following the discussion on the ietf@ietf.org list know that = it is > far from clear that draft-ietf-v6ops-6to4-to-historic is going to be adop= ted > by the IETF. It has gotten a lot of push-back. >=20 > Given that, #2 seems like the better option. The new draft simply needs t= o > pull all the data from the in-queue RFC and make a registry for it. Devel= opers > follow the RFC-to-be for now, then follow the registry when it is created= . >=20 >> P.S. Note that there is an option (2+) which would produce the -bis so = fast >> (and with care to be compatible with any IESG decision on 6to4) that it = would >> overtake the iana-objects draft on the RFC Editor queue. :-) >=20 > Which IETF have you been participating in where that kind of speed seems = even > remotely possible? :-( >=20 > --Paul Hoffman >=20 From randy@psg.com Thu Jun 9 01:30: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 0FE7A11E807E for ; Thu, 9 Jun 2011 01:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-P9bGAHgQ+h for ; Thu, 9 Jun 2011 01:30:43 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 9828111E807B for ; Thu, 9 Jun 2011 01:30:43 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=hbn-eduroam-0034.rhi.hi.is.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QUacI-000HhT-GX; Thu, 09 Jun 2011 08:29:26 +0000 Date: Thu, 09 Jun 2011 08:29:25 +0000 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: "draft-ietf-sidr-iana-objects@tools.ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 09 Jun 2011 08:30:44 -0000 > (1) Retract the iana-objects draft, update it wrt prefix status changes, > and send it back to the RFC-Editor to wait until and if the IESG approves > the 6to4-to-historic draft. > > (2) Let the iana-objects draft progress, begin work on a -bis immediately. > (The -bis could introduce a registry, if that looks like a good option.) either is fine with me. i suspect the former would be easiest on the rfc-editor. randy From randy@psg.com Thu Jun 9 01:57:01 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5361221F847A for ; Thu, 9 Jun 2011 01:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUN6tb1qQfIn for ; Thu, 9 Jun 2011 01:57:00 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 9573021F847C for ; Thu, 9 Jun 2011 01:57:00 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=hbn-eduroam-0034.rhi.hi.is.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QUb2u-000Hln-9j; Thu, 09 Jun 2011 08:56:56 +0000 Date: Thu, 09 Jun 2011 08:56:54 +0000 Message-ID: From: Randy Bush To: John Scudder In-Reply-To: <5B8DC276-52BF-4D33-852F-61CE520B3C74@juniper.net> References: <4DAF44AC.8060408@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> <4DECDFA0.9080109@cs.tcd.ie> <5B8DC276-52BF-4D33-852F-61CE520B3C74@juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list , Stephen Farrell Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 08:57:01 -0000 > The penny finally dropped and I realized there is a better reason why > SSH isn't desirable, and neither is TLS or any other solution layered > on top of TCP: they don't protect the transport. Recall why TCP-MD5 > was introduced (from RFC 2385): > > The primary motivation for this option is to allow BGP to protect > itself against the introduction of spoofed TCP segments into the > connection stream. Of particular concern are TCP resets. > > Any protocol layered over TCP can't address this concern. > > While authentication of peer identity and integrity of the transported > data are even more important than transport protection per se for > RPKI-RTR, it would seem prudent to assume that any threats that affect > BGP may also affect RPKI-RTR. That means protecting the transport > from reset attacks, and that means AO, IPSec or MD5. rpki-rtr != bgp the purpose of the wrap in rpki-rtr is authentication of the end-points. am i talking to the cache which i think i am? tcp session restart is actually doable in rpki-rtr. that is why the nonce is there. randy From internet-drafts@ietf.org Thu Jun 9 02:42: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 71CC9228003; Thu, 9 Jun 2011 02:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLfHzrPVeiSR; Thu, 9 Jun 2011 02:42:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1277A21F8489; Thu, 9 Jun 2011 02:42: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.55 Message-ID: <20110609094259.31955.8344.idtracker@ietfa.amsl.com> Date: Thu, 09 Jun 2011 02:42:59 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rescerts-provisioning-10.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 09:42: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 : A Protocol for Provisioning Resource Certificates Author(s) : Geoff Huston Robert Loomans Byron Ellacott Rob Austein Filename : draft-ietf-sidr-rescerts-provisioning-10.txt Pages : 32 Date : 2011-06-09 This document defines a framework for certificate management interactions between a resource issuer ("Issuer") and a resour= ce recipient ("Subject") through the specification of a protocol = for interaction between the two parties. The protocol supports the transmission of requests from the Subject, and corresponding responses from the Issuer encompassing the actions of certificate issuance, certificate revocation and certificate status information reports. This protocol is intended to be limited to the application of resource certificate management and is not intended to be used as part of a more general certificate management framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rescerts-provisioning-1= 0.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-rescerts-provisioning-10= .txt From ietf-ipr@ietf.org Thu Jun 9 07:56: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 1135421F8513; Thu, 9 Jun 2011 07:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VC+2Tideftha; Thu, 9 Jun 2011 07:56:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A2821F850A; Thu, 9 Jun 2011 07:56:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: pmohapat@cisco.com, jgs@juniper.net, dward@juniper.net, randy@psg.com, sra@hactrn.net, X-Test-IDTracker: no Message-ID: <20110609145649.31945.79682.idtracker@ietfa.amsl.com> Date: Thu, 09 Jun 2011 07:56:49 -0700 Cc: Sandra.Murphy@sparta.com, morrowc@ops-netman.net, sidr@ietf.org, adrian@olddog.co.uk, ipr-announce@ietf.org Subject: [sidr] IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-sidr-pfx-validate-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 14:56:50 -0000 Dear Pradosh Mohapatra, John Scudder, David Ward, Randy Bush, Rob Austein: An IPR disclosure that pertains to your Internet-Draft entitled "BGP Prefix Origin Validation" (draft-ietf-sidr-pfx-validate) was submitted to the IETF Secretariat on 2011-06-02 and has been posted on the "IETF Page of Intellec= tual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1569/). The = title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-ietf-si= dr- pfx-validate-01.""); The IETF Secretariat From Sandra.Murphy@cobham.com Thu Jun 9 12:23: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 F024611E80BF for ; Thu, 9 Jun 2011 12:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40U5Bg6LjL48 for ; Thu, 9 Jun 2011 12:23:18 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4493711E8097 for ; Thu, 9 Jun 2011 12:23:17 -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 p59JMk5u003384; Thu, 9 Jun 2011 14:22:46 -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 p59JMj6T028381; Thu, 9 Jun 2011 14:22:45 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.109]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Jun 2011 15:22:44 -0400 Date: Thu, 9 Jun 2011 15:22:43 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 09 Jun 2011 19:22:44.0545 (UTC) FILETIME=[9BCBC310:01CC26DA] Cc: andrew@ripe.net Subject: [sidr] transfer of resources and the RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 09 Jun 2011 19:23:19 -0000 Transfer of resources (both intra-RIR and inter-RIR) has been a hot topic recently in the RIRs. The RIRs have said that they are working on the process of accomplishing resource transfers wrt the RPKI. I believe the work of the SIDR WG would be aided by a better understanding of how the RIRs are considering doing transfer of resources in the RPKI. Would you share your ideas with the WG? This message is cc'd to the RIR staff who are my guess of the right people to answer the question. If I've missed the right person, please excuse me. --Sandy, speaking as wg chair From alexb@ripe.net Thu Jun 9 12:40: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 7CA2F11E8165 for ; Thu, 9 Jun 2011 12:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RADzp02Q22t8 for ; Thu, 9 Jun 2011 12:40:25 -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 E0EA411E813A for ; Thu, 9 Jun 2011 12:40:22 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QUl5S-00015m-Lq; Thu, 09 Jun 2011 21:40:17 +0200 Received: from mandrill.ripe.net ([193.0.1.209] helo=[IPv6:::1]) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1QUl5S-0004YS-7o; Thu, 09 Jun 2011 21:40:14 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alex Band In-Reply-To: Date: Thu, 9 Jun 2011 21:40:13 +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: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_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: ddd0bbf11d1e21354000f5f053f5ae69727b8169efadc222b6916051d55c03f8 Cc: sidr@ietf.org, Andrew de la Haye Subject: Re: [sidr] transfer of resources and the RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 09 Jun 2011 19:40:25 -0000 Tim Bruijnzeels (lead RPKI software engineer and regular IETF attendee) = should definitely be included. He is cc'd. Cheers, Alex On 9 Jun 2011, at 21:22, Sandra Murphy wrote: > Transfer of resources (both intra-RIR and inter-RIR) has been a hot = topic recently in the RIRs. The RIRs have said that they are working on = the process of accomplishing resource transfers wrt the RPKI. >=20 > I believe the work of the SIDR WG would be aided by a better = understanding of how the RIRs are considering doing transfer of = resources in the RPKI. Would you share your ideas with the WG? >=20 > This message is cc'd to the RIR staff who are my guess of the right = people to answer the question. If I've missed the right person, please = excuse me. >=20 > --Sandy, speaking as wg chair >=20 From terry.manderson@icann.org Thu Jun 9 18:00:06 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D5E21F8501 for ; Thu, 9 Jun 2011 18:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 531lVkv1q8Xk for ; Thu, 9 Jun 2011 18:00:05 -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 00E2621F84FF for ; Thu, 9 Jun 2011 18:00:05 -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; Thu, 9 Jun 2011 18:00:04 -0700 From: Terry Manderson To: sidr wg list Date: Thu, 9 Jun 2011 17:59:58 -0700 Thread-Topic: I-D Action: draft-manderson-sidr-geo-01.txt Thread-Index: AcwnCE51LGh50wSSTwStspvRcEDRHwAAWlop Message-ID: In-Reply-To: <20110610004921.5015.20702.idtracker@ietfa.amsl.com> 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 Subject: [sidr] FW: I-D Action: draft-manderson-sidr-geo-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 01:00:06 -0000 This document reflects the feedback from Prague both in the WG and around the halls, being: 1) Use cases? who wants this. 2) Privacy, bad idea to geotag ghostbusters, put in coordinates for just what you need. 3) Currency and 'legal', RPKI repository operator doesn't want to be responsible for stale geo data specifically. 4) Not specific enough, Don't limit it to the roa or alternatively, what about just the ASN? I would appreciate WG feedback. Cheers Terry ------ Forwarded Message > From: > Reply-To: > Date: Thu, 9 Jun 2011 17:49:21 -0700 > To: > Subject: I-D Action: draft-manderson-sidr-geo-01.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 > Title : Providing first class geographical location > statements for Internet Number Resources > Author(s) : Terry Manderson > Richard L. Barnes > Matt Lepinski > Filename : draft-manderson-sidr-geo-01.txt > Pages : 16 > Date : 2011-06-09 >=20 > This document describes the construction and use of the RPKI-GEO > record. This record provides first class informational statements > pertaining to the geographical attributes of the allocated Internet > Number Resources. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-manderson-sidr-geo-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-manderson-sidr-geo-01.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------ End of Forwarded Message From internet-drafts@ietf.org Sun Jun 12 01:53: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 BC0CF11E808A; Sun, 12 Jun 2011 01:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GK8SRLuwVwaH; Sun, 12 Jun 2011 01:53:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5CF228008; Sun, 12 Jun 2011 01:53: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.55 Message-ID: <20110612085358.15064.6873.idtracker@ietfa.amsl.com> Date: Sun, 12 Jun 2011 01:53:58 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-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: Sun, 12 Jun 2011 08:53:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : BGPSEC Protocol Specification Author(s) : Matthew Lepinski Filename : draft-ietf-sidr-bgpsec-protocol-00.txt Pages : 25 Date : 2011-06-11 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-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-protocol-00.txt From mlepinski@bbn.com Sun Jun 12 08:12: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 773AC11E80AB for ; Sun, 12 Jun 2011 08:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeL4yl--wriA for ; Sun, 12 Jun 2011 08:12:19 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6963A11E80A1 for ; Sun, 12 Jun 2011 08:12:19 -0700 (PDT) Received: from [128.89.253.17] (port=1246) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QVmKo-000J3J-FV for sidr@ietf.org; Sun, 12 Jun 2011 11:12:18 -0400 Message-ID: <4DF4D758.5090908@bbn.com> Date: Sun, 12 Jun 2011 11:12:24 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: sidr@ietf.org References: <20110612085358.15064.6873.idtracker@ietfa.amsl.com> In-Reply-To: <20110612085358.15064.6873.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-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: Sun, 12 Jun 2011 15:12:20 -0000 This is the first working group version of the BGPSEC protocol document. There are no significant technical changes since from the prior individual version. However, there were a number of clarifications/corrections to the text based on working group feedback. - Matt Lepinski On 6/12/2011 4:53 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. > > Title : BGPSEC Protocol Specification > Author(s) : Matthew Lepinski > Filename : draft-ietf-sidr-bgpsec-protocol-00.txt > Pages : 25 > Date : 2011-06-11 > > 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-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-protocol-00.txt > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From Sandra.Murphy@cobham.com Sun Jun 12 11:59:03 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A4411E8117 for ; Sun, 12 Jun 2011 11:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKbvC1VO87sf for ; Sun, 12 Jun 2011 11:59:02 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9736411E8114 for ; Sun, 12 Jun 2011 11:59:02 -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 p5CIx2jx005140 for ; Sun, 12 Jun 2011 13:59:02 -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 p5CIx1NV030529 for ; Sun, 12 Jun 2011 13:59:01 -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); Sun, 12 Jun 2011 14:59:01 -0400 Date: Sun, 12 Jun 2011 14:58:59 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 12 Jun 2011 18:59:02.0012 (UTC) FILETIME=[CB23B3C0:01CC2932] Subject: [sidr] transfer of resources and the RPKI (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: Sun, 12 Jun 2011 18:59:03 -0000 There's been a difficulty with the recipient list on the message I sent last week. Here is the message, with the cc list as I sent it. The archive only shows Andrew's address on the cc list and the personal copy I got back from the list only contains Andrew on the cc list. Alex's reply directly to me shows the entire cc list, so there's a good chance that the important people did see the message. However, the archived version again has just Andrew on the cc list. I've asked ietf-action for help here and I will check with the cc list to be certain they saw last week's message. --Sandy ---------- Forwarded message ---------- Date: Thu, 9 Jun 2011 15:22:43 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Cc: Nishal Goburdhan , bje@apnic.net, gih@apnic.net, Mark Kosters , Arturo Servin , andrew@ripe.net, alexb@ripe.net Subject: transfer of resources and the RPKI Transfer of resources (both intra-RIR and inter-RIR) has been a hot topic recently in the RIRs. The RIRs have said that they are working on the process of accomplishing resource transfers wrt the RPKI. I believe the work of the SIDR WG would be aided by a better understanding of how the RIRs are considering doing transfer of resources in the RPKI. Would you share your ideas with the WG? This message is cc'd to the RIR staff who are my guess of the right people to answer the question. If I've missed the right person, please excuse me. --Sandy, speaking as wg chair From Sandra.Murphy@cobham.com Sun Jun 12 13:10:00 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F16811E8127 for ; Sun, 12 Jun 2011 13:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boHPwPQruvOL for ; Sun, 12 Jun 2011 13:09:59 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0F82311E80C4 for ; Sun, 12 Jun 2011 13:09:58 -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 p5CK9wvR005390 for ; Sun, 12 Jun 2011 15:09:58 -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 p5CK9wWH031114 for ; Sun, 12 Jun 2011 15:09:58 -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); Sun, 12 Jun 2011 16:09:58 -0400 Date: Sun, 12 Jun 2011 16:09:57 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 12 Jun 2011 20:09:58.0248 (UTC) FILETIME=[B40DC680:01CC293C] Subject: Re: [sidr] transfer of resources and the RPKI (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: Sun, 12 Jun 2011 20:10:00 -0000 I may have found the explanation. The mailman nodupes field (which is set for sidr) is intended to prevent a list server copy from being sent to a recipient who is receiving a copy directly (thru cc or to). However, I found the following message on the ietf list, which says that some implementations have a "flaw" that seems to prune the cc list also. http://www.ietf.org/mail-archive/web/ietf/current/msg37128.html The important part is: ============== Specifics: Mailman has a per-recipient setting called "nodupes". The effect of this setting is that any recipient address that has the nodupes flag set, and which appears in a To or CC field of a message sent to the list, will not receive a copy of the message from the list. It also appears (from emperical testing with a limited sample) that the list may also remove that recipient's address from the CC field of the copy of the message sent to the list. ============== It's the "remove the recipient's address from the CC field" part that applies to this problem. This behavior creates an impression that some people were not copied on the message when they were. --Sandy On Sun, 12 Jun 2011, Sandra Murphy wrote: > There's been a difficulty with the recipient list on the message I sent last > week. > > Here is the message, with the cc list as I sent it. > > The archive only shows Andrew's address on the cc list and the personal copy > I got back from the list only contains Andrew on the cc list. > > Alex's reply directly to me shows the entire cc list, so there's a good > chance that the important people did see the message. However, the archived > version again has just Andrew on the cc list. > > I've asked ietf-action for help here and I will check with the cc list to be > certain they saw last week's message. > > --Sandy > > ---------- Forwarded message ---------- > Date: Thu, 9 Jun 2011 15:22:43 -0400 (Eastern Daylight Time) > From: Sandra Murphy > To: sidr@ietf.org > Cc: Nishal Goburdhan , bje@apnic.net, gih@apnic.net, > Mark Kosters , Arturo Servin , > andrew@ripe.net, alexb@ripe.net > Subject: transfer of resources and the RPKI > > Transfer of resources (both intra-RIR and inter-RIR) has been a hot topic > recently in the RIRs. The RIRs have said that they are working on the > process of accomplishing resource transfers wrt the RPKI. > > I believe the work of the SIDR WG would be aided by a better understanding of > how the RIRs are considering doing transfer of resources in the RPKI. Would > you share your ideas with the WG? > > This message is cc'd to the RIR staff who are my guess of the right people to > answer the question. If I've missed the right person, please excuse me. > > --Sandy, speaking as wg chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From aservin@lacnic.net Sun Jun 12 15:32: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 6364921F8481 for ; Sun, 12 Jun 2011 15:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.033 X-Spam-Level: X-Spam-Status: No, score=0.033 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, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+ITkH0oWxdB for ; Sun, 12 Jun 2011 15:32:12 -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 2DD3821F847F for ; Sun, 12 Jun 2011 15:32:12 -0700 (PDT) Received: from [192.168.1.100] (r186-48-202-103.dialup.adsl.anteldata.net.uy [186.48.202.103]) by mail.lacnic.net.uy (Postfix) with ESMTP id 81C1C30843E; Sun, 12 Jun 2011 19:32:04 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: Date: Sun, 12 Jun 2011 19:32:03 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <43374676-BAF6-4752-9564-DB774B40916D@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] transfer of resources and the RPKI (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: Sun, 12 Jun 2011 22:32:13 -0000 At least I received, I guess the others received the message as = well. Regarding the transfers and RPKI, as group (RIRs) we are working = on it. We have different scenarios with different trade-offs and we are = still discussing them. Nevertheless each idea gets complicate very = easily and it may be difficult to explain it by e-mail. I'll try to = document with the group some of the ideas that we have discussed and we = will share them with the WG. Just to start, one question that we have is that by "transfers" = you are referring to the space where a RIR is a majority holder and some = pieces of that space are allocated to another RIR (i.e. ERX), or to the = "new" transfers that may happen by the depletion of the IPv4 address = space. Best wishes, .as On 12 Jun 2011, at 15:58, Sandra Murphy wrote: > There's been a difficulty with the recipient list on the message I = sent last week. >=20 > Here is the message, with the cc list as I sent it. >=20 > The archive only shows Andrew's address on the cc list and the = personal copy I got back from the list only contains Andrew on the cc = list. >=20 > Alex's reply directly to me shows the entire cc list, so there's a = good chance that the important people did see the message. However, the = archived version again has just Andrew on the cc list. >=20 > I've asked ietf-action for help here and I will check with the cc list = to be certain they saw last week's message. >=20 > --Sandy >=20 > ---------- Forwarded message ---------- > Date: Thu, 9 Jun 2011 15:22:43 -0400 (Eastern Daylight Time) > From: Sandra Murphy > To: sidr@ietf.org > Cc: Nishal Goburdhan , bje@apnic.net, = gih@apnic.net, > Mark Kosters , Arturo Servin , > andrew@ripe.net, alexb@ripe.net > Subject: transfer of resources and the RPKI >=20 > Transfer of resources (both intra-RIR and inter-RIR) has been a hot = topic recently in the RIRs. The RIRs have said that they are working on = the process of accomplishing resource transfers wrt the RPKI. >=20 > I believe the work of the SIDR WG would be aided by a better = understanding of how the RIRs are considering doing transfer of = resources in the RPKI. Would you share your ideas with the WG? >=20 > This message is cc'd to the RIR staff who are my guess of the right = people to answer the question. If I've missed the right person, please = excuse me. >=20 > --Sandy, speaking as wg chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Sun Jun 12 21:22:36 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E29021F84FE for ; Sun, 12 Jun 2011 21:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9wrd-eBjRfq for ; Sun, 12 Jun 2011 21:22:35 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id B7C5521F84AE for ; Sun, 12 Jun 2011 21:22:35 -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 1QVyeI-0004DW-AX; Mon, 13 Jun 2011 04:21:14 +0000 Date: Sun, 12 Jun 2011 22:21:13 -0600 Message-ID: From: Randy Bush To: Arturo Servin In-Reply-To: <43374676-BAF6-4752-9564-DB774B40916D@lacnic.net> References: <43374676-BAF6-4752-9564-DB774B40916D@lacnic.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Sandra Murphy , sidr@ietf.org Subject: Re: [sidr] transfer of resources and the RPKI (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: Mon, 13 Jun 2011 04:22:36 -0000 > Just to start, one question that we have is that by "transfers" you > are referring to the space where a RIR is a majority holder and some > pieces of that space are allocated to another RIR (i.e. ERX), or to > the "new" transfers that may happen by the depletion of the IPv4 > address space. uh, how does running out of the free pool cause transfers? i suspect you are assuming a lot of layer nine causality here which may or may not hold and is not technically relevant. the issues is transfers of address between any two arbitrary holders. i.e., see http://archive.psg.com/071208.transfer.pdf randy From aservin@lacnic.net Mon Jun 13 08:41: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 3257821F854D for ; Mon, 13 Jun 2011 08:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3cPI8ZmphX5 for ; Mon, 13 Jun 2011 08:41:40 -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 8D1E921F853A for ; Mon, 13 Jun 2011 08:41:39 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (unknown [200.7.85.188]) by mail.lacnic.net.uy (Postfix) with ESMTP id 81178308446; Mon, 13 Jun 2011 12:41:18 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: Date: Mon, 13 Jun 2011 12:41:16 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <79BD3BCF-5F48-49E7-9076-7E8D5E6E774B@lacnic.net> References: <43374676-BAF6-4752-9564-DB774B40916D@lacnic.net> To: sidr@ietf.org 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: Sandra Murphy Subject: Re: [sidr] transfer of resources and the RPKI (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: Mon, 13 Jun 2011 15:41:41 -0000 On 13 Jun 2011, at 01:21, Randy Bush wrote: >> Just to start, one question that we have is that by "transfers" you >> are referring to the space where a RIR is a majority holder and some >> pieces of that space are allocated to another RIR (i.e. ERX), or to >> the "new" transfers that may happen by the depletion of the IPv4 >> address space. >=20 > uh, how does running out of the free pool cause transfers? Changes in RIRs inter-RIR-transfer policies, the trigger would = be the depletion of the IPv4, but let's focus on the technical stuff. > i suspect > you are assuming a lot of layer nine causality here which may or may > not hold and is not technically relevant. >=20 > the issues is transfers of address between any two arbitrary holders. >=20 > i.e., see >=20 > http://archive.psg.com/071208.transfer.pdf Thanks for the link. Let me read the document and I will post = some comments. >=20 > randy Regards, .as From Sandra.Murphy@cobham.com Mon Jun 13 09:09:02 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D28211E80D7 for ; Mon, 13 Jun 2011 09:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUxSRg5PhXQM for ; Mon, 13 Jun 2011 09:09:02 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id CC1F111E8093 for ; Mon, 13 Jun 2011 09:09:01 -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 p5DG8x9p013994; Mon, 13 Jun 2011 11:08:59 -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 p5DG8w7X018887; Mon, 13 Jun 2011 11:08:59 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([192.35.167.76]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Jun 2011 12:08:56 -0400 Date: Mon, 13 Jun 2011 12:08:52 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Arturo Servin In-Reply-To: <43374676-BAF6-4752-9564-DB774B40916D@lacnic.net> Message-ID: References: <43374676-BAF6-4752-9564-DB774B40916D@lacnic.net> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 13 Jun 2011 16:08:56.0177 (UTC) FILETIME=[32669E10:01CC29E4] Cc: sidr@ietf.org Subject: Re: [sidr] transfer of resources and the RPKI (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: Mon, 13 Jun 2011 16:09:02 -0000 On Sun, 12 Jun 2011, Arturo Servin wrote: > > At least I received, I guess the others received the message as well. > > Regarding the transfers and RPKI, as group (RIRs) we are working on it. We have different scenarios with different trade-offs and we are still discussing them. Nevertheless each idea gets complicate very easily and it may be difficult to explain it by e-mail. I'll try to document with the group some of the ideas that we have discussed and we will share them with the WG. > > Just to start, one question that we have is that by "transfers" you are referring to the space where a RIR is a majority holder and some pieces of that space are allocated to another RIR (i.e. ERX), or to the "new" transfers that may happen by the depletion of the IPv4 address space. I actually meant transfers in general, both intra-RIR and inter-RIR. I think information on all types of transfer would be helpful to the working group. --Sandy > > Best wishes, > .as > > On 12 Jun 2011, at 15:58, Sandra Murphy wrote: > >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > From bje@apnic.net Mon Jun 13 22:30: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 D5BC511E82B6 for ; Mon, 13 Jun 2011 22:30:10 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2UB-j2-EQFa for ; Mon, 13 Jun 2011 22:30:10 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id BD3C511E82B5 for ; Mon, 13 Jun 2011 22:30:09 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:21f:f3ff:fe8b:8df6] (unknown [IPv6:2001:dc0:a000:4:21f:f3ff:fe8b:8df6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 8F121B691E; Tue, 14 Jun 2011 15:30:07 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Byron Ellacott In-Reply-To: Date: Tue, 14 Jun 2011 15:30:07 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sandra Murphy X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: Re: [sidr] transfer of resources and the RPKI (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: Tue, 14 Jun 2011 05:30:10 -0000 To reassure the WG, I did see this message - but any comments I would = make would simply be repeating Arturo at this point. -- Byron, speaking for APNIC On 13/06/2011, at 4:58 AM, Sandra Murphy wrote: > There's been a difficulty with the recipient list on the message I = sent last week. >=20 > Here is the message, with the cc list as I sent it. >=20 > The archive only shows Andrew's address on the cc list and the = personal copy I got back from the list only contains Andrew on the cc = list. >=20 > Alex's reply directly to me shows the entire cc list, so there's a = good chance that the important people did see the message. However, the = archived version again has just Andrew on the cc list. >=20 > I've asked ietf-action for help here and I will check with the cc list = to be certain they saw last week's message. >=20 > --Sandy >=20 > ---------- Forwarded message ---------- > Date: Thu, 9 Jun 2011 15:22:43 -0400 (Eastern Daylight Time) > From: Sandra Murphy > To: sidr@ietf.org > Cc: Nishal Goburdhan , bje@apnic.net, = gih@apnic.net, > Mark Kosters , Arturo Servin , > andrew@ripe.net, alexb@ripe.net > Subject: transfer of resources and the RPKI >=20 > Transfer of resources (both intra-RIR and inter-RIR) has been a hot = topic recently in the RIRs. The RIRs have said that they are working on = the process of accomplishing resource transfers wrt the RPKI. >=20 > I believe the work of the SIDR WG would be aided by a better = understanding of how the RIRs are considering doing transfer of = resources in the RPKI. Would you share your ideas with the WG? >=20 > This message is cc'd to the RIR staff who are my guess of the right = people to answer the question. If I've missed the right person, please = excuse me. >=20 > --Sandy, speaking as wg chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From ietfc@btconnect.com Tue Jun 14 08:18: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 3875811E807F for ; Tue, 14 Jun 2011 08:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vs+EuaUusfzz for ; Tue, 14 Jun 2011 08:18:17 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr09.btconnect.com [213.123.26.187]) by ietfa.amsl.com (Postfix) with ESMTP id DE63E11E808D for ; Tue, 14 Jun 2011 08:18:16 -0700 (PDT) Received: from host81-156-207-154.range81-156.btcentralplus.com (HELO pc6) ([81.156.207.154]) by c2beaomr09.btconnect.com with SMTP id DGD02031; Tue, 14 Jun 2011 16:18:04 +0100 (BST) Message-ID: <001501cc2a9d$93f15300$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Geoff Huston" , "Randy Bush" , References: <1550D23E-DFC6-4B7D-B5F0-AA02432C6FF1@icann.org> <76A9C9D8-3BC3-4A00-8F2E-7461C3DF59B1@apnic.net> Date: Tue, 14 Jun 2011 16:14:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0303.4DF77BAB.0101, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.6.14.134814:17:7.586, ip=81.156.207.154, 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, __URI_NO_PATH, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0202.4DF77BAF.00D3,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: draft-ietf-sidr-iana-objects@tools.ietf.org, Sandra Murphy Subject: Re: [sidr] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds(6to4) to Historic status) to Informational RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 14 Jun 2011 15:18:18 -0000 ----- Original Message ----- From: "Geoff Huston" To: "Randy Bush" ; Cc: ; "Sandra Murphy" Sent: Wednesday, June 08, 2011 5:02 PM > > On 08/06/2011, at 5:56 PM, Randy Bush wrote: > > >> Perhaps, but the issue you allude to is more about calling out routing > >> intention in each and every RFC that requests a reservation or special > >> use allocation from IANA. > > > > not really. it's about the mess that is about to be made by (from the > > document) > > > > If IANA is directed to issue additional RPKI objects in future, this > > document will be revised and a new version issued. > > > > and before it is even published, a new version is needed. this is a > > problem. we have a standard way of solving this problem, and iana > > registry. > > > > +1 > > In my opinion, it would be better to amend this doc to direct the IANA to set up a registry and then use the registry update processes to make amendments as and when required as distinct from pumping out -bis -bis bis etc etc cruft in the RFCs I think I agree; it depends on how often this is going to happen. If a new address appears once a year or more often, then a registry is the right IETF technology for it. If it happens once every five years, then a -bis would seem better. Historically, these 'funny' addresses have been quite stable but of late, they seem to have become more frequent. My assumption is that in these migratory times, when either IPv6 becomes part of the furniture or else dark arts get practised with IPv4, then such addresses are likely to appear more often. So, registry it should be. Tom Petch > >> I firmly believe that the document structure is sound for what is > >> required for the timely deployment of RPKI. > > > > -1 > > > Geoff > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From kent@bbn.com Tue Jun 14 11:07: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 EBEF821F8508 for ; Tue, 14 Jun 2011 11:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmrfp-iFmTpU for ; Tue, 14 Jun 2011 11:07:45 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 25EF321F84FB for ; Tue, 14 Jun 2011 11:07:43 -0700 (PDT) Received: from dhcp89-089-178.bbn.com ([128.89.89.178]:49225) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QWY1V-0009Ll-Lp; Tue, 14 Jun 2011 14:07:33 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <43374676-BAF6-4752-9564-DB774B40916D@lacnic.net> Date: Tue, 14 Jun 2011 13:49:01 -0400 To: Randy Bush From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org, Sandra Murphy Subject: Re: [sidr] transfer of resources and the RPKI (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: Tue, 14 Jun 2011 18:07:46 -0000 At 10:21 PM -0600 6/12/11, Randy Bush wrote: > > Just to start, one question that we have is that by "transfers" you >> are referring to the space where a RIR is a majority holder and some >> pieces of that space are allocated to another RIR (i.e. ERX), or to >> the "new" transfers that may happen by the depletion of the IPv4 >> address space. > >uh, how does running out of the free pool cause transfers? i suspect >you are assuming a lot of layer nine causality here which may or may >not hold and is not technically relevant. > >the issues is transfers of address between any two arbitrary holders. > >i.e., see > > http://archive.psg.com/071208.transfer.pdf > >randy I think folks perceive that exhaustion of the IPv4 space is triggering some transfers that might not otherwise have occurred, because the going price may now be higher. Steve From internet-drafts@ietf.org Wed Jun 15 10:51: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 6C8D511E8119; Wed, 15 Jun 2011 10:51:43 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Jg7H4TFJ-xa; Wed, 15 Jun 2011 10:51:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFFA211E8081; Wed, 15 Jun 2011 10:51:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110615175142.10063.21658.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2011 10:51:42 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-overview-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 17:51:45 -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-00.txt Pages : 10 Date : 2011-06-15 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-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-overview-00.txt From iesg-secretary@ietf.org Thu Jun 16 07:59: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 D3BA79E8015; Thu, 16 Jun 2011 07:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.312 X-Spam-Level: X-Spam-Status: No, score=-102.312 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQzXgi7AGoZD; Thu, 16 Jun 2011 07:59:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE6E9E8007; Thu, 16 Jun 2011 07:59:20 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110616145920.1997.62212.idtracker@ietfa.amsl.com> Date: Thu, 16 Jun 2011 07:59:20 -0700 Cc: sidr@ietf.org Subject: [sidr] Last Call: (A Protocol for Provisioning Resource Certificates) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 14:59:21 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'A Protocol for Provisioning Resource Certificates' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a framework for certificate management interactions between a resource issuer ("Issuer") and a resource recipient ("Subject") through the specification of a protocol for interaction between the two parties. The protocol supports the transmission of requests from the Subject, and corresponding responses from the Issuer encompassing the actions of certificate issuance, certificate revocation and certificate status information reports. This protocol is intended to be limited to the application of resource certificate management and is not intended to be used as part of a more general certificate management framework. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-rescerts-provisioning/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-rescerts-provisioning/ No IPR declarations have been submitted directly on this I-D. Two downrefs occur in this document: RFC2986 and RFC5781. RFC5781 is already registered in the downref registry: http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry From iesg-secretary@ietf.org Fri Jun 17 07:37: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 BFEF211E80EC; Fri, 17 Jun 2011 07:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uibhOpkGeYUL; Fri, 17 Jun 2011 07:37:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C6211E80EB; Fri, 17 Jun 2011 07:37:57 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110617143757.3471.99041.idtracker@ietfa.amsl.com> Date: Fri, 17 Jun 2011 07:37:57 -0700 Cc: sidr mailing list , sidr chair , RFC Editor Subject: [sidr] Protocol Action: 'Manifests for the Resource Public Key Infrastructure' to Proposed Standard (draft-ietf-sidr-rpki-manifests-14.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, 17 Jun 2011 14:37:58 -0000 The IESG has approved the following document: - 'Manifests for the Resource Public Key Infrastructure' (draft-ietf-sidr-rpki-manifests-14.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-rpki-manifests/ Technical Summary This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed object issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. Working Group Summary This document specifies an object that is needed to protect against some attacks (deletion, replay, etc.) on repositories in the distributed RPKI. The need for this object was recognized by RPKI implementors and conveyed to the working group. The working group supported making this a mandatory part of the repository system. Document Quality The document is well written and clear. Implementations of the RPKI exist, which must include this mandatory object, indicating a detailed coding level review. Implemenation experience has been reflected in changes to this document. Personnel Sandra Murphy is the Document Shepherd for this document. Stewart Bryant is the Responsible Area Director. From aservin@lacnic.net Fri Jun 17 09:23: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 01AB69E800B for ; Fri, 17 Jun 2011 09:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCN1F7drc-fz for ; Fri, 17 Jun 2011 09:23:15 -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 9D8359E8008 for ; Fri, 17 Jun 2011 09:23:14 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (unknown [200.7.85.188]) by mail.lacnic.net.uy (Postfix) with ESMTP id BA1BB30842B; Fri, 17 Jun 2011 13:23:01 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-224--691900716 From: Arturo Servin In-Reply-To: Date: Fri, 17 Jun 2011 13:23:00 -0300 Message-Id: <0B26FC5C-CE28-4626-83F4-8CDECAB65E00@lacnic.net> References: <20110226204501.11290.30784.idtracker@localhost> To: Roque Gagliano 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 wg" Subject: Re: [sidr] I-D Action:draft-ietf-sidr-algorithm-agility-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 16:23:17 -0000 --Apple-Mail-224--691900716 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Roque, Some comments about the draft. I think that in phase 3 it is implicit that CAs must sign using = algs A and B (it's a must in phase 2). Wouldn't be a good idea to make = an explicit statement in phase 3 as well? There are some indent issues with some of the examples, i.e: |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA) |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA) |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA) |-> CA-Z-Signed-Objects-Algorithm-Suite-A |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA) |-> CA-Y-Signed-Objects-Algorithm-Suite-A |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA) |-> CA-X-Signed-Objects-Algorithm-Suite-A I guess it should be something like: CA X-Certificate-Algorithm-Suite-A (Cert-XA) | |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA) |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA) |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA) |-> CA-Z-Signed-Objects-Algorithm-Suite-A |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA) |-> CA-Y-Signed-Objects-Algorithm-Suite-A |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA) |-> CA-X-Signed-Objects-Algorithm-Suite-A In phase 4 the table has indent issues too. And after the table, this text is confusing: ""All signed products sets issued using the Algorithm Suite A = MUST be published at their corresponding publication point but signed products sets issued using the Algorithm Suite C MAY be published at their corresponding publication points." Do you mean? "All signed products sets issued using the Algorithm Suite A and = Algorithm Suite C MUST be published at their corresponding publication points." In section 5 I have a basic question What happen if the child = ask the parent to sign with Alg. B but the parent only supports A, it = just fails? Is there any message defined in the up/down specification to = deal with this and signal the error? Section 6 answered a question that I had when I was reading the = first part of the draft: "As a general rule, the validation of signed products using different = algorithm suites are independent and the RP MUST NOT keep any relationship between the different hierarchies" Also it says that an object is valid if it is = valid in algs. A OR B. May be it would be good to mention this somewhere = in the first part of the document but without going to too much detail. Also in the same section 6, I think that there is important to = mention that in phase 0 (coming back to) the objects signed with C are = not longer valid. Finally, Section 9. I would prefer a MUST instead. I think that's all so far. Best wishes, -as On 27 Feb 2011, at 19:51, Roque Gagliano wrote: > Dear WG, >=20 > We just submitted the -00 version of this algorithm agility draft, now = as a WG item.=20 >=20 > The document includes the different changes requested since Beijing = from the individual submission, notably: > 1. Change form "laisez faire" to "top-down" > 2. Included Multi Algorithm support in the RPKI provisioning > protocol >=20 > 3. Included Validation of multiple instance of signed products >=20 > 4. Included Revocations >=20 > 5. Included Key rollover >=20 > 6. Included Repository structure >=20 > 7. Included Security Considerations >=20 > 8. Included Acknowledgements >=20 > We look forward for your comments. > Regards, > Roque. >=20 >=20 > On Feb 26, 2011, at 9:45 PM, Internet-Drafts@ietf.org wrote: >=20 >> 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. >>=20 >>=20 >> Title : Algorithm Agility Procedure for RPKI. >> Author(s) : R. Gagliano, et al. >> Filename : draft-ietf-sidr-algorithm-agility-00.txt >> Pages : 25 >> Date : 2011-02-26 >>=20 >> This document specifies the process that Certificate Authorities >> (CAs) and Relying Parties (RP) participating in the Resource Public >> Key Infrastructure (RPKI) will need to follow to transition to a new >> (and probably cryptographically stronger) algorithm set. The process >> is expected to be completed in a time scale of months or years. >> Consequently, no emergency transition is specified. The transition >> procedure defined in this document support only a top-down migration >> (parent migrates before children). >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-ietf-sidr-algorithm-agility-00.t= xt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-224--691900716 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Some comments about the = draft.

I think that in phase 3 it is = implicit that CAs must sign using algs A and B (it's a must in phase 2). = Wouldn't be a good idea to make an explicit statement in phase 3 as = well?

There are some indent issues with = some of the examples, i.e:

       =     |-> CA-Y-Certificate-Algorithm-Suite-A = (Cert-YA)
               =     |-> CA-Z-Certificate-Algorithm-Suite-A = (Cert-ZA)
               = |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
       =                     = |-> CA-Z-Signed-Objects-Algorithm-Suite-A
     =               |-> = CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
         =           |-> = CA-Y-Signed-Objects-Algorithm-Suite-A
       =     |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
   =         |-> = CA-X-Signed-Objects-Algorithm-Suite-A

I = guess it should be something like:

CA = X-Certificate-Algorithm-Suite-A (Cert-XA)
       =     |
           |-> = CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
     =               |-> = CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
     =              |-> = CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
         =                   |-> = CA-Z-Signed-Objects-Algorithm-Suite-A
       =             |-> = CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
         =           |-> = CA-Y-Signed-Objects-Algorithm-Suite-A
       =     |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
   =         |-> = CA-X-Signed-Objects-Algorithm-Suite-A


<= div> = In phase 4 the table has indent issues = too.

And after the table, this text is = confusing:

""All  signed products sets = issued using the Algorithm Suite A MUST be
   published = at their corresponding publication point but signed
   = products sets issued using the Algorithm Suite C MAY be published = at
   their corresponding publication points."

Do you = mean?

"All  signed products sets issued using the Algorithm = Suite A and Algorithm Suite C MUST be
   published at their = corresponding publication points."

In = section 5 I have a basic question What happen if the child ask the = parent to sign with Alg. B but the parent only supports A, it just = fails? Is there any message defined in the up/down specification to deal = with this and signal the error?

Section 6 = answered a question that I had when I was reading the first part of the = draft:

"As a general rule, the validation = of signed products using different algorithm suites = are
   independent and the RP MUST NOT keep any = relationship between the
   different hierarchies" Also it = says that an object is valid if it is valid in algs. A OR B. May be it = would be good to mention this somewhere in the first part of the = document but without going to too much = detail.

Also in the same section 6, I = think that there is important to mention that in phase 0 (coming back = to) the objects signed with C are not longer = valid.

Finally, Section 9. I would = prefer a MUST instead.

I think = that's all so far.

Best = wishes,
-as

On 27 Feb 2011, at 19:51, = Roque Gagliano wrote:

Dear WG,

We = just submitted the -00 version of this algorithm agility draft, now as a = WG item. 

The document includes the = different changes requested since Beijing from the individual = submission, notably:
1. Change form = "laisez faire" to "top-down"
   =
2.  Included Multi Algorithm support in the RPKI provisioning
       protocol

   3.  Included Validation of multiple instance of signed products

   4.  Included Revocations

   5.  Included Key rollover

   6.  Included Repository structure

   7.  Included Security Considerations

   8.  Included Acknowledgements


We look =
forward for your comments.
Regards,
Roque.


On = Feb 26, 2011, at 9:45 PM, Internet-Drafts@ietf.org = wrote:

A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of the Secure = Inter-Domain Routing Working Group of the IETF.


Title =           : Algorithm = Agility Procedure for RPKI.
Author(s) =       : R. Gagliano, et al.
Filename =        : = draft-ietf-sidr-algorithm-agility-00.txt
Pages =           : = 25
= Date =            : = 2011-02-26

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

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sidr-algorithm-= agility-00.txt

Internet-Drafts are also available by = anonymous FTP at:
ftp://ftp.ietf.org/internet-d= rafts/

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.
<Mail = Attachment>_______________________________________________
si= dr mailing list
sidr@ietf.org
https://www.ietf.org/ma= ilman/listinfo/sidr

__________= _____________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/m= ailman/listinfo/sidr

= --Apple-Mail-224--691900716-- From kent@bbn.com Mon Jun 20 14: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 EE9D71F0C51 for ; Mon, 20 Jun 2011 14:06:39 -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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQxzoGmVJigA for ; Mon, 20 Jun 2011 14:06:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB1B1F0C45 for ; Mon, 20 Jun 2011 14:06:38 -0700 (PDT) Received: from dhcp89-089-178.bbn.com ([128.89.89.178]:49191) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QYlg3-000F0p-3P; Mon, 20 Jun 2011 17:06:36 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <0B26FC5C-CE28-4626-83F4-8CDECAB65E00@lacnic.net> References: <20110226204501.11290.30784.idtracker@localhost> <0B26FC5C-CE28-4626-83F4-8CDECAB65E00@lacnic.net> Date: Mon, 20 Jun 2011 15:02:21 -0400 To: Arturo Servin From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-903518502==_ma============" Cc: "sidr@ietf.org wg" Subject: Re: [sidr] I-D Action:draft-ietf-sidr-algorithm-agility-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, 20 Jun 2011 21:06:40 -0000 --============_-903518502==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Arturo, Let me reply to a couple of the questions you raised, in my role as a co-author. >Roque, > >... > And after the table, this text is confusing: > > ""All signed products sets issued using the Algorithm Suite A MUST be > published at their corresponding publication point but signed > products sets issued using the Algorithm Suite C MAY be published at > their corresponding publication points." > > Do you mean? > >"All signed products sets issued using the Algorithm Suite A and >Algorithm Suite C MUST be > published at their corresponding publication points." I agree that several areas of text are confusing. The problems starts in 4.7, which says: Phase 4 starts at the Algorithm B Twilight Date. At that date, the Algorithm A is labeled as "old" and the Algorithm B is labeled as "current": The text should probably say: Phase 4 starts at the Algorithm A Twilight Date. At that date, the Algorithm A is labeled as "old" and the Algorithm B is labeled as "current" After the diagram, the text says: During this phase, all signed product sets MUST be issued using the Algorithm Suite A and MAY be issued using the Algorithm Suite C. All signed products sets issued using the Algorithm Suite A MUST be published at their corresponding publication point but signed products sets issued using the Algorithm Suite C MAY be published at their corresponding publication points. Also, every RP MUST validate signed product sets using the Algorithm Suite A but also MAY validate signed product sets using the Algorithm Suite C. To avoid confusion (because we re-label the alg suites during this phase), we probably should say something like: During this phase, all signed product sets MUST be issued using Algorithm Suite A (formerly B) and MAY be issued using Algorithm Suite C (formerly A). All signed products sets issued using Suite A MUST be published at their corresponding publication points, but signed products sets issued using Suite C MAY be published at their corresponding publication points. Also, every RP MUST validate signed product sets using Suite A but also MAY validate signed product sets using Suite C. > > In section 5 I have a basic question What happen if the child >ask the parent to sign with Alg. B but the parent only supports A, >it just fails? Is there any message defined in the up/down >specification to deal with this and signal the error? The short answer is yes. Based on feedback we received after briefing this to SIDR at an IETF meeting, we adopted a top-down algorithm transition model. So, a child can request a cert under the new alg ONLY after its parent has begun to offer that alg for its signed products. This is stated in 4.2: In order to facilitate the transition, CAs will start issuing certificates using the Algorithm B in a hierarchical top-down order. In our example, CA Y will issue certificates using the Algorithm B suite only after CA X has started to do so (CA Y Ready Algorithm B Date > CA X Ready Algorithm B Date). This ordered transition avoids the existence of mixed certificates. >... > > Also in the same section 6, I think that there is important >to mention that in phase 0 (coming back to) the objects signed with >C are not longer valid. Section 4.8 (Return to Phase 0) says: At this phase, ALL signed product sets using Algorithm Suite C MUST be considered invalid. CAs MUST neither issue nor publish signed products using Algorithm Suite C. Section 6 discusses how to deal with signed products when more than one instance exists, under different alg suites. Since 4.8 says that CAs MUST NOT issue or publish Suite C products, I don't think we need to say anything in section 6. Hope this helps, Steve --============_-903518502==_ma============ Content-Type: text/html; charset="us-ascii" Re: [sidr] I-D Action:draft-ietf-sidr-algorithm-agility-00
Arturo,

Let me reply to a couple of the questions you raised, in my role as a co-author.

Roque,

...
        And after the table, this text is confusing:

        ""All  signed products sets issued using the Algorithm Suite A MUST be
   published at their corresponding publication point but signed
   products sets issued using the Algorithm Suite C MAY be published at
   their corresponding publication points."

      Do you mean?

"All  signed products sets issued using the Algorithm Suite A and Algorithm Suite C MUST be
   published at their corresponding publication points."

I agree that several areas of text are confusing. The problems starts in 4.7, which says:

   Phase 4 starts at the Algorithm B Twilight Date.  At that date, the
   Algorithm A is labeled as "old" and the Algorithm B is labeled as
   "current":
The text should probably say:

   Phase 4 starts at the Algorithm A Twilight Date.  At that date, the
   Algorithm A is labeled as "old" and the Algorithm B is labeled as
   "current"

After the diagram, the text says:

   During this phase, all signed product sets MUST be issued using the
   Algorithm Suite A and MAY be issued using the Algorithm Suite C. All
   signed products sets issued using the Algorithm Suite A MUST be
   published at their corresponding publication point but signed
   products sets issued using the Algorithm Suite C MAY be published at
   their corresponding publication points.  Also, every RP MUST validate
   signed product sets using the Algorithm Suite A but also MAY validate
   signed product sets using the Algorithm Suite C.

To avoid confusion (because we re-label the alg suites during this phase), we probably should say something like:

   During this phase, all signed product sets MUST be issued using
   Algorithm Suite A (formerly B) and MAY be issued using Algorithm Suite
   C (formerly A). All signed products sets issued using Suite A MUST be
   published at their corresponding publication points, but signed
   products sets issued using Suite C MAY be published at their corresponding
   publication points.  Also, every RP MUST validate  signed product sets using
   Suite A but also MAY validate signed product sets using Suite C.


        In section 5 I have a basic question What happen if the child ask the parent to sign with Alg. B but the parent only supports A, it just fails? Is there any message defined in the up/down specification to deal with this and signal the error?

The short answer is yes. Based on feedback we received after briefing this
to SIDR at an IETF meeting, we adopted a top-down algorithm transition model.
So, a child can request a cert under the new alg ONLY after its parent has
begun to offer that alg for its signed products. This is stated in 4.2:

   In order to facilitate the transition, CAs will start issuing
   certificates using the Algorithm B in a hierarchical top-down order.
   In our example, CA Y will issue certificates using the Algorithm B
   suite only after CA X has started to do so (CA Y Ready Algorithm B
   Date > CA X Ready Algorithm B Date).  This ordered transition avoids
   the existence of mixed certificates.

...

        Also in the same section 6, I think that there is important to mention that in phase 0 (coming back to) the objects signed with C are not longer valid.

Section 4.8 (Return to Phase 0) says:
        At this phase, ALL signed product sets using Algorithm Suite
        C MUST be considered invalid.  CAs MUST neither issue nor publish
        signed products using Algorithm Suite C.

Section 6 discusses how to deal with signed products when more than one
instance exists, under different alg suites.  Since 4.8 says that CAs MUST
NOT issue or publish Suite C products, I don't think we need to say anything
in section 6.


Hope this helps,

Steve
--============_-903518502==_ma============-- From hannes@juniper.net Tue Jun 21 03:00: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 B31239E802B for ; Tue, 21 Jun 2011 03:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbmgiY5H7NvM for ; Tue, 21 Jun 2011 03:00:05 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 640409E804A for ; Tue, 21 Jun 2011 03:00:05 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTgBroXyCqbvmwyTixUWVlPYqX6WDmExQ@postini.com; Tue, 21 Jun 2011 03:00:05 PDT Received: from hannes-755.juniper.net (172.23.2.43) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.2.254.0; Tue, 21 Jun 2011 02:56:36 -0700 Received: by hannes-755.juniper.net (Postfix, from userid 1000) id 74F8F25A28; Tue, 21 Jun 2011 11:56:36 +0200 (CEST) Date: Tue, 21 Jun 2011 11:56:36 +0200 From: Hannes Gredler To: Message-ID: <20110621095634.GA8806@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [sidr] tcpdump supportf for rpki-rtr protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 21 Jun 2011 10:00:09 -0000 fyi - have added some code to tcpdump.org which may help in debugging interop issues; https://github.com/mcr/tcpdump/commit/917f5f341f4901bde415293be911903362c1fbfe verbose output looks like this: 12:37:23.335204 IP (tos 0x0, ttl 64, id 27027, offset 0, flags [DF], proto TCP (6), length 332) 1.3.0.2.2222 > 1.3.0.1.57487: Flags [P.], cksum 0x4fab (correct), seq 1:281, ack 9, win 32763, options [nop,nop,TS val 485909147 ecr 485909145], length 280 RPKI-RTRv0, Cache Response PDU (3), length: 8 Cache-Nonce: 0x0000 RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 IPv4 Prefix 0.0.0.0/0-14, origin-as 16, flags 0x01 RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 IPv4 Prefix 31.1.0.0/16-16, origin-as 1100, flags 0x01 RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 IPv4 Prefix 41.0.0.0/8-17, origin-as 100, flags 0x01 RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 IPv4 Prefix 41.0.0.0/10-13, origin-as 200, flags 0x01 RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 IPv4 Prefix 41.0.0.0/11-14, origin-as 300, flags 0x01 RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 IPv4 Prefix 41.0.0.0/12-16, origin-as 400, flags 0x01 RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 IPv4 Prefix 41.0.0.0/13-18, origin-as 500, flags 0x01 RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 IPv4 Prefix 41.0.0.0/14-25, origin-as 600, flags 0x01 RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 IPv4 Prefix 41.0.0.0/18-26, origin-as 700, flags 0x01 RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 IPv4 Prefix 41.0.0.0/19-28, origin-as 800, flags 0x01 RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 IPv4 Prefix 41.0.0.0/24-32, origin-as 900, flags 0x01 RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 IPv4 Prefix 41.0.0.0/32-32, origin-as 1100, flags 0x01 RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 IPv4 Prefix 91.0.0.0/10-16, origin-as 3320, flags 0x01 RPKI-RTRv0, End of Data PDU (7), length: 12 Cache-Nonce: 0x0000, Serial: 1 tx, /hannes From randy@psg.com Tue Jun 21 03:19: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 7101B9E8046 for ; Tue, 21 Jun 2011 03:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvbgsMAk0kN7 for ; Tue, 21 Jun 2011 03:19:49 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id D168B9E802B for ; Tue, 21 Jun 2011 03: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 1QYy2T-0003FD-6K; Tue, 21 Jun 2011 10:18:33 +0000 Date: Tue, 21 Jun 2011 19:18:32 +0900 Message-ID: From: Randy Bush To: Hannes Gredler In-Reply-To: <20110621095634.GA8806@juniper.net> References: <20110621095634.GA8806@juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] tcpdump supportf for rpki-rtr protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 21 Jun 2011 10:19:50 -0000 > fyi - have added some code to tcpdump.org which may help in debugging interop issues; w00t! thank you randy From aservin@lacnic.net Tue Jun 21 08:47: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 B2E6D11E80AE for ; Tue, 21 Jun 2011 08:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PI4l2WdUz+Ck for ; Tue, 21 Jun 2011 08:47:23 -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 9E75111E807E for ; Tue, 21 Jun 2011 08:47:22 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (unknown [200.7.85.188]) by mail.lacnic.net.uy (Postfix) with ESMTP id 5A08A30841C; Tue, 21 Jun 2011 12:47:00 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: Date: Tue, 21 Jun 2011 12:46:59 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8C2E09DA-0A20-46AA-B5E2-403779391E0E@lacnic.net> References: <20110226204501.11290.30784.idtracker@localhost> <0B26FC5C-CE28-4626-83F4-8CDECAB65E00@lacnic.net> To: Stephen Kent 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 wg" Subject: Re: [sidr] I-D Action:draft-ietf-sidr-algorithm-agility-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:47:23 -0000 Stephen,=20 Thanks for the reply, it clarifies my questions. Just one nit: On 20 Jun 2011, at 16:02, Stephen Kent wrote: >=20 >=20 >> ... >>=20 >> Also in the same section 6, I think that there is important = to mention that in phase 0 (coming back to) the objects signed with C = are not longer valid. >=20 > Section 4.8 (Return to Phase 0) says: > At this phase, ALL signed product sets using Algorithm Suite > C MUST be considered invalid. CAs MUST neither issue nor = publish > signed products using Algorithm Suite C. >=20 > Section 6 discusses how to deal with signed products when more than = one > instance exists, under different alg suites. Since 4.8 says that CAs = MUST > NOT issue or publish Suite C products, I don't think we need to say = anything > in section 6. Would it be possible to say what to do to validate objects in = 4.5? Perhaps: " An RP that validates all signed product sets using both Algorithm Suite A or Algorithm Suite B, SHOULD expect the same results. Objects = are valid if they are signed using either Algorithm Suite A or Algorithm Suite B. " Or something like that. This is mention in 6, but I think it = would be good to mention it (very simply) before. Regards, -as =09 =09 From kent@bbn.com Tue Jun 21 08:59:34 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848F21F0C3C for ; Tue, 21 Jun 2011 08:59:34 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiYjq+yz96oi for ; Tue, 21 Jun 2011 08:59:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 129541F0C38 for ; Tue, 21 Jun 2011 08:59:34 -0700 (PDT) Received: from dhcp89-089-178.bbn.com ([128.89.89.178]:49158) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QZ3MR-000Pv4-UL; Tue, 21 Jun 2011 11:59:32 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <8C2E09DA-0A20-46AA-B5E2-403779391E0E@lacnic.net> References: <20110226204501.11290.30784.idtracker@localhost> <0B26FC5C-CE28-4626-83F4-8CDECAB65E00@lacnic.net> <8C2E09DA-0A20-46AA-B5E2-403779391E0E@lacnic.net> Date: Tue, 21 Jun 2011 11:59:26 -0400 To: Arturo Servin From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org wg" Subject: Re: [sidr] I-D Action:draft-ietf-sidr-algorithm-agility-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:59:34 -0000 At 12:46 PM -0300 6/21/11, Arturo Servin wrote: >Stephen, > > Thanks for the reply, it clarifies my questions. > > Just one nit: >... > > Would it be possible to say what to do to validate objects in >4.5? Perhaps: > >" > An RP that validates all signed product sets using both Algorithm > Suite A or Algorithm Suite B, SHOULD expect the same results. >Objects are valid if they are signed using either Algorithm > Suite A or Algorithm Suite B. >" > We could add text to 4.5 to make it clearer what an RP ought to do, but I fear that the text above might confuse an RP. When I read it I get the sense that different answers from the two alg suites indicates a problem. What we want to say is that an RP can use validated results from either set of signed objects. So, if you fetch both sets, and validate one set first, then you are done. if you try to validate one set and fail, then try the other. if that one validates, you are OK. Only of both sets cannot be validate is there a problem. Steve From internet-drafts@ietf.org Tue Jun 21 18:25: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 4A83011E8095; Tue, 21 Jun 2011 18:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpOSxZUfM1sr; Tue, 21 Jun 2011 18:25:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6703B9E8004; Tue, 21 Jun 2011 18:25:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110622012547.25022.29175.idtracker@ietfa.amsl.com> Date: Tue, 21 Jun 2011 18:25:47 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-usecases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 01:25:48 -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-02.txt Pages : 30 Date : 2011-06-21 This document provides use cases, directions, and interpretations for organizations and relying parties when creating or encountering RPKI object scenarios in the public RPKI in relation to the Internet routing system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-usecases-02.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-02.txt From terry.manderson@icann.org Tue Jun 21 18:37: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 9200021F8466 for ; Tue, 21 Jun 2011 18:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qvsJqIymGdm for ; Tue, 21 Jun 2011 18:37:06 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 6700B21F8465 for ; Tue, 21 Jun 2011 18:37:06 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 21 Jun 2011 18:37:05 -0700 From: Terry Manderson To: "sidr@ietf.org" Date: Tue, 21 Jun 2011 18:37:03 -0700 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-usecases-02.txt Thread-Index: Acwwe1/PHa5bdqYJRMa/7FfPatTv2QAAYM5v Message-ID: In-Reply-To: <20110622012547.25022.29175.idtracker@ietfa.amsl.com> 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 Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 01:37:07 -0000 Folks, Now that the various SIDR drafts that detail RPKI are almost out the door, we (the authors) have completed the interpretations of the rpki objects and have uploaded the latest. Review and feedback much appreciated! One item I will call out is that sidr-usecases follows the example in roa-format (section 3.3) where a single ROA is used that contains multiple specific ROAIPAddress elements, versus the position of origin-ops which suggests multiple ROAs. (neither is wrong BTW, just different approaches). eg a single ROA with: +----------------------------------------------+ | asID | address | maxLength | +----------------------------------------------+ | 64496 | 10.1.0.0/16 | 16 | | |-----------------------------------+ | | 10.1.0.0/20 | 20 | +----------------------------------------------+ versus 2 ROAs that contain ROA 1 +----------------------------------------------+ | asID | address | maxLength | +----------------------------------------------+ | 64496 | 10.1.0.0/16 | 16 | +----------------------------------------------+ ROA 2 +----------------------------------------------+ | asID | address | maxLength | +----------------------------------------------+ | 64496 | 10.1.0.0/16 | 16 | +----------------------------------------------+ Cheers Terry On 22/06/11 11:25 AM, "internet-drafts@ietf.org" wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Secure Inter-Domain Routing > Working Group of the IETF. >=20 > Title : Use Cases and Interpretation of RPKI Objects fo= r > Issuers and Relying Parties > Author(s) : Terry Manderson > Kotikalapudi Sriram > Russ White > Filename : draft-ietf-sidr-usecases-02.txt > Pages : 30 > Date : 2011-06-21 >=20 > This document provides use cases, directions, and interpretations for > organizations and relying parties when creating or encountering RPKI > object scenarios in the public RPKI in relation to the Internet > routing system. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-usecases-02.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-usecases-02.txt > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From rogaglia@cisco.com Wed Jun 22 01:39: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 C2CB811E80B6 for ; Wed, 22 Jun 2011 01:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uOU1Tg0uyNv for ; Wed, 22 Jun 2011 01:39:48 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id B378F11E80A6 for ; Wed, 22 Jun 2011 01:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=24350; q=dns/txt; s=iport; t=1308731987; x=1309941587; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=bZ5/Mvucux3QFRKbP7JufciYHojoPRSEVl0FsjvbL3o=; b=YON59FV3H0v2WpzmgUp5ZDjRIbZjnVyK/+qKAcrqx9J+Jl2ycLiMEY9z cX6xVyRm+XkYB+3mrqIPShu0T4CKpYQZGauhfiD0ygS/njlrouASSWjHV VwnuqawIFfU1PepFc+Lv6trNygAUFfBfrQhxxhZuotGeeV40YKbAHkfAa w=; X-Files: smime.p7s : 4389 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACapAU6Q/khN/2dsb2JhbABUpw53iHOhM549hi0EkWqQDg X-IronPort-AV: E=Sophos;i="4.65,405,1304294400"; d="p7s'?scan'208,217";a="37001760" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 22 Jun 2011 08:39:46 +0000 Received: from dhcp-144-254-20-200.cisco.com (dhcp-144-254-20-200.cisco.com [144.254.20.200]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5M8dkAH006986; Wed, 22 Jun 2011 08:39:46 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-538--287696063; protocol="application/pkcs7-signature"; micalg=sha1 From: Roque Gagliano In-Reply-To: <0B26FC5C-CE28-4626-83F4-8CDECAB65E00@lacnic.net> Date: Wed, 22 Jun 2011 10:39:43 +0200 Message-Id: <90AB52E1-6880-4BDE-9857-D484247444D4@cisco.com> References: <20110226204501.11290.30784.idtracker@localhost> <0B26FC5C-CE28-4626-83F4-8CDECAB65E00@lacnic.net> To: Arturo Servin X-Mailer: Apple Mail (2.1084) Cc: "sidr@ietf.org wg" Subject: Re: [sidr] I-D Action:draft-ietf-sidr-algorithm-agility-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 08:39:51 -0000 --Apple-Mail-538--287696063 Content-Type: multipart/alternative; boundary=Apple-Mail-537--287697644 --Apple-Mail-537--287697644 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Arturo, Thanks for your review. I will add some comments to Steve's response: > Roque, >=20 > Some comments about the draft. >=20 > I think that in phase 3 it is implicit that CAs must sign using = algs A and B (it's a must in phase 2). Wouldn't be a good idea to make = an explicit statement in phase 3 as well? >=20 > There are some indent issues with some of the examples, i.e: >=20 > |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA) > |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA) > |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA) > |-> CA-Z-Signed-Objects-Algorithm-Suite-A > |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA) > |-> CA-Y-Signed-Objects-Algorithm-Suite-A > |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA) > |-> CA-X-Signed-Objects-Algorithm-Suite-A >=20 > I guess it should be something like: >=20 > CA X-Certificate-Algorithm-Suite-A (Cert-XA) > | > |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA) > |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA) > |-> CA-Z-CRL-Algorithm-Suite-A = (CRL-ZA) > |-> CA-Z-Signed-Objects-Algorithm-Suite-A > |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA) > |-> CA-Y-Signed-Objects-Algorithm-Suite-A > |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA) > |-> CA-X-Signed-Objects-Algorithm-Suite-A >=20 >=20 > In phase 4 the table has indent issues too. >=20 (Roque) thanks, will correct. > And after the table, this text is confusing: >=20 > ""All signed products sets issued using the Algorithm Suite A = MUST be > published at their corresponding publication point but signed > products sets issued using the Algorithm Suite C MAY be published = at > their corresponding publication points." >=20 > Do you mean? >=20 > "All signed products sets issued using the Algorithm Suite A and = Algorithm Suite C MUST be > published at their corresponding publication points." >=20 (Roque) See Steve's answer > In section 5 I have a basic question What happen if the child = ask the parent to sign with Alg. B but the parent only supports A, it = just fails? Is there any message defined in the up/down specification to = deal with this and signal the error? >=20 (Roque) I want to add that each algorithm suite correspond to a = different "resource class" of the provisioning protocol. Consequently, = you would be trying to access a class that does not exist in the server = and you should get the error code : "1201 request - no such resource = class" Thanks! Roque > Section 6 answered a question that I had when I was reading the = first part of the draft: >=20 > "As a general rule, the validation of signed products using different = algorithm suites are > independent and the RP MUST NOT keep any relationship between the > different hierarchies" Also it says that an object is valid if it = is valid in algs. A OR B. May be it would be good to mention this = somewhere in the first part of the document but without going to too = much detail. >=20 > Also in the same section 6, I think that there is important to = mention that in phase 0 (coming back to) the objects signed with C are = not longer valid. >=20 > Finally, Section 9. I would prefer a MUST instead. >=20 > I think that's all so far. >=20 > Best wishes, > -as >=20 > On 27 Feb 2011, at 19:51, Roque Gagliano wrote: >=20 >> Dear WG, >>=20 >> We just submitted the -00 version of this algorithm agility draft, = now as a WG item.=20 >>=20 >> The document includes the different changes requested since Beijing = from the individual submission, notably: >> 1. Change form "laisez faire" to "top-down" >> 2. Included Multi Algorithm support in the RPKI provisioning >> protocol >>=20 >> 3. Included Validation of multiple instance of signed products >>=20 >> 4. Included Revocations >>=20 >> 5. Included Key rollover >>=20 >> 6. Included Repository structure >>=20 >> 7. Included Security Considerations >>=20 >> 8. Included Acknowledgements >>=20 >> We look forward for your comments. >> Regards, >> Roque. >>=20 >>=20 >> On Feb 26, 2011, at 9:45 PM, Internet-Drafts@ietf.org wrote: >>=20 >>> 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. >>>=20 >>>=20 >>> Title : Algorithm Agility Procedure for RPKI. >>> Author(s) : R. Gagliano, et al. >>> Filename : draft-ietf-sidr-algorithm-agility-00.txt >>> Pages : 25 >>> Date : 2011-02-26 >>>=20 >>> This document specifies the process that Certificate Authorities >>> (CAs) and Relying Parties (RP) participating in the Resource Public >>> Key Infrastructure (RPKI) will need to follow to transition to a new >>> (and probably cryptographically stronger) algorithm set. The = process >>> is expected to be completed in a time scale of months or years. >>> Consequently, no emergency transition is specified. The transition >>> procedure defined in this document support only a top-down migration >>> (parent migrates before children). >>>=20 >>> A URL for this Internet-Draft is: >>> = http://www.ietf.org/internet-drafts/draft-ietf-sidr-algorithm-agility-00.t= xt >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 --Apple-Mail-537--287697644 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Arturo,

Thanks for your review. I will add some = comments to Steve's response:


Roque,

Some = comments about the draft.

I think = that in phase 3 it is implicit that CAs must sign using algs A and B = (it's a must in phase 2). Wouldn't be a good idea to make an explicit = statement in phase 3 as well?

There are = some indent issues with some of the examples, i.e:

       =     |-> CA-Y-Certificate-Algorithm-Suite-A = (Cert-YA)
               =     |-> CA-Z-Certificate-Algorithm-Suite-A = (Cert-ZA)
               = |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
       =                     = |-> CA-Z-Signed-Objects-Algorithm-Suite-A
     =               |-> = CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
         =           |-> = CA-Y-Signed-Objects-Algorithm-Suite-A
       =     |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
   =         |-> = CA-X-Signed-Objects-Algorithm-Suite-A

I = guess it should be something like:

CA = X-Certificate-Algorithm-Suite-A (Cert-XA)
       =     |
           |-> = CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
     =               |-> = CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
     =              |-> = CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
         =                   |-> = CA-Z-Signed-Objects-Algorithm-Suite-A
       =             |-> = CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
         =           |-> = CA-Y-Signed-Objects-Algorithm-Suite-A
       =     |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
   =         |-> = CA-X-Signed-Objects-Algorithm-Suite-A


<= div> = In phase 4 the table has indent issues = too.


(Roque) thanks, will correct.


And after = the table, this text is confusing:

""All =  signed products sets issued using the Algorithm Suite A MUST = be
   published at their corresponding publication point = but signed
   products sets issued using the Algorithm = Suite C MAY be published at
   their corresponding = publication points."

Do you mean?

"All =  signed products sets issued using the Algorithm Suite A and = Algorithm Suite C MUST be
   published at their = corresponding publication = points."


= (Roque) See Steve's answer

In = section 5 I have a basic question What happen if the child ask the = parent to sign with Alg. B but the parent only supports A, it just = fails? Is there any message defined in the up/down specification to deal = with this and signal the = error?


<= div>(Roque) I want to add that each algorithm suite correspond to a = different "resource class" of the provisioning protocol. Consequently, = you would be trying to access a class that does not exist in the server = and you should get the error code : "1201 request - no such resource = class"

Thanks!

Ro= que

Section 6 answered a question = that I had when I was reading the first part of the = draft:

"As a general rule, the validation = of signed products using different algorithm suites = are
   independent and the RP MUST NOT keep any = relationship between the
   different hierarchies" Also it = says that an object is valid if it is valid in algs. A OR B. May be it = would be good to mention this somewhere in the first part of the = document but without going to too much = detail.

Also in the same section 6, I = think that there is important to mention that in phase 0 (coming back = to) the objects signed with C are not longer = valid.

Finally, Section 9. I would = prefer a MUST instead.

I think = that's all so far.

Best = wishes,
-as

On 27 Feb 2011, at 19:51, = Roque Gagliano wrote:

Dear WG,

We = just submitted the -00 version of this algorithm agility draft, now as a = WG item. 

The document includes the = different changes requested since Beijing from the individual = submission, notably:
1. Change form = "laisez faire" to "top-down"
   =
2.  Included Multi Algorithm support in the RPKI provisioning
       protocol

   3.  Included Validation of multiple instance of signed products

   4.  Included Revocations

   5.  Included Key rollover

   6.  Included Repository structure

   7.  Included Security Considerations

   8.  Included Acknowledgements


We look =
forward for your comments.
Regards,
Roque.


On = Feb 26, 2011, at 9:45 PM, Internet-Drafts@ietf.org = wrote:

A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of the Secure = Inter-Domain Routing Working Group of the IETF.


Title =           : Algorithm = Agility Procedure for RPKI.
Author(s) =       : R. Gagliano, et al.
Filename =        : = draft-ietf-sidr-algorithm-agility-00.txt
Pages =           : = 25
= Date =            : = 2011-02-26

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

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sidr-algorithm-= agility-00.txt

Internet-Drafts are also available by = anonymous FTP at:
ftp://ftp.ietf.org/internet-d= rafts/

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.
<Mail = Attachment>_______________________________________________
si= dr mailing list
sidr@ietf.org
https://www.ietf.org/m= ailman/listinfo/sidr

_____= __________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/m= ailman/listinfo/sidr


= --Apple-Mail-537--287697644-- --Apple-Mail-538--287696063 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXDCCBWYw ggROoAMCAQICEFyqcUyRFrhvN5s0SHw/EO4wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA1MTAwMDAwMDBaFw0x MjA1MTEyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5Sb3F1ZSBHYWdsaWFubzEhMB8GCSqGSIb3DQEJARYScm9nYWdsaWFAY2lz Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxIp28SUiJ/fiFYD/Nct8MUbG WJuPqSnhkfBYMFbbWfDDrHR8OXzK2LkWIuHY5aeAo1nalAQCO40oeTYt0cp9W++a7USNCEDQzgVN Rg0YMYL27YSQoVJnecO3u9wi0jjwhJGblWWxphaztdaMbqiChgND1PHqf7dcs4UjeUOhhKFk0/61 mTmduV721jrxj6ABIlUHAc7nXhKANtDbKdBZzEhM4dbzp6STKq65EQ3xRLVFIuapTgNVckvXtc1e Cyu4xLOLZgaD2aLq9JzBn9y/rFRMtf2euP/Nmzl7QRjAUjpPdo1n6NXWGDtNyR0lUrcJ/x1leccZ Gfj0eaqe+tpJmQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAG A1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29t L0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAsvqKrlga/tU0vyBtnBOj 4miDAZxou0/fN2wVEK7dRLzIQLYEJD35sELVhiP8v8wVHtgOeVHz9FyBEVqXmJ0RKy4kMC7gdQxj +t1MlqSTDShEaPMmiwaK6M1iJ9jpBL4JvoiirpHnQYGukkgvTUeqITWZ5ecg03nB3QHuab91Gc+n RZ1OKL4D4p5IkvzWhRlIAlxW9yGZyB8r9V6iu3+1SYEpPPUN3AYCxXeXrn8fJjkOoEodybRiGyfW pMpShpTZg2tHB7ZX162Ti3sRvwA2mktDMnBtEm1pXo15z7yieDUPmjVybMA4byV7AQcbIrjQj0eq c/biBsueC2KWoJY7TDCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEF BQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBG b3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5 MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwT j+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliW B6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGce dAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69s sQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOM Wev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0 cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtg hkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoG CCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCeg JYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4G CCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNV HREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN 7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqT OtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih /1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0D uFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRIfD8Q7jAJBgUr DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA2 MjIwODM5NDZaMCMGCSqGSIb3DQEJBDEWBBRpbZL8WIBm7zdMPpLMGKrApwOlwzCCAQMGCSsGAQQB gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBcqnFMkRa4bzebNEh8PxDuMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRI fD8Q7jANBgkqhkiG9w0BAQEFAASCAQBngLWUTWk8HRWFsO4xupJazHYFO2Qem+LKpceB235k1F8a Mb1QvDtoCmwKvZ8SF3jGI3Mo+DAcUlFOSD5f70bBdaEGbcE778PgOFmkYEmtkplDuciW9SQ+ecf7 2n9gljMrb95paBsL7dHA6HYMl279TYWXhigArCw352+UXRGOd663GJEju95pBOSVqzwAz6XdxkX6 jkFTOlRY3a/98/5xHxtKpEZ1CpRDjTRwoXV3jjpR4qnG8ACgzEb+P5zboVgQPTMXZdwv6Xk3Y87V cKHwF3v5TNkhlpdpd9U/xhuRAulcPQM5Q/wDGuavJ2eR8bL7VszlbhHAzJh+BKU82l/YAAAAAAAA --Apple-Mail-538--287696063-- From terry.manderson@icann.org Wed Jun 22 02:15:02 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E3611E80B9 for ; Wed, 22 Jun 2011 02:15:02 -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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8V17WXSnrNKh for ; Wed, 22 Jun 2011 02:15:01 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 915D611E8098 for ; Wed, 22 Jun 2011 02:15:01 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 22 Jun 2011 02:15:00 -0700 From: Terry Manderson To: Terry Manderson Date: Wed, 22 Jun 2011 02:14:56 -0700 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-usecases-02.txt Thread-Index: AcwwvN1lEMnvPK6yT8C6ZDw23vLCZw== 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: multipart/alternative; boundary="_000_B0B6EA738DFE4F4D90B273925D6BBFA6icannorg_" MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 09:15:02 -0000 --_000_B0B6EA738DFE4F4D90B273925D6BBFA6icannorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHNlY29uZCBST0EgKFJPQSAyKSBiZWxvdyB3b3VsZCBvZiBjb3Vyc2UgYmUgYWRkcmVzcyAx MC4xLjAuMC8yMCBtYXhsZW5ndGggIDIwLg0KDQpBcG9sb2dpZXMgZm9yIHRoZSBjdXQvcGFzdGUg ZXJyb3IuDQoNCkNoZWVycw0KVGVycnkNCg0KT24gMjIvMDYvMjAxMSwgYXQgMTE6MzcgQU0sICJU ZXJyeSBNYW5kZXJzb24iIDx0ZXJyeS5tYW5kZXJzb25AaWNhbm4ub3JnPG1haWx0bzp0ZXJyeS5t YW5kZXJzb25AaWNhbm4ub3JnPj4gd3JvdGU6DQoNCmEgc2luZ2xlIFJPQSB3aXRoOg0KICAgICAr LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgfCBh c0lEICAgICB8IGFkZHJlc3MgICAgICAgICAgIHwgbWF4TGVuZ3RoICAgICB8DQogICAgICstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICB8IDY0NDk2 ICAgIHwgMTAuMS4wLjAvMTYgICAgICAgfCAgICAxNiAgICAgICAgIHwNCiAgICAgfCAgICAgICAg ICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgIHwgICAgICAgICAg fCAxMC4xLjAuMC8yMCAgICAgICB8ICAgIDIwICAgICAgICAgfA0KICAgICArLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KdmVyc3VzIDIgUk9BcyB0aGF0 IGNvbnRhaW4NCg0KICAgICBST0EgMQ0KICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgfCBhc0lEICAgICB8IGFkZHJlc3MgICAgICAgICAg IHwgbWF4TGVuZ3RoICAgICB8DQogICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKw0KICAgICB8IDY0NDk2ICAgIHwgMTAuMS4wLjAvMTYgICAgICAgfCAg ICAxNiAgICAgICAgIHwNCiAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rDQoNCiAgICAgUk9BIDINCiAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgIHwgYXNJRCAgICAgfCBhZGRyZXNzICAgICAg ICAgICB8IG1heExlbmd0aCAgICAgfA0KICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgfCA2NDQ5NiAgICB8IDEwLjEuMC4wLzE2ICAgICAg IHwgICAgMTYgICAgICAgICB8DQogICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKw0KDQpDaGVlcnMNClRlcnJ5DQoNCk9uIDIyLzA2LzExIDExOjI1IEFN LCAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmc+IiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc+Pg0Kd3JvdGU6DQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9t IHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KZGlyZWN0b3JpZXMuIFRoaXMgZHJhZnQgaXMg YSB3b3JrIGl0ZW0gb2YgdGhlIFNlY3VyZSBJbnRlci1Eb21haW4gUm91dGluZw0KV29ya2luZyBH cm91cCBvZiB0aGUgSUVURi4NCg0KICAgICAgIFRpdGxlICAgICAgICAgICA6IFVzZSBDYXNlcyBh bmQgSW50ZXJwcmV0YXRpb24gb2YgUlBLSSBPYmplY3RzIGZvcg0KSXNzdWVycyBhbmQgUmVseWlu ZyBQYXJ0aWVzDQogICAgICAgQXV0aG9yKHMpICAgICAgIDogVGVycnkgTWFuZGVyc29uDQogICAg ICAgICAgICAgICAgICAgICAgICAgS290aWthbGFwdWRpIFNyaXJhbQ0KICAgICAgICAgICAgICAg ICAgICAgICAgIFJ1c3MgV2hpdGUNCiAgICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRm LXNpZHItdXNlY2FzZXMtMDIudHh0DQogICAgICAgUGFnZXMgICAgICAgICAgIDogMzANCiAgICAg ICBEYXRlICAgICAgICAgICAgOiAyMDExLTA2LTIxDQoNCiAgVGhpcyBkb2N1bWVudCBwcm92aWRl cyB1c2UgY2FzZXMsIGRpcmVjdGlvbnMsIGFuZCBpbnRlcnByZXRhdGlvbnMgZm9yDQogIG9yZ2Fu aXphdGlvbnMgYW5kIHJlbHlpbmcgcGFydGllcyB3aGVuIGNyZWF0aW5nIG9yIGVuY291bnRlcmlu ZyBSUEtJDQogIG9iamVjdCBzY2VuYXJpb3MgaW4gdGhlIHB1YmxpYyBSUEtJIGluIHJlbGF0aW9u IHRvIHRoZSBJbnRlcm5ldA0KICByb3V0aW5nIHN5c3RlbS4NCg0KDQpBIFVSTCBmb3IgdGhpcyBJ bnRlcm5ldC1EcmFmdCBpczoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWlldGYtc2lkci11c2VjYXNlcy0wMi50eHQNCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNv IGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy8NCg0KVGhpcyBJbnRlcm5ldC1EcmFmdCBjYW4gYmUgcmV0cmlldmVkIGF0Og0K ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXNpZHItdXNlY2Fz ZXMtMDIudHh0DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kc2lkciBtYWlsaW5nIGxpc3QNCnNpZHJAaWV0Zi5vcmc8bWFpbHRvOnNpZHJAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpZHINCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpZHIgbWFpbGluZyBsaXN0 DQpzaWRyQGlldGYub3JnPG1haWx0bzpzaWRyQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zaWRyDQo= --_000_B0B6EA738DFE4F4D90B273925D6BBFA6icannorg_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5UaGUgc2Vjb25kIFJPQSAoUk9BIDIp IGJlbG93IHdvdWxkIG9mIGNvdXJzZSBiZSBhZGRyZXNzJm5ic3A7PHNwYW4gY2xhc3M9IkFwcGxl LXN0eWxlLXNwYW4iIHN0eWxlPSItd2Via2l0LXRhcC1oaWdobGlnaHQtY29sb3I6IHJnYmEoMjYs IDI2LCAyNiwgMC4yOTI5NjkpOyAtd2Via2l0LWNvbXBvc2l0aW9uLWZpbGwtY29sb3I6IHJnYmEo MTc1LCAxOTIsIDIyNywgMC4yMzA0NjkpOyAtd2Via2l0LWNvbXBvc2l0aW9uLWZyYW1lLWNvbG9y OiByZ2JhKDc3LCAxMjgsIDE4MCwgMC4yMzA0NjkpOyAiPjEwLjEuMC4wLzIwIG1heGxlbmd0aCAm bmJzcDsyMC48L3NwYW4+PC9kaXY+PGRpdj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIg c3R5bGU9Ii13ZWJraXQtdGFwLWhpZ2hsaWdodC1jb2xvcjogcmdiYSgyNiwgMjYsIDI2LCAwLjI5 Mjk2OSk7IC13ZWJraXQtY29tcG9zaXRpb24tZmlsbC1jb2xvcjogcmdiYSgxNzUsIDE5MiwgMjI3 LCAwLjIzMDQ2OSk7IC13ZWJraXQtY29tcG9zaXRpb24tZnJhbWUtY29sb3I6IHJnYmEoNzcsIDEy OCwgMTgwLCAwLjIzMDQ2OSk7ICI+PGJyPjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIGNsYXNzPSJB cHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iLXdlYmtpdC10YXAtaGlnaGxpZ2h0LWNvbG9yOiByZ2Jh KDI2LCAyNiwgMjYsIDAuMjkyOTY5KTsgLXdlYmtpdC1jb21wb3NpdGlvbi1maWxsLWNvbG9yOiBy Z2JhKDE3NSwgMTkyLCAyMjcsIDAuMjMwNDY5KTsgLXdlYmtpdC1jb21wb3NpdGlvbi1mcmFtZS1j b2xvcjogcmdiYSg3NywgMTI4LCAxODAsIDAuMjMwNDY5KTsgIj5BcG9sb2dpZXMgZm9yIHRoZSBj dXQvcGFzdGUgZXJyb3IuPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxl LXNwYW4iIHN0eWxlPSItd2Via2l0LXRhcC1oaWdobGlnaHQtY29sb3I6IHJnYmEoMjYsIDI2LCAy NiwgMC4yOTI5NjkpOyAtd2Via2l0LWNvbXBvc2l0aW9uLWZpbGwtY29sb3I6IHJnYmEoMTc1LCAx OTIsIDIyNywgMC4yMzA0NjkpOyAtd2Via2l0LWNvbXBvc2l0aW9uLWZyYW1lLWNvbG9yOiByZ2Jh KDc3LCAxMjgsIDE4MCwgMC4yMzA0NjkpOyAiPjxicj48L3NwYW4+PC9kaXY+PGRpdj48c3BhbiBj bGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9Ii13ZWJraXQtdGFwLWhpZ2hsaWdodC1jb2xv cjogcmdiYSgyNiwgMjYsIDI2LCAwLjI5Mjk2OSk7IC13ZWJraXQtY29tcG9zaXRpb24tZmlsbC1j b2xvcjogcmdiYSgxNzUsIDE5MiwgMjI3LCAwLjIzMDQ2OSk7IC13ZWJraXQtY29tcG9zaXRpb24t ZnJhbWUtY29sb3I6IHJnYmEoNzcsIDEyOCwgMTgwLCAwLjIzMDQ2OSk7ICI+Q2hlZXJzPC9zcGFu PjwvZGl2PjxkaXY+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSItd2Via2l0 LXRhcC1oaWdobGlnaHQtY29sb3I6IHJnYmEoMjYsIDI2LCAyNiwgMC4yOTI5NjkpOyAtd2Via2l0 LWNvbXBvc2l0aW9uLWZpbGwtY29sb3I6IHJnYmEoMTc1LCAxOTIsIDIyNywgMC4yMzA0NjkpOyAt d2Via2l0LWNvbXBvc2l0aW9uLWZyYW1lLWNvbG9yOiByZ2JhKDc3LCAxMjgsIDE4MCwgMC4yMzA0 NjkpOyAiPlRlcnJ5PC9zcGFuPjwvZGl2PjxkaXY+PGJyPk9uIDIyLzA2LzIwMTEsIGF0IDExOjM3 IEFNLCAiVGVycnkgTWFuZGVyc29uIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRlcnJ5Lm1hbmRlcnNv bkBpY2Fubi5vcmciPnRlcnJ5Lm1hbmRlcnNvbkBpY2Fubi5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+ PGZvbnQgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIGNvbG9yPSIjMDAyM0EzIj48Zm9udCBjbGFz cz0iQXBwbGUtc3R5bGUtc3BhbiIgY29sb3I9IiMwMDAwMDAiPjxicj48L2ZvbnQ+PC9mb250Pjwv ZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PHNwYW4+YSBzaW5nbGUgUk9BIHdpdGg6 PC9zcGFuPjxicj48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Ky0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rPC9zcGFuPjxicj48c3Bhbj4g Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCBhc0lEICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO3wgYWRkcmVzcyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDt8IG1heExlbmd0aCAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8PC9z cGFuPjxicj48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Ky0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rPC9zcGFuPjxicj48c3Bhbj4gJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCA2NDQ5NiAmbmJzcDsmbmJzcDsmbmJzcDt8IDEw LjEuMC4wLzE2ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wgJm5ic3A7Jm5i c3A7Jm5ic3A7MTYgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7fDwvc3Bhbj48YnI+PHNwYW4+ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKzwvc3Bhbj48YnI+PHNwYW4+ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCAxMC4xLjAuMC8yMCAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDt8ICZuYnNwOyZuYnNwOyZuYnNwOzIwICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3w8L3NwYW4+PGJyPjxzcGFuPiAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSs8L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+dmVyc3VzIDIgUk9B cyB0aGF0IGNvbnRhaW48L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO1JPQSAxPC9zcGFuPjxicj48c3Bhbj4gJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rPC9zcGFuPjxicj48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 fCBhc0lEICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wgYWRkcmVzcyAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8IG1heExlbmd0aCAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8PC9zcGFuPjxicj48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rPC9zcGFuPjxicj48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCA2 NDQ5NiAmbmJzcDsmbmJzcDsmbmJzcDt8IDEwLjEuMC4wLzE2ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO3wgJm5ic3A7Jm5ic3A7Jm5ic3A7MTYgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fDwvc3Bhbj48YnI+PHNwYW4+ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOystLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKzwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj4gJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Uk9BIDI8L3NwYW4+PGJyPjxzcGFuPiAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSs8L3NwYW4+PGJyPjxzcGFuPiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8 IGFzSUQgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCBhZGRyZXNzICZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wgbWF4TGVuZ3RoICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO3w8L3NwYW4+PGJyPjxzcGFuPiAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSs8L3NwYW4+PGJyPjxzcGFuPiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8IDY0 NDk2ICZuYnNwOyZuYnNwOyZuYnNwO3wgMTAuMS4wLjAvMTYgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7fCAmbmJzcDsmbmJzcDsmbmJzcDsxNiAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8PC9zcGFuPjxicj48c3Bhbj4gJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rPC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPkNoZWVyczwvc3Bh bj48YnI+PHNwYW4+VGVycnk8L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+T24gMjIv MDYvMTEgMTE6MjUgQU0sICI8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn Ij5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+IiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZndDs8L3Nw YW4+PGJyPjxzcGFuPndyb3RlOjwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxicj48YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj48c3Bhbj5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJv bSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHM8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5kaXJlY3Rvcmllcy4gVGhpcyBkcmFmdCBpcyBhIHdv cmsgaXRlbSBvZiB0aGUgU2VjdXJlIEludGVyLURvbWFpbiBSb3V0aW5nPC9zcGFuPjxicj48L2Js b2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+V29ya2luZyBHcm91cCBvZiB0 aGUgSUVURi48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48 c3Bhbj48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bh bj4gJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGl0bGUgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBV c2UgQ2FzZXMgYW5kIEludGVycHJldGF0aW9uIG9mIFJQS0kgT2JqZWN0cyBmb3I8L3NwYW4+PGJy PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5Jc3N1ZXJzIGFuZCBS ZWx5aW5nIFBhcnRpZXM8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJj aXRlIj48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QXV0 aG9yKHMpICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogVGVycnkgTWFuZGVy c29uPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0tvdGlrYWxhcHVkaSBTcmlyYW08 L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4gJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7UnVzcyBXaGl0ZTwvc3Bhbj48YnI+PC9i bG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtGaWxlbmFtZSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs6IGRyYWZ0LWlldGYtc2lkci11c2VjYXNlcy0wMi50eHQ8L3Nw YW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4gJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7UGFnZXMgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiAzMDwvc3Bhbj48 YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtEYXRlICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogMjAxMS0wNi0y MTwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwv c3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiAmbmJz cDsmbmJzcDtUaGlzIGRvY3VtZW50IHByb3ZpZGVzIHVzZSBjYXNlcywgZGlyZWN0aW9ucywgYW5k IGludGVycHJldGF0aW9ucyBmb3I8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj48c3Bhbj4gJm5ic3A7Jm5ic3A7b3JnYW5pemF0aW9ucyBhbmQgcmVseWluZyBw YXJ0aWVzIHdoZW4gY3JlYXRpbmcgb3IgZW5jb3VudGVyaW5nIFJQS0k8L3NwYW4+PGJyPjwvYmxv Y2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4gJm5ic3A7Jm5ic3A7b2JqZWN0 IHNjZW5hcmlvcyBpbiB0aGUgcHVibGljIFJQS0kgaW4gcmVsYXRpb24gdG8gdGhlIEludGVybmV0 PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ICZu YnNwOyZuYnNwO3JvdXRpbmcgc3lzdGVtLjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxzcGFuPkEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOjwvc3Bhbj48 YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjxhIGhyZWY9Imh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtc2lkci11c2VjYXNl cy0wMi50eHQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYt c2lkci11c2VjYXNlcy0wMi50eHQ8L2E+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+PHNwYW4+SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBh bm9ueW1vdXMgRlRQIGF0Ojwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPjxzcGFuPjxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv Ij5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwvYT48L3NwYW4+PGJyPjwvYmxv Y2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPjwvYmxvY2tx dW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5UaGlzIEludGVybmV0LURyYWZ0IGNh biBiZSByZXRyaWV2ZWQgYXQ6PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PHNwYW4+PGEgaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLXNpZHItdXNlY2FzZXMtMDIudHh0Ij5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtc2lkci11c2VjYXNlcy0wMi50eHQ8L2E+PC9zcGFuPjxi cj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPjwvYmxvY2txdW90 ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5zaWRyIG1haWxpbmcgbGlzdDwvc3Bhbj48 YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjxhIGhyZWY9Im1h aWx0bzpzaWRyQGlldGYub3JnIj5zaWRyQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+PC9ibG9ja3F1 b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lkciI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zaWRyPC9hPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxzcGFuPjwvc3Bhbj48 YnI+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 L3NwYW4+PGJyPjxzcGFuPnNpZHIgbWFpbGluZyBsaXN0PC9zcGFuPjxicj48c3Bhbj48YSBocmVm PSJtYWlsdG86c2lkckBpZXRmLm9yZyI+c2lkckBpZXRmLm9yZzwvYT48L3NwYW4+PGJyPjxzcGFu PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lkciI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaWRyPC9hPjwvc3Bhbj48YnI+PC9k aXY+PC9ibG9ja3F1b3RlPjwvYm9keT48L2h0bWw+ --_000_B0B6EA738DFE4F4D90B273925D6BBFA6icannorg_-- From sebastian.spies@nist.gov Wed Jun 22 12:23:06 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C7811E80BA for ; Wed, 22 Jun 2011 12:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1l9TthZU2Ja for ; Wed, 22 Jun 2011 12:23:01 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAA011E809C for ; Wed, 22 Jun 2011 12:23:01 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.289.1; Wed, 22 Jun 2011 15:22:41 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 22 Jun 2011 15:22:59 -0400 From: "Spies, Sebastian Martin" To: "sidr@ietf.org" Date: Wed, 22 Jun 2011 15:22:57 -0400 Thread-Topic: [sidr] tcpdump supportf for rpki-rtr protocol Thread-Index: Acwv+e74WL+Oo5AvThav3QuCzmDmXQBFYegw Message-ID: References: <20110621095634.GA8806@juniper.net> In-Reply-To: <20110621095634.GA8806@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [sidr] tcpdump supportf for rpki-rtr protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 22 Jun 2011 19:23:06 -0000 Nice tool. I tested your dissector and could see most of the PDUs. However, some PDUs were not visible: Serial Notify: 15:02:42.403365 IP (tos 0x0, ttl 64, id 13606, offset 0, flags [none], proto TCP (6), length 52) cache-server.50000 > cache-client.45076: Flags [P.], cksum 0x5097 (correct), seq 21:33, ack 9, win 65535, length 12 0x0000: 4500 0034 3526 0000 4006 2b08 **** **** E..45&..@.+...** 0x0010: **** **** c350 b014 1049 ec16 e114 d886 **...P...I...... 0x0020: 5018 ffff 5097 0000 0000 1b24 0000 000c P...P......$.... 0x0030: 0000 0002 Serial Query (truncated): 15:02:42.403559 IP (tos 0x0, ttl 64, id 30034, offset 0, flags [DF], proto TCP (6), length 48) cache-client.45076 > cache-server.50000: Flags [P.], cksum 0x1ab9 (incorrect -> 0x54e4), seq 9:17, ack 33, win 5840, length 8 [|RPKI-RTR] 0x0000: 4500 0030 7552 4000 4006 aadf **** **** E..0uR@.@.....** 0x0010: **** **** b014 c350 e114 d886 1049 ec22 **.....P.....I." 0x0020: 5018 16d0 1ab9 0000 0001 1b24 0000 000c P............... 15:02:42.403918 IP (tos 0x0, ttl 64, id 30035, offset 0, flags [DF], proto TCP (6), length 44) cache-client.45076 > cache-server.50000: Flags [P.], cksum 0x1ab5 (incorrect -> 0x54ed), seq 17:21, ack 33, win 5840, length 4 0x0000: 4500 002c 7553 4000 4006 aae2 **** **** E..,uS@.@.....** 0x0010: **** **** b014 c350 e114 d88e 1049 ec22 **.....P.....I." 0x0020: 5018 16d0 1ab5 0000 0000 0000 P........... Best regards, Sebastian > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Hannes Gredler > Sent: Tuesday, June 21, 2011 5:57 AM > To: sidr@ietf.org > Subject: [sidr] tcpdump supportf for rpki-rtr protocol > > fyi - have added some code to tcpdump.org which may help in debugging > interop issues; > > https://github.com/mcr/tcpdump/commit/917f5f341f4901bde415293be91190336 > 2c1fbfe > > verbose output looks like this: > > 12:37:23.335204 IP (tos 0x0, ttl 64, id 27027, offset 0, flags > [DF], proto TCP (6), length 332) > 1.3.0.2.2222 > 1.3.0.1.57487: Flags [P.], cksum 0x4fab (correct), > seq 1:281, ack 9, win 32763, options [nop,nop,TS val 485909147 > ecr 485909145], length 280 > RPKI-RTRv0, Cache Response PDU (3), length: 8 > Cache-Nonce: 0x0000 > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > IPv4 Prefix 0.0.0.0/0-14, origin-as 16, flags 0x01 > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > IPv4 Prefix 31.1.0.0/16-16, origin-as 1100, flags 0x01 > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > IPv4 Prefix 41.0.0.0/8-17, origin-as 100, flags 0x01 > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > IPv4 Prefix 41.0.0.0/10-13, origin-as 200, flags 0x01 > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > IPv4 Prefix 41.0.0.0/11-14, origin-as 300, flags 0x01 > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > IPv4 Prefix 41.0.0.0/12-16, origin-as 400, flags 0x01 > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > IPv4 Prefix 41.0.0.0/13-18, origin-as 500, flags 0x01 > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > IPv4 Prefix 41.0.0.0/14-25, origin-as 600, flags 0x01 > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > IPv4 Prefix 41.0.0.0/18-26, origin-as 700, flags 0x01 > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > IPv4 Prefix 41.0.0.0/19-28, origin-as 800, flags 0x01 > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > IPv4 Prefix 41.0.0.0/24-32, origin-as 900, flags 0x01 > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > IPv4 Prefix 41.0.0.0/32-32, origin-as 1100, flags 0x01 > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > IPv4 Prefix 91.0.0.0/10-16, origin-as 3320, flags 0x01 > RPKI-RTRv0, End of Data PDU (7), length: 12 > Cache-Nonce: 0x0000, Serial: 1 > > tx, > > /hannes > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From hannes@juniper.net Wed Jun 22 15:47: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 A33299E803F for ; Wed, 22 Jun 2011 15:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wwuj7n9nZbkB for ; Wed, 22 Jun 2011 15:47:33 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD589E800B for ; Wed, 22 Jun 2011 15:47:33 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTgJxAySOrhIRaHQDfPnT0TTqSNBUXfII@postini.com; Wed, 22 Jun 2011 15:47:33 PDT Received: from hannes-755.juniper.net (172.30.152.52) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.2.254.0; Wed, 22 Jun 2011 15:45:57 -0700 Received: by hannes-755.juniper.net (Postfix, from userid 1000) id 23BB220991; Thu, 23 Jun 2011 00:45:54 +0200 (CEST) Date: Thu, 23 Jun 2011 00:45:54 +0200 From: Hannes Gredler To: "Spies, Sebastian Martin" Message-ID: <20110622224552.GB3426@juniper.net> References: <20110621095634.GA8806@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "sidr@ietf.org" Subject: Re: [sidr] tcpdump supportf for rpki-rtr protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 22 Jun 2011 22:47:34 -0000 in lieu of a well-known port for rpki-rtr (and lack of dynamic dissectors in tcpdump :-/) i have hardcoded the protocol to tcp port 2222; - make your session to emit PDUs at tcp port 2222 (or change the portnumber to 50000) and you should see nice printouts. On Wed, Jun 22, 2011 at 03:22:57PM -0400, Spies, Sebastian Martin wrote: | Nice tool. | I tested your dissector and could see most of the PDUs. However, some PDUs were not visible: | | Serial Notify: | 15:02:42.403365 IP (tos 0x0, ttl 64, id 13606, offset 0, flags [none], proto TCP (6), length 52) | cache-server.50000 > cache-client.45076: Flags [P.], cksum 0x5097 (correct), seq 21:33, ack 9, win 65535, length 12 | 0x0000: 4500 0034 3526 0000 4006 2b08 **** **** E..45&..@.+...** | 0x0010: **** **** c350 b014 1049 ec16 e114 d886 **...P...I...... | 0x0020: 5018 ffff 5097 0000 0000 1b24 0000 000c P...P......$.... | 0x0030: 0000 0002 | | Serial Query (truncated): | 15:02:42.403559 IP (tos 0x0, ttl 64, id 30034, offset 0, flags [DF], proto TCP (6), length 48) | cache-client.45076 > cache-server.50000: Flags [P.], cksum 0x1ab9 (incorrect -> 0x54e4), seq 9:17, ack 33, win 5840, length 8 | [|RPKI-RTR] | 0x0000: 4500 0030 7552 4000 4006 aadf **** **** E..0uR@.@.....** | 0x0010: **** **** b014 c350 e114 d886 1049 ec22 **.....P.....I." | 0x0020: 5018 16d0 1ab9 0000 0001 1b24 0000 000c P............... | | | 15:02:42.403918 IP (tos 0x0, ttl 64, id 30035, offset 0, flags [DF], proto TCP (6), length 44) | cache-client.45076 > cache-server.50000: Flags [P.], cksum 0x1ab5 (incorrect -> 0x54ed), seq 17:21, ack 33, win 5840, length 4 | 0x0000: 4500 002c 7553 4000 4006 aae2 **** **** E..,uS@.@.....** | 0x0010: **** **** b014 c350 e114 d88e 1049 ec22 **.....P.....I." | 0x0020: 5018 16d0 1ab5 0000 0000 0000 P........... | | | Best regards, | Sebastian | | > -----Original Message----- | > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of | > Hannes Gredler | > Sent: Tuesday, June 21, 2011 5:57 AM | > To: sidr@ietf.org | > Subject: [sidr] tcpdump supportf for rpki-rtr protocol | > | > fyi - have added some code to tcpdump.org which may help in debugging | > interop issues; | > | > https://github.com/mcr/tcpdump/commit/917f5f341f4901bde415293be91190336 | > 2c1fbfe | > | > verbose output looks like this: | > | > 12:37:23.335204 IP (tos 0x0, ttl 64, id 27027, offset 0, flags | > [DF], proto TCP (6), length 332) | > 1.3.0.2.2222 > 1.3.0.1.57487: Flags [P.], cksum 0x4fab (correct), | > seq 1:281, ack 9, win 32763, options [nop,nop,TS val 485909147 | > ecr 485909145], length 280 | > RPKI-RTRv0, Cache Response PDU (3), length: 8 | > Cache-Nonce: 0x0000 | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 | > IPv4 Prefix 0.0.0.0/0-14, origin-as 16, flags 0x01 | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 | > IPv4 Prefix 31.1.0.0/16-16, origin-as 1100, flags 0x01 | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 | > IPv4 Prefix 41.0.0.0/8-17, origin-as 100, flags 0x01 | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 | > IPv4 Prefix 41.0.0.0/10-13, origin-as 200, flags 0x01 | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 | > IPv4 Prefix 41.0.0.0/11-14, origin-as 300, flags 0x01 | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 | > IPv4 Prefix 41.0.0.0/12-16, origin-as 400, flags 0x01 | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 | > IPv4 Prefix 41.0.0.0/13-18, origin-as 500, flags 0x01 | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 | > IPv4 Prefix 41.0.0.0/14-25, origin-as 600, flags 0x01 | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 | > IPv4 Prefix 41.0.0.0/18-26, origin-as 700, flags 0x01 | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 | > IPv4 Prefix 41.0.0.0/19-28, origin-as 800, flags 0x01 | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 | > IPv4 Prefix 41.0.0.0/24-32, origin-as 900, flags 0x01 | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 | > IPv4 Prefix 41.0.0.0/32-32, origin-as 1100, flags 0x01 | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 | > IPv4 Prefix 91.0.0.0/10-16, origin-as 3320, flags 0x01 | > RPKI-RTRv0, End of Data PDU (7), length: 12 | > Cache-Nonce: 0x0000, Serial: 1 | > | > tx, | > | > /hannes | > _______________________________________________ | > 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 touch@isi.edu Wed Jun 22 15:54:15 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF291F0C48 for ; Wed, 22 Jun 2011 15:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gi4FUhtGlPTK for ; Wed, 22 Jun 2011 15:54:14 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 540361F0C45 for ; Wed, 22 Jun 2011 15:54:14 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p5MMroGu029278 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 22 Jun 2011 15:53:50 -0700 (PDT) Message-ID: <4E02727E.9060905@isi.edu> Date: Wed, 22 Jun 2011 15:53:50 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Hannes Gredler References: <20110621095634.GA8806@juniper.net> <20110622224552.GB3426@juniper.net> In-Reply-To: <20110622224552.GB3426@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "sidr@ietf.org" Subject: Re: [sidr] tcpdump supportf for rpki-rtr protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 22 Jun 2011 22:54:15 -0000 FWIW, it'd be useful to pick a dynamic port for now (50000 is fine). Picking a port already assigned to another service (or even currently unassigned) is a bad idea. If rpki-rtr needs an assigned port, it'd be useful to have the ADs request early assignment through IANA -- though the current rpki-rtr ID doesn't even discuss the need for such a port. Joe On 6/22/2011 3:45 PM, Hannes Gredler wrote: > in lieu of a well-known port for rpki-rtr (and lack of dynamic dissectors in tcpdump :-/) > i have hardcoded the protocol to tcp port 2222; - make your session to emit PDUs > at tcp port 2222 (or change the portnumber to 50000) and you should see nice printouts. > > On Wed, Jun 22, 2011 at 03:22:57PM -0400, Spies, Sebastian Martin wrote: > | Nice tool. > | I tested your dissector and could see most of the PDUs. However, some PDUs were not visible: > | > | Serial Notify: > | 15:02:42.403365 IP (tos 0x0, ttl 64, id 13606, offset 0, flags [none], proto TCP (6), length 52) > | cache-server.50000> cache-client.45076: Flags [P.], cksum 0x5097 (correct), seq 21:33, ack 9, win 65535, length 12 > | 0x0000: 4500 0034 3526 0000 4006 2b08 **** **** E..45&..@.+...** > | 0x0010: **** **** c350 b014 1049 ec16 e114 d886 **...P...I...... > | 0x0020: 5018 ffff 5097 0000 0000 1b24 0000 000c P...P......$.... > | 0x0030: 0000 0002 > | > | Serial Query (truncated): > | 15:02:42.403559 IP (tos 0x0, ttl 64, id 30034, offset 0, flags [DF], proto TCP (6), length 48) > | cache-client.45076> cache-server.50000: Flags [P.], cksum 0x1ab9 (incorrect -> 0x54e4), seq 9:17, ack 33, win 5840, length 8 > | [|RPKI-RTR] > | 0x0000: 4500 0030 7552 4000 4006 aadf **** **** E..0uR@.@.....** > | 0x0010: **** **** b014 c350 e114 d886 1049 ec22 **.....P.....I." > | 0x0020: 5018 16d0 1ab9 0000 0001 1b24 0000 000c P............... > | > | > | 15:02:42.403918 IP (tos 0x0, ttl 64, id 30035, offset 0, flags [DF], proto TCP (6), length 44) > | cache-client.45076> cache-server.50000: Flags [P.], cksum 0x1ab5 (incorrect -> 0x54ed), seq 17:21, ack 33, win 5840, length 4 > | 0x0000: 4500 002c 7553 4000 4006 aae2 **** **** E..,uS@.@.....** > | 0x0010: **** **** b014 c350 e114 d88e 1049 ec22 **.....P.....I." > | 0x0020: 5018 16d0 1ab5 0000 0000 0000 P........... > | > | > | Best regards, > | Sebastian > | > |> -----Original Message----- > |> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > |> Hannes Gredler > |> Sent: Tuesday, June 21, 2011 5:57 AM > |> To: sidr@ietf.org > |> Subject: [sidr] tcpdump supportf for rpki-rtr protocol > |> > |> fyi - have added some code to tcpdump.org which may help in debugging > |> interop issues; > |> > |> https://github.com/mcr/tcpdump/commit/917f5f341f4901bde415293be91190336 > |> 2c1fbfe > |> > |> verbose output looks like this: > |> > |> 12:37:23.335204 IP (tos 0x0, ttl 64, id 27027, offset 0, flags > |> [DF], proto TCP (6), length 332) > |> 1.3.0.2.2222> 1.3.0.1.57487: Flags [P.], cksum 0x4fab (correct), > |> seq 1:281, ack 9, win 32763, options [nop,nop,TS val 485909147 > |> ecr 485909145], length 280 > |> RPKI-RTRv0, Cache Response PDU (3), length: 8 > |> Cache-Nonce: 0x0000 > |> RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > |> IPv4 Prefix 0.0.0.0/0-14, origin-as 16, flags 0x01 > |> RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > |> IPv4 Prefix 31.1.0.0/16-16, origin-as 1100, flags 0x01 > |> RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > |> IPv4 Prefix 41.0.0.0/8-17, origin-as 100, flags 0x01 > |> RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > |> IPv4 Prefix 41.0.0.0/10-13, origin-as 200, flags 0x01 > |> RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > |> IPv4 Prefix 41.0.0.0/11-14, origin-as 300, flags 0x01 > |> RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > |> IPv4 Prefix 41.0.0.0/12-16, origin-as 400, flags 0x01 > |> RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > |> IPv4 Prefix 41.0.0.0/13-18, origin-as 500, flags 0x01 > |> RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > |> IPv4 Prefix 41.0.0.0/14-25, origin-as 600, flags 0x01 > |> RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > |> IPv4 Prefix 41.0.0.0/18-26, origin-as 700, flags 0x01 > |> RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > |> IPv4 Prefix 41.0.0.0/19-28, origin-as 800, flags 0x01 > |> RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > |> IPv4 Prefix 41.0.0.0/24-32, origin-as 900, flags 0x01 > |> RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > |> IPv4 Prefix 41.0.0.0/32-32, origin-as 1100, flags 0x01 > |> RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > |> IPv4 Prefix 91.0.0.0/10-16, origin-as 3320, flags 0x01 > |> RPKI-RTRv0, End of Data PDU (7), length: 12 > |> Cache-Nonce: 0x0000, Serial: 1 > |> > |> tx, > |> > |> /hannes > |> _______________________________________________ > |> sidr mailing list > |> sidr@ietf.org > |> https://www.ietf.org/mailman/listinfo/sidr > | _______________________________________________ > | sidr mailing list > | sidr@ietf.org > | https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From sebastian.spies@nist.gov Thu Jun 23 07:39:30 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8665511E80B1 for ; Thu, 23 Jun 2011 07:39: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxzUpskbAEL9 for ; Thu, 23 Jun 2011 07:39:26 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 60AD811E80D4 for ; Thu, 23 Jun 2011 07:39:25 -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.289.1; Thu, 23 Jun 2011 10:39:56 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 23 Jun 2011 10:38:19 -0400 From: "Spies, Sebastian Martin" To: Hannes Gredler Date: Thu, 23 Jun 2011 10:39:01 -0400 Thread-Topic: [sidr] tcpdump supportf for rpki-rtr protocol Thread-Index: AcwxLkdvRLviyTWsTMCoel+fqxrcNwAhOpzg Message-ID: References: <20110621095634.GA8806@juniper.net> <20110622224552.GB3426@juniper.net> In-Reply-To: <20110622224552.GB3426@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] tcpdump supportf for rpki-rtr protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 23 Jun 2011 14:39:30 -0000 I changed the value in tcp.h to 50000. This is why I could see the other PDUs, except for the ones below. Sebastian > -----Original Message----- > From: Hannes Gredler [mailto:hannes@juniper.net] > Sent: Wednesday, June 22, 2011 6:46 PM > To: Spies, Sebastian Martin > Cc: sidr@ietf.org > Subject: Re: [sidr] tcpdump supportf for rpki-rtr protocol > > in lieu of a well-known port for rpki-rtr (and lack of dynamic > dissectors in tcpdump :-/) > i have hardcoded the protocol to tcp port 2222; - make your session to > emit PDUs > at tcp port 2222 (or change the portnumber to 50000) and you should see > nice printouts. > > On Wed, Jun 22, 2011 at 03:22:57PM -0400, Spies, Sebastian Martin > wrote: > | Nice tool. > | I tested your dissector and could see most of the PDUs. However, some > PDUs were not visible: > | > | Serial Notify: > | 15:02:42.403365 IP (tos 0x0, ttl 64, id 13606, offset 0, flags > [none], proto TCP (6), length 52) > | cache-server.50000 > cache-client.45076: Flags [P.], cksum 0x5097 > (correct), seq 21:33, ack 9, win 65535, length 12 > | 0x0000: 4500 0034 3526 0000 4006 2b08 **** **** > E..45&..@.+...** > | 0x0010: **** **** c350 b014 1049 ec16 e114 d886 > **...P...I...... > | 0x0020: 5018 ffff 5097 0000 0000 1b24 0000 000c > P...P......$.... > | 0x0030: 0000 0002 > | > | Serial Query (truncated): > | 15:02:42.403559 IP (tos 0x0, ttl 64, id 30034, offset 0, flags [DF], > proto TCP (6), length 48) > | cache-client.45076 > cache-server.50000: Flags [P.], cksum 0x1ab9 > (incorrect -> 0x54e4), seq 9:17, ack 33, win 5840, length 8 > | [|RPKI-RTR] > | 0x0000: 4500 0030 7552 4000 4006 aadf **** **** > E..0uR@.@.....** > | 0x0010: **** **** b014 c350 e114 d886 1049 ec22 > **.....P.....I." > | 0x0020: 5018 16d0 1ab9 0000 0001 1b24 0000 000c > P............... > | > | > | 15:02:42.403918 IP (tos 0x0, ttl 64, id 30035, offset 0, flags [DF], > proto TCP (6), length 44) > | cache-client.45076 > cache-server.50000: Flags [P.], cksum 0x1ab5 > (incorrect -> 0x54ed), seq 17:21, ack 33, win 5840, length 4 > | 0x0000: 4500 002c 7553 4000 4006 aae2 **** **** > E..,uS@.@.....** > | 0x0010: **** **** b014 c350 e114 d88e 1049 ec22 > **.....P.....I." > | 0x0020: 5018 16d0 1ab5 0000 0000 0000 P........... > | > | > | Best regards, > | Sebastian > | > | > -----Original Message----- > | > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On > Behalf Of > | > Hannes Gredler > | > Sent: Tuesday, June 21, 2011 5:57 AM > | > To: sidr@ietf.org > | > Subject: [sidr] tcpdump supportf for rpki-rtr protocol > | > > | > fyi - have added some code to tcpdump.org which may help in > debugging > | > interop issues; > | > > | > > https://github.com/mcr/tcpdump/commit/917f5f341f4901bde415293be91190336 > | > 2c1fbfe > | > > | > verbose output looks like this: > | > > | > 12:37:23.335204 IP (tos 0x0, ttl 64, id 27027, offset 0, flags > | > [DF], proto TCP (6), length 332) > | > 1.3.0.2.2222 > 1.3.0.1.57487: Flags [P.], cksum 0x4fab (correct), > | > seq 1:281, ack 9, win 32763, options [nop,nop,TS val > 485909147 > | > ecr 485909145], length 280 > | > RPKI-RTRv0, Cache Response PDU (3), length: 8 > | > Cache-Nonce: 0x0000 > | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > | > IPv4 Prefix 0.0.0.0/0-14, origin-as 16, flags 0x01 > | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > | > IPv4 Prefix 31.1.0.0/16-16, origin-as 1100, flags 0x01 > | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > | > IPv4 Prefix 41.0.0.0/8-17, origin-as 100, flags 0x01 > | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > | > IPv4 Prefix 41.0.0.0/10-13, origin-as 200, flags 0x01 > | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > | > IPv4 Prefix 41.0.0.0/11-14, origin-as 300, flags 0x01 > | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > | > IPv4 Prefix 41.0.0.0/12-16, origin-as 400, flags 0x01 > | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > | > IPv4 Prefix 41.0.0.0/13-18, origin-as 500, flags 0x01 > | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > | > IPv4 Prefix 41.0.0.0/14-25, origin-as 600, flags 0x01 > | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > | > IPv4 Prefix 41.0.0.0/18-26, origin-as 700, flags 0x01 > | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > | > IPv4 Prefix 41.0.0.0/19-28, origin-as 800, flags 0x01 > | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > | > IPv4 Prefix 41.0.0.0/24-32, origin-as 900, flags 0x01 > | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > | > IPv4 Prefix 41.0.0.0/32-32, origin-as 1100, flags 0x01 > | > RPKI-RTRv0, IPV4 Prefix PDU (4), length: 20 > | > IPv4 Prefix 91.0.0.0/10-16, origin-as 3320, flags 0x01 > | > RPKI-RTRv0, End of Data PDU (7), length: 12 > | > Cache-Nonce: 0x0000, Serial: 1 > | > > | > tx, > | > > | > /hannes > | > _______________________________________________ > | > 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 Thu Jun 23 09:50: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 125E511E8181 for ; Thu, 23 Jun 2011 09:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A11uRXxb1-NG for ; Thu, 23 Jun 2011 09:50:20 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 8C60A11E8180 for ; Thu, 23 Jun 2011 09:50:19 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QZn5Q-000BS2-8Q; Thu, 23 Jun 2011 16:49:00 +0000 Date: Fri, 24 Jun 2011 01:48:59 +0900 Message-ID: From: Randy Bush To: Hannes Gredler In-Reply-To: <20110622224552.GB3426@juniper.net> References: <20110621095634.GA8806@juniper.net> <20110622224552.GB3426@juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org" Subject: Re: [sidr] tcpdump supportf for rpki-rtr protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 23 Jun 2011 16:50:21 -0000 > in lieu of a well-known port for rpki-rtr that was discussed extensively on-list a while back, when the mandatory to implement was expected to be ssh, as it is in the currently published draft. as ssh uses a known port and used the app subsystem rpki-rtr, no port registration was needed. and the data were encrypted as a side- effect, so tcpdump decode was not a serious option. all this will change in the next draft. randy From touch@isi.edu Thu Jun 23 10:01:06 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C28D11E816A for ; Thu, 23 Jun 2011 10:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJwlXW0E3jmv for ; Thu, 23 Jun 2011 10:01:05 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 15A2711E8160 for ; Thu, 23 Jun 2011 10:01:05 -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 p5NH0KQK019728 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 23 Jun 2011 10:00:20 -0700 (PDT) Message-ID: <4E037124.7060308@isi.edu> Date: Thu, 23 Jun 2011 10:00:20 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Randy Bush References: <20110621095634.GA8806@juniper.net> <20110622224552.GB3426@juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "sidr@ietf.org" Subject: Re: [sidr] tcpdump supportf for rpki-rtr protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 23 Jun 2011 17:01:06 -0000 On 6/23/2011 9:48 AM, Randy Bush wrote: >> in lieu of a well-known port for rpki-rtr > > that was discussed extensively on-list a while back, when the mandatory > to implement was expected to be ssh, as it is in the currently published > draft. as ssh uses a known port and used the app subsystem rpki-rtr, no > port registration was needed. and the data were encrypted as a side- > effect, so tcpdump decode was not a serious option. > > all this will change in the next draft. It'd be useful to discuss both the normal operation and debugging mode expectations for port use, if different. Joe From paul.hoffman@vpnc.org Thu Jun 23 17:46: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 1B7C3228014 for ; Thu, 23 Jun 2011 17:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id do6uEVsGHI-p for ; Thu, 23 Jun 2011 17:46:27 -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 2397C228010 for ; Thu, 23 Jun 2011 17:46:25 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p5O0kHsw029596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 Jun 2011 17:46:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Jun 2011 17:46:22 -0700 Message-Id: <65F7AFAB-A326-4AC5-991F-791EC46E44AF@vpnc.org> To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Rob Austein Subject: [sidr] Comments on rpki-rtr X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 00:46:30 -0000 Greetings again. In hopes that this document gets pushed out to IETF = Last Call soon, here are a few comments that might help clear up some = confusion and inconsistency in the document. Section 2 says a serial number is: A 32-bit monotonically increasing ordinal which wraps from 2^32-1 to 0. =20 Section 5.10, it says: An implementation which uses a fine granularity of time for the Serial Number might never change the Cache Nonce. Which is correct? The latter is not a monotonically increasing ordinal. Section 4 says: When the cache updates its database, it sends a Notify message to every currently connected router. Section 6.2 says: The cache server SHOULD send a notify PDU with its current serial number when the cache's serial changes The first is mandatory, the second is advisory; they should match. In section 5.3, there seems to be an implicit "MUST flush all data", = like the explicit one in section 5.10. It should probably be explicit = here as well or, if not, the document should say why a router might not = flush when getting data after a reset. Section 5.10 says: If, at any time, either the router or the cache finds the value of the nonces they hold disagree, they MUST completely drop the session and the router MUST flush all data learned from that cache. Why does the session need to be dropped? This could cause delay when = re-authenticating. Wouldn't it make more sense for the side that = discovers the problem to simply send Reset Query or Cache Reset? The = same problem appears in the first paragraph of section 10. Section 6.1 says: 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. As the cache MAY not keep updates for more than one hour, the router MUST have a polling interval of no greater than half an hour Which MUST is correct? Half an hour or an hour? (And why are these = MUST-level at all? This could be simply be an operational decision.) In section 2, "Non-authoritative Cache" is defined but is then only used = once, in section 3. Also in section 2, the definition of "cache" is not = in fact a definition. Maybe get rid of these two from section 2, and = pull the term "local cache" from section 3 here.=20 The repeated use of "rcynic" is confusing given that rcynic will = probably have features added in the future. None of them is really = needed in order to describe how this protocol functions. A non-trivial editorial issue: the draft uses "commensurate" in many = places that does not match any of the definitions I can find in my = dictionaries. I *think* that the draft means "the same", but that is not = clear. --Paul Hoffman From randy@psg.com Thu Jun 23 18:28:28 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1DB11E8084 for ; Thu, 23 Jun 2011 18:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nt8FMsa7O-yQ for ; Thu, 23 Jun 2011 18:28:27 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id F0BDC11E807C for ; Thu, 23 Jun 2011 18:28:26 -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 1QZvAr-000DBX-On; Fri, 24 Jun 2011 01:27:10 +0000 Date: Fri, 24 Jun 2011 10:27:08 +0900 Message-ID: From: Randy Bush To: Paul Hoffman In-Reply-To: <65F7AFAB-A326-4AC5-991F-791EC46E44AF@vpnc.org> References: <65F7AFAB-A326-4AC5-991F-791EC46E44AF@vpnc.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Rob Austein , sidr@ietf.org Subject: Re: [sidr] Comments on rpki-rtr X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 01:28:28 -0000 > Section 2 says a serial number is: > A 32-bit monotonically increasing ordinal which wraps > from 2^32-1 to 0. > Section 5.10, it says: > An implementation which uses a fine granularity of time for the > Serial Number might never change the Cache Nonce. > Which is correct? The latter is not a monotonically increasing ordinal. both are. and this is a problem because? the nonce is not specified to be increasing or decreasing. it is a nonce, not a counter. > Section 4 says: > When the cache updates its database, it sends a Notify message to > every currently connected router. > Section 6.2 says: > The cache server SHOULD send a notify PDU with its current serial > number when the cache's serial changes > The first is mandatory, the second is advisory; they should match. there is no MUST in the *overview* in sec 4. notify is not mandatory. > In section 5.3, there seems to be an implicit "MUST flush all data", > like the explicit one in section 5.10. It should probably be explicit > here as well or, if not, the document should say why a router might > not flush when getting data after a reset. from the currently published version -12 5.3. Reset Query Reset Query: The router tells the cache that it wants to receive the total active, current, non-withdrawn, database. The cache responds with a Cache Response PDU (Section 5.4). i see nothing about flushing anything. restart session, please. > > Section 5.10 says: > If, at > any time, either the router or the cache finds the value of the > nonces they hold disagree, they MUST completely drop the session > and the router MUST flush all data learned from that cache. > Why does the session need to be dropped? because it is not the same session. e.g. serials are not commensurate. > This could cause delay when re-authenticating. if the nonce was off i sure would want to re-auth > Section 6.1 says: > 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. > > As the cache MAY not keep updates for more than one hour, the router > MUST have a polling interval of no greater than half an hour > Which MUST is correct? Half an hour or an hour? good catch > (And why are these MUST-level at all? This could be simply be an > operational decision.) they may be under different authorities and be different code bases. > In section 2, "Non-authoritative Cache" is defined but is then only > used once, in section 3. Also in section 2, the definition of "cache" > is not in fact a definition. Maybe get rid of these two from section > 2, and pull the term "local cache" from section 3 here. i wonder why i was differentiating. have removed. thanks. > The repeated use of "rcynic" is confusing given that rcynic will > probably have features added in the future. None of them is really > needed in order to describe how this protocol functions. it is used twice, and couched in words indicating it is an example software such as rcynic for example via rcynic > A non-trivial editorial issue: the draft uses "commensurate" in many > places that does not match any of the definitions I can find in my > dictionaries. I *think* that the draft means "the same", but that is > not clear. no. it means drawn from the same number space. i.e. if the nonce differs, the cache and the router mean very different things by serial value 42. randy From paul.hoffman@vpnc.org Thu Jun 23 19:25: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 B96E411E81C6 for ; Thu, 23 Jun 2011 19:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLswehbnSrde for ; Thu, 23 Jun 2011 19:25:56 -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 441FD11E81BD for ; Thu, 23 Jun 2011 19:25:55 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p5O2PjOI033174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 Jun 2011 19:25:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 23 Jun 2011 19:25:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <834E019B-7230-423B-AF74-9B7C821639B6@vpnc.org> References: <65F7AFAB-A326-4AC5-991F-791EC46E44AF@vpnc.org> To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: Rob Austein , sidr@ietf.org Subject: Re: [sidr] Comments on rpki-rtr X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 02:25:56 -0000 On Jun 23, 2011, at 6:27 PM, Randy Bush wrote: >> Section 2 says a serial number is: >> A 32-bit monotonically increasing ordinal which wraps >> from 2^32-1 to 0. =20 >> Section 5.10, it says: >> An implementation which uses a fine granularity of time for the >> Serial Number might never change the Cache Nonce. >> Which is correct? The latter is not a monotonically increasing = ordinal. >=20 > both are. and this is a problem because? ...because the spec is inconsistent. If a router is expecting the first = and the cache is doing the second, the router would decide the cache is = noncompliant. > the nonce is not specified to be increasing or decreasing. it is a > nonce, not a counter. Wearing my security pedant hat, it is not a nonce at all. It is a = randomly-selected value that is used repeatedly as a selector. We agree = that it is not a counter. It is not useful to change all the uses of = "nonce" in this spec to something more correct. >> Section 4 says: >> When the cache updates its database, it sends a Notify message to >> every currently connected router. >> Section 6.2 says: >> The cache server SHOULD send a notify PDU with its current serial >> number when the cache's serial changes >> The first is mandatory, the second is advisory; they should match. >=20 > there is no MUST in the *overview* in sec 4. notify is not mandatory. Good. Then section 4 should say "database, it should send ..." >=20 >> In section 5.3, there seems to be an implicit "MUST flush all data", >> like the explicit one in section 5.10. It should probably be explicit >> here as well or, if not, the document should say why a router might >> not flush when getting data after a reset. >=20 > from the currently published version -12 >=20 > 5.3. Reset Query >=20 > Reset Query: The router tells the cache that it wants to receive the > total active, current, non-withdrawn, database. The cache responds > with a Cache Response PDU (Section 5.4). >=20 > i see nothing about flushing anything. restart session, please. This confuses me. What does "restart session" mean? Section 5.10 says: If, at any time, either the router or the cache finds the value of the nonces they hold disagree, they MUST completely drop the session and the router MUST flush all data learned from that cache. That sounds like "restart session" implies "MUST flush". Being a bit = more explicit in 5.3 and 5.10 would help implementations interoperate.=20= >> Section 5.10 says: >> If, at >> any time, either the router or the cache finds the value of the >> nonces they hold disagree, they MUST completely drop the session >> and the router MUST flush all data learned from that cache. >> Why does the session need to be dropped? >=20 > because it is not the same session. e.g. serials are not = commensurate. OK, maybe I'm confused by what you mean by "session", and it doesn't = appear to be to defined in the protocol. >> This could cause delay when re-authenticating. >=20 > if the nonce was off i sure would want to re-auth If you are using transport that assures integrity, there is no reason to = believe that you are no longer talking to the same party just because = one of you forgets the nonce or otherwise gets out of sync. What attack = are you trying to prevent by doing a re-authorization? >> A non-trivial editorial issue: the draft uses "commensurate" in many >> places that does not match any of the definitions I can find in my >> dictionaries. I *think* that the draft means "the same", but that is >> not clear. >=20 > no. it means drawn from the same number space. i.e. if the nonce > differs, the cache and the router mean very different things by serial > value 42. Right, but that's not what "commensurate" means. The common definition = across multiple dictionaries is "proportionate" or "of similar size", = and that is definitely *not* what you mean here. I don't even find your = definition in my math dictionary, and the math term "commensurable" is = not applicable here. --Paul Hoffman From Sandra.Murphy@cobham.com Fri Jun 24 08:07:06 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D6A21F8503 for ; Fri, 24 Jun 2011 08:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ALhgA7EFpvX for ; Fri, 24 Jun 2011 08:07:05 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8A74021F84E9 for ; Fri, 24 Jun 2011 08:07:05 -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 p5OF74dl032675; Fri, 24 Jun 2011 10:07:04 -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 p5OFeEN6002473; Fri, 24 Jun 2011 10:40:15 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.117]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Jun 2011 11:07:00 -0400 Date: Fri, 24 Jun 2011 11:06:59 -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: 24 Jun 2011 15:07:00.0692 (UTC) FILETIME=[5E57D940:01CC3280] Cc: sidr-chairs@tools.ietf.org Subject: [sidr] request for agenda items X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 24 Jun 2011 15:07:06 -0000 Draft wg agenda are due in two weeks, so please send requests for agenda time to the wg chairs sidr-chairs@tools.ietf.org. --Sandy, speaking as wg chair From Sandra.Murphy@cobham.com Fri Jun 24 08:15: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 4B8A221F8548 for ; Fri, 24 Jun 2011 08:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxgJPcLqyb8s for ; Fri, 24 Jun 2011 08:15:38 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5EA21F8547 for ; Fri, 24 Jun 2011 08:15:38 -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 p5OFFaP2000446 for ; Fri, 24 Jun 2011 10:15:36 -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 p5OFml47002876 for ; Fri, 24 Jun 2011 10:48:47 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.117]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Jun 2011 11:15:35 -0400 Date: Fri, 24 Jun 2011 11:15:34 -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: 24 Jun 2011 15:15:35.0751 (UTC) FILETIME=[91579D70:01CC3281] Subject: [sidr] important meeting dates for IETF 81 in Quebec X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 24 Jun 2011 15:15:39 -0000 Keep the following dates in mind for the upcoming meeting. We're only a month away. Note that the -00 version cutoff date is July 4, which is a holiday in the US. # 2011-06-27 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by 17:00 PT (00:00 UTC). # 2011-07-01 (Friday): Final agenda to be published. # 2011-07-04 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (00:00 UTC), upload using IETF ID Submission Tool. # 2011-07-11 (Monday): Internet Draft final submission cut-off by 17:00 PT (00:00 UTC), upload using IETF ID Submission Tool. # 2011-07-13 (Wednesday): Draft Working Group agendas due by 17:00 PT (00:00 UTC). # 2011-07-15 (Friday): Early Bird registration and payment cut-off at 17:00 PT (00:00 UTC). # 2011-07-18 (Monday): Revised Working Group agendas due by 17:00 PT (00:00 UTC). # 2011-07-18 (Monday): Registration cancellation cut-off at 17:00 PT (00:00 UTC). # 2011-07-22 (Friday): Final Pre-Registration and Pre-Payment cut-off at 17:00 local meeting time. Note that wg chairs must approve submission of a -00 wg draft, and that they are requested to approve those submissions a week before the submission deadline. If you do plan to submit a -00 draft, and you let the wg chairs know the exact name you intend to use, the wg chairs can get things set up so that submission even on the holiday is smooth and uneventful. Also know that at least one recent approval did not go smoothly due to a problem in some new tools. I'm just saying. --Sandy From internet-drafts@ietf.org Fri Jun 24 10:27: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 68AC311E8193; Fri, 24 Jun 2011 10:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOfLGUB+DlYS; Fri, 24 Jun 2011 10:27:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8DB11E8152; Fri, 24 Jun 2011 10:27:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110624172757.15690.93932.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2011 10:27:57 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 17:27:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : Threat Model for BGP Path Security Author(s) : S. Kent Filename : draft-ietf-sidr-bgpsec-threats-00.txt Pages : 18 Date : 2011-06-24 This document describes a threat model for BGP path security (BGPSEC). BGPSEC is assumed to make use of the Resource Public Key Infrastructure (RPKI) already developed in the SIDR WG [I-D.ietf- sidr-arch], and thus threats and attacks against the RPKI are part of this model. The model assumes that BGP path security is achieved through the application of digital signatures to AS_Path Info. The document characterizes classes of potential adversaries that are considered to be threats, and examines classes of attacks that might be launched against BGPSEC. It concludes with brief discussion of residual vulnerabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-threats-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-threats-00.txt From m.waehlisch@fu-berlin.de Mon Jun 27 07:06: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 4E17E11E80F0 for ; Mon, 27 Jun 2011 07:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06UTF91cmRsC for ; Mon, 27 Jun 2011 07:06:30 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEA711E80EE for ; Mon, 27 Jun 2011 07:06:27 -0700 (PDT) Envelope-to: sidr@ietf.org Received: from e178063253.adsl.alicedsl.de ([85.178.63.253] helo=mw-PC.fritz.box) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QbCSF-000B51-A4 for sidr@ietf.org; Mon, 27 Jun 2011 16:06:23 +0200 Date: Mon, 27 Jun 2011 16:06:22 +0200 From: Matthias Waehlisch To: sidr@ietf.org Message-ID: X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: sidr@ietf.org Subject: [sidr] Prefix Origin Validation & AS_SET X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 14:06:31 -0000 Hi, this question addresses the scenario, in which a BGP update contains an AS_SET. According to draft-ietf-sidr-pfx-validate-01, the variable origin_as would be defined as "NONE". In case of a valid certificate for the prefix, the prefix validation function would return "INVALID". BGP updates including an AS_SET with a valid certificate would never be valid. Correct? This seems a bit rough. Can you clarify the reason behind? I would expect that if a valid record for at least one origin AS within the AS_SET exists, the funcion will return "VALID". Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From rv@x37.NIC.DTAG.DE Mon Jun 27 07:34: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 44F3E21F864F for ; Mon, 27 Jun 2011 07:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4FipSXErKbq for ; Mon, 27 Jun 2011 07:34:11 -0700 (PDT) Received: from limes.NIC.DTAG.DE (limes.NIC.DTAG.DE [194.25.1.113]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECAC21F864E for ; Mon, 27 Jun 2011 07:34:11 -0700 (PDT) Received: from x37.NIC.DTAG.DE (x37.NIC.DTAG.DE [194.25.1.186]) by limes.NIC.DTAG.DE (8.8.5/8.8.3) with ESMTP id QAA07605; Mon, 27 Jun 2011 16:34:07 +0200 (MET DST) To: Matthias Waehlisch From: Ruediger Volk In-Reply-To: Your message of "Mon, 27 Jun 2011 16:06:22 +0200." Date: Mon, 27 Jun 2011 16:34:08 +0200 Message-ID: <11921.1309185248@x37.NIC.DTAG.DE> Sender: rv@x37.NIC.DTAG.DE Cc: sidr@ietf.org Subject: Re: [sidr] Prefix Origin Validation & AS_SET X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 14:34:12 -0000 > Hi, > > this question addresses the scenario, in which a BGP update contains > an AS_SET. According to draft-ietf-sidr-pfx-validate-01, the variable > origin_as would be defined as "NONE". In case of a valid certificate for > the prefix, the prefix validation function would return "INVALID". > > BGP updates including an AS_SET with a valid certificate would never > be valid. Correct? > This seems a bit rough. Can you clarify the reason > behind? I would expect that if a valid record for at least one origin AS > within the AS_SET exists, the funcion will return "VALID". no, as consequence of your criterium for VALID, it would get very easy to spread VALID routes with a short prefix by doing the proxy aggregation including one AS that has a ROA for some more specific... (in the extreme ROA for a /128 would VALIDate a ::/0, or say 2000::/3, or an aggregate for a very large block of your RIR's IPV6 space) If we wanted to support proxy aggregation and the related AS_SET the ROA to check for VALIDity would be one matching exactly the aggregate for the origin AS of the aggregator. Fiddling and fixing with the different cases (beware of optional attributes!) certainly allows for implementations to get it wrong (and create unwanted test requirements/efforts); seems nobody stepped forward with a convincing case really needing the AS_SET. Gruss, Ruediger Ruediger Volk Deutsche Telekom AG -- Internet Backbone Engineering From hannes@juniper.net Mon Jun 27 07:38: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 9AB5011E80E0 for ; Mon, 27 Jun 2011 07:38: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ek2c68Bkeg0e for ; Mon, 27 Jun 2011 07:38:45 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id CAA9411E80DF for ; Mon, 27 Jun 2011 07:38:43 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTgiV8PyQvd80jO8gQw5HxGy/VCzTwzSd@postini.com; Mon, 27 Jun 2011 07:38:44 PDT Received: from hannes-755.juniper.net (172.30.152.52) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.2.254.0; Mon, 27 Jun 2011 07:36:31 -0700 Received: by hannes-755.juniper.net (Postfix, from userid 1000) id DB97F2D39B; Mon, 27 Jun 2011 16:36:27 +0200 (CEST) Date: Mon, 27 Jun 2011 16:36:27 +0200 From: Hannes Gredler To: Matthias Waehlisch Message-ID: <20110627143625.GA2251@juniper.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: sidr@ietf.org Subject: Re: [sidr] Prefix Origin Validation & AS_SET X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 14:38:45 -0000 On Mon, Jun 27, 2011 at 04:06:22PM +0200, Matthias Waehlisch wrote: | Hi, | | this question addresses the scenario, in which a BGP update contains | an AS_SET. According to draft-ietf-sidr-pfx-validate-01, the variable | origin_as would be defined as "NONE". In case of a valid certificate for | the prefix, the prefix validation function would return "INVALID". | | BGP updates including an AS_SET with a valid certificate would never | be valid. Correct? This seems a bit rough. Can you clarify the reason | behind? I would expect that if a valid record for at least one origin AS | within the AS_SET exists, the funcion will return "VALID". depends ... - my understanding of the logic for extracting the "to-be-validated" AS is something alike: If aggregator is present and right-most AS segment type is AS-Set, then use aggregator AS for validating, else if if right-most AS segment type is AS-set -> result: not found else use right-most AS for validating From Sandra.Murphy@cobham.com Mon Jun 27 09:18: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 41C0D11E80E7 for ; Mon, 27 Jun 2011 09:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bx5nOAHmTOGK for ; Mon, 27 Jun 2011 09:18:25 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8C02021F85F2 for ; Mon, 27 Jun 2011 09:18:21 -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 p5RGIHeR032521; Mon, 27 Jun 2011 11:18:17 -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 p5RGIGqd028891; Mon, 27 Jun 2011 11:18:17 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.117]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Jun 2011 12:18:15 -0400 Date: Mon, 27 Jun 2011 12:18:15 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Hannes Gredler In-Reply-To: <20110627143625.GA2251@juniper.net> Message-ID: References: <20110627143625.GA2251@juniper.net> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 27 Jun 2011 16:18:15.0859 (UTC) FILETIME=[D1C7D030:01CC34E5] Cc: Matthias Waehlisch , sidr@ietf.org Subject: Re: [sidr] Prefix Origin Validation & AS_SET X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 16:18:26 -0000 On Mon, 27 Jun 2011, Hannes Gredler wrote: > On Mon, Jun 27, 2011 at 04:06:22PM +0200, Matthias Waehlisch wrote: > | Hi, > | > | this question addresses the scenario, in which a BGP update contains > | an AS_SET. According to draft-ietf-sidr-pfx-validate-01, the variable > | origin_as would be defined as "NONE". In case of a valid certificate for > | the prefix, the prefix validation function would return "INVALID". > | > | BGP updates including an AS_SET with a valid certificate would never > | be valid. Correct? This seems a bit rough. Can you clarify the reason > | behind? I would expect that if a valid record for at least one origin AS > | within the AS_SET exists, the funcion will return "VALID". > > depends ... - my understanding of the logic for extracting the > "to-be-validated" AS is something alike: > > If aggregator is present and right-most AS segment type is AS-Set, > then use aggregator AS for validating, That rule was proposed at one point but discarded. The current rule is that a route containing an AS_SET is not to be considered "valid". The text in draft-ietf-sidr-roa-validation-10 A route's "origin AS" is defined as follows: If the final path segment of the AS_PATH is of type AS_SEQUENCE, the "origin AS" is the first element of the sequence (i.e. the AS in the rightmost position with respect to the position of octets in the protocol message). If the AS_PATH contains a path segment of type AS_SET, indicating that the route is an aggregate, then the "origin AS" cannot be determined. (Note that this is even harsher than judging just the /right-most/final/least recently added/whatever/ path segment - it says if the AS_PATH *contains* an AS_SET, then the origin AS "cannot be determined.") The subsequent table and steps on page 5 can lead to a decision of "not found" or "invalid" but not a decision of "valid": 3. If the route's origin AS can be determined and ... ... .......................................... then the procedure halts with an outcome of "valid". Since the origin AS can not be determined, this step can not produce an outcome of "valid". --Sandy > else if if right-most AS segment type is AS-set -> result: not found > else use right-most AS for validating > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From Sandra.Murphy@cobham.com Mon Jun 27 09:21: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 1388C11E8108 for ; Mon, 27 Jun 2011 09:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xueSFYZf7FMx for ; Mon, 27 Jun 2011 09:21:57 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 59F2C11E8106 for ; Mon, 27 Jun 2011 09:21:57 -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 p5RGLq8O032638; Mon, 27 Jun 2011 11:21:52 -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 p5RGLqLI029097; Mon, 27 Jun 2011 11:21:52 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.117]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Jun 2011 12:21:51 -0400 Date: Mon, 27 Jun 2011 12:21:51 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Hannes Gredler In-Reply-To: Message-ID: References: <20110627143625.GA2251@juniper.net> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 27 Jun 2011 16:21:51.0843 (UTC) FILETIME=[52845B30:01CC34E6] Cc: Matthias Waehlisch , sidr@ietf.org Subject: Re: [sidr] Prefix Origin Validation & AS_SET X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 16:21:58 -0000 Forgot to say.... Since I'm speaking on chair judgement of group consensus, this is.. --Sandy, speaking as wg chair On Mon, 27 Jun 2011, Sandra Murphy wrote: > > > On Mon, 27 Jun 2011, Hannes Gredler wrote: > >> On Mon, Jun 27, 2011 at 04:06:22PM +0200, Matthias Waehlisch wrote: >> | Hi, >> | >> | this question addresses the scenario, in which a BGP update contains >> | an AS_SET. According to draft-ietf-sidr-pfx-validate-01, the variable >> | origin_as would be defined as "NONE". In case of a valid certificate for >> | the prefix, the prefix validation function would return "INVALID". >> | >> | BGP updates including an AS_SET with a valid certificate would never >> | be valid. Correct? This seems a bit rough. Can you clarify the reason >> | behind? I would expect that if a valid record for at least one origin AS >> | within the AS_SET exists, the funcion will return "VALID". >> >> depends ... - my understanding of the logic for extracting the >> "to-be-validated" AS is something alike: >> >> If aggregator is present and right-most AS segment type is AS-Set, >> then use aggregator AS for validating, > > That rule was proposed at one point but discarded. > > The current rule is that a route containing an AS_SET is not to be considered > "valid". > > The text in draft-ietf-sidr-roa-validation-10 > > A route's "origin AS" is defined as follows: If the final path > segment of the AS_PATH is of type AS_SEQUENCE, the "origin AS" is the > first element of the sequence (i.e. the AS in the rightmost position > with respect to the position of octets in the protocol message). If > the AS_PATH contains a path segment of type AS_SET, indicating that > the route is an aggregate, then the "origin AS" cannot be determined. > > (Note that this is even harsher than judging just the /right-most/final/least > recently added/whatever/ path segment - it says if the AS_PATH *contains* an > AS_SET, then the origin AS "cannot be determined.") > > The subsequent table and steps on page 5 can lead to a decision of "not > found" or "invalid" but not a decision of "valid": > > 3. If the route's origin AS can be determined and ... > ... > .......................................... then the procedure > halts with an outcome of "valid". > > Since the origin AS can not be determined, this step can not produce an > outcome of "valid". > > --Sandy > > >> else if if right-most AS segment type is AS-set -> result: not found >> else use right-most AS for validating >> _______________________________________________ >> 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 internet-drafts@ietf.org Tue Jun 28 01:34: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 8BDEB11E80B9; Tue, 28 Jun 2011 01:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6S8Daym7Pp1; Tue, 28 Jun 2011 01:34:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2F311E80AE; Tue, 28 Jun 2011 01:34:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110628083454.12917.31330.idtracker@ietfa.amsl.com> Date: Tue, 28 Jun 2011 01:34:54 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-ghostbusters-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 08:34:54 -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-04.txt Pages : 8 Date : 2011-06-28 In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information which might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This draft describes the RPKI Ghostbusters Record containing human contact information to be signed (indirectly) by a resource-owning certificate. The data in the record are those of a severely profiled vCARD. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-ghostbusters-04.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-04.txt From dougm@nist.gov Tue Jun 28 08:07: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 13AD922800E for ; Tue, 28 Jun 2011 08:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVxVmG4bVKZL for ; Tue, 28 Jun 2011 08:07:10 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id E84AF22800D for ; Tue, 28 Jun 2011 08:07:09 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 28 Jun 2011 11:06:20 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 28 Jun 2011 11:06:46 -0400 From: "Montgomery, Douglas" To: "sidr@ietf.org" Date: Tue, 28 Jun 2011 11:06:44 -0400 Thread-Topic: Announcing BRITE - BGPSEC / RPKI Interoperability Test & Evaluation system Thread-Index: Acw1pOSwPdzgA+9VTiSSDCtsZSZQ6A== 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nanog@nanog.org" Subject: [sidr] Announcing BRITE - BGPSEC / RPKI Interoperability Test & Evaluation system X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 28 Jun 2011 15:07:13 -0000 BRITE is a web-based test and evaluation framework for exercising implementations, configurations and deployments of emerging IETF BGP security technologies, including some components of the Resource Public Key Infrastructure (RPKI) and routers that support BGP security extensions. BRITE is currently capable of testing: RPKI validation caches and BGP routers that perform origin validation based upon RPKI ROAs. Future extensions will support BGP routers that support full path validation. BRITE currently supports the following capabilities / protocol interfaces: * rsync of RPKI objects from BRITE test suite repositories, * RPKI/Router Protocol (draft-ietf-sidr-rpki-rtr-12 - TCP plain sockets, no SSH transport or TCP-AO) * BGP-4 (tested interoperability with Cisco IOS, JUNOS, Quagga, OpenBGPD and BIRD) BRITE is driven by test scripts that describe carefully crafted Test Scenarios (stimulus inputs from BRITE using the protocols above) and corresponding goals (expected responses from the Implementation Under Test (IUT) using the protocols above). BRITE allows users to login, select a specific test case, interactively configure and run the test case and then browse/download detailed test reports, packet captures and log files. Current test scripts & data sets are available for: * BGP routers that implement the rpki-rtr protocol and simple BGP origin validation route policies. Additional test suites & data sets are in development and will be announced when available. To get additional information, browse existing test suites, or use the BRITE system, goto: http://brite.antd.nist.gov/ Questions or comments can be directed to brite-dev@nist.gov. dougm --=20 Doug Montgomery =AD Mgr. Internet & Scalable Systems Research / ITL / NIST From internet-drafts@ietf.org Tue Jun 28 08:22: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 43A7421F867A; Tue, 28 Jun 2011 08:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBSPUQTEiglI; Tue, 28 Jun 2011 08:22:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29CF11E8090; Tue, 28 Jun 2011 08:21: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.55 Message-ID: <20110628152123.2147.92332.idtracker@ietfa.amsl.com> Date: Tue, 28 Jun 2011 08:21:23 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 15:22:30 -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-00.txt Pages : 9 Date : 2011-06-28 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-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-ops-00.txt From internet-drafts@ietf.org Tue Jun 28 08:22: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 3773911E8088; Tue, 28 Jun 2011 08:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1ps0TrG0OTL; Tue, 28 Jun 2011 08:22:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C16011E80B5; Tue, 28 Jun 2011 08:22:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110628152240.2386.66753.idtracker@ietfa.amsl.com> Date: Tue, 28 Jun 2011 08:22:40 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-reqs-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 15:22:43 -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-00.txt Pages : 9 Date : 2011-06-24 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-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-reqs-00.txt From internet-drafts@ietf.org Wed Jun 29 00:00: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 E0C2321F85B2; Wed, 29 Jun 2011 00:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6zMzo-NsW3Q; Wed, 29 Jun 2011 00:00:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA2121F85AD; Wed, 29 Jun 2011 00:00:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110629070025.16892.26227.idtracker@ietfa.amsl.com> Date: Wed, 29 Jun 2011 00:00:25 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-13.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 07:00:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : The RPKI/Router Protocol Author(s) : Randy Bush Rob Austein Filename : draft-ietf-sidr-rpki-rtr-13.txt Pages : 24 Date : 2011-06-28 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-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-13.txt From hannes@juniper.net Wed Jun 29 02:18: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 EBE5C21F862A for ; Wed, 29 Jun 2011 02:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AB3yKwk05lXM for ; Wed, 29 Jun 2011 02:18:11 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 260B721F8628 for ; Wed, 29 Jun 2011 02:18:11 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTgrt0lc9GOdBO5cLWglp22B/HnzmqhbB@postini.com; Wed, 29 Jun 2011 02:18:11 PDT Received: from hannes-755.juniper.net (172.23.0.177) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.2.254.0; Wed, 29 Jun 2011 02:16:56 -0700 Received: by hannes-755.juniper.net (Postfix, from userid 1000) id 97542318D4; Wed, 29 Jun 2011 11:16:52 +0200 (CEST) Date: Wed, 29 Jun 2011 11:16:52 +0200 From: Hannes Gredler To: Message-ID: <20110629091651.GA17888@juniper.net> References: <20110629070025.16892.26227.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20110629070025.16892.26227.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-13.txt / error handling; X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 29 Jun 2011 09:18:12 -0000 hi, i have some concerns about the error handling of error codes; IMO error codes 5,6,7 should not be "fatal" in the sense that the session needs to get re-signaled; 5: Unsupported PDU Type (fatal): The PDU Type is not known by the receiver of the PDU. <-- this prevents seamless upgrading once we want to extend the protocol; why is this fatal ? 6: Withdrawal of Unknown Record (fatal): The received PDU has Flag=0 but a record for the Prefix/PrefixLength/MaxLength triple does not exist in the receiver's database. 7: Duplicate Announcement Received (fatal): The received PDU has an identical {prefix, len, max-len, asn} tuple as a PDU which is still active in the router. <-- why do we need to reset the session here for reasons 6 & 7 ? - in the spirit of "be tolerant what you receive" a receiving router can do the right thing w/o disrupting the session. tx, /hannes From randy@psg.com Wed Jun 29 04:03: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 2793421F8633 for ; Wed, 29 Jun 2011 04:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLOs4bT3v+Ba for ; Wed, 29 Jun 2011 04:03:18 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB8A21F8631 for ; Wed, 29 Jun 2011 04:03:18 -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 1QbsY7-0002m3-Oz; Wed, 29 Jun 2011 11:03:16 +0000 Date: Wed, 29 Jun 2011 20:03:14 +0900 Message-ID: From: Randy Bush To: Hannes Gredler In-Reply-To: <20110629091651.GA17888@juniper.net> References: <20110629070025.16892.26227.idtracker@ietfa.amsl.com> <20110629091651.GA17888@juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-13.txt / error handling; X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 29 Jun 2011 11:03:19 -0000 hi hannes, first, i need to confess that i have disagreed with 'be liberal in what you accept' from day zero. that way lies entropy. > 5: Unsupported PDU Type (fatal): The PDU Type is not known by the > receiver of the PDU. > > <-- this prevents seamless upgrading once we want to extend the protocol; > why is this fatal ? not exactly. it prevents chaotic pretend upgrading producing a bunch of incorrect garbage in the router's database which leads to incorrect validity decisions and thus incorrect routing. imagine that the unrecognized pdu was signaling "flush all data with origin AS 42," or "delete all roas for prefix P or longer." > 6: Withdrawal of Unknown Record (fatal): The received PDU has Flag=0 > but a record for the Prefix/PrefixLength/MaxLength triple does not > exist in the receiver's database. > > 7: Duplicate Announcement Received (fatal): The received PDU has an > identical {prefix, len, max-len, asn} tuple as a PDU which is > still active in the router. > > <-- why do we need to reset the session here for reasons 6 & 7 ? - > in the spirit of "be tolerant what you receive" a receiving router > can do the right thing w/o disrupting the session. in general, all these indicate that the receiver and the sender are seriously out of whack. e.g. if the receiver goes ahead despite 6 or 7, the receiver's data are most likely incorrect in the sense that it will [in]validate an update which it should not. if that's not fatal, what is? but, i think at root, we have a disagreement on the idea of requiring 'correctness.' as i said, i admit to being a naggumite. randy From wesley.george@twcable.com Wed Jun 29 09:17:00 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F7A9E805C for ; Wed, 29 Jun 2011 09:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.02 X-Spam-Level: X-Spam-Status: No, score=0.02 tagged_above=-999 required=5 tests=[AWL=0.484, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMxcF-BlGsKG for ; Wed, 29 Jun 2011 09:16:59 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA659E8058 for ; Wed, 29 Jun 2011 09:16:59 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.65,443,1304308800"; d="scan'208";a="230061029" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 29 Jun 2011 12:16:18 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Wed, 29 Jun 2011 12:16:58 -0400 From: "George, Wesley" To: "sidr@ietf.org" Date: Wed, 29 Jun 2011 12:16:57 -0400 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-13.txt Thread-Index: Acw2Kj9k9//D68SOR1SiFz8ibve/MgASuMIQ Message-ID: <34E4F50CAFA10349A41E0756550084FB0A7F8BAF@PRVPEXVS04.corp.twcable.com> References: <20110629070025.16892.26227.idtracker@ietfa.amsl.com> In-Reply-To: <20110629070025.16892.26227.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-rpki-rtr-13.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 16:17:00 -0000 I think we're a little light on text in 7 now that we've added so many opti= ons. I think it would be helpful to provide some rationale as to why AO is = preferred over the other methods, why they are considered a secondary optio= n, etc. IOW, why *shouldn't* I just keep using TLS or SSH transport? Why is AO actu= ally better/eventually mandatory to implement? Multiple members of this WG = had strong opinions, we should be documenting our reasoning. Convince the r= eader that they should be yelling at YFV for AO support... 7.3 regarding MD5. At the very least, there should be a note that TCP-MD5 h= as been obsoleted by TCP-AO. Thanks, Wes George -----Original Message----- From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Wednesday, June 29, 2011 3:00 AM To: i-d-announce@ietf.org Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-13.txt 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-13.txt Pages : 24 Date : 2011-06-28 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-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-13.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 me@sigpipe.org Wed Jun 29 10:06:22 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFB89E8067 for ; Wed, 29 Jun 2011 10:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.308 X-Spam-Level: X-Spam-Status: No, score=-1.308 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+ZAVMg8cQpO for ; Wed, 29 Jun 2011 10:06:21 -0700 (PDT) Received: from zzyzx.sigpipe.org (zzyzx.sigpipe.org [IPv6:2001:418:1::13]) by ietfa.amsl.com (Postfix) with ESMTP id 69A4C9E8060 for ; Wed, 29 Jun 2011 10:06:21 -0700 (PDT) Received: from pinky.sigpipe.org (pinky.sigpipe.org [IPv6:2001:470:d:110a::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "pinky.sigpipe.org", Issuer "sigpipe root certificate" (verified OK)) by zzyzx.sigpipe.org (Postfix) with ESMTPS id 83906140417 for ; Wed, 29 Jun 2011 17:06:18 +0000 (UTC) Received: by pinky.sigpipe.org (Postfix, from userid 1000) id 8D3A33C; Wed, 29 Jun 2011 10:06:17 -0700 (PDT) Date: Wed, 29 Jun 2011 10:06:17 -0700 From: Michael Elkins Cc: sidr@ietf.org Message-ID: <20110629170617.GC15672@sigpipe.org> References: <20110628083454.12917.31330.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20110628083454.12917.31330.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [sidr] I-D Action: draft-ietf-sidr-ghostbusters-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 17:06:22 -0000 > VERSION - pro forma packaging which MUST be the second line in the > vCARD and MUST have the value "VERSION:4.0" as described in 3.6.9 > of [I-D.ietf-vcarddav-vcardrev]. Given that the Ghostbuster vCard profile does not allow any features from the 4.0 version, is there a compelling reason to require the latest version here? There is already running code with 3.0 that would otherwise be able to produce a compliant Ghostbuster object. Does the reference to I-D.ietf-vcarddav-vcarddev mandate the use of 4.0? me From randy@psg.com Wed Jun 29 13:35: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 3D37D11E80B6 for ; Wed, 29 Jun 2011 13:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0HlA0uPHfPE for ; Wed, 29 Jun 2011 13:35:23 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4CD21F8489 for ; Wed, 29 Jun 2011 13:35:22 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qc1Tk-0003nb-3t; Wed, 29 Jun 2011 20:35:20 +0000 Date: Thu, 30 Jun 2011 05:35:19 +0900 Message-ID: From: Randy Bush To: "George, Wesley" In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0A7F8BAF@PRVPEXVS04.corp.twcable.com> References: <20110629070025.16892.26227.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB0A7F8BAF@PRVPEXVS04.corp.twcable.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-13.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 20:35:24 -0000 > I think we're a little light on text in 7 now that we've added so many > options. I think it would be helpful to provide some rationale as to > why AO is preferred over the other methods, why they are considered a > secondary option, etc. > > IOW, why *shouldn't* I just keep using TLS or SSH transport? Why is AO > actually better/eventually mandatory to implement? Multiple members of > this WG had strong opinions, we should be documenting our > reasoning. Convince the reader that they should be yelling at YFV for > AO support... > > 7.3 regarding MD5. At the very least, there should be a note that > TCP-MD5 has been obsoleted by TCP-AO. this is all covered in the transport area. do we really want this routing security doc to get into the transport wars? where's the win? randy From randy@psg.com Wed Jun 29 13:37: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 9BFEA11E80B6 for ; Wed, 29 Jun 2011 13:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmDChRG5WZo6 for ; Wed, 29 Jun 2011 13:37:27 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 25BCC11E80B5 for ; Wed, 29 Jun 2011 13:37:27 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qc1Vm-0003ns-0Q; Wed, 29 Jun 2011 20:37:26 +0000 Date: Thu, 30 Jun 2011 05:37:25 +0900 Message-ID: From: Randy Bush To: Michael Elkins In-Reply-To: <20110629170617.GC15672@sigpipe.org> References: <20110628083454.12917.31330.idtracker@ietfa.amsl.com> <20110629170617.GC15672@sigpipe.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-ghostbusters-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 20:37:27 -0000 >> VERSION - pro forma packaging which MUST be the second line in the >> vCARD and MUST have the value "VERSION:4.0" as described in 3.6.9 >> of [I-D.ietf-vcarddav-vcardrev]. > > Given that the Ghostbuster vCard profile does not allow any features > from the 4.0 version, is there a compelling reason to require the > latest version here? i was whacked by the apps ads > There is already running code with 3.0 that would otherwise be able to > produce a compliant Ghostbuster object. sorry > Does the reference to I-D.ietf-vcarddav-vcarddev mandate the use of > 4.0? i think so. i think the thought in the iesg is that, as we are just behind vcard in the process chain (it is in rfced queue), we should follow. and the ietf is all about process :( randy From touch@isi.edu Wed Jun 29 14:04: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 D456B1F0C3F for ; Wed, 29 Jun 2011 14:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6bQL8z4qsny for ; Wed, 29 Jun 2011 14:04:18 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 01FD51F0C34 for ; Wed, 29 Jun 2011 14:04:09 -0700 (PDT) Received: from [75.217.204.148] (148.sub-75-217-204.myvzw.com [75.217.204.148]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p5TL3Y2n014053 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 29 Jun 2011 14:03:59 -0700 (PDT) Message-ID: <4E0B9320.50504@isi.edu> Date: Wed, 29 Jun 2011 14:03:28 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "George, Wesley" References: <20110629070025.16892.26227.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB0A7F8BAF@PRVPEXVS04.corp.twcable.com> In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0A7F8BAF@PRVPEXVS04.corp.twcable.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-13.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 21:04:18 -0000 Hi, Wes, On 6/29/2011 9:16 AM, George, Wesley wrote: > I think we're a little light on text in 7 now that we've added so > many options. I think it would be helpful to provide some rationale > as to why AO is preferred over the other methods, why they are > considered a secondary option, etc. IOW, why *shouldn't* I just keep > using TLS or SSH transport? Why is AO actually better/eventually > mandatory to implement? Multiple members of this WG had strong > opinions, we should be documenting our reasoning. Convince the reader > that they should be yelling at YFV for AO support... I agree it would be useful to explain this, e.g., that the reason is that TLS/SSH doesn't protect the transport layer from interruption (even if such interruption is recoverable). > 7.3 regarding MD5. At the very least, there should be a note that > TCP-MD5 has been obsoleted by TCP-AO. Agreed. And that the reason for its use is support for legacy systems where TCP-AO is not yet available, as per the AO RFC. Joe From touch@isi.edu Wed Jun 29 22:55: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 BC41311E811B; Wed, 29 Jun 2011 22:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4ngXoWRw32c; Wed, 29 Jun 2011 22:55:31 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id DF54211E8116; Wed, 29 Jun 2011 22:55:31 -0700 (PDT) Received: from [172.16.0.187] (216.156.178.2.ptr.us.xo.net [216.156.178.2]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p5U5t1qT004389 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 29 Jun 2011 22:55:10 -0700 (PDT) Message-ID: <4E0C0FB3.8080602@isi.edu> Date: Wed, 29 Jun 2011 22:54:59 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "tsv-ads@tools.ietf.org" , IETF discussion list , "sidr@ietf.org" , draft-ietf-karp-design-guide@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: TSV Dir Subject: [sidr] TSVDIR review of draft-ietf-karp-design-guide X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 30 Jun 2011 05:55:32 -0000 Hi, all, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. The document discusses design issues for protecting routing protocols. The most problematic issue is the term "on the wire" which is used in various contexts to imply physical, link, network, or transport protocol layers. This needs to be clarified. Transport protection appears to be a potential focus of the design guide, but is inconsistently discussed. In some cases, transport issues are raised (TCP issues for BGP); in other cases, the relevant transport isn't even noted (e.g., RIP over UDP). This should be corrected throughout. It is important for this document to be more clear on what layers were in scope for the design guide, and what guidelines are being given with respect to those layers, even in a general sense. Further information on these issues is provided below. There is additional feedback provided below ("other notes") as a suggestion. I hope this feedback will be useful to the authors, and will be glad to provide further assistance either on- or off-list as useful. Joe --------------------------------------------------------------------- >> please note that some of these comments apply to the draft-ietf-karp-threats-reqs-03 as well; further, there is duplicate text that is not needed in both these docs. FWIW, the threats-reqs doc has many issues as well which are not addressed here. Of the four issues noted in the intro, the last uses the ambiguous term "on the wire". This is confusing in both this and the threats doc, and many times both docs us the term 'wire' or 'bits', all of which would typically indicate either the link layer or the physical media or both. There is no rationale for this focus in either document. The threats document should more clearly indicate *why* protection beyond the routing messages (the SIDR work) is needed, and what the expected threats are. These appear to be: - routing protocols often rely on information in the link, transport or network packets - routing protocols often rely on properties of transport connections to infer reachability, e.g., if a TCP connection cannot stay up, then the endpoint's routes should not be considered reachable (if there are other reasons, please clarify) The threats then appear to be: - spoofing link/network addresses - spoofing transport ports - disrupting the TCP connection (where TCP is used) Note that falsification (as noted in the threats doc) is not in this list since it is (IMO) clearly the purvue of the SIDR work. Also out of scope should have been any of the interference issues, unless the *performance* of the TCP connection needs protection. This doc then may need to protect the link or network protocol ID and/or transport protocol from interference. This should be more clearly stated in the threats doc, IMO, and the term "on the wire" should be avoided. The discussion of multicast should note that multicast can be implemented by broadcast, true multicast, or serial unicast; these may have different security requirements. The document should more clearly indicate the underlying protocol used as a key property of a routing protocol, especially because (as above) this document appears to focus on guidelines for link, network, and/or transport protocols. E.g., the discussion on OSPF, RIP, and ISIS should more clearly indicate that, e.g., RIP runs over UDP, OSPF runs over IP directly, and IS-IS runs natively over L2. Similar info would be useful for BFD, RSVP, etc. The document is unclear on its overall advice, other than a somewhat general description of "do good stuff". E.g., it notes: Not all routing protocol authentication mechanisms provide support for replay attacks, and the design teams should identify such authentication mechanisms and work on them so that this can get fixed. The design teams must look at the protocols that they are working on and see if packets captured from the previous/stale sessions can be replayed. More specific advice would be, e.g.: Not all routing protocol authentication mechanisms provide protection from replay attacks. Such deficiencies should be addressed at that layer, rather than having design teams conclude that such systems thus require lower layer (transport, network, or link) protection from replays. ---- Other notes: Overall, this document would benefit from a revision focused on clarification, where the focus of each section and advice were made more clear. The abstract is excessively detailed and doesn't get to the point until "This document...". Everything preceding that should be removed, and the result should be appended with a few sentences summarizing the recommendations. The intro refers in a lot of detail to the motivation for the doc (some of which may be historically important but is not relevant to the doc itself), but only briefly notes the KARP threats document. This document's observations should be motivated by addressing those threats, so it would be important to summarize them in this doc in the intro as context. The summary of RFC 4984 discusses four tightening steps as if they were indicated by that RFC; that RFC only suggests tightening itself. This doc should more clearly indicate that "The WG identified four...". ----- From hannes@juniper.net Wed Jun 29 23:24: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 6055D11E811B for ; Wed, 29 Jun 2011 23:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Phbe2sk-ID0u for ; Wed, 29 Jun 2011 23:24:19 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCCC11E8136 for ; Wed, 29 Jun 2011 23:24:19 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTgwWjUVZP5k3JJU5cZeev+rph9ZPKlmm@postini.com; Wed, 29 Jun 2011 23:24:19 PDT Received: from hannes-755.juniper.net (172.30.152.52) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.2.254.0; Wed, 29 Jun 2011 23:21:50 -0700 Received: by hannes-755.juniper.net (Postfix, from userid 1000) id 4296721E46; Thu, 30 Jun 2011 08:21:42 +0200 (CEST) Date: Thu, 30 Jun 2011 08:21:42 +0200 From: Hannes Gredler To: Randy Bush Message-ID: <20110630062137.GA19984@juniper.net> References: <20110629070025.16892.26227.idtracker@ietfa.amsl.com> <20110629091651.GA17888@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-13.txt / error handling; X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 30 Jun 2011 06:24:20 -0000 On Wed, Jun 29, 2011 at 08:03:14PM +0900, Randy Bush wrote: | hi hannes, | | first, i need to confess that i have disagreed with 'be liberal in what | you accept' from day zero. that way lies entropy. | | > 5: Unsupported PDU Type (fatal): The PDU Type is not known by the | > receiver of the PDU. | > | > <-- this prevents seamless upgrading once we want to extend the protocol; | > why is this fatal ? | | not exactly. it prevents chaotic pretend upgrading producing a bunch of | incorrect garbage in the router's database which leads to incorrect | validity decisions and thus incorrect routing. | | imagine that the unrecognized pdu was signaling "flush all data with | origin AS 42," or "delete all roas for prefix P or longer." 1. the router does not recognize the new PDU and returns an error. 2. by including the unrecognized PDU in the error message the cache knows what particular PDU type has caused grief, such that it can log it and bring it to the operators attention. --- ok lets go through this: i was worried about e.g. a "central" deployment model where all your ASBRs have a session to a central cache. now consider you want to upgrade the cache with rob's latest sw (which introduces new PDUs). now all rpki-rtr sessions start to flap, unless you have upgraded routers to support the new PDUs. - you might argue that you should simply upgrade the routers first, thereby implying a certain upgrade order/procedure. that is going to be a problem: at some of my larger customers operational responsibilities (routers, servers) are strictly seperate and this hidden requirement to upgrade routers first, will likely be causing support-tickets at vendors of routing and local-cache software. | > 6: Withdrawal of Unknown Record (fatal): The received PDU has Flag=0 | > but a record for the Prefix/PrefixLength/MaxLength triple does not | > exist in the receiver's database. | > | > 7: Duplicate Announcement Received (fatal): The received PDU has an | > identical {prefix, len, max-len, asn} tuple as a PDU which is | > still active in the router. | > | > <-- why do we need to reset the session here for reasons 6 & 7 ? - | > in the spirit of "be tolerant what you receive" a receiving router | > can do the right thing w/o disrupting the session. | | in general, all these indicate that the receiver and the sender are | seriously out of whack. e.g. if the receiver goes ahead despite 6 or 7, | the receiver's data are most likely incorrect in the sense that it will | [in]validate an update which it should not. if that's not fatal, what | is? the IP PDUs in the protocol have canceling semantics - i.e. latest status wins. so whats the point in bitching about the latest state ? | but, i think at root, we have a disagreement on the idea of requiring | 'correctness.' as i said, i admit to being a naggumite. consider the following exchange: (all IPvXn prefix PDUd carry exactly the same update); Cache Router ~ ~ | -------- Notify ----------> | (optional) | | | <----- Reset Query -------- | R requests data | | | ----- Cache Response -----> | C confirms request | ------- IPvX Prefix1 -----> | C sends zero or more | ------- IPvX Prefix2 -----> | IPv4 and IPv6 Prefix | ------- IPvX Prefix3 -----> | Payload PDUs | ------ End of Data ------> | C sends End of Data | | and sends new serial | <----- Reset Query -------- | R requests data | | | ----- Cache Response -----> | C confirms request | ------- IPvX Prefix1 -----> | C sends zero or more | ------- IPvX Prefix2 -----> | IPv4 and IPv6 Prefix | ------- IPvX Prefix3 -----> | Payload PDUs | ------ End of Data ------> | C sends End of Data | | and sends new serial question: is the second IPvX Prefix1 Update a duplicate update ? if so: must the cache filter those out ? if so: how can i guarantee that a "Reset Query" really gets me the latest view ? From jmh@joelhalpern.com Thu Jun 30 06:13: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 D271B11E8097; Thu, 30 Jun 2011 06:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1k7lrCiy234; Thu, 30 Jun 2011 06:13:50 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAAC21F8713; Thu, 30 Jun 2011 06:13:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id E06263228BC8; Thu, 30 Jun 2011 06:13:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-33.clppva.btas.verizon.net [71.161.50.33]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 74D763228A73; Thu, 30 Jun 2011 06:13:18 -0700 (PDT) Message-ID: <4E0C7669.3080907@joelhalpern.com> Date: Thu, 30 Jun 2011 09:13:13 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Joe Touch References: <4E0C0FB3.8080602@isi.edu> In-Reply-To: <4E0C0FB3.8080602@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tsv-ads@tools.ietf.org" , TSV Dir , draft-ietf-karp-design-guide@tools.ietf.org, IETF discussion list , "sidr@ietf.org" Subject: Re: [sidr] TSVDIR review of draft-ietf-karp-design-guide X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 30 Jun 2011 13:13:50 -0000 I am conufsed by this review of the KARP design guidelines document. My first reaction was that I had trouble understanding the general points. However, when I looked at the more detailed explaantion, what I see is "The threats document should ...". But this is not a review of the threats document. As a result, when the review then says "the document" I have no idea what document is meant. In addition to that general comment, I am completely unable to understand the reviewers concern with the use of the term "on the wire". I can believe that there is an issue with the way it is used, but have no clue how to begin to address it. Similarly, there is an assertion that it is important for the document to be more clear on what layers are in and out of scope. This is comment seems to be an assertion by the reviewer not grounded in the document. Neither document is not a scope document. The scope is defined by the charter. Discussion of layers where it is not needed is a distraction. If there are specific places where such additions would be helpful, that is a comment we can react to. As a lesser issue, it is not clear that the different ways of delivering multiple content are actually relevant to the design guidleines document. The different routing protocols have their modes of operations. Ones which send distinct messages to distinct peers are different from ones which, as routing protocols sned single messages to broadcast or multicast. As such, it is not at all clear what the reviewer is asking be clarified in this regard. Yours, Joel M. Halpern On 6/30/2011 1:54 AM, Joe Touch wrote: > Hi, all, > > I've reviewed this document as part of the transport area directorate's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the > document's authors for their information and to allow them to address > any issues raised. The authors should consider this review together with > any other last-call comments they receive. Please always CC > tsv-dir@ietf.org if you reply to or forward this review. > > The document discusses design issues for protecting routing protocols. > > The most problematic issue is the term "on the wire" which is used in > various contexts to imply physical, link, network, or transport protocol > layers. This needs to be clarified. > > Transport protection appears to be a potential focus of the design > guide, but is inconsistently discussed. In some cases, transport issues > are raised (TCP issues for BGP); in other cases, the relevant transport > isn't even noted (e.g., RIP over UDP). This should be corrected throughout. > > It is important for this document to be more clear on what layers were > in scope for the design guide, and what guidelines are being given with > respect to those layers, even in a general sense. > > Further information on these issues is provided below. There is > additional feedback provided below ("other notes") as a suggestion. > > I hope this feedback will be useful to the authors, and will be glad to > provide further assistance either on- or off-list as useful. > > Joe > > --------------------------------------------------------------------- > > >> please note that some of these comments apply to the > draft-ietf-karp-threats-reqs-03 as well; further, there is duplicate > text that is not needed in both these docs. FWIW, the threats-reqs doc > has many issues as well which are not addressed here. > > Of the four issues noted in the intro, the last uses the ambiguous term > "on the wire". This is confusing in both this and the threats doc, and > many times both docs us the term 'wire' or 'bits', all of which would > typically indicate either the link layer or the physical media or both. > There is no rationale for this focus in either document. > > The threats document should more clearly indicate *why* protection > beyond the routing messages (the SIDR work) is needed, and what the > expected threats are. These appear to be: > - routing protocols often rely on information in the > link, transport or network packets > - routing protocols often rely on properties of transport > connections to infer reachability, e.g., if a TCP connection > cannot stay up, then the endpoint's routes should not be > considered reachable > (if there are other reasons, please clarify) The threats then appear to be: > - spoofing link/network addresses > - spoofing transport ports > - disrupting the TCP connection (where TCP is used) > Note that falsification (as noted in the threats doc) is not in this > list since it is (IMO) clearly the purvue of the SIDR work. Also out of > scope should have been any of the interference issues, unless the > *performance* of the TCP connection needs protection. > > This doc then may need to protect the link or network protocol ID and/or > transport protocol from interference. This should be more clearly stated > in the threats doc, IMO, and the term "on the wire" should be avoided. > > The discussion of multicast should note that multicast can be > implemented by broadcast, true multicast, or serial unicast; these may > have different security requirements. > > The document should more clearly indicate the underlying protocol used > as a key property of a routing protocol, especially because (as above) > this document appears to focus on guidelines for link, network, and/or > transport protocols. E.g., the discussion on OSPF, RIP, and ISIS should > more clearly indicate that, e.g., RIP runs over UDP, OSPF runs over IP > directly, and IS-IS runs natively over L2. Similar info would be useful > for BFD, RSVP, etc. > > The document is unclear on its overall advice, other than a somewhat > general description of "do good stuff". E.g., it notes: > > Not all routing protocol authentication mechanisms provide > support for replay attacks, and the design teams should > identify such authentication mechanisms and work on them so > that this can get fixed. The design teams must look at the > protocols that they are working on and see if packets captured > from the previous/stale sessions can be replayed. > > More specific advice would be, e.g.: > > Not all routing protocol authentication mechanisms provide > protection from replay attacks. Such deficiencies should > be addressed at that layer, rather than having design > teams conclude that such systems thus require lower layer > (transport, network, or link) protection from replays. > > ---- > Other notes: > > Overall, this document would benefit from a revision focused on > clarification, where the focus of each section and advice were made more > clear. > > The abstract is excessively detailed and doesn't get to the point until > "This document...". Everything preceding that should be removed, and the > result should be appended with a few sentences summarizing the > recommendations. > > The intro refers in a lot of detail to the motivation for the doc (some > of which may be historically important but is not relevant to the doc > itself), but only briefly notes the KARP threats document. This > document's observations should be motivated by addressing those threats, > so it would be important to summarize them in this doc in the intro as > context. > > The summary of RFC 4984 discusses four tightening steps as if they were > indicated by that RFC; that RFC only suggests tightening itself. This > doc should more clearly indicate that "The WG identified four...". > > ----- > > > > > > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From touch@isi.edu Thu Jun 30 06:53: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 3141321F85C1; Thu, 30 Jun 2011 06:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjZxriZjSnEX; Thu, 30 Jun 2011 06:53:47 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id DEA4921F85AE; Thu, 30 Jun 2011 06:53:44 -0700 (PDT) Received: from [172.16.0.187] (216.156.178.2.ptr.us.xo.net [216.156.178.2]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p5UDqfj1023899 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 30 Jun 2011 06:52:50 -0700 (PDT) Message-ID: <4E0C7FA7.6090701@isi.edu> Date: Thu, 30 Jun 2011 06:52:39 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Joel M. Halpern" References: <4E0C0FB3.8080602@isi.edu> <4E0C7669.3080907@joelhalpern.com> In-Reply-To: <4E0C7669.3080907@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tsv-ads@tools.ietf.org" , TSV Dir , draft-ietf-karp-design-guide@tools.ietf.org, IETF discussion list , "sidr@ietf.org" Subject: Re: [sidr] TSVDIR review of draft-ietf-karp-design-guide X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 30 Jun 2011 13:53:49 -0000 Hi Joel, On 6/30/2011 6:13 AM, Joel M. Halpern wrote: > I am conufsed by this review of the KARP design guidelines document. > My first reaction was that I had trouble understanding the general > points. However, when I looked at the more detailed explaantion, what I > see is "The threats document should ...". But this is not a review of > the threats document. > As a result, when the review then says "the document" I have no idea > what document is meant. From the design guide section 1: Readers must refer to the [I-D.ietf-karp-threats-reqs] for a clear definition of the scope, goals, non goals and the audience for the design work being undertaken in KARP WG. I did so, and found issues there that caused problems here, which is why those issues are included. > In addition to that general comment, I am completely unable to > understand the reviewers concern with the use of the term "on the wire". > I can believe that there is an issue with the way it is used, but have > no clue how to begin to address it. There are more than a few who frequently refer to a protocol's "packets on the wire". This is ambiguous and can mean: - app messages (here, routing PDUs) - transport messages (e.g., TCP segments) - network messages (e.g., IP packets) - link messages (e.g., ethernet segments) - the physical media (e.g., WIFI) Protecting each of these results in different kinds of defense. The document needs to avoid the use of this term as if it were well-defined in the IETF literature and unambiguous within the IETF community. > Similarly, there is an assertion that it is important for the document > to be more clear on what layers are in and out of scope. This is comment > seems to be an assertion by the reviewer not grounded in the document. > Neither document is not a scope document. The scope is defined by the > charter. Neither document should expect that readers are familiar with the charter; relevant context should be summarized in the intro (and is not, currently). The KARP charter says: --- The KARP working group is tasked to work with the routing protocol working groups in order to improve the communication security of the packets on the wire used by the routing protocols. This working group is concerned with message authentication, packet integrity, and denial of service (DoS) protection. At present, this charter explicitly excludes confidentiality and non-repudiation concerns. ... Routing protocols use a range of transport mechanisms and communication relationships. There are also differences in details among the various protocols. The working group will attempt to describe the security relevant characteristics of routings protocols, such as the use or non-use of TCP, or the frequent use of group communication versus purely pairwise communication. Using these characteristics, the working group will then provide suitable common frameworks that can be applied, and tailored, to improve the communication security of the routing protocols. In later phases, it is expected that the working group will investigate the suitably of defining conceptual structures and APIs, so as to enable further work to be more effective. --- Again, I note that "on the wire" is not clear, nor the term "packet". The term "transport mechanisms" is overloaded, but in the IETF tends to refer to layer 4; that's not appropriate here, as some important routing protocols are directly layered over L2 or L3. > Discussion of layers where it is not needed is a distraction. A design guide to secure routing protocol message exchanges needs to clearly identify, by example, the expected kinds of protection needed for the message exchange. This breaks down to two parts: A- securing the message content B- securing any information provided by the way in which the messages are exchanged 1- securing explicit info (e.g., IDs, if relied upon by the routing protocol) 2- securing implicit info (e.g., connection status, message ordering or success, etc., as used by the routing protocol) AFAICT, KARP is focused on (B) which is necessarily in the context of L2, L3, and/or L4 {where SIDR addresses (A)}. That's fine, but a *design* guide should be more clear about what B means, and what kinds of things to look out for or address. > If there are specific places where such additions would be helpful, that > is a comment we can react to. I refer you again to the intro, which states: ... Section 8.2 calls for "[t]ightening the security of the core routing infrastructure." Four main steps were identified for that tightening: o More secure mechanisms and practices for operating routers. This work is being addressed in the OPSEC Working Group. o Cleaning up the Internet Routing Registry repository [IRR], and securing both the database and the access, so that it can be used for routing verifications. This work should be addressed through liaisons with those running the IRR's globally. o Specifications for cryptographic validation of routing message content. This work will likely be addressed in the SIDR Working Group. o Securing the routing protocols' packets on the wire This document addresses the last bullet, securing the packets on the wire of the routing protocol exchanges. The third bullet describes securing routing protocol messages as out of scope. The last sentence describes "on the wire" as in scope, again as if this were a clear indication of what needs to be protected. > As a lesser issue, it is not clear that the different ways of delivering > multiple content are actually relevant to the design guidleines > document. Can you please then explain what "on the wire" means if not "differnt ways of delivering multiple content"? Isn't that exactly the scope? > The different routing protocols have their modes of > operations. Ones which send distinct messages to distinct peers are > different from ones which, as routing protocols sned single messages to > broadcast or multicast. As such, it is not at all clear what the > reviewer is asking be clarified in this regard. The difference between unicast and multicast is important, but so is the difference between whether a protocol relies on a connection being up, or message delivery being ordered. Again, specifically: B- securing any information provided by the way in which the messages are exchanged 1- securing explicit info (e.g., IDs, if relied upon by the routing protocol) 2- securing implicit info (e.g., connection status, message ordering or success, etc., as used by the routing protocol) IMO, neither B1 nor B2 is sufficiently addressed in this doc, and neither can be addressed in the absence of a clear discussion of the different properties of L2, L3, and/or L4 as they impact routing protocols over which they operate. Joe > Yours, > Joel M. Halpern > > On 6/30/2011 1:54 AM, Joe Touch wrote: >> Hi, all, >> >> I've reviewed this document as part of the transport area directorate's >> ongoing effort to review key IETF documents. These comments were written >> primarily for the transport area directors, but are copied to the >> document's authors for their information and to allow them to address >> any issues raised. The authors should consider this review together with >> any other last-call comments they receive. Please always CC >> tsv-dir@ietf.org if you reply to or forward this review. >> >> The document discusses design issues for protecting routing protocols. >> >> The most problematic issue is the term "on the wire" which is used in >> various contexts to imply physical, link, network, or transport protocol >> layers. This needs to be clarified. >> >> Transport protection appears to be a potential focus of the design >> guide, but is inconsistently discussed. In some cases, transport issues >> are raised (TCP issues for BGP); in other cases, the relevant transport >> isn't even noted (e.g., RIP over UDP). This should be corrected >> throughout. >> >> It is important for this document to be more clear on what layers were >> in scope for the design guide, and what guidelines are being given with >> respect to those layers, even in a general sense. >> >> Further information on these issues is provided below. There is >> additional feedback provided below ("other notes") as a suggestion. >> >> I hope this feedback will be useful to the authors, and will be glad to >> provide further assistance either on- or off-list as useful. >> >> Joe >> >> --------------------------------------------------------------------- >> >> >> please note that some of these comments apply to the >> draft-ietf-karp-threats-reqs-03 as well; further, there is duplicate >> text that is not needed in both these docs. FWIW, the threats-reqs doc >> has many issues as well which are not addressed here. >> >> Of the four issues noted in the intro, the last uses the ambiguous term >> "on the wire". This is confusing in both this and the threats doc, and >> many times both docs us the term 'wire' or 'bits', all of which would >> typically indicate either the link layer or the physical media or both. >> There is no rationale for this focus in either document. >> >> The threats document should more clearly indicate *why* protection >> beyond the routing messages (the SIDR work) is needed, and what the >> expected threats are. These appear to be: >> - routing protocols often rely on information in the >> link, transport or network packets >> - routing protocols often rely on properties of transport >> connections to infer reachability, e.g., if a TCP connection >> cannot stay up, then the endpoint's routes should not be >> considered reachable >> (if there are other reasons, please clarify) The threats then appear >> to be: >> - spoofing link/network addresses >> - spoofing transport ports >> - disrupting the TCP connection (where TCP is used) >> Note that falsification (as noted in the threats doc) is not in this >> list since it is (IMO) clearly the purvue of the SIDR work. Also out of >> scope should have been any of the interference issues, unless the >> *performance* of the TCP connection needs protection. >> >> This doc then may need to protect the link or network protocol ID and/or >> transport protocol from interference. This should be more clearly stated >> in the threats doc, IMO, and the term "on the wire" should be avoided. >> >> The discussion of multicast should note that multicast can be >> implemented by broadcast, true multicast, or serial unicast; these may >> have different security requirements. >> >> The document should more clearly indicate the underlying protocol used >> as a key property of a routing protocol, especially because (as above) >> this document appears to focus on guidelines for link, network, and/or >> transport protocols. E.g., the discussion on OSPF, RIP, and ISIS should >> more clearly indicate that, e.g., RIP runs over UDP, OSPF runs over IP >> directly, and IS-IS runs natively over L2. Similar info would be useful >> for BFD, RSVP, etc. >> >> The document is unclear on its overall advice, other than a somewhat >> general description of "do good stuff". E.g., it notes: >> >> Not all routing protocol authentication mechanisms provide >> support for replay attacks, and the design teams should >> identify such authentication mechanisms and work on them so >> that this can get fixed. The design teams must look at the >> protocols that they are working on and see if packets captured >> from the previous/stale sessions can be replayed. >> >> More specific advice would be, e.g.: >> >> Not all routing protocol authentication mechanisms provide >> protection from replay attacks. Such deficiencies should >> be addressed at that layer, rather than having design >> teams conclude that such systems thus require lower layer >> (transport, network, or link) protection from replays. >> >> ---- >> Other notes: >> >> Overall, this document would benefit from a revision focused on >> clarification, where the focus of each section and advice were made more >> clear. >> >> The abstract is excessively detailed and doesn't get to the point until >> "This document...". Everything preceding that should be removed, and the >> result should be appended with a few sentences summarizing the >> recommendations. >> >> The intro refers in a lot of detail to the motivation for the doc (some >> of which may be historically important but is not relevant to the doc >> itself), but only briefly notes the KARP threats document. This >> document's observations should be motivated by addressing those threats, >> so it would be important to summarize them in this doc in the intro as >> context. >> >> The summary of RFC 4984 discusses four tightening steps as if they were >> indicated by that RFC; that RFC only suggests tightening itself. This >> doc should more clearly indicate that "The WG identified four...". >> >> ----- >> >> >> >> >> >> >> >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> From wesley.george@twcable.com Thu Jun 30 07:14: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 773EB11E813E for ; Thu, 30 Jun 2011 07:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.049 X-Spam-Level: X-Spam-Status: No, score=-0.049 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOoBOxUXDLmX for ; Thu, 30 Jun 2011 07:14:46 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id D4BDF11E814C for ; Thu, 30 Jun 2011 07:14:45 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.65,450,1304308800"; d="scan'208";a="230442316" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 30 Jun 2011 10:14:02 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Thu, 30 Jun 2011 10:14:45 -0400 From: "George, Wesley" To: Randy Bush Date: Thu, 30 Jun 2011 10:14:43 -0400 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-13.txt Thread-Index: Acw2nBNpBPJVk5uOR9G6sXPoW5OsjgAkgbtg Message-ID: <34E4F50CAFA10349A41E0756550084FB0A7F907B@PRVPEXVS04.corp.twcable.com> References: <20110629070025.16892.26227.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB0A7F8BAF@PRVPEXVS04.corp.twcable.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-13.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 14:14:46 -0000 -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Wednesday, June 29, 2011 4:35 PM To: George, Wesley Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-13.txt > I think we're a little light on text in 7 now that we've added so many > options. I think it would be helpful to provide some rationale as to > why AO is preferred over the other methods, why they are considered a > secondary option, etc. > > IOW, why *shouldn't* I just keep using TLS or SSH transport? Why is AO > actually better/eventually mandatory to implement? Multiple members of > this WG had strong opinions, we should be documenting our > reasoning. Convince the reader that they should be yelling at YFV for > AO support... > > 7.3 regarding MD5. At the very least, there should be a note that > TCP-MD5 has been obsoleted by TCP-AO. this is all covered in the transport area. do we really want this routing security doc to get into the transport wars? where's the win? Like it or not, it's already in the middle of it - the additions to this se= ction are a direct result of feedback that it would not be approved if it o= nly used MD5 and a lack of support for AO. You're welcome to cite sections of other drafts or RFCs from transport that= cover this, I'm not asking specifically for new text unless none exists th= at is adequate. The win is completeness for the audience beyond the current participants in= this WG. I've been party to the discussions because I've been following th= e list, and it still brought up the question in my mind. What happens when = people who aren't on SIDR and/or are not familiar with the transport area s= tart reading this and are looking for some rationale and guidance? As I've said in earlier messages, you have to remember that the folks imple= menting this in networks are the routing folks. They're not necessarily the= same folks as the security folks, and so you have to assume slightly less = background knowledge when it comes to the nuances of the security considera= tions of this implementation. Wes 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.