From rgaglian@fing.edu.uy Sat Aug 1 11:50:06 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A8433A6B26 for ; Sat, 1 Aug 2009 11:50: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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+9YJMFy01BQ for ; Sat, 1 Aug 2009 11:50:04 -0700 (PDT) Received: from davinci.fing.edu.uy (davinci.fing.edu.uy [164.73.32.2]) by core3.amsl.com (Postfix) with ESMTP id A553D3A697E for ; Sat, 1 Aug 2009 11:48:51 -0700 (PDT) Received: from [10.196.2.33] (static-136-246-226-77.ipcom.comunitel.net [77.226.246.136] (may be forged)) (authenticated bits=0) by davinci.fing.edu.uy with ESMTP id n71Imi0X011657; Sat, 1 Aug 2009 15:48:46 -0300 (UYT) Message-Id: From: Roque Gagliano To: Sandra Murphy In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 1 Aug 2009 13:09:45 -0300 References: <31E95EEC-0668-450F-8DBA-46503BDEE70A@apnic.net> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (davinci.fing.edu.uy [164.73.32.2]); Sat, 01 Aug 2009 15:48:49 -0300 (UYT) X-Scanned-By: MIMEDefang 2.63 on 164.73.32.2 Cc: Sandy Murphy , sidr@ietf.org Subject: Re: [sidr] Request for WG adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2009 18:50:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I support the adoption. Roque. On Jul 31, 2009, at 10:30 AM, Sandra Murphy wrote: > I am opening a two week call for comments on this request for =20 > working group adoption of draft-huston-sidr-rpki-algs-00.txt. > > The draft is available at = http://www.ietf.org/id/draft-huston-sidr-rpki-algs-00.txt=20 > . > > As usual, the rules are that silence does not indicate assent, so =20 > please actively reply. > > If you support adoption of this draft as a working group item, =20 > please also indicate whether you will be able to work on the draft =20 > (contribute or review). > > The call for adoption will end Friday, Aug 14, 2009. > > This is a call for adoption only, so comments on the contents are =20 > not necessary or needed. > > --Sandy > > On Fri, 31 Jul 2009, Geoff Huston wrote: > >> Hi Sandy, >> >> With my WG co-chair hat off I would like to request WG adoption of =20= >> the draft draft-huston-sidr-rpki-algs-00.txt. >> >> I believe that this document addresses WG concerns regarding how to =20= >> specify algorithms and key sizes in the RPKI profile in a manner =20 >> that does not over burden the CP nor require a re-issue of the =20 >> certificate profile specification as and when changes to the =20 >> algorithms and key sizes are considered prudent for the RPKI, as =20 >> discussed in the WG meeting this week. >> >> >> thanks, >> >> Geoff >> >> >> >> _______________________________________________ >> 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkp0aMkACgkQnk+WSgHpbO7x1QCfenFKfp+o/AUmKLjrjqdcmt4x ZusAn2prYZ4eAKp6aaPkdq91dCcLaDix =3Dh6qf -----END PGP SIGNATURE----- From terry.manderson@icann.org Sun Aug 2 02:08:11 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 273D33A6B32 for ; Sun, 2 Aug 2009 02:08: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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxGSHh1MGD3r for ; Sun, 2 Aug 2009 02:08:10 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 744C93A69A0 for ; Sun, 2 Aug 2009 02:08:10 -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; Sun, 2 Aug 2009 02:08:13 -0700 From: Terry Manderson To: Geoff Huston Date: Sun, 2 Aug 2009 02:08:10 -0700 Thread-Topic: [sidr] revision to draft-ietf-sidr-roa-validation Thread-Index: AcoSL20VvejODSSbSJqePf6dkmnnswBIVSGp Message-ID: In-Reply-To: <895651D7-D1D3-47BE-85F6-AFC188E9A64F@apnic.net> Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Rob Austein , "sidr@ietf.org" Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2009 09:08:11 -0000 On 1/08/09 8:36 AM, "Geoff Huston" wrote: > "ends"? >=20 > perhaps an example may help here >=20 > A ROA is issued for 203.0.113.0/24, maxlength 25, oroginating AS 65534 >=20 > using only this ROA, and nothing else, the revised draft would > generate the following outcomes: >=20 > 203.0.113.0/24, originated by AS 65534 -> "valid" > 203.0.113.128/25, originated by AS 65534 -> "valid" >=20 > 203.0.113.0/26, originated by AS 65534 -> "invalid" (more specific > than max length permits) Yes, the maxLength essentially stipulates that no more specific prefixes ca= n possibly ever be valid in this example, irrespective of AS. So this implies to me that an LIR who issues a ROA for their aggregate prefix, immediately invalidates all routes of its multi-homed customers if those customers allocated from the lir prefix and do not (yet) participate in RPKI. >From your example above, the customer, with a different AS: =20 203.0.113.0/26, originated by AS 65520 -> "invalid" >>=20 >> 2) The SIDR-WG is following the paradigm of 'make before break'? >> (yes/no) >=20 >=20 > WG co-chair hat off - still. >=20 > Do IETF WGs "follow" paradigms? How are such paradigm's "adopted" to > follow in the first place? Are such "paradigms" intended to act as > strictly applied technical constraints? Where are the paradigm police > to enforce that such paradigms are obeyed? I think that is extrapolating my question in a very different direction. Perhaps my question could be rephrased. In past 'make before break' has bee= n discussed in this working group and on the mailing list, and several times participants have used that as an adjudication factor in thinking through the issues to support or rebuff options. My understanding is that currently the WG documents that highlight the overall behaviour of the SIDR posit a make before break approach. Am I incorrect in that 'reading' .. Terry From robertl@apnic.net Sun Aug 2 17:53:16 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AF213A6C05 for ; Sun, 2 Aug 2009 17:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.425 X-Spam-Level: ** X-Spam-Status: No, score=2.425 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_NET=0.311, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77GsoHwj-1HJ for ; Sun, 2 Aug 2009 17:53:15 -0700 (PDT) Received: from asmtp.apnic.net (oregano.apnic.net [IPv6:2001:dc0:2001:a:4608::60]) by core3.amsl.com (Postfix) with ESMTP id 3AC1F3A6841 for ; Sun, 2 Aug 2009 17:53:15 -0700 (PDT) Received: from [203.119.42.183] (dynamic183.apnic.net [203.119.42.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id A9497110061; Mon, 3 Aug 2009 10:53:15 +1000 (EST) Message-ID: <4A7634FB.1070005@apnic.net> Date: Mon, 03 Aug 2009 10:53:15 +1000 From: Robert Loomans Organization: APNIC - http://www.apnic.net/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.18) Gecko/20081105 Lightning/0.9 Thunderbird/2.0.0.18 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Sandra Murphy References: <31E95EEC-0668-450F-8DBA-46503BDEE70A@apnic.net> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=C6B3AE7E; url=http://robert.loomans.org/0xC6B3AE7E.asc Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAMAAABg3Am1AAAAGFBMVEUbGxs1NTVVVVVycnKO jo6tra3MzMzg4OAC8PijAAACVElEQVR42pWVW3bjMAxDKT6U/e94AJBWXLcfHrRJpBhXoKjj2D7Q hqoyI8Jv4vTxTW6b4ZLOcD6do3XzA1g9qEKK0orGmeSuWGIHKCZE1KZkwgtA4oOzwjsMB4DRehID ULFgqc+ls49gwOami0xcwI41ipkfFRzWTWKlqZCi1ZpwRVRGQtHXG6gqRyHtN1tH1X0gMF0x+pPV 5fKs+/pSfh4yrh8AmvD11C9gM8CjQERgv+ds5/TiCWTSwYjKjc7kD8ViCT8AnzOBdppreyOOnSVc iLrkI/j3+g2E9fTItHjbEmVrcAfWmlFRTOhhJgImIUv/Uph57VmAS1+JWTt82brC8gCIHQub0yWl gAXAG5AGABGcBp0NdIs2zxjwXZGBVBIYUwL8DuhUhPEuOGePAAhllAUdAtzSMl0OgMANQAiIPXdZ GV6KKwCxMATBzaVTTOwISQCkDe6wORG91zVJARioOQK6Zzw3ekaV0gHKg0oCImKXr/wFxAMIAgrw rDAYngm9a/sCBbF3jojlDaj8KS8agGmA7jcAr8K1cXWHJmCAbIBT+Um4tekoES6dCgV4KxFBj86S IQcwdbkB/2pVyUQ7pOGpaLpaBI6i6IrZhLJcwCz1TFBEDDHt8gkIXTjAUYV6OgoBE6DsEKDnxgCW Kr7tNE0AgXtbPRrAxRi1p3TDzcEc4MjMco9ZjgTg8h/gKf465/d54GZXESr7DyD4a5vZ/m0vVE3I X/ZGG5oHiL3T/uCPcntPLBX0Hgh2y18DVf3AfQ/sD/U+IUoPKvsPLV/2p/4BtMMZxXNLW/wAAAAA SUVORK5CYII= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Sandy Murphy , sidr@ietf.org Subject: Re: [sidr] Request for WG adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 00:53:16 -0000 I support adoption, and I will review. Rob -- Robert Loomans email: robertl@apnic.net Senior Software Engineer, APNIC sip: robertl@voip.apnic.net http://www.apnic.net/ phone: +61 7 3858 3100 From ggm@apnic.net Sun Aug 2 19:14:08 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73ABB3A6C65 for ; Sun, 2 Aug 2009 19:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.809 X-Spam-Level: X-Spam-Status: No, score=0.809 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SBXMp8ObHXM for ; Sun, 2 Aug 2009 19:14:07 -0700 (PDT) Received: from asmtp.apnic.net (oregano.apnic.net [IPv6:2001:dc0:2001:a:4608::60]) by core3.amsl.com (Postfix) with ESMTP id 7C19C3A683E for ; Sun, 2 Aug 2009 19:14:06 -0700 (PDT) Received: from dynamic157.apnic.net (dynamic157.apnic.net [203.119.42.157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 83783110066 for ; Mon, 3 Aug 2009 12:14:05 +1000 (EST) Message-Id: From: George Michaelson To: sidr@ietf.org In-Reply-To: <11CC0A9E-2829-46E2-BD7B-136DF96E58C7@apnic.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 3 Aug 2009 12:14:05 +1000 References: <561CF52A-FFDE-409A-81B4-0A68F5C73718@apnic.net> <11CC0A9E-2829-46E2-BD7B-136DF96E58C7@apnic.net> X-Mailer: Apple Mail (2.935.3) Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 02:14:08 -0000 On 30/07/2009, at 8:59 PM, Geoff Huston wrote: > WG Chair hat off > > It is my impression from the WG discussion at IETF 75 on the > interpretation of a ROA that there is a common view that a ROA acts > as an implicit "denial" for those route objects that have address > prefixes that are more specific than the set of prefixes specified > in the ROA, and for those route objects which have originating AS > numbers other than those listed in valid ROAs that span the address > prefix listed in the route object. > > I therefore propose to the WG that I will resubmit draft-huston-sidr- > roa-validation-01.txt as draft-ietf-sidr-roa-validation-02.txt on > the basis that this appears to be consistent with the discussion I > have just heard in the WG meeting this morning. > > thanks,. > > Geoff > As co-author of the draft-ietf-sidr-roa-validation I also observe that the WG has no interest in pursuing a BOA based model (an explicit denial structure) and that the revised draft therefore aligns with people's expectations in documenting the validation process. -George From terry.manderson@icann.org Sun Aug 2 19:56:08 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EE863A69DB for ; Sun, 2 Aug 2009 19:56:08 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkPQA8tmV1YN for ; Sun, 2 Aug 2009 19:56:07 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 5589D3A67FB for ; Sun, 2 Aug 2009 19:56:07 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Sun, 2 Aug 2009 19:56:10 -0700 From: Terry Manderson To: "sidr@ietf.org" Date: Sun, 2 Aug 2009 19:56:08 -0700 Thread-Topic: [sidr] revision to draft-ietf-sidr-roa-validation Thread-Index: AcoT4Ca1bTrYPis8RPOeM0PNHcUBgAABcxff Message-ID: In-Reply-To: Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 02:56:08 -0000 On 3/08/09 12:14 PM, "George Michaelson" wrote: >=20 > As co-author of the draft-ietf-sidr-roa-validation I also observe that > the WG has no interest in pursuing a BOA based model (an explicit > denial structure) and that the revised draft therefore aligns with > people's expectations in documenting the validation process. >=20 It is truly a regrettable situation that the workgroup has been lulled into this position. A ROA that has an implicit deny creates a major break scenario since the RPKI system will be in partial deployment for many years= , - the resulting requirement is that every LIR's customers MUST participate in RPKI else the issuance of the LIR's ROA will invalidate all customer announcements in the examples provided by Geoff. I cannot see then, how the RPKI will actually get deployment as it will sit in a 'too hard' basket. In effect, all ROAs have to be created in a bottom up mode, yet the resource certs issued top-down. The BOA provides two functions, to protect the un-used and unallocated resources from misuse and to allow a partial deployment mechanism in a make before break process where the LIR can adopt, and issue ROAs, and once all customers are on board - a BOA can then be issued which then 'locks down' the prefix. To adapt the logic pseudo code from Dave Ward's presentation and revert the understanding of the ROA to _not_ be and implicit 'invalid' but instead 'not_found': 1. query key =3D , data =3D origin AS 2. result =3D BGP_PFXV_STATE_NOT_FOUND 3. walk prefix roa_validation table to look for the query key 4. for each matched =B3entry=B2 node in prefix roa_validation table, 5. walk all records with different maxLength values 6. for each =B3record=B2 within range (query masklen <=3D maxLength= ) 7. if query origin AS =3D=3D record origin AS 8. result =3D BGP_PFXV_STATE_VALID 9. return (result) 10. endif 11. prefix_exists =3D TRUE 12. endfor 13. endfor 14. walk prefix boa_validation table to look for the query key 15. if matched =B3entry=B2 node in prefix boa_validation table (query maskl= en <=3D maxLength) 16. prefix_exists =3D TRUE 17. endif 18. if not prefix_exists 19. walk ASN boa_validation table to look for origin AS 20. if record found in ASN boa_validation table 21. ASN_exists =3D TRUE 22. endif 23. endif 24. if prefix_exists =3D=3D TRUE or ASN_exists =3D=3D TRUE, 25. result =3D BGP_PFXV_STATE_INVALID 26. endif 27. return (result) This allows the ROA to be created by the LIR, but provide a 'soft landing' for the LIR's customers. eg allow an adoption, and not a flag day. The BOA isn't an off switch in this case but a very valid and useful explicit deny. Terry From sra@hactrn.net Mon Aug 3 08:46:33 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37D423A6DF5 for ; Mon, 3 Aug 2009 08:46:33 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44ZHMmKoYUQi for ; Mon, 3 Aug 2009 08:46:32 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) by core3.amsl.com (Postfix) with ESMTP id 5921D3A6E36 for ; Mon, 3 Aug 2009 08:46:32 -0700 (PDT) Received: from khazad-dum.hactrn.net (unknown [IPv6:2002:425c:4242:1:215:afff:fe7f:ae5d]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "khazad-dum.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id F2B56BD68 for ; Mon, 3 Aug 2009 15:46:32 +0000 (UTC) Received: from khazad-dum.hactrn.net (localhost [IPv6:::1]) by khazad-dum.hactrn.net (Postfix) with ESMTP id 1814673472 for ; Mon, 3 Aug 2009 15:46:28 +0000 (UTC) Date: Mon, 03 Aug 2009 11:46:28 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090803154629.1814673472@khazad-dum.hactrn.net> Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 15:46:33 -0000 At Fri, 31 Jul 2009 07:57:56 -0700, Terry Manderson wrote: > > May I ask for clarification on two items, just to be sure I have it clear? > > 1) The ROA ends with an implicit deny for any more specific prefix not > encapsulated by maxLength. (ie stop more specific hijack)? (yes/no) I think I see your difficulty. ROAs have maxlen, certs don't. If any ROAs exist with certs that cover a particular prefix, that prefix is routable if and only if one or more of the ROAs in question covers the prefix. That is: in the case of a prefix longer than maxlen, an entity capable of issuing ROAs for the longer prefix demonstrably exists, but has not chosen to issue said ROAs. So this is either an oops or an attack. See Randy's slide pack for examples of the various permutations. > 2) The SIDR-WG is following the paradigm of 'make before break'? (yes/no) Can't speak for the WG. At least one implementor is trying to follow make-before-break rules when performing operations that could invalidate ROAs, because Mr. Route Flap is not your friend. From Sandra.Murphy@cobham.com Mon Aug 3 13:42:17 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0E7F28C27D for ; Mon, 3 Aug 2009 13:42:17 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oKwYUKtctSE for ; Mon, 3 Aug 2009 13:42:17 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id DB02528C285 for ; Mon, 3 Aug 2009 13:42:13 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n73KfdS9019737; Mon, 3 Aug 2009 15:41:39 -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 n73KfdA8007727; Mon, 3 Aug 2009 15:41:39 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.95]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 16:41:39 -0400 Date: Mon, 3 Aug 2009 16:41:38 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Terry Manderson In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="512908254-22216-1249332098=:612" X-OriginalArrivalTime: 03 Aug 2009 20:41:39.0038 (UTC) FILETIME=[CCF0CFE0:01CA147A] Cc: "sidr@ietf.org" Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 20:42:18 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --512908254-22216-1249332098=:612 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sun, 2 Aug 2009, Terry Manderson wrote: > > > > On 3/08/09 12:14 PM, "George Michaelson" wrote: > >> >> As co-author of the draft-ietf-sidr-roa-validation I also observe that >> the WG has no interest in pursuing a BOA based model (an explicit >> denial structure) and that the revised draft therefore aligns with >> people's expectations in documenting the validation process. >> > > It is truly a regrettable situation that the workgroup has been lulled in= to > this position. A ROA that has an implicit deny creates a major break > scenario since the RPKI system will be in partial deployment for many yea= rs, Certainly the problems of partial deployment is what motivated the call=20 for a set of use cases that would help judge the various proposals for=20 validation of BGP routes. > - the resulting requirement is that every LIR's customers MUST participat= e > in RPKI else the issuance of the LIR's ROA will invalidate all customer > announcements in the examples provided by Geoff. Another suggestion has been that an LIR/ISP with RPKI-unaware customers=20 would generate the certs and ROAs for that customer. What do do with the unaware customers will be an important consideration=20 in partial deployment and I invite everyone to consider this carefully. > > I cannot see then, how the RPKI will actually get deployment as it will s= it > in a 'too hard' basket. In effect, all ROAs have to be created in a botto= m > up mode, yet the resource certs issued top-down. > > The BOA provides two functions, to protect the un-used and unallocated > resources from misuse and to allow a partial deployment mechanism in a ma= ke > before break process where the LIR can adopt, and issue ROAs, and once al= l > customers are on board - a BOA can then be issued which then 'locks down' > the prefix. > > To adapt the logic pseudo code from Dave Ward's presentation and revert t= he > understanding of the ROA to _not_ be and implicit 'invalid' but instead > 'not_found': > > 1. query key =3D , data =3D origin AS > 2. result =3D BGP_PFXV_STATE_NOT_FOUND > 3. walk prefix roa_validation table to look for the query key > 4. for each matched =B3entry=B2 node in prefix roa_validation table, > 5. walk all records with different maxLength values > 6. for each =B3record=B2 within range (query masklen <=3D maxLeng= th) > 7. if query origin AS =3D=3D record origin AS > 8. result =3D BGP_PFXV_STATE_VALID > 9. return (result) > 10. endif > 11. prefix_exists =3D TRUE > 12. endfor > 13. endfor > 14. walk prefix boa_validation table to look for the query key > 15. if matched =B3entry=B2 node in prefix boa_validation table (query mas= klen <=3D > maxLength) > 16. prefix_exists =3D TRUE > 17. endif > 18. if not prefix_exists > 19. walk ASN boa_validation table to look for origin AS > 20. if record found in ASN boa_validation table > 21. ASN_exists =3D TRUE > 22. endif > 23. endif > 24. if prefix_exists =3D=3D TRUE or ASN_exists =3D=3D TRUE, > 25. result =3D BGP_PFXV_STATE_INVALID > 26. endif > 27. return (result) > > This allows the ROA to be created by the LIR, but provide a 'soft landing= ' > for the LIR's customers. eg allow an adoption, and not a flag day. The BO= A > isn't an off switch in this case but a very valid and useful explicit den= y. Is there a use case in the use case draft that distinguishes this=20 validation from that proposed by Dave? > > Terry > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --512908254-22216-1249332098=:612-- From root@core3.amsl.com Mon Aug 3 14:15:01 2009 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8F4373A6EB2; Mon, 3 Aug 2009 14:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090803211501.8F4373A6EB2@core3.amsl.com> Date: Mon, 3 Aug 2009 14:15:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-roa-validation-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 21:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Validation of Route Origination in BGP using the Resource Certificate PKI Author(s) : G. Huston, G. Michaelson Filename : draft-ietf-sidr-roa-validation-02.txt Pages : 8 Date : 2009-08-03 This document defines an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol. The proposed application is intended to fit within the requirements for adding security to inter-domain routing, including the ability to support incremental and piecemeal deployment, and does not require any changes to the specification of BGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-validation-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-roa-validation-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-03141132.I-D@ietf.org> --NextPart-- From pmohapat@cisco.com Mon Aug 3 14:15:29 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6CF53A6C29 for ; Mon, 3 Aug 2009 14:15:29 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-6KS-nStPIc for ; Mon, 3 Aug 2009 14:15:28 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 5635B3A6EAA for ; Mon, 3 Aug 2009 14:14:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADPwdkqrR7PE/2dsb2JhbAC7VYgpjn4FhBg X-IronPort-AV: E=Sophos;i="4.43,316,1246838400"; d="scan'208";a="222822519" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 03 Aug 2009 21:14:26 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n73LEQ17005622; Mon, 3 Aug 2009 14:14:26 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n73LEQ2d004650; Mon, 3 Aug 2009 21:14:26 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 14:14:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Aug 2009 14:14:24 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5409E0EAAE@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sidr] revision to draft-ietf-sidr-roa-validation Thread-Index: AcoT4Ca1bTrYPis8RPOeM0PNHcUBgAABcxffACXdLYA= References: From: "Pradosh Mohapatra (pmohapat)" To: "Terry Manderson" , X-OriginalArrivalTime: 03 Aug 2009 21:14:25.0832 (UTC) FILETIME=[613DC280:01CA147F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3447; t=1249334066; x=1250198066; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pmohapat@cisco.com; z=From:=20=22Pradosh=20Mohapatra=20(pmohapat)=22=20 |Subject:=20RE=3A=20[sidr]=20revision=20to=20draft-ietf-sid r-roa-validation |Sender:=20; bh=GqoKtQoDwvEBnXlwLdVjwdLsi1B1gyfU2gxVam2eb3k=; b=OVaqYYlPt48N/caKQ69yOFmGMKDgmbuMffSfG/pTosDH8g0TXGhzVHpzQt JhLUgaZPo9e1CenIvQl6tpxuIBi0PXaRkycaU9JyHmOa/tyX3GYEk1YKk80i yDyxzlxd1g; Authentication-Results: sj-dkim-4; header.From=pmohapat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 21:15:29 -0000 Hi Terry, | It is truly a regrettable situation that the workgroup has been lulled | into | this position. A ROA that has an implicit deny creates a major break | scenario since the RPKI system will be in partial deployment for many | years, | - the resulting requirement is that every LIR's customers MUST | participate | in RPKI else the issuance of the LIR's ROA will invalidate all = customer | announcements in the examples provided by Geoff. The customers do not have to participate in the RPKI. The LIR can issue = the=20 ROA on their behalf, no? In any case, yes, we do assume that the more=20 specifics that get sub-allocated should also have a corresponding ROA=20 issued. Else they become INVALID in the validation logic. I do not see = how BOAs solve the "make-before-break" problem though. The moment they = become separate instances (RPKI objects vs. prefix announcements in BGP), they = can arrive in any order and a valid prefix can become invalid or vice versa. | I cannot see then, how the RPKI will actually get deployment as it = will | sit | in a 'too hard' basket. In effect, all ROAs have to be created in a | bottom | up mode, yet the resource certs issued top-down. |=20 | The BOA provides two functions, to protect the un-used and unallocated | resources from misuse and to allow a partial deployment mechanism in a | make | before break process where the LIR can adopt, and issue ROAs, and once | all | customers are on board - a BOA can then be issued which then 'locks | down' | the prefix. |=20 | To adapt the logic pseudo code from Dave Ward's presentation and = revert | the | understanding of the ROA to _not_ be and implicit 'invalid' but = instead | 'not_found': |=20 | 1. query key =3D , data =3D origin AS | 2. result =3D BGP_PFXV_STATE_NOT_FOUND | 3. walk prefix roa_validation table to look for the query key | 4. for each matched =B3entry=B2 node in prefix roa_validation table, | 5. walk all records with different maxLength values | 6. for each =B3record=B2 within range (query masklen <=3D = maxLength) | 7. if query origin AS =3D=3D record origin AS | 8. result =3D BGP_PFXV_STATE_VALID | 9. return (result) | 10. endif | 11. prefix_exists =3D TRUE | 12. endfor | 13. endfor | 14. walk prefix boa_validation table to look for the query key | 15. if matched =B3entry=B2 node in prefix boa_validation table (query | masklen <=3D | maxLength) | 16. prefix_exists =3D TRUE | 17. endif | 18. if not prefix_exists | 19. walk ASN boa_validation table to look for origin AS | 20. if record found in ASN boa_validation table | 21. ASN_exists =3D TRUE | 22. endif | 23. endif | 24. if prefix_exists =3D=3D TRUE or ASN_exists =3D=3D TRUE, | 25. result =3D BGP_PFXV_STATE_INVALID | 26. endif | 27. return (result) Having implemented the prototype code for prefix validation, I can only=20 say that the above addition creates unnecessary complexity that I would=20 like to avoid in implementation ;-) In the BGP code on a router, I would = like to just have a database of prefix <-> AS mappings (leave the rest = to=20 the RPKI repository/cache) and perform the prefix origin validation=20 from that database. That keeps it simple and efficient. My $.002, - Pradosh From sra@hactrn.net Mon Aug 3 14:25:26 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DF843A68A5 for ; Mon, 3 Aug 2009 14:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id set+8CCHeztp for ; Mon, 3 Aug 2009 14:25:25 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 9ACFD3A685B for ; Mon, 3 Aug 2009 14:25:25 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 5BFAA28469 for ; Mon, 3 Aug 2009 21:25:27 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 0FDF022805 for ; Mon, 3 Aug 2009 17:25:27 -0400 (EDT) Date: Mon, 03 Aug 2009 17:25:27 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090803212527.0FDF022805@thrintun.hactrn.net> Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 21:25:26 -0000 At Sun, 2 Aug 2009 19:56:08 -0700, Terry Manderson wrote: > > It is truly a regrettable situation that the workgroup has been > lulled into this position. Kindly tone down the rhetoric. > A ROA that has an implicit deny creates a major break scenario since > the RPKI system will be in partial deployment for many years, - the > resulting requirement is that every LIR's customers MUST participate > in RPKI else the issuance of the LIR's ROA will invalidate all > customer announcements in the examples provided by Geoff. No, the LIR just has to issue ROAs for any of its customers that are unwilling or unable to generate their own. The LIR has to know what resources each of its children has and which of its children are RPKI-capable in any case, the rest is a small matter of programming. This has been covered on the mailing list and in presentations to the WG: see, eg, Randy's slides from the Stockholm meeting just last week. From terry.manderson@icann.org Mon Aug 3 14:45:36 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 030783A69A2 for ; Mon, 3 Aug 2009 14:45: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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dk+-XwVW+gOb for ; Mon, 3 Aug 2009 14:45:35 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 3FED33A6B9B for ; Mon, 3 Aug 2009 14:45:35 -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, 3 Aug 2009 14:45:38 -0700 From: Terry Manderson To: "Pradosh Mohapatra (pmohapat)" , "sidr@ietf.org" Date: Mon, 3 Aug 2009 14:45:36 -0700 Thread-Topic: [sidr] revision to draft-ietf-sidr-roa-validation Thread-Index: AcoT4Ca1bTrYPis8RPOeM0PNHcUBgAABcxffACXdLYAAAZULYw== Message-ID: In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5409E0EAAE@xmb-sjc-215.amer.cisco.com> Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 21:45:36 -0000 Hi Pradosh, On 4/08/09 7:14 AM, "Pradosh Mohapatra (pmohapat)" wrote: >=20 > The customers do not have to participate in the RPKI. The LIR can issue t= he Not "LIR can", "LIR MUST". That is where I have the issue, the interpretation then drives that the LIR or LIR customer have no options. > ROA on their behalf, no? In any case, yes, we do assume that the more yes, it is one option. The interpretation of ROAs makes it the only option, as all else is invalid. > specifics that get sub-allocated should also have a corresponding ROA > issued. Else they become INVALID in the validation logic. I do not see ho= w > BOAs solve the "make-before-break" problem though. The moment they become Think through the process not from a clean state RIB, but one where the RPK= I is creeping in. > separate instances (RPKI objects vs. prefix announcements in BGP), they c= an > arrive in any order and a valid prefix can become invalid or vice versa. >=20 Yes. Though premise is that right now, everything is assumed valid. >=20 >=20 > Having implemented the prototype code for prefix validation, I can only > say that the above addition creates unnecessary complexity that I would > like to avoid in implementation ;-) As a thought process, think through the prefix validation from two ROAs: AS0 1.2.3.4/24 maxLength 24 AS32 1.2.3.4/24 maxLengh 24 .. enjoy. > In the BGP code on a router, I would > like to just have a database of prefix <-> AS mappings (leave the rest to > the RPKI repository/cache) and perform the prefix origin validation > from that database. That keeps it simple and efficient. I understand that motivation. So how do you account for the case of prefix not wanting to be routed, lets say the old B-root prefix that wasn't supposed to have been seen after a certain date? >=20 > My $.002, Global Financial Crisis huh? ;-) Terry From terry.manderson@icann.org Mon Aug 3 14:50:45 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA4523A6EB9 for ; Mon, 3 Aug 2009 14:50: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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQQtxENQHUJW for ; Mon, 3 Aug 2009 14:50:45 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 3A5713A6EB2 for ; Mon, 3 Aug 2009 14:50:45 -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, 3 Aug 2009 14:50:48 -0700 From: Terry Manderson To: Rob Austein , "sidr@ietf.org" Date: Mon, 3 Aug 2009 14:50:47 -0700 Thread-Topic: [sidr] revision to draft-ietf-sidr-roa-validation Thread-Index: AcoUgPp9+uYkXzsWTo+s3CFZS5YzIAAA3rU5 Message-ID: In-Reply-To: <20090803212527.0FDF022805@thrintun.hactrn.net> Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 21:50:45 -0000 On 4/08/09 7:25 AM, "Rob Austein" wrote: > At Sun, 2 Aug 2009 19:56:08 -0700, Terry Manderson wrote: >=20 > Kindly tone down the rhetoric. Apologies if you were offended. >=20 >> A ROA that has an implicit deny creates a major break scenario since >> the RPKI system will be in partial deployment for many years, - the >> resulting requirement is that every LIR's customers MUST participate >> in RPKI else the issuance of the LIR's ROA will invalidate all >> customer announcements in the examples provided by Geoff. >=20 > No, the LIR just has to issue ROAs for any of its customers that are Not "just has to", "MUST issue". > unwilling or unable to generate their own. The LIR has to know what > resources each of its children has and which of its children are > RPKI-capable in any case, the rest is a small matter of programming. I'm sorry, I think that is glib. I think It is front ending quite a lot of work on large LIRs. Small LIRs may not have the resources. >=20 > This has been covered on the mailing list and in presentations to the > WG: see, eg, Randy's slides from the Stockholm meeting just last week. yes. I just don't agree. Terry From sra@hactrn.net Mon Aug 3 15:22:13 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8464D3A684B for ; Mon, 3 Aug 2009 15:22:13 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KX-2tgptlwXa for ; Mon, 3 Aug 2009 15:22:12 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id AC6463A6905 for ; Mon, 3 Aug 2009 15:22:12 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 6A58B28469 for ; Mon, 3 Aug 2009 22:22:14 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 1B5B822805 for ; Mon, 3 Aug 2009 18:22:14 -0400 (EDT) Date: Mon, 03 Aug 2009 18:22:14 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <20090803212527.0FDF022805@thrintun.hactrn.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090803222214.1B5B822805@thrintun.hactrn.net> Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 22:22:13 -0000 At Mon, 3 Aug 2009 14:50:47 -0700, Terry Manderson wrote: > On 4/08/09 7:25 AM, "Rob Austein" wrote: > > > No, the LIR just has to issue ROAs for any of its customers that are > > unwilling or unable to generate their own. The LIR has to know what > > resources each of its children has and which of its children are > > RPKI-capable in any case, the rest is a small matter of programming. > > I'm sorry, I think that is glib. I think It is front ending quite a lot of > work on large LIRs. Small LIRs may not have the resources. Haven't modeled in detail, but suspect work involved is on roughly the same order of magnitude as issuing certs to children in the first place. A bit more work generating the ROAs themselves, a bit less work maintaining the provisioning relationship (up-down protocol) with child. At worst it's likely a small constant multiplier, eg, 2x. Bottom line is that an LIR too small to do one is probably too small to do the other. From terry.manderson@icann.org Mon Aug 3 15:36:25 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0A6F3A6AF6 for ; Mon, 3 Aug 2009 15:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imQE03ELLb2I for ; Mon, 3 Aug 2009 15:36:25 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 46A9F3A6A4D for ; Mon, 3 Aug 2009 15:36:25 -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, 3 Aug 2009 15:36:28 -0700 From: Terry Manderson To: "Pradosh Mohapatra (pmohapat)" , "sidr@ietf.org" Date: Mon, 3 Aug 2009 15:36:27 -0700 Thread-Topic: [sidr] revision to draft-ietf-sidr-roa-validation Thread-Index: AcoT4Ca1bTrYPis8RPOeM0PNHcUBgAABcxffACXdLYAAA1utXQ== Message-ID: In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5409E0EAAE@xmb-sjc-215.amer.cisco.com> Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 22:36:26 -0000 On 4/08/09 7:14 AM, "Pradosh Mohapatra (pmohapat)" wrote: > issued. Else they become INVALID in the validation logic. I do not see ho= w > BOAs solve the "make-before-break" problem though. The moment they become > separate instances (RPKI objects vs. prefix announcements in BGP), they c= an > arrive in any order and a valid prefix can become invalid or vice versa. >=20 So here is another thought, playing devils advocate and with the understanding that in a perfect world this would never happen. This unfortunately isn't a perfect world. Lets say we are half way through the the RPKI deployment for all LIRs that have address space in 10/8. Our trusty RIR based in Elbonia does a slight error and issues a ROA for 10/8 maxLenghth /8; AS65534 - clearly in error. The downside is that it automatically makes all routes not yet covered by a ROA be invalid. According to the current interpretation. Does that not concern you? Terry From sra@hactrn.net Mon Aug 3 16:15:26 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B20843A6D2B for ; Mon, 3 Aug 2009 16:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkLC8k3FVRUt for ; Mon, 3 Aug 2009 16:15:26 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id D52CE3A6C85 for ; Mon, 3 Aug 2009 16:15:25 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id E4D9D28467 for ; Mon, 3 Aug 2009 23:15:27 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 96F9022805 for ; Mon, 3 Aug 2009 19:15:27 -0400 (EDT) Date: Mon, 03 Aug 2009 19:15:27 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <04CAD96D4C5A3D48B1919248A8FE0D5409E0EAAE@xmb-sjc-215.amer.cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090803231527.96F9022805@thrintun.hactrn.net> Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 23:15:26 -0000 At Mon, 3 Aug 2009 15:36:27 -0700, Terry Manderson wrote: > > Lets say we are half way through the the RPKI deployment for all LIRs that > have address space in 10/8. Our trusty RIR based in Elbonia does a slight > error and issues a ROA for 10/8 maxLenghth /8; AS65534 - clearly in error. > The downside is that it automatically makes all routes not yet covered by a > ROA be invalid. According to the current interpretation. > > Does that not concern you? It seems likely that your hypothetical Elbonian RIR would also manage to screw up a combination of ROAs and BOAs. Sure, screwups near the root of a tree are dangerous. Adding more ways to screw up does not seem like an improvement. In any case: I think I've said enough on this topic for a while. From terry.manderson@icann.org Mon Aug 3 17:29:43 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 229A828C0F5 for ; Mon, 3 Aug 2009 17:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xisQNRkuzifq for ; Mon, 3 Aug 2009 17:29:42 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 710E828C0D6 for ; Mon, 3 Aug 2009 17:29:42 -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; Mon, 3 Aug 2009 17:29:45 -0700 From: Terry Manderson To: Rob Austein , "sidr@ietf.org" Date: Mon, 3 Aug 2009 17:29:43 -0700 Thread-Topic: [sidr] revision to draft-ietf-sidr-roa-validation Thread-Index: AcoUkFhWDe6bdg8LRBClfZdvC0bMaQAClDhC Message-ID: In-Reply-To: <20090803231527.96F9022805@thrintun.hactrn.net> Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 00:29:43 -0000 >=20 > It seems likely that your hypothetical Elbonian RIR would also manage > to screw up a combination of ROAs and BOAs. Probably, however I posit that it would need to be a well orchestrated scre= w up of the combination of roas, boas and resource certs to then adversely affect routing if the ROA semantic was 'not_found' instead of invalid. >=20 > Sure, screwups near the root of a tree are dangerous. > Adding more ways to screw up does not seem like an improvement. One thing I'm trying to do is minimize the effect of the screw-up. Where th= e issuance of one single ROA doesn't have such a widespread and terminal effect. >=20 > In any case: I think I've said enough on this topic for a while. dare I say.. ditto. Terry From root@core3.amsl.com Tue Aug 4 05:00:01 2009 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 537FA3A7024; Tue, 4 Aug 2009 05:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090804120001.537FA3A7024@core3.amsl.com> Date: Tue, 4 Aug 2009 05:00:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-repos-struct-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 12:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Profile for Resource Certificate Repository Structure Author(s) : G. Huston, et al. Filename : draft-ietf-sidr-repos-struct-03.txt Pages : 11 Date : 2009-08-04 This document defines a profile for the structure of repository publication points that contain X.509 / PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile contains the proposed object naming scheme, the contents of repository publication points, the contents of publication point manifests 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-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-repos-struct-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-04044546.I-D@ietf.org> --NextPart-- From kent@bbn.com Tue Aug 4 07:41:20 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88C653A706C for ; Tue, 4 Aug 2009 07:41:20 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMsKrA0jiMu0 for ; Tue, 4 Aug 2009 07:41:19 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 31B4E3A705A for ; Tue, 4 Aug 2009 07:41:19 -0700 (PDT) Received: from dhcp89-089-105.bbn.com ([128.89.89.105]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MYKG2-0008Cd-DV; Tue, 04 Aug 2009 09:40:50 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20090803212527.0FDF022805@thrintun.hactrn.net> References: <20090803212527.0FDF022805@thrintun.hactrn.net> Date: Tue, 4 Aug 2009 10:29:38 -0400 To: Rob Austein From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 14:41:20 -0000 At 5:25 PM -0400 8/3/09, Rob Austein wrote: >... > >No, the LIR just has to issue ROAs for any of its customers that are >unwilling or unable to generate their own. The LIR has to know what >resources each of its children has and which of its children are >RPKI-capable in any case, the rest is a small matter of programming. Does the LIR (ISP) need to know if any of his (RPKI_incapable) customers are multi-homed and, if so, to whom they are connected, in order to generate ROAs for those paths? Steve From mlepinsk@bbn.com Tue Aug 4 08:19:48 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40A6328C3E0 for ; Tue, 4 Aug 2009 08:19:48 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aff3LspLuoGF for ; Tue, 4 Aug 2009 08:19:47 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 6941B28C405 for ; Tue, 4 Aug 2009 08:19:22 -0700 (PDT) Received: from [128.89.254.130] (helo=[127.0.0.1]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1MYLmS-0005CS-9i; Tue, 04 Aug 2009 11:18:24 -0400 Message-ID: <4A7850B8.8060209@bbn.com> Date: Tue, 04 Aug 2009 11:16:08 -0400 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sandra Murphy References: <31E95EEC-0668-450F-8DBA-46503BDEE70A@apnic.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sandy Murphy , sidr@ietf.org Subject: Re: [sidr] Request for WG adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 15:19:48 -0000 Based on the discussion in Stockholm, this seems like the right way forward on algorithms. I support adoption andam willing to review the draft. - Matt Lepinski Sandra Murphy wrote: > I am opening a two week call for comments on this request for working > group adoption of draft-huston-sidr-rpki-algs-00.txt. > > The draft is available at > http://www.ietf.org/id/draft-huston-sidr-rpki-algs-00.txt. > > As usual, the rules are that silence does not indicate assent, so > please actively reply. > > If you support adoption of this draft as a working group item, please > also indicate whether you will be able to work on the draft > (contribute or review). > > The call for adoption will end Friday, Aug 14, 2009. > > This is a call for adoption only, so comments on the contents are not > necessary or needed. > > --Sandy > > On Fri, 31 Jul 2009, Geoff Huston wrote: > >> Hi Sandy, >> >> With my WG co-chair hat off I would like to request WG adoption of >> the draft draft-huston-sidr-rpki-algs-00.txt. >> >> I believe that this document addresses WG concerns regarding how to >> specify algorithms and key sizes in the RPKI profile in a manner that >> does not over burden the CP nor require a re-issue of the certificate >> profile specification as and when changes to the algorithms and key >> sizes are considered prudent for the RPKI, as discussed in the WG >> meeting this week. >> >> >> thanks, >> >> Geoff >> >> >> >> _______________________________________________ >> 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 robert@ripe.net Tue Aug 4 10:30:06 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AF493A6F71 for ; Tue, 4 Aug 2009 10:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.845 X-Spam-Level: X-Spam-Status: No, score=-3.845 tagged_above=-999 required=5 tests=[AWL=-1.245, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x32rGUc3SnJy for ; Tue, 4 Aug 2009 10:30:05 -0700 (PDT) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id 060483A6B79 for ; Tue, 4 Aug 2009 10:30:05 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MYNpm-0005cn-W4 for sidr@ietf.org; Tue, 04 Aug 2009 19:30:04 +0200 Received: from Kistel-Mac.local (cat.ripe.net [193.0.1.249]) by herring.ripe.net (Postfix) with ESMTP id E60A42F595 for ; Tue, 4 Aug 2009 19:29:58 +0200 (CEST) Message-ID: <4A787016.2010806@ripe.net> Date: Tue, 04 Aug 2009 19:29:58 +0200 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: sidr@ietf.org References: <31E95EEC-0668-450F-8DBA-46503BDEE70A@apnic.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274c393967e226493b4905f5e7f9293fef7 Subject: Re: [sidr] Request for WG adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 17:30:06 -0000 I also support the adoption of this draft and willing to review. Robert Sandra Murphy wrote: > I am opening a two week call for comments on this request for working > group adoption of draft-huston-sidr-rpki-algs-00.txt. > > The draft is available at > http://www.ietf.org/id/draft-huston-sidr-rpki-algs-00.txt. > > As usual, the rules are that silence does not indicate assent, so please > actively reply. > > If you support adoption of this draft as a working group item, please > also indicate whether you will be able to work on the draft (contribute > or review). > > The call for adoption will end Friday, Aug 14, 2009. > > This is a call for adoption only, so comments on the contents are not > necessary or needed. > > --Sandy > > On Fri, 31 Jul 2009, Geoff Huston wrote: > >> Hi Sandy, >> >> With my WG co-chair hat off I would like to request WG adoption of the >> draft draft-huston-sidr-rpki-algs-00.txt. >> >> I believe that this document addresses WG concerns regarding how to >> specify algorithms and key sizes in the RPKI profile in a manner that >> does not over burden the CP nor require a re-issue of the certificate >> profile specification as and when changes to the algorithms and key >> sizes are considered prudent for the RPKI, as discussed in the WG >> meeting this week. >> >> >> thanks, >> >> Geoff >> >> >> >> _______________________________________________ >> 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 root@core3.amsl.com Tue Aug 4 17:30:02 2009 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EEB2F28C384; Tue, 4 Aug 2009 17:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090805003001.EEB2F28C384@core3.amsl.com> Date: Tue, 4 Aug 2009 17:30:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-rpki-manifests-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 00:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Manifests for the Resource Public Key Infrastructure Author(s) : R. Austein, et al. Filename : draft-ietf-sidr-rpki-manifests-05.txt Pages : 27 Date : 2009-08-04 This document defines a "manifest" for use in the Resource Public Key Infrastructure. A manifest is a signed object that contains a listing of all the signed objects in the repository publication point associated with an authority responsible for publishing in the repository. For each certificate, or other forms 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 expose potential attacks against relying parties of the Resource Public Key Infrastructure, such as a man-in-the middle attack of withholding repository data from relying party access, or replaying stale repository data to a relying party's access request. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-manifests-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-rpki-manifests-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-04172201.I-D@ietf.org> --NextPart-- From kent@bbn.com Tue Aug 4 18:05:07 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C021E3A68A4 for ; Tue, 4 Aug 2009 18:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPas4K5aXm5W for ; Tue, 4 Aug 2009 18:05:07 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 9EBA33A7122 for ; Tue, 4 Aug 2009 18:04:52 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[172.16.1.74]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1MYUvV-0005bH-BS; Tue, 04 Aug 2009 21:04:21 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5409E0EAAE@xmb-sjc-215.amer.cisco.com> References: <04CAD96D4C5A3D48B1919248A8FE0D5409E0EAAE@xmb-sjc-215.amer.cisco.com> Date: Tue, 4 Aug 2009 21:04:19 -0400 To: "Pradosh Mohapatra (pmohapat)" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 01:05:07 -0000 I still believe that the ability to make negative assertions seems like an important feature for incremental deployment of the RPKI. My proposal makes use of ROAs with an AS# of 0 to convey the notion that the specified prefixes are NOT to be routed. If you reject any advertisements for AS# 0 anyway, would that add any appreciable complexity to your code? Steve From kotikalapudi.sriram@nist.gov Tue Aug 4 18:01:57 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1D073A6F5A for ; Tue, 4 Aug 2009 18:01:57 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzO9LBAvlgtg for ; Tue, 4 Aug 2009 18:01:56 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 967A03A6841 for ; Tue, 4 Aug 2009 18:01:56 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n7511hKh006054; Tue, 4 Aug 2009 21:01:43 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Tue, 4 Aug 2009 21:01:31 -0400 From: "Sriram, Kotikalapudi" To: Terry Manderson , "sidr@ietf.org" Date: Tue, 4 Aug 2009 21:01:29 -0400 Thread-Topic: Soft Decision during Incremental Adoption Thread-Index: AcoT4Ca1bTrYPis8RPOeM0PNHcUBgAABcxffAF9EMHA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Subject: [sidr] Soft Decision during Incremental Adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 01:06:21 -0000 The thread subject line was: "revision to draft-ietf-sidr-roa-validation" Please allow me to use a new subject line as shown. I've read through the entire thread, and I am in agreement with Terry on the need for soft decision during partial deployment and also about the use of BOA to end the soft decision period for a prefix.=20 In Terry's words "... a BOA can then be issued which then 'locks down' the prefix." =20 I presented a slide at the Stockholm SIDR WG meeting to generate some discussion on the need for soft decision during incremental adoption. I fee= l that the outcome of the discussion was not exactly conclusive. Views were expressed both ways - to consider suballocation (or more specific prefix) "Invalid" or treat it softly as "ROA not found" (when there is no requisite ROA for it). I think some more attention must be paid to details before a conclusion is reached. I personally find it easier to describe stuff with slides and diagrams rather than just in words. So I have prepared a set of slides to highlight the details and propose two solution methods.=20 Link to the slides: http://www.antd.nist.gov/~ksriram/SIDR_ROA_BOA_Interpretation.pdf=20 It will be much appreciated if you can review the material in the slides=20 and offer your comments. (I must admit that Terry has already said in this thread=20 some of the material that I have explained in the slides, but the slides try to put it all in perspective and=20 also the idea on slide 6 would perhaps be new to this discussion.=20 I am in favor of BOA per use case as illustrated in slide 5.=20 Sriram -----Original Message----- >From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of >T= erry Manderson >Sent: Sunday, August 02, 2009 10:56 PM >To: sidr@ietf.org >Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation >On 3/08/09 12:14 PM, "George Michaelson" wrote: >>=20 >> As co-author of the draft-ietf-sidr-roa-validation I also observe that >> the WG has no interest in pursuing a BOA based model (an explicit >> denial structure) and that the revised draft therefore aligns with >> people's expectations in documenting the validation process. >It is truly a regrettable situation that the workgroup has been lulled int= o >this position. A ROA that has an implicit deny creates a major break >scenario since the RPKI system will be in partial deployment for many year= s, >- the resulting requirement is that every LIR's customers MUST participate >in RPKI else the issuance of the LIR's ROA will invalidate all customer >announcements in the examples provided by Geoff. >I cannot see then, how the RPKI will actually get deployment as it will si= t >in a 'too hard' basket. In effect, all ROAs have to be created in a bottom >up mode, yet the resource certs issued top-down. >The BOA provides two functions, to protect the un-used and unallocated >resources from misuse and to allow a partial deployment mechanism in a mak= e >before break process where the LIR can adopt, and issue ROAs, and once all >customers are on board - a BOA can then be issued which then 'locks down' >the prefix. >Terry From gih@apnic.net Tue Aug 4 18:31:48 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAFF73A6783 for ; Tue, 4 Aug 2009 18:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gZjuV8NTHuw for ; Tue, 4 Aug 2009 18:31:47 -0700 (PDT) Received: from asmtp.apnic.net (oregano.apnic.net [IPv6:2001:dc0:2001:a:4608::60]) by core3.amsl.com (Postfix) with ESMTP id 6F6903A7115 for ; Tue, 4 Aug 2009 18:31:46 -0700 (PDT) Received: from dhcp096.yarralumla.aarnet.edu.au (dhcp096.yarralumla.aarnet.edu.au [192.94.63.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 5AA84110069; Wed, 5 Aug 2009 11:31:47 +1000 (EST) Message-Id: <1FB6C249-6FEF-40C2-BC2E-A26E04A0F6D4@apnic.net> From: Geoff Huston To: Stephen Kent In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 5 Aug 2009 11:31:42 +1000 References: <04CAD96D4C5A3D48B1919248A8FE0D5409E0EAAE@xmb-sjc-215.amer.cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: sidr@ietf.org Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 01:31:48 -0000 WG Chair hat OFF On 05/08/2009, at 11:04 AM, Stephen Kent wrote: > I still believe that the ability to make negative assertions seems > like an important feature for incremental deployment of the RPKI. My > proposal makes use of ROAs with an AS# of 0 to convey the notion > that the specified prefixes are NOT to be routed. If you reject any > advertisements for AS# 0 anyway, would that add any appreciable > complexity to your code? I believe that the validation procedure described in the roa- validation working group draft and the pseudo-code the pmohapat draft are consistent in that they will mark a prefix described in an AS0 ROA as "invalid" as long as there is no other valid ROA that produces a "valid" outcome. i.e. with no additional "special case" handling, an AS0 ROA would indeed generate the "invalid" outcome and hence act as a "negative assertion" in the context of these specifications. Geoff From terry.mndrsn@gmail.com Tue Aug 4 20:51:40 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEBAD3A6819 for ; Tue, 4 Aug 2009 20:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8FptNR0WCka for ; Tue, 4 Aug 2009 20:51:40 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id 268E93A659C for ; Tue, 4 Aug 2009 20:51:40 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id f9so1202526rvb.49 for ; Tue, 04 Aug 2009 20:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=dyqZmXSA2jIM6fX3aetKcMUQDcLrgxmAGpXgfFr2A+s=; b=fealAXW25gMSbBtgUt3x/tjanfyL778AvuOE/ZjtJERVZm7zPYQ8yLFyJ5dA58qR8c +VfY21YqdYfSm64wZJMdGcLdKrUfPu6mV9YYBTs1+A8pQJEvBaGSzFcR9IwCslYIhGyw 8ayZM3BZkXuOKOqPi5XHIAmrlMz8ayRZ2qMWo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=JmjuXZSKYC4tMA4uWg00EAep6lQfLr+vopYSkfhsMEDC+zT3/1xeRXwb25fJfBghQy usXVZjjTIsJPp4pYsYSnUIFqxHQF84CbLp+SIchMwCG8Cs4P8Kd2fZnPn9hNIwoEUv0g XyRUSrLlkPPR5uP59DVnzOrdwZjSTVOI+qOeI= Received: by 10.141.15.11 with SMTP id s11mr5883077rvi.171.1249444301399; Tue, 04 Aug 2009 20:51:41 -0700 (PDT) Received: from 123.72.240.10.in-addr.arpa (m1b0436d0.tmodns.net [208.54.4.27]) by mx.google.com with ESMTPS id k41sm5760925rvb.7.2009.08.04.20.51.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 04 Aug 2009 20:51:40 -0700 (PDT) Sender: Terry Manderson Message-Id: <6FD10636-4FA0-4CD9-B08A-782EB94A37E0@terrym.net> From: Terry Manderson To: Geoff Huston In-Reply-To: <1FB6C249-6FEF-40C2-BC2E-A26E04A0F6D4@apnic.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 5 Aug 2009 13:51:36 +1000 References: <04CAD96D4C5A3D48B1919248A8FE0D5409E0EAAE@xmb-sjc-215.amer.cisco.com> <1FB6C249-6FEF-40C2-BC2E-A26E04A0F6D4@apnic.net> X-Mailer: Apple Mail (2.935.3) Cc: sidr@ietf.org Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 03:51:41 -0000 On 05/08/2009, at 11:31 AM, Geoff Huston wrote: > WG Chair hat OFF > > On 05/08/2009, at 11:04 AM, Stephen Kent wrote: > >> I still believe that the ability to make negative assertions seems >> like an important feature for incremental deployment of the RPKI. >> My proposal makes use of ROAs with an AS# of 0 to convey the notion >> that the specified prefixes are NOT to be routed. If you reject any >> advertisements for AS# 0 anyway, would that add any appreciable >> complexity to your code? > > I believe that the validation procedure described in the roa- > validation working group draft and the pseudo-code the pmohapat > draft are consistent in that they will mark a prefix described in an > AS0 ROA as "invalid" as long as there is no other valid ROA that > produces a "valid" outcome. i.e. with no additional "special case" > handling, an AS0 ROA would indeed generate the "invalid" outcome and > hence act as a "negative assertion" in the context of these > specifications. In essence I agree with Steve that making non-use attestations is an important feature. I guess that I diverge there and think of the AS0 ROA in 4 areas: 1) It overloads AS0 with more meaning than I would personally give it. 2) The AS0 ROA does not allow nor cover the idea that some people might want to restrict use of AS numbers as well 3) _If_ a valid ROA does exist for a valid prefix as well as a AS0 ROA, the decision tree is yet to be mooted. 4) Academically I look on the AS0 ROA as the 'ex falso quodlibet'. eg I am making a attestation of use, but in the same breath mandating non- use. (it, in itself, is defining a contradiction as the ROA is meant to assert route-ability, not the inverse) That said, I'm more than happy to assist in documenting the AS0 ROA as an alternative option as a 50% solution that might be more palatable than the idea of a defined RPKI object (eg BOA - that has the well known and unambiguous semantics) I think the validation structure that Geoff speaks of would work, provided there is ordering on the handling of a AS0 ROA. Does that add complexity? yes. As much as BOAs? is there collision avoidance? I don't yet know I haven't modelled it. Pradosh, penny for your thoughts? Cheers Terry From ljb@merit.edu Wed Aug 5 08:52:55 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2EEF3A6950 for ; Wed, 5 Aug 2009 08:52:54 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBdcSsBuxBjF for ; Wed, 5 Aug 2009 08:52:53 -0700 (PDT) Received: from thor.merit.edu (thor.merit.edu [198.108.1.14]) by core3.amsl.com (Postfix) with ESMTP id B3D443A69AD for ; Wed, 5 Aug 2009 08:52:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAENHeUrGbD6X/2dsb2JhbADFU4dgiE6EGAU X-IronPort-AV: E=Sophos;i="4.43,329,1246852800"; d="scan'208";a="11671280" Received: from ablate.merit.edu ([198.108.62.151]) by thor.merit.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Aug 2009 11:52:56 -0400 Message-ID: <4A79AAD8.9060000@merit.edu> Date: Wed, 05 Aug 2009 11:52:56 -0400 From: Larry Blunk User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Sriram, Kotikalapudi" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org" Subject: Re: [sidr] Soft Decision during Incremental Adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 15:52:55 -0000 Why would an EE Cert be issued for a sub-allocation if the holder is not prepared to create ROA's for it? Considerable experience with this scenario with IRR's suggest that the providers will simply create ROA's for the sub-allocation if the downstream customer is not SIDR aware (just as providers now create route objects for sub-allocations to customers who are not IRR aware). Could one simply condition the "Not Found"/"Invalid" decision based on the existence or non-existence of the EE Cert for the sub-allocation? If an EE Cert exists for for the sub-allocation, but there is no ROA, treat updates for the prefix as "Not Found". If there is no EE-Cert for the sub-allocation, treat updates for the prefix as "Invalid". -Larry Sriram, Kotikalapudi wrote: > The thread subject line was: "revision to draft-ietf-sidr-roa-validation" > Please allow me to use a new subject line as shown. > > I've read through the entire thread, and I am in agreement with Terry on > the need for soft decision during partial deployment and also about > the use of BOA to end the soft decision period for a prefix. > In Terry's words "... a BOA can then be issued which then 'locks down' > the prefix." > > I presented a slide at the Stockholm SIDR WG meeting to generate some > discussion on the need for soft decision during incremental adoption. I feel > that the outcome of the discussion was not exactly conclusive. Views were > expressed both ways - to consider suballocation (or more specific prefix) > "Invalid" or treat it softly as "ROA not found" (when there is no requisite > ROA for it). I think some more attention must be paid to details before a > conclusion is reached. I personally find it easier to describe stuff with > slides and diagrams rather than just in words. So I have prepared a set of > slides to highlight the details and propose two solution methods. > Link to the slides: > > http://www.antd.nist.gov/~ksriram/SIDR_ROA_BOA_Interpretation.pdf > > It will be much appreciated if you can review the material in the slides > and offer your comments. > (I must admit that Terry has already said in this thread > some of the material that I have explained in the slides, > but the slides try to put it all in perspective and > also the idea on slide 6 would perhaps be new to this discussion. > I am in favor of BOA per use case as illustrated in slide 5. > > Sriram > > > -----Original Message----- > >> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of >Terry Manderson >> Sent: Sunday, August 02, 2009 10:56 PM >> To: sidr@ietf.org >> Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation >> > > > >> On 3/08/09 12:14 PM, "George Michaelson" wrote: >> > > >>> As co-author of the draft-ietf-sidr-roa-validation I also observe that >>> the WG has no interest in pursuing a BOA based model (an explicit >>> denial structure) and that the revised draft therefore aligns with >>> people's expectations in documenting the validation process. >>> > > > >> It is truly a regrettable situation that the workgroup has been lulled into >> this position. A ROA that has an implicit deny creates a major break >> scenario since the RPKI system will be in partial deployment for many years, >> - the resulting requirement is that every LIR's customers MUST participate >> in RPKI else the issuance of the LIR's ROA will invalidate all customer >> announcements in the examples provided by Geoff. >> > > >> I cannot see then, how the RPKI will actually get deployment as it will sit >> in a 'too hard' basket. In effect, all ROAs have to be created in a bottom >> up mode, yet the resource certs issued top-down. >> > > >> The BOA provides two functions, to protect the un-used and unallocated >> resources from misuse and to allow a partial deployment mechanism in a make >> before break process where the LIR can adopt, and issue ROAs, and once all >> customers are on board - a BOA can then be issued which then 'locks down' >> the prefix. >> > > >> Terry >> > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From kotikalapudi.sriram@nist.gov Wed Aug 5 17:28:03 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D6833A6B33 for ; Wed, 5 Aug 2009 17:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.384 X-Spam-Level: X-Spam-Status: No, score=-6.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbooDFEieri9 for ; Wed, 5 Aug 2009 17:28:02 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 320E73A6A50 for ; Wed, 5 Aug 2009 17:28:01 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n760RaAH012736; Wed, 5 Aug 2009 20:27:37 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Wed, 5 Aug 2009 20:27:36 -0400 From: "Sriram, Kotikalapudi" To: Larry Blunk Date: Wed, 5 Aug 2009 20:27:35 -0400 Thread-Topic: [sidr] Soft Decision during Incremental Adoption Thread-Index: AcoV5N3EoG9Wj0cDRc+MR7HgL6CRVgARONtA Message-ID: References: <4A79AAD8.9060000@merit.edu> In-Reply-To: <4A79AAD8.9060000@merit.edu> 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 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Cc: "sidr@ietf.org" Subject: Re: [sidr] Soft Decision during Incremental Adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 00:28:03 -0000 Please see responses inline. Sriram -----Original Message----- From: Larry Blunk [mailto:ljb@merit.edu]=20 Sent: Wednesday, August 05, 2009 11:53 AM To: Sriram, Kotikalapudi Cc: Terry Manderson; sidr@ietf.org Subject: Re: [sidr] Soft Decision during Incremental Adoption Why would an EE Cert be issued for a sub-allocation if the holder is not prepared to create ROA's for it? Considerable experience with this scenario with IRR's suggest that the providers will simply create ROA's for the sub-allocation if the downstream customer is not SIDR aware (just as providers now create route objects for sub-allocations to customers who are not IRR aware). Response: KS: I heard from folks at Verizon and ARIN that the sub-allocations can run up to seven levels deep. Many of the children/grandchildren may be capable of creating their own ROAs but do not exactly=20 synchronize with the creation of a ROA by the top level parent. Considerable level of coordination may be involved here.=20 So it may be good to give them some grace period (with soft decision) before the parent creates a BOA and locks down the prefix. Could one simply condition the "Not Found"/"Invalid" decision based on the existence or non-existence of the EE Cert for the sub-allocation? If an EE Cert exists for for the sub-allocation, but there is no ROA, treat updates for the prefix as "Not Found". If there is no EE-Cert for the sub-allocation, treat updates for the prefix as "Invalid". Response: KS: I was also thinking about that possibility. I have not thought=20 through what the underlying issues may be with EE certs. I would like to see if others have comments about your idea. -Larry Sriram, Kotikalapudi wrote: > The thread subject line was: "revision to draft-ietf-sidr-roa-validation" > Please allow me to use a new subject line as shown. > > I've read through the entire thread, and I am in agreement with Terry on > the need for soft decision during partial deployment and also about > the use of BOA to end the soft decision period for a prefix.=20 > In Terry's words "... a BOA can then be issued which then 'locks down' > the prefix." > =20 > I presented a slide at the Stockholm SIDR WG meeting to generate some > discussion on the need for soft decision during incremental adoption. I f= eel > that the outcome of the discussion was not exactly conclusive. Views were > expressed both ways - to consider suballocation (or more specific prefix) > "Invalid" or treat it softly as "ROA not found" (when there is no requisi= te > ROA for it). I think some more attention must be paid to details before a > conclusion is reached. I personally find it easier to describe stuff with > slides and diagrams rather than just in words. So I have prepared a set o= f > slides to highlight the details and propose two solution methods.=20 > Link to the slides: > > http://www.antd.nist.gov/~ksriram/SIDR_ROA_BOA_Interpretation.pdf=20 > > It will be much appreciated if you can review the material in the slides= =20 > and offer your comments. > (I must admit that Terry has already said in this thread=20 > some of the material that I have explained in the slides, > but the slides try to put it all in perspective and=20 > also the idea on slide 6 would perhaps be new to this discussion.=20 > I am in favor of BOA per use case as illustrated in slide 5.=20 > > Sriram > From kent@bbn.com Wed Aug 5 18:35:08 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4154F3A6ABB for ; Wed, 5 Aug 2009 18:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUlopl4ZR+sw for ; Wed, 5 Aug 2009 18:35:07 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id C3DF43A6BBD for ; Wed, 5 Aug 2009 18:33:39 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[172.16.1.74]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MYqvL-0006y7-FF; Wed, 05 Aug 2009 20:33:40 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <6FD10636-4FA0-4CD9-B08A-782EB94A37E0@terrym.net> References: <04CAD96D4C5A3D48B1919248A8FE0D5409E0EAAE@xmb-sjc-215.amer.cisco.com> <1FB6C249-6FEF-40C2-BC2E-A26E04A0F6D4@apnic.net> <6FD10636-4FA0-4CD9-B08A-782EB94A37E0@terrym.net> Date: Wed, 5 Aug 2009 21:33:37 -0400 To: Terry Manderson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 01:35:08 -0000 Terry, - As the creator of ROas I don't share the view that using an AS # of 0 is overloading the semantics :-). - I agree that this proposal does not allow one to express a negative assertion about ASNs, but I also do not recall a strong cas being made for the need to do so. - a valid ROA ought mot exist for both an AS 0 and and non-0 AS. Only the holder of the prefix in question could generate such a conflict, and an equivalent conflict could arise w/o the AS 0 convention. - I advocate the AS 0 convention precisely because it seems to fit easily with straightforward implementations of ROA-provcessing code. The positive assertion of a ROA is not inverted by this convention, but rather the As # happens to be reserved and this connotes the right semantics. (I am sorry that my command ofLatin is not sufficient to try to generate an appropriate phrase to support this argument :-).) Steve From ggm@apnic.net Wed Aug 5 18:46:32 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84C13A6BCE for ; Wed, 5 Aug 2009 18:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.456 X-Spam-Level: * X-Spam-Status: No, score=1.456 tagged_above=-999 required=5 tests=[AWL=-0.647, BAYES_05=-1.11, RELAY_IS_203=0.994, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InYXK3X3bGgo for ; Wed, 5 Aug 2009 18:46:32 -0700 (PDT) Received: from asmtp.apnic.net (oregano.apnic.net [IPv6:2001:dc0:2001:a:4608::60]) by core3.amsl.com (Postfix) with ESMTP id DDAB63A6CEC for ; Wed, 5 Aug 2009 18:46:31 -0700 (PDT) Received: from dynamic160.apnic.net (dynamic160.apnic.net [203.119.42.160]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 27814110069 for ; Thu, 6 Aug 2009 11:46:32 +1000 (EST) Message-Id: <50DEC53B-4B4C-440E-A516-DF7AF16AF7BD@apnic.net> From: George Michaelson To: sidr@ietf.org In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: base64 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 6 Aug 2009 11:46:31 +1000 References: <04CAD96D4C5A3D48B1919248A8FE0D5409E0EAAE@xmb-sjc-215.amer.cisco.com> <1FB6C249-6FEF-40C2-BC2E-A26E04A0F6D4@apnic.net> <6FD10636-4FA0-4CD9-B08A-782EB94A37E0@terrym.net> X-Mailer: Apple Mail (2.936) Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 01:46:33 -0000 4byhzrTOrc+Jz4IgzrPhvbDPgSDhvIDOvc6tz4fOtc+DzrjOtSDPhOG/ts69IOG8gM+Gz4HPjM69 z4nOvSAgDQrPhs+Bz4zOvc65zrzOv865IOG9hM69z4TOtc+Cwrc= From gih@apnic.net Wed Aug 5 21:30:20 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 254093A6868 for ; Wed, 5 Aug 2009 21:30:20 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCICu6kiHbDM for ; Wed, 5 Aug 2009 21:30:19 -0700 (PDT) Received: from asmtp.apnic.net (oregano.apnic.net [IPv6:2001:dc0:2001:a:4608::60]) by core3.amsl.com (Postfix) with ESMTP id 05FF43A68E4 for ; Wed, 5 Aug 2009 21:30:19 -0700 (PDT) Received: from [IPv6:2001:dc0:2001:10:217:f2ff:feed:7e6d] (unknown [IPv6:2001:dc0:2001:10:217:f2ff:feed:7e6d]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id DCEE9110069; Thu, 6 Aug 2009 14:30:17 +1000 (EST) Message-Id: <359ADECD-606B-4E53-9AB0-0792A8458A41@apnic.net> From: Geoff Huston To: George Michaelson In-Reply-To: <50DEC53B-4B4C-440E-A516-DF7AF16AF7BD@apnic.net> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 6 Aug 2009 14:30:17 +1000 References: <04CAD96D4C5A3D48B1919248A8FE0D5409E0EAAE@xmb-sjc-215.amer.cisco.com> <1FB6C249-6FEF-40C2-BC2E-A26E04A0F6D4@apnic.net> <6FD10636-4FA0-4CD9-B08A-782EB94A37E0@terrym.net> <50DEC53B-4B4C-440E-A516-DF7AF16AF7BD@apnic.net> X-Mailer: Apple Mail (2.935.3) Cc: sidr@ietf.org Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 04:30:20 -0000 On 06/08/2009, at 11:46 AM, George Michaelson wrote: > =E1=BC=A1=CE=B4=CE=AD=CF=89=CF=82 =CE=B3=E1=BD=B0=CF=81 = =E1=BC=80=CE=BD=CE=AD=CF=87=CE=B5=CF=83=CE=B8=CE=B5 =CF=84=E1=BF=B6=CE=BD = =E1=BC=80=CF=86=CF=81=CF=8C=CE=BD=CF=89=CE=BD =20 > =CF=86=CF=81=CF=8C=CE=BD=CE=B9=CE=BC=CE=BF=CE=B9 =E1=BD=84=CE=BD=CF=84=CE= =B5=CF=82=C2=B7 Timeo danaos et dona ferentis ? From root@core3.amsl.com Wed Aug 5 23:15:01 2009 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4D9C83A6D10; Wed, 5 Aug 2009 23:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090806061501.4D9C83A6D10@core3.amsl.com> Date: Wed, 5 Aug 2009 23:15:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-roa-validation-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 06:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Validation of Route Origination in BGP using the Resource Certificate PKI and ROAs Author(s) : G. Huston, G. Michaelson Filename : draft-ietf-sidr-roa-validation-03.txt Pages : 11 Date : 2009-08-05 This document defines an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol. The proposed application is intended to fit within the requirement for adding security to inter-domain routing, including the ability to support incremental and piecemeal deployment, and does not require any changes to the specification of BGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-validation-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-roa-validation-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-05231226.I-D@ietf.org> --NextPart-- From dol@cryptocom.ru Thu Aug 6 05:57:55 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF34A3A6CB3 for ; Thu, 6 Aug 2009 05:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.907 X-Spam-Level: X-Spam-Status: No, score=-0.907 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFdq+dfcWeIa for ; Thu, 6 Aug 2009 05:57:55 -0700 (PDT) Received: from mx.cryptocom.ru (mx.cryptocom.ru [87.245.158.60]) by core3.amsl.com (Postfix) with ESMTP id D16113A6AEC for ; Thu, 6 Aug 2009 05:57:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx.cryptocom.ru (Postfix) with ESMTP id 58E9E3EC70; Thu, 6 Aug 2009 16:57:56 +0400 (MSD) X-Virus-Scanned: Debian amavisd-new at cryptocom.ru Received: from mx.cryptocom.ru ([127.0.0.1]) by localhost (mx.cryptocom.ru [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qPgoKnWlz4Kl; Thu, 6 Aug 2009 16:57:56 +0400 (MSD) Received: from [10.51.22.241] (reedcat.lan.cryptocom.ru [10.51.22.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id E85843EC6F; Thu, 6 Aug 2009 16:57:55 +0400 (MSD) Message-ID: <4A7AD353.9020206@cryptocom.ru> Date: Thu, 06 Aug 2009 16:57:55 +0400 From: Basil Dolmatov User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Rob Austein References: <04CAD96D4C5A3D48B1919248A8FE0D5409E0EAAE@xmb-sjc-215.amer.cisco.com> <20090803231527.96F9022805@thrintun.hactrn.net> In-Reply-To: <20090803231527.96F9022805@thrintun.hactrn.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: sidr@ietf.org Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 12:57:55 -0000 Rob Austein пишет: > At Mon, 3 Aug 2009 15:36:27 -0700, Terry Manderson wrote: >> Lets say we are half way through the the RPKI deployment for all LIRs that >> have address space in 10/8. Our trusty RIR based in Elbonia does a slight >> error and issues a ROA for 10/8 maxLenghth /8; AS65534 - clearly in error. >> The downside is that it automatically makes all routes not yet covered by a >> ROA be invalid. According to the current interpretation. >> >> Does that not concern you? > > It seems likely that your hypothetical Elbonian RIR would also manage > to screw up a combination of ROAs and BOAs. > May be it will be more interesting to return to the question "How transition period can be performed with "INVALID" paradigm implemented?" This is more important as I think than inventing of scenarios of screwing up something. Notice with which Terry has started (about long transition period when RPKI will start its deployment, if any) contains the crucial problem of the project. So, any schemes which are not allowing smooth coexistence of RPKI and non-RPKI parts of the world for a looong period of time simply will not fly. dol@ > From robert@ripe.net Thu Aug 6 14:26:57 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A565B3A6850 for ; Thu, 6 Aug 2009 14:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.429 X-Spam-Level: X-Spam-Status: No, score=-3.429 tagged_above=-999 required=5 tests=[AWL=-0.830, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WL2T1U-3rJ+c for ; Thu, 6 Aug 2009 14:26:57 -0700 (PDT) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id E81F53A687F for ; Thu, 6 Aug 2009 14:26:56 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MZAU7-0001ES-9b; Thu, 06 Aug 2009 23:26:56 +0200 Received: from Kistel-Mac.local (dog.ripe.net [193.0.1.217]) by herring.ripe.net (Postfix) with ESMTP id 05FE92F595; Thu, 6 Aug 2009 23:26:51 +0200 (CEST) Message-ID: <4A7B4A9A.5040303@ripe.net> Date: Thu, 06 Aug 2009 23:26:50 +0200 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Geoff Huston References: <04CAD96D4C5A3D48B1919248A8FE0D5409E0EAAE@xmb-sjc-215.amer.cisco.com> <1FB6C249-6FEF-40C2-BC2E-A26E04A0F6D4@apnic.net> <6FD10636-4FA0-4CD9-B08A-782EB94A37E0@terrym.net> <50DEC53B-4B4C-440E-A516-DF7AF16AF7BD@apnic.net> <359ADECD-606B-4E53-9AB0-0792A8458A41@apnic.net> In-Reply-To: <359ADECD-606B-4E53-9AB0-0792A8458A41@apnic.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274f7d7941b9a9ebecfa9fc4f0ea4b31bb1 Cc: sidr@ietf.org Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 21:26:57 -0000 Geoff Huston wrote: >=20 > On 06/08/2009, at 11:46 AM, George Michaelson wrote: >=20 >> =E1=BC=A1=CE=B4=CE=AD=CF=89=CF=82 =CE=B3=E1=BD=B0=CF=81 =E1=BC=80=CE=BD= =CE=AD=CF=87=CE=B5=CF=83=CE=B8=CE=B5 =CF=84=E1=BF=B6=CE=BD =E1=BC=80=CF=86= =CF=81=CF=8C=CE=BD=CF=89=CE=BD =CF=86=CF=81=CF=8C=CE=BD=CE=B9=CE=BC=CE=BF= =CE=B9 =E1=BD=84=CE=BD=CF=84=CE=B5=CF=82=C2=B7 >=20 > Timeo danaos et dona ferentis ? A l=C3=A9gp=C3=A1rn=C3=A1s haj=C3=B3m tele van angoln=C3=A1kkal! Robert PS: excuses, I couldn't resist From terry.manderson@icann.org Thu Aug 6 22:54:40 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E1E53A6B89 for ; Thu, 6 Aug 2009 22:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmZMDl7bRpHf for ; Thu, 6 Aug 2009 22:54:39 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id C1BBC3A6BE2 for ; Thu, 6 Aug 2009 22:53:42 -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; Thu, 6 Aug 2009 22:53:46 -0700 From: Terry Manderson To: Stephen Kent , Terry Manderson Date: Thu, 6 Aug 2009 22:53:42 -0700 Thread-Topic: [sidr] revision to draft-ietf-sidr-roa-validation Thread-Index: AcoWNjH2/4cyxZ1HTqWTZ76da1O22QA7TkLC Message-ID: In-Reply-To: Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 05:54:40 -0000 Hi Steve, On 6/08/09 11:33 AM, "Stephen Kent" wrote: > Terry, >=20 > - As the creator of ROas I don't share the view that using an > AS # of 0 is overloading the semantics :-). agree to disagree? :-) >=20 > - I agree that this proposal does not allow one to express a > negative assertion about ASNs, but I also do not recall a strong cas > being made for the need to do so. >=20 Assuming that the cidr-report (http://www.cidr-report.org) is accurate: http://www.cidr-report.org/as2.0/bogus-as-advertisements.html 197 unallocated (bogon) AS's making 1416 prefix announcements. I believe when we start talking seriously about path validation, this will become important. I see that as a strong case. > - a valid ROA ought mot exist for both an AS 0 and and non-0 > AS. Only the holder of the prefix in question could generate such a > conflict, and an equivalent conflict could arise w/o the AS 0 > convention. >=20 Provided the interpretation of a ROA is one that does not have an implicit deny.=20 What would be the interpretation of the following ROAs 10/8 maxlength 32 AS2222 10/16 maxlength 32 AS 0 ?=20 > - I advocate the AS 0 convention precisely because it seems > to fit easily with straightforward implementations of ROA-provcessing > code. The positive assertion of a ROA is not inverted by this > convention, but rather the > As # happens to be reserved and this connotes the right semantics. So in my readying of the ROA draft, it a ROA conveys the permission of a ASN to advertise the prefix. How can AS 0 advertise the prefix? (or am I being picky on wording?) > (I am sorry that my command ofLatin is not sufficient to try to > generate an appropriate phrase to support this argument :-).) Based on the thread of quotes that followed, I'll refrain from doing so in future. :-( Cheers, Terry From andy@arin.net Fri Aug 7 05:42:12 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5B813A6E60 for ; Fri, 7 Aug 2009 05:42:12 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7IS1zNjgakC for ; Fri, 7 Aug 2009 05:42:12 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by core3.amsl.com (Postfix) with ESMTP id ED9393A6B09 for ; Fri, 7 Aug 2009 05:42:11 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id EA490165285; Fri, 7 Aug 2009 08:42:14 -0400 (EDT) Received: from ex.arin.net (ex.arin.net [192.136.136.237]) by smtp1.arin.net (Postfix) with ESMTP id A2CD416527F; Fri, 7 Aug 2009 08:42:14 -0400 (EDT) Received: from EDAMAME.arin.net ([192.136.136.194]) by ex.arin.net ([192.136.136.237]) with mapi; Fri, 7 Aug 2009 08:42:14 -0400 From: Andy Newton To: Terry Manderson , Stephen Kent Date: Fri, 7 Aug 2009 08:42:12 -0400 Thread-Topic: [sidr] revision to draft-ietf-sidr-roa-validation Thread-Index: AcoWNjH2/4cyxZ1HTqWTZ76da1O22QA7TkLCAA5ER1Q= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.081218 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] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 12:42:12 -0000 On 8/7/09 1:53 AM, "Terry Manderson" wrote: > Hi Steve, >=20 >=20 > On 6/08/09 11:33 AM, "Stephen Kent" wrote: >=20 >> Terry, >>=20 >> - As the creator of ROas I don't share the view that using an >> AS # of 0 is overloading the semantics :-). >=20 > agree to disagree? :-) I'm inclined to agree with Terry on this, as it falls into the same categor= y as using HTML comments to define scripts -- yeah it works, but the results are messy. Separation of concerns is a best practice in computer systems. There is a point of clarity as well. While this seems understandable to those creating the specs, it might lead to head scratching five years from now to people who must learn the system. It is like the maintenance programmer who has to come back around to the original developer and ask, "Why did you do this?" -andy From ljb@merit.edu Fri Aug 7 07:07:21 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC3D73A6D04 for ; Fri, 7 Aug 2009 07:07:21 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4XyNgBo9tSM for ; Fri, 7 Aug 2009 07:07:21 -0700 (PDT) Received: from thor.merit.edu (thor.merit.edu [198.108.1.14]) by core3.amsl.com (Postfix) with ESMTP id 0A3D93A6928 for ; Fri, 7 Aug 2009 07:07:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKbRe0rGbD6X/2dsb2JhbADADochiE6EFgU X-IronPort-AV: E=Sophos;i="4.43,341,1246852800"; d="scan'208";a="11788967" Received: from ablate.merit.edu ([198.108.62.151]) by thor.merit.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Aug 2009 10:07:24 -0400 Message-ID: <4A7C351C.3060101@merit.edu> Date: Fri, 07 Aug 2009 10:07:24 -0400 From: Larry Blunk User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Sriram, Kotikalapudi" References: <4A79AAD8.9060000@merit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org" Subject: Re: [sidr] Soft Decision during Incremental Adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 14:07:21 -0000 Sriram, Kotikalapudi wrote: > Please see responses inline. > Sriram > > -----Original Message----- > From: Larry Blunk [mailto:ljb@merit.edu] > Sent: Wednesday, August 05, 2009 11:53 AM > To: Sriram, Kotikalapudi > Cc: Terry Manderson; sidr@ietf.org > Subject: Re: [sidr] Soft Decision during Incremental Adoption > > Why would an EE Cert be issued for a sub-allocation > if the holder is not prepared to create ROA's for it? > Considerable experience with this scenario with IRR's suggest > that the providers will simply create ROA's for the sub-allocation > if the downstream customer is not SIDR aware (just as providers now > create route objects for sub-allocations to customers who are > not IRR aware). > > Response: > KS: I heard from folks at Verizon and ARIN that the sub-allocations > can run up to seven levels deep. Many of the children/grandchildren > may be capable of creating their own ROAs but do not exactly > synchronize with the creation of a ROA by the top level parent. > Considerable level of coordination may be involved here. > So it may be good to give them some grace period (with soft decision) > before the parent creates a BOA and locks down the prefix. > > But we are only concerned with sub-allocations which also involve Autonomous System boundaries. (see sidr-arch section 7.2.1) This is a considerably smaller subset and does not go nearly as deep. Speaking from our experience as a provider, we generally frown on customers who wish to announce a sub-allocation from our space to multi-home and prefer they get their own PI space. We've made a few exceptions, but they are rare. I can't imagine a situation where we'd permit this to go 2 levels deep (allowing a sub-allocation of a sub-allocation to be announced from yet another AS). I don't see us issuing CA Cert's to customers given the limited number of cases involved. We'd simply issue ROA's on their behalf (see option 2 of 7.2.2 in sidr-arch). -Larry From robert@ripe.net Fri Aug 7 07:32:20 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FB043A6976 for ; Fri, 7 Aug 2009 07:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.222 X-Spam-Level: X-Spam-Status: No, score=-3.222 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cuNOrdLfEid for ; Fri, 7 Aug 2009 07:32:19 -0700 (PDT) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id 44DC43A6C29 for ; Fri, 7 Aug 2009 07:32:19 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MZQUP-0000r4-Jg; Fri, 07 Aug 2009 16:32:18 +0200 Received: from Kistel-Mac.local (cat.ripe.net [193.0.1.249]) by herring.ripe.net (Postfix) with ESMTP id 8FFEE2F595; Fri, 7 Aug 2009 16:32:13 +0200 (CEST) Message-ID: <4A7C3AED.1080005@ripe.net> Date: Fri, 07 Aug 2009 16:32:13 +0200 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Larry Blunk References: <4A79AAD8.9060000@merit.edu> <4A7C351C.3060101@merit.edu> In-Reply-To: <4A7C351C.3060101@merit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a27461e08fef1e523dfb9327c1fd1cc7e859 Cc: "sidr@ietf.org" Subject: Re: [sidr] Soft Decision during Incremental Adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 14:32:20 -0000 Larry Blunk wrote: > But we are only concerned with sub-allocations which > also involve Autonomous System boundaries. (see sidr-arch > section 7.2.1) This is a considerably smaller subset and does > not go nearly as deep. Speaking from our experience as a > provider, we generally frown on customers who wish to > announce a sub-allocation from our space to multi-home and prefer they > get their own PI space. We've made a few exceptions, but > they are rare. I can't imagine a situation where we'd permit > this to go 2 levels deep (allowing a sub-allocation of a sub-allocation > to be announced from yet another AS). I don't see us issuing > CA Cert's to customers given the limited number of cases involved. > We'd simply issue ROA's on their behalf (see option 2 of 7.2.2 in > sidr-arch). > > > -Larry > Larry, AFAIK more than one level deep sub-allocations are a fact of life. "a few exceptions", as you put it, is a good enough argument to think about this. In an allocation chain of IR->ISP1->ISP2->EndUser the IR or ISP1 does not necessarily know about sub-allocations, therefore cannot anticipate what the EndUser will do with them. It'd be really sad if an act (like issuing a covering ROA) from IR or ISP1 in this case would effectively kill EndUser's _other_ announcements. I don't believe we should allow this in a partial RPPKI deployment. Because of this I tend do disagree with RobA's comment: > No, the LIR just has to issue ROAs for any of its customers that are > unwilling or unable to generate their own. The LIR has to know what > resources each of its children has and which of its children are > RPKI-capable in any case, the rest is a small matter of programming. The LIR may now about its children, but does not always to know if its *grandchildren* are RPKI capable or not. As a grandchild, you'd be completely at the mercy of your grandparent, which sounds scary. I believe this issue cannot be solved with "a small matter of programming". Robert From ljb@merit.edu Fri Aug 7 08:21:18 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE7063A6B18 for ; Fri, 7 Aug 2009 08:21: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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBidCHXBpMQo for ; Fri, 7 Aug 2009 08:21:17 -0700 (PDT) Received: from thor.merit.edu (thor.merit.edu [198.108.1.14]) by core3.amsl.com (Postfix) with ESMTP id B12633A6946 for ; Fri, 7 Aug 2009 08:21:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADvje0rGbD6X/2dsb2JhbADAPocjiE6EFgWBTA X-IronPort-AV: E=Sophos;i="4.43,342,1246852800"; d="scan'208";a="11793285" Received: from ablate.merit.edu ([198.108.62.151]) by thor.merit.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Aug 2009 11:21:21 -0400 Message-ID: <4A7C4670.1080603@merit.edu> Date: Fri, 07 Aug 2009 11:21:20 -0400 From: Larry Blunk User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Robert Kisteleki References: <4A79AAD8.9060000@merit.edu> <4A7C351C.3060101@merit.edu> <4A7C3AED.1080005@ripe.net> In-Reply-To: <4A7C3AED.1080005@ripe.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org" Subject: Re: [sidr] Soft Decision during Incremental Adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 15:21:18 -0000 Robert Kisteleki wrote: > Larry Blunk wrote: >> But we are only concerned with sub-allocations which >> also involve Autonomous System boundaries. (see sidr-arch >> section 7.2.1) This is a considerably smaller subset and does >> not go nearly as deep. Speaking from our experience as a >> provider, we generally frown on customers who wish to >> announce a sub-allocation from our space to multi-home and prefer they >> get their own PI space. We've made a few exceptions, but >> they are rare. I can't imagine a situation where we'd permit >> this to go 2 levels deep (allowing a sub-allocation of a sub-allocation >> to be announced from yet another AS). I don't see us issuing >> CA Cert's to customers given the limited number of cases involved. >> We'd simply issue ROA's on their behalf (see option 2 of 7.2.2 in >> sidr-arch). >> >> >> -Larry >> > > Larry, > > AFAIK more than one level deep sub-allocations are a fact of life. "a > few exceptions", as you put it, is a good enough argument to think > about this. In an allocation chain of IR->ISP1->ISP2->EndUser the IR > or ISP1 does not necessarily know about sub-allocations, therefore > cannot anticipate what the EndUser will do with them. It'd be really > sad if an act (like issuing a covering ROA) from IR or ISP1 in this > case would effectively kill EndUser's _other_ announcements. I don't > believe we should allow this in a partial RPPKI deployment. Again, this is not simply about sub-allocations, but rather the smaller case of sub-allocations involving autonomous system boundaries. The allocation chain above is not relevant to SIDR if there is no change in autonomous system. If EndUser decides to get an AS and wants to punch a hole in the ISP1 aggregate announcement in order to multi-home, that is something that ISP1 would very much need to anticipate and be involved with. The case of ISP2 getting an AS and using it to multi-home an ISP1 sub-allocation is not too un-common (larger ISP1's have set aside blocks of space for just such cases). I'm arguing that it is considerably rarer for EndUser to announce space out of ISP1's sub-allocation to ISP2. It shouldn't be too difficult to do some analysis of BGP tables to look for such cases. Perhaps someone has done it already. > > Because of this I tend do disagree with RobA's comment: > >> No, the LIR just has to issue ROAs for any of its customers that are >> unwilling or unable to generate their own. The LIR has to know what >> resources each of its children has and which of its children are >> RPKI-capable in any case, the rest is a small matter of programming. > > The LIR may now about its children, but does not always to know if its > *grandchildren* are RPKI capable or not. As a grandchild, you'd be > completely at the mercy of your grandparent, which sounds scary. I > believe this issue cannot be solved with "a small matter of programming". Not scary at all. As a grandparent, I very much want to be involved when my grandchild starts messing around with BGP and wants to announce space out of my allocation. ISP's have a very different perspective from RIR's when making an allocation. RIR's don't involve themselves in the routing of the sub-allocations, ISP's do. -Larry From ttauber@m106.maoz.com Fri Aug 7 11:15:26 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 453703A6E7F for ; Fri, 7 Aug 2009 11:15:26 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhpfVdb4-b6A for ; Fri, 7 Aug 2009 11:15:25 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 6BE533A6A70 for ; Fri, 7 Aug 2009 11:15:25 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-6) with ESMTP id n77IFSBE020050; Fri, 7 Aug 2009 11:15:28 -0700 Received: (from ttauber@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n77IFSaP020049; Fri, 7 Aug 2009 11:15:28 -0700 Date: Fri, 7 Aug 2009 11:15:28 -0700 From: Tony Tauber To: Larry Blunk Message-ID: <20090807181528.GJ3403@1-4-5.net> References: <4A79AAD8.9060000@merit.edu> <4A7C351C.3060101@merit.edu> <4A7C3AED.1080005@ripe.net> <4A7C4670.1080603@merit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A7C4670.1080603@merit.edu> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "sidr@ietf.org" Subject: Re: [sidr] Soft Decision during Incremental Adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 18:15:26 -0000 On Fri, Aug 07, 2009 at 11:21:20AM -0400, Larry Blunk wrote: > Robert Kisteleki wrote: >> >> The LIR may now about its children, but does not always to know if >> its *grandchildren* are RPKI capable or not. As a grandchild, you'd >> be completely at the mercy of your grandparent, which sounds scary. >> I believe this issue cannot be solved with "a small matter of >> programming". > > Not scary at all. As a grandparent, I very much want to > be involved when my grandchild starts messing around with BGP and > wants to announce space out of my allocation. ISP's have a very > different perspective from RIR's when making an allocation. RIR's > don't involve themselves in the routing of the sub-allocations, > ISP's do. > > -Larry Speaking from my ISP experience, I agree with Larry's sentiments here. Tony From randy@psg.com Fri Aug 7 20:43:04 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3590B3A69A8 for ; Fri, 7 Aug 2009 20:43:04 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zTlCrjEOQfO for ; Fri, 7 Aug 2009 20:43:03 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 539243A6B05 for ; Fri, 7 Aug 2009 20:43:03 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MZcpj-000G7X-5V; Sat, 08 Aug 2009 03:43:03 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id A34D229257E4; Sat, 8 Aug 2009 12:43:02 +0900 (JST) Date: Sat, 08 Aug 2009 12:43:02 +0900 Message-ID: From: Randy Bush To: "Pradosh Mohapatra (pmohapat)" In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5409E0EAAE@xmb-sjc-215.amer.cisco.com> References: <04CAD96D4C5A3D48B1919248A8FE0D5409E0EAAE@xmb-sjc-215.amer.cisco.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2009 03:43:04 -0000 >> - the resulting requirement is that every LIR's customers MUST >> participate in RPKI else the issuance of the LIR's ROA will >> invalidate all customer announcements in the examples provided by >> Geoff. > The customers do not have to participate in the RPKI. The LIR can > issue the ROA on their behalf, no? they do pay us. it'll be a simple part of provisioning. "will you be generating the roa(s) for your announcements, or do you expect us to?" randy From randy@psg.com Fri Aug 7 20:47:09 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E656D3A6C66 for ; Fri, 7 Aug 2009 20:47:09 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4Y5Fbe4GDWp for ; Fri, 7 Aug 2009 20:47:09 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 2C00F3A6C7C for ; Fri, 7 Aug 2009 20:47:09 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MZctj-000G8D-9L; Sat, 08 Aug 2009 03:47:11 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id CA4652925856; Sat, 8 Aug 2009 12:47:10 +0900 (JST) Date: Sat, 08 Aug 2009 12:47:10 +0900 Message-ID: From: Randy Bush To: Terry Manderson In-Reply-To: References: <20090803212527.0FDF022805@thrintun.hactrn.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Rob Austein , "sidr@ietf.org" Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2009 03:47:10 -0000 >> No, the LIR just has to issue ROAs for any of its customers that are > Not "just has to", "MUST issue". big deal. and we must connect wires to them. the list of musts to provision a customer is rather large. this one will go with the ones having to do with accepting their bgp announcement in the first place, bgp session, filters, and all that. let us not inflate the trivial. randy From randy@psg.com Fri Aug 7 20:47:48 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8497E3A6CC9 for ; Fri, 7 Aug 2009 20:47:48 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2Pn1um2tRNO for ; Fri, 7 Aug 2009 20:47:47 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id B343D3A6AEB for ; Fri, 7 Aug 2009 20:47:47 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MZcuL-000G8X-96; Sat, 08 Aug 2009 03:47:49 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id CC38A2925869; Sat, 8 Aug 2009 12:47:48 +0900 (JST) Date: Sat, 08 Aug 2009 12:47:48 +0900 Message-ID: From: Randy Bush To: Stephen Kent In-Reply-To: References: <20090803212527.0FDF022805@thrintun.hactrn.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Rob Austein , sidr@ietf.org Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2009 03:47:48 -0000 > Does the LIR (ISP) need to know if any of his (RPKI_incapable) > customers are multi-homed and, if so, to whom they are connected, in > order to generate ROAs for those paths? no. roas do not have paths. randy From terry.manderson@icann.org Sun Aug 9 23:15:16 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AD573A6A5B for ; Sun, 9 Aug 2009 23:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0XzY2LhO2gn for ; Sun, 9 Aug 2009 23:15:12 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 7D3BD3A67E9 for ; Sun, 9 Aug 2009 23:15:12 -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; Sun, 9 Aug 2009 23:15:16 -0700 From: Terry Manderson To: Randy Bush Date: Sun, 9 Aug 2009 23:15:12 -0700 Thread-Topic: [sidr] revision to draft-ietf-sidr-roa-validation Thread-Index: AcoX3SXTjmlSWFaLSK66jDd4jUWgJABpMVRA Message-ID: In-Reply-To: Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Rob Austein , "sidr@ietf.org" Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 06:15:16 -0000 On 8/08/09 1:47 PM, "Randy Bush" wrote: >>> No, the LIR just has to issue ROAs for any of its customers that are >> Not "just has to", "MUST issue". >=20 > big deal. and we must connect wires to them. the list of musts to > provision a customer is rather large. this one will go with the ones > having to do with accepting their bgp announcement in the first place, > bgp session, filters, and all that. >=20 Ahh I think I see some disjoint here. If this was a clean skin and RPKI was already deployed, I would agree this would be in the set of processes. But it isn't, and the LIR/ISP has to go do this dance with all their customers before they can issue their own ROA. I just don't see that helpin= g deployment at all. Terry From randy@psg.com Sun Aug 9 23:17:52 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 241D93A6D85 for ; Sun, 9 Aug 2009 23:17:52 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENNpl9TiG730 for ; Sun, 9 Aug 2009 23:17:51 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 38DCB3A6D99 for ; Sun, 9 Aug 2009 23:17:51 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaOCd-000Mez-Uf; Mon, 10 Aug 2009 06:17:52 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 6C8392930B46; Mon, 10 Aug 2009 15:17:51 +0900 (JST) Date: Mon, 10 Aug 2009 15:17:51 +0900 Message-ID: From: Randy Bush To: Terry Manderson In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Rob Austein , "sidr@ietf.org" Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 06:17:52 -0000 >>>> No, the LIR just has to issue ROAs for any of its customers that are >>> Not "just has to", "MUST issue". >> big deal. and we must connect wires to them. the list of musts to >> provision a customer is rather large. this one will go with the ones >> having to do with accepting their bgp announcement in the first place, >> bgp session, filters, and all that. > Ahh I think I see some disjoint here. If this was a clean skin and RPKI was > already deployed, I would agree this would be in the set of processes. > But it isn't, and the LIR/ISP has to go do this dance with all their > customers before they can issue their own ROA. I just don't see that helping > deployment at all. and this is difficult why? hint: the operators here seem to see little problem. do we not have enough problems without inventing them? randy From terry.manderson@icann.org Sun Aug 9 23:42:01 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 380173A6A32 for ; Sun, 9 Aug 2009 23:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.445 X-Spam-Level: X-Spam-Status: No, score=-6.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxbuLEbnPOOq for ; Sun, 9 Aug 2009 23:42:00 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 7C6523A68FD for ; Sun, 9 Aug 2009 23:42:00 -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; Sun, 9 Aug 2009 23:42:04 -0700 From: Terry Manderson To: Randy Bush Date: Sun, 9 Aug 2009 23:42:01 -0700 Thread-Topic: [sidr] revision to draft-ietf-sidr-roa-validation Thread-Index: AcoZgljYyAeQGqcMQ6K478k9oji/twAA1FVR Message-ID: In-Reply-To: Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Rob Austein , "sidr@ietf.org" Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 06:42:01 -0000 On 10/08/09 4:17 PM, "Randy Bush" wrote: >=20 > and this is difficult why? Not saying its difficult. Saying its a block to deployment for a LIR who ha= s customers that originate the assigned prefix from a separate AS. But maybe that is what operators want.. always easier to put things in a 'too hard' basket. Always easier to lock those customers in. >=20 > hint: the operators here seem to see little problem. do we not have > enough problems without inventing them? >=20 What is "here"? this list? where you work? I don't see this an inventing problems. I think it is realizing that the mooted interpretation is going to go badly for some in anything but a complete deployment. I would prefer that we, as a working group, aren't putting forward something that is going to cause pain. I think there are enough hairy monsters surrounding this work already. I'm currently putting together an analysis of this from the DFZ as to impact. I'll post again in a few days. T. From randy@psg.com Mon Aug 10 00:08:11 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 594FE3A6AB0 for ; Mon, 10 Aug 2009 00:08:11 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYhKZW3KpZSi for ; Mon, 10 Aug 2009 00:08:10 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 7F9423A6D50 for ; Mon, 10 Aug 2009 00:08:10 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaOzJ-000MmL-Um; Mon, 10 Aug 2009 07:08:10 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 714122931CE9; Mon, 10 Aug 2009 16:08:09 +0900 (JST) Date: Mon, 10 Aug 2009 16:08:09 +0900 Message-ID: From: Randy Bush To: Terry Manderson In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Rob Austein , "sidr@ietf.org" Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 07:08:11 -0000 >> and this is difficult why? > Not saying its difficult. Saying its a block to deployment for a LIR who has > customers that originate the assigned prefix from a separate AS. > But maybe that is what operators want.. always easier to put things in a > 'too hard' basket. Always easier to lock those customers in. we do not need the accusations, black helicopters, evil .*s, ... thanks for maintaining a polite discussion. the customer is using a sub-alloc from me. i have to provision the circuit, build bgp sessions, ... and exactly how is helping the lazy ones to field a roa further locking them in? > I don't see this an inventing problems. I think it is realizing that the > mooted interpretation is going to go badly for some in anything but a > complete deployment. except this point is far from being made. > I would prefer that we, as a working group, aren't putting forward > something that is going to cause pain. I think there are enough hairy > monsters surrounding this work already. agree wholeheartedly. > I'm currently putting together an analysis of this from the DFZ as to > impact. I'll post again in a few days. [ side note. i suggest abandoning the term dfz. maybe we start saying bgp speaking zone or something. see my iepg preso. ] From terry.manderson@icann.org Mon Aug 10 01:32:44 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 893DA28C0D0 for ; Mon, 10 Aug 2009 01:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.456 X-Spam-Level: X-Spam-Status: No, score=-6.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QD0pmOxRNPzG for ; Mon, 10 Aug 2009 01:32:43 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id B166C3A6D39 for ; Mon, 10 Aug 2009 01:32:43 -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, 10 Aug 2009 01:32:47 -0700 From: Terry Manderson To: Randy Bush Date: Mon, 10 Aug 2009 01:32:43 -0700 Thread-Topic: [sidr] revision to draft-ietf-sidr-roa-validation Thread-Index: AcoZiWEQ8kHFnby7TOGabgoEoRNFEgAC8AMx Message-ID: In-Reply-To: Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Rob Austein , "sidr@ietf.org" Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 08:32:44 -0000 On 10/08/09 5:08 PM, "Randy Bush" wrote: >>> and this is difficult why? >> Not saying its difficult. Saying its a block to deployment for a LIR who= has >> customers that originate the assigned prefix from a separate AS. >> But maybe that is what operators want.. always easier to put things in a >> 'too hard' basket. Always easier to lock those customers in. >=20 > we do not need the accusations, black helicopters, evil > .*s, ... thanks for maintaining a polite discussion. It wasn't meant as a sideward accusation. I've seen this "business practice= " done by many (gosh just look at v6, DNSSEC, etc). While I don't believe its the IETF position to discuss a business case for anything, having seen the effects where excuses are made to not adopt something based on effort level - I have a genuine concern that allowing excuses like we have to get our customers to do it first, or we have to do it for our customers (wow that does sound like v6 ;), will -as already stated- be a hindrance. But hey, I'll take the WG lead - seems to be a split so far, some want a implicit deny, some want an explicit deny. Perhaps we need to think about it in terms of flexibility and utility? >=20 > the customer is using a sub-alloc from me. i have to provision the > circuit, build bgp sessions, ... and exactly how is helping the lazy > ones to field a roa further locking them in? I suspect you might be more helpful than others. It is the case where a LIR doesn't provision a ROA for the lazy. effectively making their aggregate th= e only path to them. A learning exercise for the customer? no doubt. One that has ramifications beyond trying to implement a form of routing security.. >=20 >> I don't see this an inventing problems. I think it is realizing that the >> mooted interpretation is going to go badly for some in anything but a >> complete deployment. >=20 > except this point is far from being made. I think it is getting there.. >=20 >> I would prefer that we, as a working group, aren't putting forward >> something that is going to cause pain. I think there are enough hairy >> monsters surrounding this work already. >=20 > agree wholeheartedly. >=20 Terry From christopher.morrow@gmail.com Mon Aug 10 07:12:13 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 168263A6BCA for ; Mon, 10 Aug 2009 07:12:13 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1yD7cjMec6k for ; Mon, 10 Aug 2009 07:12:12 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 312743A68A2 for ; Mon, 10 Aug 2009 07:12:12 -0700 (PDT) Received: by qyk41 with SMTP id 41so2863427qyk.29 for ; Mon, 10 Aug 2009 07:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=8tKCcqAK5Mj5PRD8XhWIwOdZRUy6hm1brlOKdzFvifU=; b=C0XmW6ViDNu0yDFczQhb/oiRMirPth7fPBPzEAyAfWcqXnQmxp9dzkLN9A/eFeKtMz VRijAoqMEpFWJurrTNcHXEAeX3of0ax5j4MIbSfYI3ylF2f/Mx0L5sBHNAemsLQIiY6j XOYNZ6uhOtaMyR7lVqF66TCMBxlK1qLO9Qx2k= 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=b3NDaGo9z5ARF7LG4mdxrZ5VjmhBbu27DsxDzRzSdLFwvCzokKI/sJQEnaxTu/utH9 bsky8bpzbZBjGXdxrghS3FzOh6xezxkLspBZ8zXAqwC7kaO8DxXFqF3vLL4V2ToYXZun GHLGix28SnVXA52rvuPp6gvYyFPLTzX11I+Ls= MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.224.67.207 with SMTP id s15mr3123807qai.128.1249913529925; Mon, 10 Aug 2009 07:12:09 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 Aug 2009 10:12:09 -0400 X-Google-Sender-Auth: ad933141e58e5520 Message-ID: <75cb24520908100712y6c74fb5ajdd333a3d2480fd1@mail.gmail.com> From: Christopher Morrow To: Terry Manderson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rob Austein , "sidr@ietf.org" Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 14:12:13 -0000 On Mon, Aug 10, 2009 at 2:42 AM, Terry Manderson wrote: > > > > On 10/08/09 4:17 PM, "Randy Bush" wrote: > >> >> and this is difficult why? > > Not saying its difficult. Saying its a block to deployment for a LIR who = has > customers that originate the assigned prefix from a separate AS. > But maybe that is what operators want.. always easier to put things in a > 'too hard' basket. Always easier to lock those customers in. > >> >> hint: the operators here seem to see little problem. =A0do we not have >> enough problems without inventing them? >> > > What is "here"? this list? where you work? > > I don't see this an inventing problems. I think it is realizing that the > mooted interpretation is going to go badly for some in anything but a > complete deployment. I would prefer that we, as a working group, aren't > putting forward something that is going to cause pain. I think there are > enough hairy monsters surrounding this work already. Does this mean there ought to be a deployment doc written as well? I think that in general the 'eww crypto stuff' card will get pulled out (a bunch) but if this is relatively painless to setup and maintain (getting a cert from an RIR shouldn't be too rough in 2009, adding to your OSS the bits that sign down an assignment to a customer may be but shouldn't be hard) a lot of the excuses go away. -Chris > I'm currently putting together an analysis of this from the DFZ as to > impact. I'll post again in a few days. > > T. > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From sandy@tislabs.com Mon Aug 10 12:15:56 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA6E03A67D0 for ; Mon, 10 Aug 2009 12:15: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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vO2gjgH22+Kh for ; Mon, 10 Aug 2009 12:15:56 -0700 (PDT) Received: from nutshell.tislabs.com (nutshell.tislabs.com [192.94.214.100]) by core3.amsl.com (Postfix) with ESMTP id 1E5B43A6899 for ; Mon, 10 Aug 2009 12:15:56 -0700 (PDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id n7AJEDHC012571; Mon, 10 Aug 2009 15:14:13 -0400 (EDT) Received: from nodnsquery(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAw9aqJy; Mon, 10 Aug 09 15:14:12 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 2FEAC3F47E; Mon, 10 Aug 2009 15:10:04 -0400 (EDT) To: pmohapat@cisco.com, randy@psg.com In-Reply-To: Message-Id: <20090810191004.2FEAC3F47E@pecan.tislabs.com> Date: Mon, 10 Aug 2009 15:10:04 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) Cc: sidr@ietf.org Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 19:15:57 -0000 On Sat, 08 Aug 2009 12:43:02 +0900, Randy Bush said: >they do pay us. it'll be a simple part of provisioning. "will you be >generating the roa(s) for your announcements, or do you expect us to?" I can see how this will work during the provisioning process. Can you say how it will work during initical deployment in an ISP who has many customers? Go through the list of all customers, asking this question? Go through the list of all mulit-homed customers, asking this question? Do you have a record of those who are multi-homed or would you generate one from RV data? Etc. --Sandy From sandy@tislabs.com Mon Aug 10 14:19:56 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EE453A6A86 for ; Mon, 10 Aug 2009 14:19: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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W67h-zS77WXZ for ; Mon, 10 Aug 2009 14:19:55 -0700 (PDT) Received: from nutshell.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by core3.amsl.com (Postfix) with ESMTP id A96663A6A72 for ; Mon, 10 Aug 2009 14:19:55 -0700 (PDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id n7ALHD7t012701; Mon, 10 Aug 2009 17:17:13 -0400 (EDT) Received: from nodnsquery(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAp3aGZy; Mon, 10 Aug 09 17:17:13 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id B82FF3F43E; Mon, 10 Aug 2009 17:13:04 -0400 (EDT) To: sidr@ietf.org, sra@isc.org, terry.manderson@icann.org In-Reply-To: Message-Id: <20090810211304.B82FF3F43E@pecan.tislabs.com> Date: Mon, 10 Aug 2009 17:13:04 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) Cc: sandy@tislabs.com Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 21:19:56 -0000 On Mon, 3 Aug 2009 14:50:47 -0700, Terry Manderson said: >> No, the LIR just has to issue ROAs for any of its customers that are >Not "just has to", "MUST issue". Terry, could you be specific about what an ISP with a clueless customer would need to do (generate certs, sign ROAs, etc.) in the explicit deny case? Your message of Date: Sun, 2 Aug 2009 19:56:08 -0700 says: >The BOA provides two functions, to protect the un-used and unallocated >resources from misuse and to allow a partial deployment mechanism in a make >before break process where the LIR can adopt, and issue ROAs, and once all >customers are on board - a BOA can then be issued which then 'locks down' >the prefix. which leaves me not understanding what happens before all the customers are on board. --Sandy From sandy@tislabs.com Mon Aug 10 14:36:45 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 200B03A6F3C for ; Mon, 10 Aug 2009 14:36: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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XV8SSbGA8zsx for ; Mon, 10 Aug 2009 14:36:44 -0700 (PDT) Received: from nutshell.tislabs.com (ns1.tislabs.com [192.94.214.100]) by core3.amsl.com (Postfix) with ESMTP id 1BA073A6F36 for ; Mon, 10 Aug 2009 14:36:43 -0700 (PDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id n7ALXxse012713; Mon, 10 Aug 2009 17:33:59 -0400 (EDT) Received: from nodnsquery(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAMwaa1y; Mon, 10 Aug 09 17:33:59 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 41A8B3F47E; Mon, 10 Aug 2009 17:29:50 -0400 (EDT) To: andy@arin.net, kent@bbn.com, terry.manderson@icann.org In-Reply-To: Message-Id: <20090810212950.41A8B3F47E@pecan.tislabs.com> Date: Mon, 10 Aug 2009 17:29:50 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) Cc: sidr@ietf.org Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 21:36:45 -0000 On Fri, 7 Aug 2009 08:42:12 -0400, Andy Newton said: >On 8/7/09 1:53 AM, "Terry Manderson" wrote: > >> Hi Steve, >> >> >> On 6/08/09 11:33 AM, "Stephen Kent" wrote: >> >>> Terry, >>> >>> - As the creator of ROas I don't share the view that using an >>> AS # of 0 is overloading the semantics :-). >> >> agree to disagree? :-) > >I'm inclined to agree with Terry on this, as it falls into the same category >as using HTML comments to define scripts -- yeah it works, but the results >are messy. Separation of concerns is a best practice in computer systems. >There is a point of clarity as well. While this seems understandable to >those creating the specs, it might lead to head scratching five years from >now to people who must learn the system. It is like the maintenance >programmer who has to come back around to the original developer and ask, >"Why did you do this?" A comment on this line of argument (rather than a comment on explicit vs implicit deny or ROA 0 vs BOA): Some IETF routing protocols do use distinguished values for certain fields to convey a particular unique semantics or desired behavior. Consider OSPF and MAXAGE and LSInfinity. Consider RIP and the value 16 representing "infinity". Consider GSTM and the use of 255 for the TTL. --Sandy From kotikalapudi.sriram@NIST.GOV Mon Aug 10 16:04:40 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BD293A6D69 for ; Mon, 10 Aug 2009 16:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.456 X-Spam-Level: X-Spam-Status: No, score=-6.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTOYckddComb for ; Mon, 10 Aug 2009 16:04:38 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 82BE428C1D7 for ; Mon, 10 Aug 2009 16:03:42 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n7AN35LM027199; Mon, 10 Aug 2009 19:03:05 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Mon, 10 Aug 2009 19:02:53 -0400 From: "Sriram, Kotikalapudi" To: Randy Bush , Stephen Kent Date: Mon, 10 Aug 2009 19:02:52 -0400 Thread-Topic: [sidr] revision to draft-ietf-sidr-roa-validation Thread-Index: AcoX2w7AMfXyJ1V4RKSZrbp1wEzlgACK3nTQ Message-ID: References: <20090803212527.0FDF022805@thrintun.hactrn.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 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Cc: Rob Austein , "sidr@ietf.org" Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 23:04:40 -0000 I think this might help clarify what Steve's concern is, which I think several others here also share. Consider the subnet 198.32.176.0/24 and=20 take a look at their connectivity graph: =20 http://www.robtex.com/route/198.32.176.0-24.html >From this graph, four different ASes seem to originate=20 this prefix in BGP. The subnet seems directly multi-homed to four ASes. Now in the link below, search for 198.32.176.0 and then you will see that a route record exists with AS4637 but in BGP there are six ASes (including the four from above graph) which originate this prefix (note AS4637 in NOT one of them): http://www.robtex.com/as/as4637.html#bgp (I think that is meaning of the data, please correct me if I am wrong.) One of the ASes that originates this prefix is AS701 (UUNET). If you look at this url below, the Org name for this prefix=20 is EP.NET but AS701 (UUNET) is listed as associated AS.=20 http://cqcounter.com/whois/ Perhaps Randy (or others interested) can walk us through=20 what happens with RPKI and ROA registrations in this scenario? I am trying to understand how scenarios like this will be handled. Sriram =20 > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Randy Bush > Sent: Friday, August 07, 2009 11:48 PM > To: Stephen Kent > Cc: Rob Austein; sidr@ietf.org > Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation >=20 > > Does the LIR (ISP) need to know if any of his (RPKI_incapable) > > customers are multi-homed and, if so, to whom they are connected, in > > order to generate ROAs for those paths? >=20 > no. roas do not have paths. >=20 > randy From pmohapat@cisco.com Mon Aug 10 16:27:45 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A87E03A6AC3 for ; Mon, 10 Aug 2009 16:27: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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIgMIUcMl0Y7 for ; Mon, 10 Aug 2009 16:27:44 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 9F6BB3A6F21 for ; Mon, 10 Aug 2009 16:27:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOBJgEqrR7MV/2dsb2JhbAC5DYgrjx4FhBg X-IronPort-AV: E=Sophos;i="4.43,356,1246838400"; d="scan'208";a="89331008" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 10 Aug 2009 23:27:48 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7ANRmwP031219; Mon, 10 Aug 2009 16:27:48 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n7ANRmZC003543; Mon, 10 Aug 2009 23:27:48 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 16:27:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Aug 2009 16:27:46 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5409EAF732@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sidr] revision to draft-ietf-sidr-roa-validation Thread-Index: AcoX2w7AMfXyJ1V4RKSZrbp1wEzlgACK3nTQAAKcLaA= References: <20090803212527.0FDF022805@thrintun.hactrn.net> From: "Pradosh Mohapatra (pmohapat)" To: "Sriram, Kotikalapudi" , "Randy Bush" , "Stephen Kent" X-OriginalArrivalTime: 10 Aug 2009 23:27:48.0196 (UTC) FILETIME=[2BE9DA40:01CA1A12] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1380; t=1249946868; x=1250810868; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pmohapat@cisco.com; z=From:=20=22Pradosh=20Mohapatra=20(pmohapat)=22=20 |Subject:=20RE=3A=20[sidr]=20revision=20to=20draft-ietf-sid r-roa-validation |Sender:=20; bh=28vZnhShxkWgV5ZsgAWfkMWsM0jBMypSY/M4cxLOoCI=; b=IaaCbhJufIItU6U1r+3VrZo52FpK4Zt4SXHR9uMdJb+9m+BNyufCKMRb3O D5GEO2eTFS8ctmaIT/AuqzGD5oRtN0xvansA6TpX8n9YcwUrZAPb3cvqJ0RN MjPSok6Q9zESqAnaKKlM2V+hIKVmkm16FAc9WAX3u6sGvp/6JBoCM=; Authentication-Results: sj-dkim-1; header.From=pmohapat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Rob Austein , sidr@ietf.org Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 23:27:45 -0000 | I think this might help clarify what Steve's concern is, | which I think several others here also share. | Consider the subnet 198.32.176.0/24 and | take a look at their connectivity graph: | http://www.robtex.com/route/198.32.176.0-24.html | From this graph, four different ASes seem to originate | this prefix in BGP. The subnet seems directly multi-homed | to four ASes. |=20 | Now in the link below, search for 198.32.176.0 and then you | will see that a route record exists with AS4637 but | in BGP there are six ASes (including the four from above graph) | which originate this prefix (note AS4637 in NOT one of them): | http://www.robtex.com/as/as4637.html#bgp | (I think that is meaning of the data, please correct me if I | am wrong.) |=20 | One of the ASes that originates this prefix is AS701 (UUNET). | If you look at this url below, the Org name for this prefix | is EP.NET but AS701 (UUNET) is listed as associated AS. | http://cqcounter.com/whois/ |=20 | Perhaps Randy (or others interested) can walk us through | what happens with RPKI and ROA registrations in this scenario? | I am trying to understand how scenarios like this will be handled. There can be multiple valid ASes that can originate the same address prefix. It just means that multiple ROAs have to be issued. So I must be missing the problem definition. - Pradosh From pmohapat@cisco.com Mon Aug 10 16:58:04 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAFE03A6EAE for ; Mon, 10 Aug 2009 16:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMqMvZCI6Uc9 for ; Mon, 10 Aug 2009 16:58:03 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C20E13A6E60 for ; Mon, 10 Aug 2009 16:58:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAG9QgEqrR7PE/2dsb2JhbAC5A4grjyEFhBg X-IronPort-AV: E=Sophos;i="4.43,356,1246838400"; d="scan'208";a="226068345" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 10 Aug 2009 23:58:07 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7ANw7ba026105; Mon, 10 Aug 2009 16:58:07 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n7ANw7VI020553; Mon, 10 Aug 2009 23:58:07 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 16:58:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Aug 2009 16:58:05 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5409EAF755@xmb-sjc-215.amer.cisco.com> In-Reply-To: <6FD10636-4FA0-4CD9-B08A-782EB94A37E0@terrym.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sidr] revision to draft-ietf-sidr-roa-validation Thread-Index: AcoVgBUgyh9H7XiTTWauue62/GgJuwEk0upg References: <04CAD96D4C5A3D48B1919248A8FE0D5409E0EAAE@xmb-sjc-215.amer.cisco.com><1FB6C249-6FEF-40C2-BC2E-A26E04A0F6D4@apnic.net> <6FD10636-4FA0-4CD9-B08A-782EB94A37E0@terrym.net> From: "Pradosh Mohapatra (pmohapat)" To: "Terry Manderson" , "Geoff Huston" X-OriginalArrivalTime: 10 Aug 2009 23:58:07.0584 (UTC) FILETIME=[685A6E00:01CA1A16] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1996; t=1249948687; x=1250812687; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pmohapat@cisco.com; z=From:=20=22Pradosh=20Mohapatra=20(pmohapat)=22=20 |Subject:=20RE=3A=20[sidr]=20revision=20to=20draft-ietf-sid r-roa-validation |Sender:=20; bh=yIygrhzRXwIj7DRyHnL1+7mJNZc0PfTRd0AVSOdARzw=; b=oeS9rMsuhdZVfetnJdu/GowF+sTckWpDKkSME3bLhShBgRemf80t0v2QoH d44j3IWP9DTLJr4HWp0XE1W8Ue8k17q57L+PdkcdO6+PVo3W2jscKtcHi1pU cwCZEoko0H; Authentication-Results: sj-dkim-4; header.From=pmohapat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sidr@ietf.org Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 23:58:04 -0000 | In essence I agree with Steve that making non-use attestations is an | important feature. I guess that I diverge there and think of the AS0 | ROA in 4 areas: |=20 | 1) It overloads AS0 with more meaning than I would personally give it. | 2) The AS0 ROA does not allow nor cover the idea that some people | might want to restrict use of AS numbers as well | 3) _If_ a valid ROA does exist for a valid prefix as well as a AS0 | ROA, the decision tree is yet to be mooted. | 4) Academically I look on the AS0 ROA as the 'ex falso quodlibet'. eg | I am making a attestation of use, but in the same breath mandating non- | use. (it, in itself, is defining a contradiction as the ROA is meant | to assert route-ability, not the inverse) If you think of AS#0 as "just another" AS and perform the validation logic in the usual way, it should fall into place and most of the above pitfalls should not arise. i.e. it's not a negative attestation or a contradiction: AS#0 is the valid owner of the prefix and no one else. So if the prefix is advertised by another AS, the AS#s will not match and the result will come out to be INVALID. Your point #3 above also falls into place easily -- there are more than one ASes that originate the prefix -- that's a valid case. I am concerned, however, about the ambiguity with AS#0 -- correlating multiple address ranges that are completely exclusive by putting them under the bucket of AS#0 (I guess that's what you meant by point#1 above?). If it can be some other AS in the allocation chain going all the way to the root, that could be a better alternative. But I understand that not all the entities in the chain have ASes. BTW, is the following a correct summary of the origin validation issues that have been brought up? 1) Handling sub-allocation and more specifics, 2) Taking care of allocated, but unused (so non-routable) addresses to entities that do not have an ASN, 3) Non-allocated prefix ranges - Pradosh From kotikalapudi.sriram@nist.gov Mon Aug 10 17:00:14 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20A523A6910 for ; Mon, 10 Aug 2009 17:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13n7nFFk0Rq3 for ; Mon, 10 Aug 2009 17:00:13 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id A5B503A6957 for ; Mon, 10 Aug 2009 17:00:12 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n7ANxhdQ002508; Mon, 10 Aug 2009 19:59:44 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Mon, 10 Aug 2009 19:59:43 -0400 From: "Sriram, Kotikalapudi" To: "Pradosh Mohapatra (pmohapat)" Date: Mon, 10 Aug 2009 19:59:43 -0400 Thread-Topic: [sidr] revision to draft-ietf-sidr-roa-validation Thread-Index: AcoX2w7AMfXyJ1V4RKSZrbp1wEzlgACK3nTQAAKcLaAAAHcf4A== Message-ID: References: <20090803212527.0FDF022805@thrintun.hactrn.net> <04CAD96D4C5A3D48B1919248A8FE0D5409EAF732@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5409EAF732@xmb-sjc-215.amer.cisco.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 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Cc: "sidr@ietf.org" Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 00:00:14 -0000 Pradosh: The context was this email from Steve Kent (copied below) and Randy's response (which I copied in my previous email). In the scenario we are looking at, the multiple ASes=20 with whom the prefix seems multi-homed belong to different ISPs (uunet, NTT, eu network AG, etc.). =20 Sriram=20 -----Original Message----- From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Ste= phen Kent Sent: Tuesday, August 04, 2009 10:30 AM To: Rob Austein Cc: sidr@ietf.org Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation At 5:25 PM -0400 8/3/09, Rob Austein wrote: >... > >No, the LIR just has to issue ROAs for any of its customers that are >unwilling or unable to generate their own. The LIR has to know what >resources each of its children has and which of its children are >RPKI-capable in any case, the rest is a small matter of programming. Does the LIR (ISP) need to know if any of his (RPKI_incapable)=20 customers are multi-homed and, if so, to whom they are connected, in=20 order to generate ROAs for those paths? Steve > -----Original Message----- > From: Pradosh Mohapatra (pmohapat) [mailto:pmohapat@cisco.com] > Sent: Monday, August 10, 2009 7:28 PM > To: Sriram, Kotikalapudi; Randy Bush; Stephen Kent > Cc: Rob Austein; sidr@ietf.org > Subject: RE: [sidr] revision to draft-ietf-sidr-roa-validation >=20 > | I think this might help clarify what Steve's concern is, > | which I think several others here also share. > | Consider the subnet 198.32.176.0/24 and > | take a look at their connectivity graph: > | http://www.robtex.com/route/198.32.176.0-24.html > | From this graph, four different ASes seem to originate > | this prefix in BGP. The subnet seems directly multi-homed > | to four ASes. > | > | Now in the link below, search for 198.32.176.0 and then you > | will see that a route record exists with AS4637 but > | in BGP there are six ASes (including the four from above graph) > | which originate this prefix (note AS4637 in NOT one of them): > | http://www.robtex.com/as/as4637.html#bgp > | (I think that is meaning of the data, please correct me if I > | am wrong.) > | > | One of the ASes that originates this prefix is AS701 (UUNET). > | If you look at this url below, the Org name for this prefix > | is EP.NET but AS701 (UUNET) is listed as associated AS. > | http://cqcounter.com/whois/ > | > | Perhaps Randy (or others interested) can walk us through > | what happens with RPKI and ROA registrations in this scenario? > | I am trying to understand how scenarios like this will be handled. >=20 > There can be multiple valid ASes that can originate the same address > prefix. It just means that multiple ROAs have to be issued. So I must be > missing the problem definition. >=20 > - Pradosh From randy@psg.com Mon Aug 10 18:29:18 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EED93A6D94 for ; Mon, 10 Aug 2009 18:29: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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mp+lCeUP4udZ for ; Mon, 10 Aug 2009 18:29:17 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id A3B2E3A6F14 for ; Mon, 10 Aug 2009 18:28:58 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MagAe-000MjW-0i; Tue, 11 Aug 2009 01:29:00 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 8B5EF29347D1; Tue, 11 Aug 2009 10:28:59 +0900 (JST) Date: Tue, 11 Aug 2009 10:28:59 +0900 Message-ID: From: Randy Bush To: sandy@tislabs.com (Sandy Murphy) In-Reply-To: <20090810191004.2FEAC3F47E@pecan.tislabs.com> References: <20090810191004.2FEAC3F47E@pecan.tislabs.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 01:29:18 -0000 > Can you say how it will work during initical deployment in an ISP > who has many customers? Go through the list of all customers, asking > this question? Go through the list of all mulit-homed customers, > asking this question? Do you have a record of those who are multi-homed > or would you generate one from RV data? i know of no one who would use the external irr to traverse their bgp speaking customer list. which means there probably are some. :) perhaps two or three keep serious enough data in internal irr instances, e.g. ntt, level(3). but even then, i doubt those are their 'data of record.' depending on their scale and level of automation, folk track their delegated customers by various means from text files, to some commercial and open source products, to custom apps with sql databases. but they do track them. have to for ip management reasons and to explain space utilization to upstream allocator(s). sure, there will be a few slobs and mistakes. we call that operations. but the rpki roll-out will shake messes out of the system from iana on down. hell, right now, arin and ripe are signing 0/0. randy From randy@psg.com Mon Aug 10 18:32:09 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC4D3A6D38 for ; Mon, 10 Aug 2009 18:32:09 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ryu+jW8Pktqe for ; Mon, 10 Aug 2009 18:32:08 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id BF5B23A6B47 for ; Mon, 10 Aug 2009 18:32:08 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MagDh-000Mk8-RP; Tue, 11 Aug 2009 01:32:10 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 610302934822; Tue, 11 Aug 2009 10:32:09 +0900 (JST) Date: Tue, 11 Aug 2009 10:32:09 +0900 Message-ID: From: Randy Bush To: "Sriram, Kotikalapudi" In-Reply-To: References: <20090803212527.0FDF022805@thrintun.hactrn.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Rob Austein , "sidr@ietf.org" Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 01:32:09 -0000 > I think this might help clarify what Steve's concern is, which I think > several others here also share. Consider the subnet 198.32.176.0/24 > and take a look at their connectivity graph: > http://www.robtex.com/route/198.32.176.0-24.html >From this graph, > four different ASes seem to originate this prefix in BGP. The subnet > seems directly multi-homed to four ASes. > > Now in the link below, search for 198.32.176.0 and then you will see > that a route record exists with AS4637 but in BGP there are six ASes > (including the four from above graph) which originate this prefix > (note AS4637 in NOT one of them): > http://www.robtex.com/as/as4637.html#bgp (I think that is meaning of > the data, please correct me if I am wrong.) > > One of the ASes that originates this prefix is AS701 (UUNET). If you > look at this url below, the Org name for this prefix is EP.NET but > AS701 (UUNET) is listed as associated AS. http://cqcounter.com/whois/ > > Perhaps Randy (or others interested) can walk us through what happens > with RPKI and ROA registrations in this scenario? I am trying to > understand how scenarios like this will be handled. we already had this discussion once, originated by danny. that's an exchange point. in this case, an IX with poorly managed address alloc data because it is manning's. randy From bmanning@karoshi.com Mon Aug 10 21:36:19 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B75F23A6D95 for ; Mon, 10 Aug 2009 21:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.757 X-Spam-Level: X-Spam-Status: No, score=-5.757 tagged_above=-999 required=5 tests=[AWL=0.842, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyPkSafDAqyS for ; Mon, 10 Aug 2009 21:36:18 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id AA2BF3A6D36 for ; Mon, 10 Aug 2009 21:36:18 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n7B4aFsU004183; Tue, 11 Aug 2009 04:36:17 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n7B4aAIY004182; Tue, 11 Aug 2009 04:36:10 GMT Date: Tue, 11 Aug 2009 04:36:10 +0000 From: bmanning@vacation.karoshi.com To: Randy Bush Message-ID: <20090811043610.GB1914@vacation.karoshi.com.> References: <20090803212527.0FDF022805@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: Rob Austein , "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 04:36:19 -0000 On Tue, Aug 11, 2009 at 10:32:09AM +0900, Randy Bush wrote: > > I think this might help clarify what Steve's concern is, which I think > > several others here also share. Consider the subnet 198.32.176.0/24 > > and take a look at their connectivity graph: > > http://www.robtex.com/route/198.32.176.0-24.html >From this graph, > > four different ASes seem to originate this prefix in BGP. The subnet > > seems directly multi-homed to four ASes. > > > > Now in the link below, search for 198.32.176.0 and then you will see > > that a route record exists with AS4637 but in BGP there are six ASes > > (including the four from above graph) which originate this prefix > > (note AS4637 in NOT one of them): > > http://www.robtex.com/as/as4637.html#bgp (I think that is meaning of > > the data, please correct me if I am wrong.) > > > > One of the ASes that originates this prefix is AS701 (UUNET). If you > > look at this url below, the Org name for this prefix is EP.NET but > > AS701 (UUNET) is listed as associated AS. http://cqcounter.com/whois/ > > > > Perhaps Randy (or others interested) can walk us through what happens > > with RPKI and ROA registrations in this scenario? I am trying to > > understand how scenarios like this will be handled. > > we already had this discussion once, originated by danny. that's an > exchange point. in this case, an IX with poorly managed address alloc > data because it is manning's. > > randy well - the poorly managed bit might be correct - upkeep has degenerated over time as the PAIX facility was sold and resold... but expect things there to clear up quite a bit in the next few months. S&D has taken a renewed interest getting the cruft corrected. regarding the above concern that the same prefix is announced by multiple parties... http://www.ep.net/policy.html might be instructive. if folks think this is "poorly managed" ... they are entitled to their opinions. If you would like Randy to step in here, i'd be pleased to hear the offer. current planning is to get the RPKI registrations in place with ARIN for all EP.NET blocks within the month - and assign certs to any ASN that connects. presuming the good folks designing this stuff have allowed for that operational model... if not, then I'm sure something else will emerge. --bill From randy@psg.com Mon Aug 10 22:27:56 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D2D93A68C9 for ; Mon, 10 Aug 2009 22:27:56 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emoI2tFtX4Jq for ; Mon, 10 Aug 2009 22:27:40 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id D8F1E3A67E2 for ; Mon, 10 Aug 2009 22:27:40 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MajsR-000NIb-9A; Tue, 11 Aug 2009 05:26:27 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id C12502935A1C; Tue, 11 Aug 2009 14:26:26 +0900 (JST) Date: Tue, 11 Aug 2009 14:26:26 +0900 Message-ID: From: Randy Bush To: bmanning@vacation.karoshi.com In-Reply-To: <20090811043610.GB1914@vacation.karoshi.com.> References: <20090803212527.0FDF022805@thrintun.hactrn.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Rob Austein , "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 05:27:56 -0000 > if folks think this is "poorly managed" ... they are entitled to their > opinions. If you would like Randy to step in here, i'd be pleased to > hear the offer. i do not take on tasks i do not have the time to do well. ep.net reverse delegations have been problematic for years for ixen all over the bleeping planet. randy From randy@psg.com Tue Aug 11 08:10:12 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 344423A6BC8 for ; Tue, 11 Aug 2009 08:10:12 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7B4Z7z0l1QY1 for ; Tue, 11 Aug 2009 08:10:11 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 0B4A23A67E5 for ; Tue, 11 Aug 2009 08:10:11 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaszL-000NTx-CH; Tue, 11 Aug 2009 15:10:11 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 3E9452939513; Wed, 12 Aug 2009 00:10:11 +0900 (JST) Date: Wed, 12 Aug 2009 00:10:11 +0900 Message-ID: From: Randy Bush To: sandy@tislabs.com (Sandy Murphy) In-Reply-To: <20090811143335.055773F463@pecan.tislabs.com> References: <20090811143335.055773F463@pecan.tislabs.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 15:10:12 -0000 > (b) I was trying to suggest how an ISP might come up with a list of > all those customers who need a ROA generated for them. if it is not already known to us, and it darned well should be, we could just look at the bgp announcement from the delegated downstream. the hole is the asn with some of our space who is not announcing it downstream of us. but these are special relationships, usually being kind to emigres, and are tracked. of course, if they have wandered off with a chunk of our address space without our consent, then tough patooties, eh? this is all just normal day to day ops. we have to earn our keep somehow. if the ops thought this stuff would make an ops mess, we would be screaming. as it is, non-ops are saying we have an ops problem. well, this is one of the rare instances in the ietf where the ops actually got in early. and we don't need representation. > Only those customers who are multi-homed need a ROA close. those announcing from a different asn. > You missed the base question: do you envision an ISP on initial > deployment asking a long list of customers if they want a ROA signed > for them? more like tell them that they can get certs and roas by using our web interface, run certware, or whatever. go to http://whatever/ and read all about it and follow one of thr recipies. and also tell them not to worry, if they don't want to do it right off, we'll do it for them. we are paid to make their packets move. believe it or not, we do have operational relationships with customers. strange as i guess it seems to much of this crowd, we are in business, and business is about customers and service. we don't just suck their blood and shoot them from black helicopters. we only do that on odd numbered days. randy From root@core3.amsl.com Tue Aug 11 20:45:01 2009 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 375183A680F; Tue, 11 Aug 2009 20:45:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090812034501.375183A680F@core3.amsl.com> Date: Tue, 11 Aug 2009 20:45:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-rescerts-provisioning-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 03:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Protocol for Provisioning Resource Certificates Author(s) : G. Huston, et al. Filename : draft-ietf-sidr-rescerts-provisioning-05.txt Pages : 28 Date : 2009-08-11 This document defines a framework for certificate management interactions between a resource issuer ("Internet Registry" or "IR") and a resource recipient ("Internet Service Provider" or "ISP") through the specification of a protocol for interaction between the two parties. The protocol supports the transmission of requests from the ISP, and corresponding responses from the IR 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-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-rescerts-provisioning-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-11204224.I-D@ietf.org> --NextPart-- From Sandra.Murphy@cobham.com Sun Aug 23 12:30:27 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBCB13A6CC1 for ; Sun, 23 Aug 2009 12:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.657 X-Spam-Level: X-Spam-Status: No, score=0.657 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IUvBd+69mvx for ; Sun, 23 Aug 2009 12:30:26 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id C04743A672E for ; Sun, 23 Aug 2009 12:30:26 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n7NJUV7s028410; Sun, 23 Aug 2009 14:30:31 -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 n7NJUVeE014546; Sun, 23 Aug 2009 14:30:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA2428.2CC4C8A4" Date: Sun, 23 Aug 2009 15:28:51 -0400 Message-ID: <5ABE30CE099A524CBF95C715D37BCACC3D0103@nemo.columbia.ads.sparta.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sidr] Request for WG adoption Thread-Index: AcokJ/HmnYHlZ9X0TGyxop57FtKHPQ== References: <31E95EEC-0668-450F-8DBA-46503BDEE70A@apnic.net> From: "Murphy, Sandra" To: Cc: Sandy Murphy Subject: Re: [sidr] Request for WG adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2009 19:30:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA2428.2CC4C8A4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 The responses to this request have all been positive and include at = least one author from every effected draft (all those that would have to = change to point to the new draft). I judge this to be consensus in the = working group that the draft should be adopted as a working group draft. =20 --Sandy =20 ________________________________ From: Murphy, Sandra Sent: Fri 7/31/2009 9:30 AM To: sidr@ietf.org Cc: Sandy Murphy Subject: [sidr] Request for WG adoption I am opening a two week call for comments on this request for working group adoption of draft-huston-sidr-rpki-algs-00.txt. The draft is available at http://www.ietf.org/id/draft-huston-sidr-rpki-algs-00.txt. As usual, the rules are that silence does not indicate assent, so please actively reply. If you support adoption of this draft as a working group item, please = also indicate whether you will be able to work on the draft (contribute or review). The call for adoption will end Friday, Aug 14, 2009. This is a call for adoption only, so comments on the contents are not necessary or needed. --Sandy On Fri, 31 Jul 2009, Geoff Huston wrote: > Hi Sandy, > > With my WG co-chair hat off I would like to request WG adoption of the = draft > draft-huston-sidr-rpki-algs-00.txt. > > I believe that this document addresses WG concerns regarding how to = specify > algorithms and key sizes in the RPKI profile in a manner that does not = over > burden the CP nor require a re-issue of the certificate profile = specification > as and when changes to the algorithms and key sizes are considered = prudent > for the RPKI, as discussed in the WG meeting this week. > > > thanks, > > Geoff > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr ------_=_NextPart_001_01CA2428.2CC4C8A4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [sidr] Request for WG adoption=0A= =0A= =0A= =0A=
=0A=
 
=0A=
The responses to this request have all been positive and = include at least one author from every effected draft (all those that = would have to change to point to the new draft).  I judge this to = be consensus in the working group that the draft should be adopted as a = working group draft.
=0A=
 
=0A=
--Sandy
=0A=

 
=0A=
=0A=
=0A=
=0A=
From: Murphy, = Sandra
Sent: Fri 7/31/2009 9:30 AM
To: = sidr@ietf.org
Cc: Sandy Murphy
Subject: [sidr] = Request for WG adoption

=0A=
=0A=

I am opening a two week call for comments on this = request for working
group adoption of = draft-huston-sidr-rpki-algs-00.txt.

The draft is available = at
http:/= /www.ietf.org/id/draft-huston-sidr-rpki-algs-00.txt.

As = usual, the rules are that silence does not indicate assent, so = please
actively reply.

If you support adoption of this draft = as a working group item, please also
indicate whether you will be = able to work on the draft (contribute or
review).

The call for = adoption will end Friday, Aug 14, 2009.

This is a call for = adoption only, so comments on the contents are not
necessary or = needed.

--Sandy

On Fri, 31 Jul 2009, Geoff Huston = wrote:

> Hi Sandy,
>
> With my WG co-chair hat off = I would like to request WG adoption of the draft
> = draft-huston-sidr-rpki-algs-00.txt.
>
> I believe that this = document addresses WG concerns regarding how to specify
> = algorithms and key sizes in the RPKI profile in a manner that does not = over
> burden the CP nor require a re-issue of the certificate = profile specification
> as and when changes to the algorithms and = key sizes are considered prudent
> for the RPKI, as discussed in = the WG meeting this week.
>
>
> = thanks,
>
>  Geoff
>
>
>
> = _______________________________________________
> sidr mailing = list
> sidr@ietf.org
> https://www.ietf.org/= mailman/listinfo/sidr

------_=_NextPart_001_01CA2428.2CC4C8A4-- From Sandra.Murphy@cobham.com Mon Aug 24 14:48:05 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90DFF3A6ED7 for ; Mon, 24 Aug 2009 14:48:05 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lm50VaX6x1CS for ; Mon, 24 Aug 2009 14:48:04 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id C8FF73A6D60 for ; Mon, 24 Aug 2009 14:48:04 -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 n7OLmAAL010126 for ; Mon, 24 Aug 2009 16:48:10 -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 n7OLmA4k009383 for ; Mon, 24 Aug 2009 16:48:10 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.121]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 17:48:10 -0400 Date: Mon, 24 Aug 2009 17:48:09 -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: 24 Aug 2009 21:48:10.0226 (UTC) FILETIME=[928C8520:01CA2504] Subject: [sidr] draft IETF 75 meeting minutes uploaded X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 21:48:05 -0000 The draft of the minutes (thanks, Roque) has been uploaded to the IETF75 meeting materials page at http://www.ietf.org/proceedings/75/minutes/sidr.txt. Please review these minutes and provide comments or corrections to the list. --Sandy From gih@apnic.net Mon Aug 24 20:36:58 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CB5B3A6837 for ; Mon, 24 Aug 2009 20:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.181 X-Spam-Level: X-Spam-Status: No, score=-1.181 tagged_above=-999 required=5 tests=[AWL=-1.252, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nwv8Fj5w63yv for ; Mon, 24 Aug 2009 20:36:56 -0700 (PDT) Received: from asmtp.apnic.net (oregano.apnic.net [IPv6:2001:dc0:2001:a:4608::60]) by core3.amsl.com (Postfix) with ESMTP id D1C083A68EA for ; Mon, 24 Aug 2009 20:36:54 -0700 (PDT) Received: from [218.189.94.92] (unknown [218.189.94.92]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 9A5B5110066; Tue, 25 Aug 2009 13:36:53 +1000 (EST) Message-Id: <0D3F2A5C-5900-4D11-A34D-AD2D6E732944@apnic.net> From: Geoff Huston To: Sandra Murphy In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 25 Aug 2009 13:36:48 +1000 References: X-Mailer: Apple Mail (2.936) Cc: sidr@ietf.org Subject: Re: [sidr] draft IETF 75 meeting minutes uploaded X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 03:36:58 -0000 On 25/08/2009, at 7:48 AM, Sandra Murphy wrote: > The draft of the minutes (thanks, Roque) has been uploaded to the > IETF75 meeting materials page at http://www.ietf.org/proceedings/75/minutes/sidr.txt > . > > Please review these minutes and provide comments or corrections to > the list. > Hi, The audo recordings of the meeting provide a good record of what was said, so it might make sense for the minutes to attempt to provide a summary of discussion and note actions and outcomes. So I've taken the liberty of reviewing Roque's notes and editing them a little - I hope this is useful thanks, Geoff ----------------- IETF75 SIDR WG Thursday, July 30, 2009 0900-1130 Chairs: Sandy Murphy, Geoff Huston Minutes: Roque Gagliano. Actions: WG consideration of a document that specifies algorithm and key sizes for all RPKI components Revise the CP to include text that limited the applicability of the RPKI such that validly signed objects would need to be specified in an IETF Standards track document. The RPKI CP should stay within the IETF process, as a BCP. The WG Chairs will consult the AD for guidance on the topic of the WG charter and the program of future activity for this WG. Notes: 1. Updated Drafts 1.1 ROA Format A Profile for Route Origin Authorizations (ROAs) draft-ietf-sidr-roa-format-05.txt presenter: Matt Lepinski On the issue of algorithm agility, it was note that algorithm and key length specifications have been included in all RPKI documents up until now. This version of the ROA profile draft has replaced this with a reference to the CP document as an initial suggestion as to how to centralise all the references to a single specification document. The CP has been nominated as the appropriate document to carry the RPKI algorithm and key length specification, but this is a matter for discussion by the WG. The other option is a separate WG document which carries only this common algorithm and key length specification, as is proposed by Geoff Huston. Discussion: Russ Housley noted that many WG have make this mistake. The issue here is that in order to subsequently change algorithms, there is a need to update all the documents. In this case, if you use the CP, you need to update the complete CP. This has delayed other work in the Security Area in the past. Russ recommends the WG adopting a dedicated document that described algorithms, and this document is to be referenced in the other documents. Sandy Murphy commented that Roque Gagliano realized that one of the problem is that you can get inconsistencies between documents. Rob Austein commented that on problem with putting the algorithm profile in the CP was that it was a lengthy and detailed document was was eye-glazing for a reader, and Rob was unsure that implementers will read it. Rob noted that he had no problem with a single document to specify a common algorithm profile for the RPKI, but it should not be the CP. Roque Gagliano noted that the CP is intended to be maintained by different organizations revisions to the CP in the case of a technical requirement for algorithm change, and the organizational review process of the CP may be inappropriate for such a task. Roque concurs on having a dedicated document for this specification. Sandy Murphy, as Chair, thanked Roque for noticing the problem with the key length in different documents. 1.2 RPKI Architecture An Infrastructure to Support Secure Internet Routing draft-ietf-sidr-arch-07.txt presenter: Matt Lepinski The change to this document was that the Certificate's Subject Name has been specificed as not intended to be meaningful across the entire RPKI, and the exception noted RIR and other entities have been removed from the draft. Subject Names are not intended to convey meaningful information and must be unique. The WG was requested to review the most recent draft of this document. Discussion: Sam Weiler asked in IANA was to remain a special case in this respect. Matt indicated that this was not the case. 1.3 Certificate Policy Certificate Policy (CP) for the Resource PKI (RPKI) draft-ietf-sidr-cp-06.txt Presenter: Stephen Kent Steve Kent noted that Andrei Robachevski, as a representative for the RIRs, gave the document's editors substantial feedback arising from an RIR staff review. The changes applied as a result of these comments are noted in the presentation. The revision has removed CP approval procedures to be made by the organizations administering the CP, although it was noted that this may need further review, as the also CP relates to ISPs and other organizations who undertake a CA role in the context of the RPKI. Discussion: Randy Bush inquired as to the current recommendations regarding management of the CP document, and it was noted that the current draft of the CP called on the RIRs and IANA to manage the process of updates to the CP. Steve Kent noted that there was a confident expectation that the algorithm and key size may change over time, and if this specification was to be placed into the CP, then the process regarding changes to the CP would need to take this into account. Steve noted that he agreed with Geoff and Russ about having a different document for algorithm and key profile for the RPKI to address this. Russ Housley spoke to question of the CP update process and which party was placed in the role of approval of changes to the CP. Russ noted that topics that are local RIR and ISP policies have impact beyond the CP, and would normally be left to the CPS. Russ was in favour of a position where the RPKI CP should stay within the IETF process, as a BCP, and other parties, including the RIRs and ISPS, would maintain their CPS documents regaring local policies. Randy Bush raised the question of the scope of the RPKI in terms of the validity of arbitrary documents signed using signatures that are validated within the RPKI. Steve Kent noted that one response to this concern was the possible inclusion of text in the CP that limited the applicability of the RPKI such that validly signed objects would need to be specified in an IETF Standards track document. 1.4 RPSL with RPKI Signatures Securing RPSL Objects with RPKI Signatures draft-ietf-sidr-rpsl-sig-01.txt Presenter: Robert Kisteleki It was noted that the document had been revised with minor changes, including text on URL safeness, modifications to the procedure to be used for text normalization modified, additional text on number resource coverage, and the general caveat that the certificate that signs an RPSL object must have some verifiable relationship with the content of that object. Future plans for this draft include the use of normative text, a worked example as an appendix, and running code for next IETF. Discussion: Steve Kent noted that more precision would be helpful in describing the intended limitations on the certificate that signs the RPSL object, and voiced a more general observation that in his view many things in RPSL are orthogonal to RPKI, and this may have an impact on the consistency with the CP. Robert Kisteleki noted in response that he believed that this intended approach was consistent with the CP, in that in this context a resource holder is signing an attestation relating to the intended use of a resource. 1.5 BGP Considerations BGP Prefix Origin Validation draft-pmohapat-sidr-pfx-validate-01.txt draft-ymbk-rpki-rtr-protocol-04.txt Presenter: Randy Bush & Dave Ward. The WG was requested to consider whether to adopt draft-pmohapat-sidr-pfx-validate as a WG document. Discussion: The question was raised as to how this document related to the draft-ietf-sidr-roa-validation draft, which will be taken to the WG mailing list, together with the question of WG adoption of the pfx-validate draft. The question was also raised as to the relationship between the pfx-validate draft and the rtr-protocol draft. Matt Lepinski voiced the view that both drafts were helpful contributions should be considered for WG adoption. 2. New Drafts 2.1 Use Cases Use Cases and interpretation of RPKI objects for issuers and relying parties draft-manderson-sidr-usecases-00.txt Presenter: Terry Manderson The motivation for this document was to gain a common understanding of the problem space by example. The WG was requested to review the draft and provide comments. Discussion: Danny McPherson raised the question of the relationship of this document to the SIDR WG charter. The WG discussed the issue relating to the study of validation of AS Path in relation to the current WG charter. Ross Callon, speaking as Routing AD noted that this had already been considered at length in RPSEC, and if there was a prospect of reaching some consensus as to requirements relating to Path validation then this should be proposed as an addition to the WG charter. As a first step, however, origination was the area where clear requirements have been provided to SIDR from RPSEC. This topic should be taken to the WG mailing list for further consideration. Randy Bush noted that the work on origination validation was a major achievement and this work should be completed before embarking on another major effort. Russ Housley, speaking as IETF Chair, noted that the SIDR charter is clear on this, and requirements need to come from the RPSEC WG. The WG needs to ask the AD where are the requirements going to come from, and it is appropiate for the WG to seek AD guidance on this topic. Danny McPherson voiced the opinion that what the WG may decide on origination may restrict the options in addressing path validation. The WG discussed the topic of origination and path validation and there was no clear agreement that the SIDR WG approach to origination necessarily restricted the scope of mechanisms that could be used for path validation. The WG Chairs will consult the AD for guidance on the topic of the WG charter and the program of future activity for this WG. 2.2 Interpretation of ROA in Origination Validation presented K. Sriram A particular case of issuing ROAs was presented by K. Sriram and discussed by the WG, as an extension of the use-case study and ROA validation. 3. New Topics 3.1 Local Trust Anchor Management Presenter: Steve Kent Presentation outlining an approach where Relying Parties could generate a TA locally from existing RPKI information. Discussion: Randy Bush commented that this has all the problem of unique DNS root, where different views of the routing table may result. He noted that this approach may have use for private address space. In response it was noted that this approach created potential differences if there was an inconsistency in the RPKI space and the relying party believed it had sufficient information to resolve this in favour of one party of the other. It was also noted that this approach was always viable for RPs, and could not be prevented. Rob Austein commented that a RP can know more but can also know less that the public universe. The problem with multiple roots is that the RP may not have enough information on what to do when there is a conflict, nor have the ability to resolve these conflicts in a manner that was consistent with the linkage between the RP's local TA and the RPKI. From root@core3.amsl.com Mon Aug 24 21:00:01 2009 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 970CE3A6EB3; Mon, 24 Aug 2009 21:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090825040001.970CE3A6EB3@core3.amsl.com> Date: Mon, 24 Aug 2009 21:00:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-rpki-algs-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 04:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure Author(s) : G. Huston Filename : draft-ietf-sidr-rpki-algs-00.txt Pages : 4 Date : 2009-08-24 This document defines a profile for the algorithm and key size to be used for signatures applied to certificates, Certificate Revocation Lists, and signed objects in the context of the Resource Public Key Infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-algs-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-rpki-algs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-24205843.I-D@ietf.org> --NextPart-- From randy@psg.com Mon Aug 24 22:24:38 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59E213A6DB2 for ; Mon, 24 Aug 2009 22:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFP67tXyw2HS for ; Mon, 24 Aug 2009 22:24:37 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 5870B3A6A01 for ; Mon, 24 Aug 2009 22:24:37 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MfoWO-0008z0-JU; Tue, 25 Aug 2009 05:24:40 +0000 Received: from rmac.wdcguest.wdc.sri.com.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 0905B2981BBB; Tue, 25 Aug 2009 14:24:40 +0900 (JST) Date: Tue, 25 Aug 2009 14:24:39 +0900 Message-ID: From: Randy Bush To: Geoff Huston In-Reply-To: <0D3F2A5C-5900-4D11-A34D-AD2D6E732944@apnic.net> References: <0D3F2A5C-5900-4D11-A34D-AD2D6E732944@apnic.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] draft IETF 75 meeting minutes uploaded X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 05:24:38 -0000 > The audo recordings of the meeting provide a good record of what was > said, so it might make sense for the minutes to attempt to provide a > summary of discussion and note actions and outcomes. i object traditional minutes are worthwhile, and roque's work was good. folk who want to listen to the audio can, but the written record should remain as it has been. randy From housley@vigilsec.com Tue Aug 25 06:07:24 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F63F3A6F5C for ; Tue, 25 Aug 2009 06:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.682 X-Spam-Level: X-Spam-Status: No, score=-101.682 tagged_above=-999 required=5 tests=[AWL=-0.541, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcOeH46JaCgH for ; Tue, 25 Aug 2009 06:07:24 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id DE00B3A6F57 for ; Tue, 25 Aug 2009 06:07:23 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 5F300F2402C for ; Tue, 25 Aug 2009 09:07:41 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 0iyYujfAh+Nc for ; Tue, 25 Aug 2009 09:07:26 -0400 (EDT) Received: from THINKPADR52.vigilsec.com (pool-96-241-154-102.washdc.fios.verizon.net [96.241.154.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id C9035F2402B for ; Tue, 25 Aug 2009 09:07:40 -0400 (EDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 25 Aug 2009 09:07:14 -0400 To: sidr@ietf.org From: Russ Housley In-Reply-To: <20090825040001.970CE3A6EB3@core3.amsl.com> References: <20090825040001.970CE3A6EB3@core3.amsl.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Message-Id: <20090825130740.C9035F2402B@odin.smetech.net> Subject: Re: [sidr] I-D Action:draft-ietf-sidr-rpki-algs-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 13:07:24 -0000 I have a few comments on Section 2.

2.  Algorithm and Key Size

   This profile specifies the use of the RSA algorithm
[RFC3447] to
   compute the signature of certificates, CRLs and signed
objects in the
   context of the RPKI.  This profile specifies a default
of SHA-256
   with RSA (sha256WithRSAEncryption), and allows for the use
of SHA-384
   (sha384WithRSAEncryption) or SHA-512
(sha384WithRSAEncryption).

>> Typo: s/512 (sha384/512 (sha512/

   Accordingly, The OID values used in the RPKI for such
signatures MUST
   be one of { pkcs-1 11 }, { pkcs-1 12 } or { pkcs-1 13 }
[RFC4055].

   The required RSA key size MUST be 2048 bits.

   The public exponent (e) of the RSA algorithm is F4
(65,537).
>> Why allow all three hash functions.  Since you are specifying a particular key size, it seems better to select the hash function that matches that key size.

>> I can see an argument for MUST SHA-256 and SHOULD SHA-384 as an indicator that the longer has will be needed in the future.

Russ From Sandra.Murphy@cobham.com Tue Aug 25 07:50:07 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4F843A659C for ; Tue, 25 Aug 2009 07:50:07 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LfODCFNdzOm for ; Tue, 25 Aug 2009 07:50:06 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id DA7F83A686D for ; Tue, 25 Aug 2009 07:50:04 -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 n7PEo7oC016550; Tue, 25 Aug 2009 09:50:07 -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 n7PEo611029803; Tue, 25 Aug 2009 09:50:07 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.121]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Aug 2009 10:50:06 -0400 Date: Tue, 25 Aug 2009 10:50:06 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Geoff Huston In-Reply-To: <0D3F2A5C-5900-4D11-A34D-AD2D6E732944@apnic.net> Message-ID: References: <0D3F2A5C-5900-4D11-A34D-AD2D6E732944@apnic.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 25 Aug 2009 14:50:06.0520 (UTC) FILETIME=[55E87B80:01CA2593] Cc: sidr@ietf.org Subject: Re: [sidr] draft IETF 75 meeting minutes uploaded X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 14:50:07 -0000 On Tue, 25 Aug 2009, Geoff Huston wrote: > > On 25/08/2009, at 7:48 AM, Sandra Murphy wrote: > >> The draft of the minutes (thanks, Roque) has been uploaded to the IETF75 >> meeting materials page at >> http://www.ietf.org/proceedings/75/minutes/sidr.txt. >> >> Please review these minutes and provide comments or corrections to the >> list. >> > > > Hi, > > The audo recordings of the meeting provide a good record of what was said, so > it might make sense for the minutes to attempt to provide a summary of > discussion and note actions and outcomes. I recognize that the audio recordings are complete and accurate (as far as the quality allows). However, review of the audio recording is difficult, as it is strictly sequential access. I believe that the minutes record of the discussion has value over the audio recording. The minutes should indeed record actions agreed to in the meeting and any consensus, and it should also record the opinions expressed, so that those unable to attend know what was considered. > > So I've taken the liberty of reviewing Roque's notes and editing them a > little - I hope this is useful I appreciate the more compressed report style of what you propose, but I do not think that they should replace the minutes taken during the meeting. Not only are the details beneficial (without listening to the entire audio recording, as I said above), but the summary style you propose requires effort I don't want to require of the minutes taker. I'm appreciate that you put some effort into this summary and I don't want to lose the results. Would you prefer to leave this summary archived in the mailing list, or would you prefer to see it appended to the minutes for the proceedings? --Sandy > > thanks, > > Geoff > > ----------------- > > > IETF75 > > SIDR WG > Thursday, July 30, 2009 0900-1130 > > Chairs: Sandy Murphy, Geoff Huston > Minutes: Roque Gagliano. > > Actions: > > WG consideration of a document that specifies algorithm and key > sizes for all RPKI components > > Revise the CP to include text that limited the applicability of the > RPKI such that validly signed objects would need to be specified in > an IETF Standards track document. > > The RPKI CP should stay within the IETF process, as a BCP. > > The WG Chairs will consult the AD for guidance on the topic of the > WG charter and the program of future activity for this WG. > > Notes: > > 1. Updated Drafts > > 1.1 ROA Format > A Profile for Route Origin Authorizations (ROAs) > draft-ietf-sidr-roa-format-05.txt > presenter: Matt Lepinski > > On the issue of algorithm agility, it was note that algorithm and > key length specifications have been included in all RPKI documents > up until now. This version of the ROA profile draft has replaced > this with a reference to the CP document as an initial suggestion as > to how to centralise all the references to a single specification > document. The CP has been nominated as the appropriate document to > carry the RPKI algorithm and key length specification, but this is a > matter for discussion by the WG. The other option is a separate WG > document which carries only this common algorithm and key length > specification, as is proposed by Geoff Huston. > > Discussion: > > Russ Housley noted that many WG have make this mistake. The issue > here is that in order to subsequently change algorithms, there is > a need to update all the documents. In this case, if you use the > CP, you need to update the complete CP. This has delayed other > work in the Security Area in the past. Russ recommends the WG > adopting a dedicated document that described algorithms, and this > document is to be referenced in the other documents. > > Sandy Murphy commented that Roque Gagliano realized that one of > the problem is that you can get inconsistencies between documents. > > Rob Austein commented that on problem with putting the algorithm > profile in the CP was that it was a lengthy and detailed document > was was eye-glazing for a reader, and Rob was unsure that > implementers will read it. Rob noted that he had no problem with a > single document to specify a common algorithm profile for the > RPKI, but it should not be the CP. > > Roque Gagliano noted that the CP is intended to be maintained by > different organizations revisions to the CP in the case of a > technical requirement for algorithm change, and the organizational > review process of the CP may be inappropriate for such a > task. Roque concurs on having a dedicated document for this > specification. > > Sandy Murphy, as Chair, thanked Roque for noticing the problem > with the key length in different documents. > > > 1.2 RPKI Architecture > An Infrastructure to Support Secure Internet Routing > draft-ietf-sidr-arch-07.txt > presenter: Matt Lepinski > > The change to this document was that the Certificate's Subject Name > has been specificed as not intended to be meaningful across the > entire RPKI, and the exception noted RIR and other entities have > been removed from the draft. Subject Names are not intended to > convey meaningful information and must be unique. The WG was > requested to review the most recent draft of this document. > > Discussion: > > Sam Weiler asked in IANA was to remain a special case in this > respect. Matt indicated that this was not the case. > > 1.3 Certificate Policy > Certificate Policy (CP) for the Resource PKI (RPKI) > draft-ietf-sidr-cp-06.txt > Presenter: Stephen Kent > > Steve Kent noted that Andrei Robachevski, as a representative for > the RIRs, gave the document's editors substantial feedback arising > from an RIR staff review. The changes applied as a result of these > comments are noted in the presentation. The revision has removed CP > approval procedures to be made by the organizations administering > the CP, although it was noted that this may need further review, as > the also CP relates to ISPs and other organizations who undertake a > CA role in the context of the RPKI. > > Discussion: > > Randy Bush inquired as to the current recommendations regarding > management of the CP document, and it was noted that the current > draft of the CP called on the RIRs and IANA to manage the process > of updates to the CP. > > Steve Kent noted that there was a confident expectation that the > algorithm and key size may change over time, and if this > specification was to be placed into the CP, then the process > regarding changes to the CP would need to take this into > account. Steve noted that he agreed with Geoff and Russ about > having a different document for algorithm and key profile for the > RPKI to address this. > > Russ Housley spoke to question of the CP update process and which > party was placed in the role of approval of changes to the > CP. Russ noted that topics that are local RIR and ISP policies > have impact beyond the CP, and would normally be left to the > CPS. Russ was in favour of a position where the RPKI CP should > stay within the IETF process, as a BCP, and other parties, > including the RIRs and ISPS, would maintain their CPS documents > regaring local policies. > > Randy Bush raised the question of the scope of the RPKI in terms > of the validity of arbitrary documents signed using signatures > that are validated within the RPKI. Steve Kent noted that one > response to this concern was the possible inclusion of text in the > CP that limited the applicability of the RPKI such that validly > signed objects would need to be specified in an IETF Standards > track document. > > > 1.4 RPSL with RPKI Signatures > Securing RPSL Objects with RPKI Signatures > draft-ietf-sidr-rpsl-sig-01.txt > Presenter: Robert Kisteleki > > It was noted that the document had been revised with minor changes, > including text on URL safeness, modifications to the procedure to be > used for text normalization modified, additional text on number > resource coverage, and the general caveat that the certificate that > signs an RPSL object must have some verifiable relationship with the > content of that object. > > Future plans for this draft include the use of normative text, a > worked example as an appendix, and running code for next IETF. > > Discussion: > > Steve Kent noted that more precision would be helpful in describing > the intended limitations on the certificate that signs the RPSL > object, and voiced a more general observation that in his view many > things in RPSL are orthogonal to RPKI, and this may have an impact > on the consistency with the CP. Robert Kisteleki noted in response > that he believed that this intended approach was consistent with the > CP, in that in this context a resource holder is signing an > attestation relating to the intended use of a resource. > > 1.5 BGP Considerations > BGP Prefix Origin Validation > draft-pmohapat-sidr-pfx-validate-01.txt > draft-ymbk-rpki-rtr-protocol-04.txt > Presenter: Randy Bush & Dave Ward. > > The WG was requested to consider whether to adopt > draft-pmohapat-sidr-pfx-validate as a WG document. > > Discussion: > > The question was raised as to how this document related to the > draft-ietf-sidr-roa-validation draft, which will be taken to the > WG mailing list, together with the question of WG adoption of the > pfx-validate draft. > > The question was also raised as to the relationship between the > pfx-validate draft and the rtr-protocol draft. Matt Lepinski > voiced the view that both drafts were helpful contributions should > be considered for WG adoption. > > 2. New Drafts > > 2.1 Use Cases > > Use Cases and interpretation of RPKI objects for issuers and > relying parties > draft-manderson-sidr-usecases-00.txt > Presenter: Terry Manderson > > The motivation for this document was to gain a common understanding > of the problem space by example. The WG was requested to review the > draft and provide comments. > > Discussion: > > Danny McPherson raised the question of the relationship of this > document to the SIDR WG charter. The WG discussed the issue > relating to the study of validation of AS Path in relation to the > current WG charter. > > Ross Callon, speaking as Routing AD noted that this had already > been considered at length in RPSEC, and if there was a prospect of > reaching some consensus as to requirements relating to Path > validation then this should be proposed as an addition to the WG > charter. As a first step, however, origination was the area where > clear requirements have been provided to SIDR from RPSEC. This > topic should be taken to the WG mailing list for further > consideration. > > Randy Bush noted that the work on origination validation was a > major achievement and this work should be completed before > embarking on another major effort. > > Russ Housley, speaking as IETF Chair, noted that the SIDR charter > is clear on this, and requirements need to come from the RPSEC > WG. The WG needs to ask the AD where are the requirements going to > come from, and it is appropiate for the WG to seek AD guidance on > this topic. > > Danny McPherson voiced the opinion that what the WG may decide on > origination may restrict the options in addressing path > validation. The WG discussed the topic of origination and path > validation and there was no clear agreement that the SIDR WG > approach to origination necessarily restricted the scope of > mechanisms that could be used for path validation. > > The WG Chairs will consult the AD for guidance on the topic of the > WG charter and the program of future activity for this WG. > > 2.2 Interpretation of ROA in Origination Validation > presented K. Sriram > > A particular case of issuing ROAs was presented by K. Sriram and > discussed by the WG, as an extension of the use-case study and ROA > validation. > > 3. New Topics > > 3.1 Local Trust Anchor Management > Presenter: Steve Kent > > Presentation outlining an approach where Relying Parties could > generate a TA locally from existing RPKI information. > > Discussion: > > Randy Bush commented that this has all the problem of unique DNS > root, where different views of the routing table may result. He > noted that this approach may have use for private address space. In > response it was noted that this approach created potential > differences if there was an inconsistency in the RPKI space and the > relying party believed it had sufficient information to resolve this > in favour of one party of the other. > > It was also noted that this approach was always viable for RPs, and > could not be prevented. Rob Austein commented that a RP can know > more but can also know less that the public universe. The problem > with multiple roots is that the RP may not have enough information > on what to do when there is a conflict, nor have the ability to > resolve these conflicts in a manner that was consistent with the > linkage between the RP's local TA and the RPKI. > > > From david.cooper@nist.gov Tue Aug 25 08:45:28 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECA513A6AC1 for ; Tue, 25 Aug 2009 08:45: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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrvNOYCuEchN for ; Tue, 25 Aug 2009 08:45:27 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id 7D6E03A6ED2 for ; Tue, 25 Aug 2009 08:45:27 -0700 (PDT) Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n7PFjPLl025469 for ; Tue, 25 Aug 2009 11:45:25 -0400 Message-ID: <4A940715.4000306@nist.gov> Date: Tue, 25 Aug 2009 11:45:25 -0400 From: "David A. Cooper" User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: "sidr@ietf.org" References: <20090825040001.970CE3A6EB3@core3.amsl.com> <20090825130740.C9035F2402B@odin.smetech.net> In-Reply-To: <20090825130740.C9035F2402B@odin.smetech.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Subject: Re: [sidr] I-D Action:draft-ietf-sidr-rpki-algs-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 15:45:29 -0000 I agree with Russ in part, but would propose a different solution. Barring any as yet undiscovered cryptanalytic attacks, SHA-256 is already stronger than 2048-bit RSA. According to Table 3 of NIST SP 800-57 part 1 (http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf), a hash function when used for digital signatures has a cryptographic strength (i.e., number of bits of security) equal to half the length of its output. That is 128, 192, and 256 bits for SHA-256, SHA-384, and SHA-512, respectively. Meanwhile, Table 2 of SP 800-57 part 1 indicates the RSA key length needed to obtain various bits of security: bits of security RSA modulus length -------------- --------------------- 80 1024 112 2048 128 3072 192 7680 256 15360 So, I don't see any reason to allow the use of hash algorithms stronger than SHA-256 while simultaneously stating that the RSA public key must be exactly 2048 bits. As an alternative, I would suggest mandating the use of SHA-256 with a 2048 bit RSA key, while encouraging implementations to be able to handle both longer RSA key sizes and stronger hash algorithms in order to facilitate a transition to stronger cryptography at some point in the future. In addition, I see no reason to recommend support for SHA-384. As stated in Section 6 of FIPS 180-3: the specification for SHA-224 is identical to SHA-256, except that different initial hash values are used, and the final hash value is truncated to 224 bits for SHA-224. The same is true for SHA-512 and SHA-384, except that the final hash value is truncated to 384 bits for SHA-384. So, if you use SHA-384 you are essentially just computing SHA-512 and then truncating the output. This truncation is useful in some cases (e.g., ECDSA), but there's no reason to do it for an RSA signature. Granted, SHA-384 is already overkill, but if you're going to go through the work of computing a SHA-512 hash, you might as well just go ahead and use the resulting output rather than truncating it unnecessarily. So, here would be my recommendation for Section 2: This profile specifies the use of RSASSA-PKCS1-v1_5 [RFC3447] with the SHA-256 hash algorithm to compute the signature of certificates, CRLs, and signed objects in the context of the RPKI. Accordingly, the OID value in the RPKI for such signatures MUST be 1.2.840.113549.1.1.11 (sha256WithRSAEncryption). The RSA key pairs used to compute the signatures MUST have a 2048-bit modulus and a public exponent (e) of 65,537. In order to facilitate a potential need to transition to stronger cryptographic algorithms in the future, Certification Authorities (CAs) and Relying Parties (RPs) SHOULD be able to generate and verify RSASSA-PKCS1-v1_5 signatures using the SHA-512 hash algorithm and RSA key sizes longer than 2048 bits. [NOTE: There are certainly other algorithms that one might encourage CAs and RPs to be able to support as candidates for use in the future, such as RSASSA-PSS or ECDSA, but the text that I proposed seems to align most closely with the current text.] Dave Russ Housley wrote: > >> Why allow all three hash functions. Since you are specifying a > particular key size, it seems better to select the hash function that > matches that key size. > > >> I can see an argument for MUST SHA-256 and SHOULD SHA-384 as an > indicator that the longer has will be needed in the future. > > Russ > 2. Algorithm and Key Size > > This profile specifies the use of the RSA algorithm [RFC3447] to > compute the signature of certificates, CRLs and signed objects in the > context of the RPKI. This profile specifies a default of SHA-256 > with RSA (sha256WithRSAEncryption), and allows for the use of SHA-384 > (sha384WithRSAEncryption) or SHA-512 (sha384WithRSAEncryption). > Accordingly, The OID values used in the RPKI for such signatures MUST > be one of { pkcs-1 11 }, { pkcs-1 12 } or { pkcs-1 13 } [RFC4055]. > > The required RSA key size MUST be 2048 bits. > > The public exponent (e) of the RSA algorithm is F4 (65,537). From rgaglian@fing.edu.uy Tue Aug 25 16:06:42 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78D7128C103 for ; Tue, 25 Aug 2009 16:06:42 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wub6+YFmSxbA for ; Tue, 25 Aug 2009 16:06:41 -0700 (PDT) Received: from davinci.fing.edu.uy (davinci.fing.edu.uy [164.73.32.2]) by core3.amsl.com (Postfix) with ESMTP id 6EE993A6864 for ; Tue, 25 Aug 2009 16:06:39 -0700 (PDT) Received: from [192.168.1.101] (r190-64-122-1.dialup.adsl.anteldata.net.uy [190.64.122.1]) (authenticated bits=0) by davinci.fing.edu.uy with ESMTP id n7PN6RNA025812; Tue, 25 Aug 2009 20:06:28 -0300 (UYT) Message-Id: <981074B6-3724-45F7-A87C-E423B9545D10@fing.edu.uy> From: Roque Gagliano To: Sandra Murphy In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 25 Aug 2009 20:06:26 -0300 References: <0D3F2A5C-5900-4D11-A34D-AD2D6E732944@apnic.net> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.936) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (davinci.fing.edu.uy [164.73.32.2]); Tue, 25 Aug 2009 20:06:31 -0300 (UYT) X-Scanned-By: MIMEDefang 2.63 on 164.73.32.2 Cc: sidr@ietf.org Subject: Re: [sidr] draft IETF 75 meeting minutes uploaded X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 23:06:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sandy, > > I'm appreciate that you put some effort into this summary and I =20 > don't want to lose the results. Would you prefer to leave this =20 > summary archived in the mailing list, or would you prefer to see it =20= > appended to the minutes for the proceedings? > I believe that Geoff-s effort should not be lost and its content does =20= not contradict my notes. I have no objection to append it to the =20 minutes. Roque. > --Sandy > >> >> thanks, >> >> Geoff >> >> ----------------- >> >> >> IETF75 >> >> SIDR WG >> Thursday, July 30, 2009 0900-1130 >> >> Chairs: Sandy Murphy, Geoff Huston >> Minutes: Roque Gagliano. >> >> Actions: >> >> WG consideration of a document that specifies algorithm and key >> sizes for all RPKI components >> >> Revise the CP to include text that limited the applicability of the >> RPKI such that validly signed objects would need to be specified in >> an IETF Standards track document. >> >> The RPKI CP should stay within the IETF process, as a BCP. >> >> The WG Chairs will consult the AD for guidance on the topic of the >> WG charter and the program of future activity for this WG. >> >> Notes: >> >> 1. Updated Drafts >> >> 1.1 ROA Format >> A Profile for Route Origin Authorizations (ROAs) >> draft-ietf-sidr-roa-format-05.txt >> presenter: Matt Lepinski >> >> On the issue of algorithm agility, it was note that algorithm and >> key length specifications have been included in all RPKI documents >> up until now. This version of the ROA profile draft has replaced >> this with a reference to the CP document as an initial suggestion as >> to how to centralise all the references to a single specification >> document. The CP has been nominated as the appropriate document to >> carry the RPKI algorithm and key length specification, but this is a >> matter for discussion by the WG. The other option is a separate WG >> document which carries only this common algorithm and key length >> specification, as is proposed by Geoff Huston. >> >> Discussion: >> >> Russ Housley noted that many WG have make this mistake. The issue >> here is that in order to subsequently change algorithms, there is >> a need to update all the documents. In this case, if you use the >> CP, you need to update the complete CP. This has delayed other >> work in the Security Area in the past. Russ recommends the WG >> adopting a dedicated document that described algorithms, and this >> document is to be referenced in the other documents. >> >> Sandy Murphy commented that Roque Gagliano realized that one of >> the problem is that you can get inconsistencies between documents. >> >> Rob Austein commented that on problem with putting the algorithm >> profile in the CP was that it was a lengthy and detailed document >> was was eye-glazing for a reader, and Rob was unsure that >> implementers will read it. Rob noted that he had no problem with a >> single document to specify a common algorithm profile for the >> RPKI, but it should not be the CP. >> >> Roque Gagliano noted that the CP is intended to be maintained by >> different organizations revisions to the CP in the case of a >> technical requirement for algorithm change, and the organizational >> review process of the CP may be inappropriate for such a >> task. Roque concurs on having a dedicated document for this >> specification. >> >> Sandy Murphy, as Chair, thanked Roque for noticing the problem >> with the key length in different documents. >> >> >> 1.2 RPKI Architecture >> An Infrastructure to Support Secure Internet Routing >> draft-ietf-sidr-arch-07.txt >> presenter: Matt Lepinski >> >> The change to this document was that the Certificate's Subject Name >> has been specificed as not intended to be meaningful across the >> entire RPKI, and the exception noted RIR and other entities have >> been removed from the draft. Subject Names are not intended to >> convey meaningful information and must be unique. The WG was >> requested to review the most recent draft of this document. >> >> Discussion: >> >> Sam Weiler asked in IANA was to remain a special case in this >> respect. Matt indicated that this was not the case. >> >> 1.3 Certificate Policy >> Certificate Policy (CP) for the Resource PKI (RPKI) >> draft-ietf-sidr-cp-06.txt >> Presenter: Stephen Kent >> >> Steve Kent noted that Andrei Robachevski, as a representative for >> the RIRs, gave the document's editors substantial feedback arising >> from an RIR staff review. The changes applied as a result of these >> comments are noted in the presentation. The revision has removed CP >> approval procedures to be made by the organizations administering >> the CP, although it was noted that this may need further review, as >> the also CP relates to ISPs and other organizations who undertake a >> CA role in the context of the RPKI. >> >> Discussion: >> >> Randy Bush inquired as to the current recommendations regarding >> management of the CP document, and it was noted that the current >> draft of the CP called on the RIRs and IANA to manage the process >> of updates to the CP. >> >> Steve Kent noted that there was a confident expectation that the >> algorithm and key size may change over time, and if this >> specification was to be placed into the CP, then the process >> regarding changes to the CP would need to take this into >> account. Steve noted that he agreed with Geoff and Russ about >> having a different document for algorithm and key profile for the >> RPKI to address this. >> >> Russ Housley spoke to question of the CP update process and which >> party was placed in the role of approval of changes to the >> CP. Russ noted that topics that are local RIR and ISP policies >> have impact beyond the CP, and would normally be left to the >> CPS. Russ was in favour of a position where the RPKI CP should >> stay within the IETF process, as a BCP, and other parties, >> including the RIRs and ISPS, would maintain their CPS documents >> regaring local policies. >> >> Randy Bush raised the question of the scope of the RPKI in terms >> of the validity of arbitrary documents signed using signatures >> that are validated within the RPKI. Steve Kent noted that one >> response to this concern was the possible inclusion of text in the >> CP that limited the applicability of the RPKI such that validly >> signed objects would need to be specified in an IETF Standards >> track document. >> >> >> 1.4 RPSL with RPKI Signatures >> Securing RPSL Objects with RPKI Signatures >> draft-ietf-sidr-rpsl-sig-01.txt >> Presenter: Robert Kisteleki >> >> It was noted that the document had been revised with minor changes, >> including text on URL safeness, modifications to the procedure to be >> used for text normalization modified, additional text on number >> resource coverage, and the general caveat that the certificate that >> signs an RPSL object must have some verifiable relationship with the >> content of that object. >> >> Future plans for this draft include the use of normative text, a >> worked example as an appendix, and running code for next IETF. >> >> Discussion: >> >> Steve Kent noted that more precision would be helpful in describing >> the intended limitations on the certificate that signs the RPSL >> object, and voiced a more general observation that in his view many >> things in RPSL are orthogonal to RPKI, and this may have an impact >> on the consistency with the CP. Robert Kisteleki noted in response >> that he believed that this intended approach was consistent with the >> CP, in that in this context a resource holder is signing an >> attestation relating to the intended use of a resource. >> >> 1.5 BGP Considerations >> BGP Prefix Origin Validation >> draft-pmohapat-sidr-pfx-validate-01.txt >> draft-ymbk-rpki-rtr-protocol-04.txt >> Presenter: Randy Bush & Dave Ward. >> >> The WG was requested to consider whether to adopt >> draft-pmohapat-sidr-pfx-validate as a WG document. >> >> Discussion: >> >> The question was raised as to how this document related to the >> draft-ietf-sidr-roa-validation draft, which will be taken to the >> WG mailing list, together with the question of WG adoption of the >> pfx-validate draft. >> >> The question was also raised as to the relationship between the >> pfx-validate draft and the rtr-protocol draft. Matt Lepinski >> voiced the view that both drafts were helpful contributions should >> be considered for WG adoption. >> >> 2. New Drafts >> >> 2.1 Use Cases >> >> Use Cases and interpretation of RPKI objects for issuers and >> relying parties >> draft-manderson-sidr-usecases-00.txt >> Presenter: Terry Manderson >> >> The motivation for this document was to gain a common understanding >> of the problem space by example. The WG was requested to review the >> draft and provide comments. >> >> Discussion: >> >> Danny McPherson raised the question of the relationship of this >> document to the SIDR WG charter. The WG discussed the issue >> relating to the study of validation of AS Path in relation to the >> current WG charter. >> >> Ross Callon, speaking as Routing AD noted that this had already >> been considered at length in RPSEC, and if there was a prospect of >> reaching some consensus as to requirements relating to Path >> validation then this should be proposed as an addition to the WG >> charter. As a first step, however, origination was the area where >> clear requirements have been provided to SIDR from RPSEC. This >> topic should be taken to the WG mailing list for further >> consideration. >> >> Randy Bush noted that the work on origination validation was a >> major achievement and this work should be completed before >> embarking on another major effort. >> >> Russ Housley, speaking as IETF Chair, noted that the SIDR charter >> is clear on this, and requirements need to come from the RPSEC >> WG. The WG needs to ask the AD where are the requirements going to >> come from, and it is appropiate for the WG to seek AD guidance on >> this topic. >> >> Danny McPherson voiced the opinion that what the WG may decide on >> origination may restrict the options in addressing path >> validation. The WG discussed the topic of origination and path >> validation and there was no clear agreement that the SIDR WG >> approach to origination necessarily restricted the scope of >> mechanisms that could be used for path validation. >> >> The WG Chairs will consult the AD for guidance on the topic of the >> WG charter and the program of future activity for this WG. >> >> 2.2 Interpretation of ROA in Origination Validation >> presented K. Sriram >> >> A particular case of issuing ROAs was presented by K. Sriram and >> discussed by the WG, as an extension of the use-case study and ROA >> validation. >> >> 3. New Topics >> >> 3.1 Local Trust Anchor Management >> Presenter: Steve Kent >> >> Presentation outlining an approach where Relying Parties could >> generate a TA locally from existing RPKI information. >> >> Discussion: >> >> Randy Bush commented that this has all the problem of unique DNS >> root, where different views of the routing table may result. He >> noted that this approach may have use for private address space. In >> response it was noted that this approach created potential >> differences if there was an inconsistency in the RPKI space and the >> relying party believed it had sufficient information to resolve this >> in favour of one party of the other. >> >> It was also noted that this approach was always viable for RPs, and >> could not be prevented. Rob Austein commented that a RP can know >> more but can also know less that the public universe. The problem >> with multiple roots is that the RP may not have enough information >> on what to do when there is a conflict, nor have the ability to >> resolve these conflicts in a manner that was consistent with the >> linkage between the RP's local TA and the RPKI. >> >> >> > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkqUbnIACgkQnk+WSgHpbO6SqACgxDA9ilDUZB2fo3PRXlclnJjv LTwAoMswb/IX+MSbDFhNq7Da6n++Nq8v =3Dn2mc -----END PGP SIGNATURE----- From weiler@watson.org Thu Aug 27 22:18:29 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E5FB3A6BE2 for ; Thu, 27 Aug 2009 22:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fFIo-uZcJ8d for ; Thu, 27 Aug 2009 22:18:28 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 7B3F63A69ED for ; Thu, 27 Aug 2009 22:18:16 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n7S5IMdE095172 for ; Fri, 28 Aug 2009 01:18:22 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n7S5IMp7095168 for ; Fri, 28 Aug 2009 01:18:22 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 28 Aug 2009 01:18:22 -0400 (EDT) From: Samuel Weiler To: sidr@ietf.org In-Reply-To: <981074B6-3724-45F7-A87C-E423B9545D10@fing.edu.uy> Message-ID: References: <0D3F2A5C-5900-4D11-A34D-AD2D6E732944@apnic.net> <981074B6-3724-45F7-A87C-E423B9545D10@fing.edu.uy> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Fri, 28 Aug 2009 01:18:22 -0400 (EDT) Subject: Re: [sidr] draft IETF 75 meeting minutes uploaded X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 05:18:29 -0000 Many thanks to Roque for taking minutes and to Geoff for editting them into the cleaner narrative form. Since the raw minutes have details that haven't been posted to this list or otherwise archived, I suggest including both the raw notes and the editted form in the minutes submission. In comparing the raw and editted minutes, one thing jumped out. The editted version shows an action item of: "Revise the CP to include text that limited the applicability of the RPKI such that validly signed objects would need to be specified in an IETF Standards track document." While I saw that suggestion in the raw notes, I don't remember it getting enough support to count as an action item. That said, I haven't looked back at my own notes to see what I think was said -- I'm just comparing the two versions of the minutes. -- Sam From kent@bbn.com Thu Aug 27 22:56:24 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6A2E3A6B94 for ; Thu, 27 Aug 2009 22:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOVTNMUANubU for ; Thu, 27 Aug 2009 22:56:24 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 11B7D3A6890 for ; Thu, 27 Aug 2009 22:56:24 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[169.223.7.234]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1MguRp-0005FT-BQ; Fri, 28 Aug 2009 01:56:29 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <0D3F2A5C-5900-4D11-A34D-AD2D6E732944@apnic.net> <981074B6-3724-45F7-A87C-E423B9545D10@fing.edu.uy> Date: Fri, 28 Aug 2009 01:56:33 -0400 To: Samuel Weiler From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] draft IETF 75 meeting minutes uploaded X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 05:56:24 -0000 Sam, I left the meeting believing this was a change to the CP that I would make, based on the discussion. Steve From weiler+lists.sidr@watson.org Mon Aug 31 20:48:03 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBB1028C2AA for ; Mon, 31 Aug 2009 20:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_71=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNCNF+U4gx87 for ; Mon, 31 Aug 2009 20:48:01 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 7FD2128C2A5 for ; Mon, 31 Aug 2009 20:48:01 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n813mBGU088094 for ; Mon, 31 Aug 2009 23:48:12 -0400 (EDT) (envelope-from weiler+lists.sidr@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n813mBI8088090 for ; Mon, 31 Aug 2009 23:48:11 -0400 (EDT) (envelope-from weiler+lists.sidr@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 31 Aug 2009 23:48:11 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: sidr@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Mon, 31 Aug 2009 23:48:12 -0400 (EDT) Subject: Re: [sidr] Audio timestamps from IETF74 San Francisco X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 03:48:03 -0000 The recent discussion of IETF 75 minutes reminded me that I never followed through with posting my notes from IETF 74 in San Francisco. A few months ago, I went back and listened to the audio archive of the San Francisco meeting. Here are my notes from listening again. In some places it's word for word; in some places paraphrased. I believe the substance was accuately captured, though I'm sure the detail was not. Perhaps these will be helpful to someone, particularly given the sparse minutes from that meeting. Numbers in brackets are timestamps from the MP3, noting that the meeting starts about 11 minutes into that MP3. -- No amendments to the agenda; George as jabber scribe, Geoff as minute taker. Greg Lebovitz promoting the kmart work, for authenticating peering. Intent is to add key management, in part to keep operators from knowing keys. [17:50] Matt Lepinski re: architecture draft. Removed text re: trust anchors and defualt trust anchor text. Now points to separate draft. Also removed text on ROA usage; that should be in the validation draft. thanked Danny McPherson for his review. Another change suggested by George and Geoff re: subject names in certificates. Background: although RIRs may have meaningful subject names, other certs should (must?) not. To make barrier to entry as low as possible, not asking CAs to do identity verification. One property vital for certificate paths, but name should be unique among certs from one CA. Previously: recommendation had been: DN should only have a CN attribute w/ meaningless string. Recommendation is now to use two attributes: a CN and a serial number. APNIC wants a string that persists across reissues. Serial can be chosen in any way. Randy: why are RIR/NIR names meaningful, but not IANA/other LIR? Matt: no good answer. Randy: then maybe you shouldn't do it. Steve Kent: IANA is suppeded to be included along w/ RIRs. Answer for LIRs: don't want impose a requirement to verify right to use naame. It's believed that the small set of IANA/RIR does not pose a problem. Randy (off-mike). [23:06] You're certifying those names, therefore? Who'se certifying RIPE's name? Kent: RIPE is. Randy: So I, as an ISP, could certify my name? Kent: If you want to be an island and not be certified by anybody else of course one could do that... Randy: Ah, so you're saying because the RIRs are self-certifying their names, but LIRs can't? I'm confused. Kent: Well, I do have the name of a doctor. Randy: Unfortunately, my insurance is only good in Japan. Although, they gave me travel insurance, but I can't read it -- it's in Japanese. Kent: it's probably only good for getting you back to some other place [further discussion of insurance] Kent: the names for those entities are presumed not to be contentious. And... Randy: If the name for verizon contentious, Jason? Kent: since I worked for them, yes. Randy: but you know what I'm getting at... Kent: ... [24:33; more redacted] Randy: either people are first class citizens or they're not; ... Kent: the rationale was..... ... [25:30] Sandy: What advantage is there for having the RIR's name certified? Kent: I'd say the only advantage is it makes it easier for someone encountering one of those certificates to tell which of the small number ... it's associated with. We could do away with that, also; it's a human factors issue... Sandy: Are other CAs forbidden from using the name that's in the RIR cert? ... Sandy: They're choosing an abitrary string... Kent: no, in most PKI's, a subject proposes the name they want a CA to sign/attest to. This one does not have that property. In this one, the name is assigned by the issuer... to make it easy to match up with their internal databases and in order to avoid liability associated with having to verify someone's assertion about their right to use those names. Avoid turning them into DNS registrars.... Sandy: I understand. So having the RIR named in its cert would.... are other CAs... forbidden to choose one of those set-aside names? Kent: among the ones to get to do that... Randy: I beleive she's asking: am I, as a member of JPNIC, can I ask that my subject name be IIJ? Is that correct? [27:50] Sandy: No, I was asking: I'm IIJ, and I'm issuing certs; am I forbidden to put JPNIC or RIPE or APNIC or whatever in the name field? kent: this allows a CN. If you chose to do that, you'd be, from my perspective, needlessly incurring liablity, but from a mechanical standpoint, the system would still work. ... Sandy: your stated advantage to having APNIC, RIPE, JPNIC in the cert is that people could look at it and say "ah! this is an APNIC cert." If other people might have the ability and right to put those names in the certs that they produce, you can't be certain, looking at the name... Kent: the policy says NOT to do this. I was answering the mechanical question of "could you stuff it in here". the answer is: within those syntactic constraitns, one could, but it would not be consistent with the policy, I believe.w Randy: I'm trying to understand the word "meaningful" up there, in this context. Roque: Steve, is this distinction.. can be moved to the CPS, so each CA can do different things? In our case, if we have to put meaningful inofrmation in the CN, it's difficult to know what's meanginful in the DB.... Kent: was the question "Could you just move this to a CPS?" Roque: yes [30:19] Kent: if we are establishing syntactic constraints overall, then no, that wouldbe bad. This is a slippery slope. ... I'm reluctant to go down that path. Randy: the best way to keep off slippery slopes is don't start on them. [31:00] Rob A: I have a slightly different minor issue, leaving the polictcs out: the current text appears to be recommending that I have stable common name, as opposed to giving me the OPTION ... what if I don't want to have a stable common name? ... I'm not the architecture should be saying that I should have a stable name; that seems a little strong. Matt: sure. Geoff: i should explain the origin of the request from APNIC to the document author. The previous version of the draft precluded any other form of name expression other than this varying CN, and the implementation being done by APNIC wanted a structured namespace where one part was indeed persistent and identifed a database key and the other part varied with rekeying. wehen we put the request in, it became a signle model that said it must go the other way. we didn't ask for that. We just asked for the restriction to be lifted. ... [more freedom] is cool by us; we're not trying to constraint what others may do ... Rob: I'm fine with what I think I just heard Geoff ask for. Matt: the next version of the architecture draft will clarify that text. ... I apologize. The open Q which needs to go to the list are whether RIR/IANA/etc. names should be prescibed as meaningful or whether we should make the blanket statement that names are intended to convey identity. Hopefully we'll get that clarified. Matt: another issue: the current text has an example of how one RIR would delegate resources to another RIR. For ERX or future xfer... this demomstrates how the RIR root certificates; how their trust anchor material need not be reissued to accomodate such a transfer. first Q: is this example helpful? ... #2: whether arch doc or some other doc should clarify the make-before-break principle -- there is some propagation time inherent in issuing new certs, publishing ROAs, relying parties fetching, so it is important that you authorize the new routing before revoking old routing. This came up in discussion of this example. Perhaps the architecture draft or another doc should clarify that this is an important principle here. Terry M: ERX example should be removed in light of the TA draft; I don't see that it has any validity anymore. Matt: Good. One slide on ROAS format draft; it has not been revised, but I'd like to revise it after the meeting. there was a minor issue at last meeting re: overlapping prefixes in a ROA [37:08]. For example, a single ROA could include authorization for 10.0.0.0/8 w/ maxlen 10, ... and 10.1/16, and these would be overlapping. and this is a meanginful authorization. Rob A: if the intent is to allow this, please make it explicit. Matt: currently there is nothing that explicitly permits or denies, so I'm going to ... explicitly permit this type of behavior. Randy: from user point of view, I can obtain the same semantics by issuing two ROAs. Matt: yes. Randy: I would check with implementers whether getting away from canonic 3779 is annoying to you. ..... Rob A: that occuured to me. It is a bit of a pain. The code I wrote years ago tha's in openssl doesn't like this overlap. the reason I didn't make an issue of it is that Robert Kistileki argued me into the groud on this at a previous SIDR meeting and I conceded the point that we needed this because he thought he had a use case. I don't remember.... Matt: my recollection is that you and Randy both expressed concern. Robert, Ruediger, and Mu Huston had all thought that it was a reasonable thing for us to do. Ruediger Volk: from POV of plain users, having such an irregularity that you have to split off ROAs in some cases and not others is pretty unwelcome and come as a bad surprise at some time. In the end, envisioning nice programming systems that procide nice user interfaces, it also could be managed by a user interface layer, but I think for getting the whole thing off the ground, it would be nice to have a smooth, homogenous definition, which means it should be explicit here. [40:52] Randy: it's the same crap in either case; it's just which of us bears it. I'm just trying to understand the tradeoffs. .... I don't know. Ruediger: if Rob does it in the first place, it's going to be there nice and clean for all time and all the users. if it's not done there, we don't know if it actually will happen. Randy: the other way of thinking of it is "if Rob does the formal check, that is it 3770 congruent, then we have a more formal nailing to the floor". .... asks about Kent's/Matt's code... Matt: this actual code is written by another gentleman's who's not here but our code is able to accomodate do to the efforts of Charlie. Randy: so you guys are happy going either way? Matt: yeah. Rob A: I recommend taking this to the list; I think there are people who have opinions who aren't present. (off-microphone discussion) Matt: I would like to get another version of the format draft out. It needs more reviews, but it's about ready for LC. Sandy: in the arch draft, you said certain discussion of uses of ROAs should move to the validation draft? Matt: the validation draft... the scope does describe how one would use ROAs in a transitional period to achieve better routing security than we have today. tere was some overlap in text in the architecture doc. I now say, ... please see roa-validation. Sandy: do you believe that the validation draft adequently covers the topics you removed from the architecture draft, currently? Matt: [inaudible] Sandy: could you look at that? Matt: yes. at a high level, the valdiation draft covers the topics I think it needs to cover. there's a question of do I agree with everything Geoff says in the valdiation draft. I don't want to be signing my name... the scope of the discussion in that draft is appropriate and correct. [44:30] Sandy: names are required to be unique for a particular certification authority. i recall a long discussion of what CA.... when it rekeys, it is removed from the requirement to maintain uniqueness? Matt: the architecture draft is probably not sufficiently clear on this point. the answer is: yes, when the CA rekeys, we do need the uniqueness to persist... Rob A: details of this are very persnickety. as I recall, we are not rekeying a CA. instead we are creating a new CA and destroying an old one. so, strictly speaking, the uniqueness requirement does not persist. technically, because of deep x509 voodoo, we're destrying one and creating one. Kent: ... the rekeying doesn't remove this requirement unless the NAME changes. ... if the result of how we do rekey is that we change name, then it's equivalent. If you rekey w/o changing name, then you still need to be unique. ... Matt: my action item for the next version of the architecture draft is to clarify that name uniqueness is tied to the CA which is the NAME of the CA. we can specifically mention that if rekleying changes the name, uniqueness no longer needs to persist. .... it needs to be said well someone, and I will make sure it is. David Cooper: if you follow X509...names are supposed to be globally unique. kent: but that's not reality, particularly for PKIs that don't require structured names. David Cooper: know of any examples? [48:19 discussion redacted] [51:15] Steve Kent on CP doc [1:00:45] Steve implies that he's using MSWord for writing i-d's [1:01:40] Andrei Robashevsky 1) strip off references to applications (routing security and transfers); stop with validation of claims 2) reasons for revocation may clash with policy or business practices; move it out of this doc 3) terminology of CA may be misinterpreted [1:03:40] Kent: #1 is easy; send details on the rest. Randy agrees with Andrei re: #2 and goes into background re: RIPE meeting [1:06:00] done with CP [1:06:45} Geoff presenting on TA-00 [1:14:09] Q&A; long discussion {1:33:00] process discussion [1:36:15] more process stuff; ask WG re: adoption [1:42:30] someone barks; examples of IANA/ARIN DBs differing [1:49:20] comments from Rob A generate clapping [1:52:50] accusations of theft [1:53:30] Dave Ward, outgoing AD If you're going to include the technology, the last year's and certainly the last hour here's discussion must be clearly written down and discussed. At the mikes and on the email list is not the way to capture this information. If you decide to preclude it, you have your answer: you have one trust anchor. If you decide to include it, you must discuss the pros and cons because we will not decide the layer 9 issues in this working group. ... Please decide whether you're going to preclude an entire scope of engineering from the solution set. [1:55:44] I recommend ... it's almost impossible to preclude a solution set ... I'll leave it to the WG to decide. (unidentified speaker, off-mike) do other PKIs have to justify not having multiple roots? Ward: the pros and cons must be laid out. Q: in other PKIs in the IETF, is this done? ... [1:57:10] discussion of ROAs, BOAs and validation starts Geoff: ... "my assumption ... is that the aim of the sidr work is to allow the identification of bad routing information. Not good; the bad ones." [1:58] Danny McPherson: withdraws support of BOA work. Geoff: but would you agree re: aim of sidr work... Danny: No; I believe that any useful security policy is explicit about what should be permitted and implicit about what should be denied. ... Danny: you're setting me up there, aren't you? Geoff: yeah. Randy: _AN_ aim of the sidr WG. Geoff: minor quibble, but OK. Randy: THE aim, as far as routing information goes, is to be able to validate what is good Geoff: well, no shouted: yes Geoff: we're trying to figure out who's lying Randy: I'm trying to figure out who's telling the truth (discussion of drinking, black & white, truth, etc.) [2:00:00] Geoff presenting [2:04:50] AS0 approach [2:08:00] partial deployment [2:08:30] ROA & ROA set semantics; completeness [2:09:05] partial use; interpretation [2:11:37] Ruediger Volk proposes an interp. [2:14:20] Geoff: that's precisely what this slide says; ... we seem to agree [2:14:30] Rob A: I think I completely agree with the first one here; I do not currently see a need for the second. The second is as inoffensive a way of expressing explicit denial as I can think of -- we get it for free. If the people planning on stuffing this stuff into routers need that, this is aplausible way to do it. i would like to hear from .. whether they want that capability. I'm not currently seeing it, but maybe I'm mssing something [2:15:35] Randy: three things. The AS0 hack was Steve Kent's inner southern Californian trying to get out and make everybody happy. ... Second; the person writing code to put his in his routers keeps looking down at this laptop. ... Thirdly: he does have a draft out there; it speaks to this very issue. grep for pmohpat. Essentially, the first is correct, but... The use case: I'm AT&T, I have 12/8. John signs on as a multihomed customer. I give him 12.1/16. His announcing that will be denied unless either I, since I know he's lazy and he's my customer and paying me, issue the ROA for him ... or he steps up to the bar and publishes it himself. Otherwise, if I have a ROA for 12/8, his annoucement dies. [2:17:40] Geoff: so what's the maxlen of your ROA? ... ... Randy: the specific can be announced by another AS... Russ from Cisco: you now have two overlapping ROAs... Randy off-mike. [2:19:00] Russ: the first paragraph on the slide I'm perfectly happy with ... my only complaint about AS0 is that you're playing with magic numbers. Magic numbers are bad things. Randy: I agree. let's separate the two issues. The common case I have is I am 12/8; I say I am 12/8; I have a roa for 12/8. But I also delegation 12.1/16 to jason; I issue a cert. Russ: what's your max prefix len? Randy: it doesn't matter; there is no maxlen in a cert; I issued a cert to him. Russ: so...if you have overlapping ROAs; you check your cert on the longer prefix ROA, and it valdiates, that's perfectly fine. Your other option is to not issue the ROA ont he whole /8. Randy: no, because then the ROA for what Ihave left starts to looks like chopped parmesean. [2:21:40] Ruediger: ... the AS0 hack lets you document whether you want to be the exclusive source... or whether you leave it open. [2:22:30} Rob: I think Randy is requesting that we stop calling this AS0; as opposed to a magic widget. Randy: re: terminology, syntax v. semantics Geoff: Q: a prefix owner can indeed generate a ROA nominating any AS. What is the semantic, in your view, of a prefix owner creating a ROA with AS 0? Randy: probably shouldn't be allowed. But I'm with Russ White; it's the syntactical issue; I don't like overloading the syntax. Geoff: the semantics and syntax of the second sentence is consistent with the first. ... [2:24:08] Randy: I'd like to argue the semantics separately. Geoff: Where I get confused... Randy: ... [2:25:47] Someone off-mike points out that the text on the slide doesn't parse to the same thing people are saying. Geoff: that's an editing mistake. Assuming that this "unless" bit is irrelevant. ... Randy: I do not buy the "and no more specific"... [2:27:12] Sandy makes a case for use cases. Randy interrupts. [2:28:34] Roque from LACNIC: what's the need for maxlen if you delete...? ... Are we trying to characterize semantics of issuance or what I should do when I receive a ROA? Geoff: both ... [2:31:23] Geoff: right now none of the documents are explicit about what it doesn't say. I produced a BOA that tried to be explicit and folks said that was the wrong thing to do. So we tried to be explicit: when I create a ROA, I mean this. [2:32:11] Randy: I'm willing to work with you on examples, Geoff. Roque. Dave Ward: you need to frame this as a selection algorithm. In the abstract terms you have now, it's hard to understand the results of the algorithm. Geoff: our brains work differently. Dave: it's not what you're saying, it's how you're saying it. .... I propose that in stockholm or on the list, perhaps with a presentation of pradosh's draft, presented as a selection algorithm; let people throw tomatoes. ... Couch it in operational terms. Sandy: I agree, but we also have to give instructions to producers/issuers. [2:35:10] Jason, defining terms. [2:36:30] Randy, off-mike, would Jason be willing to issue ROA on their behalf? Don't know; have to think about. [2:36:50] If I have a /16 and start making subdelegations, i don't want to stat carving up my ROA --- I want to be able to say I own the whole 16; there are more specifics, go use them. That's how routing works, let's make this work the same. Randy: what he said. [2:27:30] Danny: I see Geoff's point about clarifyng text. I think that clarifying this text so that it removes the need for a BOA, if possible, is a very good thing. Kent: confused. Jason: if you've got a chunk of addr space that's been allocated to you and you have big chunks of it that have not been allocated by you to any of your clients, are you saying you want no mechanism whatsoever to be able to distinguish unauthenticated assertions about that advertsiement? (response inaudiable) OK, that's what I thought I heard you said, so I think it needs to be stated mroe clearly. Jason: what I was trying to say was: if I get a /16 and I publish a ROA for that 16 and I start makingg customer assignments out of that, I don't want to be coming back to continually shrink what's unallocated. .... Jason: channeling Heather: she disagrees with my third point: if we have an aggregate and some of our customers are using ROAs and some aren't using ROAs, she thinks that should break. She's more security focused than I am. Roque: you want this to work like routing today... ... Sandy: asking for clarification Geoff answers inaudiably. [2:40:40] Danny agrees with Heather [2:41:13] meeting ends