From nobody Wed Jul 1 16:48:45 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBA31B2C39 for ; Wed, 1 Jul 2015 16:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlSJORyS-E0E for ; Wed, 1 Jul 2015 16:48:42 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E581B2C38 for ; Wed, 1 Jul 2015 16:48:41 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 61AFC28B0041 for ; Wed, 1 Jul 2015 19:48:40 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 5A9681F8035; Wed, 1 Jul 2015 19:48:40 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_C04FAF43-B393-4ADE-A926-C60D3AC71969"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 1 Jul 2015 19:48:39 -0400 Message-Id: <52DDF139-85B2-43AE-8665-0F2AA1346CB4@tislabs.com> To: "sidr@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: Cc: Sandra Murphy Subject: [sidr] agenda topics requested X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 23:48:43 -0000 --Apple-Mail=_C04FAF43-B393-4ADE-A926-C60D3AC71969 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We are rapidly approaching Prague IETF. It is time to suggest discussion topics, offer discussion structure, and = request agenda topics. Please send suggestions, offers, and requests to the list. Draft = agendas are due soon. FCFS. --Sandy --Apple-Mail=_C04FAF43-B393-4ADE-A926-C60D3AC71969 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVlHxYAAoJEHplpQeet0IZ2NIQAIB9qmOQYWNq4oGpzFA7+0/N 6HLhBla4eCrc5BBJPzaop2j7lMFbcaZBYnPbw2tq7AUAnHoY4wq0B2Mdy3IMck2Q BOipkwei/IZBs9ticZZ1XWIIfMU8o7+mOgtsQ2Qzbty9R6kU3lszeziJtOmIIHWR tXpSfRuNRRzvmSNLgjIN2d1pV0Jywcdtp0P8Pl3yxrl4Xp+CJEJ30ZQ81kqEfhLI rxAEYBWG+aP8ZcCoQcRpZo151w9ejMp7pWKNwKfsfLS08wdV9axtthrDIvLATRNI 5nQkAZ+iXOTqgLL+bV4AUyu5dysAAlOZH9ULnkKmFrCmDSX2pcx2/JD+POjHOn0W wArwp60RFDTdHVJTmdjKfqBbd+nQ2NL6FhNxQfzbz99Yx3JfLJeI2/wNc8HsqNDw fEEldGCT+Gn5xoNvF5/8/MRnAxJqHaGmGzbcbxwbHqEDAdfdQzkxPxnE3JktnMCT O73+JZ/hffI6mkclVBGeNfa26hQaZLUeH2HPhYS1vwisAXyhhPcRnACqwhahYZ+j +8TDCmBitZJi8vaK1K9owQobpweZ+BZU6w9/rRV64mE6cB6jMk9xx+Chy4Ef6mHi G97Q+M3oo5Rf0Y8+y6SW65IGuhGDJl6QQnQ4+MA9HAJU9P+3cKfhBByKv6UrMEku dPkxdjE6DoVMm+GvTJC/ =+HNn -----END PGP SIGNATURE----- --Apple-Mail=_C04FAF43-B393-4ADE-A926-C60D3AC71969-- From nobody Thu Jul 2 17:15:36 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BA11ACED4; Thu, 2 Jul 2015 17:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTPv6UQ2RkyU; Thu, 2 Jul 2015 17:15:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3919B1ACED0; Thu, 2 Jul 2015 17:15:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150703001534.21723.87491.idtracker@ietfa.amsl.com> Date: Thu, 02 Jul 2015 17:15:34 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 00:15:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : BGPsec Operational Considerations Author : Randy Bush Filename : draft-ietf-sidr-bgpsec-ops-06.txt Pages : 8 Date : 2015-07-02 Abstract: Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present the most critical and universal. It is expected to evolve as BGPsec is formalized and initially deployed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-ops-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 3 03:39:17 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57FD1B2CCF for ; Fri, 3 Jul 2015 03:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7EmmZUehDWc for ; Fri, 3 Jul 2015 03:39:07 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BD9C1B2CC9 for ; Fri, 3 Jul 2015 03:39:07 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 6865028B0041; Fri, 3 Jul 2015 06:39:06 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id C69EC1F8035; Fri, 3 Jul 2015 06:39:05 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_E075AF0F-C647-4EF8-AA87-9601B7B0B0DE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: <555E5E4A.5080303@bbn.com> Date: Fri, 3 Jul 2015 06:39:05 -0400 Message-Id: References: <20150515192215.5707.56279.idtracker@ietfa.amsl.com> <555CE890.1090802@bbn.com> <462B3352-DAA9-476C-AA33-C517C515B7F0@tislabs.com> <555E5E4A.5080303@bbn.com> To: Richard Hansen X-Mailer: Apple Mail (2.1510) Archived-At: Cc: sidr@ietf.org, Sandra Murphy Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rfc6485bis-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 10:39:11 -0000 --Apple-Mail=_E075AF0F-C647-4EF8-AA87-9601B7B0B0DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Speaking as regular ol' member On May 21, 2015, at 6:38 PM, Richard Hansen wrote: > On 2015-05-21 17:08, Sandra Murphy wrote: >> On May 20, 2015, at 4:03 PM, Richard Hansen wrote: >>> * section 8 is incorrect -- sha256WithRSAEncryption does not >>> violate the CMS RFCs (implementations just choose to use >>> rsaEncryption instead, which has the same meaning in this >>> context) >>=20 > [...] >>=20 >> Perhaps you are concerned mostly about the terms being used? But the >> rfc6485bis document does not say "violate" and I believe that what it >> says agrees with the message above. If you don't think so, you >> should say why. >=20 > This draft's Section 8 says: >=20 > [...] A closer reading of > [RFC4055] and [RFC5754] has identified that the CMS SignerInfo field > must support use of the rsaEncryption OID for full conformance with > the CMS specifications, and the normative references in [RFC6485] > inherited this requirement. >=20 > The phrase "the CMS SignerInfo field must support use of the > rsaEncryption OID" doesn't make much sense to me -- how can an OID = field > not support an OID? I'm not 100% sure what is meant here, but the = next > paragraph provides a hint: >=20 > [...] By conforming to the > CMS specifications as per [RFC4055] and [RFC5754], RPKI CMS objects > are less likely to be rejected as non-conformant with the CMS > standards. >=20 > To me, this sentence and the one above are claiming that the CMS RFCs > say that the SignerInfo signatureAlgorithm field MUST contain > rsaEncryption, and that we are non-conformant (violating the spec) by > using sha256WithRSAEncryption. Neither is true. You and I disagree here. To be clear: our disagreement is whether the description of the = motivation for the change to RFC6485 is ambiguous or not. Personally, I do not consider that an important matter. The description = of the motivation does not change the specification, it does not change = implementation, and it does not confuse implementors about = implementation. To recap: RFC6485 chose to mandate an algorithm id. That choice is compliant with the CMS RFCs. The CMS RFCs make a choice of a mandatory to implement algorithm ID. RFC6485's choice is not the CMS mandatory to implement choice. Unfortunately, common CMS implementations chose to support only the CMS = mandatory to implement algorithm ID. So common CMS implementations can not be compliant with RFC6485. By aligning our choice of mandatory algorithm ID with the mandatory = algorithm in the CMS RFCs, we make it possible for common CMS = implementations to be compliant with RFC6485. By aligning our choice of mandatory algorithm ID with the mandatory = algorithm in the CMS RFCs, we eliminate the problem that a compliant = RPKI signed object would be rejected by the common CMS implementations. wrt: >=20 > [...] By conforming to the > CMS specifications as per [RFC4055] and [RFC5754], RPKI CMS objects > are less likely to be rejected as non-conformant with the CMS > standards. Perhaps you are reading too much into the use of "conforming to"? = Perhaps saying "aligning with" would make it more clear to you? I do not know what current CMS implementations would do if they were = presented with a RFC6485 compliant RPKI signed object. They may indeed = report the signed object is "non-conformant with the CMS standards". = So I can not say that "rejected as non-conformant with the CMS = standards" is incorrect. Error message aside, it is clear that any = RFC6485 compliant RPKI signed object (if we could find one) would be = rejected by existing implementations. There might be ways to improve = that "rejected as non-conformant" phrase of the text, but I don't think = it is necessarily wrong. > =46rom a CMS RFC conformance perspective it's perfectly OK > for RFC6485 to require RPKI CMS object producers to use > sha256WithRSAEncryption, but third party crypto libs didn't make it = easy > for implementations to conform.=20 My reading of the previous discussions is that it is worse than "didn't = make it easy" - the crypto libs made it *impossible* for = implementations to be compliant with RFC6485 - they did not implement = support for the algorithm RF6485 mandated. >=20 >> It is found in 3370, which 5754 (one of the references) updates and >> normatively references. >=20 > I don't think that is sufficient in this case. There are multiple = RFCs > that this document directly and indirectly references that define an > algorithm identifier named rsaEncryption. I believe they all have the > same OID value, but some of them give slightly different semantics. Really? I think that would be a very bad thing! But not our problem, I = think. > Thus, I think it's important to make it clear which definition of > rsaEncryption is intended. >=20 > For example, RFC3370 (for CMS) says that rsaEncryption is either a key > type identifier or a signature algorithm identifier, while RFC3279 = (for > PKIX) says that it's only a key type identifier and thus not suitable > for identifying signature algorithms in a PKIX context (you must use > xxxWithRSAEncryption instead to specify the digest). I think your "and thus not suitable" is a bit of a stretch. And it = would appear that the existing implementations we are talking about did = not make this same interpretation - we are in this mess because they use = rsaEncryption as a signature algorithm identifier. Again, speaking as a regular ol' member. --Sandy --Apple-Mail=_E075AF0F-C647-4EF8-AA87-9601B7B0B0DE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVlmZJAAoJEHplpQeet0IZ70UP/1IoL9cBzTEK1eAnUCvYdUNj aj9kZcnlmvMSVOo7mnl0uglyw/BHjsdA9A+0Zh4AUDKVbZ4FY3aZaExyR7h77cN/ xqPnEH2MnbeKDuKISzDX2mrANTebeKJI2hji5yY4TJjozZNrhHWWnbF8p3lo1t6Y DYmrODgZ1y9VY/js9/OsQLMkGTs9LaKuwluGrom5yNh+4pfy3x7gzReiu/ZNyvNj x4llqEk9kAGWTZDfFdhmAOLF8SR1vNkSVTP1R6Tqvd7wXy0zEJ/B0I5b5fVbzQ5E Ko2N5myT6R0/Pj4i0n0qxY/ZALLb4hL3aJi+8ONsHAedzSc0bsOI0eC/Zr2GepK8 A9ySlSuLd4CBCDCEtx6UZQ8FAoFBxUdKbwRcTs/7z8GQCXfodYF/dRvnrhsvwxsA 4Wy5po8ijx5H9tm+dZRxPWD7s+yHIYIYdCwjynJWsSva+0ATNVhHUBiLoyGOy50q uY9q1KLLEMOkYOYXfde3916UgS+NRzQxXZATI1l3qTMHw7ounmHGYFVjkatX0OA8 RHZav94R+rl4SwIK3Q4guRcBiMwGrEk4meftwLJtsOVgn3/aq6jkqzLwaLRj434a XD+ENjV4RkO1o8SE2Fk1s3wKz9xF7knpyY/8Ns0L6TaUVLz4BctB2V5t+DzFMFB0 WHq8m68RPXeV6ohUEisM =KVFG -----END PGP SIGNATURE----- --Apple-Mail=_E075AF0F-C647-4EF8-AA87-9601B7B0B0DE-- From nobody Sun Jul 5 08:19:39 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F423B1A8BAF for ; Sun, 5 Jul 2015 08:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixaHSEYePjVU for ; Sun, 5 Jul 2015 08:19:35 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5F71A8AFC for ; Sun, 5 Jul 2015 08:19:35 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 04F4D28B0041; Sun, 5 Jul 2015 11:19:35 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 692DA1F8035; Sun, 5 Jul 2015 11:19:34 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_89D6E665-D6FD-4E4E-BD74-F83107D5AEFF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: Date: Sun, 5 Jul 2015 11:19:33 -0400 Message-Id: <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> References: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> <556CF530.4010408@ops-netman.net> To: "sidr@ietf.org list" X-Mailer: Apple Mail (2.1510) Archived-At: Cc: Chris Morrow , "sidr-chairs@tools.ietf.org Chairs" , Sandra Murphy Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 15:19:37 -0000 --Apple-Mail=_89D6E665-D6FD-4E4E-BD74-F83107D5AEFF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In November last year, a more detailed description of transfer was = suggested as a means to move ahead with the validation-reconsidered = discussion. This draft is such a more detailed description. (http://tools.ietf.org/agenda/91/slides/slides-91-sidr-0.pdf is you = can't remember that far back.) But there have been very few comments on this draft. The hope is that = this will give the wg the grounds for an informed opinion on "the need = to alter the RPKI validation process along the lines of the 'validation = reconsidered' draft", to quote the presentation. Please, please, please. Start discussion now. Is this accurate from the standpoint of transfer activities? from the = standpoint of RPKI actions? And the further question - does this help you to understand the = validation reconsidered algorithm? --Sandy, speaking as wg co-chair On Jun 1, 2015, at 8:16 PM, Randy Bush wrote: >> Title: Resource Transfer in the Resource Public Key Infrastructure >=20 > this is a very rough first draft. all folk who agreed to author have > not even reviewed. i published partly to get them to wake up and tell > me how broken my understanding is. >=20 > randy --Apple-Mail=_89D6E665-D6FD-4E4E-BD74-F83107D5AEFF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVmUsFAAoJEHplpQeet0IZNDcP+wZ/gKI+Eht0omYgqQEK2Kxr 6BmzuBBNJee78B8jYRFuZ+ROyeN63cnHdwQsYzRh63PwaGIiomT+NGOJQlfCDBHk HXix051LSpTs30h9dmKL5E8nXys7aWEpbWGGeS8AjBNLY293giIoVwjc7qgFzbut /xndQIew3rOUMVUNW+9jQwNczquIraBcDOb/PJUm4nWIDIDeflNjgSUPDZ+RsS1t fSOSBjDUvUxC4PUQ0qtsjlxO0BG1TH8tJXUBetfDPkEPFccfmzc1iNpkAvtshISh i9rKd5cmSfs02B4WPYXW9jxXcswxso+g6hB8F8p8l9p3PDzSdemlOqKFums9X33c WKz9tnsZCfUwUeqHPjRnmyESBgubf+dbzx7uHh3cJjlQa+eel8C93toq3wvpQ7Dh th8tLPRLAxjqY8lA0f4rHldAtPeZz/Ooi+JN05DrmP9YnseQ8tJNPfoOjnM2fbMh KUSlahAfoSyz5mrVbOwVobcdi8fU5Mmpq0aG7fZShUPRxIqterCiY6LwxltHUe3s K4iiisLjd6MnmKAKsmNGlR7PLQRkXludpqeun1PYHeA6zEz+YPZrttgiWstecAIG xcxbKEfPOxNmv71iK5SmWrJKd12AuoswlSLj1MwQTL4ScZLG4X4owH0Eca/tN/iH w/O+WqTmE1rMDbbRTPwX =e1wO -----END PGP SIGNATURE----- --Apple-Mail=_89D6E665-D6FD-4E4E-BD74-F83107D5AEFF-- From nobody Mon Jul 6 05:47:34 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CB51ACEC5; Mon, 6 Jul 2015 05:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4kBb7AjPt6X; Mon, 6 Jul 2015 05:47:29 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0754.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::754]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10DFF1AD355; Mon, 6 Jul 2015 05:47:28 -0700 (PDT) Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by BLUPR09MB007.namprd09.prod.outlook.com (10.255.211.150) with Microsoft SMTP Server (TLS) id 15.1.213.10; Mon, 6 Jul 2015 12:47:12 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0207.004; Mon, 6 Jul 2015 12:47:12 +0000 From: "Sriram, Kotikalapudi" To: "sidr@ietf.org" , GROW WG Thread-Topic: updated route leaks drafts Thread-Index: AQHQt+WoFw0LQo2Ow0yBikApURO1rQ== Date: Mon, 6 Jul 2015 12:47:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nist.gov; dkim=none (message not signed) header.d=none; x-originating-ip: [129.6.223.194] x-microsoft-exchange-diagnostics: 1; BLUPR09MB007; 5:5EQ1/gTClbzpBO+W+QlNuC/S2HEzXnk9IZLGMoeXkHzl6D3AMHMf8BtVTzKTZlh8msw9pmHRFHrSyc3391zX9OBp4RYFPJPTHfqSjP5Q/DYAqfb9RLbDgZ7PIfEwffa/Rx0TMnQlY6jSccg0HA8sUQ==; 24:KT5blJFKkxUzDPFqf0bu0Ak1M8Q9gHdqTykY2xpOq8KtUvro3DD628+N7ivTBZyHoSR/hEo3SNmwBzww9BWDMiqaGFC+bTTcuMtHYt8Xwmk=; 20:FqEKp+mqMXGh5Lv/qjldqq2R26djH6xhcgrpiHxs8+D7urrE8J8WYWB/AW/6bORNjlMF5VNMEaYN/GgTve10ng== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR09MB007; blupr09mb007: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR09MB007; BCL:0; PCL:0; RULEID:; SRVR:BLUPR09MB007; x-forefront-prvs: 06290ECA9D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(66066001)(2501003)(86362001)(62966003)(2656002)(77156002)(87936001)(46102003)(5002640100001)(5001770100001)(40100003)(92566002)(76576001)(102836002)(15975445007)(77096005)(2420400003)(122556002)(2900100001)(229853001)(7110500001)(5001960100002)(74316001)(107886002)(50986999)(19580395003)(106116001)(189998001)(54356999)(5003600100002)(33656002)(140573001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR09MB007; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2015 12:47:12.0936 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR09MB007 Archived-At: Subject: [sidr] updated route leaks drafts X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 12:47:31 -0000 I know many people on the SIDR and GROW lists also follow IDR. But just in case you haven't already noticed, we (the authors) have submitted a substantially updated -01 version=20 of the route leaks solution draft in IDR: https://www.ietf.org/internet-drafts/draft-sriram-idr-route-leak-detection-= mitigation-01.txt=20 =20 WG adoption call request for this work is in progress in the IDR WG -- (6/2= 5 to 7/9/2015): =20 http://www.ietf.org/mail-archive/web/idr/current/msg14550.html=20 You may like to review the document and the discussion taking place on the = IDR list. Also, comments in response to the call or about the draft in general would = be helpful. There is also an updated version (-02) of the GROW WG draft on route leaks = definition: https://tools.ietf.org/html/draft-ietf-grow-route-leak-problem-definition-0= 2=20 Sriram = From nobody Mon Jul 6 07:05:41 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97AEE1A8820 for ; Mon, 6 Jul 2015 07:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHouKWZxPLlK for ; Mon, 6 Jul 2015 07:05:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CB311A87DB for ; Mon, 6 Jul 2015 07:05:38 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:58420 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZC71d-000Bp2-GQ for sidr@ietf.org; Mon, 06 Jul 2015 10:05:37 -0400 Message-ID: <559A8B31.50408@bbn.com> Date: Mon, 06 Jul 2015 10:05:37 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: sidr@ietf.org References: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> <556CF530.4010408@ops-netman.net> <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> In-Reply-To: <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 14:05:40 -0000 Three observations: - the briefing you cited was a high level discussion that did not make a strong case for the validation revisited I-D. - I submitted comments on the list about Randy's transfer I-D. - draft-kent-sidr-adverse-actions-00 documents a range of potential problems that can arise in the RPKI. The analysis argues for a broader solution that would encompass the overclaiming problem. Steve From nobody Mon Jul 6 07:44:27 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CB11B29F1 for ; Mon, 6 Jul 2015 07:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adBrGc9YQ3Tq for ; Mon, 6 Jul 2015 07:44:24 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6C521A88CF for ; Mon, 6 Jul 2015 07:44:24 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:58509 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZC7d9-000CqL-AD for sidr@ietf.org; Mon, 06 Jul 2015 10:44:23 -0400 Message-ID: <559A9446.6040400@bbn.com> Date: Mon, 06 Jul 2015 10:44:22 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: sidr@ietf.org References: <20150515192215.5707.56279.idtracker@ietfa.amsl.com> <555CE890.1090802@bbn.com> <462B3352-DAA9-476C-AA33-C517C515B7F0@tislabs.com> <555E5E4A.5080303@bbn.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rfc6485bis-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 14:44:26 -0000 Sandy, > Perhaps you are reading too much into the use of "conforming to"? > Perhaps saying "aligning with" would make it more clear to you? I do > not know what current CMS implementations would do if they were > presented with a RFC6485 compliant RPKI signed object. They may indeed > report the signed object is "non-conformant with the CMS standards". > So I can not say that "rejected as non-conformant with the CMS > standards" is incorrect. Error message aside, it is clear that any > RFC6485 compliant RPKI signed object (if we could find one) would be > rejected by existing implementations. There might be ways to improve > that "rejected as non-conformant" phrase of the text, but I don't > think it is necessarily wrong. you and I disagree here ;-). Conforming, in my mind, implies that we use the same syntax, validity checks, same alg requirements, etc. What we need to say is that we profile the CMS spec, deviating only with respect to the MTI algorithm. Using a phrase like "aligning with" seems needlessly ambiguous. >> Thus, I think it's important to make it clear which definition of >> rsaEncryption is intended. >> >> For example, RFC3370 (for CMS) says that rsaEncryption is either a key >> type identifier or a signature algorithm identifier, while RFC3279 (for >> PKIX) says that it's only a key type identifier and thus not suitable >> for identifying signature algorithms in a PKIX context (you must use >> xxxWithRSAEncryption instead to specify the digest). To avoid potential confusion we need to avoid ambiguity in specifying alg identifiers. RFC 3280 didn't resolve this particular ambiguity for PKIX, nor did 3370. However, this ambiguity was later addressed in RFC 4055 and RFC 5756. We should figure out which RSA-based signature alg we're mandating, and then cite the relevant, recent RFC. Steve From nobody Mon Jul 6 16:21:58 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1473D1A00FD; Mon, 6 Jul 2015 16:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60VWOO0gbTw3; Mon, 6 Jul 2015 16:21:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF0E1A1A4E; Mon, 6 Jul 2015 16:21:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706232153.18254.71659.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 16:21:53 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-13.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 23:21:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : BGPsec Protocol Specification Author : Matthew Lepinski Filename : draft-ietf-sidr-bgpsec-protocol-13.txt Pages : 39 Date : 2015-07-06 Abstract: This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of autonomous systems through which a BGP update message passes. BGPsec is implemented via a new optional non-transitive BGP path attribute that carries a digital signature produced by each autonomous system that propagates the update message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-protocol-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 16:26:16 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB461A1AD9 for ; Mon, 6 Jul 2015 16:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JseS_LX0xzO for ; Mon, 6 Jul 2015 16:26:12 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61BC61A1B07 for ; Mon, 6 Jul 2015 16:26:12 -0700 (PDT) Received: by oiyy130 with SMTP id y130so129508851oiy.0 for ; Mon, 06 Jul 2015 16:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=czCsfGTgkpRCW3DWpLDdVIjm9XZO8I/EwzZaUGbNKEE=; b=bqN1fj71ZPtTRY2XmNp8zgfpSm/aOT3Q6AlNNOXejjAbA0Da0qsKttRrBk0bGh/fP5 xgEEaLdBP/R3iwIUK58GI50Gm4Gd/Z9bGUpQgzQZE+I1dQANUjgHQMQEtfCoJuVwGthq nXheaN9YDpB50Xr0RuqMLw5NEobaLVlHnyWmGB39DZV5h0CgbmwGllHlvKc9NZwnppqZ OyIqn5eXM4p4UdtPfFPsQ1WMNvjbli4BOHCt/lUNt97F6bLkiV4hnxkHLzJ2ikbn7VDr s7RWgFVnQJRJYUbtKXEAiQXN8HQaE4//Yvcj1tFwx+Y2KxzUO76dcKUPA/MGzVMwlcTs JO1g== MIME-Version: 1.0 X-Received: by 10.60.78.104 with SMTP id a8mr1141605oex.58.1436225171773; Mon, 06 Jul 2015 16:26:11 -0700 (PDT) Received: by 10.202.171.207 with HTTP; Mon, 6 Jul 2015 16:26:11 -0700 (PDT) In-Reply-To: <478403baff907c873e474e5e9b447fac@mail.mandelberg.org> References: <37419C49-1FAC-44CD-A650-924BBF43A5C4@tislabs.com> <478403baff907c873e474e5e9b447fac@mail.mandelberg.org> Date: Mon, 6 Jul 2015 19:26:11 -0400 Message-ID: From: Matthew Lepinski To: David Mandelberg Content-Type: multipart/alternative; boundary=089e0111b78e2e619d051a3d3be2 Archived-At: Cc: "sidr@ietf.org" Subject: Re: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 23:26:14 -0000 --089e0111b78e2e619d051a3d3be2 Content-Type: text/plain; charset=UTF-8 David, Thanks a lot for raising this issue. Based on the discussion in Dallas, I was hoping that we could just go with the clean approach of including the MP_REACH_NLRI attribute in the signature. As you correctly point out, we can't sign MP_REACH_NLRI, because the "Network Address of Next Hop" field within MP_REACH_NLRI changes as an update message propagates through network. (I.e., if we sign what the -12 draft says we should sign, verification will often fail.) I have just submitted a -13 version of the document that pulls out the fields from MP_REACH_NRLI which aren't changed in transit (and thus can be safely signed). - Matt Lepinski On Mon, Jun 22, 2015 at 9:21 PM, David Mandelberg wrote: > On 2015-06-19 14:00, Sandra Murphy wrote: > >> Anyone who commented on draft-ietf-sidr-bgpsec-protocol-11.txt is >> encouraged to review this version and report if your comments have or >> have not been addressed. >> > > My comments have been addressed, but I have some questions about the way > one of them was addressed: > > Is the MP_REACH_NLRI encoded with or without the attribute flags and type > code? > > Don't the values of MP_REACH_NLRI's "Length of Next Hop Network Address" > and "Network Address of Next Hop" change with each hop, making it > infeasible for remote ASes to verify the origin's signature? > > MP_REACH_NLRI has a reserved field that "MUST be set to 0, and SHOULD be > ignored upon receipt". If a BGPsec speaker receives an update where > reserved is non-zero, what should it do? With the current text, I could > interpret "SHOULD be ignored upon receipt" as meaning either "calculate the > signature using the reserved field as received" or "calculate the signature > using all zeroes in place of the reserved field". > > -- > David Eric Mandelberg / dseomn > http://david.mandelberg.org/ > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --089e0111b78e2e619d051a3d3be2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
David,

Thanks a lot for raising this is= sue.

Based on the discussion in Dallas, I was hopi= ng that we could just go with the clean approach of including the MP_REACH_= NLRI attribute in the signature.=C2=A0

As you corr= ectly point out, we can't sign MP_REACH_NLRI, because the "Network= Address of Next Hop" field within MP_REACH_NLRI changes as an update = message propagates through network. (I.e., if we sign what the -12 draft sa= ys we should sign, verification will often fail.)

= I have just submitted a -13 version of the document that pulls out the fiel= ds from MP_REACH_NRLI which aren't changed in transit (and thus can be = safely signed).

- Matt Lepinski

On Mon, Jun 22, 2015 at = 9:21 PM, David Mandelberg <david@mandelberg.org> wrote:
On 2015-06-19 14:00, Sand= ra Murphy wrote:
Anyone who commented on=C2=A0 draft-ietf-sidr-bgpsec-protocol-11.txt is
encouraged to review this version and report if your comments have or
have not been addressed.

 My comments have been addressed, but I have some questions about the way on= e of them was addressed:

Is the MP_REACH_NLRI encoded with or without the attribute flags and type c= ode?

Don't the values of MP_REACH_NLRI's "Length of Next Hop Networ= k Address" and "Network Address of Next Hop" change with eac= h hop, making it infeasible for remote ASes to verify the origin's sign= ature?

MP_REACH_NLRI has a reserved field that "MUST be set to 0, and SHOULD = be ignored upon receipt". If a BGPsec speaker receives an update where= reserved is non-zero, what should it do? With the current text, I could in= terpret "SHOULD be ignored upon receipt" as meaning either "= calculate the signature using the reserved field as received" or "= ;calculate the signature using all zeroes in place of the reserved field&qu= ot;.

--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/


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

--089e0111b78e2e619d051a3d3be2-- From nobody Mon Jul 6 16:33:50 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE561A1B2D; Mon, 6 Jul 2015 16:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCNQh_cxEK2o; Mon, 6 Jul 2015 16:33:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 564971A1B56; Mon, 6 Jul 2015 16:33:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706233343.25843.40172.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 16:33:43 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-rollover-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 23:33:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : BGPsec Router Certificate Rollover Authors : Roque Gagliano Keyur Patel Brian Weis Filename : draft-ietf-sidr-bgpsec-rollover-04.txt Pages : 15 Date : 2015-07-06 Abstract: BGPsec will need to address the impact from regular and emergency rollover processes for the BGPsec End-Entity (EE) certificates that will be performed by Certificate Authorities (CAs) participating at the Resource Public Key Infrastructure (RPKI). Rollovers of BGPsec EE certificates must be carefully managed in order to synchronize distribution of router public keys and the usage of those pubic keys by BGPsec routers. This document provides general recommendations for that process, as well as describing reasons why the rollover of BGPsec EE certificates might be necessary. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-rollover/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-rollover-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 16:40:09 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F681A1AD9 for ; Mon, 6 Jul 2015 16:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoGBNsTf0t9D for ; Mon, 6 Jul 2015 16:40:07 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF3E1A1ABE for ; Mon, 6 Jul 2015 16:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2461; q=dns/txt; s=iport; t=1436226000; x=1437435600; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=cex04R4s+5oSMl7+VKO7wWZsxzOV0NQtwMLsXhHGcBg=; b=CBAsGeZuoJWMMIj0pzR+2t5tx+jQoFb3+1cQngdsgSTh4B1v1LIKRrss 90DxB943CU5k9bF6kIh0+XzaTm4tIXway90mj76Ucb3kNbGoXn3kOrIEP F8OCC3OyIgFfBqQlsPt3DsiBn0CrDf264+EnYRxfyZzQC6qdhC/u8MOHG U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C+AwA4EZtV/5BdJa1ZA4MSVGAGvVcJgWQKhXcCgUA4FAEBAQEBAQGBCoQkAQEDAQEBAWsbAgEIRicLJQIEE4gmCA3LHQEBAQEBAQEBAQEBAQEBAQEBAQEBAReLS4QjEQEeIxcRgwaBFAWUFQGEYYJZhC2BOkSDUZMHJoN7b4ENOoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,418,1432598400"; d="scan'208";a="166075241" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP; 06 Jul 2015 23:39:59 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t66Ndxsm014378 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 6 Jul 2015 23:39:59 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.109]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Mon, 6 Jul 2015 18:39:59 -0500 From: "Brian Weis (bew)" To: "sidr@ietf.org" Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-bgpsec-rollover-04.txt Thread-Index: AQHQuEURJ31FzXYe6k6JxX0u9bhIug== Date: Mon, 6 Jul 2015 23:39:58 +0000 Message-ID: <6EDCAD9D-900C-4F88-946E-CAA8AA6971FA@cisco.com> References: <20150706233343.25843.40172.idtracker@ietfa.amsl.com> In-Reply-To: <20150706233343.25843.40172.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.49.74] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-rollover-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 23:40:08 -0000 This version addresses comments provided during the Dallas meeting, and man= y helpful suggestions by Steve Kent that had been sent to the list. The doc= ument can=92t progress until some of the referenced documents are finalized= . In the meantime the authors do welcome additional comments. Thanks, Brian =20 On Jul 6, 2015, at 4:33 PM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Secure Inter-Domain Routing Working Grou= p of the IETF. >=20 > Title : BGPsec Router Certificate Rollover > Authors : Roque Gagliano > Keyur Patel > Brian Weis > Filename : draft-ietf-sidr-bgpsec-rollover-04.txt > Pages : 15 > Date : 2015-07-06 >=20 > Abstract: > BGPsec will need to address the impact from regular and emergency > rollover processes for the BGPsec End-Entity (EE) certificates that > will be performed by Certificate Authorities (CAs) participating at > the Resource Public Key Infrastructure (RPKI). Rollovers of BGPsec > EE certificates must be carefully managed in order to synchronize > distribution of router public keys and the usage of those pubic keys > by BGPsec routers. This document provides general recommendations > for that process, as well as describing reasons why the rollover of > BGPsec EE certificates might be necessary. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-rollover/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-rollover-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --=20 Brian Weis Security, CSG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From nobody Mon Jul 6 16:54:52 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50161A1BBE for ; Mon, 6 Jul 2015 16:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6jbLdRr7D3Y for ; Mon, 6 Jul 2015 16:54:49 -0700 (PDT) Received: from nm22-vm1.access.bullet.mail.bf1.yahoo.com (nm22-vm1.access.bullet.mail.bf1.yahoo.com [216.109.115.144]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2928C1A1BDA for ; Mon, 6 Jul 2015 16:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1436226888; bh=33mVvRT0brwcd24DoSHeAUt5v5+iESf19auieA69xLA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From:Subject; b=e37Wi48e48QNIUqCb64+R732Lu4te/pvNqDwlMXcar2SWLZAGeuQ716U2dC4TkbwTsR2eXx6Pnq15UmdzKXYJsWF/JNEM6tu4EfMa9I1dEpx+uHE32/TeFd1LHLN8pLat2aMag7qxiL8czJ/9kKgGIbw5nG2qTz23n3WBJQwb/+jgfXfOvG6Y+jBIy96hmpnkxnGQL8qezG0/MR0AmvY234RDTgJa039ZQ2fvRiIAND0+fo1+3PgIt0tDMLDYepGs8vmR7MqKTeSugKQEqH1pRRIydIB7fHPa3ccww7DJxtr/JKa/EYTsdGe2BdAMDTaV93fPomYxoYqDrYrusmllg== Received: from [66.196.81.156] by nm22.access.bullet.mail.bf1.yahoo.com with NNFMP; 06 Jul 2015 23:54:48 -0000 Received: from [98.138.226.243] by tm2.access.bullet.mail.bf1.yahoo.com with NNFMP; 06 Jul 2015 23:54:48 -0000 Received: from [127.0.0.1] by smtp114.sbc.mail.ne1.yahoo.com with NNFMP; 06 Jul 2015 23:54:48 -0000 X-Yahoo-Newman-Id: 277611.85077.bm@smtp114.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: zWf4Tu4VM1kt.r7iSdb6CxCZEVDPUSMHjF_pKnuL91wgx4p A6x3cfVIT3F4CR5kU9S5q_rhUVS7i02b7ZaE5Rlbj5RVjsOc.r1kYcGJbrjD DrHSCT8OL9vogUEiiLLu81dnEI9O1fUzNawPB3QbDJUwhLYvz5igHqCouJ7B fnbPiSu4VCNKUWwUhvgnJ2ulOGP0m8RTQ9sZVnSIRzq1Q1CVyPIAIP5e08e8 3Na53D1zfuXsi0yqt2e72jwofTCoG3Z8_mm_1cn7ngRT31psDxjNRS1eZht8 IiMkIJ0gtEXadu9JfcGTUQbEGnF56CJk.9UtgRBmThca3y73QMl1k3fhRmDb K2w_B0ycrbLRMgOMD1tmxKmcL0lOKL03Jm8o3OmuRhHubqTMJdOBd2voYACc tPVuTKdYx_b5O7O7NmOlb3drvzAcPbadc9Mp7287IS.AL7Nk6YERov.lDKBC VuRydtx9VZh90G92XtrU__zOSTmSGe9dSDKe2YHNeFmLyHQWF.wpofBZikbM bOh8g16gVHi4tl_NieD775ZtCnUg- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 506081C6095; Mon, 6 Jul 2015 19:54:46 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Date: Mon, 06 Jul 2015 19:54:46 -0400 From: David Mandelberg To: Matthew Lepinski In-Reply-To: References: <37419C49-1FAC-44CD-A650-924BBF43A5C4@tislabs.com> <478403baff907c873e474e5e9b447fac@mail.mandelberg.org> Message-ID: X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 23:54:51 -0000 The -13 revision addresses all of my questions, thanks. On 2015-07-06 19:26, Matthew Lepinski wrote: > David, > > Thanks a lot for raising this issue. > > Based on the discussion in Dallas, I was hoping that we could just go > with the clean approach of including the MP_REACH_NLRI attribute in > the signature.=C2=A0 > > As you correctly point out, we cant sign MP_REACH_NLRI, because the > "Network Address of Next Hop" field within MP_REACH_NLRI changes as=20 > an > update message propagates through network. (I.e., if we sign what the > -12 draft says we should sign, verification will often fail.) > > I have just submitted a -13 version of the document that pulls out=20 > the > fields from MP_REACH_NRLI which arent changed in transit (and thus=20 > can > be safely signed). > > - Matt Lepinski > > On Mon, Jun 22, 2015 at 9:21 PM, David Mandelberg > wrote: > >> On 2015-06-19 14:00, Sandra Murphy wrote: >> >>> Anyone who commented on=C2=A0 draft-ietf-sidr-bgpsec-protocol-11.txt >>> is >>> encouraged to review this version and report if your comments >>> have or >>> have not been addressed. >> >> My comments have been addressed, but I have some questions about >> the way one of them was addressed: >> >> Is the MP_REACH_NLRI encoded with or without the attribute flags >> and type code? >> >> Dont the values of MP_REACH_NLRIs "Length of Next Hop Network >> Address" and "Network Address of Next Hop" change with each hop, >> making it infeasible for remote ASes to verify the origins >> signature? >> >> MP_REACH_NLRI has a reserved field that "MUST be set to 0, and >> SHOULD be ignored upon receipt". If a BGPsec speaker receives an >> update where reserved is non-zero, what should it do? With the >> current text, I could interpret "SHOULD be ignored upon receipt" as >> meaning either "calculate the signature using the reserved field as >> received" or "calculate the signature using all zeroes in place of >> the reserved field". >> >> -- >> David Eric Mandelberg / dseomn >> http://david.mandelberg.org/ [1] >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org [2] >> https://www.ietf.org/mailman/listinfo/sidr [3] > > > > Links: > ------ > [1] http://david.mandelberg.org/ > [2] mailto:sidr@ietf.org > [3] https://www.ietf.org/mailman/listinfo/sidr > [4] mailto:david@mandelberg.org --=20 David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Mon Jul 6 17:28:00 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818A91A700D for ; Mon, 6 Jul 2015 17:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FRT_COCK=1.544, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Spn-DjDB4yhI for ; Mon, 6 Jul 2015 17:27:57 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAC121A6EF1 for ; Mon, 6 Jul 2015 17:27:57 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ZCGjq-0007VS-Ud; Tue, 07 Jul 2015 00:27:55 +0000 Date: Tue, 07 Jul 2015 09:27:52 +0900 Message-ID: From: Randy Bush To: Stephen Kent In-Reply-To: <559A8B31.50408@bbn.com> References: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> <556CF530.4010408@ops-netman.net> <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> <559A8B31.50408@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr wg list Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 00:27:58 -0000 really do appreciate review. do not appreciate pdfs of word docs; makes copy paste and commenting back a major pain. though i have come to suspect that is one of your goals. so i will not comment on your comments in that pdf, though i adopted/adapted the majority, with which i agreed. > - I don't consider myself to be on the hook for a "torn Euro" protocol back in 2007, you really did say you would do it. but this year it the kook kids would use a blockchain contract; that'll be a fun section to write :) > - I think the doc should distinguish between transfers of "live" > address space vs. transfers of space that is not currently in > use. The former are more complex tan the latter and thus merit a > different discussion operationally, you do not have a solid proof of [dis-]use. and i do not see how they should be treated differently. prudence says do it as if it is live. > - the text does not yet adequately describe the steps that need to > take place when the Buyer or Seller are not directly under a Swing > Point. sent text > - the TAO doc described a procedure for resource transfer that > avoids the concern you cited in Section 5. good. when we get to that doc, we can then deal i did not finish until after the dreadline. so all will be revealed in two weeks. for a small fee, early peeks might be available. randy From nobody Tue Jul 7 08:05:21 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C701ACD7C for ; Tue, 7 Jul 2015 08:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7lnHt-QA35s for ; Tue, 7 Jul 2015 08:05:18 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A699E1ACD58 for ; Tue, 7 Jul 2015 08:05:18 -0700 (PDT) Received: by wgjx7 with SMTP id x7so170583600wgj.2 for ; Tue, 07 Jul 2015 08:05:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=x9YLI4JVmIEFoiTNmUGoe9G1aoBXqzf6EMC+A+cT0Og=; b=QxSRHeUWtgGhGbTAT2gbr/PPi4CzYTQBSHWnAuLMTol+Kech+BphsKOEErsWzEf0DK pBptHmQtiBa9wsaufBSvhTdPZgTg95GrlMvQi0xqA3kNODwg6aIjgJTqWlfF1e3zxHoI 7YYMh/W0qJJWTLg5tu0CeYxY9PsUqHDQoqx9GIh+Dl5aNp+JYfZxvED2MgrLXL93ChV7 Wii7kXNfk8Ft7UfAngjHWTuAHpZIZrHWzsdA98iZuvDu6G9g6yUyOiRIe+VmDiO4Zuk8 ttGBo8HaA1vJ8T/tCkQvYkgqVMHqumhpwjYzsguG5vds5DDd5ZGMHWQiHGEcldkE2fus nv9g== X-Received: by 10.180.231.40 with SMTP id td8mr67146469wic.9.1436281517318; Tue, 07 Jul 2015 08:05:17 -0700 (PDT) Received: from ISOC-A1FD58.local ([92.109.76.43]) by mx.google.com with ESMTPSA id um5sm33800468wjc.1.2015.07.07.08.05.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jul 2015 08:05:16 -0700 (PDT) Message-ID: <559BEAAA.5090400@gmail.com> Date: Tue, 07 Jul 2015 17:05:14 +0200 From: Andrei Robachevsky User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Kent , sidr References: <556C88FC.3000409@bbn.com> In-Reply-To: <556C88FC.3000409@bbn.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pi6JVQQL1cnJL7aWX8dTvXv3L95Ke9NBe" Archived-At: Subject: Re: [sidr] draft-kent-sidr-adverse-actions-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 15:05:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pi6JVQQL1cnJL7aWX8dTvXv3L95Ke9NBe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, Stephen Kent wrote on 01/06/15 18:31: > Di Ma and I, with help from several folks at BBN, have generated this > document to try to characterize the set of attacks/errors that might > adversely impact INR holders in the RPKI context. As we discuss topics > like RPKI path validation, the Suspenders ideas, and Slurm, it seems > appropriate to have a common background on the security issues in quest= ion. >=20 > We hope this is a suitable start for this sort of discussion, something= > that might become a WG doc, maybe published as an informational RFC (or= > not). >=20 > https://datatracker.ietf.org/doc/draft-kent-sidr-adverse-actions/ >=20 > Comments appreciated. >=20 In my opinion it'd be useful to have an analysis of implications of adverse actions with respect to Internet Number Resources (INRs). I understand that probably the intention of this document is to introduce a common vocabulary that can be used for discussion of other issues and solutions, rather than provide solutions on its own. However, I found the document hard to read. It looks like the 3 main sections are not really linked together and the analysis of implications is scattered through the draft. Section 2 catalogs all various bad things that can happen, but does not provide guidance on the severity of different actions. Section 3 avoids any references to specific actions in Section 2, which brings a question of the utility of such classification. Finally, section 4 does not really depend on the considerations in the previous sections, and IMO could be written without such lengthy introduction. I think one of the main problems is that the "analysis is performed from the perspective of an affected INR holder". IMO, it'd be easier to analyze operational impact of various actions if we move the point of view to the RP, who accepts, or discards or de-prefs routing announcements. This could also allow to classify actions, or group them, by severity of the impact, and provide focus on the most critical attack vectors that may require out-of-band support/solutions. Andrei --pi6JVQQL1cnJL7aWX8dTvXv3L95Ke9NBe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlWb6qsACgkQljz5tZmtij/GRQCgiaIRytO0McIJeNOvn0eXSDgR UVUAn0Q5zK5JLx/m/nzuE+URquuiFrn+ =bL6R -----END PGP SIGNATURE----- --pi6JVQQL1cnJL7aWX8dTvXv3L95Ke9NBe-- From nobody Tue Jul 7 08:42:07 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9E81A8938 for ; Tue, 7 Jul 2015 08:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.267 X-Spam-Level: X-Spam-Status: No, score=-1.267 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FRT_COCK=1.544, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YArVZRAOS3B6 for ; Tue, 7 Jul 2015 08:42:05 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B3C41A8932 for ; Tue, 7 Jul 2015 08:42:01 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:36029 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZCV0S-000CBC-6r; Tue, 07 Jul 2015 11:42:00 -0400 From: Stephen Kent To: Randy Bush References: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> <556CF530.4010408@ops-netman.net> <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> <559A8B31.50408@bbn.com> Message-ID: <559BF347.60609@bbn.com> Date: Tue, 7 Jul 2015 11:41:59 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sidr wg list Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 15:42:06 -0000 Randy, > really do appreciate review. you're welcome. > do not appreciate pdfs of word docs; makes copy paste and commenting > back a major pain. though i have come to suspect that is one of your > goals. so i will not comment on your comments in that pdf, though i > adopted/adapted the majority, with which i agreed. I review docs in MS Word, because it makes it easy for me to correct typos and to precisely identify where comments apply. Because you reject Word docs, the best accommodation I can offer, given my unwillingness to adopt a different review mechanism, is to generate a PDF of the Word doc. I have no trouble copying and pasting text from a PDF, so I don't understand your comment about the difficulty of copy/paste. I do admit that responding, inline, to comments inn the PDF format is not easy. It would work fine if you accepted the Word doc, but ... >> - I don't consider myself to be on the hook for a "torn Euro" protocol > back in 2007, you really did say you would do it. but this year it the > kook kids would use a blockchain contract; that'll be a fun section to > write :) yes, 8 years ago I said that I (the royal I?) could do this. Time passed and I advised you a couple of years ago that it was not going to happen. I relayed this news based on advice from Matt Lepinski, who is much more knowledgeable on these crypto protocols than I. His conclusion was that the papers published on this sort of mechanism did not yet yield mature, practical, implementable protocols. >> - I think the doc should distinguish between transfers of "live" >> address space vs. transfers of space that is not currently in >> use. The former are more complex tan the latter and thus merit a >> different discussion > operationally, you do not have a solid proof of [dis-]use. and i do not > see how they should be treated differently. prudence says do it as if it > is live. The TAO I-D describes the differences in constraints imposed on the transfer process based on live vs. unused space. Unused is much, much easier and seems to be the most common type of space transferred across RIR boundaries. Thus it seems worth considering the distinction in a discussion of the problem. Steve From nobody Tue Jul 7 10:03:37 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EB51ACE96 for ; Tue, 7 Jul 2015 10:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1U7Gs2aKdWM for ; Tue, 7 Jul 2015 10:03:34 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0C01ACE91 for ; Tue, 7 Jul 2015 10:03:34 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id F156528B0041; Tue, 7 Jul 2015 13:03:33 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id CF7BA1F8035; Tue, 7 Jul 2015 13:03:33 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_EB5AE230-9781-4448-ABEE-09A36EFC5369"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: <559A9446.6040400@bbn.com> Date: Tue, 7 Jul 2015 13:03:32 -0400 Message-Id: References: <20150515192215.5707.56279.idtracker@ietfa.amsl.com> <555CE890.1090802@bbn.com> <462B3352-DAA9-476C-AA33-C517C515B7F0@tislabs.com> <555E5E4A.5080303@bbn.com> <559A9446.6040400@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1510) Archived-At: Cc: sidr@ietf.org, Sandra Murphy Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rfc6485bis-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 17:03:36 -0000 --Apple-Mail=_EB5AE230-9781-4448-ABEE-09A36EFC5369 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 6, 2015, at 10:44 AM, Stephen Kent wrote: > Sandy, >=20 >> Perhaps you are reading too much into the use of "conforming to"? = Perhaps saying "aligning with" would make it more clear to you? I do not = know what current CMS implementations would do if they were presented = with a RFC6485 compliant RPKI signed object. They may indeed report the = signed object is "non-conformant with the CMS standards". So I can not = say that "rejected as non-conformant with the CMS standards" is = incorrect. Error message aside, it is clear that any RFC6485 compliant = RPKI signed object (if we could find one) would be rejected by existing = implementations. There might be ways to improve that "rejected as = non-conformant" phrase of the text, but I don't think it is necessarily = wrong.=20 > you and I disagree here ;-). Conforming, in my mind, implies that we = use the same syntax, > validity checks, same alg requirements, etc. What we need to say is = that we profile the CMS > spec, deviating only with respect to the MTI algorithm. Using a = phrase like "aligning with" > seems needlessly ambiguous. [I'll repeat myself. This argument is about the clarity of the = description of the motivation for the change. There's no specification = or implementation impact.] I am not certain I am understanding your point. So I'll review the = background as I know it. Richard's view is that the word "conforming" in "By conforming to the = CMS specifications" makes it sounds as if RFC6485 were not in compliance = with the CMS specs.=20 But RFC6485 is definitely in compliance with the CMS specs. The mandatory algorithm choice in RFC6485 is not the same as the MTI = choice in the CMS specs. That is allowed. Unfortunately, that mandatory algorithm choice made RFC6485, er, uh, = out-of-step with common CMS implementations. So RPKI signed objects that were compliant with RFC6485 would be = rejected by the common CMS implementations - they support only the CMS = MTI algorithm. This bis changes the mandatory algorithm choice so it is the same as the = CMS MTI choice. Richard thinks "conforming" implies something not true, you think = "aligning" is ambiguous - do you have a different verb to suggest? > What we need to say is that we profile the CMS > spec, deviating only with respect to the MTI algorithm. =20 This bis removes the deviation, and makes the MTI algorithms the same. = So I disagree with this sentence. --Sandy, speaking as regular ol' member >>> Thus, I think it's important to make it clear which definition of >>> rsaEncryption is intended. >>>=20 >>> For example, RFC3370 (for CMS) says that rsaEncryption is either a = key >>> type identifier or a signature algorithm identifier, while RFC3279 = (for >>> PKIX) says that it's only a key type identifier and thus not = suitable >>> for identifying signature algorithms in a PKIX context (you must use >>> xxxWithRSAEncryption instead to specify the digest). > To avoid potential confusion we need to avoid ambiguity in specifying = alg identifiers. > RFC 3280 didn't resolve this particular ambiguity for PKIX, nor did = 3370. However, > this ambiguity was later addressed in RFC 4055 and RFC 5756. We should = figure out > which RSA-based signature alg we're mandating, and then cite the = relevant, recent RFC. The idea here is to use whatever CMS uses. Whether CMS is ambiguous in = its specification of the alg identifier, or correct in using = rsaEncryption as a signature algorithm identifier, we definitely want to = use whatever it is that CMS is using, because we want to be using CMS = implementations. =20 >=20 > Steve >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_EB5AE230-9781-4448-ABEE-09A36EFC5369 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVnAZkAAoJEHplpQeet0IZJXwP/185vJ5d7BwmCK9akBzxGrhy 1LEtTV2+WfbtZb83IGRjKU86S5q6eOqfN1TTcXObOFq8Ynys3gw89snus0LVihNH kLKhLyrnHoDEDavhA2sFJNGoUYxm09/BIXH+Hk2BoAiuUmgzsh5Am30fBSc9kN2s 1CF3VW2gWILXMARIYLvADGI+y9K+G38P1eMvPIOE6clfEXuT7RI+qqv5zN9Qpkb1 6IavwYw6dMOpzCPrw7E3lD6rhuY3Adxr6SNKuVZQS1K5mvWnwS2pDyo9S/a6Agi7 uzNLm/hTJd8OVL7aehyESy8sFiIzzDVtTWcEU30TpBn/FztZHx8JbKr028Fb9XQF 87TSwhGrApRGJnEr8WX3+6xaGiqMPuqfgWwzXjExZv1HHBHF520+r+SGE0E/1pcV XsnoOQtoqzjvjpyfLzusD54O2tAKBhh8YQj4Ax0M0byohwp6kTVg3SFoo0fYfRL4 55sa6RJz72HD3+3bTHR7J8ecSqFsggnnS8P2aQoFh3tGsA88Wn26fpm1itov0nZf SJaeXNRfg0h+umpwzPSzUsXU8bunWY9pfAjwvA9buuisU6HGGOM4fh4+YOgbiVw1 ifUpVB1STDXqhOr7MnRkooaKkzJEIpu/7fO2ExM2lNPYr+VZX1eFyTnBsK11D98D 5C8OuyHTEQw6AgkXAd+T =ThN3 -----END PGP SIGNATURE----- --Apple-Mail=_EB5AE230-9781-4448-ABEE-09A36EFC5369-- From nobody Wed Jul 8 10:30:59 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21981A1B79 for ; Wed, 8 Jul 2015 10:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30t204gmJ1il for ; Wed, 8 Jul 2015 10:30:56 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854FF1A1A62 for ; Wed, 8 Jul 2015 10:30:56 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 70D6E28B0041; Wed, 8 Jul 2015 13:30:55 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 617A81F8035; Wed, 8 Jul 2015 13:30:55 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_4EED9BAD-7A2B-4DA0-8D99-94304B870E2B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: <559BF347.60609@bbn.com> Date: Wed, 8 Jul 2015 13:30:54 -0400 Message-Id: <9DFC9C7C-CBFC-427C-8589-C13457EDD091@tislabs.com> References: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> <556CF530.4010408@ops-netman.net> <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> <559A8B31.50408@bbn.com> <559BF347.60609@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1510) Archived-At: Cc: sidr wg list , Sandra Murphy Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 17:30:59 -0000 --Apple-Mail=_4EED9BAD-7A2B-4DA0-8D99-94304B870E2B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 7, 2015, at 11:41 AM, Stephen Kent wrote: >=20 >>> - I think the doc should distinguish between transfers of "live" >>> address space vs. transfers of space that is not currently in >>> use. The former are more complex tan the latter and thus merit a >>> different discussion >> operationally, you do not have a solid proof of [dis-]use. and i do = not >> see how they should be treated differently. prudence says do it as = if it >> is live. > The TAO I-D describes the differences in constraints imposed on the > transfer process based on live vs. unused space. Unused is much, much = easier > and seems to be the most common type of space transferred across RIR = boundaries. > Thus it seems worth considering the distinction in a discussion of the = problem. I wasn't looking for this, but I happened upon an APNIC page that = describes transfer processes for three cases: unused space, for M&A, and = for historical resources. Answering their questions to get to the right = case never got me to a page that is explicitly about transferring live = address space. M&A are likely to be live and historical could be live, = I suppose. i don't find anything in their policy manual that says = transfers are only for unused space. Here's the page about transfer in general: = https://www.apnic.net/services/become-a-member/manage-your-membership/tran= sfer-resources I think it would be interesting to hear from the RIR's as to whether = they require resources to be unused, and for how long, before a transfer = is possible. That of course does not mean that transfers only occur between RIRs, or = that we can always know whether address space is in use. --Sandy, speaking as a regular ol' member P.S. =46rom the APNIC site, here are some interesting flowcharts of the = process: Transfer of unused IPv4 and AS Numbers APNIC account holders = (flowchart): = https://cgi1.apnic.net/assets/apnic/js/apps/transfers/Transfer%20procedure= %20of%20unused%20IPv4%20and%20AS%20Numbers%20between%20APNIC%20accounts.pd= f Transfer procedure of unused IPv4 from ARIN to APNIC accounts = (flowchart): = https://cgi1.apnic.net/assets/apnic/js/apps/transfers/Transfer%20procedure= %20of%20unused%20IPv4%20from%20ARIN%20to%20APNIC%20accounts.pdf detailed diagram for IPv4 transfer from other RIR to APNIC accounts: = https://www.apnic.net/services/become-a-member/manage-your-membership/tran= sfer-resources/ARIN-to-APNIC-IPv4-Transfer-with-Fees.jpg --Apple-Mail=_4EED9BAD-7A2B-4DA0-8D99-94304B870E2B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVnV5OAAoJEHplpQeet0IZT3IQAJ+qHQBMY1LwG0ve52ipZIhN eMFVvLRkeRZOUrZfp0JI+nX9S0gT5f24X/mq2ETdFE79pg1MkLeOqzIarEwZ1DxD XZZUzcjQOn4BKj8l0DTS51MVLkxanrBypIXLeDhdh64iI5VKOpsmwKQKRHBe7s0I sighDwWEfIAQeRkw+Xtt+840XQ+fktJclpRbNJ5GyRhnKqe2tJ5LGO3aI4g1Pkn0 US8oA+MYgGT3k2qQEafZSz41IhMORNfVPnwTOsEAUS4o9rfMXua+/Y9Wsq2cRoIB 4Y516zL0o9ql2Q/74d/8/vsYcnmuX0hWL9IWtwysKYG/5ipEc69dBe4MdctHCvQR YedDRCHbZHQZQxgltDY1EJ+Ymz61pb6+ZnxYx/Y/ySiGqn+JBBL6SJ+EbeQq9HqW /Qy8QLjABLfxegF7RFWJux80iC1sM4KDxUaop9uixjhgauYIDIu8zV/NGNFHOvnS t9rzDAR1+Z6MIqIpSs0NrSv7EOWN+U3aGdYruhp1dVCg5NtgncmAfv+uFSP5PKhW VvTnXpmkpiHfiEFoLtV+7UJxTedXwhvDqPRrrfXvp0BusajUB3y2fJS6MzVJY2t5 HyOaNSM5x8S1FTAjIsWELEZvE53FQ8mAB53M8KaXNCCWaZndnHpS3UMiyV8maiS7 9Pgh+RenE/+OGCUHzuI6 =ioVD -----END PGP SIGNATURE----- --Apple-Mail=_4EED9BAD-7A2B-4DA0-8D99-94304B870E2B-- From nobody Thu Jul 9 06:46:39 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B801A90D2; Thu, 9 Jul 2015 06:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaR6adRGrQcX; Thu, 9 Jul 2015 06:46:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6E91A9069; Thu, 9 Jul 2015 06:46:37 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150709134637.7120.70507.idtracker@ietfa.amsl.com> Date: Thu, 09 Jul 2015 06:46:37 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] Last Call: (Resource Public Key Infrastructure (RPKI) Trust Anchor Locator) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 13:46:38 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'Resource Public Key Infrastructure (RPKI) Trust Anchor Locator' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-07-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). This document obsoletes RFC6490 by adding support for multiple URIs in a TAL. A down reference exists in this document by using RFC5781 as a Normative Reference. RFC5781 has already been accepted by the community as a down reference and is properly documented in the DOWNREF Registry. The DOWNREF Registry can be accessed via https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6490-bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6490-bis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Jul 9 10:14:35 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2044F1B2B0E; Thu, 9 Jul 2015 10:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQnIzLLFdlXs; Thu, 9 Jul 2015 10:14:32 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0128.outbound.protection.outlook.com [207.46.100.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF90B1B2B0C; Thu, 9 Jul 2015 10:14:31 -0700 (PDT) Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by BLUPR09MB005.namprd09.prod.outlook.com (10.255.211.143) with Microsoft SMTP Server (TLS) id 15.1.213.10; Thu, 9 Jul 2015 17:14:30 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0207.004; Thu, 9 Jul 2015 17:14:30 +0000 From: "Sriram, Kotikalapudi" To: Christopher Morrow Thread-Topic: [Idr] Route Leaks and solutions Thread-Index: AQHQst/YBwy3rwbYakKgtnDiHnHcZp3NZLUJgAAwLgCAACk92IAAEGcAgAWPDmA= Date: Thu, 9 Jul 2015 17:14:29 +0000 Message-ID: References: <005901d0b283$ea07bd20$be173760$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-originating-ip: [129.6.140.100] x-microsoft-exchange-diagnostics: 1; BLUPR09MB005; 5:ih8u81BoV3woSLXhF3yPH10mfk1mIa6HfA/RZsAZ3maYGW1GeAKu7wuanrxjFclaLm7G6mqFX0AatZj+4gDBwTSq4ikpbnvQ6O1DUraYIFmNj30rlftCG08RsrXshAzKUmoWasjkV7lx/lRqtjWAeA==; 24:hssFmOkpYs3qXfQsCW2Bcn1attXGIVdajk1GwdpVHWa4LGnudqyy7lqjRhExwIrs/QSvvVKzLGGhypdwjXyfD479dhCDTx7PGIqujWhPwjg=; 20:91lTiIHdlyfPJu2bnt3NBF7e8v8GGWgR3si5CTD560hKv/WpBBOKQgvbw7XiukKK+X8fbXoiRCd/Z1wAPiF0EQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR09MB005; blupr09mb005: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR09MB005; BCL:0; PCL:0; RULEID:; SRVR:BLUPR09MB005; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(87936001)(106116001)(5003600100002)(86362001)(76576001)(62966003)(46102003)(99286002)(2656002)(66066001)(77156002)(76176999)(54356999)(50986999)(5002640100001)(2950100001)(33656002)(2900100001)(102836002)(110136002)(74316001)(77096005)(189998001)(5001960100002)(93886004)(92566002)(122556002)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR09MB005; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2015 17:14:30.0377 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR09MB005 Archived-At: Cc: idr wg list , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] [Idr] Route Leaks and solutions X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 17:14:34 -0000 KENjJ2luZyBzaWRyIGxpc3QgYWxzbyBzaW5jZSB0aGVyZSBpcyBpbnRlcmVzdCB0aGVyZSB0b28g aW4gdGhpcyB0b3BpYy4pDQoNCj4+IElmIEEncyBjdXN0b21lciBDIGRvZXMgbm90IHdhbnQgQSB0 byBwcm9wYWdhdGUsIHRoZW4gQyBoYXMgYSBjaG9pY2Ugbm90IHRvIHNlbmQNCj4+IHRoZSBwcmVm aXgtcm91dGUgdG8gQSBpbiB0aGUgZmlyc3QgcGxhY2UuDQo+PiBHaXZlbiB0aGF0IGNob2ljZSwg d2h5IHdvdWxkIEMgaW5zdGVhZCBjaG9vc2UgdG8gcG9pc29uIG9yIGRvd25ncmFkZSBieSBhbHRl cmluZyBSTFAgYml0cz8NCg0KPlE6IHdoeSBkbyBwZW9wbGUgcG9pc29uIHJvdXRlcyBieSBqYW1t aW5nIGluIHRvIHRoZSBhc3BhdGggQVNOIHdoaWNoDQo+dGhleSB3YW50IHRvIGlnbm9yZSB0aGVp ciBwcmVmaXgvYW5ub3VuY2VtZW50Pw0KPkE6IGJlY2F1c2Uga25vYi4NCg0KU2VjdGlvbiA1LjEg aW4gdGhlIHJvdXRlIGxlYWtzIHNvbHV0aW9uIGRyYWZ0IGFscmVhZHkgZGlzY3Vzc2VzIHBvc3Np YmxlIGFidXNlIA0Kb2YgdGhlIGtub2IgKHdpdGhvdXQgc2VjdXJpdHkgLyBiZ3BzZWMpLg0KUmFu ZHkgYW5kIEkgd2VyZSB0cnlpbmcgdG8gY29tZSB1cCB3aXRoIG1vcmUgZXhhbXBsZXMgKGJlc2lk ZXMgd2hhdCBpcyBpbiBTZWMuIDUuMSkuDQpJIHdpbGwgaW5jbHVkZSBSYW5keSdzIGFkZGl0aW9u YWwgZXhhbXBsZSAodGhhdCB3ZSBoYXZlIGRpc2N1c3NlZCBoZXJlKSBhbHNvIGluIFNlY3Rpb24g NS4xLiANCkJ1dCwgSU1ITywgc28gZmFyIG5vbmUgb2YgdGhlc2UgYWJ1c2VzIHNlZW1zIGVncmVn aW91cy4NClNvIHRoZSBiZW5lZml0IHNlZW1zIHRvIG91dHdlaWdoIHRoZSAnbmV3IGF0dGFjayB2 ZWN0b3InIGRpc2FkdmFudGFnZS4gRXhwbGFpbmVkIGZ1cnRoZXIgYmVsb3cuDQoNCkV2ZW4gd2l0 aCBST0Egb3JpZ2luIHZhbGlkYXRpb24sIHRoZXJlIGlzIHRoZSBmYWtlLW9yaWdpbi1BUyBhdHRh Y2sgdmVjdG9yICh3aXRob3V0IGJncHNlYyksDQpidXQgd2UgcmVjb2duaXplIHRoYXQgUk9BIG9y aWdpbiB2YWxpZGF0aW9uIHN0b3BzIGFsbCBhY2NpZGVudGFsIG1pcy1vcmlnaW5hdGlvbnMuIFNv IGl0IGlzIHdvcnRoIGl0LiAgDQpUaGUgZGV0ZXJtaW5lZCBhdHRhY2tlciBtYXkgc3RpbGwgdXNl IGZha2Utb3JpZ2luLUFTIGF0dGFjazsgDQpidXQgdGhhdCB3b3VsZCBiZSBtaXRpZ2F0ZWQgYnkg Ymdwc2VjICh3aGVuIGl0IGlzIGRlcGxveWVkKS4gDQogDQpMaWtld2lzZSwgdGhlIGV2b2x1dGlv biBwYXRoIGZvciByb3V0ZSBsZWFrcyBzb2x1dGlvbiBjb3VsZCBiZSBhcyBmb2xsb3dzOg0KDQpD dXJyZW50IEJHUCAod2l0aG91dCByb3V0ZSBsZWFrIHNvbHV0aW9uOyBhc3N1bWluZyBwcmVmaXgg L0FTIHBhdGggZmlsdGVycyBhcmVu4oCZdCBkb2luZyBqb2IgYWRlcXVhdGVseSkNCg0KLS0tIFZ1 bG5lcmFibGUgdG8gYWNjaWRlbnRhbCBhbmQgbWFsaWNpb3VzIHJvdXRlIGxlYWtzDQoNCi0tLSBM ZXQgdXMgc2F5IDk5JSBhcmUgYWNjaWRlbnRhbCBhbmQgMSUgbWFsaWNpb3VzICh5b3UgY2FuIHN1 YnN0aXR1dGUgeW91ciBudW1iZXJzKQ0KICANCiAgfA0KICB8DQogIFwvDQoNCkJHUCB3aXRoIHBy b3Bvc2VkIHJvdXRlIGxlYWsgc29sdXRpb24gKHdpdGhvdXQgYmdwc2VjKQ0KDQotLS0gRGV0ZWN0 cy9taXRpZ2F0ZXMgdGhlIDk5JSBidXQgbm90IHRoZSAxJQ0KDQogIHwNCiAgfA0KICBcLw0KICAN ClByb3Bvc2VkIHJvdXRlIGxlYWsgc29sdXRpb24gd2l0aCBiZ3BzZWMNCiAgICAgICANCi0tLSBE ZXRlY3RzL21pdGlnYXRlcyB0aGUgOTklIGFzIHdlbGwgYXMgdGhlIDElDQoNClNyaXJhbQ0KDQog ICAgIA0K From nobody Thu Jul 9 12:15:40 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B421A0010 for ; Thu, 9 Jul 2015 12:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRJNtGh_3rlY for ; Thu, 9 Jul 2015 12:15:37 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id C6D7F1A000F for ; Thu, 9 Jul 2015 12:15:36 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 802EB213A5D; Thu, 9 Jul 2015 15:15:36 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id E81B3213A54; Thu, 9 Jul 2015 15:15:35 -0400 (EDT) Received: from CHACAS02.corp.arin.net (10.1.30.108) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.210.2; Thu, 9 Jul 2015 15:22:47 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS02.corp.arin.net ([fe80::54ae:f9de:2f8b:1072%12]) with mapi id 14.03.0224.002; Thu, 9 Jul 2015 15:15:35 -0400 From: Andy Newton To: Sandra Murphy Thread-Topic: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt Thread-Index: AQHQuEvNHLMrleBUIUuX/9bvjtuFEZ3QaWKAgAGwwwCAAa+SgA== Date: Thu, 9 Jul 2015 19:15:34 +0000 Message-ID: <7A433ECB-5AEE-4521-A099-1E48DDF25E2B@arin.net> References: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> <556CF530.4010408@ops-netman.net> <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> <559A8B31.50408@bbn.com> <559BF347.60609@bbn.com> <9DFC9C7C-CBFC-427C-8589-C13457EDD091@tislabs.com> In-Reply-To: <9DFC9C7C-CBFC-427C-8589-C13457EDD091@tislabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.0.67] Content-Type: multipart/alternative; boundary="_000_7A433ECB5AEE4521A0991E48DDF25E2Barinnet_" MIME-Version: 1.0 Archived-At: Cc: sidr wg list Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 19:15:38 -0000 --_000_7A433ECB5AEE4521A0991E48DDF25E2Barinnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBKdWwgOCwgMjAxNSwgYXQgMTozMCBQTSwgU2FuZHJhIE11cnBoeSA8c2FuZHlAdGlzbGFi cy5jb208bWFpbHRvOnNhbmR5QHRpc2xhYnMuY29tPj4gd3JvdGU6DQoNCkkgdGhpbmsgaXQgd291 bGQgYmUgaW50ZXJlc3RpbmcgdG8gaGVhciBmcm9tIHRoZSBSSVIncyBhcyB0byB3aGV0aGVyIHRo ZXkgcmVxdWlyZSByZXNvdXJjZXMgdG8gYmUgdW51c2VkLCBhbmQgZm9yIGhvdyBsb25nLCBiZWZv cmUgYSB0cmFuc2ZlciBpcyBwb3NzaWJsZS4NCg0KVGhlIHJlYWxpdHkgaXMgdGhhdCB3ZSByYXJl bHkgZ2V0IHRyYW5zZmVycyBvZiBSUEtJIGNlcnRpZmllZCBzcGFjZSwgYnV0IHRvIGFuc3dlciB5 b3VyIHF1ZXN0aW9uOiB3ZSBkb27igJl0IGRlbnkgb3IgZGVsYXkgYSB0cmFuc2ZlciBqdXN0IGJl Y2F1c2UgaXQgaXMgUlBLSSBsaXZlLg0KDQotYW5keQ0K --_000_7A433ECB5AEE4521A0991E48DDF25E2Barinnet_ Content-Type: text/html; charset="utf-8" Content-ID: <6A7B2D6C39D59A45B63D2A165283D01E@corp.arin.net> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBKdWwg OCwgMjAxNSwgYXQgMTozMCBQTSwgU2FuZHJhIE11cnBoeSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNh bmR5QHRpc2xhYnMuY29tIiBjbGFzcz0iIj5zYW5keUB0aXNsYWJzLmNvbTwvYT4mZ3Q7IHdyb3Rl OjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xh c3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3Jw aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBk aXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPkkNCiB0aGluayBpdCB3b3VsZCBi ZSBpbnRlcmVzdGluZyB0byBoZWFyIGZyb20gdGhlIFJJUidzIGFzIHRvIHdoZXRoZXIgdGhleSBy ZXF1aXJlIHJlc291cmNlcyB0byBiZSB1bnVzZWQsIGFuZCBmb3IgaG93IGxvbmcsIGJlZm9yZSBh IHRyYW5zZmVyIGlzIHBvc3NpYmxlLjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGlu ZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IiBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPlRoZSByZWFsaXR5IGlzIHRoYXQgd2UgcmFyZWx5IGdldCB0 cmFuc2ZlcnMgb2YgUlBLSSBjZXJ0aWZpZWQgc3BhY2UsIGJ1dCB0byBhbnN3ZXIgeW91ciBxdWVz dGlvbjogd2UgZG9u4oCZdCBkZW55IG9yIGRlbGF5IGEgdHJhbnNmZXIganVzdCBiZWNhdXNlIGl0 IGlzIFJQS0kgbGl2ZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPi1hbmR5PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7A433ECB5AEE4521A0991E48DDF25E2Barinnet_-- From nobody Fri Jul 10 12:08:45 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58CF1B2A75 for ; Fri, 10 Jul 2015 12:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.226 X-Spam-Level: ** X-Spam-Status: No, score=2.226 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoDPzDQq-9uv for ; Fri, 10 Jul 2015 12:08:42 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9E26D1A1ADF for ; Fri, 10 Jul 2015 12:08:41 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.15,448,1432612800"; d="scan'208,217";a="907815662" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 10 Jul 2015 15:02:51 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Fri, 10 Jul 2015 15:08:35 -0400 From: "George, Wes" To: Matthew Lepinski , "sidr@ietf.org" Date: Fri, 10 Jul 2015 15:08:34 -0400 Thread-Topic: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12 Thread-Index: AdC7Q9Hpx9bBvN7SS9m9tOwaLJByqg== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D1C58D875BEACwesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 19:08:44 -0000 --_000_D1C58D875BEACwesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWF0dCAtDQoNCkkgZmluYWxseSBnb3QgYSBjaGFuY2UgdG8gcmV2aWV3IHRoZSB1cGRhdGVzIHlv dSBwdXQgaW4gZm9yIOKAkzEyIGFuZCAxMy4gSXQgaGFzIGFkZHJlc3NlZCBtb3N0IG9mIHRoZSBj b25jZXJucyBJIHJhaXNlZC4gT25seSB0aGluZyBJIHNlZSBtaXNzaW5nIGlzIHRoaXMgY29tbWVu dCBmcm9tIG15IHByZXZpb3VzIHJldmlldy4NCg0KU2VjdGlvbiA1LjIgLSBlbHNld2hlcmUgaW4g dGhlIGRvY3VtZW50ICg3LjMpLCB5b3Ugbm90ZSB0aGF0IHZhbGlkYXRpb24NCnNob3VsZCBzdG9w IHdoZW4gYW4gaW52YWxpZCBzaWduYXR1cmUgaXMgZm91bmQuIEhvd2V2ZXIsIEkgc2VlIG5vIG1l bnRpb24NCm9mIHRoYXQgaW4gdGhlIGFjdHVhbCB2YWxpZGF0aW9uIGFsZ29yaXRobS4gVGhhdCBz ZWVtcyBsaWtlIGdvb2QgcHJhY3RpY2UNCmV2ZW4gaWYgdGhlcmUgaXNuJ3QgYSBsb25nIGNoYWlu IG9mIHNpZ25hdHVyZXMgdG8gdmFsaWRhdGUuDQpBZGRpdGlvbmFsbHksIDcuMSdzIHRleHQgIlRo dXMsIGEgQkdQc2VjIHNwZWFrZXIgTVVTVCBjb21wbGV0ZWx5IHZhbGlkYXRlDQphbGwgQkdQc2Vj IHVwZGF0ZSBtZXNzYWdlcyByZWNlaXZlZCBmcm9tIGV4dGVybmFsIHBlZXJzLiIgc2VlbXMgdG8N CmNvbmZsaWN0IHdpdGggdGhpcyByZWNvbW1lbmRhdGlvbiBiZWNhdXNlIGl0IHNheXMgImNvbXBs ZXRlbHkiLiBJIHRoaW5rDQppdCdzIGEgd29yZGluZyBwcm9ibGVtLCBpLmUuIFdlJ3JlIG5vdCBz YXlpbmcgeW91IE1VU1QgdmFsaWRhdGUgdGhlDQoqZW50aXJlKiB1cGRhdGUsIGJ1dCByYXRoZXIg eW91IG11c3QgdmFsaWRhdGUgQUxMIHVwZGF0ZXMgdGhhdCB5b3UNCipyZWNlaXZlKiB1bnRpbCB5 b3UgZW5jb3VudGVyIGFuIGludmFsaWQgc2lnbmF0dXJlIHdpdGhpbiBhIGdpdmVuIHVwZGF0ZSwN CmluIHdoaWNoIGNhc2UgeW91IGNhbiBzdG9wIGFuZCBtb3ZlIHRvIHRoZSBuZXh0IHVwZGF0ZS4N Cg0KDQpUaGFua3MsDQoNCldlcw0KDQoNCkZyb206IHNpZHIgPHNpZHItYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86c2lkci1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIE1hdHRoZXcgTGVw aW5za2kgPG1sZXBpbnNraS5pZXRmQGdtYWlsLmNvbTxtYWlsdG86bWxlcGluc2tpLmlldGZAZ21h aWwuY29tPj4NCkRhdGU6IE1vbmRheSwgSnVuZSAxNSwgMjAxNSBhdCAxMjo0MSBBTQ0KVG86ICJz aWRyQGlldGYub3JnPG1haWx0bzpzaWRyQGlldGYub3JnPiIgPHNpZHJAaWV0Zi5vcmc8bWFpbHRv OnNpZHJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW3NpZHJdIE5ldyBWZXJzaW9uOiBkcmFmdC1pZXRm LXNpZHItYmdwc2VjLXByb3RvY29sLTEyDQoNCkkgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lv biBvZiB0aGUgQkdQc2VjIHByb3RvY29sIHNwZWNpZmljYXRpb24uDQoNClRoaXMgdmVyc2lvbiBp bmNsdWRlcyBzb21lIG1pbm9yIGZpeGVzIGFzIHdlbGwgYXMgYWxsIG9mIHRoZSBjaGFuZ2VzIGRp c2N1c3NlZCBhdCBJRVRGIDkyLiAoTWludXRlcyBjYW4gYmUgZm91bmQgaGVyZSAtLSBodHRwOi8v d3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkyL21pbnV0ZXMvbWludXRlcy05Mi1zaWRyKSBJIGJl bGlldmUgdGhhdCBhbGwgb3BlbiBpc3N1ZXMgd2l0aCB0aGlzIGRvY3VtZW50IGhhdmUgYmVlbiBh ZGRyZXNzZWQuDQoNClRoZSBvbmx5IG5vcm1hdGl2ZSBjaGFuZ2VzIGluIHRoZSAtMTIgdmVyc2lv biBhcmUgdGhlIGZvbGxvd2luZzoNCi0tIEJHUHNlYyBzcGVha2VycyBNVVNUIHN1cHBvcnQgdGhl IG11bHRpLXByb3RvY29sIGV4dGVuc2lvbiAoUkZDIDQ3NjApDQotLSBCR1BzZWMgbm93IHNpZ25z IHRoZSBlbnRpcmUgTVBfUkVBQ0hfTkxSSSBhdHRyaWJ1dGUuIChSZWNhbGwgdGhhdCB0aGVyZSB3 YXMgYW4gZXJyb3IgcHJldmlvdXNseSB3aGVyZSB0aGUgQUZJIHdhcyBub3QgcHJvdGVjdGVkIHVu ZGVyIHRoZSBzaWduYXR1cmUpDQoNCkkgYmVsaWV2ZSB0aGF0IHRoaXMgZG9jdW1lbnQgaXMgbm93 IHJlYWR5IHRvIHNoaXAgdG8gdGhlIElFU0cuIElmIHlvdSBkaXNhZ3JlZSwgcGxlYXNlIGxldCBt ZSBrbm93IHdoYXQgc3RpbGwgbmVlZHMgdG8gYmUgYWRkcmVzc2VkLg0KDQotIE1hdHQgTGVwaW5z a2kNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRoaXMgRS1tYWlsIGFuZCBh bnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3By aWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9y IHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhp cyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFs IG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVk IHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9u IHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8g dGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFs IGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K --_000_D1C58D875BEACwesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+TWF0 dCAtJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGZpbmFsbHkgZ290IGEg Y2hhbmNlIHRvIHJldmlldyB0aGUgdXBkYXRlcyB5b3UgcHV0IGluIGZvciDigJMxMiBhbmQgMTMu IEl0IGhhcyBhZGRyZXNzZWQgbW9zdCBvZiB0aGUgY29uY2VybnMgSSByYWlzZWQuIE9ubHkgdGhp bmcgSSBzZWUgbWlzc2luZyBpcyB0aGlzIGNvbW1lbnQgZnJvbSBteSBwcmV2aW91cyByZXZpZXcu Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07Ij5TZWN0aW9uIDUuMiAtIGVsc2V3 aGVyZSBpbiB0aGUgZG9jdW1lbnQgKDcuMyksIHlvdSBub3RlIHRoYXQgdmFsaWRhdGlvbjwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyBmb250LXNpemU6IG1lZGl1bTsi PnNob3VsZCBzdG9wIHdoZW4gYW4gaW52YWxpZCBzaWduYXR1cmUgaXMgZm91bmQuIEhvd2V2ZXIs IEkgc2VlIG5vIG1lbnRpb248L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xh czsgZm9udC1zaXplOiBtZWRpdW07Ij5vZiB0aGF0IGluIHRoZSBhY3R1YWwgdmFsaWRhdGlvbiBh bGdvcml0aG0uIFRoYXQgc2VlbXMgbGlrZSBnb29kIHByYWN0aWNlPC9kaXY+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTogQ29uc29sYXM7IGZvbnQtc2l6ZTogbWVkaXVtOyI+ZXZlbiBpZiB0aGVy ZSBpc24ndCBhIGxvbmcgY2hhaW4gb2Ygc2lnbmF0dXJlcyB0byB2YWxpZGF0ZS48L2Rpdj4NCjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07Ij5BZGRp dGlvbmFsbHksIDcuMSdzIHRleHQgJnF1b3Q7VGh1cywgYSBCR1BzZWMgc3BlYWtlciBNVVNUIGNv bXBsZXRlbHkgdmFsaWRhdGU8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xh czsgZm9udC1zaXplOiBtZWRpdW07Ij5hbGwgQkdQc2VjIHVwZGF0ZSBtZXNzYWdlcyByZWNlaXZl ZCBmcm9tIGV4dGVybmFsIHBlZXJzLiZxdW90OyBzZWVtcyB0bzwvZGl2Pg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6IENvbnNvbGFzOyBmb250LXNpemU6IG1lZGl1bTsiPmNvbmZsaWN0IHdpdGgg dGhpcyByZWNvbW1lbmRhdGlvbiBiZWNhdXNlIGl0IHNheXMgJnF1b3Q7Y29tcGxldGVseSZxdW90 Oy4gSSB0aGluazwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyBmb250 LXNpemU6IG1lZGl1bTsiPml0J3MgYSB3b3JkaW5nIHByb2JsZW0sIGkuZS4gV2UncmUgbm90IHNh eWluZyB5b3UgTVVTVCB2YWxpZGF0ZSB0aGU8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07Ij4qZW50aXJlKiB1cGRhdGUsIGJ1dCByYXRo ZXIgeW91IG11c3QgdmFsaWRhdGUgQUxMIHVwZGF0ZXMgdGhhdCB5b3U8L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07Ij4qcmVjZWl2ZSog dW50aWwgeW91IGVuY291bnRlciBhbiBpbnZhbGlkIHNpZ25hdHVyZSB3aXRoaW4gYSBnaXZlbiB1 cGRhdGUsPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7IGZvbnQtc2l6 ZTogbWVkaXVtOyI+aW4gd2hpY2ggY2FzZSB5b3UgY2FuIHN0b3AgYW5kIG1vdmUgdG8gdGhlIG5l eHQgdXBkYXRlLjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDExcHQ7Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPldlczxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw LjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElP TiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4 dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJP UkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZU OiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7 IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5zaWRyICZsdDs8YSBocmVmPSJtYWls dG86c2lkci1ib3VuY2VzQGlldGYub3JnIj5zaWRyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBv biBiZWhhbGYgb2YgTWF0dGhldyBMZXBpbnNraSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1sZXBpbnNr aS5pZXRmQGdtYWlsLmNvbSI+bWxlcGluc2tpLmlldGZAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPk1vbmRheSwgSnVuZSAx NSwgMjAxNSBhdCAxMjo0MSBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5U bzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpzaWRyQGlldGYub3JnIj5zaWRyQGlldGYu b3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpZHJAaWV0Zi5vcmciPnNpZHJAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0 OiA8L3NwYW4+W3NpZHJdIE5ldyBWZXJzaW9uOiBkcmFmdC1pZXRmLXNpZHItYmdwc2VjLXByb3Rv Y29sLTEyPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+SSBo YXZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBCR1BzZWMgcHJvdG9jb2wgc3BlY2lm aWNhdGlvbi4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoaXMgdmVyc2lvbiBpbmNsdWRlcyBz b21lIG1pbm9yIGZpeGVzIGFzIHdlbGwgYXMgYWxsIG9mIHRoZSBjaGFuZ2VzIGRpc2N1c3NlZCBh dCBJRVRGIDkyLiAoTWludXRlcyBjYW4gYmUgZm91bmQgaGVyZSAtLQ0KPGEgaHJlZj0iaHR0cDov L3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Mi9taW51dGVzL21pbnV0ZXMtOTItc2lkciI+aHR0 cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Mi9taW51dGVzL21pbnV0ZXMtOTItc2lkcjwv YT4pIEkgYmVsaWV2ZSB0aGF0IGFsbCBvcGVuIGlzc3VlcyB3aXRoIHRoaXMgZG9jdW1lbnQgaGF2 ZSBiZWVuIGFkZHJlc3NlZC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBvbmx5 IG5vcm1hdGl2ZSBjaGFuZ2VzIGluIHRoZSAtMTIgdmVyc2lvbiBhcmUgdGhlIGZvbGxvd2luZzom bmJzcDs8L2Rpdj4NCjxkaXY+LS0gQkdQc2VjIHNwZWFrZXJzIE1VU1Qgc3VwcG9ydCB0aGUgbXVs dGktcHJvdG9jb2wgZXh0ZW5zaW9uIChSRkMgNDc2MCkmbmJzcDs8L2Rpdj4NCjxkaXY+LS0gQkdQ c2VjIG5vdyBzaWducyB0aGUgZW50aXJlIE1QX1JFQUNIX05MUkkgYXR0cmlidXRlLiAoUmVjYWxs IHRoYXQgdGhlcmUgd2FzIGFuIGVycm9yIHByZXZpb3VzbHkgd2hlcmUgdGhlIEFGSSB3YXMgbm90 IHByb3RlY3RlZCB1bmRlciB0aGUgc2lnbmF0dXJlKTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+SSBiZWxpZXZlIHRoYXQgdGhpcyBkb2N1bWVudCBpcyBub3cgcmVhZHkgdG8gc2hpcCB0 byB0aGUgSUVTRy4gSWYgeW91IGRpc2FncmVlLCBwbGVhc2UgbGV0IG1lIGtub3cgd2hhdCBzdGls bCBuZWVkcyB0byBiZSBhZGRyZXNzZWQuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4t IE1hdHQgTGVwaW5za2k8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPjxicj4NCjxocj4NCjxmb250IGZh Y2U9IkFyaWFsIiBjb2xvcj0iR3JheSIgc2l6ZT0iMSI+VGhpcyBFLW1haWwgYW5kIGFueSBvZiBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkg aW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVj dCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFp bCBpcyBpbnRlbmRlZCBzb2xlbHkNCiBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBl bnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0 IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtl biBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvDQogdGhp cyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFu ZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Ljxicj4NCjwvZm9udD4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D1C58D875BEACwesleygeorgetwcablecom_-- From nobody Fri Jul 10 13:25:24 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39ED51A006F for ; Fri, 10 Jul 2015 13:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1QlLGN4dMda for ; Fri, 10 Jul 2015 13:25:22 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3021A006D for ; Fri, 10 Jul 2015 13:25:21 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ZDerH-0002Vn-Ih; Fri, 10 Jul 2015 20:25:20 +0000 Date: Fri, 10 Jul 2015 13:25:18 -0700 Message-ID: From: Randy Bush To: Wes George In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr wg list Subject: Re: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 20:25:23 -0000 see skip-out logic in expression evaluation randy From nobody Fri Jul 10 13:35:44 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED911A00F5 for ; Fri, 10 Jul 2015 13:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70tLWiYlQBM5 for ; Fri, 10 Jul 2015 13:35:42 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E79591A0091 for ; Fri, 10 Jul 2015 13:35:41 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ZDf1I-0002ZN-LZ; Fri, 10 Jul 2015 20:35:40 +0000 Date: Fri, 10 Jul 2015 13:35:40 -0700 Message-ID: From: Randy Bush To: Wes George In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr wg list Subject: Re: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 20:35:42 -0000 > see skip-out logic in expression evaluation a friend just whacked me for being obscure by using compiler and language geekery. sorry. when evaluating A & B, if A is false, there is no sense evaluating B. A | B, if A is true, there is no sense evaluating B. this sometimes surprises new programmers when B is, for example, a function with side effects. randy From nobody Fri Jul 10 13:55:20 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5379F1B2AF8 for ; Fri, 10 Jul 2015 13:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJ9P23b4SB5k for ; Fri, 10 Jul 2015 13:55:14 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7101E1A010D for ; Fri, 10 Jul 2015 13:55:14 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:42392 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZDfK9-0007ZK-M9; Fri, 10 Jul 2015 16:55:09 -0400 To: Andy Newton , Sandra Murphy References: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> <556CF530.4010408@ops-netman.net> <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> <559A8B31.50408@bbn.com> <559BF347.60609@bbn.com> <9DFC9C7C-CBFC-427C-8589-C13457EDD091@tislabs.com> <7A433ECB-5AEE-4521-A099-1E48DDF25E2B@arin.net> From: Stephen Kent Message-ID: <55A0312D.3050401@bbn.com> Date: Fri, 10 Jul 2015 16:55:09 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <7A433ECB-5AEE-4521-A099-1E48DDF25E2B@arin.net> Content-Type: multipart/alternative; boundary="------------070700090400080806050204" Archived-At: Cc: sidr wg list Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 20:55:19 -0000 This is a multi-part message in MIME format. --------------070700090400080806050204 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Andy, In this context "live" refers to address space in use as opposed to allocated but not in use. So your reply doesn't address the question. Steve > >> On Jul 8, 2015, at 1:30 PM, Sandra Murphy > > wrote: >> >> I think it would be interesting to hear from the RIR's as to whether >> they require resources to be unused, and for how long, before a >> transfer is possible. > > The reality is that we rarely get transfers of RPKI certified space, > but to answer your question: we don’t deny or delay a transfer just > because it is RPKI live. > > -andy --------------070700090400080806050204 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Andy,

In this context "live" refers to address space in use as opposed to allocated
but not in use. So your reply doesn't address the question.

Steve


On Jul 8, 2015, at 1:30 PM, Sandra Murphy <sandy@tislabs.com> wrote:

I think it would be interesting to hear from the RIR's as to whether they require resources to be unused, and for how long, before a transfer is possible.

The reality is that we rarely get transfers of RPKI certified space, but to answer your question: we don’t deny or delay a transfer just because it is RPKI live.

-andy

--------------070700090400080806050204-- From nobody Fri Jul 10 14:14:56 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EE81B2B26 for ; Fri, 10 Jul 2015 14:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VciCnpGKhMbZ for ; Fri, 10 Jul 2015 14:14:54 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B52C1B2AC2 for ; Fri, 10 Jul 2015 14:14:54 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ZDfdE-0002nB-OQ; Fri, 10 Jul 2015 21:14:52 +0000 Date: Fri, 10 Jul 2015 14:14:52 -0700 Message-ID: From: Randy Bush To: Stephen Kent In-Reply-To: <55A0312D.3050401@bbn.com> References: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> <556CF530.4010408@ops-netman.net> <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> <559A8B31.50408@bbn.com> <559BF347.60609@bbn.com> <9DFC9C7C-CBFC-427C-8589-C13457EDD091@tislabs.com> <7A433ECB-5AEE-4521-A099-1E48DDF25E2B@arin.net> <55A0312D.3050401@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr wg list Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 21:14:55 -0000 making assumptions if and how address space is or is not used is a recipe for mistakes and is not really useful. randy From nobody Sat Jul 11 15:18:17 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F45E1ACDAA for ; Sat, 11 Jul 2015 15:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFHTB4SayEIn for ; Sat, 11 Jul 2015 15:18:15 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D070D1ACDA9 for ; Sat, 11 Jul 2015 15:18:14 -0700 (PDT) Received: by qkhu186 with SMTP id u186so229665634qkh.0 for ; Sat, 11 Jul 2015 15:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=7Kmfi4SDWAbl5XEErqypbNlKSZ5LhJ2rCUPxsmHeNMY=; b=FpYe6bubZ5Hk+FdGqAp9lQh5feYXFtbdtQpL02mMpdaNuLFfB7/6leGTpwcL24XxxU Jtung1QYr5MuEk9J27uk7e9h2tUIXtsBdRkmZrzmSghxM6h3dXxMSVwkXVFwFeKaycc2 ZyfENrem/ZQLayCFMbKrf2+aNKqYpONYpvzWHdCcXWMFHxJ4AhjcwIjdtmqHaXlFjlHu pJUOX3GNgKqkTS/DZp24YD4qyzjXEzTcfC4GT6ZWCgQIx72hxNu0H//40sBavqInxjSK oK4VQFyb/yWSCXEBQsB9r2br7qxFiKdTe9Nl0/Id7QOh0SMSK3FD8l3WA+L52jbccJ7+ t2sg== X-Received: by 10.140.96.195 with SMTP id k61mr29665780qge.93.1436653094064; Sat, 11 Jul 2015 15:18:14 -0700 (PDT) MIME-Version: 1.0 References: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> <556CF530.4010408@ops-netman.net> <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> <559A8B31.50408@bbn.com> <559BF347.60609@bbn.com> <9DFC9C7C-CBFC-427C-8589-C13457EDD091@tislabs.com> <7A433ECB-5AEE-4521-A099-1E48DDF25E2B@arin.net> <55A0312D.3050401@bbn.com> In-Reply-To: From: Arturo Servin Date: Sat, 11 Jul 2015 22:18:04 +0000 Message-ID: To: Randy Bush , Stephen Kent Content-Type: multipart/alternative; boundary=001a113ace065659e2051aa0dd77 Archived-At: Cc: sidr wg list Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2015 22:18:16 -0000 --001a113ace065659e2051aa0dd77 Content-Type: text/plain; charset=UTF-8 How would you define that address space is unused? Because it is unannounced to the global BGP table? Because there is not traffic to it even though is announced? This question has come up in several policy discussion in almost every RIR, it has never been consensus on the answer. So we should probably considered every transfer as been in use. The draft is a good start, thanks for writing it. As soon as I have some time I will send some comments. /as On Fri, 10 Jul 2015 at 18:15 Randy Bush wrote: > making assumptions if and how address space is or is not used is a > recipe for mistakes and is not really useful. > > randy > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --001a113ace065659e2051aa0dd77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

How would you define that address space is unused= ? Because it is unannounced to the global BGP table?

Because there is not traffic to it even though is announced?
<= br>
This question has come up in several policy discussion in alm= ost every RIR, it has never been consensus on the answer. So we should prob= ably considered every transfer as been in use.

The= draft is a good start, thanks for writing it. As soon as I have some time = I will send some comments.

/as


On Fri, 10 Jul 2015 = at 18:15 Randy Bush <randy@psg.com&= gt; wrote:
making assumptions if an= d how address space is or is not used is a
recipe for mistakes and is not really useful.

randy

_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
--001a113ace065659e2051aa0dd77-- From nobody Sat Jul 11 16:53:21 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88DD91A0074 for ; Sat, 11 Jul 2015 16:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fmryFvY554G for ; Sat, 11 Jul 2015 16:53:19 -0700 (PDT) Received: from mail-vn0-x22d.google.com (mail-vn0-x22d.google.com [IPv6:2607:f8b0:400c:c0f::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B2831A006F for ; Sat, 11 Jul 2015 16:53:19 -0700 (PDT) Received: by vnbg129 with SMTP id g129so35038579vnb.11 for ; Sat, 11 Jul 2015 16:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=o+YKeRK3ZvoxNmxk3mS6n6EInjIPBV8bzALerXk8Qug=; b=ygG7WP/ynal+cznykLPdpmP2yq9GikvD2ZoqgKV2r5cogPhJHP8wU3eNoWr85OFQ3P leU21CdQ2M4j82MsixJLrhWY0BQp6FFdZhvniDfhQqln1DdqOMey/J0rDoFmNpjop1+A ATXdYjvXLPnXWSBJt1OCfo9e6PWXl5cwC1uCNjXrF+4tzoON0nUpjji/zDW589J215dY DtS4313ZR26YkM3mn3eMaH7MN4cXwIZ9BDf3BiB3zJoZvLlpb7/t6Sk2L1p/DUBwBDyZ cfy7h4MwqOJXKVRsKzcLG+ttkIYMIMPCtv+AeAh7rZLbMQwDqy9Qjr2fgCdadu9uH8dL c6/w== X-Received: by 10.52.32.34 with SMTP id f2mr5973293vdi.11.1436658798305; Sat, 11 Jul 2015 16:53:18 -0700 (PDT) Received: from dallas.local (r167-61-48-222.dialup.adsl.anteldata.net.uy. [167.61.48.222]) by smtp.googlemail.com with ESMTPSA id r7sm2179057vdw.23.2015.07.11.16.53.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Jul 2015 16:53:17 -0700 (PDT) Message-ID: <55A1AC1E.6090707@gmail.com> Date: Sat, 11 Jul 2015 20:51:58 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Arturo Servin , Randy Bush , Stephen Kent References: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> <556CF530.4010408@ops-netman.net> <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> <559A8B31.50408@bbn.com> <559BF347.60609@bbn.com> <9DFC9C7C-CBFC-427C-8589-C13457EDD091@tislabs.com> <7A433ECB-5AEE-4521-A099-1E48DDF25E2B@arin.net> <55A0312D.3050401@bbn.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: sidr wg list Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2015 23:53:20 -0000 As Arturo mentions, defining 'actual use' of number resources has proved quite tricky. The only workable assumption is that space that is marked 'available' or 'reserved' in the delegated-extended files is not in use whereas everything else is in use, regardless of whether it is announced in the Internet or not. Even this assumption could lead to unexpected situations here and there as there could be space being recovered that is still routed in bgp while being marked as reserved, not mentioning possible ongoing route hijacks of 'available' space still getting traffic. cheers! -Carlos On 7/11/15 7:18 PM, Arturo Servin wrote: > > How would you define that address space is unused? Because it is > unannounced to the global BGP table? > > Because there is not traffic to it even though is announced? > > This question has come up in several policy discussion in almost every > RIR, it has never been consensus on the answer. So we should probably > considered every transfer as been in use. > > The draft is a good start, thanks for writing it. As soon as I have some > time I will send some comments. > > /as > > > On Fri, 10 Jul 2015 at 18:15 Randy Bush > wrote: > > making assumptions if and how address space is or is not used is a > recipe for mistakes and is not really useful. > > randy > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From nobody Sat Jul 11 17:36:27 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C351A0104 for ; Sat, 11 Jul 2015 17:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.41 X-Spam-Level: X-Spam-Status: No, score=-0.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IXHASH_X1=1.5, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2F-ww5Shv38 for ; Sat, 11 Jul 2015 17:36:24 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4E6D1A0103 for ; Sat, 11 Jul 2015 17:36:24 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ZE5Fm-00033s-V0; Sun, 12 Jul 2015 00:36:23 +0000 Date: Sat, 11 Jul 2015 17:36:20 -0700 Message-ID: From: Randy Bush To: "Carlos M. Martinez" In-Reply-To: <55A1AC1E.6090707@gmail.com> References: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> <556CF530.4010408@ops-netman.net> <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> <559A8B31.50408@bbn.com> <559BF347.60609@bbn.com> <9DFC9C7C-CBFC-427C-8589-C13457EDD091@tislabs.com> <7A433ECB-5AEE-4521-A099-1E48DDF25E2B@arin.net> <55A0312D.3050401@bbn.com> <55A1AC1E.6090707@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr wg list Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2015 00:36:25 -0000 yup. we have a long history of trying to assign colors, flavors, sounds, ... to integers. it has never worked out very well. randy From nobody Mon Jul 13 04:31:39 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1AD1A87EB for ; Mon, 13 Jul 2015 04:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38QFMf7ZkiJA for ; Mon, 13 Jul 2015 04:31:36 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B4591A8821 for ; Mon, 13 Jul 2015 04:31:36 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1ZEbxO-0001nJ-5R; Mon, 13 Jul 2015 13:31:35 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-90.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1ZEbxO-0004Ir-1V; Mon, 13 Jul 2015 13:31:34 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Tim Bruijnzeels In-Reply-To: Date: Mon, 13 Jul 2015 13:31:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <75D85F43-69ED-4018-A195-9217F1320A08@ripe.net> References: <20150328232012.8464.95328.idtracker@ietfa.amsl.com> To: David Mandelberg X-Mailer: Apple Mail (2.2102) X-RIPE-Spam-Level: ---- X-RIPE-Spam-Report: Spam Total Points: -4.3 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07195561dc258136440f43e36232b8d7a0bc Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rfc6490-bis-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 11:31:38 -0000 Hi all, > On Apr 1, 2015, at 4:06 AM, David Mandelberg = wrote: >=20 > Hi, >=20 > While thinking about RRDP (draft-ietf-sidr-delta-protocol-00), I = realized that there's a minor conflict between RRDP's push to transition = from rsync to http(s), and the TAL format's requirement to use only = rsync URIs. I propose the below changes to = draft-ietf-sidr-rfc6490-bis-03 to make RRDP's work easier in the future = without causing any harm now. Sorry to bring this up so late in the = process for draft-ietf-sidr-rfc6490-bis. >=20 >=20 > In the abstract, change: >=20 > This document obsoletes RFC 6490 by adding support for multiple URIs = in a TAL. >=20 > to: >=20 > This document obsoletes RFC 6490 by adding support for multiple URIs = in a TAL, and allowing URI schemes other than rsync. >=20 There is no need for this just now. As long as we have rsync as well, = there is no problem fetching the root certificate using rsync. Also, = experience with and discussion of RRDP may actually lead us to wanting = something slightly different eventually (e.g. if we should come up with = a more defined way to refer to specific objects in RRDP). In short: I think we should come back to this later when RRDP is mature = enough. Thanks, Tim From nobody Mon Jul 13 17:26:42 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8AB1A885D for ; Mon, 13 Jul 2015 17:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRVAscd56MWv for ; Mon, 13 Jul 2015 17:26:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 429131A8860 for ; Mon, 13 Jul 2015 17:26:39 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:51868 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZEo3Q-0009wj-VA; Mon, 13 Jul 2015 20:26:37 -0400 To: Randy Bush References: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> <556CF530.4010408@ops-netman.net> <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> <559A8B31.50408@bbn.com> <559BF347.60609@bbn.com> <9DFC9C7C-CBFC-427C-8589-C13457EDD091@tislabs.com> <7A433ECB-5AEE-4521-A099-1E48DDF25E2B@arin.net> <55A0312D.3050401@bbn.com> From: Stephen Kent Message-ID: <55A4573C.5020006@bbn.com> Date: Mon, 13 Jul 2015 20:26:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sidr wg list Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 00:26:40 -0000 I disagree. In this context the entity relinquishing the address space should know whether the space is in use or not. We ought to be able to take advantage of this knowledge to simplify the transfer process, when applicable. Steve On 7/10/15 5:14 PM, Randy Bush wrote: > making assumptions if and how address space is or is not used is a > recipe for mistakes and is not really useful. > > randy > From nobody Mon Jul 13 17:35:58 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505171A8898 for ; Mon, 13 Jul 2015 17:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id la9NjqGZK4oG for ; Mon, 13 Jul 2015 17:35:56 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39BA81A885B for ; Mon, 13 Jul 2015 17:35:56 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:51890 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZEoCO-0009yN-0i; Mon, 13 Jul 2015 20:35:52 -0400 To: Arturo Servin , Randy Bush References: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> <556CF530.4010408@ops-netman.net> <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> <559A8B31.50408@bbn.com> <559BF347.60609@bbn.com> <9DFC9C7C-CBFC-427C-8589-C13457EDD091@tislabs.com> <7A433ECB-5AEE-4521-A099-1E48DDF25E2B@arin.net> <55A0312D.3050401@bbn.com> From: Stephen Kent Message-ID: <55A45967.5040309@bbn.com> Date: Mon, 13 Jul 2015 20:35:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sidr wg list Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 00:35:57 -0000 In the TAO proposal the entity relinquishing the address space is presumed to know, and to declare the transfer accordingly. That seems to be the simplest approach, and if that entity screws up, its users are impacted. Steve From nobody Mon Jul 13 17:37:23 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB271A88BE for ; Mon, 13 Jul 2015 17:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVKwBUuuFaza for ; Mon, 13 Jul 2015 17:37:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB8D81A889C for ; Mon, 13 Jul 2015 17:37:17 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:51894 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZEoDk-0009yZ-55; Mon, 13 Jul 2015 20:37:16 -0400 To: carlos@lacnic.net, Arturo Servin , Randy Bush References: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> <556CF530.4010408@ops-netman.net> <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> <559A8B31.50408@bbn.com> <559BF347.60609@bbn.com> <9DFC9C7C-CBFC-427C-8589-C13457EDD091@tislabs.com> <7A433ECB-5AEE-4521-A099-1E48DDF25E2B@arin.net> <55A0312D.3050401@bbn.com> <55A1AC1E.6090707@gmail.com> From: Stephen Kent Message-ID: <55A459BB.5060700@bbn.com> Date: Mon, 13 Jul 2015 20:37:15 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <55A1AC1E.6090707@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sidr wg list Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 00:37:19 -0000 Carlos, > As Arturo mentions, defining 'actual use' of number resources has proved > quite tricky. to an outsider maybe, but the entity initiating the transfer presumably knows, right? There's not need to infer this status from externally observable info. Steve From nobody Mon Jul 13 19:05:20 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B810B1A8911 for ; Mon, 13 Jul 2015 19:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Deyw7ZjGwmrO for ; Mon, 13 Jul 2015 19:05:19 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE5641A890E for ; Mon, 13 Jul 2015 19:05:18 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ZEpav-0005F8-1A; Tue, 14 Jul 2015 02:05:17 +0000 Date: Mon, 13 Jul 2015 19:05:16 -0700 Message-ID: From: Randy Bush To: Stephen Kent In-Reply-To: <55A45967.5040309@bbn.com> References: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> <556CF530.4010408@ops-netman.net> <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> <559A8B31.50408@bbn.com> <559BF347.60609@bbn.com> <9DFC9C7C-CBFC-427C-8589-C13457EDD091@tislabs.com> <7A433ECB-5AEE-4521-A099-1E48DDF25E2B@arin.net> <55A0312D.3050401@bbn.com> <55A45967.5040309@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr wg list Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 02:05:19 -0000 > In the TAO proposal the entity relinquishing the address space is > presumed to know, and to declare the transfer accordingly. That seems > to be the simplest approach, and if that entity screws up, its users > are impacted. and this is the ietf, so who gives a damn about the users? right. randy From nobody Tue Jul 14 01:43:17 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715D51A90AD; Tue, 14 Jul 2015 01:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wBYBBOCbHJq; Tue, 14 Jul 2015 01:43:11 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F6DD1A909A; Tue, 14 Jul 2015 01:43:11 -0700 (PDT) Received: by wgmn9 with SMTP id n9so2898513wgm.0; Tue, 14 Jul 2015 01:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=4LFAXgYSjdZ+eVViHky0QFdjlooTOlqjIkjEbhrbAf8=; b=Frt4DO3eAgg7C4ll1V5ewfO9klvJbPvDP9X8cVq9pJOgten5Sj0tCCLUk3WFgsihxg aAOaWJVdb7RMYk9WnpXfBx2AMGqqR8cY5qUu4Cq73XxakW5TgPcXRB/Qx3gtqJRw6kVz QeVCB/3AOnWCttMLGLyuKHjMAbMDebx3jFP1AbGi9VwRon30ZW+p1KBYjlgcCX+dQ9wU 8D2Dm8QUWRXCrCwmiyTPkViA9UAwGFAgEY7HO56iSeUx33GBwfbnJfpQtLtj+uz3Ae1Q qRH1mObNMv5hpqGyyNrjmdHTyRrLiCFY5kdCWJOVYsHCXHBpPJFXh8EzVvJroFwxiX4k kBdA== X-Received: by 10.194.205.101 with SMTP id lf5mr81050135wjc.37.1436863389851; Tue, 14 Jul 2015 01:43:09 -0700 (PDT) Received: from ISOC-A1FD58.local ([92.109.76.43]) by smtp.googlemail.com with ESMTPSA id gw7sm19422423wib.15.2015.07.14.01.43.08 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Jul 2015 01:43:09 -0700 (PDT) To: "Sriram, Kotikalapudi" References: <005901d0b283$ea07bd20$be173760$@ndzh.com> From: Andrei Robachevsky X-Enigmail-Draft-Status: N1110 Message-ID: <55A4CB9B.2050207@gmail.com> Date: Tue, 14 Jul 2015 10:43:07 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Tr7L8mupREAFb7Qt6BRiRwwhU5o0R3EEr" Archived-At: Cc: idr wg list , "sidr wg list \(sidr@ietf.org\)" Subject: [sidr] draft-sriram-idr-route-leak-detection-mitigation: difference between a peer and a customer X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 08:43:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Tr7L8mupREAFb7Qt6BRiRwwhU5o0R3EEr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Sriram, could you please elaborate what the difference is between the route-leak detection (and action) for customers and peers. It seems to me that sections 3.2.1. and 3.2.2. propose the same algorithm (modulo the BGP neighbor is a customer or a peer). The difference in the "possible actions" (3.3.) is not clear to me either. Finally, what is the proposed action when an RLP-marked update is received from an upstream? Thanks, Andrei --Tr7L8mupREAFb7Qt6BRiRwwhU5o0R3EEr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlWky5wACgkQljz5tZmtij8o9ACg5GNN3ZG0Efa28nJPCxsipsay EpEAmQF5bSon1aF04k5HHHy7u1l+iZKM =oZZy -----END PGP SIGNATURE----- --Tr7L8mupREAFb7Qt6BRiRwwhU5o0R3EEr-- From nobody Tue Jul 14 06:46:42 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB481ACD3E for ; Tue, 14 Jul 2015 06:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HV2p0U73wtnD for ; Tue, 14 Jul 2015 06:46:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BC1D1ACD3B for ; Tue, 14 Jul 2015 06:46:39 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:53526 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZF0XY-000EsR-HU; Tue, 14 Jul 2015 09:46:32 -0400 To: Randy Bush References: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> <556CF530.4010408@ops-netman.net> <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> <559A8B31.50408@bbn.com> <559BF347.60609@bbn.com> <9DFC9C7C-CBFC-427C-8589-C13457EDD091@tislabs.com> <7A433ECB-5AEE-4521-A099-1E48DDF25E2B@arin.net> <55A0312D.3050401@bbn.com> <55A45967.5040309@bbn.com> From: Stephen Kent Message-ID: <55A512B7.8040905@bbn.com> Date: Tue, 14 Jul 2015 09:46:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sidr wg list Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 13:46:40 -0000 Randy, What I meant to imply is that: - because the entity transferring the space knows whether it is is use - and because asserting that it isn't, when it is, will adversely affect users affiliated with that entity - therefore the entity in question is motivated to get it right - but, in the worst case, the damage is limited to users who could be screwed my the same entity due to other careless/erroneous behavior Steve >> In the TAO proposal the entity relinquishing the address space is >> presumed to know, and to declare the transfer accordingly. That seems >> to be the simplest approach, and if that entity screws up, its users >> are impacted. > and this is the ietf, so who gives a damn about the users? right. > > randy > From nobody Tue Jul 14 06:56:26 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6981ACD4A for ; Tue, 14 Jul 2015 06:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oXl_KAlZInU for ; Tue, 14 Jul 2015 06:56:22 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19431ACD3E for ; Tue, 14 Jul 2015 06:56:22 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 1DFAE28B003D for ; Tue, 14 Jul 2015 09:56:22 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id DF7591F8035; Tue, 14 Jul 2015 09:56:21 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_D153DC20-FF8C-49F2-95BF-58FBB7F37F30"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Tue, 14 Jul 2015 09:56:10 -0400 Message-Id: To: sidr wg list Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: Cc: Sandra Murphy Subject: [sidr] agenda update; slides request; scribe and minutes request X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 13:56:24 -0000 --Apple-Mail=_D153DC20-FF8C-49F2-95BF-58FBB7F37F30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Session preparation: Agenda: I have uploaded a new agenda. The times allotted to each presenter is = noted. If you see errors, particularly if you requested time and do not see a = slot, please inform the chairs as soon as possible. If you have a new topic to present, please inform the chairs. There is = space on the agenda. Slides: Presenters, please get your slides in early to the chairs. Slides must = be uploaded before the meeting. Our session is Friday morning, please = have your slides to the chairs by close of meeting Wed. Since we aren't meeting on Monday morning, the chairs have time to hunt = you down, so be prudent. Remember to number your slides, for the ease of those listening = remotely. Scribing and Minutes taking: We will need a minutes taker and a jabber scribe before the meeting can = start. Please volunteer (don't just rely on the same faithful few). Spare the = chairs the pitiful begging at the beginning of the meeting. --Sandy, speaking as one of the co-chairs --Apple-Mail=_D153DC20-FF8C-49F2-95BF-58FBB7F37F30 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVpRUHAAoJEHplpQeet0IZtJQQAJa8+RguJBHFaq9nSBVJadib nqnOwk07XFl1DCdhsta/OfNvIcUYoxpyQDiv4uNr6S4o6GcbI2hDnakAtnMzENLQ QRWTrFUGrf54NVLJ9V/TdFU4hZKMsTqG49a0bsu0KlVtt1zwWAzTPzdQAMIOqUaP 2g45h5pqxEGTX/hDVU1l4tGS2vT2daPdJ9w+/zxbihZfHfx3ulkywCEWbUmJ+835 HkU/FUugniT1cyl5lt4wt2TJ+eyRPpOrrFtOEfw3UpTx+uQWNFk3bEzFeJQgGDqO Ki2pu6I5bkvn6Jt5koVTxpGJbBmqdRVgfy+2ymC2Ub3w9HbtqcwrEqUtIP08qkdt Lw8ePSHTb10ENTE079lgz2SUetj+oSn7gMZBCLPvPgHvw04WqFsNzo/hIA786s/j 9ONzmCACmuquAzetlyyZkduRnKhf0DEUF1LzaMq58QkcXAxJP9NYAtxnkPkC3/lW pI5iA85XPSOi6C4hlv54jrI9eGzv2JxSXCSvgOfIMksRlVkfS2/+uow52A9vAbr/ jUSEyZ7SCYuFmhN76r5q/s7NIMXj2swzu96A9Dnz+nJxE2n1PFynAtfdcFpdED9b F2fvZHBQomow/sg3lJNfTg3V++lyAV8JtKXYkGqJGfREKhUv5civet/+BYqJUqqN mT7drFfqxhDCQXNI21pk =6JOx -----END PGP SIGNATURE----- --Apple-Mail=_D153DC20-FF8C-49F2-95BF-58FBB7F37F30-- From nobody Tue Jul 14 07:07:36 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3991ACD78 for ; Tue, 14 Jul 2015 07:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dv23WWoK6VKe for ; Tue, 14 Jul 2015 07:07:34 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 002461ACD7B for ; Tue, 14 Jul 2015 07:07:33 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ZF0rp-0000Jd-NY; Tue, 14 Jul 2015 14:07:30 +0000 Date: Tue, 14 Jul 2015 07:07:29 -0700 Message-ID: From: Randy Bush To: Stephen Kent In-Reply-To: <55A512B7.8040905@bbn.com> References: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> <556CF530.4010408@ops-netman.net> <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> <559A8B31.50408@bbn.com> <559BF347.60609@bbn.com> <9DFC9C7C-CBFC-427C-8589-C13457EDD091@tislabs.com> <7A433ECB-5AEE-4521-A099-1E48DDF25E2B@arin.net> <55A0312D.3050401@bbn.com> <55A45967.5040309@bbn.com> <55A512B7.8040905@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr wg list Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 14:07:35 -0000 > - because the entity transferring the space knows whether it is > is use as the operators and rirs here keep trying to tell you, this is not a safe assumption. unlike you, some of us make mistakes. > - and because asserting that it isn't, when it is, will adversely > affect users affiliated with that entity > - therefore the entity in question is motivated to get it right > - but, in the worst case, the damage is limited to users who could be > screwed my the same entity due to other careless/erroneous behavior there are potholes in the road. this does not mean it is ok to dig more of them. in fact, we are trying to reduce them. randy From nobody Tue Jul 14 07:34:56 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7971ACE06 for ; Tue, 14 Jul 2015 07:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3Uqzl-SHwUI for ; Tue, 14 Jul 2015 07:34:53 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F3D21ACE01 for ; Tue, 14 Jul 2015 07:34:52 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:33885 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZF1II-0002ui-94; Tue, 14 Jul 2015 10:34:50 -0400 To: Randy Bush References: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> <556CF530.4010408@ops-netman.net> <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> <559A8B31.50408@bbn.com> <559BF347.60609@bbn.com> <9DFC9C7C-CBFC-427C-8589-C13457EDD091@tislabs.com> <7A433ECB-5AEE-4521-A099-1E48DDF25E2B@arin.net> <55A0312D.3050401@bbn.com> <55A45967.5040309@bbn.com> <55A512B7.8040905@bbn.com> From: Stephen Kent Message-ID: <55A51E0A.7020904@bbn.com> Date: Tue, 14 Jul 2015 10:34:50 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sidr wg list Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 14:34:55 -0000 So, your argument is that because a mis-declaration of space as unused vs. can by an ISP cause harm, we should engineer a transfer model that imposes additional complexity on what seems likely to be the most common case. (I assume transfer of unused space is or will be the most common case because it represents the space that is sold and we've been told that RIRs expect a big increase in transfers due to sales of v4 space.) I acknowledge the merits of your argument, but I also like to engineer solutions that optimize for the common case. Steve >> - because the entity transferring the space knows whether it is >> is use > as the operators and rirs here keep trying to tell you, this is not a > safe assumption. unlike you, some of us make mistakes. > >> - and because asserting that it isn't, when it is, will adversely >> affect users affiliated with that entity >> - therefore the entity in question is motivated to get it right >> - but, in the worst case, the damage is limited to users who could be >> screwed my the same entity due to other careless/erroneous behavior > there are potholes in the road. this does not mean it is ok to dig more > of them. in fact, we are trying to reduce them. > > randy > From nobody Tue Jul 14 08:11:16 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF701ACEA0 for ; Tue, 14 Jul 2015 08:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8lHVLAa1d4Y for ; Tue, 14 Jul 2015 08:11:13 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EA9E1AC432 for ; Tue, 14 Jul 2015 08:11:05 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:53842 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZF1rK-000Fuh-Ix; Tue, 14 Jul 2015 11:11:02 -0400 To: Andrei Robachevsky , sidr References: <556C88FC.3000409@bbn.com> <559BEAAA.5090400@gmail.com> From: Stephen Kent Message-ID: <55A52680.3020504@bbn.com> Date: Tue, 14 Jul 2015 11:10:56 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <559BEAAA.5090400@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] draft-kent-sidr-adverse-actions-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 15:11:15 -0000 Andrei, Thanks for taking the time to read the adverse actions doc. I realize that it's dense in places, and appreciate feedback to improve it. > In my opinion it'd be useful to have an analysis of implications of > adverse actions with respect to Internet Number Resources (INRs). I > understand that probably the intention of this document is to introduce > a common vocabulary that can be used for discussion of other issues and > solutions, rather than provide solutions on its own. Yes, the intent is not to propose solutions here, but to establish a taxonomy of actions that can have adverse impacts on RPKI RPs, so that we have a common basis for evaluating proposals. > However, I found the document hard to read. It looks like the 3 main > sections are not really linked together and the analysis of implications > is scattered through the draft. > Section 2 catalogs all various bad things that can happen, but does not > provide guidance on the severity of different actions. Section 2 describes the current set of RPKI objects and defines the classes of actions that can befall them. In so doing it notes the top-level implications of each type of action in the context of the object. You're right that the severity of the impact is not described. In part the severity depends on where in the RPKI hierarchy the adverse event takes place. We can add text to each action (identified as "A-x.x") to provide some insights about the severity of the action. > Section 3 avoids any references to specific actions in Section 2, which > brings a question of the utility of such classification. This section establishes scenarios to place actions into context, i.e., to indicate which classes of actions can be effected by which actors based on the scenario. It does not refer to individual actions from Section 2, but rather notes what classes of actions can be effected by a bad actor. Without the characterization of types of actions in Section 2, one would not be able to make brief statements about what bad things can happen in a given scenario. For example, text in this section notes when modification, revocation or injection actions can be effected by a INR holder, or by a parent or by an outsourced repository operator, etc. So I think the utility of the taxonomy in Section 2 is evident here, even though we don't cite specific actions in Section 3. > Finally, section 4 does not really depend on the considerations in the > previous sections, and IMO could be written without such lengthy > introduction. The recommendations in Section 4 result from the analysis in Sections 2 and 3. The recommendations are justified based on that analysis. We can add text to this section to point to the basis for each recommendation to make that linkage more apparent. > I think one of the main problems is that the "analysis is performed from > the perspective of an affected INR holder". IMO, it'd be easier to > analyze operational impact of various actions if we move the point of > view to the RP, who accepts, or discards or de-prefs routing > announcements. We chose to use the perspective if the INR holder because we were worried that a more diffuse perspective would result in a redundant taxonomy. (Actions by an INR holder affect its own resources and those of any subordinate INR holders, for example.) Nonetheless, I agree that the RP perspective is a very valuable one. We already note the impact on RPs of most of the actions described in Section 2. But we could add text to discuss the impact on RPs in places where it is missing/sparse. We also could add a section to pull together this info if you think it would make the exposition clearer, > This could also allow to classify actions, or group them, by severity of > the impact, and provide focus on the most critical attack vectors that > may require out-of-band support/solutions. OK, We'll look into that. Steve From nobody Tue Jul 14 21:53:08 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55FF1A02F1; Tue, 14 Jul 2015 21:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4THsMGKXNjw; Tue, 14 Jul 2015 21:53:04 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20AA51A0276; Tue, 14 Jul 2015 21:53:04 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:38446) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZFEgi-000JFq-FX; Wed, 15 Jul 2015 00:52:56 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id 35A65400DC Message-ID: <55A5E727.7020605@bbn.com> Date: Wed, 15 Jul 2015 00:52:55 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: ietf@ietf.org References: <20150709134637.7120.70507.idtracker@ietfa.amsl.com> In-Reply-To: <20150709134637.7120.70507.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] Last Call: (Resource Public Key Infrastructure (RPKI) Trust Anchor Locator) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 04:53:06 -0000 There is one substantive issue I noticed: embedded newlines in the Base64 string. Section 2.1 refers to Base64 encoding, defined in RFC4648 Section 4. RFC4648 Section 3.1 says: Implementations MUST NOT add line feeds to base-encoded data unless the specification referring to this document explicitly directs base encoders to add line feeds after a specific number of characters. This draft does not say anything about adding newlines to the Base64 string, yet: * all published TALs (that I could find) contain embedded newlines at regular intervals, in violation of this specification * the example in Section 2.3 contains embedded newlines every 57 characters All existing implementations support embedded newlines at arbitrary places in the Base64 string, including multiple newlines in a row (if I'm reading everyone's code correctly). I see three possible fixes: 1. Add a note next to the example in Section 2.3 that says that newlines were added to the example due to line length limitations in the RFC format. Encourage TAL publishers to fix their TALs by removing the embedded newlines. 2. Permit but don't require newlines. For example, change Section 2.1 item #3 from: 3) a subjectPublicKeyInfo [RFC5280] in DER format [X.509], encoded in Base64 (see Section 4 of [RFC4648]. to: 3) a subjectPublicKeyInfo [RFC5280] in DER format [X.509], encoded in Base64 (see Section 4 of [RFC4648]). To avoid long lines, or line breaks MAY be inserted into the Base64 encoded string. 3. Require line breaks in the Base64 string. For example, change Section 2.1 item #3 from: 3) a subjectPublicKeyInfo [RFC5280] in DER format [X.509], encoded in Base64 (see Section 4 of [RFC4648]. to: 3) a subjectPublicKeyInfo [RFC5280] in DER format [X.509], encoded in Base64 (see Section 4 of [RFC4648]). To avoid long lines, a or line break MUST be inserted into the Base64 encoded string every 75 or fewer characters. I prefer option #3. If I understand correctly, OpenSSL's Base64 BIO filter has two modes: no newlines permitted or newlines must be inserted every 79 or fewer characters. The mode is not automatically detected; the programmer must choose which mode to use. If the standard guarantees that all lines will be shorter than 79 characters, then OpenSSL's Base64 BIO filter can be used without any preprocessing. (The choice of 75 is more-or-less arbitrary. Keeping it less than 80 is important for OpenSSL compatibility. MIME (RFC2045) and vCard (RFC6350) both require Base64 strings to be broken up every 75 or fewer characters, and I figured it might be good to match.) My second choice is option #2. It still requires preprocessing before OpenSSL's Base64 BIO filter can be used, but it permits existing practice= . Option #1 is my least favorite. It is the least disruptive to the document, but it still requires modifying the document so we might as well modify it to permit existing practice. (Also, getting all of the RIRs to fix their TALs is probably more work than changing the specification.) Nits: * section 2.1, item 3: missing close parenthesis * section 2.1: "comprised of" should be "composed of" * section 2.1: "one of more" should be "one or more" * section 3, item 4: "These test" should be "These tests" * regressions of comma changes made by the RFC Editor before RFC6490 was published -Richard On 2015-07-09 09:46, The IESG wrote: >=20 > The IESG has received a request from the Secure Inter-Domain Routing WG > (sidr) to consider the following document: > - 'Resource Public Key Infrastructure (RPKI) Trust Anchor Locator' > as Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-07-23. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This document defines a Trust Anchor Locator (TAL) for the Resource > Public Key Infrastructure (RPKI). This document obsoletes RFC6490 b= y > adding support for multiple URIs in a TAL. >=20 >=20 > A down reference exists in this document by using RFC5781 as a Normativ= e=20 > Reference. RFC5781 has already been accepted by the community as a dow= n=20 > reference and is properly documented in the DOWNREF Registry. >=20 > The DOWNREF Registry can be accessed via > https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry >=20 > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6490-bis/ >=20 > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6490-bis/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. From nobody Wed Jul 15 01:55:12 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBE11A004A; Wed, 15 Jul 2015 01:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saHNT1LJMnlV; Wed, 15 Jul 2015 01:55:05 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A20D11A0053; Wed, 15 Jul 2015 01:55:02 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1ZFISx-0007gc-22; Wed, 15 Jul 2015 10:55:00 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-13.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1ZFISw-0002oa-Tn; Wed, 15 Jul 2015 10:54:58 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Tim Bruijnzeels In-Reply-To: <55A5E727.7020605@bbn.com> Date: Wed, 15 Jul 2015 10:55:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2F6DFD09-0831-413E-AC52-05DE95F78929@ripe.net> References: <20150709134637.7120.70507.idtracker@ietfa.amsl.com> <55A5E727.7020605@bbn.com> To: Richard Hansen X-Mailer: Apple Mail (2.2102) X-RIPE-Spam-Level: ---- X-RIPE-Spam-Report: Spam Total Points: -4.3 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719fb9f102c736404b2367677c278e2b05a Archived-At: Cc: ietf@ietf.org, sidr@ietf.org Subject: Re: [sidr] Last Call: (Resource Public Key Infrastructure (RPKI) Trust Anchor Locator) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 08:55:06 -0000 Hi, > On Jul 15, 2015, at 6:52 AM, Richard Hansen wrote: >=20 > 3. Require line breaks in the Base64 string. For example, change > Section 2.1 item #3 from: >=20 > 3) a subjectPublicKeyInfo [RFC5280] in DER format [X.509], > encoded in Base64 (see Section 4 of [RFC4648]. >=20 > to: >=20 > 3) a subjectPublicKeyInfo [RFC5280] in DER format [X.509], > encoded in Base64 (see Section 4 of [RFC4648]). To avoid > long lines, a or line break MUST be inserted into > the Base64 encoded string every 75 or fewer characters. >=20 > I prefer option #3. If I understand correctly, OpenSSL's Base64 BIO > filter has two modes: no newlines permitted or newlines must be > inserted every 79 or fewer characters.=20 I am fine with this option. I agree that it's better to have this = explicit. De facto this is what everyone is doing now, and I see no = issues with our running code (both trust anchor code producing TALs, and = validator code parsing this). Regards Tim Bruijnzeels (RIPE NCC)= From nobody Wed Jul 15 06:04:04 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D931A8F35; Wed, 15 Jul 2015 06:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVHewsS34m_4; Wed, 15 Jul 2015 06:04:00 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:732]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 991F71A8F33; Wed, 15 Jul 2015 06:04:00 -0700 (PDT) Received: from SN1PR09MB0799.namprd09.prod.outlook.com (10.162.101.145) by SN1PR09MB0797.namprd09.prod.outlook.com (10.162.101.143) with Microsoft SMTP Server (TLS) id 15.1.213.14; Wed, 15 Jul 2015 13:03:39 +0000 Received: from SN1PR09MB0799.namprd09.prod.outlook.com ([10.162.101.145]) by SN1PR09MB0799.namprd09.prod.outlook.com ([10.162.101.145]) with mapi id 15.01.0213.000; Wed, 15 Jul 2015 13:03:39 +0000 From: "Sriram, Kotikalapudi" To: Andrei Robachevsky Thread-Topic: draft-sriram-idr-route-leak-detection-mitigation: difference between a peer and a customer Thread-Index: AQHQvhEfZNxwzI8V2ECO5TICdbuD2Z3cfN/4 Date: Wed, 15 Jul 2015 13:03:39 +0000 Message-ID: References: <005901d0b283$ea07bd20$be173760$@ndzh.com> , <55A4CB9B.2050207@gmail.com> In-Reply-To: <55A4CB9B.2050207@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [129.6.222.120] x-microsoft-exchange-diagnostics: 1; SN1PR09MB0797; 5:EkXjRldeuVlA2N1ATiFWoxuUwYA/wE15+ebirxO9qv5A9o3XPUSiv+FmdbZ8q1Tpxr2rVaS9aA4IINnGlh+j6DHgw64WwRgF7futAmQLwfScewYg9+TwpMKsxiwPjOYYnANsNgF8g9n/aHQRsL0IWg==; 24:4caH0F+rzJyAeXbP37RlhgUP9KyBCHUuNk4AnO3bzTBWH/nxKRn9oFNr91d+B3sqHQ2Ni+rbBmGbTm5Bjw1pMGOMpVEzsEcMpByc+sbCyRI=; 20:GhyJ6z7Mun7fC444iMfLElnFsxbnoqk5P4fGDxotpqXSsikbukG9Nuw/TXYpwIHZpOT6RfrXjY0RwVRrtffcFw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR09MB0797; sn1pr09mb0797: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR09MB0797; BCL:0; PCL:0; RULEID:; SRVR:SN1PR09MB0797; x-forefront-prvs: 0638FD5066 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189998001)(87936001)(33656002)(2656002)(93886004)(5003600100002)(5002640100001)(122556002)(62966003)(76176999)(5001960100002)(40100003)(50986999)(66066001)(86362001)(230783001)(46102003)(2900100001)(106116001)(110136002)(77096005)(92566002)(77156002)(54356999)(99286002)(76576001)(74316001)(561944003)(102836002)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR09MB0797; H:SN1PR09MB0799.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2015 13:03:39.5657 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR09MB0797 Archived-At: Cc: idr wg list , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] draft-sriram-idr-route-leak-detection-mitigation: difference between a peer and a customer X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 13:04:03 -0000 Andrei, Thank you for reading the draft and offering comments -- certainly very hel= pful towards refining the proposal as well adding greater clarity in the documen= t. >It seems to me that sections 3.2.1. and 3.2.2. propose the same >algorithm (modulo the BGP neighbor is a customer or a peer).=20 Your observation is correct. It has to do with the semantics of RLP bits. For now, we have RLP =3D 00 (default; nothing said) and RLP =3D 01 ('do not= propagate up'). 'Do not propagate up' certainly means that the update should not subsequent= ly=20 propagate from a customer to its provider. However, a receiver can (at its own discretion) interpret RLP =3D 01 more s= trictly=20 to mean 'do not propagate to provider or peer'.=20 That is because if an ISP is not supposed to forward an update with RLP =3D= 01=20 'up' to a provider, then normally it should not forward it 'laterally' to a= peer either. So we have separated the receiver detection procedures for=20 (a) when the update comes from a *customer* (section 3.2.1), and=20 vs. (b) when it comes from a *peer* (section 3.2.2). The difference is the stricter interpretation (in Section 3.2.2) of RLP =3D= 01. Initially the attempt is to see if we can keep the RLP semantics simple, and still accomplish the detection objectives w.r.t. customer/peer.=20 These two section can be merged into one if, for example,=20 RLP =3D 01 is specified to denote 'do not propagate to provider or peer'. = =20 >The difference in the "possible actions" (3.3.) is not clear to me either. When an update is detected and 'marked' as 'route leak' (based on section 3= .2.1 or 3.2.2 detection), then the same/similar method(s) of mitigation can be applied (in the two ca= ses).=20 The draft should not specify a mitigation method because that is left to op= erator policy. So we describe only an *example* policy: Suspend the "prefer customer" poli= cy; i.e. instead of a 'marked' update from a customer, prefer an 'unmarked' update from a provider or peer. Some similar policy can be applied for a pe= er.=20 Let the operator decide the actual policy to be used in each case. >Finally, what is the proposed action when an RLP-marked update is >received from an upstream? Good point. The draft currently does not discuss this. If the customer is single-homed and does not have any alternate path for the prefix, then it would install the route learned from its sole provider even if it i= s 'marked'. If the customer is multi-homed, it should prefer an 'unmarked' update from= =20 one provider over a 'marked' update from another provider. Etc. Again these actions/methods are left to operator policy. However, in the next revision, we will include a subsection to outline this= . =20 Sriram From nobody Wed Jul 15 08:00:33 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FE71ACC88; Wed, 15 Jul 2015 08:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEwBKZu-d1K0; Wed, 15 Jul 2015 08:00:27 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD1E1ACC81; Wed, 15 Jul 2015 08:00:26 -0700 (PDT) Received: by widjy10 with SMTP id jy10so2294328wid.1; Wed, 15 Jul 2015 08:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=5MTJwI3qr3FS/9n+9dq0ooOnLcuvN/FTueKJNTYABFo=; b=axU3VsHDHITxsJT0i/TmPdSVsPIaZ6trwVeDecc8T7BddggOTQxUKvtpJI4HbA+1Ri QU3HcEpMWr7jXBmzU2Ub2JpYWsZfWbrlSj2wbpBq+bLBe8nhS/2A3xSEqcLg/FGPODNJ tMGNWgh0tVTLGsydp0amCuD6qyNjxqiz3e2JNDbu+WNI3wkuhfwWQYzXbAKDCJiN3shG gqUgcpsW/qH+PZoDD0OxOZBdm+bA915OHiQ3yvcWk0m3H407XxVjCXYF5wh0psbhY0hM 1tdg1o0uu/uJSotM8SdGC+cvLM+djV4hSiYI+oK9gv2tsadGbyJ1GxmKMvLhl3LuHrT6 /KcA== X-Received: by 10.194.94.101 with SMTP id db5mr9066079wjb.91.1436972425596; Wed, 15 Jul 2015 08:00:25 -0700 (PDT) Received: from ISOC-A1FD58.local ([92.109.76.43]) by smtp.googlemail.com with ESMTPSA id jy6sm8352902wjc.4.2015.07.15.08.00.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Jul 2015 08:00:24 -0700 (PDT) To: "Sriram, Kotikalapudi" References: <005901d0b283$ea07bd20$be173760$@ndzh.com> <55A4CB9B.2050207@gmail.com> From: Andrei Robachevsky X-Enigmail-Draft-Status: N1110 Message-ID: <55A67586.6050604@gmail.com> Date: Wed, 15 Jul 2015 17:00:22 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rb8bjcPqK7w9r3rRQLBw7WkpwPpbVVpMl" Archived-At: Cc: idr wg list , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] draft-sriram-idr-route-leak-detection-mitigation: difference between a peer and a customer X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 15:00:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rb8bjcPqK7w9r3rRQLBw7WkpwPpbVVpMl Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thank you for your response, Sriram. Let me understand the semantics of the RLP field better. I am assuming that it indicates that a leak happened somewhere in the path, not necessarily at the adjacent AS (your customer or your peer). If this is indeed so, the only case I can think of when an RLP-marked update is not a leak, is when it came from the upstream. And if we follow the same logic an RLP-marked update from the upstream can still be a leak (and not just downstream announcements), but I think it would be difficult to distinguish between the two. If my considerations are correct, there are only two cases - upstreams/transit providers, for which RLP doesn't matter, and others (customers and peers) where an RLP indicates a leak and has to be dealt accordingly. Related to the latter - what would be in your opinion a reason to accept a leaked route? Is it just for reachability (i.e. only one route to the destination), or are there "legitimate" cases for route leaks? Thanks, Andrei Sriram, Kotikalapudi wrote on 15/07/15 15:03: > Andrei, >=20 > Thank you for reading the draft and offering comments -- certainly very= helpful > towards refining the proposal as well adding greater clarity in the doc= ument. >=20 >> It seems to me that sections 3.2.1. and 3.2.2. propose the same >> algorithm (modulo the BGP neighbor is a customer or a peer).=20 >=20 > Your observation is correct. It has to do with the semantics of RLP bit= s. > For now, we have RLP =3D 00 (default; nothing said) and RLP =3D 01 ('do= not propagate up'). > 'Do not propagate up' certainly means that the update should not subseq= uently=20 > propagate from a customer to its provider. > However, a receiver can (at its own discretion) interpret RLP =3D 01 mo= re strictly=20 > to mean 'do not propagate to provider or peer'.=20 > That is because if an ISP is not supposed to forward an update with RLP= =3D 01=20 > 'up' to a provider, then normally it should not forward it 'laterally' = to a peer either. > So we have separated the receiver detection procedures for=20 > (a) when the update comes from a *customer* (section 3.2.1), and=20 > vs. (b) when it comes from a *peer* (section 3.2.2). > The difference is the stricter interpretation (in Section 3.2.2) of RLP= =3D 01. > Initially the attempt is to see if we can keep the RLP semantics simple= , > and still accomplish the detection objectives w.r.t. customer/peer.=20 > These two section can be merged into one if, for example,=20 > RLP =3D 01 is specified to denote 'do not propagate to provider or peer= '. =20 >=20 >> The difference in the "possible actions" (3.3.) is not clear to me eit= her. >=20 > When an update is detected and 'marked' as 'route leak' (based on secti= on 3.2.1 or 3.2.2 detection), > then the same/similar method(s) of mitigation can be applied (in the tw= o cases).=20 > The draft should not specify a mitigation method because that is left t= o operator policy. > So we describe only an *example* policy: Suspend the "prefer customer" = policy; > i.e. instead of a 'marked' update from a customer, prefer an 'unmarked'= > update from a provider or peer. Some similar policy can be applied for = a peer.=20 > Let the operator decide the actual policy to be used in each case. >=20 >> Finally, what is the proposed action when an RLP-marked update is >> received from an upstream? >=20 > Good point. The draft currently does not discuss this. If the customer > is single-homed and does not have any alternate path for the prefix, > then it would install the route learned from its sole provider even if = it is 'marked'. > If the customer is multi-homed, it should prefer an 'unmarked' update f= rom=20 > one provider over a 'marked' update from another provider. Etc. > Again these actions/methods are left to operator policy. > However, in the next revision, we will include a subsection to outline = this. =20 >=20 > Sriram >=20 --rb8bjcPqK7w9r3rRQLBw7WkpwPpbVVpMl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlWmdYcACgkQljz5tZmtij924ACgs6hMN15YAZHGUC20R2GeqrLX o70AoMmjnz+XiWAofKN0hMt7UiX72f2O =ZeeR -----END PGP SIGNATURE----- --rb8bjcPqK7w9r3rRQLBw7WkpwPpbVVpMl-- From nobody Wed Jul 15 13:41:55 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2B01B2B05 for ; Wed, 15 Jul 2015 13:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QamMvvSIG-g4 for ; Wed, 15 Jul 2015 13:41:44 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6F9B1B2AFE for ; Wed, 15 Jul 2015 13:41:44 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:41720 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZFTUt-0005Tb-9T for sidr@ietf.org; Wed, 15 Jul 2015 16:41:43 -0400 References: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> <556CF530.4010408@ops-netman.net> <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> <559A8B31.50408@bbn.com> <559BF347.60609@bbn.com> <9DFC9C7C-CBFC-427C-8589-C13457EDD091@tislabs.com> Cc: sidr wg list From: Stephen Kent Message-ID: <55A6C585.6060602@bbn.com> Date: Wed, 15 Jul 2015 16:41:41 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <9DFC9C7C-CBFC-427C-8589-C13457EDD091@tislabs.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 20:41:52 -0000 Sandy, > On Jul 7, 2015, at 11:41 AM, Stephen Kent wrote: > >>>> - I think the doc should distinguish between transfers of "live" >>>> address space vs. transfers of space that is not currently in >>>> use. The former are more complex tan the latter and thus merit a >>>> different discussion >>> operationally, you do not have a solid proof of [dis-]use. and i do not >>> see how they should be treated differently. prudence says do it as if it >>> is live. >> The TAO I-D describes the differences in constraints imposed on the >> transfer process based on live vs. unused space. Unused is much, much easier >> and seems to be the most common type of space transferred across RIR boundaries. >> Thus it seems worth considering the distinction in a discussion of the problem. > > I wasn't looking for this, but I happened upon an APNIC page that describes transfer processes for three cases: unused space, for M&A, and for historical resources. Answering their questions to get to the right case never got me to a page that is explicitly about transferring live address space. M&A are likely to be live and historical could be live, I suppose. It's interesting that they make these distinctions, presumably for policy purposes. > i don't find anything in their policy manual that says transfers are only for unused space. I did not suggested that. What I said was that it seems likely that the growing number of address space transfers will be for unused space, IF the reason for the transfer is a sale of assets. (This seems to be the rationale cited for the growth in v4 address space transfers.) And, I noted that it seems attractive to engineer a solution to for unused space transfers IF the solution is simpler than for live space transfers (it is), and IF unused space transfers are the common case. Randy's view is that it is preferable to engineer a single solution that is agnostic about whether the address space is in use or not, even if that is a more complex solution. His rationale seems to be that its safer to treat all space as in use, so as to avoid the damage to users that arises if the entity transferring the space can't properly classify it properly. Steve From nobody Wed Jul 15 14:21:02 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22E81A8851; Wed, 15 Jul 2015 14:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lo6k6XRTwlAV; Wed, 15 Jul 2015 14:20:59 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0771.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::771]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E441A873C; Wed, 15 Jul 2015 14:20:59 -0700 (PDT) Received: from CY1PR09MB0795.namprd09.prod.outlook.com (10.163.43.145) by CY1PR09MB0377.namprd09.prod.outlook.com (10.160.147.14) with Microsoft SMTP Server (TLS) id 15.1.213.14; Wed, 15 Jul 2015 21:20:39 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by CY1PR09MB0795.namprd09.prod.outlook.com (10.163.43.145) with Microsoft SMTP Server (TLS) id 15.1.213.14; Wed, 15 Jul 2015 21:20:38 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0219.000; Wed, 15 Jul 2015 21:20:38 +0000 From: "Sriram, Kotikalapudi" To: Andrei Robachevsky Thread-Topic: draft-sriram-idr-route-leak-detection-mitigation: difference between a peer and a customer Thread-Index: AQHQvhEfZNxwzI8V2ECO5TICdbuD2Z3cfN/4gAAk8ACAAGNnMA== Date: Wed, 15 Jul 2015 21:20:38 +0000 Message-ID: References: <005901d0b283$ea07bd20$be173760$@ndzh.com> <55A4CB9B.2050207@gmail.com> <55A67586.6050604@gmail.com> In-Reply-To: <55A67586.6050604@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-originating-ip: [129.6.140.100] x-microsoft-exchange-diagnostics: 1; CY1PR09MB0795; 24:SLWKECSJpE7V9pVNXfLI17B9A/SsI4LK5nIxK3AOGakzFAsnsCaSBg5Z1IOnAw/ooZN2W/eoFgVdDD05AU2TcjDGUDr3aqTySzM0Ya3Cz+A=; 20:sOJr3S0yz5tagYHdgQh5mGfeGB/PYHRjyLq9QYN+d4/wzWdJOpEjHLmmp7eyK3dRMuHnBIb7jyXbh0xVakiAGA== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0795; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0377; cy1pr09mb0795: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0795; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0795; x-forefront-prvs: 0638FD5066 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(122556002)(189998001)(40100003)(74316001)(2656002)(86362001)(87936001)(62966003)(77156002)(106116001)(92566002)(5001960100002)(66066001)(5002640100001)(46102003)(93886004)(77096005)(33656002)(102836002)(2900100001)(2950100001)(50986999)(230783001)(54356999)(76176999)(76576001)(5003600100002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0795; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2015 21:20:38.2873 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0795 X-Microsoft-Exchange-Diagnostics: 1; CY1PR09MB0377; 2:pbOJ3YoSkywa2XNrIGKi3DpxY8/J0uSJZCaJ/HzYm3q/V8kLx47n1dL8qe10zqV1; 3:qlH7jr6CtaK2xlw3V1DKvEqwyF0rADFadkTY+VygURecjko0YYz3yOlwC7jywwVUk3WFOTdywV8rLTkXUGuJyiYfCkwuVNhYG7wS2A+PglNoSVxrYhjEeKdUk4jBFcyvf0bKYabhExkrWzYmlpqEyQ==; 25:HCPx1MxiqyjUa2lBthc3Pelrtw5vsbEQNpbbMpKRnKIE6i58PvMvN0mOkcUyzJ1IqswBVDxeV3LhjEZZC/ZgLv2gLMPK8C3pwWtcMJ6LS9CGUgckPN6F4VwFjL868wNkYE2R/3YoblFVM06kLTMJHtYsT+CxiG1wf9xVP4wfyIugt5n90AvBocqNnpxYpsI/l9n9ebkb+FE+LYJXNOyD1ea7RcT9rBTk2eqSc8GAvwtTK3CM66+GK8soK8Njncc63DAgjMqt6e1iTQim2aqL2Q==; 20:BnQCZ0tbt/kgJi7t3Zs/c3ak6KTj3KJPOCSIHqrbO2zupnibBT2dY92/q/966Rvcg4KTIT+Tv78n25icB5+9jg==; 23:H6ye0PB/Khn4ENnv6VdNfNsC9Yc6I4W24vznwjQEQIqcZR/Y/UoNcv/DzpHHT5W8+DSBdslyp0MJL0pV514qa2deDBW4aUehPWy7DcJ4/LC7LCQFLSljZkEp5/BRXTgpy9t72uTtq/+uBplpeqJfncIz47CXLZLEr+KyHu3WNXuQk4RYVDANd8X6QHGtiHQtPknK6sKItweUk/tvbrqvy/lKOBs1LBUBgy5I9he/S1YI5l0rkCEckoc27GCYpvtk CY1PR09MB0377: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: nist.gov Archived-At: Cc: idr wg list , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] draft-sriram-idr-route-leak-detection-mitigation: difference between a peer and a customer X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 21:21:01 -0000 >Let me understand the semantics of the RLP field better. I am assuming >that it indicates that a leak happened somewhere in the path,=20 RLP field does not indicate (or encode) that a *leak happened*. It merely facilitates a receiving router to detect if an update from a sending router (an adjacent AS) is a route leak.=20 Example 1: Route for prefix P propagates as follows:=20 P---AS A ---{ RLP(AB) =3D 01 }---> AS B (cust. of A) ---{ RLP(BC) =3D 01,= RLP(AB) =3D 01 }---> AS C (cust. of B)=20 Sequentially, B is a customer of A, and C is a customer of B. =20 The expression in wiggly brackets {} shows the RLP values in the prefix upd= ate. A transitive RLP field is added in the update for each hop in the path.=20 Each AS sets an RLP value for its hop to the next AS for the route it forwa= rds for prefix P. RLP =3D 01 indicates that the update SHOULD NOT be sent 'up' to a provider = (or=20 'laterally' to a peer), but it is allowed to forward the update to a custom= er. So no one in this Example 1 detects a route leak. There is no route leak.=20 Example 2: P---AS A ---{ RLP(AB) =3D01 } ---> AS B (cust. of A) --- { RLP(AB) =3D01,= RLP(BC) =3D00) } ---> AS C (provider of B) B (in the middle) has two providers A and C. B learned a route from A and is leaking the route to C, and C detects it. C looks at RLP(AB) =3D 01, and therefore it knows that B's update is a leak= . So C marks B's update as a route leak. =20 >not necessarily at the adjacent AS (your customer or your peer).=20 As in the examples above, the receiver is only detecting if the update from= =20 its adjacent router is a route leak. It does so by looking=20 at NOT the RLP field value set by the adjacent router=20 but the RLP field values set by the ASes that preceded it. >If this is indeed so, the only case I can think of when an RLP-marked upda= te is not >a leak, is when it came from the upstream. May be this question goes away in light of the proper understanding=20 of RLP field values provided above. It is true that an upstream provider cannot leak any prefix route to its customer by definition. Any prefix routes that the upstream has accepted=20 (after applying route leak detection/mitigation etc.), the upstream usually= send all those routes to its customer (except those learned from that customer).=20 So in general, a customer need not try to detect route leak from its upstre= am provider (keep in mind that we are talking about the relationships on per prefix bas= is). (Please ignore what I said in my previous reply to you about detecting rout= e leaks from a provider; the last paragraph.) We have not used the term "RLP-marked" anywhere in the draft. So I don't know what exactly you mean by it. But hopefully the above explanations clarify things for you. When we say an update is 'marked', it simply means that it was detected=20 to be a route leak (as it was received from a neighbor AS).=20 >And if we follow the same logic an RLP-marked update from the upstream >can still be a leak (and not just downstream announcements), but I think >it would be difficult to distinguish between the two. > >If my considerations are correct, there are only two cases - >upstreams/transit providers, for which RLP doesn't matter, and others >(customers and peers) where an RLP indicates a leak and has to be dealt >accordingly. Yes, I agree that detecting route leaks from customers/peers matters. Detecting route leaks from upstreams/transit providers does not really matt= er (as explained above). >Related to the latter - what would be in your opinion a reason to accept >a leaked route? Is it just for reachability (i.e. only one route to the >destination), or are there "legitimate" cases for route leaks? In this discussion and the draft, we have not called anything a "legitimate" route leak. But some customer ASes could make mistakes. For example, if X is single-homed stub customer of Y and Y is a customer of= Z, and if X sets RLP =3D 01 by mistake in its prefix update to Y, then Z detec= ts and marks the prefix route from Y as a route leak.=20 Z will not have any alternate path for that prefix because X is single-home= d stub. In this case, Z may accept the update for reachability even though it was detected to be route leak. Again, we don't specify this.=20 We only specify the detection method, not the mitigation policy. =20 Thank you. Sriram From nobody Wed Jul 15 16:44:19 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7039C1B34A6 for ; Wed, 15 Jul 2015 16:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlkRoShRzQAp for ; Wed, 15 Jul 2015 16:44:14 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AD541B2F36 for ; Wed, 15 Jul 2015 16:44:14 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:37645) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZFWLS-00072q-QU; Wed, 15 Jul 2015 19:44:10 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id 9C3C23FFD7 Message-ID: <55A6F046.1090109@bbn.com> Date: Wed, 15 Jul 2015 19:44:06 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Sandra Murphy References: <20150515192215.5707.56279.idtracker@ietfa.amsl.com> <555CE890.1090802@bbn.com> <462B3352-DAA9-476C-AA33-C517C515B7F0@tislabs.com> <555E5E4A.5080303@bbn.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SS1t4JrM2Qe0LMRPNjswTrd81iHsNjxRW" Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rfc6485bis-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 23:44:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SS1t4JrM2Qe0LMRPNjswTrd81iHsNjxRW Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-07-03 06:39, Sandra Murphy wrote: > Speaking as regular ol' member > On May 21, 2015, at 6:38 PM, Richard Hansen wrote: >=20 >> On 2015-05-21 17:08, Sandra Murphy wrote: >>> On May 20, 2015, at 4:03 PM, Richard Hansen wrote: >>>> * section 8 is incorrect -- sha256WithRSAEncryption does not >>>> violate the CMS RFCs (implementations just choose to use >>>> rsaEncryption instead, which has the same meaning in this >>>> context) >>> >> [...] >>> >>> Perhaps you are concerned mostly about the terms being used? But the= >>> rfc6485bis document does not say "violate" and I believe that what it= >>> says agrees with the message above. If you don't think so, you >>> should say why. >> >> This draft's Section 8 says: >> >> [...] A closer reading of >> [RFC4055] and [RFC5754] has identified that the CMS SignerInfo field= >> must support use of the rsaEncryption OID for full conformance with >> the CMS specifications, and the normative references in [RFC6485] >> inherited this requirement. >> >> The phrase "the CMS SignerInfo field must support use of the >> rsaEncryption OID" doesn't make much sense to me -- how can an OID fie= ld >> not support an OID? I'm not 100% sure what is meant here, but the nex= t >> paragraph provides a hint: >> >> [...] By conforming to the >> CMS specifications as per [RFC4055] and [RFC5754], RPKI CMS objects >> are less likely to be rejected as non-conformant with the CMS >> standards. >> >> To me, this sentence and the one above are claiming that the CMS RFCs >> say that the SignerInfo signatureAlgorithm field MUST contain >> rsaEncryption, and that we are non-conformant (violating the spec) by >> using sha256WithRSAEncryption. Neither is true. >=20 > You and I disagree here. >=20 > To be clear: our disagreement is whether the description of the > motivation for the change to RFC6485 is ambiguous or not. I feel that Section 8 is incorrect, not just unclear. (If I'm interpreting it in a way that is not intended by the authors, and I don't think I am, then this disagreement *is* just about clarity, not correctness.) >=20 > Personally, I do not consider that an important matter. The > description of the motivation does not change the specification, it > does not change implementation, and it does not confuse implementors > about implementation. I agree that Section 8 as worded does not impact implementations of *this* standard. My concern is that the current wording adds to the existing confusion surrounding the CMS signed object spec, and that people trying to understand the CMS standard will see this section and reach an incorrect conclusion. >=20 > To recap: > RFC6485 chose to mandate an algorithm id. > That choice is compliant with the CMS RFCs. > The CMS RFCs make a choice of a mandatory to implement algorithm ID. > RFC6485's choice is not the CMS mandatory to implement choice. > Unfortunately, common CMS implementations chose to support only the > CMS mandatory to implement algorithm ID. > So common CMS implementations can not be compliant with RFC6485. > By aligning our choice of mandatory algorithm ID with the mandatory > algorithm in the CMS RFCs, we make it possible for common CMS > implementations to be compliant with RFC6485. > By aligning our choice of mandatory algorithm ID with the mandatory > algorithm in the CMS RFCs, we eliminate the problem that a compliant > RPKI signed object would be rejected by the common CMS > implementations. Yes, I agree with this recap. >=20 > wrt: >=20 >> >> [...] By conforming to the >> CMS specifications as per [RFC4055] and [RFC5754], RPKI CMS objects >> are less likely to be rejected as non-conformant with the CMS >> standards. >=20 > Perhaps you are reading too much into the use of "conforming to"? There is a chance I am interpreting that sentence in a way not intended by the authors. If I am, then something should be done to reduce the difficulty of interpreting the sentence correctly. If I am not, then something should be done to correct the sentence. Either way, something should be done. > Perhaps saying "aligning with" would make it more clear to you? That's an improvement, but still not sufficient. I sent a suggested rewrite of Section 8 to the authors on 2015-05-20 with no response; here's a more minimal rewrite of just that sentence: [...] By requiring RPKI CMS signed objects to use an OID that is widely supported by existing libraries, implementations are less likely to reject valid RPKI CMS signed objects due to incomplete algorithm support. >=20 > I do not know what current CMS implementations would do if they were > presented with a RFC6485 compliant RPKI signed object. RPSTIR currently accepts either OID. Before this OID issue was raised, RPSTIR only accepted CMS signed objects that used sha256WithRSAEncryption. CMS signed objects that used rsaEncryption were rejected due to non-conformance with RFC6485. > They may indeed report the signed object is "non-conformant with the > CMS standards". I suspect the other implementations would have rejected CMS signed objects that use sha256WithRSAEncryption with "unsupported algorithm", not "non-conformant with the CMS standard" (but I can't say for sure). > So I can not say that "rejected as non-conformant with > the CMS standards" is incorrect. Error message aside, it is clear > that any RFC6485 compliant RPKI signed object (if we could find one) Before this OID issue was raised, RPSTIR's test cases generated valid CMS signed objects that used sha256WithRSAEncryption. Those test cases were changed once everyone agreed to switch to rsaEncryption. We will add a sha256WithRSAEncryption test case once the rfc6485bis dust settles (to require RPs to either accept or reject depending on what the final RFC says). In the meantime, it would be fairly trivial for us to manually generate such an object. > would be rejected by existing implementations. except RPSTIR > There might be ways to improve that "rejected as non-conformant" > phrase of the text, but I don't think it is necessarily wrong. I do, because I doubt that's an accurate reflection of history. >=20 >> From a CMS RFC conformance perspective it's perfectly OK >> for RFC6485 to require RPKI CMS object producers to use >> sha256WithRSAEncryption, but third party crypto libs didn't make it ea= sy >> for implementations to conform.=20 >=20 > My reading of the previous discussions is that it is worse than > "didn't make it easy" - the crypto libs made it *impossible* for > implementations to be compliant with RFC6485 - they did not implement > support for the algorithm RF6485 mandated. RPSTIR did support RFC6485 as written until this OID issue came up, at which point we also started accepting rsaEncryption. (In order to support sha256WithRSAEncryption we had to reinvent much of the wheel via manual ASN.1 parsing and calls to primitive crypto functions. I suspect the other RP implementations call easy-to-use high-level OpenSSL functions that don't understand sha256WithRSAEncryptio= n.) >=20 >> >>> It is found in 3370, which 5754 (one of the references) updates and >>> normatively references. >> >> I don't think that is sufficient in this case. There are multiple RFC= s >> that this document directly and indirectly references that define an >> algorithm identifier named rsaEncryption. I believe they all have the= >> same OID value, but some of them give slightly different semantics. >=20 > Really? I think that would be a very bad thing! But not our problem, = I think. The multiple meanings for rsaEncryption is not our problem, but not specifying which meaning we want *is* our problem. >=20 >> Thus, I think it's important to make it clear which definition of >> rsaEncryption is intended. >> >> For example, RFC3370 (for CMS) says that rsaEncryption is either a key= >> type identifier or a signature algorithm identifier, while RFC3279 (fo= r >> PKIX) says that it's only a key type identifier and thus not suitable >> for identifying signature algorithms in a PKIX context (you must use >> xxxWithRSAEncryption instead to specify the digest). >=20 > I think your "and thus not suitable" is a bit of a stretch. rsaEncryption can't be used to identify a signature algorithm in a PKIX certificate because it doesn't specify the hash algorithm (PKIX doesn't have a separate signature hash algorithm OID like CMS does). It can be (and is) used to identify the PKIX key type, however. > And it would appear that the existing implementations we are talking > about did not make this same interpretation - we are in this mess > because they use rsaEncryption as a signature algorithm identifier. The story with CMS is different -- and considerably more murky -- than PKIX because CMS has a separate hash OID for signatures. I asked the smime mailing list [1] if they could point me to text that clarifies the relationship between the signatureAlgorithm and digestAlgorithm fields, and what it means to choose a signatureAlgorithm OID that also specifies a digest algorithm. My conclusion is: * the CMS RFCs are woefully unclear about this * practically speaking, you should never choose a signatureAlgorithm OID that conflicts with the digestAlgorithm OID (you're asking for trouble if you pick md5WithRSAEncryption and sha-1 for the two OIDs) * assuming the digest algorithm is x, then practically speaking it shouldn't matter whether the signatureAlgorithm is xWithRSAEncryption or just rsaEncryption; implementations will probably do the same thing either way (assuming they understand both OIDs, which isn't true for sha256WithRSAEncryption) [1] http://thread.gmane.org/gmane.ietf.smime/7053 -Richard >=20 > Again, speaking as a regular ol' member. >=20 > --Sandy --SS1t4JrM2Qe0LMRPNjswTrd81iHsNjxRW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlWm8EoACgkQMs/lq+4xKKJ7UQCdHn/Te5Y4vhWOdDaka3ZquI+O OKwAn0BjGrsF0mY1bMv8rMv0nRy7SwLE =WJDV -----END PGP SIGNATURE----- --SS1t4JrM2Qe0LMRPNjswTrd81iHsNjxRW-- From nobody Thu Jul 16 01:14:04 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340CA1B3754; Thu, 16 Jul 2015 01:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_TOOL=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7c71zW9pAUPn; Thu, 16 Jul 2015 01:14:01 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD8C21B3752; Thu, 16 Jul 2015 01:14:00 -0700 (PDT) Received: by wgkl9 with SMTP id l9so51846567wgk.1; Thu, 16 Jul 2015 01:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=vTQ57BLBTJoi6YMKiB0evw0PY+AxnyQ6fAbpR1FBd8M=; b=Er/TrzCoUDYd/Lh5jrND1gqDYg1+6Ci5NjXMUN3gOQ8cAgBW2E6VD7F5D4mVgbikgq V3F2jeljaRr3hYuvTBasSOgp88V9KMHd7Qdiny4Q9IVbQCtPIytdPcid8+7JG/tF3Cod 4NLAav1ivMqtc+V4nGKPt0qsA7+6EXuue+bdF9ZAvsgcOmjWtPxJIy1Bn/d7pVDglZmZ acAQO73H1Q9UNbq/T5FKhYSJvoKW9pbmVHBxaM5vQ664VL4gIKGfMBhScZJAVE5VDc5N NxWX1GwjnFsJuRZQMzWKdkm7WIyTOznmyI5TmUdXVZpM2Qgla7A5QsIfdTLz18FEBj2B i+zA== X-Received: by 10.194.78.14 with SMTP id x14mr17096642wjw.48.1437034439551; Thu, 16 Jul 2015 01:13:59 -0700 (PDT) Received: from ISOC-A1FD58.local ([92.109.76.43]) by smtp.googlemail.com with ESMTPSA id ec19sm2297181wic.0.2015.07.16.01.13.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jul 2015 01:13:58 -0700 (PDT) To: "Sriram, Kotikalapudi" References: <005901d0b283$ea07bd20$be173760$@ndzh.com> <55A4CB9B.2050207@gmail.com> <55A67586.6050604@gmail.com> From: Andrei Robachevsky X-Enigmail-Draft-Status: N1110 Message-ID: <55A767C5.3090805@gmail.com> Date: Thu, 16 Jul 2015 10:13:57 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1JxceUR20vfWJapxxd97CeQKnOLX3EI1b" Archived-At: Cc: idr wg list , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] draft-sriram-idr-route-leak-detection-mitigation: difference between a peer and a customer X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 08:14:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1JxceUR20vfWJapxxd97CeQKnOLX3EI1b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sriram, Your explanations make it very clear, thanks. Sriram, Kotikalapudi wrote on 15/07/15 23:20: > Example 2: >=20 > P---AS A ---{ RLP(AB) =3D01 } ---> AS B (cust. of A) --- { RLP(AB) =3D= 01, RLP(BC) =3D00) } ---> AS C (provider of B) >=20 > B (in the middle) has two providers A and C. > B learned a route from A and is leaking the route to C, and C detects i= t. > C looks at RLP(AB) =3D 01, and therefore it knows that B's update is a = leak. > So C marks B's update as a route leak. =20 >=20 >> not necessarily at the adjacent AS (your customer or your peer).=20 >=20 Yes. What I meant here is a case when you extend your example to AS D (a peer or a provider of AS C). Assuming that AS C has no route-leak mitigation policy and propagates the update further, AS D may detect the leak, which happened somewhere in the path (where precisely - D does not know and does not need to know). The only thing that matters is that the update has the RLP field set to '01' indication for one or more hops (excluding the most recent) in the AS path (that is what I called the RLP-marked in my note) *and* it does not come from the upstream/transit provider. [...] >> >> If my considerations are correct, there are only two cases - >> upstreams/transit providers, for which RLP doesn't matter, and others >> (customers and peers) where an RLP indicates a leak and has to be deal= t >> accordingly. >=20 > Yes, I agree that detecting route leaks from customers/peers matters. > Detecting route leaks from upstreams/transit providers does not really = matter > (as explained above). I guess what I am arguing for is that the semantics of RLP 01 should be "propagate only down" rather than "do not propagate up" and any updates with the RLP field set from a peer or a customer should be treated as a leak. Thanks, Andrei --1JxceUR20vfWJapxxd97CeQKnOLX3EI1b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlWnZ8UACgkQljz5tZmtij/k8gCdGZaHhTy9JZV8OKsEkshVpmAl MKoAnjGca9PvMLxNTTWrDqVF8Eaphx5u =eCHk -----END PGP SIGNATURE----- --1JxceUR20vfWJapxxd97CeQKnOLX3EI1b-- From nobody Thu Jul 16 04:05:50 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47821B39A4 for ; Thu, 16 Jul 2015 04:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTIqLNtVAV-A for ; Thu, 16 Jul 2015 04:05:47 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA8CB1B39A2 for ; Thu, 16 Jul 2015 04:05:46 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id D1AD328B0041; Thu, 16 Jul 2015 07:05:45 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 745131F8035; Thu, 16 Jul 2015 07:05:45 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_5E1B013E-233C-461D-9A08-9D04CD55E542"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: Date: Thu, 16 Jul 2015 07:05:41 -0400 Message-Id: <44E7D017-9EC5-4C24-A8BE-903B5EEEE82B@tislabs.com> References: To: "Borchert, Oliver" X-Mailer: Apple Mail (2.1510) Archived-At: Cc: "sidr@ietf.org" , David Mandelberg , Sandra Murphy Subject: Re: [sidr] WGLC for drained ft-ietf-sidr-rpki-rtr-rfc6810-bis-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 11:05:48 -0000 --Apple-Mail=_5E1B013E-233C-461D-9A08-9D04CD55E542 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Could you please reply to the list and say whether you believe that the = draft-ietf-sidr-rpki-rtr-rfc6810-bis-04.txt version satisfies your = comments? It would help with the process. --Sandy On Mar 25, 2015, at 5:13 PM, "Borchert, Oliver" = wrote: > David, >=20 > A correction for my previous email, I mixed up session id and serial > number. > I think to keep it simple for version 0 - 1 switches and future = changes, a > change > Within the session id and version id should trigger a =93Cache Reset=94 = by the > cache > And the client must resynch with the server. > And yes, wording in this matter might need to be added - but still it = also > could > Be an implementation issue. >=20 > Oliver >=20 > ------------------------------------------------------------- > Oliver Borchert, Computer Scientist > National Institute of Standards and Technology > (Phone) 301.975.4856 , (Fax) 301.975.6238 >=20 >=20 >=20 >=20 >=20 > On 3/24/15, 10:58 AM, "Borchert, Oliver" = wrote: >=20 >> Isn=B9t this an implementation issue? The client either speaks 0 or = 1. As >> long as the server >> keeps track of the version for the session IMHO it does not matter if = the >> session id is >> shared? The client doesn=B9t know about it. Lets say one encounter a = new key >> and this >> Only triggers a PDU 9, the server sends send out the notification. = The >> client can but must not >> React to it anyhow. If the client reacts, the server sends an end of >> update to a version 0 >> session and all pdu 9 updates to a version 1 session. >> I don=B9t see a needed wording here. Not yet but I=8Cm open for = enlightenment. >>=20 >> Oliver >> ------------------------------------------------------------- >> Oliver Borchert, Computer Scientist >> National Institute of Standards and Technology >> (Phone) 301.975.4856 , (Fax) 301.975.6238 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 3/24/15, 10:36 AM, "David Mandelberg" = wrote: >>=20 >>> Rob and I were talking about rpki-rtr, and I came up with another >>> potential issue with switching between protocol versions. I don't = see >>> any text about whether a single session (session id and serial = numbers) >>> can be used for both version 0 and 1. If a router has a valid = version 0 >>> session, upgrades to version 1, and issues a serial query with the = same >>> session id and serial number, it's unclear what the server should = do. >>> Could we add text to the document saying that the cache MUST = maintain a >>> separate session for each protocol version it supports, and a router >>> MUST NOT attempt to reuse session information across multiple = protocol >>> versions? >>>=20 >>> -- >>> David Eric Mandelberg / dseomn >>> http://david.mandelberg.org/ >>>=20 >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_5E1B013E-233C-461D-9A08-9D04CD55E542 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVp5ALAAoJEHplpQeet0IZTBAP/RqgMI18BDc5/EQc5h/VAatN ANB28BCOCeOgNCMIk6j1x/ipRU0fIgkT53AXb8Zm96XI9PKQS0TViwSYnDD+mqwK CiXkOoNH6Tb7RUSuz27V/GfLvC9ocJECj3R0YdAgult1yPqzilhqMsGfj7+zDXAZ L1nwL2VmLwJSaUAtauc4ILcuNaPqBqFMp+1/VVauwVC+uDL2VVl/CO+bULtwDnVi vANCXLxgST5So1lx9q9zBD3xV69E26Cf05ieBXqr8dviDhDAA6kXSWLX/1BDtERI Q1knkqouVu8hQRhzlP5zbMVMbL+lA2mmrIpzlkO3OpOksPnZOD3aWHSNFA1xEjcw 7Vb7yd7dgZWM936YqGUe0/NWC01MncpYTiWPdGrpJRoufgBuCyQQHoCjFd8cXuYj GElJoun72n1c/4pazIty18bwIlsu0fJHb1pn/nF5P6j00FXWJpbiG7GS+/q0MK02 h1Vj4HM9vY15ZSBw6ysUXRYFSDRcaURY4uBMNHoQUjILOHjJh7W+9II7v1yJNnE/ WBxWdqHxUv4xpSqgr9CwbfhOWFIMutOsZDJ58q6EQEPfvEUaZhuMJL3be+tcE8N7 JZC/FgALImBuSwSyudS7UYJe+WL1emP4s8mTJdE3AY/D6a0abt7jn5wCZVNEiiWv om2Ig4nv+gfNWAev2dNk =bmcA -----END PGP SIGNATURE----- --Apple-Mail=_5E1B013E-233C-461D-9A08-9D04CD55E542-- From nobody Thu Jul 16 04:09:54 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D614C1B39B4 for ; Thu, 16 Jul 2015 04:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TS4rcRF1kshJ for ; Thu, 16 Jul 2015 04:09:51 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73C471B396D for ; Thu, 16 Jul 2015 04:09:51 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id CB75428B0041; Thu, 16 Jul 2015 07:09:50 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 5D0441F8035; Thu, 16 Jul 2015 07:09:50 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_2795CF4E-C36E-4C77-ABE9-97A355FEB1C9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: <552F3C79.8030809@bbn.com> Date: Thu, 16 Jul 2015 07:09:52 -0400 Message-Id: References: <552F3C79.8030809@bbn.com> To: Richard Hansen X-Mailer: Apple Mail (2.1510) Archived-At: Cc: sidr@ietf.org, Sandra Murphy Subject: Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 11:09:54 -0000 --Apple-Mail=_2795CF4E-C36E-4C77-ABE9-97A355FEB1C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Could you please respond to the list and say whether the = draft-ietf-sidr-rpki-rtr-rfc6810-bis-04.txt version satisfies your = comments? It would help the process. --Sandy On Apr 16, 2015, at 12:37 AM, Richard Hansen wrote: > Hi all, >=20 > Here are my comments, some of which overlap with what others have = said: >=20 > * The name of the draft says "rfc6810-bis", but the XML tag > doesn't have an obsoletes=3D"6810" attribute. And I don't think it > should -- Section 7 has a normative reference to RFC6810 when > discussing downgrades to version 0, which isn't specified in this > document. So perhaps the title and abstract should be worded to > make it clear that this is not a replacement for RFC6810, but > rather a new version of the protocol specified in RFC6810. (Or > maybe this document should be worded as an update to RFC6810?) > (Also mentioned in = .) >=20 > * The protocol is mostly query-response lockstep, but there are no > timeouts. If the cache is taking unreasonably long to respond to a > query, what should the router do? How long is unreasonably long? > If timeouts are added, should the router reset its timeout timer > for each response PDU (Cache Response, payload, and End of Data), > or only after it receives the End of Data PDU? >=20 > * Should the cache time out the router if the router doesn't send a > Query soon after connecting? >=20 > * Notify/Query race: What is supposed to happen if the router sees a > Serial Notify right after it sends a Serial Query or Reset Query? > This could happen if the two are sent at the same time -- the > messages will cross paths and the router might think that the > Serial Notify is an erroneous response to the query, and that the > subsequent Cache Response came out of the blue. >=20 > * The name "Session ID" is misleading. Section 2 clearly defines it, > but unless you pay attention to the definition it's easy to assume > that "session" refers to the transport session with the peer. I > would prefer a different name such as "Cache Instance ID", though > that name may be insufficient when you consider the protocol > upgrade problem brought up by David in > . Maybe something > like "Data Series ID"? >=20 > * In Section 5.1 (fields) under "Session ID", what is the definition > of "completely drop the session"? Do you mean send a fatal error > PDU, do a transport-layer disconnect, and let the router reconnect > (possibly to a more preferred cache)? Or do you mean send a Cache > Reset (cache->router) or Reset Query (router->cache) and continue > the existing transport session? Or is either reaction acceptable? >=20 > * What is the definition of "payload PDU", mentioned in Sections 5.3, > 5.5, 8.1, 8.2, and 8.3? (I assume it means IPv4 Prefix, IPv6 > Prefix, and Router Key, but it should be explicitly stated.) >=20 > * Suppose an IPv4 Prefix was announced in serial 5 and withdrawn in > serial 6, and a router does a Serial Query against serial 4. Is > it OK if the cache elides the announce/withdraw pair? MUST it? If > it doesn't, it seems like the cache MUST send the payload PDUs in > serial number order, and the router MUST process the payload PDUs = in > serial number order (which implies that the transport MUST provide > in-order delivery of the PDUs because the router has no idea which > PDUs correspond to which serial number). >=20 > * Section 5.1 (fields) says that the serial number is the serial > number of the cache, but Section 5.3 (Serial Query) talks about > serial numbers as if they are properties of a PDU. Perhaps 5.3 > should be worded like: >=20 > The router sends a Serial Query to ask the cache for the > announcements and withdrawals that have occurred since the > Serial Number in the Serial Query. >=20 > Section 5.5 (Cache Response) has similarly problematic wording. >=20 > * The two sentences in 5.3 (Serial Query) paragraph 2 seem to > contradict each other in the case where there are no (net?) > changes: The first sentence suggests that the cache sends a Cache > Response (maybe followed by something?), while the second suggests > that it only sends an End of Data (no Cache Response). I think the > intention is for the cache to send a Cache Response immediately > followed by an End of Data. Is that correct? >=20 > * I don't think the set of valid responses to a Query (Reset or > Serial) is clearly specified. I think the intention is for these > to be the only valid responses: >=20 > - Reset Query: > * Cache Response followed by 0 or more payload PDUs followed > by End of Data > * Error Report > - Serial Query: > * Cache Response followed by 0 or more payload PDUs followed > by End of Data > * Error Report > * Cache Reset >=20 > Is this correct? >=20 > * Is there a particular reason for omitting a payload PDU count field > from the Cache Response PDU? If one was present, the router could > pre-allocate an appropriate amount of memory to handle the payload > PDUs (and perform additional sanity checks). >=20 > I guess a PDU count field would prevent an implementation from > opportunistically sending additional PDUs if there happened to be a > serial number bump during the middle of a Cache Response. > (Instead, the cache would have to follow the End of Data PDU with a > Serial Notify, which is almost as good.) >=20 > * Section 5.6 (IPv4 Prefix) mentions duplicates, but are redundant > entries OK? Examples: > - {65536,192.0.2.0/24-26} and {65536,192.0.2.0/26-26} (the latter > is redundant) > - {65536,192.0.2.0/24-26} and {65536,192.0.2.0/24-25} (the latter > is redundant) >=20 > * The fixed-length SKI field doesn't permit algorithm changes. Note > that there has been some discussion about using SHA-256 for the SKI > and AKI fields for the RFC6487(bis) profile (I'm guessing that's > probably not going to happen, but still...). > (Also mentioned in = .) >=20 > * Section 5.11 (Error Report) says that Error Reports are only sent > as responses to other PDUs. Why the restriction? This prevents a > side from raising a timeout error, and it prevents the cache from > raising an internal error if a problem is detected when it's time > to send a Serial Notify. >=20 > * If error reports are only sent as responses to other PDUs, how is > it possible for an Error Report to not be associated with the PDU > to which it is responding? (Section 5.11 paragraph 4) >=20 > * For version negotiation, what is supposed to happen if the router > starts with a PDU with version > 1? There is an Unsupported > Protocol Version error type, but nothing requires that to be sent. >=20 > * Suppose a router connects and issues a v0 Query. If the cache > doesn't support protocol v0, Section 7 says it MUST either > downgrade or disconnect. Can it issue an Error Report before > disconnecting? I would prefer it if the server MUST issue an > Unsupported Protocol Version Error Report before disconnecting. >=20 > * The second-to-last paragraph of Section 10 talks about deleting > data from a cache when it has been unable to refresh from that > cache for twice the polling period (by default). Why not have the > time to delete equal the Expire Interval as specified in Section 6? >=20 > Thanks, > Richard >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_2795CF4E-C36E-4C77-ABE9-97A355FEB1C9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVp5EAAAoJEHplpQeet0IZpeMP/0iVLxY2UnK85XP1utoktwmr QfQiDR1ItSpR3OHjzCTHMd3HHi64PIqAj6kemsCD3WQN9iRISelVeF/xFofAlGI7 hgnTiGmGJFQSzvQVrViJOQNivY+mrbVmJPebJ5yiE+mvehtfAfTqI/u0cI/WiW6u LTw3jLsThqaNkFZ3MXBAZ9Bp4TkxnHNj0Lt+uqpwgRtS80/4Z/YGpuOnk6rRUrGH D2nvRFzH+pFlC0GEM9MUgPYIv+rN7fktadW1s8N8Q6ahqKpJFDfA1q6Hxikal9vH 5eNFS5JbJ6JYUbOAOnua3uJGeACoUVe9abe/vbN1Crrf46bjDllD94DuUEIf8Fnd 8a7X59hXM/BdJeCj+1icXIcQ4mDFDYdoQ15r0s1M1tcXJsTcINNJOo6oVqpFC9St bdRxPJJjTNy3XbacCDd+QM3EGLhZM+tqFK34HdNu+p6agTCLlfUkHm5y9W2LeQMn WY0T8AvmerA9tTNrPsibwHuHwJbdVyFu/LLdp6R0A+kSygLBWryhPk2N8hF4gaqH tpPktVvd9xrNtmqru4/4RQCn3CjqpwlUg2vXRGQSRw20416jD4LkrstxDfdOCNeU d2jAs7mBEDktsof0mwCKhtCA56iR0ko5DT5nv28rmULIh7tBp5HEYXdUFQidWrjL GmF64MJPHzbUTcWA0mb5 =Gryw -----END PGP SIGNATURE----- --Apple-Mail=_2795CF4E-C36E-4C77-ABE9-97A355FEB1C9-- From nobody Thu Jul 16 06:18:43 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D931B3AED for ; Thu, 16 Jul 2015 06:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXwi-3E9j1Mi for ; Thu, 16 Jul 2015 06:18:36 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6621B3AE0 for ; Thu, 16 Jul 2015 06:18:36 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id BC26A213B1F; Thu, 16 Jul 2015 09:18:35 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id 3CF33213A02; Thu, 16 Jul 2015 09:18:35 -0400 (EDT) Received: from CHACAS02.corp.arin.net (10.1.30.108) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.210.2; Thu, 16 Jul 2015 09:25:35 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS02.corp.arin.net ([fe80::54ae:f9de:2f8b:1072%12]) with mapi id 14.03.0224.002; Thu, 16 Jul 2015 09:18:34 -0400 From: Andy Newton To: Stephen Kent Thread-Topic: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt Thread-Index: AQHQuEvNHLMrleBUIUuX/9bvjtuFEZ3QaWKAgAGwwwCACzWggIABFoQA Date: Thu, 16 Jul 2015 13:18:33 +0000 Message-ID: <8BE719A0-0EC1-4E35-8BAD-A64E06D0979C@arin.net> References: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> <556CF530.4010408@ops-netman.net> <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> <559A8B31.50408@bbn.com> <559BF347.60609@bbn.com> <9DFC9C7C-CBFC-427C-8589-C13457EDD091@tislabs.com> <55A6C585.6060602@bbn.com> In-Reply-To: <55A6C585.6060602@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: multipart/alternative; boundary="_000_8BE719A00EC14E358BADA64E06D0979Carinnet_" MIME-Version: 1.0 Archived-At: Cc: sidr wg list Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 13:18:43 -0000 --_000_8BE719A00EC14E358BADA64E06D0979Carinnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBKdWwgMTUsIDIwMTUsIGF0IDQ6NDEgUE0sIFN0ZXBoZW4gS2VudCA8a2VudEBiYm4uY29t PG1haWx0bzprZW50QGJibi5jb20+PiB3cm90ZToNCg0KUmFuZHkncyB2aWV3IGlzIHRoYXQgaXQg aXMgcHJlZmVyYWJsZSB0byBlbmdpbmVlciBhIHNpbmdsZSBzb2x1dGlvbiB0aGF0IGlzIGFnbm9z dGljDQphYm91dCB3aGV0aGVyIHRoZSBhZGRyZXNzIHNwYWNlIGlzIGluIHVzZSBvciBub3QsIGV2 ZW4gaWYgdGhhdCBpcyBhIG1vcmUgY29tcGxleA0Kc29sdXRpb24uIEhpcyByYXRpb25hbGUgc2Vl bXMgdG8gYmUgdGhhdCBpdHMgc2FmZXIgdG8gdHJlYXQgYWxsIHNwYWNlIGFzIGluIHVzZSwgc28g YXMNCnRvIGF2b2lkIHRoZSBkYW1hZ2UgdG8gdXNlcnMgdGhhdCBhcmlzZXMgaWYgdGhlIGVudGl0 eSB0cmFuc2ZlcnJpbmcgdGhlIHNwYWNlIGNhbid0DQpwcm9wZXJseSBjbGFzc2lmeSBpdCBwcm9w ZXJseS4NCg0KSXNu4oCZdCB0aGUg4oCcdW51c2Vk4oCdIHNjZW5hcmlvIHdoYXQgd2UgaGF2ZSB0 b2RheT8gV2h5IGRvIHdlIG5lZWQgYSBzb2x1dGlvbiBmb3Igc29tZXRoaW5nIHRoYXQgaXMgYWxy ZWFkeSBiZWluZyBhY2NvbXBsaXNoZWQ/DQoNCi1hbmR5DQo= --_000_8BE719A00EC14E358BADA64E06D0979Carinnet_ Content-Type: text/html; charset="utf-8" Content-ID: <19914D1909F4444BBDCC2D186DDA16A3@corp.arin.net> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBKdWwg MTUsIDIwMTUsIGF0IDQ6NDEgUE0sIFN0ZXBoZW4gS2VudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtl bnRAYmJuLmNvbSIgY2xhc3M9IiI+a2VudEBiYm4uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8 YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRv OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlu bGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+UmFuZHkncw0KIHZpZXcgaXMgdGhhdCBpdCBpcyBw cmVmZXJhYmxlIHRvIGVuZ2luZWVyIGEgc2luZ2xlIHNvbHV0aW9uIHRoYXQgaXMgYWdub3N0aWM8 L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRv OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlu bGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+YWJvdXQNCiB3aGV0aGVyIHRoZSBhZGRyZXNzIHNw YWNlIGlzIGluIHVzZSBvciBub3QsIGV2ZW4gaWYgdGhhdCBpcyBhIG1vcmUgY29tcGxleDwvc3Bh bj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5l ICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5zb2x1dGlvbi4NCiBIaXMgcmF0aW9uYWxlIHNlZW1zIHRv IGJlIHRoYXQgaXRzIHNhZmVyIHRvIHRyZWF0IGFsbCBzcGFjZSBhcyBpbiB1c2UsIHNvIGFzPC9z cGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5z OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxp bmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPnRvDQogYXZvaWQgdGhlIGRhbWFnZSB0byB1c2VycyB0 aGF0IGFyaXNlcyBpZiB0aGUgZW50aXR5IHRyYW5zZmVycmluZyB0aGUgc3BhY2UgY2FuJ3Q8L3Nw YW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6 IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGlu ZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+cHJvcGVybHkNCiBjbGFzc2lmeSBpdCBwcm9wZXJseS48 L3NwYW4+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+SXNu4oCZdCB0aGUg4oCcdW51c2Vk4oCdIHNjZW5hcmlvIHdoYXQgd2UgaGF2ZSB0 b2RheT8gV2h5IGRvIHdlIG5lZWQgYSBzb2x1dGlvbiBmb3Igc29tZXRoaW5nIHRoYXQgaXMgYWxy ZWFkeSBiZWluZyBhY2NvbXBsaXNoZWQ/PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4tYW5keTwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8BE719A00EC14E358BADA64E06D0979Carinnet_-- From nobody Thu Jul 16 06:56:45 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467BB1B3BF2 for ; Thu, 16 Jul 2015 06:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eSCz54dIzlF for ; Thu, 16 Jul 2015 06:56:41 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B85CC1B3BB3 for ; Thu, 16 Jul 2015 06:56:41 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:53546 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZFjeP-000PBc-CC; Thu, 16 Jul 2015 09:56:37 -0400 To: Andy Newton References: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> <556CF530.4010408@ops-netman.net> <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> <559A8B31.50408@bbn.com> <559BF347.60609@bbn.com> <9DFC9C7C-CBFC-427C-8589-C13457EDD091@tislabs.com> <55A6C585.6060602@bbn.com> <8BE719A0-0EC1-4E35-8BAD-A64E06D0979C@arin.net> From: Stephen Kent Message-ID: <55A7B814.1020509@bbn.com> Date: Thu, 16 Jul 2015 09:56:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <8BE719A0-0EC1-4E35-8BAD-A64E06D0979C@arin.net> Content-Type: multipart/alternative; boundary="------------080209060600020208080307" Archived-At: Cc: sidr wg list Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 13:56:44 -0000 This is a multi-part message in MIME format. --------------080209060600020208080307 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Andy, The context for the discussion is address space transfer in the RPKI context. We don't have an RFC describing how to do that, AFAIK. So, when you say that this is the scenario we have today, to what are you referring? Steve > >> On Jul 15, 2015, at 4:41 PM, Stephen Kent > > wrote: >> >> Randy's view is that it is preferable to engineer a single solution >> that is agnostic >> about whether the address space is in use or not, even if that is a >> more complex >> solution. His rationale seems to be that its safer to treat all space >> as in use, so as >> to avoid the damage to users that arises if the entity transferring >> the space can't >> properly classify it properly. > > Isn’t the “unused” scenario what we have today? Why do we need a > solution for something that is already being accomplished? > > -andy --------------080209060600020208080307 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Andy,

The context for the discussion is address space transfer in the RPKI context.
We don't have an RFC describing how to do that, AFAIK. So, when you say that
this is the scenario we have today, to what are you referring?

Steve

On Jul 15, 2015, at 4:41 PM, Stephen Kent <kent@bbn.com> wrote:

Randy's view is that it is preferable to engineer a single solution that is agnostic
about whether the address space is in use or not, even if that is a more complex
solution. His rationale seems to be that its safer to treat all space as in use, so as
to avoid the damage to users that arises if the entity transferring the space can't
properly classify it properly.

Isn’t the “unused” scenario what we have today? Why do we need a solution for something that is already being accomplished?

-andy

--------------080209060600020208080307-- From nobody Thu Jul 16 10:04:09 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583CD1ACEA2 for ; Thu, 16 Jul 2015 10:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCfTFK6ZAU5M for ; Thu, 16 Jul 2015 10:04:07 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC7C1ACE9F for ; Thu, 16 Jul 2015 10:04:05 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 13F8D213A36; Thu, 16 Jul 2015 13:04:05 -0400 (EDT) Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id 5D5A2213A30; Thu, 16 Jul 2015 13:04:04 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.210.2; Thu, 16 Jul 2015 13:10:07 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0224.002; Thu, 16 Jul 2015 13:04:03 -0400 From: Andy Newton To: Stephen Kent Thread-Topic: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt Thread-Index: AQHQuEvNHLMrleBUIUuX/9bvjtuFEZ3QaWKAgAGwwwCACzWggIABFoQAgAAKowCAADRcAA== Date: Thu, 16 Jul 2015 17:04:03 +0000 Message-ID: <6FD0DC29-9169-44D7-9152-2F1C0E0458A1@arin.net> References: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> <556CF530.4010408@ops-netman.net> <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> <559A8B31.50408@bbn.com> <559BF347.60609@bbn.com> <9DFC9C7C-CBFC-427C-8589-C13457EDD091@tislabs.com> <55A6C585.6060602@bbn.com> <8BE719A0-0EC1-4E35-8BAD-A64E06D0979C@arin.net> <55A7B814.1020509@bbn.com> In-Reply-To: <55A7B814.1020509@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.34.130] Content-Type: multipart/alternative; boundary="_000_6FD0DC29916944D791522F1C0E0458A1arinnet_" MIME-Version: 1.0 Archived-At: Cc: sidr wg list Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 17:04:08 -0000 --_000_6FD0DC29916944D791522F1C0E0458A1arinnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBKdWwgMTYsIDIwMTUsIGF0IDk6NTYgQU0sIFN0ZXBoZW4gS2VudCA8a2VudEBiYm4uY29t PG1haWx0bzprZW50QGJibi5jb20+PiB3cm90ZToNCg0KQW5keSwNCg0KVGhlIGNvbnRleHQgZm9y IHRoZSBkaXNjdXNzaW9uIGlzIGFkZHJlc3Mgc3BhY2UgdHJhbnNmZXIgaW4gdGhlIFJQS0kgY29u dGV4dC4NCldlIGRvbid0IGhhdmUgYW4gUkZDIGRlc2NyaWJpbmcgaG93IHRvIGRvIHRoYXQsIEFG QUlLLiBTbywgd2hlbiB5b3Ugc2F5IHRoYXQNCnRoaXMgaXMgdGhlIHNjZW5hcmlvIHdlIGhhdmUg dG9kYXksIHRvIHdoYXQgYXJlIHlvdSByZWZlcnJpbmc/DQoNClN0ZXZlDQoNCk9uIEp1bCAxNSwg MjAxNSwgYXQgNDo0MSBQTSwgU3RlcGhlbiBLZW50IDw8bWFpbHRvOmtlbnRAYmJuLmNvbT5rZW50 QGJibi5jb208bWFpbHRvOmtlbnRAYmJuLmNvbT4+IHdyb3RlOg0KDQpSYW5keSdzIHZpZXcgaXMg dGhhdCBpdCBpcyBwcmVmZXJhYmxlIHRvIGVuZ2luZWVyIGEgc2luZ2xlIHNvbHV0aW9uIHRoYXQg aXMgYWdub3N0aWMNCmFib3V0IHdoZXRoZXIgdGhlIGFkZHJlc3Mgc3BhY2UgaXMgaW4gdXNlIG9y IG5vdCwgZXZlbiBpZiB0aGF0IGlzIGEgbW9yZSBjb21wbGV4DQpzb2x1dGlvbi4gSGlzIHJhdGlv bmFsZSBzZWVtcyB0byBiZSB0aGF0IGl0cyBzYWZlciB0byB0cmVhdCBhbGwgc3BhY2UgYXMgaW4g dXNlLCBzbyBhcw0KdG8gYXZvaWQgdGhlIGRhbWFnZSB0byB1c2VycyB0aGF0IGFyaXNlcyBpZiB0 aGUgZW50aXR5IHRyYW5zZmVycmluZyB0aGUgc3BhY2UgY2FuJ3QNCnByb3Blcmx5IGNsYXNzaWZ5 IGl0IHByb3Blcmx5Lg0KDQpJc27igJl0IHRoZSDigJx1bnVzZWTigJ0gc2NlbmFyaW8gd2hhdCB3 ZSBoYXZlIHRvZGF5PyBXaHkgZG8gd2UgbmVlZCBhIHNvbHV0aW9uIGZvciBzb21ldGhpbmcgdGhh dCBpcyBhbHJlYWR5IGJlaW5nIGFjY29tcGxpc2hlZD8NCg0KLWFuZHkNCg0KDQpTdGV2ZSwNCg0K R2l2ZW4gd2hhdCBJIHNhaWQgaW5pdGlhbGx5IGluIHRoaXMgdGhyZWFkLCBJIHRob3VnaHQgd2Ug d2VyZSB0YWxraW5nIGFib3V0IHRoZSBzYW1lIHRoaW5nLiBJIGd1ZXNzIG5vdC4gV2UgY291bGQg dGVhc2UgdGhpcyBhcGFydCwgYnV0IGlzIGl0IHdvcnRoIGl0IGlmIOKAnFJhbmR54oCZcyB2aWV3 4oCdIGNvdmVycyBhbGwgc2l0dWF0aW9ucz8NCg0KLWFuZHkNCg== --_000_6FD0DC29916944D791522F1C0E0458A1arinnet_ Content-Type: text/html; charset="utf-8" Content-ID: <1B909BC67C77424FA1E969F54A64DCD4@corp.arin.net> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+T24gSnVsIDE2LCAyMDE1LCBhdCA5OjU2IEFNLCBTdGVwaGVuIEtlbnQg Jmx0OzxhIGhyZWY9Im1haWx0bzprZW50QGJibi5jb20iIGNsYXNzPSIiPmtlbnRAYmJuLmNvbTwv YT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5l Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGJnY29sb3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAi IGNsYXNzPSIiPkFuZHksPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIGNvbnRleHQg Zm9yIHRoZSBkaXNjdXNzaW9uIGlzIGFkZHJlc3Mgc3BhY2UgdHJhbnNmZXIgaW4gdGhlIFJQS0kg Y29udGV4dC48YnIgY2xhc3M9IiI+DQpXZSBkb24ndCBoYXZlIGFuIFJGQyBkZXNjcmliaW5nIGhv dyB0byBkbyB0aGF0LCBBRkFJSy4gU28sIHdoZW4geW91IHNheSB0aGF0PGJyIGNsYXNzPSIiPg0K dGhpcyBpcyB0aGUgc2NlbmFyaW8gd2UgaGF2ZSB0b2RheSwgdG8gd2hhdCBhcmUgeW91IHJlZmVy cmluZz88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJtb3otY2l0ZS1w cmVmaXgiPlN0ZXZlPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjaXRlPSJtaWQ6 OEJFNzE5QTAtMEVDMS00RTM1LThCQUQtQTY0RTA2RDA5NzlDQGFyaW4ubmV0IiB0eXBlPSJjaXRl IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gSnVsIDE1LCAyMDE1LCBhdCA0 OjQxIFBNLCBTdGVwaGVuIEtlbnQgJmx0OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0i bWFpbHRvOmtlbnRAYmJuLmNvbSIgY2xhc3M9IiI+PC9hPjxhIGNsYXNzPSJtb3otdHh0LWxpbmst YWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzprZW50QGJibi5jb20iPmtlbnRAYmJuLmNvbTwvYT4m Z3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4N CjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZToNCiAgICAgICAgICAgICAgMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQ6IG5vcm1hbDsNCiAgICAgICAgICAgICAgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6DQogICAgICAgICAgICAgIG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50Og0KICAgICAgICAgICAgICAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6DQog ICAgICAgICAgICAgIGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7DQogICAgICAgICAgICAgIGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUg IWltcG9ydGFudDsiIGNsYXNzPSIiPlJhbmR5J3MNCiB2aWV3IGlzIHRoYXQgaXQgaXMgcHJlZmVy YWJsZSB0byBlbmdpbmVlciBhIHNpbmdsZSBzb2x1dGlvbiB0aGF0IGlzIGFnbm9zdGljPC9zcGFu PjxiciBzdHlsZT0iZm9udC1mYW1pbHk6DQogICAgICAgICAgICAgIEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7DQogICAgICAgICAgICAgIGZvbnQtdmFyaWFu dDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzoNCiAgICAgICAg ICAgICAgbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFs aWduOg0KICAgICAgICAgICAgICBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7DQogICAgICAgICAgICAgIHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0 bzsgd29yZC1zcGFjaW5nOiAwcHg7DQogICAgICAgICAgICAgIC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsNCiAgICAgICAgICAgICAgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6DQogICAgICAgICAgICAgIG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsNCiAgICAgICAgICAg ICAgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7DQog ICAgICAgICAgICAgIHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87DQogICAgICAgICAgICAgIHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0Og0KICAgICAgICAgICAgICBub25lOyBkaXNwbGF5 OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPmFib3V0DQogd2hldGhlciB0aGUgYWRkcmVz cyBzcGFjZSBpcyBpbiB1c2Ugb3Igbm90LCBldmVuIGlmIHRoYXQgaXMgYSBtb3JlIGNvbXBsZXg8 L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOw0KICAgICAgICAgICAgICBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7 DQogICAgICAgICAgICAgIGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IGxpbmUtaGVpZ2h0Og0KICAgICAgICAgICAgICBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDoNCiAgICAgICAgICAgICAgMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOg0KICAgICAgICAgICAg ICBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4Ow0KICAgICAgICAgICAgICBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dDogbm9ybWFsOyBmb250LXdlaWdodDoNCiAgICAgICAgICAgICAgbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOw0KICAgICAgICAgICAgICBvcnBoYW5z OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsNCiAgICAgICAgICAg ICAgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0 bzsNCiAgICAgICAgICAgICAgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgZmxvYXQ6DQogICAgICAgICAgICAgIG5vbmU7IGRpc3BsYXk6IGlubGluZSAh aW1wb3J0YW50OyIgY2xhc3M9IiI+c29sdXRpb24uDQogSGlzIHJhdGlvbmFsZSBzZWVtcyB0byBi ZSB0aGF0IGl0cyBzYWZlciB0byB0cmVhdCBhbGwgc3BhY2UgYXMgaW4gdXNlLCBzbyBhczwvc3Bh bj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7DQogICAgICAgICAgICAgIGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsNCiAg ICAgICAgICAgICAgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg bGluZS1oZWlnaHQ6DQogICAgICAgICAgICAgIG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50Og0KICAgICAgICAgICAgICAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6DQogICAgICAgICAgICAgIGF1 dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7DQogICAgICAgICAgICAgIGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBu b3JtYWw7IGZvbnQtd2VpZ2h0Og0KICAgICAgICAgICAgICBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7DQogICAgICAgICAgICAgIG9ycGhhbnM6IGF1 dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4Ow0KICAgICAgICAgICAgICB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOw0K ICAgICAgICAgICAgICB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyBmbG9hdDoNCiAgICAgICAgICAgICAgbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBv cnRhbnQ7IiBjbGFzcz0iIj50bw0KIGF2b2lkIHRoZSBkYW1hZ2UgdG8gdXNlcnMgdGhhdCBhcmlz ZXMgaWYgdGhlIGVudGl0eSB0cmFuc2ZlcnJpbmcgdGhlIHNwYWNlIGNhbid0PC9zcGFuPjxiciBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsNCiAgICAgICAgICAgICAgZm9udC1zaXplOiAx MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOw0KICAgICAgICAg ICAgICBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhl aWdodDoNCiAgICAgICAgICAgICAgbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6DQogICAgICAgICAgICAgIDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czoNCiAgICAgICAgICAgICAgYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsN CiAgICAgICAgICAgICAgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6DQogICAgICAgICAgICAgIG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsNCiAgICAgICAgICAgICAgb3JwaGFuczogYXV0bzsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7DQogICAgICAgICAgICAgIHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87DQogICAgICAg ICAgICAgIHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IGZsb2F0Og0KICAgICAgICAgICAgICBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsi IGNsYXNzPSIiPnByb3Blcmx5DQogY2xhc3NpZnkgaXQgcHJvcGVybHkuPC9zcGFuPjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPklzbuKA mXQgdGhlIOKAnHVudXNlZOKAnSBzY2VuYXJpbyB3aGF0IHdlIGhhdmUgdG9kYXk/IFdoeSBkbyB3 ZSBuZWVkIGEgc29sdXRpb24gZm9yIHNvbWV0aGluZyB0aGF0IGlzIGFscmVhZHkgYmVpbmcgYWNj b21wbGlzaGVkPzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+LWFuZHk8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+U3RldmUsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5HaXZlbiB3aGF0IEkgc2FpZCBpbml0aWFsbHkgaW4gdGhpcyB0aHJl YWQsIEkgdGhvdWdodCB3ZSB3ZXJlIHRhbGtpbmcgYWJvdXQgdGhlIHNhbWUgdGhpbmcuIEkgZ3Vl c3Mgbm90LiBXZSBjb3VsZCB0ZWFzZSB0aGlzIGFwYXJ0LCBidXQgaXMgaXQgd29ydGggaXQgaWYg 4oCcUmFuZHnigJlzIHZpZXfigJ0gY292ZXJzIGFsbCBzaXR1YXRpb25zPzwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LWFuZHk8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6FD0DC29916944D791522F1C0E0458A1arinnet_-- From nobody Thu Jul 16 10:54:00 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B941B2A9B for ; Thu, 16 Jul 2015 10:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVTRU7pCiDug for ; Thu, 16 Jul 2015 10:53:55 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 774CF1B2A99 for ; Thu, 16 Jul 2015 10:53:55 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:37806) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZFnM1-000FsY-US; Thu, 16 Jul 2015 13:53:54 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id B45F84006D Message-ID: <55A7EFB1.30406@bbn.com> Date: Thu, 16 Jul 2015 13:53:53 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Sandra Murphy References: <552F3C79.8030809@bbn.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5MAruJQxCIu18otaURb7nBWI2HWPU8IUD" Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 17:53:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5MAruJQxCIu18otaURb7nBWI2HWPU8IUD Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-07-16 07:09, Sandra Murphy wrote: > Could you please respond to the list and say whether the > draft-ietf-sidr-rpki-rtr-rfc6810-bis-04.txt version satisfies your > comments? It would help the process. Not all of them, and I noticed some new (mostly minor) issues in -04. I sent a new round of comments to the authors off-list, and they replied saying they'll take a look after the Prague busyness subsides. I'll report my comments to the list after the authors and I have had a chance to discuss them. -Richard >=20 > --Sandy >=20 > On Apr 16, 2015, at 12:37 AM, Richard Hansen wrote: >=20 >> Hi all, >> >> Here are my comments, some of which overlap with what others have said= : >> >> * The name of the draft says "rfc6810-bis", but the XML tag >> doesn't have an obsoletes=3D"6810" attribute. And I don't think it= >> should -- Section 7 has a normative reference to RFC6810 when >> discussing downgrades to version 0, which isn't specified in this >> document. So perhaps the title and abstract should be worded to >> make it clear that this is not a replacement for RFC6810, but >> rather a new version of the protocol specified in RFC6810. (Or >> maybe this document should be worded as an update to RFC6810?) >> (Also mentioned in .= ) >> >> * The protocol is mostly query-response lockstep, but there are no >> timeouts. If the cache is taking unreasonably long to respond to a= >> query, what should the router do? How long is unreasonably long? >> If timeouts are added, should the router reset its timeout timer >> for each response PDU (Cache Response, payload, and End of Data), >> or only after it receives the End of Data PDU? >> >> * Should the cache time out the router if the router doesn't send a >> Query soon after connecting? >> >> * Notify/Query race: What is supposed to happen if the router sees a= >> Serial Notify right after it sends a Serial Query or Reset Query? >> This could happen if the two are sent at the same time -- the >> messages will cross paths and the router might think that the >> Serial Notify is an erroneous response to the query, and that the >> subsequent Cache Response came out of the blue. >> >> * The name "Session ID" is misleading. Section 2 clearly defines it,= >> but unless you pay attention to the definition it's easy to assume >> that "session" refers to the transport session with the peer. I >> would prefer a different name such as "Cache Instance ID", though >> that name may be insufficient when you consider the protocol >> upgrade problem brought up by David in >> . Maybe something >> like "Data Series ID"? >> >> * In Section 5.1 (fields) under "Session ID", what is the definition >> of "completely drop the session"? Do you mean send a fatal error >> PDU, do a transport-layer disconnect, and let the router reconnect >> (possibly to a more preferred cache)? Or do you mean send a Cache >> Reset (cache->router) or Reset Query (router->cache) and continue >> the existing transport session? Or is either reaction acceptable? >> >> * What is the definition of "payload PDU", mentioned in Sections 5.3,= >> 5.5, 8.1, 8.2, and 8.3? (I assume it means IPv4 Prefix, IPv6 >> Prefix, and Router Key, but it should be explicitly stated.) >> >> * Suppose an IPv4 Prefix was announced in serial 5 and withdrawn in >> serial 6, and a router does a Serial Query against serial 4. Is >> it OK if the cache elides the announce/withdraw pair? MUST it? If= >> it doesn't, it seems like the cache MUST send the payload PDUs in >> serial number order, and the router MUST process the payload PDUs i= n >> serial number order (which implies that the transport MUST provide >> in-order delivery of the PDUs because the router has no idea which >> PDUs correspond to which serial number). >> >> * Section 5.1 (fields) says that the serial number is the serial >> number of the cache, but Section 5.3 (Serial Query) talks about >> serial numbers as if they are properties of a PDU. Perhaps 5.3 >> should be worded like: >> >> The router sends a Serial Query to ask the cache for the >> announcements and withdrawals that have occurred since the >> Serial Number in the Serial Query. >> >> Section 5.5 (Cache Response) has similarly problematic wording. >> >> * The two sentences in 5.3 (Serial Query) paragraph 2 seem to >> contradict each other in the case where there are no (net?) >> changes: The first sentence suggests that the cache sends a Cache >> Response (maybe followed by something?), while the second suggests >> that it only sends an End of Data (no Cache Response). I think the= >> intention is for the cache to send a Cache Response immediately >> followed by an End of Data. Is that correct? >> >> * I don't think the set of valid responses to a Query (Reset or >> Serial) is clearly specified. I think the intention is for these >> to be the only valid responses: >> >> - Reset Query: >> * Cache Response followed by 0 or more payload PDUs followed >> by End of Data >> * Error Report >> - Serial Query: >> * Cache Response followed by 0 or more payload PDUs followed >> by End of Data >> * Error Report >> * Cache Reset >> >> Is this correct? >> >> * Is there a particular reason for omitting a payload PDU count field= >> from the Cache Response PDU? If one was present, the router could >> pre-allocate an appropriate amount of memory to handle the payload >> PDUs (and perform additional sanity checks). >> >> I guess a PDU count field would prevent an implementation from >> opportunistically sending additional PDUs if there happened to be a= >> serial number bump during the middle of a Cache Response. >> (Instead, the cache would have to follow the End of Data PDU with a= >> Serial Notify, which is almost as good.) >> >> * Section 5.6 (IPv4 Prefix) mentions duplicates, but are redundant >> entries OK? Examples: >> - {65536,192.0.2.0/24-26} and {65536,192.0.2.0/26-26} (the latter= >> is redundant) >> - {65536,192.0.2.0/24-26} and {65536,192.0.2.0/24-25} (the latter= >> is redundant) >> >> * The fixed-length SKI field doesn't permit algorithm changes. Note >> that there has been some discussion about using SHA-256 for the SKI= >> and AKI fields for the RFC6487(bis) profile (I'm guessing that's >> probably not going to happen, but still...). >> (Also mentioned in .= ) >> >> * Section 5.11 (Error Report) says that Error Reports are only sent >> as responses to other PDUs. Why the restriction? This prevents a >> side from raising a timeout error, and it prevents the cache from >> raising an internal error if a problem is detected when it's time >> to send a Serial Notify. >> >> * If error reports are only sent as responses to other PDUs, how is >> it possible for an Error Report to not be associated with the PDU >> to which it is responding? (Section 5.11 paragraph 4) >> >> * For version negotiation, what is supposed to happen if the router >> starts with a PDU with version > 1? There is an Unsupported >> Protocol Version error type, but nothing requires that to be sent. >> >> * Suppose a router connects and issues a v0 Query. If the cache >> doesn't support protocol v0, Section 7 says it MUST either >> downgrade or disconnect. Can it issue an Error Report before >> disconnecting? I would prefer it if the server MUST issue an >> Unsupported Protocol Version Error Report before disconnecting. >> >> * The second-to-last paragraph of Section 10 talks about deleting >> data from a cache when it has been unable to refresh from that >> cache for twice the polling period (by default). Why not have the >> time to delete equal the Expire Interval as specified in Section 6?= >> >> Thanks, >> Richard >> >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 --5MAruJQxCIu18otaURb7nBWI2HWPU8IUD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlWn77EACgkQMs/lq+4xKKLxcQCgsAoef8xql6YkwgGQ3VJ6T5JD Qv0AoJZzcr587f8OBR6PSP83wmZf6INr =sBrv -----END PGP SIGNATURE----- --5MAruJQxCIu18otaURb7nBWI2HWPU8IUD-- From nobody Thu Jul 16 16:17:16 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42AE1ACE80 for ; Thu, 16 Jul 2015 16:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulk-8WI11qGY for ; Thu, 16 Jul 2015 16:17:13 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F8B1ACE73 for ; Thu, 16 Jul 2015 16:17:12 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:38880) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZFsOr-000DcX-9n; Thu, 16 Jul 2015 19:17:09 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id 173504006D Message-ID: <55A83B74.6020303@bbn.com> Date: Thu, 16 Jul 2015 19:17:08 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Sandra Murphy References: <20150515192215.5707.56279.idtracker@ietfa.amsl.com> <555CE890.1090802@bbn.com> <462B3352-DAA9-476C-AA33-C517C515B7F0@tislabs.com> <555E5E4A.5080303@bbn.com> <55A6F046.1090109@bbn.com> In-Reply-To: <55A6F046.1090109@bbn.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="o7lm78CE2lp7x37Xr6rXReM8X7LaVMbc4" Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rfc6485bis-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 23:17:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --o7lm78CE2lp7x37Xr6rXReM8X7LaVMbc4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-07-15 19:44, Richard Hansen wrote: > Before this OID issue was raised, RPSTIR only accepted CMS signed > objects that used sha256WithRSAEncryption. CMS signed objects that use= d > rsaEncryption were rejected due to non-conformance with RFC6485. Apologies; this is incorrect. Up to and including v0.3 (released 2012-03-05), RPSTIR only accepted rsaEncryption. =46rom v0.4 (released 2012-06-08) to v0.9 (released 2013-10-13) inclusive= , RPSTIR accepted both but warned on rsaEncryption. Starting in v0.10 (released 2014-02-25), RPSTIR quietly accepts both. We added rigorous test cases in v0.4. The thread that brought this OID issue to SIDR's attention [1] was started shortly after RPSTIR v0.4 was released. [1] http://thread.gmane.org/gmane.ietf.sidr/4706 -Richard --o7lm78CE2lp7x37Xr6rXReM8X7LaVMbc4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlWoO3QACgkQMs/lq+4xKKJOegCfcJ5Yd3gvMDrOS4eOMnf0RSHn WIYAnApVQ4wPOCwHwihJXQ1aslaUIcPO =dcjI -----END PGP SIGNATURE----- --o7lm78CE2lp7x37Xr6rXReM8X7LaVMbc4-- From nobody Thu Jul 16 21:25:01 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205261ACD6E for ; Thu, 16 Jul 2015 21:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CC0wpz35BRnb for ; Thu, 16 Jul 2015 21:25:00 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EFD81B2AD5 for ; Thu, 16 Jul 2015 21:24:37 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ZFxCL-0002LU-TE; Fri, 17 Jul 2015 04:24:34 +0000 Date: Fri, 17 Jul 2015 06:24:32 +0200 Message-ID: From: Randy Bush To: Andy Newton In-Reply-To: <8BE719A0-0EC1-4E35-8BAD-A64E06D0979C@arin.net> References: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> <556CF530.4010408@ops-netman.net> <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> <559A8B31.50408@bbn.com> <559BF347.60609@bbn.com> <9DFC9C7C-CBFC-427C-8589-C13457EDD091@tislabs.com> <55A6C585.6060602@bbn.com> <8BE719A0-0EC1-4E35-8BAD-A64E06D0979C@arin.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: sidr wg list Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 04:25:01 -0000 > Randy's view is that it is preferable to engineer a single solution > that is agnostic about whether the address space is in use or not, > even if that is a more complex solution. His rationale seems to be > that its safer to treat all space as in use, so as to avoid the damage > to users that arises if the entity transferring the space can't > properly classify it properly. thank you for putting words in my mouth, especially as they are the correct words :) > Isn=E2=80=99t the =E2=80=9Cunused=E2=80=9D scenario what we have today? W= hy do we need a > solution for something that is already being accomplished? in steve's model, one has to implement both. job security for engineers :) randy From nobody Fri Jul 17 06:40:26 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4E01B33E5 for ; Fri, 17 Jul 2015 06:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36bfKE-LZDiY for ; Fri, 17 Jul 2015 06:40:23 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD9181B33E7 for ; Fri, 17 Jul 2015 06:40:23 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:54719 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZG5sE-000OXF-OQ for sidr@ietf.org; Fri, 17 Jul 2015 09:40:22 -0400 References: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> <556CF530.4010408@ops-netman.net> <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> <559A8B31.50408@bbn.com> <559BF347.60609@bbn.com> <9DFC9C7C-CBFC-427C-8589-C13457EDD091@tislabs.com> <55A6C585.6060602@bbn.com> <8BE719A0-0EC1-4E35-8BAD-A64E06D0979C@arin.net> <55A7B814.1020509@bbn.com> <6FD0DC29-9169-44D7-9152-2F1C0E0458A1@arin.net> Cc: sidr wg list From: Stephen Kent Message-ID: <55A905C6.7050904@bbn.com> Date: Fri, 17 Jul 2015 09:40:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <6FD0DC29-9169-44D7-9152-2F1C0E0458A1@arin.net> Content-Type: multipart/alternative; boundary="------------010902080702000700070903" Archived-At: Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 13:40:25 -0000 This is a multi-part message in MIME format. --------------010902080702000700070903 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Andy, > ... > Steve, > > Given what I said initially in this thread, I thought we were talking > about the same thing. I guess not. We could tease this apart, but is > it worth it if “Randy’s view” covers all situations? > > -andy Randy's approach covers both cases, at the cost of some added complexity for what I suspect is the most common case. Whether that's preferable to two similar, but slightly different mechanisms, where one is optimized for the (purported) most common case is a matter of engineering taste. The WG will have to decide at some point, when we have complete, detailed proposals for both. Steve --------------010902080702000700070903 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Andy,


...
Steve,

Given what I said initially in this thread, I thought we were talking about the same thing. I guess not. We could tease this apart, but is it worth it if “Randy’s view” covers all situations?

-andy
Randy's approach covers both cases, at the cost of some added complexity for what I suspect
is the most common case. Whether that's preferable to two similar, but slightly different
mechanisms, where one is optimized for the (purported) most common case is a matter of
engineering taste. The WG will have to decide at some point, when we have complete, detailed
proposals for both.

Steve

--------------010902080702000700070903-- From nobody Fri Jul 17 06:40:46 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFDE1B33AD; Fri, 17 Jul 2015 06:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vs3DMlBfteVw; Fri, 17 Jul 2015 06:40:43 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0762.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::762]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 973771B33E9; Fri, 17 Jul 2015 06:40:42 -0700 (PDT) Received: from CY1PR09MB0795.namprd09.prod.outlook.com (10.163.43.145) by CY1PR09MB0377.namprd09.prod.outlook.com (10.160.147.14) with Microsoft SMTP Server (TLS) id 15.1.213.14; Fri, 17 Jul 2015 13:40:38 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by CY1PR09MB0795.namprd09.prod.outlook.com (10.163.43.145) with Microsoft SMTP Server (TLS) id 15.1.219.17; Fri, 17 Jul 2015 13:40:37 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0219.000; Fri, 17 Jul 2015 13:40:37 +0000 From: "Sriram, Kotikalapudi" To: Andrei Robachevsky Thread-Topic: draft-sriram-idr-route-leak-detection-mitigation: difference between a peer and a customer Thread-Index: AQHQvhEfZNxwzI8V2ECO5TICdbuD2Z3cfN/4gAAk8ACAAGNnMIAAvWGAgAHfYks= Date: Fri, 17 Jul 2015 13:40:37 +0000 Message-ID: References: <005901d0b283$ea07bd20$be173760$@ndzh.com> <55A4CB9B.2050207@gmail.com> <55A67586.6050604@gmail.com> , <55A767C5.3090805@gmail.com> In-Reply-To: <55A767C5.3090805@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [129.6.220.66] x-microsoft-exchange-diagnostics: 1; CY1PR09MB0795; 5:qXPBUM/eWZOjRi+xfysoNRStpXKd+Ym/paV3PnDw5EvOwFpQTDNwKFt2hOs6IpMshqD4DrQ5JhEMm/JQmzPRlHccW9jc3YnsXKjOtfi7dZlWyFe2BD6apS1S67MECVPFs+VI1h7jSohUEj/M5y/Cfw==; 24:N/LR0ZTDdPcquP5vQEwKqcP55Hl2d8gMFgoMiDr5z/Us64guBSQLd2h37UvXiBJChQT7030CD1tLnMQPqpQL7nd6ChYGw9FF/dd5OI7XLkM=; 20:KmSIltxeAqqYJOJTl8jCDwMGgtRhrMmji+dWiCJ/cz6SA9EpA+5HpveK/s85JWgaq25Eq7LgW3pJ9cUkwJVPZw== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0795; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0377; cy1pr09mb0795: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0795; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0795; x-forefront-prvs: 06400060E1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(2656002)(62966003)(77156002)(46102003)(93886004)(74316001)(122556002)(106116001)(99286002)(40100003)(5003600100002)(230783001)(102836002)(54356999)(92566002)(77096005)(5001920100001)(33656002)(5002640100001)(5001960100002)(110136002)(66066001)(87936001)(76176999)(76576001)(50986999)(189998001)(86362001)(2900100001)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0795; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2015 13:40:37.6313 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0795 X-Microsoft-Exchange-Diagnostics: 1; CY1PR09MB0377; 2:ebhUe5LMQm3zPMxTQRRp9OFxVzuC+w+2pKZeW/Z15pFWIwWbe4tKeARDTBTSCRnr; 3:H0LmVNBU/qEuSY+z7s9aoJ2dBsVrk1oGiAoLfoVytqUMUcHXLnmsJEGCAQ9/uHdsOZY8X+nnG5Nylwb349YwnrIgXfjUHc9fqq2JV4+dNd8QZ8xaDvE1brupkH83+Hp3hiMS4NfJ71e+1+GXFsXTIA==; 25:3+EtKf8vQuQjuKopyjMi+AS4meqOkU+rmwRNg3JIbzKZ34WAKvtk7fb2/SY0FWJbYcSxvY1bYooC2/eDU5UJQWbbVpiOZxSgDeiSBfaby+f58WIdGq0n1vG7r4TwV1BDJHmYiXWvkVgDfQjeOL3TT6lLLLkkLFb5Eric9KglNzHc1nfesvfYFxjwzKTrpBvZQdsQ+Z4lpdZ4wCn6CtEcSWn6MKAOLgiCQlVojZjzmEfcUBcCL9TQ7MUtFhfu6eJwh2bQgrbVTxFXtKJPI5fmTw==; 20:DPsoAkzX5KVRjOIQ1Ph2ka+ETbrrSFQ9nVLVEsGphE7l9Qlx94gwRlwl6HkwkBib62/63JkRsqBvlfT9a9m4ug==; 23:5zJUVQ56bGGg/BybalJQZdLQDk0ZrzeMsKFkfjyCeHeIA+shn1mnoBQ5NfWs7uVGjxXPSRggZG3eTqjr3tHoLrMK743jq4flHxSyR7paZkjnWj2/KbzpiDTD0kL/Yd7mBUMRDInMOY66wDnxa8mJbXpfvr7NnqmtcZ8v3Cu5mW277/LuIuFInFJ4vMopDpxhNEQ50TSCDm89uSGrO0v2bnKVlCMyRUZHu8CwiGRrJ0/XuFTWgnXXtUNV2ILNq+Gm CY1PR09MB0377: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: nist.gov Archived-At: Cc: idr wg list , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] draft-sriram-idr-route-leak-detection-mitigation: difference between a peer and a customer X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 13:40:44 -0000 >Your explanations make it very clear, thanks. Thanks, Andrei.=20 Looks like we've converged on pretty much all issues that we've discussed s= o far in this thread. One comment inline below. [...] >>> If my considerations are correct, there are only two cases - >>> upstreams/transit providers, for which RLP doesn't matter, and others >>> (customers and peers) where an RLP indicates a leak and has to be dealt >>> accordingly. >> >> Yes, I agree that detecting route leaks from customers/peers matters. >> Detecting route leaks from upstreams/transit providers does not really m= atter >> (as explained above). >I guess what I am arguing for is that the semantics of RLP 01 should be >"propagate only down" rather than "do not propagate up" and any updates >with the RLP field set from a peer or a customer should be treated as a >leak. OK, I see now what you meant. Your suggestion is good.=20 In the draft, currently in Section 3.2.2 "do not propagate up"=20 is interpreted (implicitly) as "propagate only down" for a peer. =20 But with this change (as suggested above by you) , we no longer have to=20 make that distinction. The semantics of RLP 01 would be the same=20 whether an update is received from a customer or a peer.=20 Then route leak detection algorithm would be the same for customer or peer, and sections 3.2.1 and 3.2.2 can be merged into one. Thanks. Sriram =20 From nobody Mon Jul 20 04:45:38 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102241A1DBC; Mon, 20 Jul 2015 04:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTNfBQzH2pRU; Mon, 20 Jul 2015 04:45:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE8D1A21A4; Mon, 20 Jul 2015 04:45:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150720114534.28681.4536.idtracker@ietfa.amsl.com> Date: Mon, 20 Jul 2015 04:45:34 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-09.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 11:45:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Router Keying for BGPsec Authors : Sean Turner Keyur Patel Randy Bush Filename : draft-ietf-sidr-rtr-keying-09.txt Pages : 11 Date : 2015-07-20 Abstract: BGPsec-speaking routers are provisioned with private keys to sign BGP messages; the corresponding public keys are published in the global RPKI (Resource Public Key Infrastructure) thereby enabling verification of BGPsec messages. This document describes two ways of provisioning the public-private key-pairs: router-driven and operator-driven. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 20 04:47:31 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CA91A6EED for ; Mon, 20 Jul 2015 04:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0qDkkknvrtO for ; Mon, 20 Jul 2015 04:47:28 -0700 (PDT) Received: from gateway23.websitewelcome.com (gateway23.websitewelcome.com [192.185.50.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CD631A1EF1 for ; Mon, 20 Jul 2015 04:47:24 -0700 (PDT) Received: by gateway23.websitewelcome.com (Postfix, from userid 500) id 8C52C7DADA92A; Mon, 20 Jul 2015 06:46:26 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway23.websitewelcome.com (Postfix) with ESMTP id 790857DADA90E for ; Mon, 20 Jul 2015 06:46:26 -0500 (CDT) Received: from [31.133.178.195] (port=49326 helo=dhcp-b2c3.meeting.ietf.org) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZH9Wb-0007BY-RY for sidr@ietf.org; Mon, 20 Jul 2015 06:46:26 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <20150720114534.28681.4536.idtracker@ietfa.amsl.com> Date: Mon, 20 Jul 2015 13:46:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4A06DE11-A843-4379-BB03-A57C345BA108@ieca.com> References: <20150720114534.28681.4536.idtracker@ietfa.amsl.com> To: sidr wg list X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 31.133.178.195 X-Exim-ID: 1ZH9Wb-0007BY-RY X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-b2c3.meeting.ietf.org) [31.133.178.195]:49326 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 14 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-09.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 11:47:29 -0000 This is a simple keep alive update (i.e., I just updated the dates). spt On Jul 20, 2015, at 13:45, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Inter-Domain Routing Working = Group of the IETF. >=20 > Title : Router Keying for BGPsec > Authors : Sean Turner > Keyur Patel > Randy Bush > Filename : draft-ietf-sidr-rtr-keying-09.txt > Pages : 11 > Date : 2015-07-20 >=20 > Abstract: > BGPsec-speaking routers are provisioned with private keys to sign = BGP > messages; the corresponding public keys are published in the global > RPKI (Resource Public Key Infrastructure) thereby enabling > verification of BGPsec messages. This document describes two ways = of > provisioning the public-private key-pairs: router-driven and > operator-driven. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-09 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rtr-keying-09 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Mon Jul 20 04:52:24 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1611A21B7; Mon, 20 Jul 2015 04:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEtu6FMwF0f7; Mon, 20 Jul 2015 04:52:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D0D1A6EFE; Mon, 20 Jul 2015 04:52:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150720115221.3762.72058.idtracker@ietfa.amsl.com> Date: Mon, 20 Jul 2015 04:52:21 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-10.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 11:52:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : BGPsec Algorithms, Key Formats, & Signature Formats Author : Sean Turner Filename : draft-ietf-sidr-bgpsec-algs-10.txt Pages : 7 Date : 2015-07-20 Abstract: This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size and signature format used in BGPsec (Border Gateway Protocol Security). This document updates the Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure (RFC 6485). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 20 04:54:59 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26E01A6EFE for ; Mon, 20 Jul 2015 04:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqW8q2g8zbc9 for ; Mon, 20 Jul 2015 04:54:57 -0700 (PDT) Received: from gateway23.websitewelcome.com (gateway23.websitewelcome.com [192.185.50.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA311A21AF for ; Mon, 20 Jul 2015 04:54:57 -0700 (PDT) Received: by gateway23.websitewelcome.com (Postfix, from userid 500) id D84FD7DB258D0; Mon, 20 Jul 2015 06:54:33 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway23.websitewelcome.com (Postfix) with ESMTP id C8FF97DB2586E for ; Mon, 20 Jul 2015 06:54:33 -0500 (CDT) Received: from [31.133.178.195] (port=49389 helo=dhcp-b2c3.meeting.ietf.org) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZH9eT-0008CQ-7i for sidr@ietf.org; Mon, 20 Jul 2015 06:54:33 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <20150720115221.3762.72058.idtracker@ietfa.amsl.com> Date: Mon, 20 Jul 2015 13:54:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8BAB5068-F3A7-4BE6-9DB4-513460048F86@ieca.com> References: <20150720115221.3762.72058.idtracker@ietfa.amsl.com> To: sidr wg list X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 31.133.178.195 X-Exim-ID: 1ZH9eT-0008CQ-7i X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-b2c3.meeting.ietf.org) [31.133.178.195]:49389 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 16 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-10.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 11:54:59 -0000 Change is r/BGPSEC/BGPsec to align with overview draft and dates. spt On Jul 20, 2015, at 13:52, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Inter-Domain Routing Working = Group of the IETF. >=20 > Title : BGPsec Algorithms, Key Formats, & Signature = Formats > Author : Sean Turner > Filename : draft-ietf-sidr-bgpsec-algs-10.txt > Pages : 7 > Date : 2015-07-20 >=20 > Abstract: > This document specifies the algorithms, algorithms' parameters, > asymmetric key formats, asymmetric key size and signature format = used > in BGPsec (Border Gateway Protocol Security). This document updates > the Profile for Algorithms and Key Sizes for use in the Resource > Public Key Infrastructure (RFC 6485). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-10 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-algs-10 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Jul 20 07:22:11 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5091A897B; Mon, 20 Jul 2015 07:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9K2PIjj8C3q; Mon, 20 Jul 2015 07:22:10 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5DBE1A8974; Mon, 20 Jul 2015 07:22:09 -0700 (PDT) Received: by ykax123 with SMTP id x123so140041961yka.1; Mon, 20 Jul 2015 07:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZS8uBIy39oIHPOnxSQyTg3xqMquaYNtX6h63IWp7mqk=; b=UTJknqCSMcqVOb8jZiMGS0hucT5zeS5Ksm0HRgJxxn7USUId6U9xf1MOmzJG43FeA8 8G43FlOY6lKndkfEgU0q9Ec7o8p8DcWjGf++Cn81zEl46Q/nbx9QGE4RGMuXSMIRY4BO RnPbS04Yo8puCtVgMQ6tPA5zcsAKGKoD6Kmt1zYasFUR9nuKlPvO3ELfBsEP2o9HsCvc N3abJr1BE7G5S7Wbj1oHKR6Lt8SNWGofeg3jP7YB31xWRSwLpbSoT/+hX7WSCG18M1b5 Fix02ahT5W7gAitoEMHg50HZsBGkMgQClEq5JafWSPiqJAwrw7vLo1ERAJJHIdhyBPuB +eWw== MIME-Version: 1.0 X-Received: by 10.13.236.5 with SMTP id v5mr28516053ywe.138.1437402129199; Mon, 20 Jul 2015 07:22:09 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.228.196 with HTTP; Mon, 20 Jul 2015 07:22:09 -0700 (PDT) In-Reply-To: References: <005901d0b283$ea07bd20$be173760$@ndzh.com> Date: Mon, 20 Jul 2015 10:22:09 -0400 X-Google-Sender-Auth: _wHo3cPH6zn29CLZRF5n8Pnr8eM Message-ID: From: Christopher Morrow To: "Sriram, Kotikalapudi" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: idr wg list , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] [Idr] Route Leaks and solutions X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 14:22:11 -0000 I think I see the current plan as a it challenging to depend upon... If the RLP bit is dependent upon ops folks getting the right config-bit set for each customer we would want that to be as much automated as possible so there would be the least chance for 'forgot to set the bit' or 'set bit incorrectly'. I'm worried that I can't tell reliably what the bit was 2 as-hops away, did they mean 'customer' ? or was that a mistake? Did someone change it mid-path to me? Did the implementation of their vendor gear change/set the wrong attribute value? There seem to be a bunch of uncertainties with this, in my mind. I guess that with bgpsec signing this attribute at least 'joe really meant that jim was his customer', and you can't change the value on a bgpsec path. If we want that, I think having the attribute where it can get changed (not-bgpsec secured paths) is a real problem, or opens up some pretty large problems... From nobody Tue Jul 21 08:21:32 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEEF1B2F4A for ; Tue, 21 Jul 2015 08:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.084 X-Spam-Level: X-Spam-Status: No, score=0.084 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvWcDs-tLhCP for ; Tue, 21 Jul 2015 08:21:28 -0700 (PDT) Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79C4E1B2F8B for ; Tue, 21 Jul 2015 08:20:27 -0700 (PDT) Received: from dhcp-b283.meeting.ietf.org (unknown [IPv6:2001:67c:370:176:743b:d330:54f2:2946]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 8AD9BEB7 for ; Tue, 21 Jul 2015 17:20:25 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1437492025; bh=QD/Tfx3rzWNbRQAFD7SVJb/2QutDNosa0kdLAiGZaFc=; h=To:From:Subject:Date; b=VXhFG02sMIREkVnBvd9aKDhqdkNPDPr2O0PRf6Nqx9yCGasBoPwZkLYh4I7gAuFvm VRueayCTU4I1ViqVWjhzP4lWpZh2dW1qvncu2RRA1kC9+Jeu1aS48S8xKfFB4GpXD4 tze5aA1ytYL6yl8hddNEuuUs8HZoMTNexb8fr/M0= To: sidr@ietf.org From: Benno Overeinder X-Enigmail-Draft-Status: N1110 Message-ID: <55AE6339.9080504@NLnetLabs.nl> Date: Tue, 21 Jul 2015 17:20:25 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [sidr] simulation study of RPKI deployment scenarios and its measured effect X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 15:21:30 -0000 Hi all, Not SIDR WG material, but interesting to the IETF people in the SIDR WG. Last month a student/intern at NLnet Labs finished his BSc. thesis on simulation of RPKI deployment scenarios and analysing the effect on routes (valid/invalid/unknown) and the length of the paths. Of course, this is just a study with a limited scope, focussed on a small number of specific scenarios. But maybe also a study to extend with more relevant scenarios, statistics measured, and results analysed. You can find the thesis and slides at: - thesis: https://www.nlnetlabs.nl/~benno/opendir/bryan-thesis-3.pdf - slides: https://www.nlnetlabs.nl/~benno/opendir/BGP%20Routing%20Security%20&%20Deployment%20Strategies-5.pdf If you are interested to discuss the study (comments/suggestions to improve, etc.), drop me an email and we can discuss the work during the next days at the IETF. Regards, -- Benno -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From nobody Tue Jul 21 09:57:08 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D401ACD4E; Tue, 21 Jul 2015 09:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDPTTg-WEeQL; Tue, 21 Jul 2015 09:57:02 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980671ACD2B; Tue, 21 Jul 2015 09:57:02 -0700 (PDT) Received: from SN1PR09MB0799.namprd09.prod.outlook.com (10.162.101.145) by SN1PR09MB0797.namprd09.prod.outlook.com (10.162.101.143) with Microsoft SMTP Server (TLS) id 15.1.219.17; Tue, 21 Jul 2015 16:56:45 +0000 Received: from SN1PR09MB0799.namprd09.prod.outlook.com ([10.162.101.145]) by SN1PR09MB0799.namprd09.prod.outlook.com ([10.162.101.145]) with mapi id 15.01.0219.018; Tue, 21 Jul 2015 16:56:45 +0000 From: "Sriram, Kotikalapudi" To: Christopher Morrow Thread-Topic: [Idr] Route Leaks and solutions Thread-Index: AQHQst/YBwy3rwbYakKgtnDiHnHcZp3NZLUJgAAwLgCAACk92IAAEGcAgAWPDmCAESuXgIABuyOo Date: Tue, 21 Jul 2015 16:56:45 +0000 Message-ID: References: <005901d0b283$ea07bd20$be173760$@ndzh.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: psg.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:67c:370:160:21f3:a411:d0d1:8b05] x-microsoft-exchange-diagnostics: 1; SN1PR09MB0797; 24:/77ZeFBfFegWrvDTxkEQXgJ+esN/Eim5SCvH8/8LU8qm3uyvsjOtMnuwQ1TQMZmlrs/mSsYiP4JKpMXSGsbwzwkRZHb40vuEHAY3ZLeHxXU=; 20:oyS4iah/bGn9eMJg7MegUyMQGwcsBrVVieZhftVFIUshSqhazKPP2AHdUF5OArKjivBB9O05F/WVABEvDe/tMQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR09MB0797; sn1pr09mb0797: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR09MB0797; BCL:0; PCL:0; RULEID:; SRVR:SN1PR09MB0797; x-forefront-prvs: 0644578634 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(62966003)(87936001)(189998001)(77156002)(19580395003)(110136002)(106116001)(86362001)(5001960100002)(99286002)(92566002)(102836002)(2950100001)(2656002)(76576001)(77096005)(15975445007)(74316001)(5003600100002)(54356999)(40100003)(33656002)(76176999)(46102003)(50986999)(122556002)(5002640100001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR09MB0797; H:SN1PR09MB0799.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2015 16:56:45.8133 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR09MB0797 Archived-At: Cc: idr wg list , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] [Idr] Route Leaks and solutions X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 16:57:05 -0000 >If the RLP bit is dependent upon ops folks getting the right >config-bit set for each customer we would want that to be as much >automated as possible so there would be the least chance for 'forgot >to set the bit' or 'set bit incorrectly'. Some sort of mapping of a prefix-route to eBGP neighbors to who it will be = sent to,=20 namely, customers, peers, providers, isn=92t that done already in a routers= currently? >I'm worried that I can't tell reliably what the bit was 2 as-hops >away, did they mean 'customer' ? or was that a mistake? Did someone >change it mid-path to me? Did the implementation of their vendor gear >change/set the wrong attribute value? Initially, only the big ISPs have to get it right (setting the RLP bits).=20 That itself would help reap the benefit substantially. Basically, then one big ISP=92s prefix-routes sent to its customer cannot m= ake =20 a U-turn (route leak) somewhere in its customer cone and be accepted by ano= ther big ISP, even if the ASes in between are not doing it (or they make mistakes with th= eir=20 RLP bits) as long as they do not change any preceding ASs' RLP fields. =20 >There seem to be a bunch of uncertainties with this, in my mind. I >guess that with bgpsec signing this attribute at least 'joe really >meant that jim was his customer', and you can't change the value on a >bgpsec path. > >If we want that, I think having the attribute where it can get changed >(not-bgpsec secured paths) is a real problem, or opens up some pretty >large problems... Like I said in my talk in GROW yesterday, without bgpsec (RLP bits secured)= ,=20 the 99% accidental leaks are detected/mitigated but not the 1% malicious. = =20 With bgpsec (RLP bits secured), the 1% malicious are also detected/mitigate= d. =20 See slide 5: https://www.ietf.org/proceedings/93/slides/slides-93-grow-4.pdf=20 Prior to bgpsec protection, there are two types of attacks that are possible on unprotected RLP bits: 1. Upgrade attack (RLP =3D 01 is altered to RLP =3D 00) to avoid route-leak= detection.=20 That falls in the 1% malicious category (undetected) but no other=20 more egregious damage occurs as a result of this upgrade attack. See more discussion of this in Section 5.1. of the draft: https://www.ietf.org/id/draft-sriram-idr-route-leak-detection-mitigation-01= .txt=20 2. Downgrade attack: (RLP =3D 00 is altered to RLP =3D 01)=20 This does not matter in the 'down' direction because RLP =3D01=20 always allows propagation of the prefix-route in 'down' direction. So this attack (RLP =3D 00 --> RLP =3D 01) matters only when update propaga= tes=20 in the up or lateral peer direction. That would only mean that an alternate update that is not labeled a route l= eak=20 would be preferred by the (provider or peer) over this one. And if there is no alternate update, then for reachability, the only prefix-route that seems like a leak might still be accepted. But this is left up to operator policy. =20 Sriram= From nobody Wed Jul 22 04:33:12 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934BB1B2C4D for ; Wed, 22 Jul 2015 04:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXAU9RJerj8o for ; Wed, 22 Jul 2015 04:33:10 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3F11B2D60 for ; Wed, 22 Jul 2015 04:33:10 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id B2F4128B003D for ; Wed, 22 Jul 2015 07:33:09 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 005FD1F8035; Wed, 22 Jul 2015 07:33:08 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_D1E1F3C5-BB68-4DD0-B595-E4712E5CD706"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 22 Jul 2015 07:33:08 -0400 Message-Id: <84577E88-A207-41AA-9156-17A1B5D39CDD@tislabs.com> To: "sidr@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: Cc: Sandra Murphy Subject: [sidr] new agenda uploaded X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 11:33:11 -0000 --Apple-Mail=_D1E1F3C5-BB68-4DD0-B595-E4712E5CD706 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have uploaded a new agenda, with some changes in ordering to = facilitate some people's itineraries. There's also a new presentation by Dr. Declan Ma. My apologies to Dr. = Ma for missing his request last week. For those on the agenda, please check the agenda to see there are any = errors. Revision requests are quite acceptable. If you think you should be on the agenda but you are not, send mail to = sidr-chairs@ietf.org --Sandy --Apple-Mail=_D1E1F3C5-BB68-4DD0-B595-E4712E5CD706 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVr390AAoJEHplpQeet0IZcsYP/2d/qoyNGw2oJcgPQP4lDWT/ dRkwbF/rIcaBDgb7nxiObYemeTcO7H+13Bw4bnGZNa/ze2HjGaXLe39WFCsUBvSZ aXNDIwPj2MUa83XBvJI0gguGZfk6sV29z07nKgXRLOAsST89MMjgqmvar7H8oBu4 TaWxSkViy4oM1QlL/OrK84WipAnorREHSvqj1IW8ej/wzwTEJxufICT1wZ6Y6nOg swZb1dgbAdb4kyeqisNtPERpaWyml0toSD0xMLDTfaOaVjRKEIXUo3N3GTYLEks5 62IyI3NWfkCWTlUhudnJTUuxGdCSl42h8sNe3Tj1U036Py+ppuJj37Jew7p44A84 2nf9fUuEPVgIrCL0wb3KO4x46ATMqrUfRYOxuGGpuLYS+tTcF+diXTu546tQLEd8 077GbDTvyWRq/646cEc0uDRV4kA5ifRi18ahvZubRfZojuePFDHR/W7jdHGs6WYV tV5eKiF4D9n3BZirqKmOnAN3jCnJBPa4MM2Rordcic/6HZMOpiqy4+xUNCMvtpbt HZXrCACP1xw1NInE9gv0p+s7kb1idbBzGjkGcMlnPjOc2SMcCqvVsBbd/z1Sq2Mi xkDpxGOz2pXlLP+NzniAVCEgVIxr+SRZdtURvp4BYKYvKEG9d19OWBswU0ayiYGZ xZfhcidlelE+STmsd/2r =aQel -----END PGP SIGNATURE----- --Apple-Mail=_D1E1F3C5-BB68-4DD0-B595-E4712E5CD706-- From nobody Wed Jul 22 04:48:28 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973EE1B2DB3 for ; Wed, 22 Jul 2015 04:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIErVQ_PFsBW for ; Wed, 22 Jul 2015 04:48:25 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E38921B2BF6 for ; Wed, 22 Jul 2015 04:48:24 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 46DDA28B003D for ; Wed, 22 Jul 2015 07:48:24 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id AEE691F8035; Wed, 22 Jul 2015 07:48:23 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8B098094-E09D-4635-92F2-D610CD0DE0D9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: Date: Wed, 22 Jul 2015 07:48:23 -0400 Message-Id: <1411E4F4-0301-4E09-94F3-2FDE24BFAD0A@tislabs.com> References: To: sidr wg list X-Mailer: Apple Mail (2.1510) Archived-At: Cc: Sandra Murphy Subject: [sidr] slides request (was: agenda update; slides request; scribe and minutes request) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 11:48:26 -0000 --Apple-Mail=_8B098094-E09D-4635-92F2-D610CD0DE0D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 14, 2015, at 9:56 AM, Sandra Murphy wrote: >=20 > Slides: >=20 > Presenters, please get your slides in early to the chairs. Slides = must be uploaded before the meeting. Our session is Friday morning, = please have your slides to the chairs by close of meeting Wed. >=20 > Since we aren't meeting on Monday morning, the chairs have time to = hunt you down, so be prudent. >=20 > Remember to number your slides, for the ease of those listening = remotely. Today is Wednesday. This is the nagging reminder that you should get = your slides in today. Send your slides to sidr-chairs@ietf.org. Sending to the alias improves = your chances that your message will be seen and acted on. Pay attention to the part about numbers on the slides. --Sandy, speaking as one of the wg co-chairs --Apple-Mail=_8B098094-E09D-4635-92F2-D610CD0DE0D9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVr4MHAAoJEHplpQeet0IZEUkP/j2LTvzr17MB6MXzYctYxpAD V77Avr/KSTUp8LQWxXJkYTO4vfwqED7cQzM/WnjYp651AqYCA2lnK5fD5moW3KNk FAZnUb2kOv2QYfpFZcj8kggLCJeAewyMgMX9MNPchQWuid/L5FlNZXI9xViu7WdA 6kE3Dv6T/zLmaCHrzcxkk9BeLG9COhBOp0sMz5VtHJ9II6NegTOaGJdB2MdoOwSH rGDhelDCW3yFhIG0Heou9FTZyErlrcD0vZseWJR4jgjDEayBgMExqImEZB3HOkiI PxTSIko+lhuXSblSVLOeipMjWBwih+jyPoaWbzlPGtt8V87iiNdPYwmQnQUn89fu sLaqgYJNBU3WrNWQWwtyso/1BKeL4NP3pq6Jq89mnAOy6CnpEW0Km9pUbW8bE25G Du1MfMUr1A0+5I+QpsB5ZyKsdCM4/X844rkY+x1yeiRIWlfjmFtxPz6DH3ZBB8uL F/AkKZfVPsjgcajQSRbznhijBLBUqpzz+ZvVfOI0QHkIG17VcJ0suAOGvbY1eQuR vD86ddPSqDGy+VUDqZcYXlbnkM+3Bq9pQFwFIu246gfl24Ih25o1E3AzR/cy1NJ1 6j8bhFQ+X+aTSV8pP216yuIIyHyy7kuaFWFsxo2u3Ju5k7co1iKOWfHXOfo2SFXx yi4bFQ1OXc07aF5LfaXB =R3K4 -----END PGP SIGNATURE----- --Apple-Mail=_8B098094-E09D-4635-92F2-D610CD0DE0D9-- From nobody Wed Jul 22 04:51:00 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357641A8AE3 for ; Wed, 22 Jul 2015 04:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdFoYUu9kJCK for ; Wed, 22 Jul 2015 04:50:57 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F36341A036B for ; Wed, 22 Jul 2015 04:50:56 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 53B6328B003D for ; Wed, 22 Jul 2015 07:50:56 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id A89481F8035; Wed, 22 Jul 2015 07:50:55 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_99348C12-67D1-48F2-806E-8CF77EEC794F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: Date: Wed, 22 Jul 2015 07:50:55 -0400 Message-Id: References: To: sidr wg list X-Mailer: Apple Mail (2.1510) Archived-At: Cc: Sandra Murphy Subject: [sidr] scribe and minutes taker request (was agenda update; slides request; scribe and minutes request) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 11:50:58 -0000 --Apple-Mail=_99348C12-67D1-48F2-806E-8CF77EEC794F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 14, 2015, at 9:56 AM, Sandra Murphy wrote: >=20 > Scribing and Minutes taking: >=20 > We will need a minutes taker and a jabber scribe before the meeting = can start. >=20 > Please volunteer (don't just rely on the same faithful few). Spare = the chairs the pitiful begging at the beginning of the meeting. >=20 > --Sandy, speaking as one of the co-chairs >=20 >=20 No one has volunteered. We will need one on Friday in order to continue = the meeting. --Sandy, speaking as one of the wg co-chairs --Apple-Mail=_99348C12-67D1-48F2-806E-8CF77EEC794F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVr4OfAAoJEHplpQeet0IZue8QAK/41Vdw/Qp/0IWspmXkqAVV LAUAm94rjoVqZMvII5HvvLCCQhqM27WFKSvPAQMIQRecl889rGqgfyU2KMsxTtEC oRferfDk1Wu8++F38NNgl2sDs7LLXJdnI5ybRKAAuxQZYuTQQ0km5oh11cpfnUbU kMX3Mn0qbX+WfT+z1+MSjUjwdOjDr7RGV1DKdgyC/L2bLQ2JsQIrjek7ksvQkBIQ Ezm12QKpkvmA5/cLrJhMJKY0S4rTB8DKhKElP0YpgXgwal+n0+aNNjYlUw+6T2DK 210a4/zEloUOiV7UW/qbRKm7x3AZIZBO55pLlLv/8gDaEHMUrqH99ZHGiQ3ZldF6 bXCgO8KdxQKHsj59J5ZWedASFSkwR9ICVF9dr//Av9jY/u7u3MlHJkBhgsk/0iTQ i/MATVp9spM7G+6IF1n/YRl/OSvc+OVyOk/LhZIIWLdqaY3tN3RoXhWxSN67X3mk 9DHnEDUH5ISlszvcDFq6Hml5K132Z2zyXJnco9jjPVf81GpGtiCoKIZ6iek+k/kB RgEpcmcV9UKkBlr6+RfCM9TW0hr7rA8+99qoDuaVkBIp4be9MEJ1kBGVQbzgfG3r Ep34iGQFWjIU4tZCDiGwiguvTfAVQrG3GaJOvT768BO6IOTbguxtVEridRjPNPX+ /kPmVb5dcJcD3WpeUEk/ =Rg9L -----END PGP SIGNATURE----- --Apple-Mail=_99348C12-67D1-48F2-806E-8CF77EEC794F-- From nobody Wed Jul 22 05:23:19 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941211B31A9 for ; Wed, 22 Jul 2015 05:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-rrG5yqsc3B for ; Wed, 22 Jul 2015 05:23:17 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADBC21B31A8 for ; Wed, 22 Jul 2015 05:23:17 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.178.184; From: "Susan Hares" To: "'Sandra Murphy'" , "'sidr wg list'" References: In-Reply-To: Date: Wed, 22 Jul 2015 08:23:14 -0400 Message-ID: <012001d0c479$2f6d8d20$8e48a760$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKq9QkVkwgwnKlX8L+RxyuKkWcBnQE+q8qHnCkSw5A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [sidr] scribe and minutes taker request (was agenda update; slides request; scribe and minutes request) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 12:23:18 -0000 Sandy: I will be a jabber scribe. Sue -----Original Message----- From: sidr [mailto:sidr-bounces@ietf.org] On Behalf Of Sandra Murphy Sent: Wednesday, July 22, 2015 7:51 AM To: sidr wg list Cc: Sandra Murphy Subject: [sidr] scribe and minutes taker request (was agenda update; slides request; scribe and minutes request) On Jul 14, 2015, at 9:56 AM, Sandra Murphy wrote: > > Scribing and Minutes taking: > > We will need a minutes taker and a jabber scribe before the meeting can start. > > Please volunteer (don't just rely on the same faithful few). Spare the chairs the pitiful begging at the beginning of the meeting. > > --Sandy, speaking as one of the co-chairs > > No one has volunteered. We will need one on Friday in order to continue the meeting. --Sandy, speaking as one of the wg co-chairs From nobody Thu Jul 23 09:18:24 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36B51A1ACA for ; Thu, 23 Jul 2015 09:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQtjQfvlsd8c for ; Thu, 23 Jul 2015 09:18:22 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D2C71A1B23 for ; Thu, 23 Jul 2015 09:18:22 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id BBEF828B003D for ; Thu, 23 Jul 2015 12:18:21 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 5E3C01F8035; Thu, 23 Jul 2015 12:18:21 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_B3F7D2B2-E6A8-435C-9733-99DFA90ABFA5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: Date: Thu, 23 Jul 2015 12:18:13 -0400 Message-Id: <53E00EF4-F02C-4DF9-9805-D070328238C3@tislabs.com> References: To: sidr wg list X-Mailer: Apple Mail (2.1510) Archived-At: Cc: Sandra Murphy Subject: Re: [sidr] scribe and minutes taker request (was agenda update; slides request; scribe and minutes request) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 16:18:24 -0000 --Apple-Mail=_B3F7D2B2-E6A8-435C-9733-99DFA90ABFA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 22, 2015, at 7:50 AM, Sandra Murphy wrote: >=20 > On Jul 14, 2015, at 9:56 AM, Sandra Murphy wrote: >=20 >>=20 >> Scribing and Minutes taking: >>=20 >> We will need a minutes taker and a jabber scribe before the meeting = can start. >>=20 >> Please volunteer (don't just rely on the same faithful few). Spare = the chairs the pitiful begging at the beginning of the meeting. >>=20 >> --Sandy, speaking as one of the co-chairs >>=20 >>=20 >=20 > No one has volunteered. We will need one on Friday in order to = continue the meeting. Thanks to Sue for volunteering to jabber scribe. We still need a minutes taker volunteer. --Sandy, speaking as one of the wg co-chairs --Apple-Mail=_B3F7D2B2-E6A8-435C-9733-99DFA90ABFA5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVsRPMAAoJEHplpQeet0IZjjcQAJmC59WNsMRiqerZpt0DLcq2 cDbui1BgwQaprujPWi+7Wclvh34+0KSU7DoEVW+dgdJuUCuuS1l6akmf0RuEjQzw qG8RNghzS/uUBa8QWeKAfZFSb4SOrwkokLPQ1iXq2Es1tZR3hZy4k8mRJI6/wNg+ 6RrhGWkrawfbKGkbsPDH49xCSP2gZktUwHgD+txyNHi+TScXWfKYIPYKL9cRKHB+ j//RLPkypgVfBvs8QWQ5ZfdhQoLtE6Av1U1rtelpsqhK64aI9IJ9mgVpTjWMMxaT 79OeFxv/MDlcHJoM9BXtBDYt/K6DXUljQvWYlWaubB+nJG7Evm8CnvU6PBnbSaP8 YLYRgtC4X0jd+Bsd3lvFfR4ZMN7HqXZSqGLHcVsZn5qGcMsWQ4uQ46Bo7pnrXyUC /x9tOEDrx6viLcfHT7IIvg5v2ojtuhGRnjeoRMBP3PLTHAunjIEJ5RKn2317e8uw dMr7JWG0NyC7AQ5a70//jgzyzgxhTA2nbHdZnUIpUulWreMTmAgU0syRMQU6UWAt fYyVnJbM5Kt07/pCd7W1E4G0z9S9IZ/n2kqvf/Vq+vBnkFAvpe5jk7s3j3wLO32z R2hyyNiqNZaea8eyMhRnzoajg/AMZaftn5S6RUbL7C8+W0rzzgeRF6JE9WvyFP1w o1MPV9Du/Q+eqJ0ZlUeB =ymay -----END PGP SIGNATURE----- --Apple-Mail=_B3F7D2B2-E6A8-435C-9733-99DFA90ABFA5-- From nobody Thu Jul 23 14:06:32 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9081C1AC3AE for ; Thu, 23 Jul 2015 14:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rW6C1zL6LdSI for ; Thu, 23 Jul 2015 14:06:29 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0125.outbound.protection.outlook.com [65.55.169.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 208001A9071 for ; Thu, 23 Jul 2015 14:06:28 -0700 (PDT) Received: from BN3PR09MB0355.namprd09.prod.outlook.com (10.160.115.152) by BN3PR09MB0353.namprd09.prod.outlook.com (10.160.115.150) with Microsoft SMTP Server (TLS) id 15.1.225.19; Thu, 23 Jul 2015 21:06:27 +0000 Received: from BN3PR09MB0355.namprd09.prod.outlook.com ([10.160.115.152]) by BN3PR09MB0355.namprd09.prod.outlook.com ([10.160.115.152]) with mapi id 15.01.0219.018; Thu, 23 Jul 2015 21:06:27 +0000 From: "Borchert, Oliver" To: Sandra Murphy , "Borchert, Oliver" Thread-Topic: [sidr] WGLC for drained ft-ietf-sidr-rpki-rtr-rfc6810-bis-03 Thread-Index: AQHQZ0CTdT6ASHFRyUaxHdTkYjFfEJ3eoDOAgAvJsAA= Date: Thu, 23 Jul 2015 21:06:27 +0000 Message-ID: In-Reply-To: <44E7D017-9EC5-4C24-A8BE-903B5EEEE82B@tislabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 authentication-results: tislabs.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.219.183] x-microsoft-exchange-diagnostics: 1; BN3PR09MB0353; 5:vh5QsIknHDh/SUQRobLrZEHNN41+/HABjwexmeN2Cd8rN+PlQ5sjqr9RrGNiWCIk5BQ2M5/rkOFMyXHhIa48HoEt8Q89ZxAd1M7tWB4Bh2PLaMMnCnhQFYZVmRYh6VfEC8hI+yqkClbOSfKICoeLTg==; 24:QBtqFAlhN+pTp1H89mJv39QeRe8p1oZlzX/nHf3gcZaAuzOUDCt/zxqKLhGthXgAcaR/cM+pk53HxoWxTLLIVv/wGwGsBC9rYS//BWybp9Q=; 20:3q6cbgQ75U8yeiqjXsG01qmyfx6IG4Bh2OMjkH0QEyE6N74d2NIe7FnvYPzH5y15wZUDoTmoEEV5k8vwaNBGJA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR09MB0353; bn3pr09mb0353: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN3PR09MB0353; BCL:0; PCL:0; RULEID:; SRVR:BN3PR09MB0353; x-forefront-prvs: 06469BCC91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(40224003)(24454002)(30584003)(479174004)(66066001)(86362001)(230783001)(19580395003)(2656002)(87936001)(83506001)(19580405001)(4001450100002)(46102003)(5002640100001)(4001350100001)(5001770100001)(5001960100002)(77156002)(62966003)(189998001)(2950100001)(2900100001)(77096005)(15975445007)(102836002)(54356999)(92566002)(122556002)(106116001)(40100003)(50986999)(99286002)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR09MB0353; H:BN3PR09MB0355.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2015 21:06:27.2734 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR09MB0353 Archived-At: Cc: sidr list , David Mandelberg Subject: Re: [sidr] WGLC for drained ft-ietf-sidr-rpki-rtr-rfc6810-bis-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 21:06:31 -0000 U2FuZHksDQoNClllcyBJIGRvIGJlbGlldmUgdGhlIGNvbW1lbnRzIGFyZSBzYXRpc2ZpZWQsDQpP bGl2ZXINCg0KT24gNy8xNi8xNSAxOjA1IFBNLCAiU2FuZHJhIE11cnBoeSIgPHNhbmR5QHRpc2xh YnMuY29tPiB3cm90ZToNCg0KPkNvdWxkIHlvdSBwbGVhc2UgcmVwbHkgdG8gdGhlIGxpc3QgYW5k IHNheSB3aGV0aGVyIHlvdSBiZWxpZXZlIHRoYXQgdGhlDQo+ZHJhZnQtaWV0Zi1zaWRyLXJwa2kt cnRyLXJmYzY4MTAtYmlzLTA0LnR4dCB2ZXJzaW9uIHNhdGlzZmllcyB5b3VyDQo+Y29tbWVudHM/ ICBJdCB3b3VsZCBoZWxwIHdpdGggdGhlIHByb2Nlc3MuDQo+DQo+LS1TYW5keQ0KPg0KPk9uIE1h ciAyNSwgMjAxNSwgYXQgNToxMyBQTSwgIkJvcmNoZXJ0LCBPbGl2ZXIiDQo+PG9saXZlci5ib3Jj aGVydEBuaXN0Lmdvdj4gd3JvdGU6DQo+DQo+PiBEYXZpZCwNCj4+IA0KPj4gQSBjb3JyZWN0aW9u IGZvciBteSBwcmV2aW91cyBlbWFpbCwgSSBtaXhlZCB1cCBzZXNzaW9uIGlkIGFuZCBzZXJpYWwN Cj4+IG51bWJlci4NCj4+IEkgdGhpbmsgdG8ga2VlcCBpdCBzaW1wbGUgZm9yIHZlcnNpb24gMCAt IDEgc3dpdGNoZXMgYW5kIGZ1dHVyZQ0KPj5jaGFuZ2VzLCBhDQo+PiBjaGFuZ2UNCj4+IFdpdGhp biB0aGUgc2Vzc2lvbiBpZCBhbmQgdmVyc2lvbiBpZCBzaG91bGQgdHJpZ2dlciBhIOKAnENhY2hl IFJlc2V04oCdIGJ5DQo+PnRoZQ0KPj4gY2FjaGUNCj4+IEFuZCB0aGUgY2xpZW50IG11c3QgcmVz eW5jaCB3aXRoIHRoZSBzZXJ2ZXIuDQo+PiBBbmQgeWVzLCB3b3JkaW5nIGluIHRoaXMgbWF0dGVy IG1pZ2h0IG5lZWQgdG8gYmUgYWRkZWQgLSBidXQgc3RpbGwgaXQNCj4+YWxzbw0KPj4gY291bGQN Cj4+IEJlIGFuIGltcGxlbWVudGF0aW9uIGlzc3VlLg0KPj4gDQo+PiBPbGl2ZXINCj4+IA0KPj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPj4gT2xpdmVyIEJvcmNoZXJ0LCBDb21wdXRlciBTY2llbnRpc3QNCj4+IE5hdGlvbmFs IEluc3RpdHV0ZSBvZiBTdGFuZGFyZHMgYW5kIFRlY2hub2xvZ3kNCj4+IChQaG9uZSkgMzAxLjk3 NS40ODU2ICwgKEZheCkgMzAxLjk3NS42MjM4DQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4g T24gMy8yNC8xNSwgMTA6NTggQU0sICJCb3JjaGVydCwgT2xpdmVyIiA8b2xpdmVyLmJvcmNoZXJ0 QG5pc3QuZ292Pg0KPj53cm90ZToNCj4+IA0KPj4+IElzbsK5dCB0aGlzIGFuIGltcGxlbWVudGF0 aW9uIGlzc3VlPyBUaGUgY2xpZW50IGVpdGhlciBzcGVha3MgMCBvciAxLiBBcw0KPj4+IGxvbmcg YXMgdGhlIHNlcnZlcg0KPj4+IGtlZXBzIHRyYWNrIG9mIHRoZSB2ZXJzaW9uIGZvciB0aGUgc2Vz c2lvbiBJTUhPIGl0IGRvZXMgbm90IG1hdHRlciBpZg0KPj4+dGhlDQo+Pj4gc2Vzc2lvbiBpZCBp cw0KPj4+IHNoYXJlZD8gVGhlIGNsaWVudCBkb2VzbsK5dCBrbm93IGFib3V0IGl0LiBMZXRzIHNh eSBvbmUgZW5jb3VudGVyIGEgbmV3DQo+Pj5rZXkNCj4+PiBhbmQgdGhpcw0KPj4+IE9ubHkgdHJp Z2dlcnMgYSBQRFUgOSwgdGhlIHNlcnZlciBzZW5kcyBzZW5kIG91dCB0aGUgbm90aWZpY2F0aW9u LiBUaGUNCj4+PiBjbGllbnQgY2FuIGJ1dCBtdXN0IG5vdA0KPj4+IFJlYWN0IHRvIGl0IGFueWhv dy4gSWYgdGhlIGNsaWVudCByZWFjdHMsIHRoZSBzZXJ2ZXIgc2VuZHMgYW4gZW5kIG9mDQo+Pj4g dXBkYXRlIHRvIGEgdmVyc2lvbiAwDQo+Pj4gc2Vzc2lvbiBhbmQgYWxsIHBkdSA5IHVwZGF0ZXMg dG8gYSB2ZXJzaW9uIDEgc2Vzc2lvbi4NCj4+PiBJIGRvbsK5dCBzZWUgYSBuZWVkZWQgd29yZGlu ZyBoZXJlLiBOb3QgeWV0IGJ1dCBJxZJtIG9wZW4gZm9yDQo+Pj5lbmxpZ2h0ZW5tZW50Lg0KPj4+ IA0KPj4+IE9saXZlcg0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiBPbGl2ZXIgQm9yY2hlcnQsIENvbXB1dGVyIFNj aWVudGlzdA0KPj4+IE5hdGlvbmFsIEluc3RpdHV0ZSBvZiBTdGFuZGFyZHMgYW5kIFRlY2hub2xv Z3kNCj4+PiAoUGhvbmUpIDMwMS45NzUuNDg1NiAsIChGYXgpIDMwMS45NzUuNjIzOA0KPj4+IA0K Pj4+IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IE9uIDMvMjQvMTUsIDEwOjM2IEFNLCAiRGF2aWQg TWFuZGVsYmVyZyIgPGRhdmlkQG1hbmRlbGJlcmcub3JnPiB3cm90ZToNCj4+PiANCj4+Pj4gUm9i IGFuZCBJIHdlcmUgdGFsa2luZyBhYm91dCBycGtpLXJ0ciwgYW5kIEkgY2FtZSB1cCB3aXRoIGFu b3RoZXINCj4+Pj4gcG90ZW50aWFsIGlzc3VlIHdpdGggc3dpdGNoaW5nIGJldHdlZW4gcHJvdG9j b2wgdmVyc2lvbnMuIEkgZG9uJ3Qgc2VlDQo+Pj4+IGFueSB0ZXh0IGFib3V0IHdoZXRoZXIgYSBz aW5nbGUgc2Vzc2lvbiAoc2Vzc2lvbiBpZCBhbmQgc2VyaWFsDQo+Pj4+bnVtYmVycykNCj4+Pj4g Y2FuIGJlIHVzZWQgZm9yIGJvdGggdmVyc2lvbiAwIGFuZCAxLiBJZiBhIHJvdXRlciBoYXMgYSB2 YWxpZCB2ZXJzaW9uDQo+Pj4+MA0KPj4+PiBzZXNzaW9uLCB1cGdyYWRlcyB0byB2ZXJzaW9uIDEs IGFuZCBpc3N1ZXMgYSBzZXJpYWwgcXVlcnkgd2l0aCB0aGUNCj4+Pj5zYW1lDQo+Pj4+IHNlc3Np b24gaWQgYW5kIHNlcmlhbCBudW1iZXIsIGl0J3MgdW5jbGVhciB3aGF0IHRoZSBzZXJ2ZXIgc2hv dWxkIGRvLg0KPj4+PiBDb3VsZCB3ZSBhZGQgdGV4dCB0byB0aGUgZG9jdW1lbnQgc2F5aW5nIHRo YXQgdGhlIGNhY2hlIE1VU1QgbWFpbnRhaW4NCj4+Pj5hDQo+Pj4+IHNlcGFyYXRlIHNlc3Npb24g Zm9yIGVhY2ggcHJvdG9jb2wgdmVyc2lvbiBpdCBzdXBwb3J0cywgYW5kIGEgcm91dGVyDQo+Pj4+ IE1VU1QgTk9UIGF0dGVtcHQgdG8gcmV1c2Ugc2Vzc2lvbiBpbmZvcm1hdGlvbiBhY3Jvc3MgbXVs dGlwbGUgcHJvdG9jb2wNCj4+Pj4gdmVyc2lvbnM/DQo+Pj4+IA0KPj4+PiAtLQ0KPj4+PiBEYXZp ZCBFcmljIE1hbmRlbGJlcmcgLyBkc2VvbW4NCj4+Pj4gaHR0cDovL2RhdmlkLm1hbmRlbGJlcmcu b3JnLw0KPj4+PiANCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+Pj4gc2lkciBtYWlsaW5nIGxpc3QNCj4+Pj4gc2lkckBpZXRmLm9yZw0KPj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpZHINCj4+PiANCj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IHNpZHIg bWFpbGluZyBsaXN0DQo+Pj4gc2lkckBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2lkcg0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2lkciBtYWlsaW5nIGxpc3QNCj4+IHNpZHJAaWV0 Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lkcg0KPg0K DQo= From nobody Thu Jul 23 22:31:20 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698021B2DDD for ; Thu, 23 Jul 2015 22:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jOGq-7bQ_5e for ; Thu, 23 Jul 2015 22:31:15 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F741ACE2B for ; Thu, 23 Jul 2015 22:31:15 -0700 (PDT) Received: by obdeg2 with SMTP id eg2so10328569obd.0 for ; Thu, 23 Jul 2015 22:31:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XQ3lvkQ83LTPJrEezRW3hHV6Q+n9c6ij/2054J3AocU=; b=TixDeY/w3/Vzc562w0gzCbVaefCvo0VC44ih9nvPVRUktdeDNgLuxaQ9S178tWFCbh eps7qV5QRWHuxBMFhDo1RiNbw9H0k2CYjRL3ak66iSo0nG0LNesiPiiJtFOH0/zYc6dS MFaGqSDeAvpa7knyMgRh8P9nBwUmlaiTNCybWMsWLvJJfmQ9SOyeyC7H5QCA13vXJR4M vZMzE5EiWGabvDi6VsOMFCIF76VJ6GL0tQPBx+oio0dwespQm+pHF5XzbGIP456e5Sbr c+OKBJ9SY5sr69t6MnDvqqU/3OB4+kMRjHXoVEFEt6lGoCxypE81fGnrKiBKCUpw5Hkw 269g== MIME-Version: 1.0 X-Received: by 10.60.33.74 with SMTP id p10mr13691717oei.62.1437715874713; Thu, 23 Jul 2015 22:31:14 -0700 (PDT) Received: by 10.202.201.86 with HTTP; Thu, 23 Jul 2015 22:31:14 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 Jul 2015 01:31:14 -0400 Message-ID: From: Matthew Lepinski To: "George, Wes" Content-Type: multipart/alternative; boundary=089e0115eef8001921051b985088 Archived-At: Cc: "sidr@ietf.org" Subject: Re: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 05:31:18 -0000 --089e0115eef8001921051b985088 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Wes, Sorry for the delay. I completely agree with you that the text in 7.1 could be more clear. I appreciate your suggested change and I am happy to issue a quick revision to clarify this issue. With regards to the validation algorithm (Section 5.2), I am not convinced there is a problem. The document currently states (at the beginning of 5.2 on page 26) that implements must have the same input/output behavior as the validation algorithm in the document. That is, my interpretation of the current text is that we don't want to mandate any particular algorithm (or rule out any potential implementation-specific optimizations), but we want every implementation to return "Valid" on the same inputs as any other implementation. I believe this means that implementations are free to "skip-out" after a failed signature verification or not as they see fit [and still be compliant with the spec either way]. That being said, I agree with you that from the point of view of a denial-of-service prevention, that we should be recommending that implementations "Skip out" after a failed signature verification. When I read the text in "Step III" on page 29 within Section 5.2, I interpret that text as indicating that implementations should skip the remaining signatures once they get a failed signature verification. If you interpret that text differently, please let me know, but in my reading of the document, I understand the 5.2 algorithm as saying implementations should "skip out" when a signature is bad. - Matt Lepinski On Fri, Jul 10, 2015 at 3:08 PM, George, Wes wrote: > Matt - > > I finally got a chance to review the updates you put in for =E2=80=9312 = and 13. > It has addressed most of the concerns I raised. Only thing I see missing = is > this comment from my previous review. > > Section 5.2 - elsewhere in the document (7.3), you note that validation > should stop when an invalid signature is found. However, I see no mention > of that in the actual validation algorithm. That seems like good practice > even if there isn't a long chain of signatures to validate. > Additionally, 7.1's text "Thus, a BGPsec speaker MUST completely validate > all BGPsec update messages received from external peers." seems to > conflict with this recommendation because it says "completely". I think > it's a wording problem, i.e. We're not saying you MUST validate the > *entire* update, but rather you must validate ALL updates that you > *receive* until you encounter an invalid signature within a given update, > in which case you can stop and move to the next update. > > > Thanks, > > > > Wes > > > > From: sidr on behalf of Matthew Lepinski < > mlepinski.ietf@gmail.com> > Date: Monday, June 15, 2015 at 12:41 AM > To: "sidr@ietf.org" > Subject: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12 > > I have submitted a new version of the BGPsec protocol specification. > > This version includes some minor fixes as well as all of the changes > discussed at IETF 92. (Minutes can be found here -- > http://www.ietf.org/proceedings/92/minutes/minutes-92-sidr) I believe > that all open issues with this document have been addressed. > > The only normative changes in the -12 version are the following: > -- BGPsec speakers MUST support the multi-protocol extension (RFC 4760) > -- BGPsec now signs the entire MP_REACH_NLRI attribute. (Recall that ther= e > was an error previously where the AFI was not protected under the signatu= re) > > I believe that this document is now ready to ship to the IESG. If you > disagree, please let me know what still needs to be addressed. > > - Matt Lepinski > > ------------------------------ > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely > for the use of the individual or entity to which it is addressed. If you > are not the intended recipient of this E-mail, you are hereby notified th= at > any dissemination, distribution, copying, or action taken in relation to > the contents of and attachments to this E-mail is strictly prohibited and > may be unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any copy o= f > this E-mail and any printout. > --089e0115eef8001921051b985088 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wes,

Sorry for the delay. I completely = agree with you that the text in 7.1 could be more clear. I appreciate your = suggested change and I am happy to issue a quick revision to clarify this i= ssue.

With regards to the validation algorithm (Section 5.2),= I am not convinced there is a problem. The document currently states (at t= he beginning of 5.2 on page 26) that implements must have the same input/ou= tput behavior as the validation algorithm in the document. That is, my inte= rpretation of the current text is that we don't want to mandate any par= ticular algorithm (or rule out any potential implementation-specific optimi= zations), but we want every implementation to return "Valid" on t= he same inputs as any other implementation. I believe this means that imple= mentations are free to "skip-out" after a failed signature verifi= cation or not as they see fit [and still be compliant with the spec either = way].

That being said, I agree with you that from = the point of view of a denial-of-service prevention, that we should be reco= mmending that implementations "Skip out" after a failed signature= verification. When I read the text in "Step III" on page 29 with= in Section 5.2, I interpret that text as indicating that implementations sh= ould skip the remaining signatures once they get a failed signature verific= ation. If you interpret that text differently, please let me know, but in m= y reading of the document, I understand the 5.2 algorithm as saying impleme= ntations should "skip out" when a signature is bad.=C2=A0

- Matt Lepinski
On Fri, Jul 10, 2015 at 3:08 PM, George, Wes <wesley.george@twcable.com> wrote:
Matt -=C2=A0

I finally got a chance to review the updates you put in for =E2=80=931= 2 and 13. It has addressed most of the concerns I raised. Only thing I see = missing is this comment from my previous review.=C2=A0

Section 5.2 - elsewher= e in the document (7.3), you note that validation
should stop when an in= valid signature is found. However, I see no mention
of that in the actual = validation algorithm. That seems like good practice
even if there isn'= t a long chain of signatures to validate.
Additionally, 7.1'= s text "Thus, a BGPsec speaker MUST completely validate
all BGPsec update mess= ages received from external peers." seems to
conflict with this rec= ommendation because it says "completely". I think
it's a wording pro= blem, i.e. We're not saying you MUST validate the
*entire* update, but r= ather you must validate ALL updates that you
*receive* until you en= counter an invalid signature within a given update,
in which case you can = stop and move to the next update.


Tha= nks,

= =C2=A0

Wes=

= =C2=A0


From: sidr <sidr-bounces@ietf.org> on beh= alf of Matthew Lepinski <mlepinski.ietf@gmail.com>
Date: Monday, June 15, 2015 at 12:4= 1 AM
To: "sidr@ietf.org" <sidr@ietf.org>
Subject: [sidr] New Version: draft-= ietf-sidr-bgpsec-protocol-12


This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.

--089e0115eef8001921051b985088-- From nobody Fri Jul 24 06:33:13 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952581A6EE2; Fri, 24 Jul 2015 06:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOLiYJ-oehHy; Fri, 24 Jul 2015 06:33:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F481A905F; Fri, 24 Jul 2015 06:32:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.1.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150724133255.23566.85626.idtracker@ietfa.amsl.com> Date: Fri, 24 Jul 2015 06:32:55 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rfc6485bis-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 13:33:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : The Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure Authors : Geoff Huston George Michaelson Filename : draft-ietf-sidr-rfc6485bis-03.txt Pages : 9 Date : 2015-07-24 Abstract: This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate Revocation Lists (CRLs), Cryptographic Message Syntax (CMS) signed objects and certification requests as well as for the relying parties (RPs) that verify these digital signatures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-rfc6485bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rfc6485bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jul 25 01:48:05 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB45E1B2A07 for ; Sat, 25 Jul 2015 01:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.801 X-Spam-Level: X-Spam-Status: No, score=-101.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLNwwTpIFBpJ for ; Sat, 25 Jul 2015 01:48:02 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C185C1B29FF for ; Sat, 25 Jul 2015 01:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to:x-mailer:return-path: x-originating-ip; bh=SqHf+e1EK0PNeCGGDSp0v1HyLJECZZGhOLuoFjguUXs=; b=T1T09eM0h0fNB1VxISRQcm6+3oZb6tI5Bh7lvbL4/EzZ5aLeV3zCM8jVyo+nd3zEt6j9RI7flZcos Puop8C5PRyVaW70pQgO7JpV75MZPrmO7l4R8/Hs2fs++/NIB2wVphdGfBSEoZiRU4Uvp7IgnVk0K82 1V04Bb+dEXrR9V20= Received: from iamda3.org.apnic.net (unknown [IPv6:2001:dd8:9:2::101:249]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS for ; Sat, 25 Jul 2015 18:47:46 +1000 (AEST) Received: from [192.168.0.32] (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.1.218.12; Sat, 25 Jul 2015 18:47:49 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Geoff Huston In-Reply-To: <20150724133255.23566.85626.idtracker@ietfa.amsl.com> Date: Sat, 25 Jul 2015 10:47:44 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <2C6935CA-971B-45E0-BF42-AAB9FAAD2335@apnic.net> References: <20150724133255.23566.85626.idtracker@ietfa.amsl.com> To: sidr wg list X-Mailer: Apple Mail (2.2102) X-Originating-IP: [203.119.101.249] Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rfc6485bis-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 08:48:05 -0000 With many thanks to Richard Hansen for his editing of this draft, I = believe that this draft addresses both the underlying tech issue that was unable to = be addressed in an erratum, and also addressed the other outstanding errata reported = for RFC 6485,=20 as well as correcting minor nits that escaped the eagle eyes of various = reviewers of the RFC and previous versions of this draft, and hopefully I=E2=80=99ve = avoided adding more nits in my final markup! Chairs (well, specifically Sandy, as she has been working with me on = getting this document ready), I=E2=80=99m not sure of the current WG status of this = document, wrt last calls, etc, but I believe its about as cooked as it is ever going to be! regards, Geoff =20 > On 24 Jul 2015, at 3:32 pm, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Inter-Domain Routing Working = Group of the IETF. >=20 > Title : The Profile for Algorithms and Key Sizes for = use in the Resource Public Key Infrastructure > Authors : Geoff Huston > George Michaelson > Filename : draft-ietf-sidr-rfc6485bis-03.txt > Pages : 9 > Date : 2015-07-24 >=20 > Abstract: > This document specifies the algorithms, algorithms' parameters, > asymmetric key formats, asymmetric key size, and signature format = for > the Resource Public Key Infrastructure (RPKI) subscribers that > generate digital signatures on certificates, Certificate Revocation > Lists (CRLs), Cryptographic Message Syntax (CMS) signed objects and > certification requests as well as for the relying parties (RPs) that > verify these digital signatures. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-rfc6485bis-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rfc6485bis-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Tue Jul 28 06:19:37 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCD61A8AED for ; Tue, 28 Jul 2015 06:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.926 X-Spam-Level: ** X-Spam-Status: No, score=2.926 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j91mS3bvgac0 for ; Tue, 28 Jul 2015 06:19:33 -0700 (PDT) Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4051A8AE7 for ; Tue, 28 Jul 2015 06:19:33 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.15,563,1432612800"; d="scan'208,217";a="291265606" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 28 Jul 2015 08:57:49 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Tue, 28 Jul 2015 09:19:32 -0400 From: "George, Wes" To: Matthew Lepinski Date: Tue, 28 Jul 2015 09:19:30 -0400 Thread-Topic: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12 Thread-Index: AdDJOApFP3+P0RODQqOros+OR1wFJg== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D1DCF6A75EB29wesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: Cc: "sidr@ietf.org" Subject: Re: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 13:19:35 -0000 --_000_D1DCF6A75EB29wesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGcm9tOiBNYXR0aGV3IExlcGluc2tpIDxtbGVwaW5za2kuaWV0ZkBnbWFpbC5jb208bWFpbHRv Om1sZXBpbnNraS5pZXRmQGdtYWlsLmNvbT4+DQpEYXRlOiBGcmlkYXksIEp1bHkgMjQsIDIwMTUg YXQgMTozMSBBTQ0KVG86ICJHZW9yZ2UsIFdlcyIgPHdlc2xleS5nZW9yZ2VAdHdjYWJsZS5jb208 bWFpbHRvOndlc2xleS5nZW9yZ2VAdHdjYWJsZS5jb20+Pg0KQ2M6ICJzaWRyQGlldGYub3JnPG1h aWx0bzpzaWRyQGlldGYub3JnPiIgPHNpZHJAaWV0Zi5vcmc8bWFpbHRvOnNpZHJAaWV0Zi5vcmc+ Pg0KU3ViamVjdDogUmU6IFtzaWRyXSBOZXcgVmVyc2lvbjogZHJhZnQtaWV0Zi1zaWRyLWJncHNl Yy1wcm90b2NvbC0xMg0KDQpUaGF0IGJlaW5nIHNhaWQsIEkgYWdyZWUgd2l0aCB5b3UgdGhhdCBm cm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIGEgZGVuaWFsLW9mLXNlcnZpY2UgcHJldmVudGlvbiwg dGhhdCB3ZSBzaG91bGQgYmUgcmVjb21tZW5kaW5nIHRoYXQgaW1wbGVtZW50YXRpb25zICJTa2lw IG91dCIgYWZ0ZXIgYSBmYWlsZWQgc2lnbmF0dXJlIHZlcmlmaWNhdGlvbi4gV2hlbiBJIHJlYWQg dGhlIHRleHQgaW4gIlN0ZXAgSUlJIiBvbiBwYWdlIDI5IHdpdGhpbiBTZWN0aW9uIDUuMiwgSSBp bnRlcnByZXQgdGhhdCB0ZXh0IGFzIGluZGljYXRpbmcgdGhhdCBpbXBsZW1lbnRhdGlvbnMgc2hv dWxkIHNraXAgdGhlIHJlbWFpbmluZyBzaWduYXR1cmVzIG9uY2UgdGhleSBnZXQgYSBmYWlsZWQg c2lnbmF0dXJlIHZlcmlmaWNhdGlvbi4gSWYgeW91IGludGVycHJldCB0aGF0IHRleHQgZGlmZmVy ZW50bHksIHBsZWFzZSBsZXQgbWUga25vdywgYnV0IGluIG15IHJlYWRpbmcgb2YgdGhlIGRvY3Vt ZW50LCBJIHVuZGVyc3RhbmQgdGhlIDUuMiBhbGdvcml0aG0gYXMgc2F5aW5nIGltcGxlbWVudGF0 aW9ucyBzaG91bGQgInNraXAgb3V0IiB3aGVuIGEgc2lnbmF0dXJlIGlzIGJhZC4NCg0KV0ddIEkg YWdyZWUgd2l0aCB5b3VyIGludGVycHJldGF0aW9uLiBBcyBSYW5keSBwb2ludGVkIG91dCwgdGhp cyBpcyBwcm9iYWJseSBhIGNhc2Ugb2YgbWlzaW50ZXJwcmV0YXRpb24gZHVlIHRvIHRoZSBmYWN0 IHRoYXQgSSdtIG5vdCB0aGUgdGFyZ2V0IGF1ZGllbmNlIChpbXBsZW1lbnRlcnMpIGFuZCB0aHVz IEkgbWlzc2VkIHNvbWV0aGluZyB0aGF0IHdvdWxkIGhhdmUgYmVlbiBvYnZpb3VzIHRvIHlvdXIg dGFyZ2V0IGF1ZGllbmNlLg0KDQpUaGFua3MNCldlcw0KDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1h eSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGlj aCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJl bG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29s ZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBp cyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhp cyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24s IGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRo ZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkg cHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFu ZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUt bWFpbCBhbmQgYW55IHByaW50b3V0Lg0K --_000_D1DCF6A75EB29wesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlf U0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFw dDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5v bmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElO Ry1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQg c29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5NYXR0aGV3IExlcGluc2tp ICZsdDs8YSBocmVmPSJtYWlsdG86bWxlcGluc2tpLmlldGZAZ21haWwuY29tIj5tbGVwaW5za2ku aWV0ZkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5EYXRlOiA8L3NwYW4+RnJpZGF5LCBKdWx5IDI0LCAyMDE1IGF0IDE6MzEgQU08YnI+DQo8c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4mcXVvdDtHZW9yZ2UsIFdlcyZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndlc2xleS5nZW9yZ2VAdHdjYWJsZS5jb20iPndlc2xl eS5nZW9yZ2VAdHdjYWJsZS5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5DYzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpzaWRyQGlldGYub3JnIj5z aWRyQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpZHJAaWV0Zi5vcmci PnNpZHJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5TdWJqZWN0OiA8L3NwYW4+UmU6IFtzaWRyXSBOZXcgVmVyc2lvbjogZHJhZnQtaWV0Zi1zaWRy LWJncHNlYy1wcm90b2NvbC0xMjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXYg ZGlyPSJsdHIiPg0KPGRpdj5UaGF0IGJlaW5nIHNhaWQsIEkgYWdyZWUgd2l0aCB5b3UgdGhhdCBm cm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIGEgZGVuaWFsLW9mLXNlcnZpY2UgcHJldmVudGlvbiwg dGhhdCB3ZSBzaG91bGQgYmUgcmVjb21tZW5kaW5nIHRoYXQgaW1wbGVtZW50YXRpb25zICZxdW90 O1NraXAgb3V0JnF1b3Q7IGFmdGVyIGEgZmFpbGVkIHNpZ25hdHVyZSB2ZXJpZmljYXRpb24uIFdo ZW4gSSByZWFkIHRoZSB0ZXh0IGluICZxdW90O1N0ZXAgSUlJJnF1b3Q7IG9uIHBhZ2UgMjkgd2l0 aGluDQogU2VjdGlvbiA1LjIsIEkgaW50ZXJwcmV0IHRoYXQgdGV4dCBhcyBpbmRpY2F0aW5nIHRo YXQgaW1wbGVtZW50YXRpb25zIHNob3VsZCBza2lwIHRoZSByZW1haW5pbmcgc2lnbmF0dXJlcyBv bmNlIHRoZXkgZ2V0IGEgZmFpbGVkIHNpZ25hdHVyZSB2ZXJpZmljYXRpb24uIElmIHlvdSBpbnRl cnByZXQgdGhhdCB0ZXh0IGRpZmZlcmVudGx5LCBwbGVhc2UgbGV0IG1lIGtub3csIGJ1dCBpbiBt eSByZWFkaW5nIG9mIHRoZSBkb2N1bWVudCwgSSB1bmRlcnN0YW5kDQogdGhlIDUuMiBhbGdvcml0 aG0gYXMgc2F5aW5nIGltcGxlbWVudGF0aW9ucyBzaG91bGQgJnF1b3Q7c2tpcCBvdXQmcXVvdDsg d2hlbiBhIHNpZ25hdHVyZSBpcyBiYWQuJm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldHXSBJIGFncmVlIHdpdGggeW91ciBpbnRlcnByZXRhdGlv bi4gQXMgUmFuZHkgcG9pbnRlZCBvdXQsIHRoaXMgaXMgcHJvYmFibHkgYSBjYXNlIG9mIG1pc2lu dGVycHJldGF0aW9uIGR1ZSB0byB0aGUgZmFjdCB0aGF0IEknbSBub3QgdGhlIHRhcmdldCBhdWRp ZW5jZSAoaW1wbGVtZW50ZXJzKSBhbmQgdGh1cyBJIG1pc3NlZCBzb21ldGhpbmcgdGhhdCB3b3Vs ZCBoYXZlIGJlZW4gb2J2aW91cyB0byB5b3VyIHRhcmdldCBhdWRpZW5jZS48L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rczwvZGl2Pg0KPGRpdj5XZXM8L2Rpdj4NCjxzcGFuIGlk PSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PGJyPg0KPGhyPg0KPGZvbnQg ZmFjZT0iQXJpYWwiIGNvbG9yPSJHcmF5IiBzaXplPSIxIj5UaGlzIEUtbWFpbCBhbmQgYW55IG9m IGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFy eSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJq ZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1t YWlsIGlzIGludGVuZGVkIHNvbGVseQ0KIGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9y IGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRo YXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRh a2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8NCiB0 aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwg YW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuPGJyPg0KPC9mb250 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D1DCF6A75EB29wesleygeorgetwcablecom_-- From nobody Tue Jul 28 22:53:02 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654C81A854C for ; Tue, 28 Jul 2015 22:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeEPxjc4y9wp for ; Tue, 28 Jul 2015 22:53:00 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1871A86F5 for ; Tue, 28 Jul 2015 22:52:54 -0700 (PDT) Received: from LIUXD (unknown [218.241.103.243]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0BJUGQ0arhV_OqnBw--.17834S3; Wed, 29 Jul 2015 13:52:52 +0800 (CST) From: "Fu Yu" To: "'sidr'" Date: Wed, 29 Jul 2015 13:53:17 +0800 Message-ID: <001c01d0c9c2$de1634a0$9a429de0$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdDJvYTuk5c/K+hYTfOSQbZNYMeNSwABFY7g Content-Language: zh-cn X-CM-TRANSID: AQAAf0BJUGQ0arhV_OqnBw--.17834S3 X-Coremail-Antispam: 1UD129KBjvdXoW7GFyDJry5Gw4UZF43GF4rZrb_yoWkGFbEya 1rCryDJw42vrWktr43tryI9rsaq3s093WfC34jq3sF934UZw4DWrs7G345ur17tw1rGw45 A3ZxJr90yrs8WjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUb28YjsxI4VW3JwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW5JVW7JwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIE14v26F4UJVW0owA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IE w4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_JrI_JrylYx0Ex4A2jsIE14v26r1j6r4UMc vjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCY02Avz4vE14v_GrWl42xK82IY c2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s 026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1j6r15MIIYrxkI7VAKI48JMIIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0x vE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07jYoGQUUUUU= X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: Subject: [sidr] FW: New Version Notification for draft-lee-sidr-rpki-deployment-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 05:53:02 -0000 Hi all,=20 We have submitted a new draft for the RPKI deployment considerations as = below. It analyze some problems when we simulated the RPKI deployment scenarios = in the lab of CNNIC. Some solutions are also analyzed for these problems in the draft. Your valuable comments are appreciated. Cheers Yu Name: draft-lee-sidr-rpki-deployment Revision: 00 Title: RPKI Deployment Considerations: Problem Analysis and Alternative = Solutions Document date: 2015-07-28 Group: Individual Submission Pages: 13 URL: = https://www.ietf.org/internet-drafts/draft-lee-sidr-rpki-deployment-00.tx= t Status: = https://datatracker.ietf.org/doc/draft-lee-sidr-rpki-deployment/ Htmlized: = https://tools.ietf.org/html/draft-lee-sidr-rpki-deployment-00 Abstract: With the global deployment of RPKI, a lot of concerns from technical, economic and political aspects have and will be raised. In this draft, we collect and analyze the problems have been appeared or will appear during the RPKI deployment, and give the alternative solutions to address or mitigate these problems. = =20 From nobody Wed Jul 29 17:52:30 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC561B313F; Wed, 29 Jul 2015 17:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsN9k-eScUUp; Wed, 29 Jul 2015 17:52:24 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82DE61B3121; Wed, 29 Jul 2015 17:52:24 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:41375) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZKc59-0007U7-4i; Wed, 29 Jul 2015 20:52:23 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id CF2E940076 Message-ID: <55B97546.3060200@bbn.com> Date: Wed, 29 Jul 2015 20:52:22 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: sidr@ietf.org References: <20150709134637.7120.70507.idtracker@ietfa.amsl.com> <55A5E727.7020605@bbn.com> In-Reply-To: <55A5E727.7020605@bbn.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: ietf@ietf.org Subject: Re: [sidr] Last Call: (Resource Public Key Infrastructure (RPKI) Trust Anchor Locator) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 00:52:27 -0000 Hi all, I misread the MIME RFC; it requires line breaks every 76 characters, not every 75. So I think 76 is a better choice. My new proposal is to change Section 2.1 item #3 from: 3) a subjectPublicKeyInfo [RFC5280] in DER format [X.509], encoded in Base64 (see Section 4 of [RFC4648]. to: 3) a subjectPublicKeyInfo [RFC5280] in DER format [X.509], encoded in Base64 (see Section 4 of [RFC4648]). To avoid long lines, a or line break MUST be inserted into the Base64 encoded string every 76 or fewer characters. (This is the same as option #3 in my previous email but with 76 instead of 75.) -Richard On 2015-07-15 00:52, Richard Hansen wrote: > There is one substantive issue I noticed: embedded newlines in the > Base64 string. > > Section 2.1 refers to Base64 encoding, defined in RFC4648 Section 4. > RFC4648 Section 3.1 says: > > Implementations MUST NOT add line feeds to base-encoded data unless > the specification referring to this document explicitly directs base > encoders to add line feeds after a specific number of characters. > > This draft does not say anything about adding newlines to the Base64 > string, yet: > > * all published TALs (that I could find) contain embedded newlines at > regular intervals, in violation of this specification > * the example in Section 2.3 contains embedded newlines every 57 > characters > > All existing implementations support embedded newlines at arbitrary > places in the Base64 string, including multiple newlines in a row (if > I'm reading everyone's code correctly). > > I see three possible fixes: > > 1. Add a note next to the example in Section 2.3 that says that > newlines were added to the example due to line length limitations > in the RFC format. Encourage TAL publishers to fix their TALs by > removing the embedded newlines. > > 2. Permit but don't require newlines. For example, change Section 2.1 > item #3 from: > > 3) a subjectPublicKeyInfo [RFC5280] in DER format [X.509], > encoded in Base64 (see Section 4 of [RFC4648]. > > to: > > 3) a subjectPublicKeyInfo [RFC5280] in DER format [X.509], > encoded in Base64 (see Section 4 of [RFC4648]). To avoid > long lines, or line breaks MAY be inserted into > the Base64 encoded string. > > 3. Require line breaks in the Base64 string. For example, change > Section 2.1 item #3 from: > > 3) a subjectPublicKeyInfo [RFC5280] in DER format [X.509], > encoded in Base64 (see Section 4 of [RFC4648]. > > to: > > 3) a subjectPublicKeyInfo [RFC5280] in DER format [X.509], > encoded in Base64 (see Section 4 of [RFC4648]). To avoid > long lines, a or line break MUST be inserted into > the Base64 encoded string every 75 or fewer characters. > > I prefer option #3. If I understand correctly, OpenSSL's Base64 BIO > filter has two modes: no newlines permitted or newlines must be > inserted every 79 or fewer characters. The mode is not automatically > detected; the programmer must choose which mode to use. If the standard > guarantees that all lines will be shorter than 79 characters, then > OpenSSL's Base64 BIO filter can be used without any preprocessing. (The > choice of 75 is more-or-less arbitrary. Keeping it less than 80 is > important for OpenSSL compatibility. MIME (RFC2045) and vCard (RFC6350) > both require Base64 strings to be broken up every 75 or fewer > characters, and I figured it might be good to match.) > > My second choice is option #2. It still requires preprocessing before > OpenSSL's Base64 BIO filter can be used, but it permits existing practice. > > Option #1 is my least favorite. It is the least disruptive to the > document, but it still requires modifying the document so we might as > well modify it to permit existing practice. (Also, getting all of the > RIRs to fix their TALs is probably more work than changing the > specification.) > > Nits: > * section 2.1, item 3: missing close parenthesis > * section 2.1: "comprised of" should be "composed of" > * section 2.1: "one of more" should be "one or more" > * section 3, item 4: "These test" should be "These tests" > * regressions of comma changes made by the RFC Editor before RFC6490 > was published > > -Richard > > > On 2015-07-09 09:46, The IESG wrote: >> >> The IESG has received a request from the Secure Inter-Domain Routing WG >> (sidr) to consider the following document: >> - 'Resource Public Key Infrastructure (RPKI) Trust Anchor Locator' >> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2015-07-23. Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> This document defines a Trust Anchor Locator (TAL) for the Resource >> Public Key Infrastructure (RPKI). This document obsoletes RFC6490 by >> adding support for multiple URIs in a TAL. >> >> >> A down reference exists in this document by using RFC5781 as a Normative >> Reference. RFC5781 has already been accepted by the community as a down >> reference and is properly documented in the DOWNREF Registry. >> >> The DOWNREF Registry can be accessed via >> https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6490-bis/ >> >> IESG discussion can be tracked via >> https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6490-bis/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. From nobody Thu Jul 30 08:51:41 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3601B2DD8; Thu, 30 Jul 2015 08:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pIuVo18LDj3; Thu, 30 Jul 2015 08:51:35 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [147.28.0.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DED321B2DD4; Thu, 30 Jul 2015 08:51:35 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-24-34-34-101.hsd1.ma.comcast.net [24.34.34.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 99522B805; Thu, 30 Jul 2015 15:51:35 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id D18C719D848A; Thu, 30 Jul 2015 11:51:33 -0400 (EDT) Date: Thu, 30 Jul 2015 11:51:33 -0400 From: Rob Austein To: sidr@ietf.org, ietf@ietf.org In-Reply-To: <55B97546.3060200@bbn.com> References: <20150709134637.7120.70507.idtracker@ietfa.amsl.com> <55A5E727.7020605@bbn.com> <55B97546.3060200@bbn.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 Message-Id: <20150730155133.D18C719D848A@minas-ithil.hactrn.net> Archived-At: Subject: Re: [sidr] Last Call: (Resource Public Key Infrastructure (RPKI) Trust Anchor Locator) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 15:51:37 -0000 I think that requiring line breaks is silly. Most Base64 parsers handle arbitrary whitespace. OpenSSL's parser is just plain nasty (yes, I once made the mistake of reading the code), but even with OpenSSL's parser there's a straightforward (if ridiculous) workaround: http://subvert-rpki.hactrn.net/trunk/rp/rcynic/bio_f_linebreak.c http://subvert-rpki.hactrn.net/trunk/rp/rcynic/bio_f_linebreak.h I really don't think we need to enshrine OpenSSL's warts in the specification. I prefer Richard's option 2 (allow but do not require linebreaks), which is what RFC 6490 RP implementations had to support anyway. From nobody Thu Jul 30 17:05:33 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9831B2DFB for ; Thu, 30 Jul 2015 17:05:32 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjrrUIMR40_A for ; Thu, 30 Jul 2015 17:05:31 -0700 (PDT) Received: from nm13-vm1.access.bullet.mail.gq1.yahoo.com (nm13-vm1.access.bullet.mail.gq1.yahoo.com [216.39.63.11]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DDE11B2DAA for ; Thu, 30 Jul 2015 17:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1438301130; bh=l7R+BHw5TuJOIwGwVnkYuHZkB9r67vi03GaLN6uNG+E=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From:Subject; b=juOIbmJggrAV3HQz/DcJURo7xxcQjc7XLwHt3dJYFabrJ2UXjwfsrA8Vbc7WB+TDAoqhPrfwx553IdfRhQ8PdMDnkIEvt5vNumY4JUDPmMfXA5NC9MM+luejVevFAAgjXCPFGyvcGAc55pek/KKaPRNBlhzAHCuVH8sm7XryE9ApE9nW86WimtvFnha72pD26dPZ0cs4gRSVzgv3uCZyrE2JcM4bjuCxRQMEJ+OSaJauvOUnXz4rHXBF789XaEBdu8SyLpzB0d9klOEROB+nbHAyntCq2H4zC9R1E33ThJRhg+giBReELx6vCk/vu2+5g8QSV0t3t7p0WN3U1FgqXw== Received: from [216.39.60.176] by nm13.access.bullet.mail.gq1.yahoo.com with NNFMP; 31 Jul 2015 00:05:30 -0000 Received: from [98.138.226.241] by tm12.access.bullet.mail.gq1.yahoo.com with NNFMP; 31 Jul 2015 00:05:30 -0000 Received: from [127.0.0.1] by smtp112.sbc.mail.ne1.yahoo.com with NNFMP; 31 Jul 2015 00:05:30 -0000 X-Yahoo-Newman-Id: 776784.79972.bm@smtp112.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: cfFKHDQVM1l7Espxvi8bExaa7lytQMXs925vqlQVXzNMO.R 5WL2WCTSb6MemRndyRBryLx6Vft7sntSQQQnMXqsxnGpTV4rEkzu_IjTxNAz nn8w4IoNR5g72HpyMCx_S4EuU4ndgHpOnLkN86xEC3jdQzVH9sPPxCGe_6ls kDo3cvv5CpTvnHbxSkYzFNB6EhrhngHJbBmuiaUXm4m7GAKD8IwNBzOCz4tm 5Obh9a.KWZQDyoLtmNS.KFZ1kBzZz5WeNXw0nrhrreuMh5maCrij0ko8NT4H .9udHTh0x7zcGOGJa3V_VOS.FCUlS5hdPxUe6sIWrwB8X6Hd2NZduQCNvmBv FzV7OVLhSIs2udCDA1K7u5K7Tvjef40jnHhAk474lt4JdPrWsYD1ZcZQ9zm. Sdn14NP5c1Dnigyuj3WF4gwYGcIsrrxodgUVv36Hv69bZsH4PjpxwiqzN2fl 9LJC9zQDvtxHxizXJHdtuxYkQTfnukfyccBYNx2NT6Hab_ff4m.RUxnL4BcP vsapug2UJgujUsad9TXlvUJG1XqN5AwK.lpo_Pw-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 9AA011C6066; Thu, 30 Jul 2015 20:05:29 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 30 Jul 2015 20:05:29 -0400 From: David Mandelberg To: In-Reply-To: <55B97546.3060200@bbn.com> References: <20150709134637.7120.70507.idtracker@ietfa.amsl.com> <55A5E727.7020605@bbn.com> <55B97546.3060200@bbn.com> Message-ID: <6330ac92bedc4de98ff02530d9750918@mail.mandelberg.org> X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 Archived-At: Cc: ietf@ietf.org Subject: Re: [sidr] Last Call: (Resource Public Key Infrastructure (RPKI) Trust Anchor Locator) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 00:05:32 -0000 On 2015-07-29 20:52, Richard Hansen wrote: > I misread the MIME RFC; it requires line breaks every 76 characters, > not > every 75. So I think 76 is a better choice. For what it's worth, here are line lengths from an assortment of TALs I had lying around. afrinic.tal: 64 apnic-rpki-root-afrinic-origin.tal: 64 apnic-rpki-root-arin-origin.tal: 64 apnic-rpki-root-iana-origin.tal: 64 apnic-rpki-root-lacnic-origin.tal: 64 apnic-rpki-root-ripe-origin.tal: 64 arin.tal: 80 lacnic.tal: 64 ripe-ncc-root.tal: 55 ripe-pilot.tal: 78 Of these, one production TAL (arin.tal) and one non-production TAL (ripe-pilot.tal) are longer than 76. However, TALs are generally only used locally, and re-wrapping text is rather easy. So I don't think the existing TALs should have too large of an impact on whatever decision we make. -- David Eric Mandelberg / dseomn http://david.mandelberg.org/