From nobody Wed Nov 5 14:05:37 2014 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 E48ED1ACE6F for ; Wed, 5 Nov 2014 14:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 rUoK8qpDn4gk for ; Wed, 5 Nov 2014 14:05:31 -0800 (PST) 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 D0D4E1ACE64 for ; Wed, 5 Nov 2014 14:05:30 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 32CBD28B003D for ; Wed, 5 Nov 2014 17:05:30 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 29F101F8035; Wed, 5 Nov 2014 17:05:30 -0500 (EST) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_D39BC231-20B8-44C1-B038-A0316A892C0E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Wed, 5 Nov 2014 17:05:27 -0500 References: <8E99802C-D851-4396-9AF2-432C12F050F4@tislabs.com> To: sidr wg list X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/NeVef51VL0T-JFkr2WRFFCbYSUM Cc: Sandra Murphy Subject: [sidr] Fwd: minutes and updated slides 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, 05 Nov 2014 22:05:35 -0000 --Apple-Mail=_D39BC231-20B8-44C1-B038-A0316A892C0E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Looks like auto-complete in the recipient list meant that my message = below went only to the sidr secretary. Sorry about that. --Sandy Begin forwarded message: > From: Sandra Murphy > Subject: minutes and updated slides uploaded > Date: November 4, 2014 9:00:48 PM EST > To: SIDR Secretary , "idr@ietf.org wg" = > Cc: Sandra Murphy >=20 > I uploaded minutes, with thanks to Sue Hares for taking the minutes. >=20 > I made a few name spelling corrections. I added a comment where Sue = had recorded something I said that I did not recognize. Anyone else who = remembers that part of the conversation can clarify. >=20 > There was one participant who introduced himself as Chris from = Australia. Neither Sue nor I were certain of Chris's last name. If = anyone knows who that might have been (I thought the last name might = have been Weiren), could you please let the chairs know? >=20 > I made a few changes to the slides as noted in the meeting. I changed = "Ie" to "I.e.," on slide 11 to help those who thought it read "le", as = in "less than". I added the router keying draft to the list of = documents, noted as missing during the meeting. I deleted two spare = slides at the end - more colorful versions of previous slides. >=20 > The minutes are copied below. >=20 > If anyone has any comments or corrections, please do send them to the = list. >=20 > --Sandy >=20 >=20 >=20 > Attendees >=20 > =B7 Susan Hares > =B7 John Scudder > =B7 Chris Morrow > =B7 Sandy Murphy > =B7 Chris from Australia, last name possibly =93Weiren=94 > =B7 William (Bill) Attwood > =B7 Mike Baer > =B7 Jeff Haas > =B7 Jay Borkenhagen > =B7 Alia Atlas > =B7 Doug Montgomery > =B7 Kotikalapudi Sriram > =B7 Oliver Borchert > =B7 Hyojeong Kim (RSVP'd but not certain was in attendance) > =B7 Kambiz Agahian >=20 > SIDR Meeting >=20 > 10:05 Recording attempted but failed. >=20 > Meeting intended to provide a little bit of background for the IDR = folks who will be asked to comment on the SIDR draft. This background = provides the necessary information for IDR participants to review the = BGPSEC work. >=20 > Slide presentation >=20 > Questions after slide 10: >=20 > =B7 John: How large will these signatures be? > =B7 Sandy: One of the drafts (algorithms), these certificates use = ECDSA.=20 > =B7 Doug: We could send a note regarding how the BGPSEC impacts = the normal common RIB. Size of signatures and how this could related to = common RIBs > =B7 John: I=92m asking how many bytes per ARC > =B7 Sriram: 64 bytes (P256 curve) per AS > =B7 John: This is contrasted to 4 per AS. >=20 > Slide 11: >=20 > =B7 Sandy: We have done away with the AS Paths, and it is encoded = in the BGPSEC Attributes. Including the AS Path might confuse. We did = not tunnel the ASPath information as the 4 Byte AS does. There is an = algorithm to extract the valid ASPath from the BGP Sec AS Path. An = implementation can remove it from the BGP SecPath attribute upon = reception. At the boundaries, you must strip the BGPSEC Attributes. >=20 >=20 >=20 >=20 >=20 > Slide 12: >=20 > =B7 [Chris W(?)]: Can you tell me how this will impact on global = routing system on carrying the signatures? =20 > =B7 [Sandy]: Rephrasing the question if you send one NLRI per = update, how does this expand the space requirement? Secondly, how much = does the signature add per ASpath.=20 > =B7 Doug M: The RIB modeling dealt with the signature size = issues. We=92ve presented these details at a SIDR meeting. =20 > =B7 Sriram: We also looked at how many more updates how many more = updates will you have. When we examined this 4 years ago, there were an = average 3.8 NLRI per attribute path. Therefore you will grow by 4 times. > =B7 Jeff: In the grand scheme of input, I agree that the data = flow of will grow by 4 times per update. However, the major costs will = be processing time and internal space sharing due to the lack of caching = of the ASPath related attributes. > =B7 Sandy: Can you tell us why it is impossible to share the AS = Path. > =B7 Jeff: Most attributes tend to share objects as shared objects = (AS, next-hop, etc). The problem is that the AS-Path will not be able = to be shared. > =B7 Sandy: I see that the signature is not sharable. > =B7 Jeff: In implementation, these tend to be grouped together. > =B7 Doug: If you are caching at the attribute level. Then the = path-attribute would be unique for each attribute that is signed. > =B7 Sandy: I do understand that the signatures are unique. If = your code is caching attributes, this should not prevent as_path = sharing? > =B7 Jeff: You need to store the signature as an attribute of the = path attributes. > =B7 Sandy: It should not hamper > =B7 Jeff: Implementations may need to change our cache. The = processing of the AS path is big part of the caching methodology. = Therefore the caching will be higher than you consider in your estimates = of per route estimates. > =B7 Sandy: Should we consider this input? > =B7 Jeff: The point is that this will impact the routes > =B7 John: People should think about what this means for their = attribute list. >=20 > Second question stream: >=20 > =B7 Sandy; Does this impact the route server functions? > =B7 John: There are two document: Route serve ops draft is a = grow draft =96 it is in or past IETF LC. The Route Server is an IDR = draft, and it is not yet ready for WG LC. > =B7 Sandy: I was not certain if the route-server changes were = in-spec or out-spec for BGP of the information. > A Router-server operates as a collection point for routes at an = exchange point (IXP) from all peers. The route-server removes its own = AS, and the path length does not change. > =B7 John: For BGPSec, the route server is visible as regarding = signatures, but invisible regarding the path length. > =B7 Sandy: The route server sends ASPATH with a key encrypted. = (=46rom Sandy: I am not sure what I said here. The route server sends a = BGPSEC attribute with itself included, but is flagged as a route server, = so the ASPATH path length does not increase and the route server AS = would not appear in the extracted ASPATH) > =B7 John: People who care about Route Server scalability should = review previous slides. >=20 > Slide 13: No additional questions >=20 > Slide 14: 4 byte AS numbers are assumed. >=20 > Slide 18: >=20 > =B7 Kambiz: Will BGPSEC change the decision process? > =B7 Sandy: The results of the BGPSEC process will be available = for the decision process. The BGPSEC process will mark whether this is = valid or not. This is then left to the BGP decision process. These are = similar to the BGP-origin state. One example one operator adds +100 = from preferences valid and subtracts 50 for the invalid state. There = has been discussion that under a heavy load you send all routes. > =B7 Kambiz: Can this be done on a private AS.? > =B7 Sandy: RPKI is for global and public resources. The = certificates are all related via the trust hierarchy. You can set-up a = local RPKI to handle local address space (E.g. RFC1918 space) and then = use BGPSEC path attributes.=20 > =B7 Sriram: We do have fairly detailed RIB-size modeling slide = for normal routers and route-reflectors (Quebec Meeting). > =B7 Sandy: I think that your route-reflector mode would be = similar to route-servers. > =B7 John: Sriram did you have the same information for CPU load =96= Would you include that? > =B7 Sriram: yes we do. We assumed general purpose processor = (Sandy bridge, KVM process) on how the BGPSEC mode. > =B7 Sandy: Can you bring this up in the joint meeting. > =B7 Jay Borkenhagen: on slide 18, partial deployment two = clouds of BGPSEC do not know of each other. What happens if AS456 is = partially deployed? I think that the only thing that matters is that = there is a pathway through AS456 can be connected. > =B7 Sandy: This is an interesting point. I do not know how = operators will deploy BGPSEC. Do you think it will cause a problem? > =B7 Jeff: This feature will be partial islands of secured = information. You will have an AS will be half secure and half secure. = It is likely that the security aspects of the BGP information will = impact deployment. This may increase tunneling between ISPS. This may = impact forwarding. > =B7 Sandy: This forwarding can be done via tunnels or careful = next-hop handling. > =B7 Sandy: I=92m not sure what happens when one routing policy is = not contiguous through an AS.=20 > =B7 Chris: Some of this operations process and some of this is = implementation specific. comments. >=20 >=20 >=20 > Final comments: John: We have an open agenda for BGPSEC. Please send = in agenda suggestions to both the IDR and the SIDR chairs. >=20 > Meeting ended at 11:25 am. >=20 --Apple-Mail=_D39BC231-20B8-44C1-B038-A0316A892C0E 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 iQIcBAEBCgAGBQJUWp8nAAoJEHplpQeet0IZg7YP/jMOaU5YqxgEjDA+QbSXnu/t L2eyXitpUZv256ZTA6y63oB7+rXGLsGZO2q3SbS6sDyfafLu0cISL9J28r5W1ZZr 3rGPyqNy5uB054jC83nnF9XQCHrRlQOY3/mkJpDf0YOJHUiljJvYC+FT5bz60EEg RJv3EZScK4KPLAnRJQA5WllsNtYqp9xS8OrwrozPsD7ONYHSgmkivPhhBJwmhn16 0wEDha61OvwNfbS0zJKN0fhiekM5eKBedqEmxq6ao76lPkphl9u4rBG1sNnCbOh1 +eW33j/DIISF/eX7ad2PKiqCVFXXPuUjsHEc92AeeilRKqUkf6GFWX9RkaQlvSav SREWRIdZWQ4Lk4jnqHMBbjzQH5AlC6uo+FvxcSljBIZ60GgRKZxkrMru6QqCU4Na VKjCR4099DP6Cv1L6FXxI7IDAhhhWPX8zlfOpSJN5dCHRpD7ajNFSPB+lHXs/AKK L8NUXUKacxZ4OXuo2JNZmlPrQk5FiG3Myw1w54BLb46RlKHM52Ktz3IW3fsIKi2F Ma3Uwmr1TxYs9uLczFzfwpZs+wa8FF22aQ5LxRGcheX0TuVYK6wJOrnDYj1ibvxe E9AZzyotUd/778vHk8lOPESEI+/Jf00V9Sbq942sz31wlAJO/aBIQkYLsvSJDfYs 47zwmDOvaDYy7MLrUJZt =KclV -----END PGP SIGNATURE----- --Apple-Mail=_D39BC231-20B8-44C1-B038-A0316A892C0E-- From nobody Wed Nov 5 14:07:07 2014 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 626B21ACE4D for ; Wed, 5 Nov 2014 14:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] 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 qCe-FQGNFaFQ for ; Wed, 5 Nov 2014 14:07:03 -0800 (PST) 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 94AA91A000A for ; Wed, 5 Nov 2014 14:07:03 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id E608728B003D; Wed, 5 Nov 2014 17:07:02 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id E22A21F8035; Wed, 5 Nov 2014 17:07:02 -0500 (EST) From: Sandra Murphy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Nov 2014 17:07:01 -0500 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: http://mailarchive.ietf.org/arch/msg/sidr/U1Kdy4EHCsT0Z7nTegJL6u4gAAk Cc: Sandra Murphy Subject: [sidr] agenda revision and slide 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, 05 Nov 2014 22:07:04 -0000 The agenda was uploaded on the 3rd and revised on the 4th. As you can see, we have an uncharacteristically light agenda. The = presenters all have more time than they requested, so we might finish = uncharacteristically early. Our slot is first thing Monday morning. Those who are presenting slides = should get their slides to the chairs by Saturday midnight, Hawaii time. Standard reminder: please do number your slides. --Sandy, speaking as wg co-chair From nobody Wed Nov 5 14:12:04 2014 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 1C0F71ACE4A for ; Wed, 5 Nov 2014 14:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 AkynLJRT-Z3o for ; Wed, 5 Nov 2014 14:12:01 -0800 (PST) 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 A7C6F1A0011 for ; Wed, 5 Nov 2014 14:12:01 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id F313928B003D for ; Wed, 5 Nov 2014 17:12:00 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id D8B451F8035; Wed, 5 Nov 2014 17:12:00 -0500 (EST) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_EF3C2355-EF79-401B-B5AA-A6A28EEFDA85"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 5 Nov 2014 17:11:59 -0500 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: http://mailarchive.ietf.org/arch/msg/sidr/bPk2cNuw_osmVTLw2gfGoqr8wmA Cc: Sandra Murphy Subject: [sidr] minutes taker and jabber scribe 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, 05 Nov 2014 22:12:03 -0000 --Apple-Mail=_EF3C2355-EF79-401B-B5AA-A6A28EEFDA85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Given that almost everyone is traveling long distances to Hawaii and we = are first thing Mon morning, it would be an even better idea than usual = to have minutes takers and jabber scribes lined up ahead of time. If you are willing and able to volunteer for either function, please do = inform the list. Send a message to sidr-chairs@ietf.org. --Sandy --Apple-Mail=_EF3C2355-EF79-401B-B5AA-A6A28EEFDA85 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 iQIcBAEBCgAGBQJUWqCvAAoJEHplpQeet0IZ2FUQAJE5LZxT/XXrWxXI3STHBzRF +Dxge6W/mi99n3n7CemOAfkG4EbRK6WnrHrWscgrldefyrfrx8wpjREltA7h7uel rIPAwVhw133T8YaWqKeUN2twuhsLU/0CC/J80PqVXNd6YYB+YqdWEcOUBaL5xgsH dSeJXfHtu5skUS8eiHfuiKdRnZJT6F/5Ap/ei2ARoE8HCBfUJpHh4MskLdPraydY anngwXjDPWD0NbWPuwd9llo0kRB/7t6cKS/KdAp9OFdXRCACssOboWCOP2jWFyX5 GiTBzC05q1MYnGY65XCiieeKwRUGpiBjHjiR8you5Bj2ieeXckiyPWltHwpyydYn 3ARU8IX2tg1jIshRt4+LbMqGBGm0qrVVkiFfuCmQFyGV18UxTXyNuy7UQFoI1PUG HyMKG1Nvv/E6isoyXbx2ZiNFPxZJoOhAfKgBa228IG9FHedDbbf9/mx/al3W2rCm zN1cAOkVHuHggshC1x5kIhnCl+fI3WcMUqIiZDLwoId0GhI5oIuhkBRIiQHMr1rE CRkVknHLo1/SuT7LXXY1rnmqT12hxmiMoIJFb14NcYcF5JDK+8FH8t6B4c3C9PAy t2tMWYnEwyKes8O5iw9aH6L6hAFhWTgnFbpwa5Gi+MpVSO0+tD6GtsqS7mU8XrcM lI/DQ943mL8rnL0F4u9w =4gJ6 -----END PGP SIGNATURE----- --Apple-Mail=_EF3C2355-EF79-401B-B5AA-A6A28EEFDA85-- From nobody Wed Nov 5 14:12:57 2014 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 45D4D1ACE57 for ; Wed, 5 Nov 2014 14:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] 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 wPRRP2NFIRJU for ; Wed, 5 Nov 2014 14:12:54 -0800 (PST) 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 1A5A01ACE4A for ; Wed, 5 Nov 2014 14:12:54 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 72DAD28B003D; Wed, 5 Nov 2014 17:12:53 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 6DA741F8035; Wed, 5 Nov 2014 17:12:53 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: Date: Wed, 5 Nov 2014 17:12:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <52BB1E67-CB41-485A-9C57-5113F223814A@parsons.com> References: To: Sandra Murphy X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/xDTG7lMOXxh0bEaZ2oNRUgulGC4 Cc: sidr wg list Subject: Re: [sidr] agenda revision and slide 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, 05 Nov 2014 22:12:55 -0000 On Nov 5, 2014, at 5:07 PM, Sandra Murphy = wrote: > The agenda was uploaded on the 3rd and revised on the 4th. >=20 > As you can see, we have an uncharacteristically light agenda. The = presenters all have more time than they requested, so we might finish = uncharacteristically early. >=20 > Our slot is first thing Monday morning. Those who are presenting = slides should get their slides to the chairs by Saturday midnight, = Hawaii time. Send slides to sidr-chairs@ietf.org, please. That ensures it gets to = whomever is available. --Sandy, speaking as wg co-chair >=20 > Standard reminder: please do number your slides. >=20 > --Sandy, speaking as wg co-chair >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Nov 6 11:02:00 2014 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 3F62A1A8A48 for ; Thu, 6 Nov 2014 11:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.594, 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 Ow5c1kSZMxlz for ; Thu, 6 Nov 2014 11:01:54 -0800 (PST) Received: from mail.ops-netman.net (mailserver.ops-netman.net [208.76.12.119]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D581A88DF for ; Thu, 6 Nov 2014 11:01:52 -0800 (PST) Received: from donkey.her.corp.google.com (unknown [72.14.227.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 355D4880021; Thu, 6 Nov 2014 19:01:51 +0000 (UTC) Message-ID: <545BC59E.7020507@ops-netman.net> Date: Thu, 06 Nov 2014 14:01:50 -0500 From: Chris Morrow User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "sidr@ietf.org" , "sidr-chairs@tools.ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/PqiBCTiON7qG7lbfz5SQRupeqIY Subject: [sidr] A note prior to the meeting ... about behavior 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, 06 Nov 2014 19:01:59 -0000 Howdy folks! It occurs to me that we didn't say something clearly and (maybe) concisely after the last in-person meeting about expectations for working group person behavior... so, with that in mind please: 1) be courteous 2) do not make your argument about the other person or how you feel they may make their arguement or whatever other problems you may perceive with NOT their discussion point. 3) DO remember that we're all trying to solve the same problem (making the routing system more secure) 4) discussions that are off topic or not related to solving this problem are a distraction in what is often a very short timeframe, tightly scheduled meeting, so they are a waste of everyone's time. I'll say something like this at the start of the meeting time as well, for folk that don't read email as often as others... Thanks! -chris co-chair-roboton From nobody Mon Nov 10 10:49:53 2014 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 9E1051A1B35; Mon, 10 Nov 2014 10:49:50 -0800 (PST) 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 gGoWXdUPe8Bx; Mon, 10 Nov 2014 10:49:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2951A9110; Mon, 10 Nov 2014 10:49:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141110184948.5876.32141.idtracker@ietfa.amsl.com> Date: Mon, 10 Nov 2014 10:49:48 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/s23IP31rIivtfyiPvb_WYOGRKvc Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-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, 10 Nov 2014 18:49:50 -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 : A Profile for BGPSEC Router Certificates, Certificate Revocation Lists, and Certification Requests Authors : Mark Reynolds Sean Turner Steve Kent Filename : draft-ietf-sidr-bgpsec-pki-profiles-09.txt Pages : 13 Date : 2014-11-10 Abstract: This document defines a standard profile for X.509 certificates for the purposes of supporting validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPSEC. BGP is a critical component for the proper operation of the Internet as a whole. The BGPSEC protocol is under development as a component to address the requirement to provide security for the BGP protocol. The goal of BGPSEC is to design a protocol for full AS path validation based on the use of strong cryptographic primitives. The End-Entity (EE) certificates specified by this profile are issued under Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificates, containing the AS Identifier Delegation extension, to routers within the Autonomous System (AS). The certificate asserts that the router(s) holding the private key are authorized to send out secure route advertisements on behalf of the specified AS. This document also profiles the Certificate Revocation List (CRL), profiles the format of certification requests, and specifies Relying Party certificate path validation procedures. The document extends the RPKI; therefore, this documents updates the RPKI Resource Certificates Profile (RFC 6487). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-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 Nov 10 10:51:46 2014 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 DA6CF1A00FF for ; Mon, 10 Nov 2014 10:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 XqGegpm4XElI for ; Mon, 10 Nov 2014 10:51:43 -0800 (PST) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [67.18.10.5]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CAE01A008F for ; Mon, 10 Nov 2014 10:51:43 -0800 (PST) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 81E531A7DD78F; Mon, 10 Nov 2014 12:51:22 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway04.websitewelcome.com (Postfix) with ESMTP id 709471A7DD73E for ; Mon, 10 Nov 2014 12:51:22 -0600 (CST) Received: from [31.133.163.154] (port=64488 helo=dhcp-a39a.meeting.ietf.org) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xnu3d-0003nb-W9 for sidr@ietf.org; Mon, 10 Nov 2014 12:51:22 -0600 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: <20141110184948.5876.32141.idtracker@ietfa.amsl.com> Date: Mon, 10 Nov 2014 08:51:19 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <7B6EEE3D-C939-46E9-9B7B-3B7FA93993B7@ieca.com> References: <20141110184948.5876.32141.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.163.154 X-Exim-ID: 1Xnu3d-0003nb-W9 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-a39a.meeting.ietf.org) [31.133.163.154]:64488 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/kCouiL4bGk7pHu7bxWfm2kLdPJA Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-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, 10 Nov 2014 18:51:45 -0000 I went ahead and submitted the -09 version I referred to earlier: http://www.ietf.org/mail-archive/web/sidr/current/msg06825.html As far I know, there are no outstanding issues. spt On Nov 10, 2014, at 08:49, 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 : A Profile for BGPSEC Router Certificates, = Certificate Revocation Lists, and Certification Requests > Authors : Mark Reynolds > Sean Turner > Steve Kent > Filename : draft-ietf-sidr-bgpsec-pki-profiles-09.txt > Pages : 13 > Date : 2014-11-10 >=20 > Abstract: > This document defines a standard profile for X.509 certificates for > the purposes of supporting validation of Autonomous System (AS) = paths > in the Border Gateway Protocol (BGP), as part of an extension to = that > protocol known as BGPSEC. BGP is a critical component for the = proper > operation of the Internet as a whole. The BGPSEC protocol is under > development as a component to address the requirement to provide > security for the BGP protocol. The goal of BGPSEC is to design a > protocol for full AS path validation based on the use of strong > cryptographic primitives. The End-Entity (EE) certificates = specified > by this profile are issued under Resource Public Key Infrastructure > (RPKI) Certification Authority (CA) certificates, containing the AS > Identifier Delegation extension, to routers within the Autonomous > System (AS). The certificate asserts that the router(s) holding the > private key are authorized to send out secure route advertisements = on > behalf of the specified AS. This document also profiles the > Certificate Revocation List (CRL), profiles the format of > certification requests, and specifies Relying Party certificate path > validation procedures. The document extends the RPKI; therefore, > this documents updates the RPKI Resource Certificates Profile (RFC > 6487). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-09 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-pki-profiles-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 > _______________________________________________ > 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 Nov 10 12:17:55 2014 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 50F051ACDF3 for ; Mon, 10 Nov 2014 12:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 gU6LdYgZ00SD for ; Mon, 10 Nov 2014 12:17:46 -0800 (PST) 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 AB6DA1ACDEE for ; Mon, 10 Nov 2014 12:17:46 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 0D52828B0017 for ; Mon, 10 Nov 2014 15:17:46 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 7F0041F8035; Mon, 10 Nov 2014 15:17:45 -0500 (EST) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_1E693733-13C9-4830-9677-A834E9ABAB77"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Mon, 10 Nov 2014 15:17:44 -0500 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: http://mailarchive.ietf.org/arch/msg/sidr/HQ-J_zFVsBT3T-yTIsXK5qRLde8 Cc: Sandra Murphy Subject: [sidr] this is possibly Tim Bruijnzeels delta protocol 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, 10 Nov 2014 20:17:49 -0000 --Apple-Mail=_1E693733-13C9-4830-9677-A834E9ABAB77 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Took some searching but here is a recent submission with Tim's name on it. https://tools.ietf.org/html/draft-tbruijnzeels-sidr-delta-protocol-02 --Sandy --Apple-Mail=_1E693733-13C9-4830-9677-A834E9ABAB77 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 iQIcBAEBCgAGBQJUYR1pAAoJEHplpQeet0IZaGsQALtjsip4fM6jTpSaQP9KSOsl S+BwgM3eu9uhZtBhSpM4hNY5ei4+qvZi3zvSd6EwqIjt3TRxNDdDSa8Sp+xhOrhJ d/3cuhcIKAHIEt/SZ3i4/ZmGHdUhVfp7qcJeP/8zj74jpc7UaorLKdWD9cdOn6Wu w1+Xny37l7KVTUbWtSJkafIOUQ4Z8EhNnmyAyTpWrbez6UXXDc/d9dwg5D/3wjny WXEQMwOlSIFTC359XdzXthMrcVATgxt5HPsyOpdUi+r+6IG9oM+QVQu2mW2/F8ck Qo+zWd3m1LpGzdA/RjbSOYna82iXV9fNkumrE2TJazpBMBa2wN5e64tl3oA51qle jfB2o7rtIL5c/6H0D4ALLipqSzqQVtFqa3sGW7N6GjF1Ly74h4eKSZU0YpRP0UvU gAYyvEYN32NzR7hTvzSd0+VCdV+nuolcAxGY/p4ZKWHuCLS/53at+OYFYW2bgqvQ js6U3a/JV3cA/8eo/wucv88nN4VsJoqKELS8hMH9zQzsY6+LARcW4IptJxHbZTij z4UZ4BfWpNoE8A0LKduJthHZjIvdkjJhxaqbQ01+Jih6+MrPzsA2IPQE4SrcXfQk ryTF6g59sVp9p5lWD1RBqXrgRBOeeYkyRxARmSmMRMSabJJ2vacd91Zwv+PvUSdc 8H3G1ZWrU1cvMZEdSn1Y =sZ3I -----END PGP SIGNATURE----- --Apple-Mail=_1E693733-13C9-4830-9677-A834E9ABAB77-- From nobody Mon Nov 10 22:18:29 2014 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 43D6A1A6F6F for ; Mon, 10 Nov 2014 22:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] 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-icHkR8angX for ; Mon, 10 Nov 2014 22:18:23 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 749F41A1A19 for ; Mon, 10 Nov 2014 22:18:22 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1Xo4mB-00016R-Sl for sidr@ietf.org; Tue, 11 Nov 2014 08:18:03 +0200 From: Mark Tinka Organization: SEACOM To: sidr@ietf.org Date: Tue, 11 Nov 2014 08:17:29 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4137447.pjdGQooKGj"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201411110817.32233.mark.tinka@seacom.mu> Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/8ik56x0dUcXluDFYqcY64RB2xfA Subject: [sidr] Violation of RFC 6811 - Route Selection Algorithm Due To RPKI State X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 06:18:25 -0000 --nextPart4137447.pjdGQooKGj Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all. In operating RPKI on Cisco IOS and IOS XE devices, we note=20 that this vendor is deliberately making BGP best path=20 decisions based on RPKI state of a route without the=20 explicit input of operator-based routing policy. So in addition to the normal (i.e., historically known) BGP=20 best path decision process, the presence of an RTR session=20 causes this vendor to, by default, add RPKI state to the BGP=20 best path decision process when there does not exist a=20 routing policy initiated by the operator to do so. This is in violation of RFC 6811, Section 2, which clearly=20 states: "An implementation MUST NOT exclude a route from the Adj-RIB-In or from consideration in the decision process as a side effect of its validation state, unless explicitly configured to do so." Official documentation from the vendor confirms this default=20 behaviour as well: http://tinyurl.com/pqpjmen While the vendor provides knobs to disable this default=20 behaviour, operators could generally miss this information.=20 And given that there is no clear reason why a "normally"=20 best path would be rejected on grounds of RPKI state not=20 initiated by the operator, this is a hard problem to=20 troubleshoot, even with prior (working) knowledge of RPKI. Cheers, Mark. --nextPart4137447.pjdGQooKGj Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJUYan8AAoJEGcZuYTeKm+GpmYP/A5jj5oz3I8pXGaBNaPixc4D 9i65OP6sh4ixfA0GugMt4JzTXv0SghPt2+L0cSN6lNaIW9jqHBOVA27CfQTgDQrI tTA2kWKDRThfHb0IK3HQC/IxRpWazmUBx/eola3Ye4ob2taXFg3LPExe802i9UYO LswicCtLI1qhPdA4p13n3Sq7awoJyS1LvlAMhgBZPkiVWnqKsGqRNK79DbGr0N1n U2wg/FDlREQu8KDRStLGCMRfIOaPb0r3J022I68Mfq/mHx2lX/10CnrT5yGxg7bI 2D2Dmkyr8jnjAIHC0aFc+jjIB56X+8JQVSVNPhlDAk9HKpJgc7OFBEqpG79+nBCp Y2j44J4V9QF+1BhQYcoXdr7XXCqrfPX/StD9QGrJesha1yhyldUgpQjO4JUcvzDM c1dG3SCOG1EOcOjAbEVnofKk7POYPXsdvI5Bp2dYAcU4LVkv9p3ROt39+YaiigM/ jJlYMZ6oJ9YUlkwqbGFE0Tij+w/KBDOyqOtl2dDwFfJtoUhZvzmR4N6XFwJeILm5 0boBPLntWJAhTeBWNnxUWmXZWAsU9238woQAHLJjZBu/d9zFYpLBb4+dT3SDRfQw AMP8ihyxLcDLtOry130O6qeEIacP4L/4rRH75boO9JlIhQ/xalk/2LzcX2WKSbes SIhWjwp6aNDnCFIE8INA =49dA -----END PGP SIGNATURE----- --nextPart4137447.pjdGQooKGj-- From nobody Mon Nov 10 23:39:13 2014 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 6CD541ACE95 for ; Mon, 10 Nov 2014 23:39:10 -0800 (PST) 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 DtoiFZBCc-bA for ; Mon, 10 Nov 2014 23:39:05 -0800 (PST) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 214E01A87D9 for ; Mon, 10 Nov 2014 23:39:05 -0800 (PST) Received: by mail-yh0-f43.google.com with SMTP id a41so3156464yho.16 for ; Mon, 10 Nov 2014 23:39:04 -0800 (PST) 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=FIV0aXYYop8pm0zxe4iSAi24vB3HIiVF/r6bENj2ego=; b=bFJFUgGWKm25xTnb8iB2Fzy/xWnRTRudUdMvQTBhZC1nouPQZ44hpT0cDefQMmtsF1 m7/JDnGg5GqRL0uCK69RhynZHbiTjduqHrHsaW/gv536g4xwQ6iEYsk8LvxjOj12pq73 Ht/yoVJvBIhTMrQ1oUFeNjJfN5+28lQcl+MgFSU41wnGE3siFtSBoZOm3B+lfp4k1i33 ppM2uuRWmJDpx3sCxB6rS23y62YQXpzv03NJpV9Ln1aMP9mkCA5BpdBEMsslfrdrmb5e uomgapFd/xm5t4mC3sF9BMoYmhcVLDZ/57s6S15JBCKf7HIyFKLmr/i6qBfLUetl+k6n FctA== MIME-Version: 1.0 X-Received: by 10.52.37.138 with SMTP id y10mr21399686vdj.11.1415691544418; Mon, 10 Nov 2014 23:39:04 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.221.44.8 with HTTP; Mon, 10 Nov 2014 23:39:04 -0800 (PST) In-Reply-To: <201411110817.32233.mark.tinka@seacom.mu> References: <201411110817.32233.mark.tinka@seacom.mu> Date: Tue, 11 Nov 2014 02:39:04 -0500 X-Google-Sender-Auth: m3OnbgKVnyljbhiij44Cicxwod8 Message-ID: From: Christopher Morrow To: mark.tinka@seacom.mu Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/l4BFqWmAz3VskOpI6Dw-lssKe04 Cc: "sidr@ietf.org" Subject: Re: [sidr] Violation of RFC 6811 - Route Selection Algorithm Due To RPKI State 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, 11 Nov 2014 07:39:11 -0000 On Tue, Nov 11, 2014 at 1:17 AM, Mark Tinka wrote: > Hello all. > > In operating RPKI on Cisco IOS and IOS XE devices, we note > that this vendor is deliberately making BGP best path > decisions based on RPKI state of a route without the > explicit input of operator-based routing policy. ro-ro-shaggy... that seems like a poor plan. > > So in addition to the normal (i.e., historically known) BGP > best path decision process, the presence of an RTR session > causes this vendor to, by default, add RPKI state to the BGP > best path decision process when there does not exist a > routing policy initiated by the operator to do so. oh.. that's super not cool. > > This is in violation of RFC 6811, Section 2, which clearly > states: > > "An implementation MUST NOT exclude a route from the > Adj-RIB-In or from consideration in the decision > process as a side effect of its validation state, > unless explicitly configured to do so." > > Official documentation from the vendor confirms this default > behaviour as well: > > http://tinyurl.com/pqpjmen > > While the vendor provides knobs to disable this default > behaviour, operators could generally miss this information. > And given that there is no clear reason why a "normally" > best path would be rejected on grounds of RPKI state not > initiated by the operator, this is a hard problem to > troubleshoot, even with prior (working) knowledge of RPKI. > sorry :( > Cheers, > > Mark. > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From nobody Tue Nov 11 16:50:15 2014 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 32EE81A870D for ; Tue, 11 Nov 2014 16:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.594, 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 SR5RIz4HfDUk for ; Tue, 11 Nov 2014 16:50:10 -0800 (PST) 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 66BCF1A872A for ; Tue, 11 Nov 2014 16:50:10 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id AA88228B0017 for ; Tue, 11 Nov 2014 19:50:09 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 3968C1F8035; Tue, 11 Nov 2014 19:50:09 -0500 (EST) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_054B7601-714B-4482-9C2B-ECDB8989017A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Tue, 11 Nov 2014 19:50:08 -0500 Message-Id: <19BF2229-3179-443D-A044-1C400FC711E3@tislabs.com> To: sidr wg list Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/pcDgExCJScYfiNBNyZqfFY0UYlc Cc: Sandra Murphy Subject: [sidr] Wes George on RPKI at NANOG 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, 12 Nov 2014 00:50:13 -0000 --Apple-Mail=_054B7601-714B-4482-9C2B-ECDB8989017A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Speaking as regular ol' member Wes mentioned yesterday that the proposed new transport protocol for = RPKI (replacement for rsync) overcame one of his concerns about RPKI = deployment. He made several points in a presentation at NANOG: slides: = https://www.nanog.org/sites/default/files/wednesday_george_adventuresinrpk= i_62.9.pdf video (captures interaction) = https://www.nanog.org/sites/default/files/08-oct-2014-webcast-adventures-i= n-rpki-non-deployment.mp4 even YouTube http://www.youtube.com/watch?v=3DuGSo4uiYyAc These might be useful for the working group to consider. --Sandy, speaking as regular ol' member --Apple-Mail=_054B7601-714B-4482-9C2B-ECDB8989017A 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 iQIcBAEBCgAGBQJUYq7AAAoJEHplpQeet0IZbrcP/j8lWwIZ+d2HKqrU6Bx4iutR 3fGGFS5dxRNhOGAB7n1TLT3j/v/LgtH5eEB5sp2ZIBjSYHJmDSO6lhTN7VcfAE2J ERtNNvf1uOm8M1uZ/NIbWe/eA7d19OOTpf5NxS2WOOYA7kVl7v3amIqbPmtHZA5R mKBHKILeeigmRtkp/YlG2VVwzzhuxW5p5L9JrSCI/X1cMwBR4TUV1aJL6jjPcHEQ ka5ZwI8Uhc/Bya0a4+eVpFmVXPoEEUNpvZmfxbsh2C+yYDaNTzvX+dXu9zqtQqVO LD/wmLvuim3dYoK6gkS4eqywWQ4xy9dit7nhLQ/6yufM4eXquQ1X9HtnBepsTGfs 1Nt0qBdnFaYm0f00lat9uVNuTa51iAnG8W1aFHrpoKrtkPDFdDbenhkoCJ8Cy+kP 6627gTVdzrwCZ4Hcq46wa2zsCInV0v2/sKs3FgCuSOwHyaNrsmnfrc7R/6O9ktyP FsB5N5ek90qjrFfyEVHnpDk0KTEARzuihY5Buhy6HK3WG9T6ohexRxy2/tU7LiMy 3UbVmLaAJ9XZ+TWvSbVDPm6FBniCKJKCuzpjg3PWX9i2a9UIwC2fIkZjnLF30XGl PbKfowsVHTlqdr9AlrgYYaDvdY15TD2s9p7k/12TFbkQYELbiZHWXa6IifAc8hd5 JUZqJ0VQjusD7B/DV3bS =A2/v -----END PGP SIGNATURE----- --Apple-Mail=_054B7601-714B-4482-9C2B-ECDB8989017A-- From nobody Wed Nov 12 13:57:07 2014 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 5BCC11ACDFC for ; Wed, 12 Nov 2014 13:57:05 -0800 (PST) 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, SPF_HELO_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 FHEQF9p0Fti1 for ; Wed, 12 Nov 2014 13:57:03 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0791.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:791]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37CD81ACD1A for ; Wed, 12 Nov 2014 13:57:03 -0800 (PST) Received: from DM2PR09MB0302.namprd09.prod.outlook.com (25.160.96.147) by DM2PR09MB0303.namprd09.prod.outlook.com (25.160.96.148) with Microsoft SMTP Server (TLS) id 15.1.16.15; Wed, 12 Nov 2014 21:56:40 +0000 Received: from DM2PR09MB0302.namprd09.prod.outlook.com ([25.160.96.147]) by DM2PR09MB0302.namprd09.prod.outlook.com ([25.160.96.147]) with mapi id 15.01.0016.006; Wed, 12 Nov 2014 21:56:40 +0000 From: "Sriram, Kotikalapudi" To: Matthew Lepinski , "sidr@ietf.org" Thread-Topic: [sidr] New version : draft-ietf-sidr-bgpsec-protocol-10 Thread-Index: AQHP8j+r4RQrcXpUDk2b8sNIFeC7Vpxdl187 Date: Wed, 12 Nov 2014 21:56:40 +0000 Message-ID: <1415829399189.10953@nist.gov> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.219.85] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0303; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0303; x-forefront-prvs: 03932714EB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(69224002)(199003)(189002)(105586002)(99286002)(20776003)(36756003)(40100003)(64706001)(95666004)(31966008)(66066001)(230783001)(122556002)(99396003)(117636001)(46102003)(120916001)(97736003)(107046002)(50986999)(76176999)(54356999)(107886001)(77156002)(2656002)(62966003)(101416001)(92566001)(87936001)(77096003)(86362001)(92726001)(4396001)(106356001)(2501002)(21056001)(106116001)(509002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0303; H:DM2PR09MB0302.namprd09.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/SI2DQv_mFxMpQyi9LJ5GonOhHZw Subject: Re: [sidr] New version : draft-ietf-sidr-bgpsec-protocol-10 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, 12 Nov 2014 21:57:05 -0000 Matt,=0A= =0A= Thanks for all your efforts and time in keeping this I-D updated.=0A= Some technical and some editorial comments on the new version 10 follow.=0A= =0A= Technical comments:=0A= =0A= 1. At the top of sec. 5.1, say something like =96 =0A= Here we focus only on validation of BGPSEC_Path or Secure_Path attribute. = =0A= And refer to RFC 6811 for the recommended origin validation algorithm. =0A= =0A= 2. In sec. 5.1 and 5.2, wherever there is mention of validation of *BGPSEC = update message*, =0A= it should be replaced by =93validation of BGPSEC_Path (or Secure_Path or Si= gnature_Block).=0A= =0A= 3. In sec. 7 (Security Considerations), the vulnerability to replay attacks= is currently =0A= not mentioned? Should it be mentioned?=0A= =0A= Editorial comments:=0A= =0A= 1. Some references to Internet Drafts have old dates (not showing the actua= l updated dates).=0A= =0A= 2. Perhaps RFC 6811 should be a normative reference.=0A= =0A= 3. p. 5, 1st para: =0A= =0A= =93A BGP speaker SHOULD=0A= NOT advertise the capability of BGPSEC support for a particular AFI=0A= unless it has also advertised the multiprotocol extension capability=0A= for the same AFI combination [3].=94=0A= =0A= s/ a particular AFI/ a particular set of AFIs/=0A= =0A= 4. p. 7, para 1: s/in the same way/ in a similar way/=0A= =0A= 5. The following sentence is repeated on pages 6 and 7:=0A= =0A= =93A BGPSEC update message=0A= containing the BGPSEC_Path attribute MUST NOT contain the AS_PATH attrib= ute.=94=0A= =0A= 6. p. 7, para 2: s/for one AS number/for each AS number/=0A= =0A= 7. p. 7, para 2: s/secure path segment/ Secure_Path segment/=0A= =0A= 8. p. 8, para 4: =0A= =0A= =93(The pCount field is also=0A= useful in managing AS Number migrations, see [18] for details.)=94=0A= Could be replaced with:=0A= (The pCount field is also=0A= useful in managing route servers (see Section 4.2) and AS Number migrati= ons, see [18] for details.)=0A= =0A= 9. p. 10, para 2:=0A= =0A= =93When originating a new route=0A= advertisement and sending it to an internal peer, the BGPSEC speaker=0A= creates a new BGPSEC_Path attribute with zero Secure_Path segments=0A= and zero Signature Segments.=94=0A= =0A= This sentence is a bit verbose. There is no BGPSEC_Path attribute if it has= zero =0A= Secure_Path segments and zero Signature Segments.=0A= =0A= So why not reword it simply as:=0A= =93When originating a new route=0A= advertisement and sending it to an internal peer, the BGPSEC speaker=0A= sends only the NLRI (to an iBGP peer).=94=0A= =0A= 10. The last paragraph on p.11 and the top two paragraphs on p.12 can be mo= ved to the preamble of =0A= Section 4 (to a spot just before start of Sec. 4.1). =0A= This is because these three paragraphs are generally applicable to both Sec= tions 4.1 and 4.2.=0A= =0A= 11. p.13, 2nd last para: s/ to the RPKI router corresponding to the=0A= BGPSEC speaker / to the RPKI router *certificate* corresponding to the= =0A= BGPSEC speaker/=0A= =0A= 12. p.16, para 2: s/ in the Subject Key Identifier extension of=0A= the RPKI router corresponding to / in the Subject Key Identifier extensi= on of=0A= the RPKI router *certificate* corresponding to/=0A= =0A= 13. p.17, last para: s/ the most recently added Secure_Path *segments*/ the= most recently =0A= added Secure_Path *segment*/ (make =93segments=94 singular)=0A= =0A= 14. p 18, para 3: s/ for a signature=0A= produced by a BGPSEC speaker outside of a confederation/ for a signature= =0A= produced by a *peer* BGPSEC speaker outside of a confederation/=0A= =0A= 15. In Sections 5.1 and 5.2, search =93update message=94 and see if it shou= ld be replaced by =0A= =93BGPSEC_Path attribute=94 or Secure_Path=94 or =93Signature_Block=94 =0A= as the case may be. (In the context of validation)=0A= =0A= 16. p.28, 3 rd last para: s/ A BGPSEC speaker/ a BGPSEC speaker/ (should b= e lower case A)=0A= =0A= Sriram= From nobody Wed Nov 12 17:10:50 2014 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 6C1971A00AD for ; Wed, 12 Nov 2014 17:10:47 -0800 (PST) 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 e0OQdz2LgNLG for ; Wed, 12 Nov 2014 17:10:43 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B44C41A0089 for ; Wed, 12 Nov 2014 17:10:42 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id n3so402515wiv.2 for ; Wed, 12 Nov 2014 17:10:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=DzD9O1uBqcqnCVq1nyUe0guwdIkyb/kuCo0iOIgIxZM=; b=KWl151rpGJJ7xwll6zAMVFjX5kzKQKDLsVD5xxbyVm5Fe0r80+o39ZbSyvaUA6t2SU C6HmkUvJQOtWZV43rwxOThwEi54hIsnbJnVUX+XB1aOZtGSErf00CvN4QzPmCCy+MYf4 sDk0j7coyBHQGjApOKJepwpi45sGySWl0bfCwAdjoBffDDHxG6MWROkA2u6ZWQSPHHo0 f6fJbNnISvXtxfWV4ciiqhGnuT3HMnl74WUNYhZc0lQYt3cWxoQ0cfYvv+jULXznkX7E DNPpU1z9BcJXvF0ZWGtfCE2sNNn3aGQ3QGtzWtPOXkmAyVeUelkDfarjqU/MAGz5cSIw iamw== X-Received: by 10.180.12.136 with SMTP id y8mr55199441wib.73.1415841041578; Wed, 12 Nov 2014 17:10:41 -0800 (PST) Received: from [192.168.0.229] (93-36-32-49.ip58.fastwebnet.it. [93.36.32.49]) by mx.google.com with ESMTPSA id el6sm12252330wib.23.2014.11.12.17.10.39 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Nov 2014 17:10:40 -0800 (PST) Message-ID: <5464050E.6070009@gmail.com> Date: Thu, 13 Nov 2014 02:10:38 +0100 From: Daniele Iamartino User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: sidr wg list Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/EIb4ozHeSKvrzBSKaYHBm71SI3E Subject: [sidr] Securing DNS root servers prefixes 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, 13 Nov 2014 01:10:47 -0000 Hello, Since DNS root servers are a critical service, I've been checking if their prefixes could be origin-validated on BGP using RPKI. It would be good if we could secure them. So I've built this website monitoring the status of DNS root servers prefixes once a day: http://rpki.me/dns.html (So far I'm using LINX route-views monitor and RIR's RPKI repo + CA0 repo) RIPE NCC already told me that they will secure the v4 address of K-root very soon. I also wrote to several other root server operators, but I'm still waiting an answer. Some prefixes are in v4 legacy address space (not administered by ARIN: with RegDate < 22 Dec 1997). I suppose that this might be a problem in order to obtain certificates covering them from ARIN. Regards -- Daniele Iamartino Computer engineering student at Politecnico di Milano, Italy From nobody Thu Nov 13 09:32:15 2014 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 431751A8F45 for ; Thu, 13 Nov 2014 09:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 51y_geLjkCix for ; Thu, 13 Nov 2014 09:32:13 -0800 (PST) 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 48A6B1A8F34 for ; Thu, 13 Nov 2014 09:32:13 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1XoyFg-0002sJ-1Z; Thu, 13 Nov 2014 17:32:12 +0000 Date: Thu, 13 Nov 2014 07:32:11 -1000 Message-ID: From: Randy Bush To: Daniele Iamartino In-Reply-To: <5464050E.6070009@gmail.com> References: <5464050E.6070009@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: http://mailarchive.ietf.org/arch/msg/sidr/DChS1DG7bwQ0CKwa9yQRMl-9yNo Cc: sidr wg list Subject: Re: [sidr] Securing DNS root servers prefixes 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, 13 Nov 2014 17:32:14 -0000 > Some prefixes are in v4 legacy address space (not administered by > ARIN: with RegDate < 22 Dec 1997). I suppose that this might be a > problem in order to obtain certificates covering them from ARIN. altCA == ca0 From nobody Thu Nov 13 11:18:41 2014 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 C709E1ACD2A for ; Thu, 13 Nov 2014 11:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 i81PL6rvngMn for ; Thu, 13 Nov 2014 11:18:33 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB5A1ACD25 for ; Thu, 13 Nov 2014 11:09:43 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 13 Nov 2014 11:09:42 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Thu, 13 Nov 2014 11:09:42 -0800 From: Terry Manderson To: Daniele Iamartino , sidr wg list Thread-Topic: [sidr] Securing DNS root servers prefixes Thread-Index: AQHP/t62C/0+0bGIJk+eKQLzzjpBkpxgGsCA Date: Thu, 13 Nov 2014 19:09:41 +0000 Message-ID: References: <5464050E.6070009@gmail.com> In-Reply-To: <5464050E.6070009@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [31.133.143.37] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3498786579_11936243" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/QaxBmqb469yC7JIl8xFC6WrjaK4 Subject: Re: [sidr] Securing DNS root servers prefixes 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, 13 Nov 2014 19:18:38 -0000 --B_3498786579_11936243 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Daniele, Speaking for L-root. We have made the decision to be conservative in adopting new protocols so that when we do adopt a new technology it is done with full awareness of the implications to the global internet for an important service like root zone resolution. That measured and conservative approach is expected of L-root, and I certainly intend to live up to that. At this point in time, my assessment of RPKI is such that much work is still to be done before I feel I can judge it as complete and robust. for example: - the position on validation is in flux - an entirely new mechanism for object retrieval from publication points is being developed - there remains no strong mechanism for key roll (like rfc5011) - the IAB's single trust anchor is yet to materialise - resiliency in the RPKI systems is yet to be proven (at least to me) - legal teams are still vacillating on the implications of RPKI use I do appreciate your enthusiasm, and I encourage you to keep your page active. I also encourage you to share all of your experiences of RPKI (good/bad/otherwise) here so that this working group can collectively review the ongoing deployment. Cheers Terry On 13/11/2014 11:10 am, "Daniele Iamartino" wrote: >Hello, > >Since DNS root servers are a critical service, I've been checking if >their prefixes could be origin-validated on BGP using RPKI. >It would be good if we could secure them. > >So I've built this website monitoring the status of DNS root servers >prefixes once a day: http://rpki.me/dns.html > >(So far I'm using LINX route-views monitor and RIR's RPKI repo + CA0 repo) > >RIPE NCC already told me that they will secure the v4 address of K-root >very soon. > >I also wrote to several other root server operators, but I'm still >waiting an answer. > > >Some prefixes are in v4 legacy address space (not administered by ARIN: >with RegDate < 22 Dec 1997). I suppose that this might be a problem in >order to obtain certificates covering them from ARIN. > > >Regards > >-- >Daniele Iamartino >Computer engineering student at Politecnico di Milano, Italy > >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr --B_3498786579_11936243 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITvAYJKoZIhvcNAQcCoIITrTCCE6kCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYgwggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/Bvw MDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJl ZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqp FZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/i sdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm +qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusI Xxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E FgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNt yA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3laz n8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91// IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+G xvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cq aBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCy p/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMQIQD89pSVGbAJQ9+ZeKCcX9BTAJBgUrDgMCGgUAoF0wIwYJKoZIhvcN AQkEMRYEFAKOWII58ZhgKIUaMXPNOHxRivliMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTE0MTExMzE5MDkzOVowDQYJKoZIhvcNAQEBBQAEggEAEf14CMhv UhxRROTgLBRKDFLEJ3i1RjCAPE8tZSFB/g0P+o08evRqPlpS9RwJORx+fSTulTn3SSrfNeG6 WPH+H3HF6T7K8qI5k7NxcH4F1lkmPbL+OPRxDSwdo2fqumiYh7cpjD7WEkO/fUJZj+oKY6kb 1fGHmTB7Q58zoAaUJ+G0N17GNq/BdthdyMKeSjqtPpnb0SrLwf9ezZuFR+RrBeLmJEu9EPHH Kpe3BxY0KAjrhMtg24cXO0qFQ2ujHZwqQiIjRrty+UqT/1UovPyZz7jwcNCrPtvztS3SNSnf Chx9jZ4hkn08DT1S3Qkt7jnp2ZV9KcDXamk2ezFu10BRAg== --B_3498786579_11936243-- From nobody Fri Nov 14 11:10:02 2014 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 DDB981A8A4B; Fri, 14 Nov 2014 11:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.646 X-Spam-Level: *** X-Spam-Status: No, score=3.646 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 Pa124cqoHfPv; Fri, 14 Nov 2014 11:09:56 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9871A8A17; Fri, 14 Nov 2014 11:09:56 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.161.204; From: "Susan Hares" To: , Date: Fri, 14 Nov 2014 14:09:54 -0500 Message-ID: <049301d0003e$93ca1090$bb5e31b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0494_01D00014.AAF67990" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdAAPjI0dIgLTgo0RL2qOw+rvEk1tA== X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/zKXtBXLlWtUUBOvR7UCQY7NriMg Subject: [sidr] etherpad and jabber sessions are on IDR for Friday's session 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, 14 Nov 2014 19:09:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0494_01D00014.AAF67990 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit For those remote - we will be using the IDR etherpad and jabber sessions for the joint sidr/IDR session today. Sue ------=_NextPart_000_0494_01D00014.AAF67990 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For those = remote – we will be using the IDR etherpad  and jabber = sessions for the joint sidr/IDR session today.

 

Sue =

------=_NextPart_000_0494_01D00014.AAF67990-- From nobody Fri Nov 14 11:50:31 2014 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 EF2B01A9042; Fri, 14 Nov 2014 11:50:20 -0800 (PST) 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 0ieErxeT8dnz; Fri, 14 Nov 2014 11:50:17 -0800 (PST) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B35441A904A; Fri, 14 Nov 2014 11:50:17 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id id10so4888112vcb.32 for ; Fri, 14 Nov 2014 11:50:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Z6phTMi1hICd7a3siXW7rljo7RwLNnNk6rrV0ipqxg8=; b=zvM9wK4e3TiCyCGXbNU/lYo7K/x8R/BZ3mqS8UGgvgDoljPtM3CEQ5Fm8hE4/nL5nJ jE3H1JLzyTsdSSDGlHiyVJ4+SMAP1HZ/BOR961zZtPb4LLNcputpHr5gAEF9n7RqrINS vw5nu4/g3QLZ/JGFItOrMLpQLD+cV2LEElhO5AHQiW1dEGGuRNG3vfjwe3TT3CGTETOo pw2PtAQhUcEPoRKj6ba7BrMs3ViRONowS/QQekTDT2mNxQVJyvWDQex+vyihlHih7Rx6 Skr+dHDKbaa1NN5FA+KYPDHDysdZeW7VjEhQu9AO8w1pyzDZXc9Xr4f5FG1N39nq6MkU Dgfw== MIME-Version: 1.0 X-Received: by 10.220.136.17 with SMTP id p17mr8109955vct.3.1415994616886; Fri, 14 Nov 2014 11:50:16 -0800 (PST) Received: by 10.221.44.8 with HTTP; Fri, 14 Nov 2014 11:50:16 -0800 (PST) Date: Fri, 14 Nov 2014 14:50:16 -0500 Message-ID: From: Christopher Morrow To: "idr@ietf.org List" , "sidr@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/MeohmsMvigW8uAlNar_nr9EGVKA Subject: [sidr] A note from today's IDR/SIDR joint meeting - RPKI-RTR protocol document 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, 14 Nov 2014 19:50:21 -0000 The topic of getting 'rpki data to routers' is covered in the 'rpki-rtr' document: RFC6810 - and: -chris From nobody Fri Nov 14 12:01:26 2014 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 7AD851A8863; Fri, 14 Nov 2014 12:01:15 -0800 (PST) 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 D40pUW0zM_bJ; Fri, 14 Nov 2014 12:01:12 -0800 (PST) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37A341A90D1; Fri, 14 Nov 2014 12:00:56 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id id10so4897637vcb.18 for ; Fri, 14 Nov 2014 12:00:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+UGORUDvN4o0KNJc5sLP7YEsWaMYgngrW5kaIy44Mv8=; b=JJse8LbDftygSkxuKSF005bVDuU2DXAfxpFaQ5VTuU3aw1c/tLOaN1zHiuxz3jIcdC lVSDxncy5rEPBt0oDArsKjBZgysSRc8HGxCB+/HiB9N+246la0PWBfnHzawqaEauoXwr l7wJDnbzIAfS0o7gMyFmvgKV4eFAazQCe8UAancIq1+wuMvobwPfBf8SJcWLRmaPSO29 wNKzUhBZMiqH01GYUVa0pCGGZLk7y2VzRhWh00OJz5qphNyj2ZFezCdjTO8UB56cUKfK YDDi7uL4/c8uPoMsTTfHqTBs+y59W63lXH2Id9nOD7gapiBXBKT3NAKpkaHOy74hWcuM 7xbw== MIME-Version: 1.0 X-Received: by 10.52.128.105 with SMTP id nn9mr1026690vdb.59.1415995255251; Fri, 14 Nov 2014 12:00:55 -0800 (PST) Received: by 10.221.44.8 with HTTP; Fri, 14 Nov 2014 12:00:55 -0800 (PST) In-Reply-To: References: Date: Fri, 14 Nov 2014 15:00:55 -0500 Message-ID: From: Christopher Morrow To: "idr@ietf.org List" , "sidr@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/ML9YACKAuLm8D73-bhpcncXSD18 Subject: Re: [sidr] A note from today's IDR/SIDR joint meeting - RPKI-RTR protocol document 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, 14 Nov 2014 20:01:15 -0000 Also there was a question (from hannes?) about algorithm change processes and timelines.. that's covered in: -chris On Fri, Nov 14, 2014 at 2:50 PM, Christopher Morrow wrote: > The topic of getting 'rpki data to routers' is covered in the > 'rpki-rtr' document: > RFC6810 - > > and: > > > -chris From nobody Fri Nov 14 12:39:15 2014 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 C91111A0045 for ; Fri, 14 Nov 2014 12:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 s8cfrCM_Gs9B for ; Fri, 14 Nov 2014 12:39:13 -0800 (PST) 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 8DBAE1A0015 for ; Fri, 14 Nov 2014 12:39:13 -0800 (PST) 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 1XpNe5-0001Ae-IQ; Fri, 14 Nov 2014 21:39:06 +0100 Received: from tel-sslvpn-1.ripe.net ([193.0.20.232] helo=vpn-97.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1XpNe5-0004VJ-71; Fri, 14 Nov 2014 21:39:05 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Tim Bruijnzeels In-Reply-To: Date: Fri, 14 Nov 2014 10:38:58 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sandra Murphy X-Mailer: Apple Mail (2.1878.6) X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719c9534209cfb3dd6db391901a6941aded Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/vmEze9cBwp24IFZcJVcpO5v6sFE Cc: sidr wg list Subject: Re: [sidr] this is possibly Tim Bruijnzeels delta protocol 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, 14 Nov 2014 20:39:15 -0000 Hi all, This is the old version of the doc. The basic principle remains the = same, but we made some significant simplifications. I am working on a = revised document and I hope to post it to the wg within two weeks. So, = you=92re welcome to read this, but it may be worth waiting for the = update because it will hopefully already answer questions that you might = have reading this old document. Thanks, Tim On 10 Nov 2014, at 10:17, Sandra Murphy wrote: > Took some searching but here is a recent submission with Tim's name on = it. >=20 > https://tools.ietf.org/html/draft-tbruijnzeels-sidr-delta-protocol-02 >=20 > --Sandy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Sun Nov 16 15:24:09 2014 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 801AF1A1F20 for ; Sun, 16 Nov 2014 15:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.54 X-Spam-Level: * X-Spam-Status: No, score=1.54 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.594, 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 wPOw-vhIWRbP for ; Sun, 16 Nov 2014 15:23:44 -0800 (PST) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 6212D1A1BFE for ; Sun, 16 Nov 2014 15:23:44 -0800 (PST) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.07,399,1413259200"; d="scan'208";a="218789030" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 16 Nov 2014 18:22:17 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Sun, 16 Nov 2014 18:23:43 -0500 From: "George, Wes" To: Matthew Lepinski , "sidr@ietf.org" Date: Sun, 16 Nov 2014 18:23:42 -0500 Thread-Topic: [sidr] New version : draft-ietf-sidr-bgpsec-protocol-10 Thread-Index: AdAB9FxDB0hLm5wNQkSfOxiaDvKBzw== 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.4.5.141003 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/Az5wIzjq0jN2IgivD9ev--j8yK8 Subject: Re: [sidr] New version : draft-ietf-sidr-bgpsec-protocol-10 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, 16 Nov 2014 23:23:46 -0000 TWF0dC0NCg0KUGVyIGRpc2N1c3Npb24gZHVyaW5nIElEUi9TSURSIG1lZXRpbmcgRnJpZGF5LCB0 aGVyZSBtYXkgbmVlZCB0byBiZSBzb21lDQp0ZXh0IGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucyBhcm91bmQgdGhlIGF0dGFjayB2ZWN0b3Igb2Ygc2VuZGluZw0KbWFueSB1cGRhdGVzIHdp dGggbG9uZyAoYnV0IHZhbGlkKSBBU19QYXRocywgc2luY2UgdGhlIGFuYWx5c2lzIFNyaXJhbQ0K cHJvdmlkZWQgaW5kaWNhdGVkIGEgY29ycmVsYXRpb24gYmV0d2VlbiB0aGUgbGVuZ3RoIG9mIHRo ZSBBUyBQYXRoIHRvIGJlDQp2YWxpZGF0ZWQgYW5kIENQVSBpbXBhY3Qgb3IgY29udmVyZ2VuY2Ug dGltZSBpbXBhY3QuIFNvdW5kcyBsaWtlIHdlIGRvbid0DQpoYXZlIGEgcHJvYmxlbSB3aXRoIGxv bmcgcGF0aHMgY29tcHJpc2VkIG9mICBtdWx0aXBsZSBwcmVwZW5kcyBiZWNhdXNlDQpQY291bnQg bWVhbnMgdGhhdCB0aGVyZSBhcmVuJ3QgbXVsdGlwbGUgc2lnbmF0dXJlcywgYnV0IHZhbGlkbHkg c2lnbmVkDQpzdHJpbmdzIG9mIHVuaXF1ZSBBU05zIGNvdWxkIHN0aWxsIHRyaWdnZXIgdGhpcyBw cm9ibGVtLCB3aGV0aGVyIHRoZXkgYXJlDQpnZW5lcmF0ZWQgYWNjaWRlbnRhbGx5IG9yIG1hbGlj aW91c2x5LiBXZSBtYXkgYWxzbyBuZWVkIHRvIG1ha2UgdGhlDQpvYnNlcnZhdGlvbiB0aGF0IHJh cGlkIHJvdXRlIGNodXJuIHdpdGggdGhlc2Ugc29ydHMgb2YgcHJlZml4ZXMgYXJlIGxpa2VseQ0K dG8gbWFrZSB0aGUgaW1wYWN0IGV2ZW4gaGlnaGVyLCBzdWNoIHRoYXQgaXQgbWF5IGJlIGFkdmlz YWJsZSB0byBpbXBsZW1lbnQNCnJvdXRlIGZsYXAgZGFtcGVuaW5nIHRvIHByb3ZpZGUgYWRkaXRp b25hbCBwcm90ZWN0aW9uIGFnYWluc3Qgcm91dGUgY2h1cm4uDQoNCg0KVGhhdCBzYWlkLCBJJ20g bm90IHN1cmUgdGhhdCB0aGlzIGlzIHN0cmljdGx5IGEgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMN CmFkZGl0aW9uLCBiZWNhdXNlIHdlIG1heSBuZWVkIHRvIG1ha2Ugc29tZSBzdWdnZXN0aW9ucyBp biB0aGUgZGVzaWduIHRvDQpwcm90ZWN0IGFnYWluc3QgdGhlc2Ugc29ydHMgb2Ygc2NhbGluZyBw cm9ibGVtcy4NCkknbSBub3Qgc3VyZSBpZiB3ZSBjYW4gdXNlIGFuYWx5c2lzIG9mIGV4aXN0aW5n IHJvdXRpbmcgdGFibGUgZGF0YSB0bw0KaWRlbnRpZnkgYW4gODAvMjAgdGhyZXNob2xkIG9mIHRo ZSBsb25nZXN0IGNyZWRpYmxlIEFTIFBhdGggYW5kIHB1dCBhDQpyZWNvbW1lbmRhdGlvbiBvbiBh IG1heF9hc19sZW5ndGggdmFsdWUgZm9yIHRoZSBsaW1pdCBmb3IgcHJvdGVjdGlvbg0KYWdhaW5z dCB0aGlzIGF0dGFjaywgb3Igd2hldGhlciB3ZSBjYW5ub3QgcmVjb21tZW5kIGEgdmFsdWUsIGFu ZCBoYXZlIHRvDQpzaW1wbHkgYWNrbm93bGVkZ2UgdGhhdCB0aGlzIGlzIGEgcHJvYmxlbSBhbmQg cmVjb21tZW5kIHRoYXQgaW1wbGVtZW50ZXJzDQpwcm92aWRlIGEga25vYiBmb3Igc2V0dGluZyBh IGxpbWl0IG9uIEFTIFBhdGggc3VjaCB0aGF0IGltcGxlbWVudGF0aW9ucw0KY2FuIGludGVyY2Vw dCBhbmQgZHJvcCBsb25nIEFTX1BhdGhzIGJlZm9yZSB0aGUgQkdQU2VjIG1hY2hpbmVyeSB0cmll cyB0bw0KdmFsaWRhdGUgdGhlbS4gUGVyaGFwcyBib3RoLCBpLmUuIEEgcmVhc29uYWJsZSBkZWZh dWx0IGxpbWl0IHRoYXQgY2FuIGJlDQpyYWlzZWQgb3IgbG93ZXJlZCBpZiBhIHVzZXIgc2VlcyBm aXQuIEFsdGVybmF0aXZlbHksIHdlIGNvdWxkIHN1Z2dlc3QgYQ0KZmFsbC1iYWNrIG1ldGhvZCB3 aGVyZWJ5IGV4Y2Vzc2l2ZWx5IGxvbmctcGF0aCBCR1BTZWMgdXBkYXRlcyBhcmUNCmRlcHJpb3Jp dGl6ZWQgb3IgdGhyb3R0bGVkIHRvIGF2b2lkIGNhdXNpbmcgYWR2ZXJzZSBwZXJmb3JtYW5jZSBp bXBhY3RzLA0KcGVyaGFwcyBpbiBjb25qdW5jdGlvbiB3aXRoIGV4aXN0aW5nIFJGRCBpbXBsZW1l bnRhdGlvbnMgZm9yIHJvdXRlcyB0aGF0DQphcmUgYm90aCBsb25nLXBhdGggYW5kIGNodXJuaW5n Lg0KDQpJIGNhbiB0cnkgdG8gY29udHJpYnV0ZSBzb21lIHRleHQgb25jZSB0aGUgV0cgd2VpZ2hz IGluIG9uIHdoYXQgZGlyZWN0aW9uDQp0aGV5IHdhbnQgdG8gdGFrZSB0byBhZGRyZXNzIHRoaXMs IGJ1dCBJIHdhbnRlZCB0byBhdCBsZWFzdCBnZXQgdGhlDQpkaXNjdXNzaW9uIHN0YXJ0ZWQuDQoN ClRoYW5rcywNCg0KV2VzIEdlb3JnZQ0KDQoNCg0KT24gMTAvMjcvMTQsIDc6NDAgUE0sICJNYXR0 aGV3IExlcGluc2tpIiA8bWxlcGluc2tpLmlldGZAZ21haWwuY29tPiB3cm90ZToNCg0KPkp1c3Qg cG9zdGVkIHRoZSAtMTAgcmV2aXNpb24gb2YgdGhlIGRvY3VtZW50Lg0KPg0KPlRoZSBvbmx5IG5v cm1hdGl2ZSBjaGFuZ2Ugd2FzIHRvIGRlY291cGxlIEJHUHNlYyB2YWxpZGF0aW9uIGZyb20NCj5P cmlnaW4gVmFsaWRhdGlvbi4gKFRoaXMgaXMgYSBub3JtYXRpdmUgY2hhbmdlIHRvIHRoZSB2YWxp ZGF0aW9uDQo+YWxnb3JpdGhtIGluIFNlY3Rpb24gNS4pIFRoaXMgaXMgYmFzZWQgb24gd29ya2lu ZyBncm91cCBkaXNjdXNzaW9ucyBhdA0KPklFVEYgOTAgYW5kIGNvbmZpcm1lZCBvbiB0aGUgbGlz dCBpbiBTZXB0ZW1iZXIuDQo+DQo+QWRkaXRpb25hbGx5LCB0aGVyZSB3ZXJlIHNvbWUgdGV4dCBj aGFuZ2VzIG1hZGUsIGluY2x1ZGluZyBhIHJlZmVyZW5jZQ0KPnRvIHRoZSBBUy1NaWdyYXRpb24g ZG9jdW1lbnQgKGFuZCBhbiBhY2NvbXBhbnlpbmcgdGV4dCBjaGFuZ2UNCj5yZWdhcmRpbmcgcENv dW50PTApLg0KPg0KPkkgaGF2ZSBhIGNvdXBsZSBvZiBpbXByb3ZlbWVudHMgdG8gdGhlIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIHRleHQNCj50aGF0IEkgd2Fzbid0IGFibGUgdG8gZm9sZCBpbnRv IHRoaXMgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQuDQo+DQo+T3RoZXIgdGhhbiBpbXByb3Zpbmcg dGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLCBJIGFtIG5vdCBhd2FyZSBvZg0KPmFueSBvcGVu IGlzc3VlcyBpbiB0aGlzIHBhcnRpY3VsYXIgZG9jdW1lbnQuDQo+DQo+LSBNYXR0IExlcGluc2tp DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5z aWRyIG1haWxpbmcgbGlzdA0KPnNpZHJAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpZHINCg0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRh Y2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1h dGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNv cHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGlu dGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8g d2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNz ZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxh dGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlz IHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkg b2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg== From nobody Sun Nov 16 21:13:37 2014 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 295F31A00DF for ; Sun, 16 Nov 2014 21:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 KPmexv5-zKuD for ; Sun, 16 Nov 2014 21:13:31 -0800 (PST) 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 AE4EF1A00E5 for ; Sun, 16 Nov 2014 21:13:31 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1XqEcx-0000cz-FV; Mon, 17 Nov 2014 05:13:28 +0000 Date: Mon, 17 Nov 2014 11:13:25 +0600 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: http://mailarchive.ietf.org/arch/msg/sidr/jgm4fpFpvUQoDbz-VL5LbSsqnnE Cc: sidr wg list Subject: Re: [sidr] New version : draft-ietf-sidr-bgpsec-protocol-10 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, 17 Nov 2014 05:13:33 -0000 > Per discussion during IDR/SIDR meeting Friday, there may need to be > some text in the security considerations around the attack vector of > sending many updates with long (but valid) AS_Paths could you please describe how an attacker can send many long bgpsec paths? how are these long paths signed? randy From nobody Mon Nov 17 01:33:07 2014 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 A71661A1A4C; Mon, 17 Nov 2014 01:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 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, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, 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 pWWKOwh7i7fU; Mon, 17 Nov 2014 01:33:00 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A08F01A1A46; Mon, 17 Nov 2014 01:33:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2049; q=dns/txt; s=iport; t=1416216780; x=1417426380; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=AH1RUulac6I3q9CdYLMso8uGkYjE8eLmIgKFebqM0DQ=; b=B+vvGQSvm07hZfObuBDsYOmcBgoTe7P7vyBG9s9tE5xlNOWFSrHqlYgS b5Ugx9Zp5/ZNw4hB3uGonAsjL6ZVKkGsGKLT+WHR609FQrYhMLX5JhKnE Yzb433/46X3j7aTk2g9HmKew4ciP1gXaog4nPae/Xj8uVz3pvTMGuOKyn s=; X-Files: smime.p7s : 654 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAFzAaVStJA2I/2dsb2JhbABbgw5VWQTMDAqHTgKBFxYBAQEBAX2EAwEBBAEBAWsbAgEIGC4CHwYLJQIEARIOiB4DEg3KHQ2GWgEBAQEBAQEBAQEBAQEBAQEBARqOZIIjIoRLBZJHghyBVGuFF4ITgXGOFIZ1gjaBRm2BSIEDAQEB X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="p7s'?scan'208";a="372781915" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP; 17 Nov 2014 09:32:49 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sAH9WnPx021621 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Nov 2014 09:32:49 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.221]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Mon, 17 Nov 2014 03:32:49 -0600 From: "Roque Gagliano (rogaglia)" To: Christopher Morrow , "idr@ietf.org List" , "sidr@ietf.org" Thread-Topic: [Idr] A note from today's IDR/SIDR joint meeting - RPKI-RTR protocol document Thread-Index: AQHQAklzt2rxV2gt80ipEslQPl1Q0A== Date: Mon, 17 Nov 2014 09:32:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.148.51.55] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3499065172_27159128" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/49mgmjyu21VDNz6v_ZdtIKOg_-0 Subject: Re: [sidr] [Idr] A note from today's IDR/SIDR joint meeting - RPKI-RTR protocol document 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, 17 Nov 2014 09:33:02 -0000 --B_3499065172_27159128 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Chis, The document is now RFC 6912 published as BCP. Regards, Roque On 14/11/14 21:00, "Christopher Morrow" wrote: >Also there was a question (from hannes?) about algorithm change >processes and timelines.. that's covered in: > > >-chris > >On Fri, Nov 14, 2014 at 2:50 PM, Christopher Morrow > wrote: >> The topic of getting 'rpki data to routers' is covered in the >> 'rpki-rtr' document: >> RFC6810 - >> >> and: >> >> >> -chris > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr --B_3499065172_27159128 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIICigYJKoZIhvcNAQcCoIICezCCAncCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwExggJSMIICTgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENv cnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEHgmPGbEBYqJ98YIErP9kawwDQYJYIZIAWUDBAIB BQCgaTAvBgkqhkiG9w0BCQQxIgQges0k81WsS7cX2/RkLYVAND9/s6ffmdvMxP0aVF+7fOUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQxMTE3MDkzMjUy WjANBgkqhkiG9w0BAQEFAASCAQBMAligU/tlypDr/+cOo1lR3wvNTWzuOha1KnbAzXmCLqyl 5xBl37anc+Kggx65+5nwYOS4ZhO9GK/1DvbXgVITBBwksqB8Jd/8pz3JWEki/wDIXJnlKOZp Dtpq+n29KI1pXqEx9qmu64ROS/Kr7v1W3tbRne6g38FvTiR0ji1NlWxpn3u+b0BtBEPpYRo5 +6et+qy758SEq3uy1FYtgLSU8zpMgjngljPxdXAYwfdws9CDgnOhopzn5Em3uX9nGrOspKCN SqL2NY0lsZa9oUa5mGrfuSYZRBtBphvFJ2KVG9uInHu77DZva/rHFwOaYe+7N7HZISn6Kjyy k0m6Y+hO --B_3499065172_27159128-- From nobody Mon Nov 17 06:44:13 2014 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 C927E1A6F28; Mon, 17 Nov 2014 06:44:07 -0800 (PST) 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 dNqqLMMm0TyZ; Mon, 17 Nov 2014 06:44:06 -0800 (PST) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1FBC1A3BA5; Mon, 17 Nov 2014 06:44:05 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id im17so7260305vcb.13 for ; Mon, 17 Nov 2014 06:44:05 -0800 (PST) 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=Ba5V89puFrU9C+PvBA8E3rnuJQvD2vjrJYkwwehQLaw=; b=MwtLKbA70qH6wmsRlXpYPvfzP3S0Jp5T3I6Yb8VDibyysz0No5R3XwAxLYVKA8tsUS Xdu7YHudYw8zo8i8054+AWDx1uQwVdcY/5qu7nrq7FpVFXqHbzOwcisdbekTELmH12Ko ck0t1EuUxa66tS8sgC3eTBKwHZWHPU96wdL0a6WN9ydYs1Y/4RFIqhn9T+1TrFg0Dkjg udWvePlgK5TIovFAZlQJ21Ts41OzU7Z01YZOxVBr1ds8p9ZgBdDRZBNByG0p2zJBc+DO Unyb7CbS/G3ZYd7BndSuH+uvOUw7Yk7vJ1wLSNalHpJMISn06l6oVYO9QkRwz4hfYVLV k63A== MIME-Version: 1.0 X-Received: by 10.220.213.197 with SMTP id gx5mr14275618vcb.51.1416235445043; Mon, 17 Nov 2014 06:44:05 -0800 (PST) Received: by 10.221.44.8 with HTTP; Mon, 17 Nov 2014 06:44:04 -0800 (PST) In-Reply-To: References: Date: Mon, 17 Nov 2014 09:44:04 -0500 Message-ID: From: Christopher Morrow To: "Roque Gagliano (rogaglia)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/Qq7L8fUF7POxkpmia7dHwv02YI8 Cc: "idr@ietf.org List" , "sidr@ietf.org" Subject: Re: [sidr] [Idr] A note from today's IDR/SIDR joint meeting - RPKI-RTR protocol document 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, 17 Nov 2014 14:44:08 -0000 On Mon, Nov 17, 2014 at 4:32 AM, Roque Gagliano (rogaglia) wrote: > Chis, > > The document is now RFC 6912 published as BCP. great! (I should have looked further along the line in the tools page I bet) > > Regards, > Roque > > On 14/11/14 21:00, "Christopher Morrow" > wrote: > >>Also there was a question (from hannes?) about algorithm change >>processes and timelines.. that's covered in: >> >> >>-chris >> >>On Fri, Nov 14, 2014 at 2:50 PM, Christopher Morrow >> wrote: >>> The topic of getting 'rpki data to routers' is covered in the >>> 'rpki-rtr' document: >>> RFC6810 - >>> >>> and: >>> >>> >>> -chris >> >>_______________________________________________ >>Idr mailing list >>Idr@ietf.org >>https://www.ietf.org/mailman/listinfo/idr From nobody Mon Nov 17 06:55:30 2014 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 658F81A6F58; Mon, 17 Nov 2014 06:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.445 X-Spam-Level: X-Spam-Status: No, score=-4.445 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 5Fww_vfxohNt; Mon, 17 Nov 2014 06:55:27 -0800 (PST) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 361DB1A6F53; Mon, 17 Nov 2014 06:55:27 -0800 (PST) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XqNi8-000j6M-KZ>; Mon, 17 Nov 2014 15:55:24 +0100 Received: from ze304.pia.fu-berlin.de ([87.77.227.4] helo=mw-PC.zedat.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XqNi8-000fer-JP>; Mon, 17 Nov 2014 15:55:24 +0100 Date: Mon, 17 Nov 2014 15:55:21 +0100 From: Matthias Waehlisch To: Christopher Morrow In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) X-X-Sender: waehl@mail.zedat.fu-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Originating-IP: 87.77.227.4 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/QG5hoIsYKBKiKP9yEpJDL8kJ5qM Cc: "idr@ietf.org List" , "sidr@ietf.org" Subject: Re: [sidr] [Idr] A note from today's IDR/SIDR joint meeting - RPKI-RTR protocol document 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, 17 Nov 2014 14:55:29 -0000 Just to be precise, it's RFC 6916 (BCP 182). RFC 6912 is about "Principles for Unicode Code Point Inclusion in Labels in the DNS" - differnet topic ;). Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net On Mon, 17 Nov 2014, Christopher Morrow wrote: > On Mon, Nov 17, 2014 at 4:32 AM, Roque Gagliano (rogaglia) > wrote: > > Chis, > > > > The document is now RFC 6912 published as BCP. > > great! (I should have looked further along the line in the tools page I bet) > > > > > Regards, > > Roque > > > > On 14/11/14 21:00, "Christopher Morrow" > > wrote: > > > >>Also there was a question (from hannes?) about algorithm change > >>processes and timelines.. that's covered in: > >> > >> > >>-chris > >> > >>On Fri, Nov 14, 2014 at 2:50 PM, Christopher Morrow > >> wrote: > >>> The topic of getting 'rpki data to routers' is covered in the > >>> 'rpki-rtr' document: > >>> RFC6810 - > >>> > >>> and: > >>> > >>> > >>> -chris > >> > >>_______________________________________________ > >>Idr mailing list > >>Idr@ietf.org > >>https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From nobody Mon Nov 17 14:21:25 2014 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 C06031ACD1B for ; Mon, 17 Nov 2014 14:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 yZrsrmY3ERxv for ; Mon, 17 Nov 2014 14:21:08 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1A71ACD95 for ; Mon, 17 Nov 2014 14:21:08 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id r20so4323297wiv.2 for ; Mon, 17 Nov 2014 14:21:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=g+qSDZBQO2gqVw5vuV+YGwvZN6Zq5O8Pk26VLcHviaY=; b=MCSD8cCyxjYxCIQEkWMIl8z5/mY55MxzCM5oRX5BH3Vs8839PfWoWcRHEAuXO1uMsZ wVTMJDXz2SF1TKJf5MfsYrSMP3DHSVs9r1B89jV8yc8qhesAaHP6+ptAETAdMF+3flRa lbn0OABk4pRDmqCN0bpomH5uWHXoAchxoKnZgzblL9OUjrsCRhpLoL/FAQABBKBAJyzJ ynPZ66xKEbJN0djknHuypjg/JfO3VR3bJgdVhCe4jDbw5mm/HAFd2ajanzT6tS1SvHPE Xnp0UQCAAz4CoX88uq4k3mftnKXqUuv6H1wEgj/L3nAIISDIp5eFVI7oFyV84QcoX/j1 mJZw== X-Gm-Message-State: ALoCoQmPgqw658Wd9r09uhZlt8tAXJC3oycAO//51yIkQTTITszPXv9PhUFAvaGFMGXJRSpuqlV8 MIME-Version: 1.0 X-Received: by 10.194.93.168 with SMTP id cv8mr14749494wjb.114.1416262867301; Mon, 17 Nov 2014 14:21:07 -0800 (PST) Received: by 10.194.64.37 with HTTP; Mon, 17 Nov 2014 14:21:07 -0800 (PST) In-Reply-To: References: Date: Mon, 17 Nov 2014 12:21:07 -1000 Message-ID: From: Warren Kumari To: Randy Bush Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/TFWY38YhmE2uLKhDMKaOE_EcLDs Cc: sidr wg list Subject: Re: [sidr] New version : draft-ietf-sidr-bgpsec-protocol-10 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, 17 Nov 2014 22:21:19 -0000 On Sun, Nov 16, 2014 at 7:13 PM, Randy Bush wrote: >> Per discussion during IDR/SIDR meeting Friday, there may need to be >> some text in the security considerations around the attack vector of >> sending many updates with long (but valid) AS_Paths > > could you please describe how an attacker can send many long bgpsec > paths? how are these long paths signed? > I'm not Wes, but I could imagine an attacker who has 2 ASNs making a path that looks like: 192.0.2.0/24 174 3561 17 42 17 42 17 42 .... 17 42 17 42 701 Seems like it would be a lot of work for very little fun, but that's what I'd understood the question to be. W > randy > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Nov 17 14:27:31 2014 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 2D48F1ACDCE for ; Mon, 17 Nov 2014 14:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.54 X-Spam-Level: * X-Spam-Status: No, score=1.54 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.594, 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 eOSXJj1TVfaY for ; Mon, 17 Nov 2014 14:27:28 -0800 (PST) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id BA0BD1ACDC9 for ; Mon, 17 Nov 2014 14:27:27 -0800 (PST) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.07,405,1413259200"; d="scan'208";a="219381791" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 17 Nov 2014 17:25:42 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Mon, 17 Nov 2014 17:27:08 -0500 From: "George, Wes" To: Randy Bush Date: Mon, 17 Nov 2014 17:27:07 -0500 Thread-Topic: [sidr] New version : draft-ietf-sidr-bgpsec-protocol-10 Thread-Index: AdACtZ+vmtouCk7KQKqIs9f2vPt31w== 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.4.6.141106 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/tjoKDir5dWrnR0DUwEhbece_KF8 Cc: sidr wg list Subject: Re: [sidr] New version : draft-ietf-sidr-bgpsec-protocol-10 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, 17 Nov 2014 22:27:30 -0000 T24gMTEvMTcvMTQsIDEyOjEzIEFNLCAiUmFuZHkgQnVzaCIgPHJhbmR5QHBzZy5jb20+IHdyb3Rl Og0KDQoNCj5jb3VsZCB5b3UgcGxlYXNlIGRlc2NyaWJlIGhvdyBhbiBhdHRhY2tlciBjYW4gc2Vu ZCBtYW55IGxvbmcgYmdwc2VjDQo+cGF0aHM/ICBob3cgYXJlIHRoZXNlIGxvbmcgcGF0aHMgc2ln bmVkPw0KDQpUaG91Z2ggSSdtIGd1ZXNzaW5nIGl0IG1pZ2h0IGJlIHBvc3NpYmxlIHRvIHRyeSBp dCBhcyBhIHJlcGxheSBhdHRhY2sNCihncmFiIGEgc3RyaW5nIG9mIHNpZ25lZCBBU05zIGZyb20g dGhlIHBhdGggb2Ygb25lIG9yIG1vcmUgcm91dGVzIHRoYXQgZ28NCnBhc3QgeW91LCB0aGVuIGFk ZCB0aGVtIHRvIGFub3RoZXIgc2V0IG9mIHJvdXRlcyB0aGF0IGRvZXNuJ3QgYWxyZWFkeSBoYXZl DQp0aGVtKSwgSSB3YXMgdGhpbmtpbmcgdGhlIGF0dGFja2VyIGxpa2VseSBoYXMgdG8gaGF2ZSB0 aGUgYWJpbGl0eSB0byBzaWduDQp0aG9zZSBBU05zICh0aGV5IGhhdmUgdGhlIGtleXMpIHNvIHRo YXQgdGhleSdyZSB2YWxpZCwgb3RoZXJ3aXNlIHRoZSByb3V0ZQ0KanVzdCBnZXRzIGRyb3BwZWQu DQpJdCdzIG5vdCBoYXJkIHRvIGdldCBhbiBBU04gb3IgMTAuICREYXlqb2IgaGF2ZSAxMiBvciAx NSB0aGF0IEkga25vdw0KYWJvdXQsIENvbWNhc3QgaGFzIDMwKyBBU05zLCBhbmQgcGxlbnR5IG9m IGhvc3RpbmcgcHJvdmlkZXJzIHVzZSBhbiBBU04NCnBlciBsb2NhdGlvbiB0byBhdm9pZCBuZWVk aW5nIHdheXMgdG8gY29ubmVjdCBpc2xhbmRzIG9mIHRoZSBzYW1lIEFTTg0KdG9nZXRoZXIuIE5v cm1hbGx5IHRoZXkgZG9uJ3QgaGF2ZSByb3V0ZXMgdGhhdCBnbyB0aHJvdWdoIGVhY2ggQVNOLCBi dXQNCnNwaW5uaW5nIHVwIEJHUCBzcGVha2luZyBWTSBpbnN0YW5jZXMgb24gUXVhZ2dhIG9yIHNp bWlsYXIgdG8gZ2VuZXJhdGUNCnJvdXRlcyB0byBpbmplY3QgYW5kIHNpZ24gZnJvbSBvbmUgQVNO IHRvIGFub3RoZXIgaXMgbm90IGhhcmQuIEluIG9yZGVyIHRvDQphdm9pZCB0aGUgcHJvdGVjdGlv bnMgdGhhdCBPcmlnaW4gVmFsaWRhdGlvbiB3b3VsZCBwcm92aWRlLCBpdCdzIGxlc3MNCmxpa2Vs eSB0aGF0IHRoaXMgaXMgZ29pbmcgdG8gYmUgZG9uZSBhdCBvcmlnaW4sIGJ1dCByYXRoZXIgYnkg YW4gQVNOIHRoYXQNCmlzIGluIHRoZSBtaWRkbGUgb2YgdGhlIHBhdGguDQpJLmUuIDxvcmlnaW4+ IC0tIDx1cHN0cmVhbSAxPiAtLSA8YmFkIHVwc3RyZWFtPiAtLSA8dXBzdHJlYW0gMz4NCkJhZCB1 cHN0cmVhbSByZWNlaXZlcyByb3V0ZXMgZnJvbSBpdHMgZG93bnN0cmVhbSwgYW5kIGFkZHMgdGhl IGxpc3Qgb2YNCkFTTnMgaXQgY2FuIHNpZ24gZm9yIHBsdXMgYW55IGNodXJuIGl0IHdhbnRzIHRv IGluZHVjZSwgc2VuZHMgaXQgdG8NCnVwc3RyZWFtIDMsIHdoaWNoIGluIHRoaXMgY2FzZSB3b3Vs ZCBiZSB0aGUgdGFyZ2V0IG9mIHRoZSBhdHRhY2ssIGFuZCBpZg0KaXQgcHJvcGFnYXRlcyB0aGUg cm91dGVzIGZ1cnRoZXIsIG5ldHdvcmtzIGJleW9uZCBpdCB3b3VsZCBhbHNvIGJlDQphZmZlY3Rl ZC4gRXZlbiBpZiB0aGUgYWRkZWQgQVNOcyBpbiB0aGUgcGF0aCBoYXZlIHRoZSByZXN1bHQgb2YN CnJlZGlyZWN0aW5nIHRyYWZmaWMgdG8gYW5vdGhlciBjYW5kaWRhdGUgd2l0aCBhIHNob3J0ZXIg QVMgUGF0aCwgdGhlIHJvdXRlDQp1cGRhdGUgaXRzZWxmIHdpbGwgcHJvcGFnYXRlIG9uIGFuZCBz dGlsbCBlYXQgQ1BVIGFuZCBtZW1vcnkgb24gdGhlDQpyb3V0ZXJzIGl0IHRyYW5zaXRzLCBhbmQg bWF5YmUgZXZlbiBiZSBhbXBsaWZpZWQgYXMgaXQgZ2V0cyBkdXBsaWNhdGVkIHRvDQpiZSBzZW50 IHRvIHRoZSBsZWFybmluZyByb3V0ZXIncyBCR1AgcGVlcnMuIFRoaXMgYXR0YWNrIGlzIGRpZmZl cmVudCBmcm9tDQp0aGUgbm9ybWFsIEFTIFBhdGggYXR0YWNrcyBCR1BTZWMgd2FzIGRlc2lnbmVk IHRvIHByb3RlY3QgYWdhaW5zdCwgYmVjYXVzZQ0KaXQncyBub3QgbmVjZXNzYXJpbHkgdHJ5aW5n IHRvIGFkZCBhIHNwZWNpZmljIEFTTiB0byBzaGlmdCB0cmFmZmljIHRvIGENCmNlcnRhaW4gbmV0 d29yaywgdGhhdCdzIGp1c3QgYSBzaWRlLWVmZmVjdCBvZiB0aGUgYXR0ZW1wdCB0byBhdHRhY2sg dGhlDQpyb3V0ZXJzIHJ1bm5pbmcgQkdQU2VjIHRoZW1zZWx2ZXMuDQoNCkknbSB0aGlua2luZyBv ZiB0aGlzIGluIHRlcm1zIG9mIHdvcnN0LWNhc2Ugc2NlbmFyaW8sIHdoZXJlIG9uZSBidWlsZHMg YQ0KbmljZSBsb25nIEFTTiBwYXRoLCB0aGVuIHVzZXMgaXQgdG8gbGVuZ3RoZW4gYSBmZXcgdGhv dXNhbmQgcm91dGVzIGFzIHRoZXkNCnBhc3MsIGFuZCB0aGVuIGNodXJuIHRoZW0sIGVpdGhlciBv biB0aGUgYXNzdW1wdGlvbiB0aGF0IFJGRCBpc24ndA0KY29uZmlndXJlZCwgb3Iga2VlcGluZyB0 aGUgY2h1cm4gb24gYW4gaW5kaXZpZHVhbCByb3V0ZSBsb3cgZW5vdWdoIHRvIGtlZXANCmZyb20g dHJpZ2dlcmluZyB0aGUgZGFtcGVuaW5nLCBidXQgY2h1cm4gbG90cyBvZiByb3V0ZXMgc2ltdWx0 YW5lb3VzbHkuDQoNCkkgYWRtaXQgdGhhdCB0aGlzIHNlZW1zIGxpa2UgYSBzdHJldGNoIHNpbmNl IGV4cGxvaXRpbmcgaXQgcmVxdWlyZXMgYWNjZXNzDQp0byBBU05zIGFuZCBrZXlzIGFuZCBwb3Nz aWJseSBjb21wcm9taXNpbmcgYSByb3V0ZXIgaW4gdGhlIG1pZGRsZSBvZiBhDQpuZXR3b3JrIHNv IHRoYXQgeW91IGNhbiBoYXZlIGEgcGxhdGZvcm0gdG8gbGF1bmNoIHRoZSBhdHRhY2ssIGJ1dCB0 aGVyZSBpcw0KYWxzbyB0aGUgcG9zc2liaWxpdHkgdGhhdCB0aGUgc2ltcGxlIGFjdCBvZiBoYXZp bmcgYSBsb25nIHN0cmluZyBvZiB2YWxpZA0KQVNOcyBpbiB0aGUgYWN0dWFsIGZvcndhcmRpbmcg cGF0aCBjb3VsZCBjYXVzZSB0aGlzLCBlc3BlY2lhbGx5IGluDQpjb25qdW5jdGlvbiB3aXRoIGNo dXJuLCBsb3RzIG9mIHJvdXRlIGRlYWdncmVnYXRpb24sIGFuZCBtaXNjb25maWd1cmF0aW9uDQoo cm91dGUgbGVha3MpIHRoYXQgaGFzIHRoZSBuZXQgcmVzdWx0IG9mIHRha2luZyBhIGxvbmcgQVMg cGF0aCBhbmQgbWFraW5nDQppdCBsb25nZXIuIFRoZSBrZXkgcXVlc3Rpb24gYXMgdG8gaG93IG11 Y2ggb2YgYSBwcm9ibGVtIHRoaXMgYWN0dWFsbHkNCm1pZ2h0IGJlIGlzLCAiaG93IGxvbmcgb2Yg YW4gQVMgUGF0aCBpcyB0b28gbG9uZyBpbiBCR1BTZWM/IiBvcg0KYWx0ZXJuYXRlbHksICJ3aGVu IGRvZXMgdGhlIHByb2R1Y3Qgb2YgbnVtYmVyIG9mIHNpZ25lZCByb3V0ZXMgYW5kIG51bWJlcg0K b2YgQVNOcyBwZXIgcm91dGUgc3RhcnQgY2F1c2luZyBwZXJmb3JtYW5jZSBkZWdyYWRhdGlvbiBk dXJpbmcNCnZhbGlkYXRpb24/IikgSSdtIG5vdCBzdXJlIHdlIGNhbiBrbm93IHRoYXQgYXQgdGhp cyBwb2ludCwgYmVjYXVzZSBpdCdsbA0KZGVwZW5kIG9uIGEgbG90IG9mIHRoaW5ncywgc28gdW5s ZXNzIHdlIGNhbiBtYWtlIHNvbWUgY29tbW9uLXNlbnNlDQppbmZlcmVuY2VzIGJhc2VkIG9uIHdo YXQgd2Ugc2VlIGluIHRoZSByb3V0aW5nIHRhYmxlLCB3ZSBtYWlubHkgaGF2ZSB0bw0KaWRlbnRp ZnkgaXQgYXMgYSBwb3RlbnRpYWwgcHJvYmxlbS4NCg0KVGhhbmtzLA0KDQpXZXMNCg0KDQpBbnl0 aGluZyBiZWxvdyB0aGlzIGxpbmUgaGFzIGJlZW4gYWRkZWQgYnkgbXkgY29tcGFueeKAmXMgbWFp bCBzZXJ2ZXIsIEkNCmhhdmUgbm8gY29udHJvbCBvdmVyIGl0Lg0KLS0tLS0tLS0tLS0NCg0KDQoN Cg0KDQoNCg0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMg cHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdp bmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBm b3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRk cmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1t YWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0 cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29u dGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1h aWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVy bWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwg YW5kIGFueSBwcmludG91dC4NCg== From nobody Mon Nov 24 07:54:57 2014 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 EB5931A6FDC for ; Mon, 24 Nov 2014 07:54:55 -0800 (PST) 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 H7IFdUVP9aY4 for ; Mon, 24 Nov 2014 07:54:54 -0800 (PST) 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 46B8F1A6FD5 for ; Mon, 24 Nov 2014 07:54:54 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:50827 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XsvyW-000MDd-Sg for sidr@ietf.org; Mon, 24 Nov 2014 10:54:52 -0500 Message-ID: <547354D3.3020905@bbn.com> Date: Mon, 24 Nov 2014 10:54:59 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sidr@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/uYScnnOOTQ-DPjQClcM4inbD3xo Subject: Re: [sidr] A draft seeking guidance. 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, 24 Nov 2014 15:54:56 -0000 Terry + Leo, Sorry I didn't around to reviewing your doc sooner. here are some comments: 4.1: The suggestion that the RPKI needs to support different algorithms in different jurisdictions conflicts with RFC 6485. It is not consistent with the algorithm agility design in RFC 6916 (BCP 182), which assumes a single, system-wide alg suite. If one were to allow different algs on a per-jurisdiction basis, it would impose a burden on ALL clients, since all of them would have to support any alg adopted by any jurisdiction. I also note that Roque's observations about the GOST experience and DNSSEC argues against this approach. 4.2: I agree with Roque here too. The wording here seems a bit confusing, since 6916 already describes an alg transition mechanism, within which the GTA would be included. 5: again, I agree with Roque. Stay consistent with 6485, and plan on a key roll prior to 2030. 6.1: The wording here might confuse some readers. We have a spec for RPKI key rollover (RFC 6489). I suggest you mention it and explain that rollover of the GTA is not covered by that RFC, because of the special nature of a "root" CA. Then discuss the TAL (RFC 6490) and note that you see a need to update that spec to better support GTA key rollover. 7: I find the wording in this section a bit confusing. I agree with your observation that errors at the higher tiers of the hierarchy can have significant impact. But, as Roque noted, there is no notion of a system-wide cert/ROA validation checker. Validation is a distributed function, performed by each RP. I would expect any RP that detects a problem with its RPKI signed objects to notify its CA to have the problem remedied quickly. The Suspenders proposal (draft-kent-sidr-suspenders) calls for that behavior, and I would expect every RP to do that anyway. But, I agree that we should publish a doc that recommends such behavior by all RPs, including the RIRs as subordinate CAs under the GTA. I don't know if an automated procedure is needed to deal wtih this sort of problem, or if OOB means of contact, which may vary based on the CA, suffice. Steve From nobody Mon Nov 24 11:35:59 2014 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 122551A8944 for ; Mon, 24 Nov 2014 11:35:24 -0800 (PST) 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 UQqSCsh3UjYa for ; Mon, 24 Nov 2014 11:35:22 -0800 (PST) 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 DF8961A891A for ; Mon, 24 Nov 2014 11:35:21 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:58374 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XszPs-000OU6-Gg for sidr@ietf.org; Mon, 24 Nov 2014 14:35:20 -0500 Message-ID: <54738878.5030101@bbn.com> Date: Mon, 24 Nov 2014 14:35:20 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sidr@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/PuwqtvxWjOS3uD0nJkSFlbyqUZM Subject: Re: [sidr] New version : draft-ietf-sidr-bgpsec-protocol-10 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, 24 Nov 2014 19:35:24 -0000 Wes, To first order I agree with your concern of this DoS vulnerability, but with some minor clarifications. 1. BGPsec-signed updates are sent only between ASes that agree to send and receive (separate choices) this signed data. So, an attack of this sort is perpetrated only against an immediate neighbor that agrees to accept BGPsec traffic from you. You cannot send a BGPsec route to an arbitrary AS that it not configured for you as a neighbor. 2. As you noted, an AS can generate a path only for ASes that it holds, and thus, for which it holds private keys. So, a long path of the sort you describe is directly traceable to the resources holder, creating a "smoking gun" effect, for forensic purposes. If we can agree on a max path length, based on real world data, and RECOMMEND that routers enforce this limit, we can mitigate the ability of an AS to Dos it's neighbor (and others). That, combined with the ability to identify who added all of the questionable AS entries, might provide a deterrent to this behavior. Still, even with a max path length, there is the potential to add just a few, unnecessary ASes to every signed route that traverses an evil AS, to add to the burden of neighbors and those beyond. Given all the folks who track routing updates, this too will probably be noted by a bunch of folks, and because of the signatures, there will be no doubt about the source(s). So, here too, that may prove to be a deterrent. I believe someone at the meeting observed that smart implementations will try to address this sort of concern by postponing BGPsec crypto processing when resources get scarce. While I agree that this represents another attack vector, the ability to identify the perpetrators may diminish the attraction of this attack strategy. In any case, this is a good topic to address, perhaps in the BGPsec security considerations section, plus a separate document that suggests implementation notes. Steve From nobody Mon Nov 24 12:09:04 2014 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 D497E1A8BC1 for ; Mon, 24 Nov 2014 12:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 zf5JnPichRZc for ; Mon, 24 Nov 2014 12:08:57 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABCED1A8BB4 for ; Mon, 24 Nov 2014 12:08:53 -0800 (PST) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id sAOK8kGo008586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2014 14:08:46 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 09C2F1E0060; Mon, 24 Nov 2014 14:08:41 -0600 (CST) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id D947F1E004F; Mon, 24 Nov 2014 14:08:40 -0600 (CST) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id sAOK8edx021960; Mon, 24 Nov 2014 13:08:40 -0700 (MST) Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.ctl.intranet [151.119.128.28]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id sAOK8dlm021940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Nov 2014 13:08:40 -0700 (MST) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([2002:9777:801c::9777:801c]) with mapi id 14.03.0195.001; Mon, 24 Nov 2014 13:08:39 -0700 From: "Smith, Donald" To: Stephen Kent , "sidr@ietf.org" Thread-Topic: [sidr] New version : draft-ietf-sidr-bgpsec-protocol-10 Thread-Index: AQHP8j+pATNFn/KUqE2lQKcrwsWO0pxkeZEAgABhtYCAASDQgIAK0FMA//+TEvY= Date: Mon, 24 Nov 2014 20:08:39 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D24C2C7BA@PDDCWMBXEX503.ctl.intranet> References: ,<54738878.5030101@bbn.com> In-Reply-To: <54738878.5030101@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.70.40.131] Content-Type: multipart/alternative; boundary="_000_68EFACB32CF4464298EA2779B058889D24C2C7BAPDDCWMBXEX503ct_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/45SMl-QouauxzpBgd1PRuX099hs Subject: Re: [sidr] New version : draft-ietf-sidr-bgpsec-protocol-10 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, 24 Nov 2014 20:09:00 -0000 --_000_68EFACB32CF4464298EA2779B058889D24C2C7BAPDDCWMBXEX503ct_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Wouldn't GTSM and tcp-ao help with DOS attacks? I would recommend they be put in in the paragraph below. 7.3 Mitigation of Denial of Service Attacks BGPSEC speakers should implement an update validation algorithm that performs expensive checks (e.g., signature verification) after performing less expensive checks (e.g., syntax checks). The validation algorithm specified in Section 5.2 was chosen so as to perform checks which are likely to be expensive after checks that are likely to be inexpensive. https://tools.ietf.org/html/rfc5082 https://tools.ietf.org/html/rfc5925 As examples or recommendations for the "less expensive" checks. In fact it should be GTSM, tcp-ao THEN bgpsec validation. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com ________________________________ From: sidr [sidr-bounces@ietf.org] on behalf of Stephen Kent [kent@bbn.com] Sent: Monday, November 24, 2014 12:35 PM To: sidr@ietf.org Subject: Re: [sidr] New version : draft-ietf-sidr-bgpsec-protocol-10 Wes, To first order I agree with your concern of this DoS vulnerability, but with some minor clarifications. 1. BGPsec-signed updates are sent only between ASes that agree to send and receive (separate choices) this signed data. So, an attack of this sort is perpetrated only against an immediate neighbor that agrees to accept BGPsec traffic from you. You cannot send a BGPsec route to an arbitrary AS that it not configured for you as a neighbor. 2. As you noted, an AS can generate a path only for ASes that it holds, and thus, for which it holds private keys. So, a long path of the sort you describe is directly traceable to the resources holder, creating a "smoking gun" effect, for forensic purposes. If we can agree on a max path length, based on real world data, and RECOMMEND that routers enforce this limit, we can mitigate the ability of an AS to Dos it's neighbor (and others). That, combined with the ability to identify who added all of the questionable AS entries, might provide a deterrent to this behavior. Still, even with a max path length, there is the potential to add just a few, unnecessary ASes to every signed route that traverses an evil AS, to add to the burden of neighbors and those beyond. Given all the folks who track routing updates, this too will probably be noted by a bunch of folks, and because of the signatures, there will be no doubt about the source(s). So, here too, that may prove to be a deterrent. I believe someone at the meeting observed that smart implementations will try to address this sort of concern by postponing BGPsec crypto processing when resources get scarce. While I agree that this represents another attac= k vector, the ability to identify the perpetrators may diminish the attractio= n of this attack strategy. In any case, this is a good topic to address, perhaps in the BGPsec security considerations section, plus a separate document that suggests implementation notes. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. --_000_68EFACB32CF4464298EA2779B058889D24C2C7BAPDDCWMBXEX503ct_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Wouldn't GTSM and tcp-ao help with DOS attacks?

I would recommend they be put in in the paragraph below.

7.3 Mitigation of Denial of Service Attacks

BGPSEC speakers
   should implement an update validation algorithm that performs<= br>    expensive checks (e.g., signature verification) after performi= ng less
   expensive checks (e.g., syntax checks).  The validation a= lgorithm
   specified in Section 5.2 was chosen so as to perform checks which are
   likely to be expensive after checks that are likely to be
   inexpensive.

 

https://tools.ietf.org/h= tml/rfc5082

 

https://tools.ietf.org/h= tml/rfc5925

 

As examples or recommendations for the "less expensive" checks= .

 

In fact it should be GTSM, tcp-ao THEN bgpsec validation.

 

 

 

(coffee !=3D sleep) & (!coffee =3D=3D sleep)
 Donald.Smith@centuryl= ink.com
From: sidr [sidr-bounces@ietf.org] on beha= lf of Stephen Kent [kent@bbn.com]
Sent: Monday, November 24, 2014 12:35 PM
To: sidr@ietf.org
Subject: Re: [sidr] New version : draft-ietf-sidr-bgpsec-protocol-10=

Wes,

To first order I agree with your concern of this DoS vulnerability,
but with some minor clarifications.

1. BGPsec-signed updates are sent only between ASes that agree to
send and receive (separate choices) this signed data. So, an
attack of this sort is perpetrated only against an immediate neighbor
that agrees to accept BGPsec traffic from you. You cannot send
a BGPsec route to an arbitrary AS that it not configured for you
as a neighbor.

2. As you noted, an AS can generate a path only for ASes that it
holds, and thus, for which it holds private keys. So, a long path
of the sort you describe is directly traceable to the resources holder,
creating a "smoking gun" effect, for forensic purposes.

If we can agree on a max path length, based on real world data, and
RECOMMEND that routers enforce this limit, we can mitigate the
ability of an AS to Dos it's neighbor (and others). That, combined with
the ability to identify who added all of the questionable AS entries,
might provide a deterrent to this behavior.

Still, even with a max path length, there is the potential to add just a few,
unnecessary ASes to every signed route that traverses an evil AS, to add to=
the burden of neighbors and those beyond. Given all the folks who track
routing updates, this too will probably be noted by a bunch of folks, and because of the signatures, there will be no doubt about the source(s). So,<= br> here too, that may prove to be a deterrent.

I believe someone at the meeting observed that smart implementations will try to address this sort of concern by postponing BGPsec crypto processing<= br> when resources get scarce. While I agree that this represents another attac= k
vector, the ability to identify the perpetrators may diminish the attractio= n
of this attack strategy.

In any case, this is a good topic to address, perhaps in the BGPsec
security considerations section, plus a separate document that suggests
implementation notes.

Steve

_______________________________________________
sidr mailing list
sidr@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sidr
This communication is the property of CenturyLink and may contain c= onfidential or privileged information. Unauthorized use of this communicati= on is strictly prohibited and may be unlawful. If you have received this co= mmunication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communicat= ion and any attachments.
--_000_68EFACB32CF4464298EA2779B058889D24C2C7BAPDDCWMBXEX503ct_-- From nobody Wed Nov 26 08:44:49 2014 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 843CD1A03A7; Wed, 26 Nov 2014 08:44:44 -0800 (PST) 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 Kyj5J8Lw_PX7; Wed, 26 Nov 2014 08:44:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDC91A0118; Wed, 26 Nov 2014 08:44:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141126164443.26069.29089.idtracker@ietfa.amsl.com> Date: Wed, 26 Nov 2014 08:44:43 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/b9niKlmaJ-zH1kMXWs6Ag9KYYi8 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpsl-sig-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: Wed, 26 Nov 2014 16:44:44 -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 : Securing RPSL Objects with RPKI Signatures Authors : Robert Kisteleki Brian Haberman Filename : draft-ietf-sidr-rpsl-sig-06.txt Pages : 14 Date : 2014-11-26 Abstract: This document describes a method to allow parties to electronically sign RPSL-like objects and validate such electronic signatures. This allows relying parties to detect accidental or malicious modifications on such objects. It also allows parties who run Internet Routing Registries or similar databases, but do not yet have RPSS-like authentication of the maintainers of certain objects, to verify that the additions or modifications of such database objects are done by the legitimate holder(s) of the Internet resources mentioned in those objects. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rpsl-sig-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpsl-sig-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 Wed Nov 26 08:51:40 2014 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 653D71A0118 for ; Wed, 26 Nov 2014 08:51:38 -0800 (PST) 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 aOvU3j1rYu6q for ; Wed, 26 Nov 2014 08:51:37 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA28B1A0149 for ; Wed, 26 Nov 2014 08:51:36 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id BFA3E88122 for ; Wed, 26 Nov 2014 08:51:36 -0800 (PST) Received: from clemson.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 791A6136821B for ; Wed, 26 Nov 2014 08:51:36 -0800 (PST) Message-ID: <54760513.2050709@innovationslab.net> Date: Wed, 26 Nov 2014 11:51:31 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sidr@ietf.org References: <20141126164443.26069.29089.idtracker@ietfa.amsl.com> In-Reply-To: <20141126164443.26069.29089.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KdImFdd6pGiLSMdjgh9x1GDUH1itgFA3P" Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/VZ4AJB_dV5B5-cPTQl2-m-fjQPw Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpsl-sig-06.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, 26 Nov 2014 16:51:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KdImFdd6pGiLSMdjgh9x1GDUH1itgFA3P Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All, Robert and I have found the time/energy to push this work to completion. This version does not contain any substantive updates from the -05, I simply got this version out to allow for discussion on it to resume. One question that I would like to discuss is the currently optional "o" attribute. Robert feels it is not needed if the "c" attribute references a RFC 3779-compliant certificate. I feel that the flexibility of having multiple signatures allows for instances where different parties own, for example, the prefix being advertised and the ASN. I would appreciate feedback on this issue. A follow-on version will address comments raised previously on the document. Regards, Brian On 11/26/14 11:44 AM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. >=20 > Title : Securing RPSL Objects with RPKI Signatures > Authors : Robert Kisteleki > Brian Haberman > Filename : draft-ietf-sidr-rpsl-sig-06.txt > Pages : 14 > Date : 2014-11-26 >=20 > Abstract: > This document describes a method to allow parties to electronically > sign RPSL-like objects and validate such electronic signatures. Thi= s > allows relying parties to detect accidental or malicious > modifications on such objects. It also allows parties who run > Internet Routing Registries or similar databases, but do not yet hav= e > RPSS-like authentication of the maintainers of certain objects, to > verify that the additions or modifications of such database objects > are done by the legitimate holder(s) of the Internet resources > mentioned in those objects. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-rpsl-sig-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rpsl-sig-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of submi= ssion > 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 --KdImFdd6pGiLSMdjgh9x1GDUH1itgFA3P 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.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUdgUZAAoJEBOZRqCi7goqpREH/2dpXQCjI1fyS0Hd6XtrOvMV zcY3MCVYbntvSSpkHb8fwe4+pjgx9Xd9oNFbmA9GmP0uh8CTIMeWMyEvhWEuSl5b Bq3+ykSuhCy3yekIeOet/YEhdrW95rROvABBRb9anlIkQgOgGzIzyowjT0WWpOwz 5p1ZIBj/pXhIyWCEKRkeDgMLHX2FLk6CeI7ZorFfatVoU5HW9ztA2g5K3FNXmbKn GTIkDaW+Fv+avBNjNoJhgMM6JknjPVuiMOh4sh0zOgX8OlkUbRcFRxO/ntF22OYE zTICZfpOcJxft4Cqpr34KYVbPDRYoeKyHiBvfcT4Wh1brRl4L58lUiuhZ1E12HM= =BlTU -----END PGP SIGNATURE----- --KdImFdd6pGiLSMdjgh9x1GDUH1itgFA3P-- From nobody Fri Nov 28 02:06:35 2014 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 E30941A1AA2 for ; Fri, 28 Nov 2014 02:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.161 X-Spam-Level: X-Spam-Status: No, score=-1.161 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, 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 oQfNpbrZz2Cp for ; Fri, 28 Nov 2014 02:06:32 -0800 (PST) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3DB91A1ADB for ; Fri, 28 Nov 2014 02:06:31 -0800 (PST) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) for sidr@ietf.org with esmtp (envelope-from ) id <1XuIRZ-001N80-Sa>; Fri, 28 Nov 2014 11:06:29 +0100 Received: from g231104081.adsl.alicedsl.de ([92.231.104.81] helo=mw-PC.fritz.box) by inpost2.zedat.fu-berlin.de (Exim 4.82) for sidr@ietf.org with esmtpsa (envelope-from ) id <1XuIRZ-003m2T-PN>; Fri, 28 Nov 2014 11:06:29 +0100 Date: Fri, 28 Nov 2014 11:06:14 +0100 From: Matthias Waehlisch To: sidr@ietf.org Message-ID: User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) X-X-Sender: waehl@mail.zedat.fu-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Originating-IP: 92.231.104.81 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/xB-p6s1nYXvfr5hxIf6y4337EP4 Subject: [sidr] Call for input: RPKI Browser 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, 28 Nov 2014 10:06:34 -0000 Hi, we started with the development of a browser that provides a graphical user interface to the objects of the distributed RPKI repository. A very preliminary version is available here http://rpki-browser.realmv6.org/. As we think such a tool could be useful for the community, we are asking for input at a very early stage. Please let me know which features you would like to see in such kind of tool. Some more details are described here https://labs.ripe.net/Members/waehlisch/call-for-input-rpki-browser Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From nobody Fri Nov 28 06:04:27 2014 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 2A7FF1A1A6D for ; Fri, 28 Nov 2014 06:04:25 -0800 (PST) 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 mTsuATbVm2VW for ; Fri, 28 Nov 2014 06:04:22 -0800 (PST) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE551A1ACE for ; Fri, 28 Nov 2014 06:04:22 -0800 (PST) Received: by mail-qc0-f177.google.com with SMTP id x3so4770380qcv.22 for ; Fri, 28 Nov 2014 06:04:21 -0800 (PST) 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:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=wQN/JQlSTdshnCOGjviAVRXUxSeWdHCyE7GN/opN5kY=; b=amuAvS3awbaooS1ut7HrrLoR1FbEd9V1sltJbKCTtskDm8jEh4PN8Ke3oPbRVruysr m1ICBw/Fvx7cVcKbzW5+Bk6K58lqk6PQcsw/M3pS6aAWHLrNpdjjwMYQ+vYZx1VramMU lVEw/rfT3/Oh1O03ZZSj9c01ZoJnY2bpcyf2hjJSjspyo6o1Dtqhq58HgtBisTcDE8cy gE6tjIDqUe2bewhuLMj7wBjCFSwb7xdOlLjcozsR7xa0lMdDsm5K+9I346bIekIXwaSE Iew2wDqDVVo1VSsvkFEu0BmC+zaQGBXMlZ382r/0xiGH2Dj4OJ9cySh09t7irswGRryM gibQ== X-Received: by 10.140.84.111 with SMTP id k102mr7248911qgd.76.1417183461831; Fri, 28 Nov 2014 06:04:21 -0800 (PST) Received: from europa.local ([2001:13c7:7001:7000:2d51:cf18:a5c2:1ff7]) by mx.google.com with ESMTPSA id w75sm9263798qgd.14.2014.11.28.06.04.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Nov 2014 06:04:20 -0800 (PST) Message-ID: <547880E1.90800@gmail.com> Date: Fri, 28 Nov 2014 12:04:17 -0200 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Matthias Waehlisch , sidr@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/jZpXblSOoYqd7cXZQ2IzWLFzRV8 Subject: Re: [sidr] Call for input: RPKI Browser 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: Fri, 28 Nov 2014 14:04:25 -0000 Hi Matthias, We indeed believe that such a tools is badly needed. We created something that provides some similar features, but it is definitely less mature than yours. http://tools.labs.lacnic.net/visor/set You can navigate through the hierarchy but you have to click through the manifests. But it works, and has proven *very* useful. One feature that perhaps your tool could use is the ability to either upload a cert and/or point the browser to a specific URI, so you can browse non-production or non-official repos. regards -Carlos On 11/28/14 8:06 AM, Matthias Waehlisch wrote: > Hi, > > we started with the development of a browser that provides a graphical > user interface to the objects of the distributed RPKI repository. A very > preliminary version is available here http://rpki-browser.realmv6.org/. > > As we think such a tool could be useful for the community, we are > asking for input at a very early stage. Please let me know which > features you would like to see in such kind of tool. > > Some more details are described here > https://labs.ripe.net/Members/waehlisch/call-for-input-rpki-browser > > > > Thanks > matthias > From nobody Fri Nov 28 06:40:06 2014 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 CE99D1A1B6C for ; Fri, 28 Nov 2014 06:40:01 -0800 (PST) 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 UqXA2KqWlcd1 for ; Fri, 28 Nov 2014 06:39:58 -0800 (PST) Received: from koko.ripe.net (koko.ripe.net [IPv6:2001:67c:2e8:11::c100:1348]) (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 C32B31A1B42 for ; Fri, 28 Nov 2014 06:39:58 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XuMi9-0001QR-Pz; Fri, 28 Nov 2014 15:39:55 +0100 Received: from tel-sslvpn-1.ripe.net ([193.0.20.232] helo=vpn-232.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1XuMi9-0005Ck-Mz; Fri, 28 Nov 2014 15:39:53 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Tim Bruijnzeels In-Reply-To: Date: Fri, 28 Nov 2014 15:39:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3849CC4E-C34D-49EF-8F81-047FFD7DF599@ripe.net> References: To: Matthias Waehlisch X-Mailer: Apple Mail (2.1878.6) X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071977eb913e6956229ce9ea56c2ddb0bfb0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/42d6M2oWrsjIWotS0xdt9rRr7Mw Cc: sidr@ietf.org Subject: Re: [sidr] Call for input: RPKI Browser 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, 28 Nov 2014 14:40:02 -0000 Hi Matthias, We have been thinking of building a similar graphical UI for browsing = the RPKI tree into our validator, but we haven=92t had the time to work = on it so-far, and we have quite a few other things to work on as well. = What is your future plan with this? Are you planning to provide this as = a service, or do you envision this is a tool that people can run = locally? Is it open source? I like the initiative and I think it=92s a useful concept. I played with = the filter to search for a resource, and I would like to suggest that if = I search for example for a prefix that maybe I should also see more = specific matches. For example if I now search for 84.205.80.0/19 I see = the certificate issued to RIPE NCC operations, but it doesn=92t show the = ROA for 84.205.80.0/24. Cheers Tim On 28 Nov 2014, at 11:06, Matthias Waehlisch = wrote: > Hi, >=20 > we started with the development of a browser that provides a = graphical=20 > user interface to the objects of the distributed RPKI repository. A = very=20 > preliminary version is available here = http://rpki-browser.realmv6.org/. >=20 > As we think such a tool could be useful for the community, we are=20 > asking for input at a very early stage. Please let me know which=20 > features you would like to see in such kind of tool. >=20 > Some more details are described here=20 > https://labs.ripe.net/Members/waehlisch/call-for-input-rpki-browser >=20 >=20 >=20 > Thanks > matthias >=20 > --=20 > Matthias Waehlisch > . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST > . Takustr. 9, D-14195 Berlin, Germany > .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl > :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr