From nobody Tue Jul 1 04:36: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 C33321A007D for ; Tue, 1 Jul 2014 04:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 7oVt5qC0YBdK for ; Tue, 1 Jul 2014 04:36:26 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 928AC1A0076 for ; Tue, 1 Jul 2014 04:36:26 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 4F8C128B0040; Tue, 1 Jul 2014 07:36:26 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 2657D1F8032; Tue, 1 Jul 2014 07:36:26 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_FF11D860-094C-4AFD-B3D2-DB67413269FC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: Date: Tue, 1 Jul 2014 07:36:25 -0400 Message-Id: References: <75C51A68-FEC3-40B0-BC6C-A8A2471FF4CD@tislabs.com> To: Randy Bush X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/Hyv5ownTL9CJNDq_T8UyeWVQwYo Cc: sidr wg list , Sandra Murphy Subject: Re: [sidr] about the thread "Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487" 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, 01 Jul 2014 11:36:27 -0000 --Apple-Mail=_FF11D860-094C-4AFD-B3D2-DB67413269FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 30, 2014, at 6:09 PM, Sandra Murphy wrote: >=20 > So we need to come up with a way to get the AS number to the CA, also. >=20 To continue this thought=85 There's a list in RFC6487 of the certificate extensions that are allowed = in the PKCS#10 request. Is there any reason why we could not just include the AS Resources = extension in the list of allowed extensions in the/a PKCS#10 request? = AS Resources is a list, which is what is needed. =20 Would that be the right authority relationship? (the router is the = authority for saying what AS(ASs) the router uses?) --Sandy --Apple-Mail=_FF11D860-094C-4AFD-B3D2-DB67413269FC 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 iQIcBAEBCgAGBQJTsp05AAoJEHplpQeet0IZOVQQAIxSyfXhlfSfq/fVJutOTmWx FpjLCYeA5QvGWy+abV6s5cNwOEUE3ImGhlUlXQwZesVPu+xOjY9lzlLIakiH5+TM jp7ef9hz57hC6eUNQ7aE7VlpdDHhTlG+UBZiD1XmnRqhT6meK7Wazr7m7DDaaBO4 10qLDL1y2f6BOjOtag6lNwUn2luDlaGuvC9RFr03PLQ2Kp4z22QNdSxIwlmE553X gTRtILpxyy2yl/YVgWSbJo6iTMSADO8AFUZMn6L/LkqsC/blcjK3ipYn0aJBljYi O1YmPJqH0xVKAiLLt3FHA17lK1WZuPyP1EnR2E803ikBVO9Shh19J/oWQRaoNIvw t9GahxOEt6U4CLJRR8McLe4OsiHTerioH39O09pxzxDBIMLJnLSFLxrCVfYELTJA mqyMUK8jY/YkiUGmQW+HBDXWEMLfIbpNglrALFlDmY36t90RPpIgc5v2PJx3zwq1 zUAiEE4GG8oGgCcshwBzJkFSupXPtjxX17DafMKWz6VrG0WFOo5jpUwvnwmnst4d YGisoJgqaFdgwgOj2Fe44M8SLV16RPihrhx2SR4SRHL7eF4e64eU4TcUTsaQ2N4d kiqj9iqIqeJmrZTHQ+N1SbKiZ82xeI8cO9y8WWI4A51c6C7kIt6ko3hxCKyMvWQP eHCD+/OC3IPxuTQJPH0M =Oge4 -----END PGP SIGNATURE----- --Apple-Mail=_FF11D860-094C-4AFD-B3D2-DB67413269FC-- From nobody Tue Jul 1 08:56:48 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 A7F4A1A0367 for ; Tue, 1 Jul 2014 08:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 zsbC0yk_iGGt for ; Tue, 1 Jul 2014 08:56:45 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5C601A0515 for ; Tue, 1 Jul 2014 08:56:44 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:53698) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X20QS-000H7h-3B for sidr@ietf.org; Tue, 01 Jul 2014 11:56:56 -0400 Message-ID: <53B2DA30.7060602@bbn.com> Date: Tue, 01 Jul 2014 11:56:32 -0400 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: <75C51A68-FEC3-40B0-BC6C-A8A2471FF4CD@tislabs.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/q700Y94b7l-3dn5IhtVOXW4YJRg Subject: Re: [sidr] about the thread "Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487" 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, 01 Jul 2014 15:56:46 -0000 Sandy, > On Jun 30, 2014, at 6:09 PM, Sandra Murphy wrote: > >> So we need to come up with a way to get the AS number to the CA, also. >> > To continue this thought… > > There's a list in RFC6487 of the certificate extensions that are allowed in the PKCS#10 request. > > Is there any reason why we could not just include the AS Resources extension in the list of allowed extensions in the/a PKCS#10 request? AS Resources is a list, which is what is needed. > > Would that be the right authority relationship? (the router is the authority for saying what AS(ASs) the router uses? I would not say that the router is the authority; the operator is the authority, and the operator should be controlling the CA. Still, the router could include the AS list in the request, and the CA could filter it to match it's config database. Steve From nobody Tue Jul 1 09:02:52 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 CEDF31B283D for ; Tue, 1 Jul 2014 09:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 AcVmhd8BOlFc for ; Tue, 1 Jul 2014 09:02:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46D821B283A for ; Tue, 1 Jul 2014 09:02:40 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:53699) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X20WB-000HAs-VJ for sidr@ietf.org; Tue, 01 Jul 2014 12:02:52 -0400 Message-ID: <53B2DB9E.9000107@bbn.com> Date: Tue, 01 Jul 2014 12:02:38 -0400 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: <75C51A68-FEC3-40B0-BC6C-A8A2471FF4CD@tislabs.com> 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/h6DpQWVW2qKR-a8EaJSq-7NFdPY Subject: Re: [sidr] about the thread "Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487" 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, 01 Jul 2014 16:02:47 -0000 Sandy, > On Jun 27, 2014, at 8:53 PM, Randy Bush wrote: > >> [ you omitted the as number in your discussion, but ca needs a so it >> knows which AS signs. luckily bgpsec-pki-profiles does have it in the >> pkcs#10 subject ] > That's a good point. > > Actually, bgpsec-pki-profiles does NOT have it in the PKCS#10 subject. > > bgpsec-pki-profiles gives a list of exceptions to the PKCS#10 defined in RFC6487, but the exceptions do not include the AS number. > > I had forgotten (if I ever noted) that the PKCS#10 profile in RFC6487 does not include the number resources. > > So we need to come up with a way to get the AS number to the CA, also. Thinking about this some more: note that a CA generally needs to have some way of linking a cert request to a specific entity, person or thing. In this context, the router needs to be known to the CA when the request is made. So, if the router is registered in a database accessible to the CA, that database should contain the AS # that the router is authorized to represent. Having the router propose an AS# is OK too, but the CA is authoritative. Steve From nobody Tue Jul 1 10:07:10 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 47D451A03BB for ; Tue, 1 Jul 2014 10:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 W5pSQGWpqA-a for ; Tue, 1 Jul 2014 10:07:01 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC51C1B287B for ; Tue, 1 Jul 2014 10:06:57 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:54436) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X21WP-000HeG-11 for sidr@ietf.org; Tue, 01 Jul 2014 13:07:09 -0400 Message-ID: <53B2EAAB.1080109@bbn.com> Date: Tue, 01 Jul 2014 13:06:51 -0400 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 Content-Type: multipart/alternative; boundary="------------080100070004070205040102" Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/SkMR7rwNF-yG5WUPkwLBDM5tk1k Subject: [sidr] draft-ietf-sidr-lta-use-cases-01 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, 01 Jul 2014 17:07:05 -0000 This is a multi-part message in MIME format. --------------080100070004070205040102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I appreciate the changes Randy made to the -00 version of this doc. However, I have a few concerns about the current version. The end of Section 3 states: For the purposes of this exploration, we refer to this localized view as a 'Local Trust Anchor', mostly for historical reasons, but also because implementation would likely be the local distribution of one or more specialized trust anchors, [RFC6481]. Since this is supposed to be a requirements (aka use cases) doc, we ought not prejudice the doc by presuming how the requirements will be satisfied. Also, there are two docs that, together, probably address the requirements I think we are trying to characterize, and they do not rely on the LTA model that was proposed long ago. Section 4 is a set of folksy, almost parable-style examples. I think the doc should provide clear definitions of the requirements, not examples from which the reader is expected to extract the underlying requirements. Examples are fine as ways to help illustrate a requirement, but are not a substitute for a clear statement of a requirement. I offered re-worded examples in response to the -00 version of the use cases doc. They try to avoid extraneous comments and use very simple text (see below). Still, they were just examples based on Randy's -00 text. I suggest we try to develop simple, clear requirements statements that align with the examples Randy and I have offered. Section 5 correctly notes that what we are trying to "fix" are ROAs, not certs. But, if we are to avoid pre-judging solutions, we ought to remove the discussion of the need to modify Resource certs, GB records, etc. Steve ----- Case 1: ISP C find that its CA certificate has been be revoked (or modified to removed resources) by the RIR (or ISP) that issued it. ISP C believes that this revocation was either an error by RIR staff, or that the RIR has been compelled to revoke the certificate by a law enforcement agency in the jurisdiction where the RIR operates. ISP C would like other ISPs to be able to ignore the certificate revocation (or modification), at their discretion. Case 1 also encompasses a larger case, e.g., when all of the ISPs with a country require protection for an RIR action of this sort, coordinated at a national level. We cannot assume that the country operates an NIR. Case 2: ISP B makes use of private address space (RFC 1918) or makes use of address space allocated to some other party , but which is not announced globally). ISP B makes use of the RPKI internally, as well as for global routing. ISP B would like its use of private address space to work internally with routers that make use of RPKI data. Case 3: An organization, A, is authorized to control routing of traffic from a set of ISPs to the rest of the Internet. (For example, A may want traffic to selected addresses to be redirected to other addresses, or be dropped.)Because these ISPs want to use the RPKI, A needs a way to coordinate their use of the RPKI (insupport of A's traffic management goal). --------------080100070004070205040102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I appreciate the changes Randy made to the -00 version of this doc.

However, I have a few concerns about the current version.

The end of Section 3 states:
   For the purposes of this exploration, we refer to this localized view
   as a 'Local Trust Anchor', mostly for historical reasons, but also
   because implementation would likely be the local distribution of one
   or more specialized trust anchors, [RFC6481].

Since this is supposed to be a requirements (aka use cases) doc, we ought
not prejudice the doc by presuming how the requirements will be satisfied.
Also, there are two docs that, together, probably address the requirements
I think we are trying to characterize, and they do not rely on the LTA model
that was proposed long ago.

Section 4 is a set of folksy, almost parable-style examples. I think the doc should
provide clear definitions of the requirements, not examples from which the reader
is expected to extract the underlying requirements.  Examples are fine as ways to
help illustrate a requirement, but are not a substitute for a clear statement
of a requirement.

I offered re-worded examples in response to the -00 version of the use cases doc.
They try to avoid extraneous comments and use very simple text (see below). Still,
they were just examples based on Randy's -00 text. I suggest we try to develop simple,
clear requirements statements that align with the examples Randy and I have offered.

Section 5 correctly notes that what we are trying to "fix" are ROAs, not certs. But,
if we are to avoid pre-judging solutions, we ought to remove the discussion of the
need to modify Resource certs, GB  records, etc.


Steve
-----

Case 1:

ISP C find that its CA certificate has been be revoked (or modified to removed resources) by the RIR (or ISP) that issued it. ISP C believes that this revocation was either an error by RIR staff, or that the RIR has been compelled to revoke the certificate by a law enforcement agency in the jurisdiction where the RIR operates. ISP C would like other ISPs to be able to ignore the certificate revocation (or modification), at their discretion.

Case 1 also encompasses a larger case, e.g., when all of the ISPs with a country require protection for an RIR action of this sort, coordinated at a national level. We cannot assume that the country operates an NIR.

 

Case 2:

ISP B makes use of private address space (RFC 1918) or makes use of address space allocated to some other party , but which is not announced globally). ISP B makes use of the RPKI internally, as well as for global routing. ISP B would like its use of private address space to work internally with routers that make use of RPKI data.

 

Case 3:

An organization, A, is authorized to control routing of traffic from a set of ISPs to the rest of the Internet. (For example, A may want traffic to selected addresses to be redirected to other addresses, or be dropped.)  Because these ISPs want to use the RPKI, A needs a way to coordinate their use of the RPKI (in  support of A’s traffic management goal).

--------------080100070004070205040102-- From nobody Tue Jul 1 15:29:52 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 AF3F41A0ABC for ; Tue, 1 Jul 2014 15:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 P14JeCdZTB2O for ; Tue, 1 Jul 2014 15:29:49 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57FE61A0ABA for ; Tue, 1 Jul 2014 15:29:49 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-50-189-40-138.hsd1.ma.comcast.net [50.189.40.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 09BE239824 for ; Tue, 1 Jul 2014 22:29:49 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 5E0D5F43767 for ; Tue, 1 Jul 2014 18:29:48 -0400 (EDT) Date: Tue, 01 Jul 2014 18:29:48 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <75C51A68-FEC3-40B0-BC6C-A8A2471FF4CD@tislabs.com> References: <75C51A68-FEC3-40B0-BC6C-A8A2471FF4CD@tislabs.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20140701222948.5E0D5F43767@minas-ithil.hactrn.net> Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/DMa97Z0z1_IrZqfdoIRosqAy0gE Subject: Re: [sidr] about the thread "Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487" 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, 01 Jul 2014 22:29:50 -0000 At Fri, 27 Jun 2014 16:50:12 -0400, Sandra Murphy wrote: > > RFC6487 6.1.1 (how to send a cert request in PKCS) says > > Subject > This field MAY be omitted. If present, the value of this field > SHOULD be empty (i.e., NULL), in which case the CA MUST > generate a subject name that is unique in the context of > certificates issued by this CA. > > a) "This field MAY be omitted." is wrong. PKCS#10 does not say that > the subject field is optional. So an implementation that did > omit this field might not work with a CA's implementation. Right. I think it's reasonably clear that, on this point, RFC 6487 just needs to be fixed, as it violates the base specification. > b) "If present, the value of this field SHOULD be empty" means that > the rtr-keying draft was (at the time) non-compliant - rtr-keying > said to put the "router number" in the subject field of a PKCS#10 > cert request. > > The bgpsec-pki-profile draft says that the subject of a router cert > has the router ID in it. [...] I think the simplest approach is to allow router key PKCS #10 requests to include both the router id and the ASN(s). The need to support multiple ASNs (rare, but possible, if I understand correctly) means that we can't just use the subject name hack for this, since the proposed encoding of router ID and ASN into the subject name only supports one ASN. So I think we should: - Allow a non-empty subject name in the router certificate PKCS #10, said name to follow whatever we pick for the recommended form of the expected resulting certificate (ROUTER-, or whatever), where the here is usually the one-and-only ASN but, if there's more than one, is whichever ASN seems good to the router operator. - Allow the ASIdentifiers extension in the router certificate PKCS #10. I don't particularly care whether we require this to be present in all cases or only in the multi-ASN case, but if it is present at all, the ASN encoded in the subject name MUST also be listed in the ASIdentifiers extension. The CA, of course, is free to reject this PKCS #10, or issue a certificate using the public key from the PKCS #10, a different subject name than proposed in the PKCS #10, or only certify a subset of the ASNs requested in the PKCS #10. Final decision on what to certify remains with the CA, the PKCS #10 is just a mechanism for conveying data to the CA in a tidy package. Note that the multi-ASN case could be construed as an argument for dropping the ASN out of the router certificate name entirely, or perhaps only dropping the ASN out of the name when dealing with a multi-ASN certificate. I have no strong feelings on the matter. I do not particularly care whether the PKCS #10 profile for router certificates is based on RFC 6487 or is a free-standing document; whichever is easiest to get right in a reasonable period of time. From nobody Tue Jul 1 15:34:24 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 1B94B1A0ABD for ; Tue, 1 Jul 2014 15:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 BZM-Y-4gnTN9 for ; Tue, 1 Jul 2014 15:34:20 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E36221A03FD for ; Tue, 1 Jul 2014 15:34:19 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-50-189-40-138.hsd1.ma.comcast.net [50.189.40.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id A2B9039824 for ; Tue, 1 Jul 2014 22:34:19 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 3E6B9F4380E for ; Tue, 1 Jul 2014 18:34:19 -0400 (EDT) Date: Tue, 01 Jul 2014 18:34:19 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <53B181C7.4000701@bbn.com> References: <75C51A68-FEC3-40B0-BC6C-A8A2471FF4CD@tislabs.com> <53B181C7.4000701@bbn.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20140701223419.3E6B9F4380E@minas-ithil.hactrn.net> Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/VRo2ZtVQ6GuFQ14-nwnYcCAsb_0 Subject: [sidr] EST (was Re: about the thread "Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487") 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, 01 Jul 2014 22:34:21 -0000 At Mon, 30 Jun 2014 11:27:03 -0400, Stephen Kent wrote: > > I did suggest we might use other cert request mechanisms. EST is the > obvious, current, standards-based option for this, if folks want to > consider alternatives to PKCS#10. Since it was authored by a Cisco > guy, there is some chance it might become available in their > routers. I would suggest this path only for router certs, not for > the RPKI certs. That might make it unpalatable, as a CA operated by > an ISP would have to deal with two cert request formats: PKCS#1- for > child CA certs (if the ISP is not a stub in the RPKI tree) and EST > for router certs. Is there any real benefit to EST, given that we already have to support PKCS #10 and given that PKCS #10 implementations are almost certainly easier to find than EST implementations? Absent some serious advantage that I'm not seeing, this doesn't seem particularly attractive. > I'm just pointing out options. Understood. From nobody Tue Jul 1 18:27:21 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 08F271B27AE; Tue, 1 Jul 2014 18:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oY7J6pFGSSFL; Tue, 1 Jul 2014 18:27:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 037911B27A5; Tue, 1 Jul 2014 18:27:17 -0700 (PDT) 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.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> Date: Tue, 01 Jul 2014 18:27:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/VQDGQjL6AcP4MopHVP0wd_Aaf5U Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.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, 02 Jul 2014 01:27:18 -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 : RPKI Validation Reconsidered Authors : Geoff Huston George Michaelson Carlos M. Martinez Tim Bruijnzeels Andrew Lee Newton Alain Aina Filename : draft-ietf-sidr-rpki-validation-reconsidered-00.txt Pages : 10 Date : 2014-07-01 Abstract: This document reviews the certificate validation procedure specified in RFC6487 and highlights aspects of potentially acute operational fragility in the management of certificates in the RPKI in response to the movement of resources across registries, and the associated actions of Certification Authorities to maintain continuity of validation of certification of resources during this movement. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rpki-validation-reconsidered-00 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 Tue Jul 1 18:43:39 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 CB6391B27B2 for ; Tue, 1 Jul 2014 18:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 vPQvuyZC6UuD for ; Tue, 1 Jul 2014 18:43:35 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 69B381B27AA for ; Tue, 1 Jul 2014 18:43:35 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id E00DA28B0017 for ; Tue, 1 Jul 2014 21:43:34 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id D913E1F8032; Tue, 1 Jul 2014 21:43:34 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_44F94A88-D6BF-43C2-8B9D-55BF063D4329"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <62267045-56C3-4141-AE84-6A7696FCBE4E@tislabs.com> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Tue, 1 Jul 2014 21:43:34 -0400 References: <20140701190543.12535.86367.idtracker@ietfa.amsl.com> To: sidr wg list X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/iNJT_hrhQW2nyHiNR_couVtPg_o Cc: Sandra Murphy Subject: [sidr] Fwd: IETF 90 Final Agenda 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, 02 Jul 2014 01:43:37 -0000 --Apple-Mail=_44F94A88-D6BF-43C2-8B9D-55BF063D4329 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The final agenda has been announced and sidr meets Friday morning. FRIDAY, July 25, 2014 0900-1130 Morning Session I Territories (MM) RTG sidr Secure Inter-Domain = Routing WG --Sandy Begin forwarded message: > From: IETF Agenda > Subject: IETF 90 Final Agenda > Date: July 1, 2014 3:05:43 PM EDT > To: IETF Announcement List > Cc: ietf@ietf.org > Reply-To: IETF Agenda >=20 >=20 > 90th IETF Meeting - Toronto, ON, Canada > July 20 - 25, 2014 >=20 > The final agenda is now available. >=20 > https://datatracker.ietf.org/meeting/90/agenda.html > https://datatracker.ietf.org/meeting/90/agenda.txt >=20 > While this is considered the final agenda for printing, changes may be = made to the agenda up until and during the meeting. Updates will be = reflected on the web version of the agenda.=20 >=20 > Information about the 90th IETF meeting in Toronto, ON, Canada can be = found here: https://www.ietf.org/meeting/90/index.html >=20 > Thank you and see you in Toronto! >=20 > Sincerely, >=20 > The IETF Secretariat --Apple-Mail=_44F94A88-D6BF-43C2-8B9D-55BF063D4329 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 iQIcBAEBCgAGBQJTs2PGAAoJEHplpQeet0IZbVsP/17TBFoOQW7g2ZRuaMssJtvI oESe7Dsecxi1DNOnvFKTYt8SwVNqIQ4H9W8/r5yeYgDNJg3qMwxBVCttuz6r+CLb IVjhgUtf5iio1BL2N9yVU7UNIIbHaQIM0K+dXjmNzKMA3n8KTbYp34aWHjzDDlsG htY3ANWijPHDMwEbhpm9Zzh5Ef29/gBHz/jmBVIzvlnEH3SbOrVEojavjUnZaYLD diJaiW3OqttsQ2MudRHacj33CqfWnO8e0ISuNx5zwG139qkCyCFIS2c/loZsKELf 3Tnvh9+okgFPq8MqNRDUWPpSrZeUtFv64sRvlBnexYE8zWRJ662zBG8ZA27qA650 +s8tkvXuf7I/5pRyATnvpU5lUMF6/sfWB57hWV1Dv6yrYkW2IlukKwhOPFqhIbxk gcWuZAbb9Vk/lgd8w32MVqG0DWhHDcNj+8VNMmIXll7SM0jx15IP8JXQboX3k8JZ AVHWfGhmccRj3H1FDkBvu3pnBps9c3TO8tQ+TXIOda6Ijh/nnd0lbzPCWO8BB15R gUO36iWcO6a4f3Pu7dJl94orE4CxGwJHxDhtV9h43upIG/MHRCuyXBFNlURjfxjA tz7EvF8iUEBzIWSIUqc+xL2WoAqebF2CyL8K63OTIUfS0KrfBxxzWz1CpMxE/CI0 RW/64plimEO9TTzKE105 =wQlR -----END PGP SIGNATURE----- --Apple-Mail=_44F94A88-D6BF-43C2-8B9D-55BF063D4329-- From nobody Wed Jul 2 07:00: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 3E68B1A0113 for ; Wed, 2 Jul 2014 07:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 3LFJa6xZTRVp for ; Wed, 2 Jul 2014 07:00:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1A161A00E8 for ; Wed, 2 Jul 2014 07:00:17 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:55422 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X2L5J-0001pU-NW for sidr@ietf.org; Wed, 02 Jul 2014 10:00:29 -0400 Message-ID: <53B41070.7040902@bbn.com> Date: Wed, 02 Jul 2014 10:00:16 -0400 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: <75C51A68-FEC3-40B0-BC6C-A8A2471FF4CD@tislabs.com> <53B181C7.4000701@bbn.com> <20140701223419.3E6B9F4380E@minas-ithil.hactrn.net> In-Reply-To: <20140701223419.3E6B9F4380E@minas-ithil.hactrn.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/09HSym77QxUOvU4PP7ifkycqOzY Subject: Re: [sidr] EST (was Re: about the thread "Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487") 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, 02 Jul 2014 14:00:27 -0000 Rob, > At Mon, 30 Jun 2014 11:27:03 -0400, Stephen Kent wrote: >> I did suggest we might use other cert request mechanisms. EST is the >> obvious, current, standards-based option for this, if folks want to >> consider alternatives to PKCS#10. Since it was authored by a Cisco >> guy, there is some chance it might become available in their >> routers. I would suggest this path only for router certs, not for >> the RPKI certs. That might make it unpalatable, as a CA operated by >> an ISP would have to deal with two cert request formats: PKCS#1- for >> child CA certs (if the ISP is not a stub in the RPKI tree) and EST >> for router certs. > Is there any real benefit to EST, given that we already have to > support PKCS #10 and given that PKCS #10 implementations are almost > certainly easier to find than EST implementations? As I noted, I am aware of only a Cisco implementation, but we could check with Max Pritikin to see if he is aware of others. > Absent some serious advantage that I'm not seeing, this doesn't seem > particularly attractive. > >> I'm just pointing out options. > Understood. From nobody Wed Jul 2 07:50: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 828FE1A0240 for ; Wed, 2 Jul 2014 07:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 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, T_FSL_HELO_BARE_IP_2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wwv9qzyaV92m for ; Wed, 2 Jul 2014 07:50:32 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.56.236.19]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3F771A0331 for ; Wed, 2 Jul 2014 07:50:32 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 09CDA9B789C32; Wed, 2 Jul 2014 09:50:32 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway01.websitewelcome.com (Postfix) with ESMTP id E16109B789C06 for ; Wed, 2 Jul 2014 09:50:31 -0500 (CDT) Received: from [173.73.128.252] (port=51165 helo=192.168.1.10) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X2Lrj-0004cG-7o; Wed, 02 Jul 2014 09:50:31 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <20140701222948.5E0D5F43767@minas-ithil.hactrn.net> Date: Wed, 2 Jul 2014 10:50:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <75C51A68-FEC3-40B0-BC6C-A8A2471FF4CD@tislabs.com> <20140701222948.5E0D5F43767@minas-ithil.hactrn.net> To: Rob Austein 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: 173.73.128.252 X-Exim-ID: 1X2Lrj-0004cG-7o X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.10) [173.73.128.252]:51165 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/7tVcK_akq0SuH1KtM7MRVvGoJBk Cc: sidr@ietf.org Subject: Re: [sidr] about the thread "Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487" 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, 02 Jul 2014 14:50:35 -0000 On Jul 01, 2014, at 18:29, Rob Austein wrote: > At Fri, 27 Jun 2014 16:50:12 -0400, Sandra Murphy wrote: >>=20 >> RFC6487 6.1.1 (how to send a cert request in PKCS) says >>=20 >> Subject >> This field MAY be omitted. If present, the value of this = field >> SHOULD be empty (i.e., NULL), in which case the CA MUST >> generate a subject name that is unique in the context of >> certificates issued by this CA. >>=20 >> a) "This field MAY be omitted." is wrong. PKCS#10 does not say that >> the subject field is optional. So an implementation that did >> omit this field might not work with a CA's implementation. >=20 > Right. I think it's reasonably clear that, on this point, RFC 6487 > just needs to be fixed, as it violates the base specification. +1 >> b) "If present, the value of this field SHOULD be empty" means that >> the rtr-keying draft was (at the time) non-compliant - rtr-keying >> said to put the "router number" in the subject field of a PKCS#10 >> cert request. >>=20 >> The bgpsec-pki-profile draft says that the subject of a router cert >> has the router ID in it. > [...] >=20 > I think the simplest approach is to allow router key PKCS #10 requests > to include both the router id and the ASN(s). The need to support > multiple ASNs (rare, but possible, if I understand correctly) means > that we can't just use the subject name hack for this, since the > proposed encoding of router ID and ASN into the subject name only > supports one ASN. >=20 > So I think we should: >=20 > - Allow a non-empty subject name in the router certificate PKCS #10, > said name to follow whatever we pick for the recommended form of the > expected resulting certificate (ROUTER-, or > whatever), where the here is usually the one-and-only ASN but, > if there's more than one, is whichever ASN seems good to the router > operator. >=20 > - Allow the ASIdentifiers extension in the router certificate PKCS > #10. I don't particularly care whether we require this to be > present in all cases or only in the multi-ASN case, but if it is > present at all, the ASN encoded in the subject name MUST also be > listed in the ASIdentifiers extension. +1 > The CA, of course, is free to reject this PKCS #10, or issue a > certificate using the public key from the PKCS #10, a different > subject name than proposed in the PKCS #10, or only certify a subset > of the ASNs requested in the PKCS #10. Final decision on what to > certify remains with the CA, the PKCS #10 is just a mechanism for > conveying data to the CA in a tidy package. Yep the CA is the one attesting to the binding so it gets the final say. > Note that the multi-ASN case could be construed as an argument for > dropping the ASN out of the router certificate name entirely, or > perhaps only dropping the ASN out of the name when dealing with a > multi-ASN certificate. I have no strong feelings on the matter. >=20 > I do not particularly care whether the PKCS #10 profile for router > certificates is based on RFC 6487 or is a free-standing document; > whichever is easiest to get right in a reasonable period of time. Just le me know which route you want to take (no pun intended) wrt = draft-ietf-sidr-rtr-keying and draft-ietf-sidr-bgpsec-pki-profiles. spt= From nobody Wed Jul 2 08:17: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 AEF861B2935 for ; Wed, 2 Jul 2014 08:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.342 X-Spam-Level: X-Spam-Status: No, score=0.342 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FSL_HELO_BARE_IP_2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtIirjhCaGoT for ; Wed, 2 Jul 2014 08:17:32 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [67.18.21.17]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 057AA1B2931 for ; Wed, 2 Jul 2014 08:17:31 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id F0CCB889D459F; Wed, 2 Jul 2014 10:17:29 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 2B879889CC0E2 for ; Wed, 2 Jul 2014 10:16:51 -0500 (CDT) Received: from [173.73.128.252] (port=51351 helo=192.168.1.10) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X2MHC-0007Wl-Dj; Wed, 02 Jul 2014 10:16:50 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <53B41070.7040902@bbn.com> Date: Wed, 2 Jul 2014 11:16:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <938CD198-AF49-42DF-8415-0FF844420BFD@ieca.com> References: <75C51A68-FEC3-40B0-BC6C-A8A2471FF4CD@tislabs.com> <53B181C7.4000701@bbn.com> <20140701223419.3E6B9F4380E@minas-ithil.hactrn.net> <53B41070.7040902@bbn.com> To: sidr@ietf.org 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: 173.73.128.252 X-Exim-ID: 1X2MHC-0007Wl-Dj X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.10) [173.73.128.252]:51351 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/t_R7VS3bs5LrgnTOIPOxB4J3RVY Subject: Re: [sidr] EST (was Re: about the thread "Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487") 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, 02 Jul 2014 15:17:33 -0000 On Jul 02, 2014, at 10:00, Stephen Kent wrote: > Rob, >=20 >> At Mon, 30 Jun 2014 11:27:03 -0400, Stephen Kent wrote: >>> I did suggest we might use other cert request mechanisms. EST is the >>> obvious, current, standards-based option for this, if folks want to >>> consider alternatives to PKCS#10. Since it was authored by a Cisco >>> guy, there is some chance it might become available in their >>> routers. I would suggest this path only for router certs, not for >>> the RPKI certs. That might make it unpalatable, as a CA operated by >>> an ISP would have to deal with two cert request formats: PKCS#1- for >>> child CA certs (if the ISP is not a stub in the RPKI tree) and EST >>> for router certs. >> Is there any real benefit to EST, given that we already have to >> support PKCS #10 and given that PKCS #10 implementations are almost >> certainly easier to find than EST implementations? > As I noted, I am aware of only a Cisco implementation, but we could = check with > Max Pritikin to see if he is aware of others. >> Absent some serious advantage that I'm not seeing, this doesn't seem >> particularly attractive. >>=20 >>> I'm just pointing out options. >> Understood. >=20 Dan=92s got an implementation on github: https://github.com/danharkins/est spt From nobody Wed Jul 2 08:35:01 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 50FDF1A034D; Wed, 2 Jul 2014 08:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BA-in7aaK0VS; Wed, 2 Jul 2014 08:34:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7EA11B27F9; Wed, 2 Jul 2014 08:34:55 -0700 (PDT) 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.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140702153455.10414.45146.idtracker@ietfa.amsl.com> Date: Wed, 02 Jul 2014 08:34:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/I9EVh3q0K4sJuWrZ5Vh5j1Gqrpc Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-07.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, 02 Jul 2014 15:34:58 -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 : BGP Algorithms, Key Formats, & Signature Formats Author : Sean Turner Filename : draft-ietf-sidr-bgpsec-algs-07.txt Pages : 7 Date : 2014-07-02 Abstract: This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size and signature format used in BGPSEC (Border Gateway Protocol Security). This document updates the Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure (RFC 6485). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-07 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 Jul 2 08:40:19 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 21CE81A0328 for ; Wed, 2 Jul 2014 08:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 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, T_FSL_HELO_BARE_IP_2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KcO0ogVNykQ for ; Wed, 2 Jul 2014 08:40:17 -0700 (PDT) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [67.18.144.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB50B1A031B for ; Wed, 2 Jul 2014 08:40:16 -0700 (PDT) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id 6BCA8CC68E62A; Wed, 2 Jul 2014 10:38:20 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway09.websitewelcome.com (Postfix) with ESMTP id 56D74CC66FE19 for ; Wed, 2 Jul 2014 10:36:51 -0500 (CDT) Received: from [173.73.128.252] (port=51452 helo=192.168.1.10) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X2MaY-0007Vd-MG for sidr@ietf.org; Wed, 02 Jul 2014 10:36:50 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <20140702153455.10414.45146.idtracker@ietfa.amsl.com> Date: Wed, 2 Jul 2014 11:36:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0CA71605-C46F-4BAE-9646-1AB287549CF8@ieca.com> References: <20140702153455.10414.45146.idtracker@ietfa.amsl.com> To: sidr@ietf.org 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: 173.73.128.252 X-Exim-ID: 1X2MaY-0007Vd-MG X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.10) [173.73.128.252]:51452 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 11 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/eS2KSt6SQ3GUmV1inCAM-uAr3Ck Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-07.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, 02 Jul 2014 15:40:18 -0000 A minor update to move some references that were in the wrong place as = well as to correctly identify where the OID goes that indicates the = algorithm used in the CRMF (thanks Sandy for pointing these out). Oh = and I updated the dates. spt On Jul 02, 2014, at 11:34, 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 : BGP Algorithms, Key Formats, & Signature = Formats > Author : Sean Turner > Filename : draft-ietf-sidr-bgpsec-algs-07.txt > Pages : 7 > Date : 2014-07-02 >=20 > Abstract: > This document specifies the algorithms, algorithms' parameters, > asymmetric key formats, asymmetric key size and signature format = used > in BGPSEC (Border Gateway Protocol Security). This document updates > the Profile for Algorithms and Key Sizes for use in the Resource > Public Key Infrastructure (RFC 6485). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-07 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-algs-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Wed Jul 2 08:41: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 914391A031B; Wed, 2 Jul 2014 08:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7-1ccdI0WUZ; Wed, 2 Jul 2014 08:41:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DED1B280F; Wed, 2 Jul 2014 08:41:46 -0700 (PDT) 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.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140702154146.12004.37413.idtracker@ietfa.amsl.com> Date: Wed, 02 Jul 2014 08:41:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/4UNGafbnEz2Uxji8q2ywIUuzqLQ Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-08.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, 02 Jul 2014 15:41:49 -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 : BGP Algorithms, Key Formats, & Signature Formats Author : Sean Turner Filename : draft-ietf-sidr-bgpsec-algs-08.txt Pages : 7 Date : 2014-07-02 Abstract: This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size and signature format used in BGPSEC (Border Gateway Protocol Security). This document updates the Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure (RFC 6485). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-08 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 Jul 2 08:42: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 E14CA1A031B for ; Wed, 2 Jul 2014 08:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 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, T_FSL_HELO_BARE_IP_2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qcsl8DJY5wFy for ; Wed, 2 Jul 2014 08:42:32 -0700 (PDT) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [67.18.144.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706731A0328 for ; Wed, 2 Jul 2014 08:42:31 -0700 (PDT) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id 475E2CC6B2D7D; Wed, 2 Jul 2014 10:41:07 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway09.websitewelcome.com (Postfix) with ESMTP id EB589CC6931D3 for ; Wed, 2 Jul 2014 10:39:46 -0500 (CDT) Received: from [173.73.128.252] (port=51454 helo=192.168.1.10) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X2MdO-0003iR-B8 for sidr@ietf.org; Wed, 02 Jul 2014 10:39:46 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <0CA71605-C46F-4BAE-9646-1AB287549CF8@ieca.com> Date: Wed, 2 Jul 2014 11:39:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9149D9BA-B14D-404E-BE45-8A9EF7DE6F33@ieca.com> References: <20140702153455.10414.45146.idtracker@ietfa.amsl.com> <0CA71605-C46F-4BAE-9646-1AB287549CF8@ieca.com> To: sidr@ietf.org 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: 173.73.128.252 X-Exim-ID: 1X2MdO-0003iR-B8 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.10) [173.73.128.252]:51454 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 12 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/47m-gZchrw3neFuyA1lEnx7Ahbk Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-07.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, 02 Jul 2014 15:42:33 -0000 And then I just noticed the section #ing is not sequential :( Stay = tuned for another version. spt On Jul 02, 2014, at 11:36, Sean Turner wrote: > A minor update to move some references that were in the wrong place as = well as to correctly identify where the OID goes that indicates the = algorithm used in the CRMF (thanks Sandy for pointing these out). Oh = and I updated the dates. >=20 > spt >=20 > On Jul 02, 2014, at 11:34, internet-drafts@ietf.org wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Secure Inter-Domain Routing Working = Group of the IETF. >>=20 >> Title : BGP Algorithms, Key Formats, & Signature = Formats >> Author : Sean Turner >> Filename : draft-ietf-sidr-bgpsec-algs-07.txt >> Pages : 7 >> Date : 2014-07-02 >>=20 >> Abstract: >> This document specifies the algorithms, algorithms' parameters, >> asymmetric key formats, asymmetric key size and signature format = used >> in BGPSEC (Border Gateway Protocol Security). This document updates >> the Profile for Algorithms and Key Sizes for use in the Resource >> Public Key Infrastructure (RFC 6485). >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-07 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-algs-07 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 From nobody Wed Jul 2 10:21:23 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 5A6E31B284A; Wed, 2 Jul 2014 10:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhPVz7y_4mkm; Wed, 2 Jul 2014 10:21:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F03501B280C; Wed, 2 Jul 2014 10:21:19 -0700 (PDT) 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.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140702172119.8782.8548.idtracker@ietfa.amsl.com> Date: Wed, 02 Jul 2014 10:21:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/sB9yIuKc_4dTKGT-1LgXb-tKKXk Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-oob-setup-01.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, 02 Jul 2014 17:21:21 -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 : An Out-Of-Band Setup Protocol For RPKI Production Services Author : Rob Austein Filename : draft-ietf-sidr-rpki-oob-setup-01.txt Pages : 19 Date : 2014-07-02 Abstract: This note describes a simple out-of-band protocol to ease setup of the RPKI provisioning and publication protocols between two parties. The protocol is encoded in a small number of XML messages, which can be passed back and forth by any mutually agreeable secure means. This setup protocol is not part of the provisioning or publication protocol, rather, it is intended to simplify configuration of these protocols by setting up relationships and exchanging BPKI keying material. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-oob-setup/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rpki-oob-setup-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-oob-setup-01 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 Jul 2 10:27:03 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 C31421B2846 for ; Wed, 2 Jul 2014 10:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 olMlCNlJGtY9 for ; Wed, 2 Jul 2014 10:26:54 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [147.28.0.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0834B1B2845 for ; Wed, 2 Jul 2014 10:26:54 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-50-189-40-138.hsd1.ma.comcast.net [50.189.40.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id B8B5B39824 for ; Wed, 2 Jul 2014 17:26:53 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 72263F511D0 for ; Wed, 2 Jul 2014 13:26:56 -0400 (EDT) Date: Wed, 02 Jul 2014 13:26:56 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <20140702172119.8782.8548.idtracker@ietfa.amsl.com> References: <20140702172119.8782.8548.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20140702172656.72263F511D0@minas-ithil.hactrn.net> Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/0JZgI-3-TC1yUbVX9jFRt0Ou6tY Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-oob-setup-01.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, 02 Jul 2014 17:26:55 -0000 Keep-alive: bumped version number, tweaked several examples and one reference to mollify xml2rfc. No substantive changes from -00. From nobody Wed Jul 2 10:31:11 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 1C3511B29AF for ; Wed, 2 Jul 2014 10:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.143 X-Spam-Level: * X-Spam-Status: No, score=1.143 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FSL_HELO_BARE_IP_2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KIQstbvTyOG for ; Wed, 2 Jul 2014 10:31:08 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.56.236.19]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 442421B29A4 for ; Wed, 2 Jul 2014 10:31:08 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id C7F3C9C133F1C; Wed, 2 Jul 2014 12:30:40 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 998059C12AC5C for ; Wed, 2 Jul 2014 12:30:08 -0500 (CDT) Received: from [173.73.128.252] (port=52163 helo=192.168.1.10) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X2ODV-0002Qo-Al; Wed, 02 Jul 2014 12:21:09 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: Date: Wed, 2 Jul 2014 13:21:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8C95CFCE-BCF5-4CDC-A63C-915EC39080C1@ieca.com> References: <5C076C44-9200-4A07-A1BE-3888DCC9BC36@apnic.net> To: Sandra Murphy 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: 173.73.128.252 X-Exim-ID: 1X2ODV-0002Qo-Al X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.10) [173.73.128.252]:52163 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/fPU1b-oZnaEfPh6VlfxrLvXmaU8 Cc: sidr wg list Subject: Re: [sidr] comments on draft-ietf-sidr-rfc6485bis 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, 02 Jul 2014 17:31:09 -0000 On May 20, 2014, at 13:49, Sandra Murphy wrote: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >=20 > Then there's this new bit, which I noticed in the midst of checking > what was needed for the certificate requests. >=20 >=20 > In Section 2, the text says >=20 > In a certification request, the OID appears in the PKCS #10 > signatureAlgorithm field [RFC2986], or in the Certificate Request > Message Format (CRMF) POPOSigningKey signature field [RFC4211]. >=20 > RFC4211 says that the POPOSigningKey is: >=20 > POPOSigningKey ::=3D SEQUENCE { > poposkInput [0] POPOSigningKeyInput OPTIONAL, > algorithmIdentifier AlgorithmIdentifier, > signature BIT STRING } >=20 > I'm pretty sure the text should say the OID goes in the POPOSigningKey > algorithmIdentifier field, not the POPOSigningKey signature field. >=20 > [[While this looks clear to me, the comment could use some review by > someone comfortable with ASN.1 overloaded and inconsistent field > names.]] >=20 > That text is in the original RFC6485 and it has no relationship with = the > problem with the OID choice in CMS, the reason for this bis. >=20 > However, if true, this has implementation impact, so I think this > should be considered at some point. >=20 > *IF* people agree that this is wrong, do the authors have any > problem with changing the text in this bis? >=20 > FROM: >=20 > Message Format (CRMF) POPOSigningKey signature field [RFC4211]. >=20 > TO: >=20 > Message Format (CRMF) POPOSigningKey algorithmIdentifier field=20 > [RFC4211]. This change makes sense to me because the name of the field is = algorithmIdentifier not signature. spt= From nobody Wed Jul 2 13:47: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 8E6301B2889 for ; Wed, 2 Jul 2014 13:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 CLKgTb05dsyi for ; Wed, 2 Jul 2014 13:47:05 -0700 (PDT) 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 F3B721A083D for ; Wed, 2 Jul 2014 13:47:04 -0700 (PDT) Received: from donkey.her.corp.google.com (unknown [72.14.227.6]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 22EBA8801C8; Wed, 2 Jul 2014 20:47:02 +0000 (UTC) Message-ID: <53B46FC6.60507@ops-netman.net> Date: Wed, 02 Jul 2014 16:47:02 -0400 From: Chris Morrow User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "sidr-chairs@tools.ietf.org" , "sidr@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/cB833RvC81ZF3Tjj09QBLq_Jyms Subject: [sidr] Agenda discussion topics 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, 02 Jul 2014 20:47:06 -0000 Howdy SIDR folk! So in getting ready for Toronto a few things seem like they should be on the agenda, though we've (chair-folk) not heard +/- from the authors of these documents/ideas: 1) Validation Algorithm Document/process - We've talked about this on-list a bit, and in at least 3 face-to-face meetings, the document was: and recently became this: Reading this and talking about it at the meeting seems in order, to me at least. 2) SLURM/Suspenders/LTA - What should happen to LTA things with referenced documents being at least: There's a bit of draft work around this, and considerable discussion... it seems useful (to me at least) to talk about where this is going and efficacy of the approaches being considered of late. 3) Router Keying Communication of cert to CA. There's been a thread on the sidr list titled: "Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487" which seems to need some conversation. The relevant documents are: and and 4) AS Migration - Wes's Discussion about a) standards or informational track for the document b) Is this 'MUST' implement for BGPSEC implementations or SHOULD? The drafts for this are: The conversation clipped above as 'a and b' came up during WGLC (by the author), a short discussion in person will, I think, be helpful to move these two documents forward. -chris co-chair From nobody Thu Jul 3 12:05:58 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 1F22C1B2B52 for ; Thu, 3 Jul 2014 12:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 USSG0t36tM5z for ; Thu, 3 Jul 2014 12:05:55 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6E6A1B2B41 for ; Thu, 3 Jul 2014 12:05:55 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49370) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X2mKd-000C0x-5w for sidr@ietf.org; Thu, 03 Jul 2014 15:06:07 -0400 Message-ID: <53B5A991.4010500@bbn.com> Date: Thu, 03 Jul 2014 15:05:53 -0400 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: <53B46FC6.60507@ops-netman.net> In-Reply-To: <53B46FC6.60507@ops-netman.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/T6fT88BOmKF9z4VT4shJmD1213A Subject: Re: [sidr] Agenda discussion topics 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, 03 Jul 2014 19:05:57 -0000 Chris, > 1) Validation Algorithm Document/process - We've talked about this > on-list a bit, and in at least 3 face-to-face meetings, the document was: > > > and recently became this: > > > Reading this and talking about it at the meeting seems in order, to me > at least. > I quickly glanced at the new version of this doc. It seems to be a reasonable starting point for WG discussion, since it tries to focus on the problem and not mandate a solution. Since the author list now has a representative from every RIR, I'd like to see a discussion of what procedures the RIRs envision to help minimize the likelihood of the problem arising (I offered some examples a while ago), so that we understand the likelihood of this problem arising (at the RIR tier) after such procedures are employed. > 2) SLURM/Suspenders/LTA - What should happen to LTA things with > referenced documents being at least: > > > David and I just updated the 1st and 3rd docs above, referencing Randy's uses cases I-D. As we noted earlier, we would like to kill the 2nd doc above, and replace it with the other two. Either David or I will plan to speak briefly on this topic in Toronto. Steve From nobody Fri Jul 4 07:40:10 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 69C171B2C9E; Fri, 4 Jul 2014 07:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTxq-E_Zlkc0; Fri, 4 Jul 2014 07:40:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 675561A009C; Fri, 4 Jul 2014 07:40:06 -0700 (PDT) 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.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704144006.12378.37335.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 07:40:06 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/t5Xy57b17J2u1DlSoUXaQ5utG7s Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-overview-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 14:40:07 -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 : An Overview of BGPSEC Authors : Matt Lepinski Sean Turner Filename : draft-ietf-sidr-bgpsec-overview-05.txt Pages : 10 Date : 2014-07-04 Abstract: This document provides an overview of a security extension to the Border Gateway Protocol (BGP) referred to as BGPSEC. BGPSEC improves security for BGP routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-overview/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-overview-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-overview-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 08:02: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 913291B2A4A; Fri, 4 Jul 2014 08:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHA3hsN0AQU6; Fri, 4 Jul 2014 08:02:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BBA1B2A50; Fri, 4 Jul 2014 08:01:59 -0700 (PDT) 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.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704150159.16312.87077.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 08:01:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/gzvMHUvIbkT1cjnWimGXteaXhtU Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-policy-qualifiers-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 15:02:02 -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 : Policy Qualifiers in RPKI Certificates Authors : Andrew Lee Newton Geoff Huston Filename : draft-ietf-sidr-policy-qualifiers-02.txt Pages : 4 Date : 2014-07-04 Abstract: This document updates RFC 6487 by clarifying the inclusion of policy qualifiers in the certificate policies extension of RPKI resource certificates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-policy-qualifiers/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-policy-qualifiers-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-policy-qualifiers-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 08:45:54 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 18F4E1A0180 for ; Fri, 4 Jul 2014 08:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 0ztsToqLjWDE for ; Fri, 4 Jul 2014 08:45:50 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id BBC601A01F6 for ; Fri, 4 Jul 2014 08:45:50 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 655F928B0041 for ; Fri, 4 Jul 2014 11:45:50 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 3D94B1F8032; Fri, 4 Jul 2014 11:45:50 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_A5E25413-D9D9-403D-8629-0AA25F1AFEFD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Fri, 4 Jul 2014 11:45:48 -0400 Message-Id: <8EDD8182-1C18-4372-B2F4-B76E2AE1DC43@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/dHLgiuvdSK-eW511jS5yHX-pUo8 Cc: Sandra Murphy Subject: [sidr] needing chair action for the remainder of today 4 July 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, 04 Jul 2014 15:45:52 -0000 --Apple-Mail=_A5E25413-D9D9-403D-8629-0AA25F1AFEFD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The deadline for drafts is this evening midnight UTC. For drafts of the form draft-ietf-sidr-fooandbar-00.txt, chair approval = is needed. That is only true for -00 versions. If you have not already informed the chairs, and find yourself in need = of approval, please send a message to the chairs alias = sidr-chairs@ietf.org or even better to the mailing list, to maximize the = chances one of the right people will see the message. --Sandy, speaking as one of the co-chairs --Apple-Mail=_A5E25413-D9D9-403D-8629-0AA25F1AFEFD 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 iQIcBAEBCgAGBQJTtswsAAoJEHplpQeet0IZnvEP/2UeB2Q87dHo059Z4n9X2p0q fJNaDr/LNY0rLWH7qTFx2MrrWO/Yos/mGmPM6+IPmNtNLNTwn/4pUGPDHBtDUss+ 9ZFZkRdGMPS4mFuJR6wt/xMeE3Ci9RwcM+O6cEz/no/oOLjsziIUqt5oTOpGxzTI NZLwLAsmjKyCGRbcjmPHN4os137RjFowiE5EJXH7FpvjwrFLj4cdJRXiqCmK2+69 8KUB75PGRL2vHgVyNH6scn09aP3+JQa6KeXDVTGY3Mzr1aXXdS/Xvs2OWjyY1B5X /0c1egn0Z+xXGCmNhDqnTQbcBWtnAspvMI7eM8XaTe7wGud+RUZncEXosNco6d7D qHWSFMFce8iN5+RjiQbryed6zJHeBvpv/OxYO0fVzZGsCGoepx0RPCtgi6FtzKD7 9JOhVZ7tcYNoz1kYId2T+UjB1F2Sk1VV4PpEczBMHGtGo6XBkqIedqO3PSt3UtZ3 0XDand3+PUxEmtOEQu06IsIhhepVaWzObjZUpxuSuhOlS/Q4ZXzUqQlNKwepZYMW OZFqEXDsk+oI5lBEa5noEKZRy2M1zKrEv5NtgYQt7oBQBRSeSPEc7YZdFG9/sULF qZdtX+Qzr5cBV57hTsQYMyAIzHuhUWWkL3FjEG/GghMiejeKWebpwpApCx8T6qvP g+2Vi3PZ+Jb4bU8f5WqE =gzov -----END PGP SIGNATURE----- --Apple-Mail=_A5E25413-D9D9-403D-8629-0AA25F1AFEFD-- From nobody Fri Jul 4 15:04: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 9981C1A008F; Fri, 4 Jul 2014 15:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URs7aTfQEUv8; Fri, 4 Jul 2014 15:04:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF711A0004; Fri, 4 Jul 2014 15:04:14 -0700 (PDT) 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.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704220414.22376.54911.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 15:04:14 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/NPc2Rp1OKc1Tu3kFTW78roEo1c0 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-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: Fri, 04 Jul 2014 22:04:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : BGPSEC Protocol Specification Author : Matthew Lepinski Filename : draft-ietf-sidr-bgpsec-protocol-09.txt Pages : 34 Date : 2014-07-04 Abstract: This document describes BGPSEC, an extension to the Border Gateway Protocol (BGP) that provides security for the path of autonomous systems through which a BGP update message passes. BGPSEC is implemented via a new optional non-transitive BGP path attribute that carries a digital signature produced by each autonomous system that propagates the update message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-protocol-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 Fri Jul 4 15:16:22 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 DCC291A005F for ; Fri, 4 Jul 2014 15:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMsllxMZzCLD for ; Fri, 4 Jul 2014 15:16:19 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81FC91A003B for ; Fri, 4 Jul 2014 15:16:19 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id r20so4442052wiv.10 for ; Fri, 04 Jul 2014 15:16:18 -0700 (PDT) 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=yY0mvgDkfK3MGlYXExp56ot+FGBtqlC8cM4FPqwXgsY=; b=Yr0sK0lOdV8tkP5t/cG4HMkzKnED/BpDlSnWYukP03YTEchSp7AijtnfRi609CgMGX 5DhswlechJbB49BjkLdE4zBpvlKVNyAEX/OTqwN8DpJmMwfEqiE08UEVJ1r9hYH4X9uf 1gJaqqRB7QXmmJcGG0f6L8uwXSos14KaI18dawlZCrn0yFQw+w7KZhqn1WwVYWi3WS+5 45NKm4IhxZq2qjDCDx6PxkYqIoTMAjtAIhLrjkfaezyyFeUb59ixqiuxIUK//NdOiXl0 UXLCIhaZcSykPlnBpctNp612xvSJcXUS5Rxm9oIY+50gkpUj5Fdi18JNk9bmvxdsbYQ4 y98g== MIME-Version: 1.0 X-Received: by 10.195.13.79 with SMTP id ew15mr14192660wjd.19.1404512178011; Fri, 04 Jul 2014 15:16:18 -0700 (PDT) Received: by 10.216.170.137 with HTTP; Fri, 4 Jul 2014 15:16:17 -0700 (PDT) Date: Fri, 4 Jul 2014 18:16:17 -0400 Message-ID: From: Matthew Lepinski To: "sidr@ietf.org" Content-Type: multipart/alternative; boundary=047d7bfd093a74042104fd657907 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/wznSILixMDQiCX4w0gzVtcUl3Jk Subject: [sidr] New version draft-ietf-sidr-bgpsec-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, 04 Jul 2014 22:16:21 -0000 --047d7bfd093a74042104fd657907 Content-Type: text/plain; charset=UTF-8 I submitted a new version of the bgpsec protocol document. This revision includes a fair number of editorial changes but does not include any normative changes. Now that the BGPSEC requirements document is essentially done, I look forward to discussing the protocol document again in Toronto. In particular, between now and the Toronto meeting I will write up (and send to the list) a brief comparison between the requirements in the final version of the reqs draft and what we deliver in the protocol document. The only open issue in the protocol document that I am aware of is the following: * It was suggested in a review that we should explicitly specify (when we discuss error handling) that an implementation send a BGP NOTIFICATION message when an error occurs. Personally, I don't think this is necessary. (In particular, my reading of draft-ietf-idr-error-handling-13 is that in the "treat as withdrawal" case that a NOTIFICATION message is not required. That being said, I am very willing to defer to the BGP experts in the group on this issue. In particular, does anyone know if the intention of draft-ietf-idr-error-handling is for a NOTIFICATION to be sent when an error is "treat as withdrawal"? (I am concerned that sending a NOTIFICATION message in a case where we are not closing the session is not a good idea, but I am certain that others know more about these details than I do.) --047d7bfd093a74042104fd657907 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I submitted a new version of the bgpsec protocol document.= This revision includes a fair number of editorial changes but does not inc= lude any normative changes.

Now that the BGPSEC requirem= ents document is essentially done, I look forward to discussing the protoco= l document again in Toronto. In particular, between now and the Toronto mee= ting I will write up (and send to the list) a brief comparison between the = requirements in the final version of the reqs draft and what we deliver in = the protocol document.=C2=A0

The only open issue in the protocol document that I am = aware of is the following:

* It was suggested in a= review that we should explicitly specify (when we discuss error handling) = that an implementation send a BGP NOTIFICATION message when an error occurs= .=C2=A0

Personally, I don't think this is necessary. (In pa= rticular, my reading of=C2=A0draft-ietf-idr-error-handling-13 is that in th= e "treat as withdrawal" case that a NOTIFICATION message is not r= equired.

That being said, I am very willing to defer to the BGP = experts in the group on this issue. In particular, does anyone know if the = intention of draft-ietf-idr-error-handling is for a NOTIFICATION to be sent= when an error is "treat as withdrawal"? (I am concerned that sen= ding a NOTIFICATION message in a case where we are not closing the session = is not a good idea, but I am certain that others know more about these deta= ils than I do.)
--047d7bfd093a74042104fd657907-- From nobody Sat Jul 5 15:41: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 372391A001D; Sat, 5 Jul 2014 15:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 gGj9spQvtITT; Sat, 5 Jul 2014 15:40:54 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42421A0010; Sat, 5 Jul 2014 15:40:53 -0700 (PDT) Received: from CY1PR09MB0283.namprd09.prod.outlook.com (25.160.159.11) by CY1PR09MB0281.namprd09.prod.outlook.com (25.160.140.27) with Microsoft SMTP Server (TLS) id 15.0.974.11; Sat, 5 Jul 2014 22:40:51 +0000 Received: from CY1PR09MB0283.namprd09.prod.outlook.com ([25.160.159.11]) by CY1PR09MB0283.namprd09.prod.outlook.com ([25.160.159.11]) with mapi id 15.00.0974.002; Sat, 5 Jul 2014 22:40:52 +0000 From: "Sriram, Kotikalapudi" To: "grow@ietf.org" , "sidr wg list (sidr@ietf.org)" , "idr@ietf.org" Thread-Topic: New Version Notification for draft-sriram-route-leak-protection-00 Thread-Index: Ac+YoG1v4r/E8oBITwO9qOVMW2v8hg== Date: Sat, 5 Jul 2014 22:40:49 +0000 Message-ID: <881700c1df264d11a9c74c0fca20c64f@CY1PR09MB0283.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.223.116] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02638D901B x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(377454003)(377424004)(13464003)(20776003)(64706001)(81342001)(33646001)(81542001)(4396001)(66066001)(80022001)(79102001)(76482001)(31966008)(74662001)(74502001)(77982001)(46102001)(107886001)(107046002)(95666004)(105586002)(99286002)(106356001)(15202345003)(83322001)(19580405001)(19580395003)(54356999)(50986999)(101416001)(15975445006)(99396002)(85852003)(83072002)(87936001)(2656002)(92566001)(86362001)(76576001)(85306003)(77096002)(74316001)(21056001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CY1PR09MB0281; H:CY1PR09MB0283.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/LkvZphYGtvXYjt9LuO_bGTqq4-Q Subject: [sidr] FW: New Version Notification for draft-sriram-route-leak-protection-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 22:40:57 -0000 VGhpcyBpcyBhIC0wMCBpbmRpdmlkdWFsIGRyYWZ0IGNvbnRyaWJ1dGlvbi4gDQpJIHdpbGwgY29u c3VsdCB3aXRoIEdST1cgYW5kIFNJRFIgY2hhaXJzIHJlZ2FyZGluZyBhIA0KcG9zc2libGUgcHJl c2VudGF0aW9uIG9mIHRoaXMgd29yayBpbiBUb3JvbnRvLg0KWW91ciBjb21tZW50cywgc3VnZ2Vz dGlvbnMgcmVxdWVzdGVkLiANCg0KU3JpcmFtDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmddIA0KU2VudDogRnJpZGF5LCBKdWx5IDA0LCAyMDE0IDc6MTcgUE0NClRvOiBTcmly YW0sIEtvdGlrYWxhcHVkaTsgTW9udGdvbWVyeSwgRG91Z2xhczsgTW9udGdvbWVyeSwgRG91Z2xh czsgU3JpcmFtLCBLb3Rpa2FsYXB1ZGkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtc3JpcmFtLXJvdXRlLWxlYWstcHJvdGVjdGlvbi0wMC50eHQNCg0KDQpBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtc3JpcmFtLXJvdXRlLWxlYWstcHJvdGVjdGlvbi0wMC50 eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgS290aWthbGFwdWRpIFNyaXJh bSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1zcmly YW0tcm91dGUtbGVhay1wcm90ZWN0aW9uDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJRW5oYW5jZW1l bnQgdG8gQkdQU0VDIGZvciBQcm90ZWN0aW9uIGFnYWluc3QgUm91dGUgTGVha3MNCkRvY3VtZW50 IGRhdGU6CTIwMTQtMDctMDQNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJ CTExDQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtc3JpcmFtLXJvdXRlLWxlYWstcHJvdGVjdGlvbi0wMC50eHQNClN0YXR1czogICAgICAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zcmlyYW0tcm91dGUtbGVh ay1wcm90ZWN0aW9uLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXNyaXJhbS1yb3V0ZS1sZWFrLXByb3RlY3Rpb24tMDANCg0KDQpBYnN0cmFjdDoNCiAg IFRoaXMgZG9jdW1lbnQgZW51bWVyYXRlcyBkaWZmZXJlbnQgdHlwZXMgb2Ygcm91dGUgbGVha3Mg YmFzZWQgb24NCiAgIG9ic2VydmVkIGV2ZW50cyBvbiB0aGUgSW50ZXJuZXQuICBJdCBpbGx1c3Ry YXRlcyBob3cgQkdQU0VDIGluIGl0cw0KICAgY3VycmVudCBmb3JtIChhcyBkZXNjcmliZWQgaW4g ZHJhZnQtaWV0Zi1zaWRyLWJncHNlYy1wcm90b2NvbC0wOSkNCiAgIGFscmVhZHkgcHJvdmlkZXMg cHJvdGVjdGlvbiBhZ2FpbnN0IGFsbCBidXQgb25lIG9mIHRoZXNlIHJvdXRlLWxlYWtzDQogICBz Y2VuYXJpb3MuICBUaGUgZG9jdW1lbnQgZnVydGhlciBkaXNjdXNzZXMgYSBkZXNpZ24gZW5oYW5j ZW1lbnQgdG8NCiAgIHRoZSBCR1BTRUMgcHJvdG9jb2wgdGhhdCB3aWxsIGV4dGVuZCBwcm90ZWN0 aW9uIGFnYWluc3QgdGhpcyBvbmUNCiAgIHJlbWFpbmluZyB0eXBlIG9mIHJvdXRlLWxlYWsgYXR0 YWNrIGFzIHdlbGwuICBXaXRoIHRoZSBpbmNsdXNpb24gb2YNCiAgIHRoaXMgZW5oYW5jZW1lbnQs IEJHUFNFQyBpcyBleHBlY3RlZCB0byBwcm92aWRlIHByb3RlY3Rpb24gYWdhaW5zdA0KICAgYWxs IHR5cGVzIG9mIHJvdXRlLWxlYWtzLiAgVGhlIGRvY3VtZW50IGFsc28gaW5jbHVkZXMgYSBzdG9w Z2FwDQogICBtZXRob2QgZm9yIGRldGVjdGlvbiBhbmQgbWl0aWdhdGlvbiBvZiByb3V0ZSBsZWFr cyBmb3IgdGhlIHBoYXNlIHdoZW4NCiAgIEJHUFNFQyAocGF0aCB2YWxpZGF0aW9uKSBpcyBub3Qg eWV0IGRlcGxveWVkIGJ1dCBvbmx5IG9yaWdpbg0KICAgdmFsaWRhdGlvbiBpcyBkZXBsb3llZC4N Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p ZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Sun Jul 6 20:54:16 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 CAA781A0AE3 for ; Sun, 6 Jul 2014 20:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, 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 NrZCzhh0h7Az for ; Sun, 6 Jul 2014 20:54:12 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) by ietfa.amsl.com (Postfix) with SMTP id 65C631A0AE1 for ; Sun, 6 Jul 2014 20:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:from:to:subject:thread-topic:thread-index:date:message-id: references:in-reply-to:accept-language:content-language:x-ms-has-attach: x-ms-tnef-correlator:x-originating-ip:content-type:content-id: content-transfer-encoding:mime-version; bh=t8fO/ksBpyaLOUcMRlkHwVybotMMu4ga4pOnwEAUESo=; b=2gZ89+qLsPPb9iOqOfUTNQyBhG+UzD6LO8KMsVZFF8Pga3SYO/5Serfdp2bVVLGzTUt39u1jZW40q aiD2KfN2ylbmeMQxaRzd+aLb813ssfw98/FFuDa2ZcEtlp5ZHANcnBYxbOwLCnI6yt4xID0CxpRxwn A9RudV1NrZiArzg0= Received: from iamda3.org.apnic.net (unknown [203.119.101.249]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP for ; Mon, 7 Jul 2014 13:53:58 +1000 (EST) Received: from NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67]) by iamda3.org.apnic.net ([fe80::e195:c0e8:e814:db75%15]) with mapi id 14.01.0218.012; Mon, 7 Jul 2014 13:54:09 +1000 From: Byron Ellacott To: "sidr@ietf.org" Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt Thread-Index: AQHPmZcbU/We9JsEpE+FEBXwF0llig== Date: Mon, 7 Jul 2014 03:54:09 +0000 Message-ID: References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> In-Reply-To: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.20] Content-Type: text/plain; charset="us-ascii" Content-ID: <2CE4E1BF725A554CB8192E62C75354A1@apnic.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/BysvcJQNlvRaRsTBvEmWj9jxodU Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 03:54:15 -0000 I have read and reviewed this document. The problem described is one that concerns me greatly as the operator of a near-apex CA and repository. While all due care is taken to ensure correctness of action, good engineering practice is to identify risks through frequency and impact and take steps to mitigate those risks. In this case, the frequency is low but the current impact is extremely high. With solutions to mitigate the impact at hand, it seems straightforward to me that those solutions should be pursued: removing the occurrence of events of this nature altogether is impractical. Regarding the content of the document, the last paragraph of section 2 offers a very clear description of the problem: a technical choice, not driven by any system requirements, is imposing a significant consequence on operations. Section 3 covers scenarios related to movement of resources between CAs, but does not consider the additional impact of cache refresh cycles. Each CA in a chain must wait until it is confident that all clients have refreshed, which introduces at least 24 hours delay at each tier in the hierarchy. This cascade of delays up and down the hierarchy, plus coordination lag across timezones, is likely to extend the time it takes to move resources within the RPKI by days at best. Perhaps the document should make some reference to this issue? And one minor typo at the top of page 4 with the resources listed as ".../24/24". Fortunately this typo doesn't invalidate the rest of the document :-) Byron On 2/07/2014 11:27 am, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Secure Inter-Domain Routing Working >Group of the IETF. > > Title : RPKI Validation Reconsidered > Authors : Geoff Huston > George Michaelson > Carlos M. Martinez > Tim Bruijnzeels > Andrew Lee Newton > Alain Aina > Filename : draft-ietf-sidr-rpki-validation-reconsidered-00.txt > Pages : 10 > Date : 2014-07-01 > >Abstract: > This document reviews the certificate validation procedure specified > in RFC6487 and highlights aspects of potentially acute operational > fragility in the management of certificates in the RPKI in response > to the movement of resources across registries, and the associated > actions of Certification Authorities to maintain continuity of > validation of certification of resources during this movement. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconside >red/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-sidr-rpki-validation-reconsidered-00 > > >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/ > >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From nobody Mon Jul 7 09:40:24 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 72BC21A0352 for ; Mon, 7 Jul 2014 09:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.285 X-Spam-Level: ** X-Spam-Status: No, score=2.285 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 50NZHkoqo5E4 for ; Mon, 7 Jul 2014 09:40:22 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7558F1A0344 for ; Mon, 7 Jul 2014 09:40:21 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.01,619,1400040000"; d="scan'208,217";a="392717099" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 07 Jul 2014 12:40:19 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Mon, 7 Jul 2014 12:40:20 -0400 From: "George, Wes" To: Matthew Lepinski , "sidr@ietf.org" Date: Mon, 7 Jul 2014 12:40:19 -0400 Thread-Topic: [sidr] New version draft-ietf-sidr-bgpsec-protocol Thread-Index: Ac+aAiOLOBNyil3zTDuLZ7O41ge1ig== 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.3.140616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CFE041BA21BB6wesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/xbfXnqJYX7TnapH3pMmDAwKTB4Y Subject: Re: [sidr] New version draft-ietf-sidr-bgpsec-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, 07 Jul 2014 16:40:23 -0000 --_000_CFE041BA21BB6wesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGcm9tOiBNYXR0aGV3IExlcGluc2tpIDxtbGVwaW5za2kuaWV0ZkBnbWFpbC5jb208bWFpbHRv Om1sZXBpbnNraS5pZXRmQGdtYWlsLmNvbT4+DQpEYXRlOiBGcmlkYXksIEp1bHkgNCwgMjAxNCBh dCA2OjE2IFBNDQpUbzogInNpZHJAaWV0Zi5vcmc8bWFpbHRvOnNpZHJAaWV0Zi5vcmc+IiA8c2lk ckBpZXRmLm9yZzxtYWlsdG86c2lkckBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbc2lkcl0gTmV3IHZl cnNpb24gZHJhZnQtaWV0Zi1zaWRyLWJncHNlYy1wcm90b2NvbA0KDQpJIHN1Ym1pdHRlZCBhIG5l dyB2ZXJzaW9uIG9mIHRoZSBiZ3BzZWMgcHJvdG9jb2wgZG9jdW1lbnQuIFRoaXMgcmV2aXNpb24g aW5jbHVkZXMgYSBmYWlyIG51bWJlciBvZiBlZGl0b3JpYWwgY2hhbmdlcyBidXQgZG9lcyBub3Qg aW5jbHVkZSBhbnkgbm9ybWF0aXZlIGNoYW5nZXMuDQoNCk5vdyB0aGF0IHRoZSBCR1BTRUMgcmVx dWlyZW1lbnRzIGRvY3VtZW50IGlzIGVzc2VudGlhbGx5IGRvbmUsIEkgbG9vayBmb3J3YXJkIHRv IGRpc2N1c3NpbmcgdGhlIHByb3RvY29sIGRvY3VtZW50IGFnYWluIGluIFRvcm9udG8uIEluIHBh cnRpY3VsYXIsIGJldHdlZW4gbm93IGFuZCB0aGUgVG9yb250byBtZWV0aW5nIEkgd2lsbCB3cml0 ZSB1cCAoYW5kIHNlbmQgdG8gdGhlIGxpc3QpIGEgYnJpZWYgY29tcGFyaXNvbiBiZXR3ZWVuIHRo ZSByZXF1aXJlbWVudHMgaW4gdGhlIGZpbmFsIHZlcnNpb24gb2YgdGhlIHJlcXMgZHJhZnQgYW5k IHdoYXQgd2UgZGVsaXZlciBpbiB0aGUgcHJvdG9jb2wgZG9jdW1lbnQuDQoNClRoZSBvbmx5IG9w ZW4gaXNzdWUgaW4gdGhlIHByb3RvY29sIGRvY3VtZW50IHRoYXQgSSBhbSBhd2FyZSBvZiBpcyB0 aGUgZm9sbG93aW5nOg0KDQpbc25pcF0NCg0KTWF0dCAtDQoNCk9uZSBhZGRpdGlvbmFsIGNoYW5n ZSBJIHRoaW5rIGlzIG5lY2Vzc2FyeSBpcyB0byBhZGQgYSByZWZlcmVuY2UgdG8gaWV0Zi1zaWRy LWFzLW1pZ3JhdGlvbi4gVGhpcyBpcyBlZmZlY3RpdmVseSBhbiBleHRlbnNpb24gb2YgdGhlIEJH UFNlYyBwcm90b2NvbCB0aGF0IGlzIGNvbnRhaW5lZCBpbiBhIHNlcGFyYXRlIGRvY3VtZW50LiBJ ZiB0aGUgQkdQU2VjIGRvYyB3YXMgYWxyZWFkeSBkb25lLCBJJ2QgbW9zdCBsaWtlbHkgYmUgdXNp bmcgdGhlIG1ldGFkYXRhIG9mIGFzLW1pZ3JhdGlvbiB0byB1cGRhdGUgUkZDbm5ubiBzbyB0aGF0 IHRoZSBsaW5rIHdvdWxkIGV4aXN0IGZyb20gdGhlIEJHUFNlYyBwcm90b2NvbCBkb2MgaW4gYWRk aXRpb24gdG8gdGhlIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gLXByb3RvY29sIGZyb20gYXPigJNt aWdyYXRpb24sIGJ1dCBpbiB0aGUgY3VycmVudCBmb3JtIHdoZXJlIGl0J3MgdHJpdmlhbCB0byB1 cGRhdGUgdGhlIC1wcm90b2NvbCBkcmFmdCwgSSB0aGluayB0aGF0IHNob3VsZCBpbnN0ZWFkIGJl IGFjY29tcGxpc2hlZCBieSBhIGZvcndhcmQgcmVmZXJlbmNlLCBhbmQgdGhlbiB0aGUgdHdvIGRv Y3VtZW50cyB3aWxsIHNpbXBseSBiZSBwYXJ0IG9mIHRoZSBncm91cCBvZiBpbnRlcmRlcGVuZGVu dCBkb2NzIHRoYXQgZ2V0IHJlbGVhc2VkIGZvciBCR1BTZWMgKGFzc3VtaW5nIG9mIGNvdXJzZSB0 aGF0IC1hc+KAk21pZ3JhdGlvbiBwYXNzZXMgTEMpLg0KDQpUaGF0IHNhaWQsIG15IHF1aWNrIHNj YW4gb2Yg4oCTcHJvdG9jb2wgZGlkbid0IHJldmVhbCBhbiBvYnZpb3VzIHBsYWNlIHRvIGluc2Vy dCB0aGF0IHJlZmVyZW5jZSwgc28gaWYgeW91IG9yIG90aGVycyBoYXZlIGlkZWFzIG9mIHdoZXJl IGl0IHNob3VsZCBnbywgSSdtIGhhcHB5IHRvIGNvbnRyaWJ1dGUgYSBmZXcgbGluZXMgb2Ygd3Jh cHBlciB0ZXh0Lg0KDQpUaGFua3MsDQoNCldlcw0KDQpBbnl0aGluZyBiZWxvdyB0aGlzIGxpbmUg aGFzIGJlZW4gYWRkZWQgYnkgbXkgY29tcGFueeKAmXMgbWFpbCBzZXJ2ZXIsIEkgaGF2ZSBubyBj b250cm9sIG92ZXIgaXQuDQotLS0tLS0tLS0tLQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMg cHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdp bmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBm b3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRk cmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1t YWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0 cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29u dGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1h aWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVy bWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwg YW5kIGFueSBwcmludG91dC4NCg== --_000_CFE041BA21BB6wesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjps ZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZU OiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBB RERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1S SUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5NYXR0aGV3IExlcGluc2tpICZsdDs8YSBocmVmPSJt YWlsdG86bWxlcGluc2tpLmlldGZAZ21haWwuY29tIj5tbGVwaW5za2kuaWV0ZkBnbWFpbC5jb208 L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+ RnJpZGF5LCBKdWx5IDQsIDIwMTQgYXQgNjoxNiBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpzaWRyQGlldGYub3Jn Ij5zaWRyQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpZHJAaWV0Zi5v cmciPnNpZHJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5TdWJqZWN0OiA8L3NwYW4+W3NpZHJdIE5ldyB2ZXJzaW9uIGRyYWZ0LWlldGYtc2lkci1i Z3BzZWMtcHJvdG9jb2w8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0i bHRyIj5JIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBiZ3BzZWMgcHJvdG9jb2wgZG9j dW1lbnQuIFRoaXMgcmV2aXNpb24gaW5jbHVkZXMgYSBmYWlyIG51bWJlciBvZiBlZGl0b3JpYWwg Y2hhbmdlcyBidXQgZG9lcyBub3QgaW5jbHVkZSBhbnkgbm9ybWF0aXZlIGNoYW5nZXMuDQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5Ob3cgdGhhdCB0aGUgQkdQU0VDIHJlcXVpcmVtZW50cyBkb2N1 bWVudCBpcyBlc3NlbnRpYWxseSBkb25lLCBJIGxvb2sgZm9yd2FyZCB0byBkaXNjdXNzaW5nIHRo ZSBwcm90b2NvbCBkb2N1bWVudCBhZ2FpbiBpbiBUb3JvbnRvLiBJbiBwYXJ0aWN1bGFyLCBiZXR3 ZWVuIG5vdyBhbmQgdGhlIFRvcm9udG8gbWVldGluZyBJIHdpbGwgd3JpdGUgdXAgKGFuZCBzZW5k IHRvIHRoZSBsaXN0KSBhIGJyaWVmIGNvbXBhcmlzb24gYmV0d2VlbiB0aGUNCiByZXF1aXJlbWVu dHMgaW4gdGhlIGZpbmFsIHZlcnNpb24gb2YgdGhlIHJlcXMgZHJhZnQgYW5kIHdoYXQgd2UgZGVs aXZlciBpbiB0aGUgcHJvdG9jb2wgZG9jdW1lbnQuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5UaGUgb25seSBvcGVuIGlzc3VlIGluIHRoZSBwcm90b2NvbCBkb2N1bWVudCB0 aGF0IEkgYW0gYXdhcmUgb2YgaXMgdGhlIGZvbGxvd2luZzo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFu Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+W3NuaXBdPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+TWF0dCAtJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5PbmUgYWRkaXRpb25hbCBjaGFuZ2UgSSB0aGluayBpcyBuZWNlc3NhcnkgaXMgdG8gYWRkIGEg cmVmZXJlbmNlIHRvIGlldGYtc2lkci1hcy1taWdyYXRpb24uIFRoaXMgaXMgZWZmZWN0aXZlbHkg YW4gZXh0ZW5zaW9uIG9mIHRoZSBCR1BTZWMgcHJvdG9jb2wgdGhhdCBpcyBjb250YWluZWQgaW4g YSBzZXBhcmF0ZSBkb2N1bWVudC4gSWYgdGhlIEJHUFNlYyBkb2Mgd2FzIGFscmVhZHkgZG9uZSwg SSdkIG1vc3QgbGlrZWx5IGJlIHVzaW5nIHRoZQ0KIG1ldGFkYXRhIG9mIGFzLW1pZ3JhdGlvbiB0 byB1cGRhdGUgUkZDbm5ubiBzbyB0aGF0IHRoZSBsaW5rIHdvdWxkIGV4aXN0IGZyb20gdGhlIEJH UFNlYyBwcm90b2NvbCBkb2MgaW4gYWRkaXRpb24gdG8gdGhlIG5vcm1hdGl2ZSByZWZlcmVuY2Ug dG8gLXByb3RvY29sIGZyb20gYXPigJNtaWdyYXRpb24sIGJ1dCBpbiB0aGUgY3VycmVudCBmb3Jt IHdoZXJlIGl0J3MgdHJpdmlhbCB0byB1cGRhdGUgdGhlIC1wcm90b2NvbCBkcmFmdCwgSSB0aGlu ayB0aGF0DQogc2hvdWxkIGluc3RlYWQgYmUgYWNjb21wbGlzaGVkIGJ5IGEgZm9yd2FyZCByZWZl cmVuY2UsIGFuZCB0aGVuIHRoZSB0d28gZG9jdW1lbnRzIHdpbGwgc2ltcGx5IGJlIHBhcnQgb2Yg dGhlIGdyb3VwIG9mIGludGVyZGVwZW5kZW50IGRvY3MgdGhhdCBnZXQgcmVsZWFzZWQgZm9yIEJH UFNlYyAoYXNzdW1pbmcgb2YgY291cnNlIHRoYXQgLWFz4oCTbWlncmF0aW9uIHBhc3NlcyBMQyku PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGF0IHNhaWQsIG15IHF1aWNrIHNjYW4g b2Yg4oCTcHJvdG9jb2wgZGlkbid0IHJldmVhbCBhbiBvYnZpb3VzIHBsYWNlIHRvIGluc2VydCB0 aGF0IHJlZmVyZW5jZSwgc28gaWYgeW91IG9yIG90aGVycyBoYXZlIGlkZWFzIG9mIHdoZXJlIGl0 IHNob3VsZCBnbywgSSdtIGhhcHB5IHRvIGNvbnRyaWJ1dGUgYSBmZXcgbGluZXMgb2Ygd3JhcHBl ciB0ZXh0LiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7Ij5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPldlczwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij48c3BhbiBzdHlsZT0iY29s b3I6IHJnYigxMjcsIDEyNywgMTI3KTsiPkFueXRoaW5nIGJlbG93IHRoaXMgbGluZSBoYXMgYmVl biBhZGRlZCBieSBteSBjb21wYW554oCZcyBtYWlsIHNlcnZlciwgSSBoYXZlIG5vIGNvbnRyb2wg b3ZlciBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij48c3BhbiBzdHls ZT0iY29sb3I6IHJnYigxMjcsIDEyNywgMTI3KTsiPi0tLS0tLS0tLS0tPC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDEyNywgMTI3LCAxMjcp OyI+PGJyPg0KPC9zcGFuPjwvZGl2Pg0KPGJyPg0KPGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNv bG9yPSJHcmF5IiBzaXplPSIxIj5UaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50 cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwg d2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdo dCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVk IHNvbGVseQ0KIGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGlj aCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQg b2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWlu YXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9u IHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8NCiB0aGlzIEUtbWFpbCBpcyBz dHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9m IHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuPGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_CFE041BA21BB6wesleygeorgetwcablecom_-- From nobody Mon Jul 7 10:03: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 04CB71A0424 for ; Mon, 7 Jul 2014 10:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKhiHsW1E-VC for ; Mon, 7 Jul 2014 10:03:32 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24831A041E for ; Mon, 7 Jul 2014 10:03:31 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id r20so16196296wiv.14 for ; Mon, 07 Jul 2014 10:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cTgaVSlUnHmkw0IjsCa09i2hdcsNHtSXT4cbCE9AB1Y=; b=nfAxU4TPVBKoBXYujKmUWnHtrlZ0rkyi9Q3ucTw2KrXl8qN7txBZSfyNWfpchqsyOd fTDb0ihQuWRwu/N7Y1GbKijWB/GJdK59v7VWfhFws+jG2pH3qxEslv6aXwBqKZ4MkPp5 sUwIvkEBZ2HfZ5HofQpPhXgI70uk6A4wr23xJ37rCo42vzyWdSaHciQ9xlIKGbaoJGJ/ UgLJxqm9ESxM9jIbMtbt+c9BFWlZHcXYM7YU3tggBKj46yd21lZh29qvZtsZyMiRwwf1 XUzXdQ/0lxP9wI2CXIP5zg+zq97K/VvQyaiUGmuQhZ0UOPOGjYxlIpNmbm/GGJ2Zul2z uRiw== MIME-Version: 1.0 X-Received: by 10.180.208.35 with SMTP id mb3mr72129420wic.48.1404752606922; Mon, 07 Jul 2014 10:03:26 -0700 (PDT) Received: by 10.216.170.137 with HTTP; Mon, 7 Jul 2014 10:03:26 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 Jul 2014 13:03:26 -0400 Message-ID: From: Matthew Lepinski To: "George, Wes" Content-Type: multipart/alternative; boundary=001a11c38636220e4e04fd9d745e Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/od9jgQZ2Y75ajrQswn4-Xy37x0g Cc: "sidr@ietf.org" Subject: Re: [sidr] New version draft-ietf-sidr-bgpsec-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, 07 Jul 2014 17:03:34 -0000 --001a11c38636220e4e04fd9d745e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Wes, I agree that inserting a reference in bgpsec-protocol (and bgpsec-overview) and then publishing as-migration as part of the bgpsec document set (along with the router certificate profile, the algorithm document, etc) is a good way forward. I need to do a careful review of the latest version of as-migration (I really haven't looked at the -01). I will get to that before we meet in Toronto. Also, I am open to suggestions with regards to where to insert a reference to as-migration -- but I will try to suggestion for how to link the two documents in time for Toronto. - Matt Lepinski On Mon, Jul 7, 2014 at 12:40 PM, George, Wes wrote: > > From: Matthew Lepinski > Date: Friday, July 4, 2014 at 6:16 PM > To: "sidr@ietf.org" > Subject: [sidr] New version draft-ietf-sidr-bgpsec-protocol > > I submitted a new version of the bgpsec protocol document. This revision > includes a fair number of editorial changes but does not include any > normative changes. > > Now that the BGPSEC requirements document is essentially done, I look > forward to discussing the protocol document again in Toronto. In > particular, between now and the Toronto meeting I will write up (and send > to the list) a brief comparison between the requirements in the final > version of the reqs draft and what we deliver in the protocol document. > > The only open issue in the protocol document that I am aware of is the > following: > > [snip] > > Matt - > > One additional change I think is necessary is to add a reference to > ietf-sidr-as-migration. This is effectively an extension of the BGPSec > protocol that is contained in a separate document. If the BGPSec doc was > already done, I'd most likely be using the metadata of as-migration to > update RFCnnnn so that the link would exist from the BGPSec protocol doc = in > addition to the normative reference to -protocol from as=E2=80=93migratio= n, but in > the current form where it's trivial to update the -protocol draft, I thin= k > that should instead be accomplished by a forward reference, and then the > two documents will simply be part of the group of interdependent docs tha= t > get released for BGPSec (assuming of course that -as=E2=80=93migration pa= sses LC). > > That said, my quick scan of =E2=80=93protocol didn't reveal an obvious p= lace to > insert that reference, so if you or others have ideas of where it should > go, I'm happy to contribute a few lines of wrapper text. > > Thanks, > > > > Wes > > Anything below this line has been added by my company=E2=80=99s mail se= rver, I > have no control over it. > > ----------- > > > ------------------------------ > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely > for the use of the individual or entity to which it is addressed. If you > are not the intended recipient of this E-mail, you are hereby notified th= at > any dissemination, distribution, copying, or action taken in relation to > the contents of and attachments to this E-mail is strictly prohibited and > may be unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any copy o= f > this E-mail and any printout. > --001a11c38636220e4e04fd9d745e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wes,

I agree that inserting a reference= in bgpsec-protocol (and bgpsec-overview) and then publishing as-migration = as part of the bgpsec document set (along with the router certificate profi= le, the algorithm document, etc) is a good way forward.=C2=A0

I need to do a careful review of the latest version of = as-migration (I really haven't looked at the -01). I will get to that b= efore we meet in Toronto.=C2=A0

Also, I am open to= suggestions with regards to where to insert a reference to as-migration --= but I will try to suggestion for how to link the two documents in time for= Toronto.

- Matt Lepinski
<= br>
On Mon, Jul 7, 2014 at 12:40 PM, George, = Wes <wesley.george@twcable.com> wrote:

From: Matthew Lepinski <mlepinski.ietf@gmail= .com>
Date: Friday, July 4, 2014 at 6:16 = PM
To: "sidr@ietf.org" <sidr@ietf.org>
Subject: [sidr] New version draft-i= etf-sidr-bgpsec-protocol

I submitted a new version of the bgpsec protocol document.= This revision includes a fair number of editorial changes but does not inc= lude any normative changes.

Now that the BGPSEC requirements document is essentially done, I look = forward to discussing the protocol document again in Toronto. In particular= , between now and the Toronto meeting I will write up (and send to the list= ) a brief comparison between the requirements in the final version of the reqs draft and what we deliver in= the protocol document.=C2=A0

The only open issue in the protocol document that I am aware of is the= following:

[snip]

Matt -=C2=A0

One additional change I think is necessary is to add a reference to ie= tf-sidr-as-migration. This is effectively an extension of the BGPSec protoc= ol that is contained in a separate document. If the BGPSec doc was already = done, I'd most likely be using the metadata of as-migration to update RFCnnnn so that the link would exist fr= om the BGPSec protocol doc in addition to the normative reference to -proto= col from as=E2=80=93migration, but in the current form where it's trivi= al to update the -protocol draft, I think that should instead be accomplished by a forward reference, and then the two do= cuments will simply be part of the group of interdependent docs that get re= leased for BGPSec (assuming of course that -as=E2=80=93migration passes LC)= .

That said, my quick scan of =E2=80=93protocol didn't reveal an obv= ious place to insert that reference, so if you or others have ideas of wher= e it should go, I'm happy to contribute a few lines of wrapper text.=C2= =A0

Tha= nks,

= =C2=A0

Wes=


Anything below this line has been added= by my company=E2=80=99s mail server, I have no control over it.<= /u>

-----------



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

--001a11c38636220e4e04fd9d745e-- From nobody Mon Jul 7 10:06: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 E6CE01A0452 for ; Mon, 7 Jul 2014 10:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuvHJ8xwNmg4 for ; Mon, 7 Jul 2014 10:06:05 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 505A61A0340 for ; Mon, 7 Jul 2014 10:06:05 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id l18so2021227wgh.18 for ; Mon, 07 Jul 2014 10:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zQFUy06gmYcHSlyyeCKYjB7iXoKzG/nc0+8gcU4lMvU=; b=hRZssawTO+5FcLEYCw2nQ6FTtBuZtnMWfJ7qFxf0ddb251Asc8ju3HoyjezaDtpRYU f1QC/M2DNgI0KmMBewYdZqWXucS7+4s2byE+R0jj65eQFZYAk6/eKVl6dH7OGpzsXjIQ TVG7O5NjO9BkUBXMqQWcE0ly7xdkJ4YGPzqrZmRgxjrS2kqmUeJgPAcuhaxhNz1CJfTD /9MqQWewKNzPhk3cLipizvVKziBgRpd23ajJ12YeADMv9oiGQlLlKsV2kOarT8gTTmYn 9NH1CZDV3cseqLNFT2n+U623h6B4VlryLQFCENthp+OHiLlagq/hVGXP9lppCLyyM/Tt Pvuw== MIME-Version: 1.0 X-Received: by 10.180.198.116 with SMTP id jb20mr37753408wic.59.1404752763807; Mon, 07 Jul 2014 10:06:03 -0700 (PDT) Received: by 10.216.170.137 with HTTP; Mon, 7 Jul 2014 10:06:03 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 Jul 2014 13:06:03 -0400 Message-ID: From: Matthew Lepinski To: "George, Wes" Content-Type: multipart/alternative; boundary=047d7b66f9197bee6804fd9d7d6d Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/kR32ViCIZnfN8Fw50m8ypccdq9k Cc: "sidr@ietf.org" Subject: Re: [sidr] New version draft-ietf-sidr-bgpsec-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, 07 Jul 2014 17:06:08 -0000 --047d7b66f9197bee6804fd9d7d6d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Oh, one other thing: If anyone on this list thinks that instead of referencing as-migration, that we are better off merging as-migration into bgpsec-protocol, this would be a great time to speak up. (That is, it is not too late to pull the solution from as-migration directly into bgpsec-protocol, but if we are going to go down that road, we should do it as soon as possible!) On Mon, Jul 7, 2014 at 1:03 PM, Matthew Lepinski wrote: > Wes, > > I agree that inserting a reference in bgpsec-protocol (and > bgpsec-overview) and then publishing as-migration as part of the bgpsec > document set (along with the router certificate profile, the algorithm > document, etc) is a good way forward. > > I need to do a careful review of the latest version of as-migration (I > really haven't looked at the -01). I will get to that before we meet in > Toronto. > > Also, I am open to suggestions with regards to where to insert a referenc= e > to as-migration -- but I will try to suggestion for how to link the two > documents in time for Toronto. > > - Matt Lepinski > > > On Mon, Jul 7, 2014 at 12:40 PM, George, Wes > wrote: > >> >> From: Matthew Lepinski >> Date: Friday, July 4, 2014 at 6:16 PM >> To: "sidr@ietf.org" >> Subject: [sidr] New version draft-ietf-sidr-bgpsec-protocol >> >> I submitted a new version of the bgpsec protocol document. This >> revision includes a fair number of editorial changes but does not includ= e >> any normative changes. >> >> Now that the BGPSEC requirements document is essentially done, I look >> forward to discussing the protocol document again in Toronto. In >> particular, between now and the Toronto meeting I will write up (and sen= d >> to the list) a brief comparison between the requirements in the final >> version of the reqs draft and what we deliver in the protocol document. >> >> The only open issue in the protocol document that I am aware of is the >> following: >> >> [snip] >> >> Matt - >> >> One additional change I think is necessary is to add a reference to >> ietf-sidr-as-migration. This is effectively an extension of the BGPSec >> protocol that is contained in a separate document. If the BGPSec doc was >> already done, I'd most likely be using the metadata of as-migration to >> update RFCnnnn so that the link would exist from the BGPSec protocol doc= in >> addition to the normative reference to -protocol from as=E2=80=93migrati= on, but in >> the current form where it's trivial to update the -protocol draft, I thi= nk >> that should instead be accomplished by a forward reference, and then the >> two documents will simply be part of the group of interdependent docs th= at >> get released for BGPSec (assuming of course that -as=E2=80=93migration p= asses LC). >> >> That said, my quick scan of =E2=80=93protocol didn't reveal an obvious = place to >> insert that reference, so if you or others have ideas of where it should >> go, I'm happy to contribute a few lines of wrapper text. >> >> Thanks, >> >> >> >> Wes >> >> Anything below this line has been added by my company=E2=80=99s mail s= erver, I >> have no control over it. >> >> ----------- >> >> >> ------------------------------ >> This E-mail and any of its attachments may contain Time Warner Cable >> proprietary information, which is privileged, confidential, or subject t= o >> copyright belonging to Time Warner Cable. This E-mail is intended solely >> for the use of the individual or entity to which it is addressed. If you >> are not the intended recipient of this E-mail, you are hereby notified t= hat >> any dissemination, distribution, copying, or action taken in relation to >> the contents of and attachments to this E-mail is strictly prohibited an= d >> may be unlawful. If you have received this E-mail in error, please notif= y >> the sender immediately and permanently delete the original and any copy = of >> this E-mail and any printout. >> > > --047d7b66f9197bee6804fd9d7d6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Oh, one other thing:

If anyone on this = list thinks that instead of referencing as-migration, that we are better of= f merging as-migration into bgpsec-protocol, this would be a great time to = speak up.

=C2=A0(That is, it is not too late to pull the solution= from as-migration directly into bgpsec-protocol, but if we are going to go= down that road, we should do it as soon as possible!)


On Mon, Jul 7, 2014 at 1:03 PM, Matthew = Lepinski <mlepinski.ietf@gmail.com> wrote:
Wes,

I agree that inserting a reference= in bgpsec-protocol (and bgpsec-overview) and then publishing as-migration = as part of the bgpsec document set (along with the router certificate profi= le, the algorithm document, etc) is a good way forward.=C2=A0

I need to do a careful review of the latest version of = as-migration (I really haven't looked at the -01). I will get to that b= efore we meet in Toronto.=C2=A0

Also, I am open to= suggestions with regards to where to insert a reference to as-migration --= but I will try to suggestion for how to link the two documents in time for= Toronto.

- Matt Lepinski


O= n Mon, Jul 7, 2014 at 12:40 PM, George, Wes <wesley.george@twcab= le.com> wrote:

From: Matthew Lepinski <mlepinski.ietf@gmail= .com>
Date: Friday, July 4, 2014 at 6:16 = PM
To: "sidr@ietf.org" <sidr@ietf.org>
Subject: [sidr] New version draft-i= etf-sidr-bgpsec-protocol

I submitted a new version of the bgpsec protocol document.= This revision includes a fair number of editorial changes but does not inc= lude any normative changes.

Now that the BGPSEC requirements document is essentially done, I look = forward to discussing the protocol document again in Toronto. In particular= , between now and the Toronto meeting I will write up (and send to the list= ) a brief comparison between the requirements in the final version of the reqs draft and what we deliver in= the protocol document.=C2=A0

The only open issue in the protocol document that I am aware of is the= following:

[snip]

Matt -=C2=A0

One additional change I think is necessary is to add a reference to ie= tf-sidr-as-migration. This is effectively an extension of the BGPSec protoc= ol that is contained in a separate document. If the BGPSec doc was already = done, I'd most likely be using the metadata of as-migration to update RFCnnnn so that the link would exist fr= om the BGPSec protocol doc in addition to the normative reference to -proto= col from as=E2=80=93migration, but in the current form where it's trivi= al to update the -protocol draft, I think that should instead be accomplished by a forward reference, and then the two do= cuments will simply be part of the group of interdependent docs that get re= leased for BGPSec (assuming of course that -as=E2=80=93migration passes LC)= .

That said, my quick scan of =E2=80=93protocol didn't reveal an obv= ious place to insert that reference, so if you or others have ideas of wher= e it should go, I'm happy to contribute a few lines of wrapper text.=C2= =A0

Tha= nks,

= =C2=A0

Wes=


Anything below this line has been added= by my company=E2=80=99s mail server, I have no control over it.<= /u>

-----------



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


--047d7b66f9197bee6804fd9d7d6d-- From nobody Mon Jul 7 13:19: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 369A71A0515 for ; Mon, 7 Jul 2014 13:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBHlgd5bxVUD for ; Mon, 7 Jul 2014 13:19:24 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FAAC1A01F7 for ; Mon, 7 Jul 2014 13:19:24 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id r10so5979307pdi.9 for ; Mon, 07 Jul 2014 13:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AFpxJ37w2ykCauJEtdB9xNmZaqMHPBjytKB/5sNLTWg=; b=qmmxrg9ijaP8cgFoTH4xQR9sbPZqrpSgNlrwREslO0jr3LG5Xv2yCwP4zvJZXEZ7vg C7EXex6tPjXPHNxrKN+9PecCroVuICkJIWsw+0YnYPPC43R1WfzryhvxoiW4Rg0HZuDB WYGeaGK47DoaRaKo07YzF7xq7DrJ5Ju4gM4bgK5fDrAoP0ngTSK3uIsGQZXAbjgRTNxG fBuYLawDKMZxto1GXPpUqeQ9yFcr/GWxQomPkwAMBNXvpxMgp4a16d1dhvkZy+r0oyYb IDhLZoYVJ59dLiUeynNGElorjnG4ZffPmh2nksWNjd0Tu4oFYOwHOwidpcMOyZeie2AM AfrA== X-Received: by 10.66.131.39 with SMTP id oj7mr30947937pab.20.1404764363958; Mon, 07 Jul 2014 13:19:23 -0700 (PDT) Received: from [10.2.98.234] ([119.225.153.210]) by mx.google.com with ESMTPSA id zf9sm14034478pab.5.2014.07.07.13.19.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jul 2014 13:19:23 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Geoff Huston In-Reply-To: <0CA71605-C46F-4BAE-9646-1AB287549CF8@ieca.com> Date: Tue, 8 Jul 2014 06:19:17 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <40F096CA-F99B-4E4C-A3EF-EAC71A613CED@gmail.com> References: <20140702153455.10414.45146.idtracker@ietfa.amsl.com> <0CA71605-C46F-4BAE-9646-1AB287549CF8@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/uoEthbfxsZGO_nhhvlAM_05oKTE Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-07.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, 07 Jul 2014 20:19:25 -0000 Hi Sean, Whats the relationship between this draft and = draft-ietf-sidr-rfc6485bis? g On 3 Jul 2014, at 1:36 am, Sean Turner wrote: > A minor update to move some references that were in the wrong place as = well as to correctly identify where the OID goes that indicates the = algorithm used in the CRMF (thanks Sandy for pointing these out). Oh = and I updated the dates. >=20 > spt >=20 > On Jul 02, 2014, at 11:34, internet-drafts@ietf.org wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Secure Inter-Domain Routing Working = Group of the IETF. >>=20 >> Title : BGP Algorithms, Key Formats, & Signature = Formats >> Author : Sean Turner >> Filename : draft-ietf-sidr-bgpsec-algs-07.txt >> Pages : 7 >> Date : 2014-07-02 >>=20 >> Abstract: >> This document specifies the algorithms, algorithms' parameters, >> asymmetric key formats, asymmetric key size and signature format = used >> in BGPSEC (Border Gateway Protocol Security). This document updates >> the Profile for Algorithms and Key Sizes for use in the Resource >> Public Key Infrastructure (RFC 6485). >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-07 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-algs-07 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Mon Jul 7 13:29: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 321E21B28D8 for ; Mon, 7 Jul 2014 13:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsqUG_BlY-UY for ; Mon, 7 Jul 2014 13:28:55 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) by ietfa.amsl.com (Postfix) with SMTP id 803411B28C9 for ; Mon, 7 Jul 2014 13:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=X9K2y14WWGqHyGL+AUwWEhXE2C+ww1SKgpX/8olo25A=; b=xtucQFDEbUjTjBqqf6/W18RbwWris6keQF9rGINjB+oGFuStps4IRTZYcru25APkLjXtXRPHCvb/1 /yxHSUaOTC3Sz82YB3Awh6Sf/rMXtR+UWOKQ0SCaTGL1fdlbWmrcKxkLQiRNR+k6Tp1eDHLdlFcmlV aeuJF3j4G0+vl04Q= Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTP for ; Tue, 8 Jul 2014 06:28:51 +1000 (EST) Received: from [10.2.98.234] (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 8 Jul 2014 06:28:51 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Geoff Huston In-Reply-To: <0CA71605-C46F-4BAE-9646-1AB287549CF8@ieca.com> Date: Tue, 8 Jul 2014 06:28:49 +1000 Content-Transfer-Encoding: quoted-printable Message-ID: <0AD801E2-D37B-432C-91FE-7983235468A4@apnic.net> References: <20140702153455.10414.45146.idtracker@ietfa.amsl.com> <0CA71605-C46F-4BAE-9646-1AB287549CF8@ieca.com> To: sidr wg list X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/ptN2vZT4f2ujXEJMtycXSyyrg3Y Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-07.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, 07 Jul 2014 20:29:02 -0000 Hi Sean, Whats the relationship between this draft and = draft-ietf-sidr-rfc6485bis? g On 3 Jul 2014, at 1:36 am, Sean Turner wrote: > A minor update to move some references that were in the wrong place as = well as to correctly identify where the OID goes that indicates the = algorithm used in the CRMF (thanks Sandy for pointing these out). Oh = and I updated the dates. >=20 > spt >=20 > On Jul 02, 2014, at 11:34, internet-drafts@ietf.org wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Secure Inter-Domain Routing Working = Group of the IETF. >>=20 >> Title : BGP Algorithms, Key Formats, & Signature = Formats >> Author : Sean Turner >> Filename : draft-ietf-sidr-bgpsec-algs-07.txt >> Pages : 7 >> Date : 2014-07-02 >>=20 >> Abstract: >> This document specifies the algorithms, algorithms' parameters, >> asymmetric key formats, asymmetric key size and signature format used >> in BGPSEC (Border Gateway Protocol Security). This document updates >> the Profile for Algorithms and Key Sizes for use in the Resource >> Public Key Infrastructure (RFC 6485). >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-07 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-algs-07 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Mon Jul 7 14:04: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 9B0291B28D3 for ; Mon, 7 Jul 2014 14:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1bCb9Ndni-j for ; Mon, 7 Jul 2014 14:04:41 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E78D91B28CC for ; Mon, 7 Jul 2014 14:04:40 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id u56so4936195wes.35 for ; Mon, 07 Jul 2014 14:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=07MG1Iq/VdUwXTeGVODi0Jme/O2aJ+mByeBKaGDFxYY=; b=pgANQmyMib0odyFSMcAGk2ARkroZYr5jrneuSPmYVvkajvYhuLFwIlSWhZbT483DYV EeCfcKS55CpSHd0NBIsmya5M5EBoSkwdZ3mTStuNCouUKLEhnSlWmHLnDHztCsReqXzx tWfzpgxYL+HtDXoy5V0MLTy+OW2h2WTxBnhG1ikIAqYPcqE8GfaCehNHhappDZFFHSOH kXr20J2TN05BbdBJPMaRG5q0Ddmg9MaKJ03V53rCZfoubr+VjWrUJPL3KSR3rKZyCtll JuK9tf6DnFSogrmu0g8N7qLhqolcNqBZjI5UwnR37XdCHj34mrhIumE/UwBnzR5LxcYx T0kw== MIME-Version: 1.0 X-Received: by 10.180.198.116 with SMTP id jb20mr38822661wic.59.1404767079279; Mon, 07 Jul 2014 14:04:39 -0700 (PDT) Received: by 10.216.170.137 with HTTP; Mon, 7 Jul 2014 14:04:39 -0700 (PDT) In-Reply-To: <0AD801E2-D37B-432C-91FE-7983235468A4@apnic.net> References: <20140702153455.10414.45146.idtracker@ietfa.amsl.com> <0CA71605-C46F-4BAE-9646-1AB287549CF8@ieca.com> <0AD801E2-D37B-432C-91FE-7983235468A4@apnic.net> Date: Mon, 7 Jul 2014 17:04:39 -0400 Message-ID: From: Matthew Lepinski To: Geoff Huston Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/stqFzT0_VqVtZPcUb4yhcTO0d1M Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-07.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, 07 Jul 2014 21:04:46 -0000 Yes, there seems to be an issue here: I believe the question is what types of keys can appear as the subject public key in an RPKI certificate. -- RFC 6485 says "See 6487" (and thus 6487bis when it is published) to find out what is allowed as a subject public key -- draft-ietf-sidr-bgpsec-pki-profiles updates RFC 6485 and says "For Router Certs (end-entity certificates use by BGPSEC) see draft-ietf-sidr-bgpsec-algs Ideally, this shouldn't be a problem. RFC 6487 governs subject public keys for all certificates in the RPKI except BGPSEC router certificates and draft-sidr-bgpsec-algs covers that case. That being said, we currently have two working group documents that update RFC 6485 and I am not sure that it is sufficiently clear in the text of those documents how the two updates interact. On Mon, Jul 7, 2014 at 4:28 PM, Geoff Huston wrote: > Hi Sean, > > Whats the relationship between this draft and draft-ietf-sidr-rfc6485bis? > > g > > > On 3 Jul 2014, at 1:36 am, Sean Turner wrote: > >> A minor update to move some references that were in the wrong place as well as to correctly identify where the OID goes that indicates the algorithm used in the CRMF (thanks Sandy for pointing these out). Oh and I updated the dates. >> >> spt >> >> On Jul 02, 2014, at 11:34, internet-drafts@ietf.org wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. >>> >>> Title : BGP Algorithms, Key Formats, & Signature Formats >>> Author : Sean Turner >>> Filename : draft-ietf-sidr-bgpsec-algs-07.txt >>> Pages : 7 >>> Date : 2014-07-02 >>> >>> Abstract: >>> This document specifies the algorithms, algorithms' parameters, >>> asymmetric key formats, asymmetric key size and signature format used >>> in BGPSEC (Border Gateway Protocol Security). This document updates >>> the Profile for Algorithms and Key Sizes for use in the Resource >>> Public Key Infrastructure (RFC 6485). >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-07 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-07 >>> >>> >>> 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/ >>> >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Mon Jul 7 15:29: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 A56A61B28A5 for ; Mon, 7 Jul 2014 15:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alhGay5nkgNI for ; Mon, 7 Jul 2014 15:29:55 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) by ietfa.amsl.com (Postfix) with SMTP id 85E291A0AAD for ; Mon, 7 Jul 2014 15:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=h31iBzQvzo0OmKL/ozoisBpzH+wJvmZdSD8h0jGgwMs=; b=kw5CPZJx+Z876q2+yLjiZTveIWyHKYXaEemtZdqzgtEUbrZO0v9NteSYb4pzSeBNn90yFfDBfzCsV 5QUBPmSsRMxeQJNg1aWJrhGYZQHfdVn363ECPbDMDBoNhzNCyBqGrBQResMAwVVei9M9E3Bfgkp882 C+bwwPmruuduU+8k= Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Tue, 8 Jul 2014 08:29:51 +1000 (EST) Received: from [10.2.46.179] (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 8 Jul 2014 08:29:51 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Geoff Huston In-Reply-To: Date: Tue, 8 Jul 2014 08:29:49 +1000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140702153455.10414.45146.idtracker@ietfa.amsl.com> <0CA71605-C46F-4BAE-9646-1AB287549CF8@ieca.com> <0AD801E2-D37B-432C-91FE-7983235468A4@apnic.net> To: Matthew Lepinski X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/mvUOXTCa-HNb9WnJ_kdg-0GQlMk Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-07.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, 07 Jul 2014 22:29:57 -0000 yes confusion all round > -- RFC 6485 says "See 6487" (and thus 6487bis when it is published) > to find out what is allowed as a subject public key RFC 6487 says "See RFC6485" and (thus 6485bis when it is published) to = find out what is allowed as a subject public key i.e. I think I understand what you are saying here, but you seem to have = 6485 and 6487 swapped - right? g On 8 Jul 2014, at 7:04 am, Matthew Lepinski = wrote: > Yes, there seems to be an issue here: >=20 > I believe the question is what types of keys can appear as the subject > public key in an RPKI certificate. >=20 > -- RFC 6485 says "See 6487" (and thus 6487bis when it is published) > to find out what is allowed as a subject public key >=20 > -- draft-ietf-sidr-bgpsec-pki-profiles updates RFC 6485 and says "For > Router Certs (end-entity certificates use by BGPSEC) see > draft-ietf-sidr-bgpsec-algs >=20 > Ideally, this shouldn't be a problem. RFC 6487 governs subject public > keys for all certificates in the RPKI except BGPSEC router > certificates and draft-sidr-bgpsec-algs covers that case. >=20 > That being said, we currently have two working group documents that > update RFC 6485 and I am not sure that it is sufficiently clear in the > text of those documents how the two updates interact. >=20 > On Mon, Jul 7, 2014 at 4:28 PM, Geoff Huston wrote: >> Hi Sean, >>=20 >> Whats the relationship between this draft and = draft-ietf-sidr-rfc6485bis? >>=20 >> g >>=20 >>=20 >> On 3 Jul 2014, at 1:36 am, Sean Turner wrote: >>=20 >>> A minor update to move some references that were in the wrong place = as well as to correctly identify where the OID goes that indicates the = algorithm used in the CRMF (thanks Sandy for pointing these out). Oh = and I updated the dates. >>>=20 >>> spt >>>=20 >>> On Jul 02, 2014, at 11:34, internet-drafts@ietf.org wrote: >>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>> This draft is a work item of the Secure Inter-Domain Routing = Working Group of the IETF. >>>>=20 >>>> Title : BGP Algorithms, Key Formats, & Signature = Formats >>>> Author : Sean Turner >>>> Filename : draft-ietf-sidr-bgpsec-algs-07.txt >>>> Pages : 7 >>>> Date : 2014-07-02 >>>>=20 >>>> Abstract: >>>> This document specifies the algorithms, algorithms' parameters, >>>> asymmetric key formats, asymmetric key size and signature format = used >>>> in BGPSEC (Border Gateway Protocol Security). This document = updates >>>> the Profile for Algorithms and Key Sizes for use in the Resource >>>> Public Key Infrastructure (RFC 6485). >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-07 >>>>=20 >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-algs-07 >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of = submission >>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> sidr mailing list >>>> sidr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sidr >>>=20 >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr From nobody Mon Jul 7 15:37: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 6DD021B281C for ; Mon, 7 Jul 2014 15:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pn5cxt_lkS3A for ; Mon, 7 Jul 2014 15:37:46 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37EAE1A0AAD for ; Mon, 7 Jul 2014 15:37:46 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id q59so5107732wes.40 for ; Mon, 07 Jul 2014 15:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PLJ0ZYwKA4fMpVnXzZO9jWlSft8zQh+c21e0ZjKYaGQ=; b=gi9ZFet9xe8vMHg7WKcWFungfVHRcB8kVnD/Kb1cA3ABOny3p0wcEj7OycQMg6PF3K 3yqM1CRo/pGsGrU1J8/B5PZMq6ejJcsirrbClHZzeXyDPxMyeZVYg/HlRmLQwsWwhj2p jl+UxjF+7u9Bopw8GndPT0wCh2Eg/Qiw0kdH/SIHN8oCFo0jXqmoSs1KA0cyJ1/ZVRZg 5rW/j7eFcXbthmkci2IhvEt+KgzMMoxm6wTHTcWR1a0GEzjlV74r9idEp0EB9vhvAiMg PZLlZopKaFxgPEiEd24QdenGxmCps73aDXSahaMhoqCphVDYrTHxz+BX4kFPHc+hlt5h 0Lzw== MIME-Version: 1.0 X-Received: by 10.180.13.47 with SMTP id e15mr81042329wic.28.1404772664807; Mon, 07 Jul 2014 15:37:44 -0700 (PDT) Received: by 10.216.170.137 with HTTP; Mon, 7 Jul 2014 15:37:44 -0700 (PDT) In-Reply-To: References: <20140702153455.10414.45146.idtracker@ietfa.amsl.com> <0CA71605-C46F-4BAE-9646-1AB287549CF8@ieca.com> <0AD801E2-D37B-432C-91FE-7983235468A4@apnic.net> Date: Mon, 7 Jul 2014 18:37:44 -0400 Message-ID: From: Matthew Lepinski To: Geoff Huston Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/4iRP__TBzCO-eFXDDTCSyVzELDg Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-07.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, 07 Jul 2014 22:37:48 -0000 Yes, let me try re-sending my original message -- this time with correct RFC numbers: I believe the question is what types of keys can appear as the subject public key in an RPKI certificate. -- RFC 6487 says "See 6485" (and thus 6485bis when it is published) to find out what is allowed as a subject public key -- draft-ietf-sidr-bgpsec-pki-profiles updates RFC 6487 and says "For Router Certs (end-entity certificates use by BGPSEC) see draft-ietf-sidr-bgpsec-algs Ideally, this shouldn't be a problem. RFC 6487 governs subject public keys for all certificates in the RPKI except BGPSEC router certificates and draft-sidr-bgpsec-algs covers that case. That being said, we currently have two working group documents that update existing documents and I am not sure that the text of those documents (taken together) is sufficiently clear on what can and cannot appear as a subject public key in an RPKI certificate. In particular, 6485bis seems to say "only RSA with SHA256" and I think what sidr-bgpsec-pki-profiles wants to say (but I don't know if it is sufficiently clear) that b485bis applies to all RPKI certificates except end-enty router certificates and that those certificates should look at bgpsec-algs to figure out what an acceptable subject public key is On Mon, Jul 7, 2014 at 6:29 PM, Geoff Huston wrote: > yes confusion all round > > >> -- RFC 6485 says "See 6487" (and thus 6487bis when it is published) >> to find out what is allowed as a subject public key > > > RFC 6487 says "See RFC6485" and (thus 6485bis when it is published) to find out what is allowed as a subject public key > > i.e. I think I understand what you are saying here, but you seem to have 6485 and 6487 swapped - right? > > > g > > > > > > On 8 Jul 2014, at 7:04 am, Matthew Lepinski wrote: > >> Yes, there seems to be an issue here: >> >> I believe the question is what types of keys can appear as the subject >> public key in an RPKI certificate. >> >> -- RFC 6485 says "See 6487" (and thus 6487bis when it is published) >> to find out what is allowed as a subject public key >> >> -- draft-ietf-sidr-bgpsec-pki-profiles updates RFC 6485 and says "For >> Router Certs (end-entity certificates use by BGPSEC) see >> draft-ietf-sidr-bgpsec-algs >> >> Ideally, this shouldn't be a problem. RFC 6487 governs subject public >> keys for all certificates in the RPKI except BGPSEC router >> certificates and draft-sidr-bgpsec-algs covers that case. >> >> That being said, we currently have two working group documents that >> update RFC 6485 and I am not sure that it is sufficiently clear in the >> text of those documents how the two updates interact. >> >> On Mon, Jul 7, 2014 at 4:28 PM, Geoff Huston wrote: >>> Hi Sean, >>> >>> Whats the relationship between this draft and draft-ietf-sidr-rfc6485bis? >>> >>> g >>> >>> >>> On 3 Jul 2014, at 1:36 am, Sean Turner wrote: >>> >>>> A minor update to move some references that were in the wrong place as well as to correctly identify where the OID goes that indicates the algorithm used in the CRMF (thanks Sandy for pointing these out). Oh and I updated the dates. >>>> >>>> spt >>>> >>>> On Jul 02, 2014, at 11:34, internet-drafts@ietf.org wrote: >>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>> This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. >>>>> >>>>> Title : BGP Algorithms, Key Formats, & Signature Formats >>>>> Author : Sean Turner >>>>> Filename : draft-ietf-sidr-bgpsec-algs-07.txt >>>>> Pages : 7 >>>>> Date : 2014-07-02 >>>>> >>>>> Abstract: >>>>> This document specifies the algorithms, algorithms' parameters, >>>>> asymmetric key formats, asymmetric key size and signature format used >>>>> in BGPSEC (Border Gateway Protocol Security). This document updates >>>>> the Profile for Algorithms and Key Sizes for use in the Resource >>>>> Public Key Infrastructure (RFC 6485). >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-07 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-07 >>>>> >>>>> >>>>> 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/ >>>>> >>>>> _______________________________________________ >>>>> sidr mailing list >>>>> sidr@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sidr >>>> >>>> _______________________________________________ >>>> sidr mailing list >>>> sidr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sidr >>> >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr > From nobody Mon Jul 7 16:00: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 24B1D1B297E for ; Mon, 7 Jul 2014 16:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJZLyu14aUcI for ; Mon, 7 Jul 2014 16:00:40 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) by ietfa.amsl.com (Postfix) with SMTP id 394DB1B28A5 for ; Mon, 7 Jul 2014 16:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=dCp2OReu1JKxSI4mLhOnp9XXwPXVpeT71R7yAR/Inys=; b=YsyaGlgPHHqTH8OgC3hkqoDG8NFUBb3rTxzD02ZU8ATUjfmBbKw4lD3w15HRGl4x6Klkm/yID1cMc AibxQvgfGTTm9UmOc5g+MPc6T6WNQzwYzz8LgUwdGW53MBK9OVI15/OVT1HXEism5PsW/R2DbfHF1S FcSa3PBMwG2NXCFU= Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Tue, 8 Jul 2014 09:00:36 +1000 (EST) Received: from [10.2.46.179] (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 8 Jul 2014 09:00:36 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Geoff Huston In-Reply-To: Date: Tue, 8 Jul 2014 09:00:35 +1000 Content-Transfer-Encoding: quoted-printable Message-ID: <586E1AFE-895F-40AB-A101-271F07774FA6@apnic.net> References: <20140702153455.10414.45146.idtracker@ietfa.amsl.com> <0CA71605-C46F-4BAE-9646-1AB287549CF8@ieca.com> <0AD801E2-D37B-432C-91FE-7983235468A4@apnic.net> To: Matthew Lepinski X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/LqqQjwNv4KLn1FA9gN70DkmMoN4 Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-07.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, 07 Jul 2014 23:00:48 -0000 On 8 Jul 2014, at 8:37 am, Matthew Lepinski = wrote: > Yes, let me try re-sending my original message -- this time with > correct RFC numbers: >=20 > I believe the question is what types of keys can appear as the subject > public key in an RPKI certificate. >=20 > -- RFC 6487 says "See 6485" (and thus 6485bis when it is published) > to find out what is allowed as a subject public key >=20 > -- draft-ietf-sidr-bgpsec-pki-profiles updates RFC 6487 and says "For > Router Certs (end-entity certificates use by BGPSEC) see > draft-ietf-sidr-bgpsec-algs but... the header of draft-ietf-sidr-bgpsec-algs-08 says: "Updates: 6485 (if approved) " so I'm still confused about the two 6485 update drafts. =20 >=20 > Ideally, this shouldn't be a problem. RFC 6487 governs subject public > keys for all certificates in the RPKI except BGPSEC router > certificates and draft-sidr-bgpsec-algs covers that case. errr - do you mean 6487 or 6485? >=20 > That being said, we currently have two working group documents that > update existing documents and I am not sure that the text of those > documents (taken together) is sufficiently clear on what can and > cannot appear as a subject public key in an RPKI certificate. I can agree wholeheartedly on this observation of a lack of clarity = here! Geoff >=20 > In particular, 6485bis seems to say "only RSA with SHA256" and I think > what sidr-bgpsec-pki-profiles wants to say (but I don't know if it is > sufficiently clear) that b485bis applies to all RPKI certificates > except end-enty router certificates and that those certificates should > look at bgpsec-algs to figure out what an acceptable subject public > key is >=20 > On Mon, Jul 7, 2014 at 6:29 PM, Geoff Huston wrote: >> yes confusion all round >>=20 >>=20 >>> -- RFC 6485 says "See 6487" (and thus 6487bis when it is published) >>> to find out what is allowed as a subject public key >>=20 >>=20 >> RFC 6487 says "See RFC6485" and (thus 6485bis when it is published) = to find out what is allowed as a subject public key >>=20 >> i.e. I think I understand what you are saying here, but you seem to = have 6485 and 6487 swapped - right? >>=20 >>=20 >> g >>=20 >>=20 >>=20 >>=20 >>=20 >> On 8 Jul 2014, at 7:04 am, Matthew Lepinski = wrote: >>=20 >>> Yes, there seems to be an issue here: >>>=20 >>> I believe the question is what types of keys can appear as the = subject >>> public key in an RPKI certificate. >>>=20 >>> -- RFC 6485 says "See 6487" (and thus 6487bis when it is published) >>> to find out what is allowed as a subject public key >>>=20 >>> -- draft-ietf-sidr-bgpsec-pki-profiles updates RFC 6485 and says = "For >>> Router Certs (end-entity certificates use by BGPSEC) see >>> draft-ietf-sidr-bgpsec-algs >>>=20 >>> Ideally, this shouldn't be a problem. RFC 6487 governs subject = public >>> keys for all certificates in the RPKI except BGPSEC router >>> certificates and draft-sidr-bgpsec-algs covers that case. >>>=20 >>> That being said, we currently have two working group documents that >>> update RFC 6485 and I am not sure that it is sufficiently clear in = the >>> text of those documents how the two updates interact. >>>=20 >>> On Mon, Jul 7, 2014 at 4:28 PM, Geoff Huston wrote: >>>> Hi Sean, >>>>=20 >>>> Whats the relationship between this draft and = draft-ietf-sidr-rfc6485bis? >>>>=20 >>>> g >>>>=20 >>>>=20 >>>> On 3 Jul 2014, at 1:36 am, Sean Turner wrote: >>>>=20 >>>>> A minor update to move some references that were in the wrong = place as well as to correctly identify where the OID goes that indicates = the algorithm used in the CRMF (thanks Sandy for pointing these out). = Oh and I updated the dates. >>>>>=20 >>>>> spt >>>>>=20 >>>>> On Jul 02, 2014, at 11:34, internet-drafts@ietf.org wrote: >>>>>=20 >>>>>>=20 >>>>>> A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>> This draft is a work item of the Secure Inter-Domain Routing = Working Group of the IETF. >>>>>>=20 >>>>>> Title : BGP Algorithms, Key Formats, & Signature = Formats >>>>>> Author : Sean Turner >>>>>> Filename : draft-ietf-sidr-bgpsec-algs-07.txt >>>>>> Pages : 7 >>>>>> Date : 2014-07-02 >>>>>>=20 >>>>>> Abstract: >>>>>> This document specifies the algorithms, algorithms' parameters, >>>>>> asymmetric key formats, asymmetric key size and signature format = used >>>>>> in BGPSEC (Border Gateway Protocol Security). This document = updates >>>>>> the Profile for Algorithms and Key Sizes for use in the Resource >>>>>> Public Key Infrastructure (RFC 6485). >>>>>>=20 >>>>>>=20 >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ >>>>>>=20 >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-07 >>>>>>=20 >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-algs-07 >>>>>>=20 >>>>>>=20 >>>>>> Please note that it may take a couple of minutes from the time of = submission >>>>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>>>=20 >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>=20 >>>>>> _______________________________________________ >>>>>> sidr mailing list >>>>>> sidr@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sidr >>>>>=20 >>>>> _______________________________________________ >>>>> sidr mailing list >>>>> sidr@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sidr >>>>=20 >>>> _______________________________________________ >>>> sidr mailing list >>>> sidr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sidr >>=20 From nobody Mon Jul 7 16:33:21 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 974FA1B298B for ; Mon, 7 Jul 2014 16:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 du3eQexP3qhq for ; Mon, 7 Jul 2014 16:33:18 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2831B2988 for ; Mon, 7 Jul 2014 16:33:18 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 370F428B003D for ; Mon, 7 Jul 2014 19:33:18 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 3154A1F8032; Mon, 7 Jul 2014 19:33:18 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_4C001650-1196-4CDD-A9C1-6C7723DE54A5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Mon, 7 Jul 2014 19:33:19 -0400 Message-Id: To: sidr wg list Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/rspzxEVG08CuVI_dbwSNHunGi5I Cc: Sandra Murphy Subject: [sidr] agenda uploaded X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 23:33:19 -0000 --Apple-Mail=_4C001650-1196-4CDD-A9C1-6C7723DE54A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii An agenda has been uploaded. Please notify the chairs of errors, desires for more/less time, = questions, complaints, etc. --Sandy --Apple-Mail=_4C001650-1196-4CDD-A9C1-6C7723DE54A5 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 iQIcBAEBCgAGBQJTuy5AAAoJEHplpQeet0IZaHsQALudX5jweksmfunwrHx9ck2m uKihs+pSJt1gTrWWAPLYnXREcNrCGgFbbPMrYHUogmgtfoTKJ1E8uk6+rYppAywi 1OXwkNSB5rs/aHT4Gj8iDMGgvgaM40rRlv62P68TYXqzqUIh5pIeo0lVyeDOR2ju TzObEbt8/ovq+3YeYA8sGBzDwJSGEwofuLm/V97J4K2+0cp+NmiWIY3qdUKWZwBO zUCMh2r6jBmJpsBrSElcBdop8+PZ6QEATAHr+osoyq7pfPFwgP3IFeqq7VjLFyUJ 0JIDg2OBQD1HBNMjM4nkG7KGNMp5EI/kFq4yHRPQNgYy0OFu71XiQzK42x+bT/hZ t5ZNEKHUgb2wDLex2iEGoOtRSeTDTpU6zAIMK9bSvH0LRog4I+WTcXzoC7CuOtDw UZnUjngdSoMk3dNs/9lf9wXrjedT2+iewEYyrs+U6i5j0sQbgWnAseUj8MaUZgGQ r0j2oO6T9oTOm8p+0vuU+5GQcnVE9b6bCj8svrfVWVQDEaIUc4QRAf4T9PaxWSZD gKpY0Kxlrz4TPrSoT0bhfWB3ZVPzUR4KqPz7KcQpQxwNyWBmR+5YsCYJ+PzKqhjq sbzt8I8omszizx++FCfKjHF7ss+eZoGlGdOmjjywBxRWtQZ/N8TMV8aJWliHrnRe hAD+Svo7imHWBJSZTDo9 =AmJ7 -----END PGP SIGNATURE----- --Apple-Mail=_4C001650-1196-4CDD-A9C1-6C7723DE54A5-- From nobody Mon Jul 7 16:42: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 6017D1B298C for ; Mon, 7 Jul 2014 16:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 dhhxu4wIJgXa for ; Mon, 7 Jul 2014 16:42:49 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id AFAAA1B2990 for ; Mon, 7 Jul 2014 16:42:49 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 6ACFF28B003D; Mon, 7 Jul 2014 19:42:49 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 647331F8032; Mon, 7 Jul 2014 19:42:49 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_5B9E6BED-3890-4585-B57A-4FA7EDA4D72F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: <586E1AFE-895F-40AB-A101-271F07774FA6@apnic.net> Date: Mon, 7 Jul 2014 19:42:51 -0400 Message-Id: References: <20140702153455.10414.45146.idtracker@ietfa.amsl.com> <0CA71605-C46F-4BAE-9646-1AB287549CF8@ieca.com> <0AD801E2-D37B-432C-91FE-7983235468A4@apnic.net> <586E1AFE-895F-40AB-A101-271F07774FA6@apnic.net> To: Geoff Huston X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/Uxt0m1YB1P5Ob_me4d_aiqdWicY Cc: sidr wg list , Sandra Murphy Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-07.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, 07 Jul 2014 23:42:51 -0000 --Apple-Mail=_5B9E6BED-3890-4585-B57A-4FA7EDA4D72F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 7, 2014, at 7:00 PM, Geoff Huston wrote: > the header of draft-ietf-sidr-bgpsec-algs-08 says: > "Updates: 6485 (if approved) " >=20 >=20 > so I'm still confused about the two 6485 update drafts. >=20 >=20 Ah. So your original question was: >=20 > Whats the relationship between this draft and = draft-ietf-sidr-rfc6485bis? So you want to know if bgpsec-algs is updating the original RFC6485 or = updating rfc6485bis? --Sandy, speaking as regular ol' member --Apple-Mail=_5B9E6BED-3890-4585-B57A-4FA7EDA4D72F 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 iQIcBAEBCgAGBQJTuzB7AAoJEHplpQeet0IZLeQQALU1j79ZneH/cq5Jh1x4DfjK R63eoarwx/bg8YQTe+h3qMaQZjtjRBE8ffcN6g+zBOye/oQwYk0lelYDglhWWEcC Os/m7qeK/aHiyGYoXnVPKHecFlOUO+Mx8dP8f5RThPFJYnUbdEBdTJ06vNXaMERP 6sogWs8/mSp4bK92ObZOJYN9Jv7dbVQ4CMVFiFh8jS2b6ywhnFEmCdTIU2pgp0mW FOIgC8N2THmIxiwZ4dP3XUsoTzTmPFiBAXZyd3lbOGovNdXnWwMwVizsbxij5l1k oxFM25CCWTT5gk0csYKyXrLYFu0iue0n6CqCYJLVVnr1VyFZ3ODHky6bNP4rf6Hc 8irmn9nH1p4bKHOI6V7MSJ4zCvK0EnLguhWwSjph3FLFTNvOP+q3FyxWTBje1tEa PS2tTLvDUJzO8ZVQMoU+8Y0/mgjHf6aRr3MAIhFlUTBdO+B03Z/qrtnr0ekn0maN PcS4ODabvMu8yBlqVQhWMfkXNb2tc1Gfil3BE3WVylMlvAah+PU5jkL63xahNDC+ IUfBcSExbCqQtYTPvE72sbgZs0lOOseS9BFGxhEXh9r+mRis893sJNb50MA1aNG5 KxCP4HPghZtpS/c3zPQ+GQ/5FXHInaQGyOc5fwPKWVEzUcoU/2RQA8IjItcQ5Ydh bjoJ7cGFfmH0x62fdD23 =egy/ -----END PGP SIGNATURE----- --Apple-Mail=_5B9E6BED-3890-4585-B57A-4FA7EDA4D72F-- From nobody Mon Jul 7 18:13: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 BBCD31B29B0 for ; Mon, 7 Jul 2014 18:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.342 X-Spam-Level: X-Spam-Status: No, score=0.342 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FSL_HELO_BARE_IP_2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6PI1azv0gAl for ; Mon, 7 Jul 2014 18:12:02 -0700 (PDT) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [69.41.242.28]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9878A1B29A9 for ; Mon, 7 Jul 2014 18:11:38 -0700 (PDT) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id AC223D65D5368; Mon, 7 Jul 2014 20:11:37 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway08.websitewelcome.com (Postfix) with ESMTP id 89C29D65D5302 for ; Mon, 7 Jul 2014 20:11:37 -0500 (CDT) Received: from [96.231.228.7] (port=50891 helo=192.168.1.8) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X4JwR-0006ls-Ow; Mon, 07 Jul 2014 20:11:37 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: Date: Mon, 7 Jul 2014 21:11:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <134C6F51-689E-4BB0-BEF0-8D7F16DA52F9@ieca.com> References: <20140702153455.10414.45146.idtracker@ietfa.amsl.com> <0CA71605-C46F-4BAE-9646-1AB287549CF8@ieca.com> <0AD801E2-D37B-432C-91FE-7983235468A4@apnic.net> <586E1AFE-895F-40AB-A101-271F07774FA6@apnic.net> To: Geoff Huston 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: 96.231.228.7 X-Exim-ID: 1X4JwR-0006ls-Ow X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.8) [96.231.228.7]:50891 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/dGbiF0XQ4mCr1AQ-Yq33t8NhCh8 Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 01:12:02 -0000 On Jul 07, 2014, at 19:42, Sandra Murphy wrote: >=20 > On Jul 7, 2014, at 7:00 PM, Geoff Huston wrote: >=20 >=20 >> the header of draft-ietf-sidr-bgpsec-algs-08 says: >> "Updates: 6485 (if approved) " >>=20 >>=20 >> so I'm still confused about the two 6485 update drafts. >>=20 >>=20 >=20 >=20 > Ah. So your original question was: >=20 >>=20 >> Whats the relationship between this draft and = draft-ietf-sidr-rfc6485bis? >=20 > So you want to know if bgpsec-algs is updating the original RFC6485 or = updating rfc6485bis? draft-ietf-sidr-bgpsec-algs adds support for EC public keys & signature = formats to RFC 6485 for BGPsec. If 6485bis is going to be updated to = include these changes then draft-ietf-sidr-bgpsec-algs can go away but I = didn=92t think that was the plan. Assuming EC algs aren=92t = incorporated in 6485bis then draft-ietf-sidr-bgpsec-algs needs to update = RFC 6485 or any document that obsoletes it. I=92m happy to change the = updates header info to =93Updates: draft-ietf-sidr-rfc6485bis (once = approved)" though if that makes things crystal clear. spt= From nobody Mon Jul 7 18:22:52 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 B131F1B29B4 for ; Mon, 7 Jul 2014 18:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FSL_HELO_BARE_IP_2=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 3t3cwL-qQgCz for ; Mon, 7 Jul 2014 18:22:48 -0700 (PDT) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [64.5.52.12]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD2311B29BE for ; Mon, 7 Jul 2014 18:22:47 -0700 (PDT) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id 7994AD1EA79DF; Mon, 7 Jul 2014 20:22:47 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway09.websitewelcome.com (Postfix) with ESMTP id 4D7E2D1EA795D for ; Mon, 7 Jul 2014 20:22:47 -0500 (CDT) Received: from [96.231.228.7] (port=50931 helo=192.168.1.8) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X4K7K-0005lB-0k; Mon, 07 Jul 2014 20:22:46 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: Date: Mon, 7 Jul 2014 21:22:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Matthew Lepinski 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: 96.231.228.7 X-Exim-ID: 1X4K7K-0005lB-0k X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.8) [96.231.228.7]:50931 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 7 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/Fw55ou3G_hhLFryQ1PYDiEnOqNE Cc: "sidr@ietf.org" Subject: Re: [sidr] New version draft-ietf-sidr-bgpsec-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: Tue, 08 Jul 2014 01:22:49 -0000 WRT integrating the two specs =85 whatever is easier. spt On Jul 07, 2014, at 13:06, Matthew Lepinski = wrote: > Oh, one other thing: >=20 > If anyone on this list thinks that instead of referencing = as-migration, that we are better off merging as-migration into = bgpsec-protocol, this would be a great time to speak up. >=20 > (That is, it is not too late to pull the solution from as-migration = directly into bgpsec-protocol, but if we are going to go down that road, = we should do it as soon as possible!) >=20 >=20 > On Mon, Jul 7, 2014 at 1:03 PM, Matthew Lepinski = wrote: > Wes, >=20 > I agree that inserting a reference in bgpsec-protocol (and = bgpsec-overview) and then publishing as-migration as part of the bgpsec = document set (along with the router certificate profile, the algorithm = document, etc) is a good way forward.=20 >=20 > I need to do a careful review of the latest version of as-migration (I = really haven't looked at the -01). I will get to that before we meet in = Toronto.=20 >=20 > Also, I am open to suggestions with regards to where to insert a = reference to as-migration -- but I will try to suggestion for how to = link the two documents in time for Toronto. >=20 > - Matt Lepinski >=20 >=20 > On Mon, Jul 7, 2014 at 12:40 PM, George, Wes = wrote: >=20 > From: Matthew Lepinski > Date: Friday, July 4, 2014 at 6:16 PM > To: "sidr@ietf.org" > Subject: [sidr] New version draft-ietf-sidr-bgpsec-protocol >=20 > I submitted a new version of the bgpsec protocol document. This = revision includes a fair number of editorial changes but does not = include any normative changes. >=20 > Now that the BGPSEC requirements document is essentially done, I look = forward to discussing the protocol document again in Toronto. In = particular, between now and the Toronto meeting I will write up (and = send to the list) a brief comparison between the requirements in the = final version of the reqs draft and what we deliver in the protocol = document.=20 >=20 > The only open issue in the protocol document that I am aware of is the = following: >=20 > [snip] >=20 > Matt -=20 >=20 > One additional change I think is necessary is to add a reference to = ietf-sidr-as-migration. This is effectively an extension of the BGPSec = protocol that is contained in a separate document. If the BGPSec doc was = already done, I'd most likely be using the metadata of as-migration to = update RFCnnnn so that the link would exist from the BGPSec protocol doc = in addition to the normative reference to -protocol from as=96migration, = but in the current form where it's trivial to update the -protocol = draft, I think that should instead be accomplished by a forward = reference, and then the two documents will simply be part of the group = of interdependent docs that get released for BGPSec (assuming of course = that -as=96migration passes LC). >=20 > That said, my quick scan of =96protocol didn't reveal an obvious place = to insert that reference, so if you or others have ideas of where it = should go, I'm happy to contribute a few lines of wrapper text.=20 >=20 > Thanks, > =20 > Wes >=20 > Anything below this line has been added by my company=92s mail server, = I have no control over it. > ----------- >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Mon Jul 7 21:49: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 B85F21B2A2D for ; Mon, 7 Jul 2014 21:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPj8g-Kw9VCS for ; Mon, 7 Jul 2014 21:49:36 -0700 (PDT) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) by ietfa.amsl.com (Postfix) with SMTP id 8676A1B2A25 for ; Mon, 7 Jul 2014 21:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=HdjULzbD6OFU7kzUOi5PYnYsHxLcuyYLcxeNEY4X6EQ=; b=pCf/IUnxkXVnBg370yGkNZ3DZj7Uqtz2itk6nrM/b4CGKGuJsPHnOpbJawp5e94jyDRLHI7N8HceU Urea2g/Mms4Z2mf/uJ6S+vHHvDFrtjIDFgPJ4DDKH8PHG+LpOt8l9JiFHVA0EOKTK5gD81iL8TjD/K uZvQKT2RczX3BtxQ= Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by nx-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Tue, 8 Jul 2014 14:49:37 +1000 (EST) Received: from [10.1.3.132] (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 8 Jul 2014 14:49:32 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Geoff Huston In-Reply-To: Date: Tue, 8 Jul 2014 14:49:30 +1000 Content-Transfer-Encoding: quoted-printable Message-ID: <6BF5F265-36EB-4D81-B12E-7207147266D3@apnic.net> References: <20140702153455.10414.45146.idtracker@ietfa.amsl.com> <0CA71605-C46F-4BAE-9646-1AB287549CF8@ieca.com> <0AD801E2-D37B-432C-91FE-7983235468A4@apnic.net> <586E1AFE-895F-40AB-A101-271F07774FA6@apnic.net> To: Sandra Murphy X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/x4RlS06OW-hOmAPI7j2xpp9mgpg Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 04:49:37 -0000 well I would like to understand why there appears to be two parallel = efforts to update RFC6485, and it was I suppose a question that is correctly = passed to the chairs, given that the chairs wanted rfc6485bis produced, and I assume that the chairs similarly approved the WG adoption of = bgpsec-algs. The original desire was to isolate the structure and framework from the = crypto, which is why RFC6485 was produced in the first place, but now it appears = that we are fragmenting this and producing multiple crypto profiles. Geoff (I was told recently that the DNS specs now span a few hundred RFCs. For = a widely deployed active protocol I can kinda see that, but I'm not sure that there is = merit in SIDR at this point in time to take this same quantity of RFCs as an objective! :-) ) On 8 Jul 2014, at 9:42 am, Sandra Murphy wrote: >=20 > On Jul 7, 2014, at 7:00 PM, Geoff Huston wrote: >=20 >=20 >> the header of draft-ietf-sidr-bgpsec-algs-08 says: >> "Updates: 6485 (if approved) " >>=20 >>=20 >> so I'm still confused about the two 6485 update drafts. >>=20 >>=20 >=20 >=20 > Ah. So your original question was: >=20 >>=20 >> Whats the relationship between this draft and = draft-ietf-sidr-rfc6485bis? >=20 > So you want to know if bgpsec-algs is updating the original RFC6485 or = updating rfc6485bis? >=20 > --Sandy, speaking as regular ol' member From nobody Mon Jul 7 22:02:51 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 F036A1B2A3D for ; Mon, 7 Jul 2014 22:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcIpE-LiwiCN for ; Mon, 7 Jul 2014 22:02:15 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 406181B2A38 for ; Mon, 7 Jul 2014 22:02:14 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi2so268730wib.7 for ; Mon, 07 Jul 2014 22:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ucI/0fsftvc+39L/S6ji061upZ956KSIKyQrfNl2Egk=; b=IVPh8Zsyy8h54/HIszuAOJ77uFZWDf8oxhvRrJcO9affIyFPTZ4kG6/8y8r4us3Cha Wmn66xFcAiU5TfOcYVqOnby7+Ih/XJQAolrb4NLzkCaA6pvOsYm5SKVI/BY2S4asylW6 1jksF1K2Z7Wfx7aiwhG3dqf7YU66c0aNTTgC/FhZ+3Jvwj2SbiraJShWx/r833ZbECfx 4QS7LKrVqvULw3upaFpZ7Bapw/cvFKNOM7GRjuWVV/pOIseFCPkkGn+UauOFnrnFilpp Sg895TyXGdMAwemKIHtEM4/+7HTsx0BzrRCs/MQ6FsGNM1Qxk6cR97nzvBgsSJtyuK1M 8Vjg== MIME-Version: 1.0 X-Received: by 10.180.92.65 with SMTP id ck1mr1011233wib.48.1404795733679; Mon, 07 Jul 2014 22:02:13 -0700 (PDT) Received: by 10.216.148.138 with HTTP; Mon, 7 Jul 2014 22:02:13 -0700 (PDT) In-Reply-To: <6BF5F265-36EB-4D81-B12E-7207147266D3@apnic.net> References: <20140702153455.10414.45146.idtracker@ietfa.amsl.com> <0CA71605-C46F-4BAE-9646-1AB287549CF8@ieca.com> <0AD801E2-D37B-432C-91FE-7983235468A4@apnic.net> <586E1AFE-895F-40AB-A101-271F07774FA6@apnic.net> <6BF5F265-36EB-4D81-B12E-7207147266D3@apnic.net> Date: Tue, 8 Jul 2014 01:02:13 -0400 Message-ID: From: Matthew Lepinski To: Geoff Huston Content-Type: multipart/alternative; boundary=f46d043c8076b0232904fda77e2f Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/Wo_HheOit8TjRaq1cRrOHtIDjPw Cc: Sandra Murphy , sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 05:02:39 -0000 --f46d043c8076b0232904fda77e2f Content-Type: text/plain; charset=UTF-8 So I have no preference with regards to one document or two. (That is, if the working group wants to merge the BGPSec algs document with 6485bis, I see nothing wrong with fewer documents.) However, I believe that there is a good reason to have a distinct set of algorithms for creating BGPSEC signatures and for signing RPKI certificates. In particular, the devices that we envision producing BGPSEC signatures are different than the devices that are currently signing RPKI certificates. Additionally, signature length seems to be a non issue today with regards to signing RPKI certificates, but signature length is a more important consideration for BGPSEC signatures. That is, the trade offs in what makes a good signature algorithm are somewhat different when it comes to BGPSEC and I don't think we want to artificially force the two signature algorithms (for RPKI certs and for BGPSEC) to be the same. That is the original reason for producing the bgpsec-algs document (of course, this document was first written before it became clear that we needed to do a bis for 6485, and so perhaps it we should revisit whether we want one document or two). - Matt Lepinski On Jul 8, 2014 12:49 AM, "Geoff Huston" wrote: > well I would like to understand why there appears to be two parallel > efforts > to update RFC6485, and it was I suppose a question that is correctly passed > to the chairs, given that the chairs wanted rfc6485bis produced, and > I assume that the chairs similarly approved the WG adoption of bgpsec-algs. > > The original desire was to isolate the structure and framework from the > crypto, > which is why RFC6485 was produced in the first place, but now it appears > that we > are fragmenting this and producing multiple crypto profiles. > > > Geoff > > > (I was told recently that the DNS specs now span a few hundred RFCs. For a > widely deployed > active protocol I can kinda see that, but I'm not sure that there is merit > in SIDR at this > point in time to take this same quantity of RFCs as an objective! :-) ) > > > > > > > > On 8 Jul 2014, at 9:42 am, Sandra Murphy wrote: > > > > > On Jul 7, 2014, at 7:00 PM, Geoff Huston wrote: > > > > > >> the header of draft-ietf-sidr-bgpsec-algs-08 says: > >> "Updates: 6485 (if approved) " > >> > >> > >> so I'm still confused about the two 6485 update drafts. > >> > >> > > > > > > Ah. So your original question was: > > > >> > >> Whats the relationship between this draft and > draft-ietf-sidr-rfc6485bis? > > > > So you want to know if bgpsec-algs is updating the original RFC6485 or > updating rfc6485bis? > > > > --Sandy, speaking as regular ol' member > > --f46d043c8076b0232904fda77e2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

So I have no preference with regards to one= document or two. (That is, if the working group wants to merge the BGPSec = algs document with 6485bis, I see nothing wrong with fewer documents.)

However, I believe that there is a good reason to have a dis= tinct set of algorithms for creating BGPSEC signatures and for signing RPKI= certificates. In particular, the devices that we envision producing BGPSEC= signatures are different than the devices that are currently signing RPKI = certificates. Additionally, signature length seems to be a non issue today = with regards to signing RPKI certificates, but signature length is a more i= mportant consideration for BGPSEC signatures. That is, the trade offs in wh= at makes a good signature algorithm are somewhat different when it comes to= BGPSEC and I don't think we want to artificially force the two signatu= re algorithms (for RPKI certs and for BGPSEC) to be the same. That is the o= riginal reason for producing the bgpsec-algs document (of course, this docu= ment was first written before it became clear that we needed to do a bis fo= r 6485, and so perhaps it we should revisit whether we want one document or= two).

- Matt Lepinski

On Jul 8, 2014 12:49 AM, "Geoff Huston"= ; <gih@apnic.net&= gt; wrote:
well I would like to understand why there appears to be two parallel effort= s
to update RFC6485, and it was I suppose a question that is correctly passed=
to the chairs, given that the chairs wanted rfc6485bis produced, and
I assume that the chairs similarly approved the WG adoption of bgpsec-algs.=

The original desire was to isolate the structure and framework from the cry= pto,
which is why RFC6485 was produced in the first place, but now it appears th= at we
are fragmenting this and producing multiple crypto profiles.


Geoff


(I was told recently that the DNS specs now span a few hundred RFCs. For a = widely deployed
active protocol I can kinda see that, but I'm not sure that there is me= rit in SIDR at this
point in time to take this same quantity of RFCs as an objective! :-) )







On 8 Jul 2014, at 9:42 am, Sandra Murphy <sandy@tislabs.com> wrote:

>
> On Jul 7, 2014, at 7:00 PM, Geoff Huston <gih@apnic.net> wrote:
>
>
>> the header of draft-ietf-sidr-bgpsec-algs-08 says:
>> =C2=A0 "Updates: 6485 (if approved) "
>>
>>
>> so I'm still confused about the two 6485 update drafts.
>>
>>
>
>
> Ah. =C2=A0So your original question was:
>
>>
>> Whats the relationship between this draft and draft-ietf-sidr-rfc6= 485bis?
>
> So you want to know if bgpsec-algs is updating the original RFC6485 or= updating rfc6485bis?
>
> --Sandy, speaking as regular ol' member

--f46d043c8076b0232904fda77e2f-- From nobody Mon Jul 7 22:07:32 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 C788A1B2A35 for ; Mon, 7 Jul 2014 22:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXf6T6M5Ku25 for ; Mon, 7 Jul 2014 22:07:27 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) by ietfa.amsl.com (Postfix) with SMTP id 394461B2A33 for ; Mon, 7 Jul 2014 22:07:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=DdrpERSgRmQd3IRG/zk3SP646EKQLDHz2TtFG9pTJ8k=; b=5HxUiaEHrufumNA4U9rchfvkd1VzdLlmmy78FofsVQF4CUltR9tIGpf8KOyFFU0hS61AIcuM9zLzf 1+atM4N8OhNJoRmFRoNotNxWXfwSunW4rmgbc9/oBy2kKbnv6tMQ1rF9CkymLNEzPekBpxjmhPgQ+W AHEvqAIi1JwHZ4y8= Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Tue, 8 Jul 2014 15:07:24 +1000 (EST) Received: from [10.1.3.132] (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 8 Jul 2014 15:07:24 +1000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Geoff Huston In-Reply-To: <134C6F51-689E-4BB0-BEF0-8D7F16DA52F9@ieca.com> Date: Tue, 8 Jul 2014 15:07:23 +1000 Content-Transfer-Encoding: quoted-printable Message-ID: <4028EFDE-4831-4C76-BA1A-E5B21CCBFCF9@apnic.net> References: <20140702153455.10414.45146.idtracker@ietfa.amsl.com> <0CA71605-C46F-4BAE-9646-1AB287549CF8@ieca.com> <0AD801E2-D37B-432C-91FE-7983235468A4@apnic.net> <586E1AFE-895F-40AB-A101-271F07774FA6@apnic.net> <134C6F51-689E-4BB0-BEF0-8D7F16DA52F9@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/owO1dgczWOQLft7s0WjJmJNoLYE Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 05:07:29 -0000 Personal opinion: I think SIDR is already densely littered with a LOT of specification = documents, and=20 we are now at a stage where maintaing internal consistency across these = specs is a=20 real challenge. Indeed even now there is a need for a SIDR Roadmap to = explain the set of documents we have and their inter-relationship. I would prefer to see fewer documents, not more, and I think the two = update efforts in 6485 should be merged. Geoff On 8 Jul 2014, at 11:11 am, Sean Turner wrote: > On Jul 07, 2014, at 19:42, Sandra Murphy wrote: >=20 >>=20 >> On Jul 7, 2014, at 7:00 PM, Geoff Huston wrote: >>=20 >>=20 >>> the header of draft-ietf-sidr-bgpsec-algs-08 says: >>> "Updates: 6485 (if approved) " >>>=20 >>>=20 >>> so I'm still confused about the two 6485 update drafts. >>>=20 >>>=20 >>=20 >>=20 >> Ah. So your original question was: >>=20 >>>=20 >>> Whats the relationship between this draft and = draft-ietf-sidr-rfc6485bis? >>=20 >> So you want to know if bgpsec-algs is updating the original RFC6485 = or updating rfc6485bis? >=20 > draft-ietf-sidr-bgpsec-algs adds support for EC public keys & = signature formats to RFC 6485 for BGPsec. If 6485bis is going to be = updated to include these changes then draft-ietf-sidr-bgpsec-algs can go = away but I didn=92t think that was the plan. Assuming EC algs aren=92t = incorporated in 6485bis then draft-ietf-sidr-bgpsec-algs needs to update = RFC 6485 or any document that obsoletes it. I=92m happy to change the = updates header info to =93Updates: draft-ietf-sidr-rfc6485bis (once = approved)" though if that makes things crystal clear. >=20 > spt From nobody Mon Jul 7 22:13: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 8B15C1B2A35 for ; Mon, 7 Jul 2014 22:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMkHkvCR8Dee for ; Mon, 7 Jul 2014 22:13:24 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) by ietfa.amsl.com (Postfix) with SMTP id 79F101B2A34 for ; Mon, 7 Jul 2014 22:13:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=TtTxMstyr8Up1HzB4X/kQG4wd8m1nF/t8+lVOO2OnFQ=; b=Qj7ZMmCai1AD9QuqJeU2OuLRGvV98iaaYByRZeqYc8IYy+k4A3tqvaH3VNoXUapJFEA16BWwxuq86 N7bIgQqnQKDjpJjdZtUbOQdfXDV2MWVpZvwEX1qG7/45yiz0AtviMs9NbFq2QtXun4/6rWq2di26fL hvIH+FxkY/xkB1bA= Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Tue, 8 Jul 2014 15:13:20 +1000 (EST) Received: from [10.1.3.132] (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 8 Jul 2014 15:13:20 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Geoff Huston In-Reply-To: Date: Tue, 8 Jul 2014 15:13:19 +1000 Content-Transfer-Encoding: quoted-printable Message-ID: <7901F9DB-74DF-48F1-8107-09C25B872D6C@apnic.net> References: <20140702153455.10414.45146.idtracker@ietfa.amsl.com> <0CA71605-C46F-4BAE-9646-1AB287549CF8@ieca.com> <0AD801E2-D37B-432C-91FE-7983235468A4@apnic.net> <586E1AFE-895F-40AB-A101-271F07774FA6@apnic.net> <6BF5F265-36EB-4D81-B12E-7207147266D3@apnic.net> To: Matthew Lepinski X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/M8rTh7mQeLDX2B53LhQOe8zwsWQ Cc: Sandra Murphy , sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 05:13:25 -0000 On 8 Jul 2014, at 3:02 pm, Matthew Lepinski = wrote: > So I have no preference with regards to one document or two. (That is, = if the working group wants to merge the BGPSec algs document with = 6485bis, I see nothing wrong with fewer documents.) >=20 > However, I believe that there is a good reason to have a distinct set = of algorithms for creating BGPSEC signatures and for signing RPKI = certificates. I can understand that perspective, and it makes sense to me, But that = does not necessarily imply two RFCs. I think we need to keep an eye on = the entire framework, and as we add pieces to the RPKI we should clearly = understand where and how they interlock. For that reason, I would like = to see a single RPKI algorithms and key length spec that encompasses the = entire RPKI use domain. If there is a need to split this document to = make the distinction between use in the certificate and authority domain = and use within the router-to-router domain then thats fine, but that = split would (in my opinion) be within a single specification document, = rather than more documents. Geoff > In particular, the devices that we envision producing BGPSEC = signatures are different than the devices that are currently signing = RPKI certificates. Additionally, signature length seems to be a non = issue today with regards to signing RPKI certificates, but signature = length is a more important consideration for BGPSEC signatures. That is, = the trade offs in what makes a good signature algorithm are somewhat = different when it comes to BGPSEC and I don't think we want to = artificially force the two signature algorithms (for RPKI certs and for = BGPSEC) to be the same. That is the original reason for producing the = bgpsec-algs document (of course, this document was first written before = it became clear that we needed to do a bis for 6485, and so perhaps it = we should revisit whether we want one document or two). >=20 > - Matt Lepinski >=20 > On Jul 8, 2014 12:49 AM, "Geoff Huston" wrote: > well I would like to understand why there appears to be two parallel = efforts > to update RFC6485, and it was I suppose a question that is correctly = passed > to the chairs, given that the chairs wanted rfc6485bis produced, and > I assume that the chairs similarly approved the WG adoption of = bgpsec-algs. >=20 > The original desire was to isolate the structure and framework from = the crypto, > which is why RFC6485 was produced in the first place, but now it = appears that we > are fragmenting this and producing multiple crypto profiles. >=20 >=20 > Geoff >=20 >=20 > (I was told recently that the DNS specs now span a few hundred RFCs. = For a widely deployed > active protocol I can kinda see that, but I'm not sure that there is = merit in SIDR at this > point in time to take this same quantity of RFCs as an objective! :-) = ) >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 8 Jul 2014, at 9:42 am, Sandra Murphy wrote: >=20 > > > > On Jul 7, 2014, at 7:00 PM, Geoff Huston wrote: > > > > > >> the header of draft-ietf-sidr-bgpsec-algs-08 says: > >> "Updates: 6485 (if approved) " > >> > >> > >> so I'm still confused about the two 6485 update drafts. > >> > >> > > > > > > Ah. So your original question was: > > > >> > >> Whats the relationship between this draft and = draft-ietf-sidr-rfc6485bis? > > > > So you want to know if bgpsec-algs is updating the original RFC6485 = or updating rfc6485bis? > > > > --Sandy, speaking as regular ol' member >=20 From nobody Tue Jul 8 11:17:54 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 662111A03D1 for ; Tue, 8 Jul 2014 11:17:52 -0700 (PDT) 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 XdTZwpJK2En1 for ; Tue, 8 Jul 2014 11:17:51 -0700 (PDT) Received: from mail.mikesoffice.com (dns.mikesoffice.com [75.101.48.145]) by ietfa.amsl.com (Postfix) with ESMTP id 2E94A1A038D for ; Tue, 8 Jul 2014 11:17:51 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f05:274:3e97:eff:feba:52f]) by mail.mikesoffice.com (Postfix) with ESMTPSA id C0BE3610A6; Tue, 8 Jul 2014 11:17:50 -0700 (PDT) From: Michael Baer To: Matthew Lepinski References: X-Face: "*g#dUT3; 8M9AE5dLk\\b4G\cNCQkRb.g/2QwEXQKf.: (Matthew Lepinski's message of "Fri, 4 Jul 2014 18:16:17 -0400") Message-ID: <87bnszaf5d.fsf@rebma.mikesoffice.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/0qS5fmKGTnhjKAwpoFuGnF_FHo0 Cc: "sidr@ietf.org" Subject: Re: [sidr] New version draft-ietf-sidr-bgpsec-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: Tue, 08 Jul 2014 18:17:52 -0000 >>>>> On Fri, 4 Jul 2014 18:16:17 -0400, Matthew Lepinski said: ML> I submitted a new version of the bgpsec protocol document. This ML> revision includes a fair number of editorial changes but does ML> not include any normative changes. ML> Now that the BGPSEC requirements document is essentially done, I ML> look forward to discussing the protocol document again in ML> Toronto. In particular, between now and the Toronto meeting I ML> will write up (and send to the list) a brief comparison between ML> the requirements in the final version of the reqs draft and what ML> we deliver in the protocol document. ML> The only open issue in the protocol document that I am aware of ML> is the following: ML> * It was suggested in a review that we should explicitly specify ML> (when we discuss error handling) that an implementation send a ML> BGP NOTIFICATION message when an error occurs. ML> Personally, I don't think this is necessary. (In particular, my ML> reading of draft-ietf-idr-error-handling-13 is that in the ML> "treat as withdrawal" case that a NOTIFICATION message is not ML> required. I'm working on a BGPSEC implementation and I've made some comments on error handling in the past. If it is my comment you are mentioning, then that wasn't quite what I meant. In any case, I agree that not all errors should behave the same. I do think that for a specific error case, the error handling description should explicitly state whether or not a notification should be sent for that type of error. E.g., when 'A' happens a notification SHOULD (or SHOULD NOT) be sent. I think the previous update together with the reference to the idr-error-handling draft answered the issues I had. Looking through the 09 draft's version of UPDATE message error handling, the edits have only made it clearer. One minor thing I think is missing is a description of how to handle multiple BGPSEC_Path attributes. Without it, I believe the default response would be a session reset, but a treat-as-withdraw would be more consistent. My reading of idr-error-handling is that 2+ AS_PATH attributes, or an AS_PATH and BGPSEC_PATH attribute in an UPDATE message would indicate a treat-as-withdraw. But without a description of the handling of multiple BGPSEC_PATH attributes in the bgpsec-protocol doc, 2+ BGPSEC_PATH attributes would indicate a session-reset. ML> That being said, I am very willing to defer to the BGP experts ML> in the group on this issue. In particular, does anyone know if ML> the intention of draft-ietf-idr-error-handling is for a ML> NOTIFICATION to be sent when an error is "treat as withdrawal"? ML> (I am concerned that sending a NOTIFICATION message in a case ML> where we are not closing the session is not a good idea, but I ML> am certain that others know more about these details than I do.) I'm not sure about the intention of idr-error-handling draft. But FWIW, my reading of the draft is that a session-reset MUST send a notification. A treat-as-withdraw would not normally send a notification, but could for a specific case. I'm using that interpretation when reading the bgpsec-protocol draft. I.e., A treat-as-withdraw indicates no notification is sent unless otherwise specified. -Mike -- Michael Baer baerm@tislabs.com Senior Software Engineer Parsons Global Shared Services, Cyber Security Division C: 530.902.3131 From nobody Tue Jul 8 12:02: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 521481A02D8 for ; Tue, 8 Jul 2014 12:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 HQX7ZSLvr2yT for ; Tue, 8 Jul 2014 12:02:03 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id EACFA1A0251 for ; Tue, 8 Jul 2014 12:02:02 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 842F628B003D; Tue, 8 Jul 2014 15:02:02 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 7C4B61F8032; Tue, 8 Jul 2014 15:02:02 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8A98BEC9-6D6C-4502-874E-08D9C4C0BD98"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: <134C6F51-689E-4BB0-BEF0-8D7F16DA52F9@ieca.com> Date: Tue, 8 Jul 2014 15:02:02 -0400 Message-Id: <25CFFE15-BA13-488D-92B1-47B53B82AD44@tislabs.com> References: <20140702153455.10414.45146.idtracker@ietfa.amsl.com> <0CA71605-C46F-4BAE-9646-1AB287549CF8@ieca.com> <0AD801E2-D37B-432C-91FE-7983235468A4@apnic.net> <586E1AFE-895F-40AB-A101-271F07774FA6@apnic.net> <134C6F51-689E-4BB0-BEF0-8D7F16DA52F9@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/Z8dptjaWxQVZmUklAxW3JVY2HyM Cc: sidr wg list , Sandra Murphy Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 19:02:04 -0000 --Apple-Mail=_8A98BEC9-6D6C-4502-874E-08D9C4C0BD98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 7, 2014, at 9:11 PM, Sean Turner wrote: > On Jul 07, 2014, at 19:42, Sandra Murphy wrote: >=20 >>=20 >> On Jul 7, 2014, at 7:00 PM, Geoff Huston wrote: >>>=20 >>> Whats the relationship between this draft and = draft-ietf-sidr-rfc6485bis? >>=20 >> So you want to know if bgpsec-algs is updating the original RFC6485 = or updating rfc6485bis? >=20 > draft-ietf-sidr-bgpsec-algs adds support for EC public keys & = signature formats to RFC 6485 for BGPsec. If 6485bis is going to be = updated to include these changes then draft-ietf-sidr-bgpsec-algs can go = away but I didn=92t think that was the plan. Assuming EC algs aren=92t = incorporated in 6485bis then draft-ietf-sidr-bgpsec-algs needs to update = RFC 6485 or any document that obsoletes it. I=92m happy to change the = updates header info to =93Updates: draft-ietf-sidr-rfc6485bis (once = approved)" though if that makes things crystal clear. >=20 The rfc6485bis draft is intended to clean up errors in RFC6485. That = should progress. Implementations already comply with the corrected = text. The bgpsec-algs draft is adding new algorithms to be used in new RPKI = objects and in the bgpsec protocol. The bgpsec-algs draft should be = updating the rfc6485bis document. As there's still work in progress = here, there should be no problem with the order of publication. I can = see that there are several references to RFC6485 in bgpsec-algs that = will have to take the final publication of rfc6485bis draft into = account, in order to clear up the relationships. --Sandy, speaking for the wg co-chairs --Apple-Mail=_8A98BEC9-6D6C-4502-874E-08D9C4C0BD98 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 iQIcBAEBCgAGBQJTvEAqAAoJEHplpQeet0IZch4P/3J3vSq6LWEsvYvURB4AyH0E 8NqlxazGBQ1a8y46aNMV3yCqBJZfR/pszstQVuuQlzPKdojqzoiU8jtLezzEF+Id 4dow3iFJcBZamQNp7oLsJ8n5auKzhkq/6iMYQXV+adE1I/mKBt0j6bo/yhWCEu4f W7/63n9Jtz8BwNcDa9naJ2UeZZ6m6az8Xb6rdB26dyUICoppDEk4j9KgLNeSiPZW /lZDE1yC4rLVLwHTYPbP4K5v/lxvUtgCuK8WEsq/AniZ2LMBxJ5G9CafL/7bmoIA tsi3/ZZtLjRaNpEEHcUmfILcwg6J0LoyERhMZaUwsGgKzsFYdjLF6+iY1114kjoJ aKZ9+ktCYbcECnFCCCgLZO5s4BhJLjXt63DYsqfUQp3RVvYJGumel8/JxIxdzHch eiyxDrGPx8kI1SRGd+cPP23uU5Ae2lyLliFzq7B94OVitr/dfy5toW+tIeKs6M31 t5ieGehqxgEpiOu3x8IOjxreMdXtuvZKBJEQiVRaiA4dG24s2Xx7BUhTPQNHgDCc TeOJ7LEjqmQPezf1npm8koxXfB9S3MREjYSNv/lbdeYnFqpbAY/2Y+AHglMmtGFw PTj/LIrrVGmM5A92kcuVuvkFrTdvQi681rfOA4xNt1aSsZnIfCaOMml5Kh+p6wbQ veBh8oMLQ8AVLNC1NN6i =UzlS -----END PGP SIGNATURE----- --Apple-Mail=_8A98BEC9-6D6C-4502-874E-08D9C4C0BD98-- From nobody Tue Jul 8 13:23:42 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 540B31A0025 for ; Tue, 8 Jul 2014 13:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6XBV4ZKSSZw for ; Tue, 8 Jul 2014 13:23:39 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) by ietfa.amsl.com (Postfix) with SMTP id 207951A000F for ; Tue, 8 Jul 2014 13:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=Xi3Bbz8NB58PydQpvDUOB+VslGDpubPR3bnUVgyhMeE=; b=tq9Bqqy9fCQlZjufaxRLDxm8jvCyV9T6s5ULcNKq2mzr6gbI850sB/HcXB3QQsVCZwUFXN4UzoBN/ 5pI1VZM+Ku3XtyKEensOpOW6O0e7HAuNpFbff/hjwxRkYXtIHSc2qIroH4QaKyDTxg424Ed2Se2OH3 8bDis/OaGRTWXVWc= Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Wed, 9 Jul 2014 06:23:35 +1000 (EST) Received: from [10.1.3.132] (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 9 Jul 2014 06:23:36 +1000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Geoff Huston In-Reply-To: <25CFFE15-BA13-488D-92B1-47B53B82AD44@tislabs.com> Date: Wed, 9 Jul 2014 06:23:34 +1000 Content-Transfer-Encoding: quoted-printable Message-ID: <7CDFEAF1-5715-4F11-B6E6-067D7B515426@apnic.net> References: <20140702153455.10414.45146.idtracker@ietfa.amsl.com> <0CA71605-C46F-4BAE-9646-1AB287549CF8@ieca.com> <0AD801E2-D37B-432C-91FE-7983235468A4@apnic.net> <586E1AFE-895F-40AB-A101-271F07774FA6@apnic.net> <134C6F51-689E-4BB0-BEF0-8D7F16DA52F9@ieca.com> <25CFFE15-BA13-488D-92B1-47B53B82AD44@tislabs.com> To: Sandra Murphy X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/ZBeLpnqjeN_jMk4l2r1JWCFCysc Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 20:23:41 -0000 On 9 Jul 2014, at 5:02 am, Sandra Murphy wrote: >=20 > On Jul 7, 2014, at 9:11 PM, Sean Turner wrote: >=20 >> On Jul 07, 2014, at 19:42, Sandra Murphy wrote: >>=20 >>>=20 >>> On Jul 7, 2014, at 7:00 PM, Geoff Huston wrote: >>>>=20 >>>> Whats the relationship between this draft and = draft-ietf-sidr-rfc6485bis? >>>=20 >>> So you want to know if bgpsec-algs is updating the original RFC6485 = or updating rfc6485bis? >>=20 >> draft-ietf-sidr-bgpsec-algs adds support for EC public keys & = signature formats to RFC 6485 for BGPsec. If 6485bis is going to be = updated to include these changes then draft-ietf-sidr-bgpsec-algs can go = away but I didn=92t think that was the plan. Assuming EC algs aren=92t = incorporated in 6485bis then draft-ietf-sidr-bgpsec-algs needs to update = RFC 6485 or any document that obsoletes it. I=92m happy to change the = updates header info to =93Updates: draft-ietf-sidr-rfc6485bis (once = approved)" though if that makes things crystal clear. >>=20 >=20 > The rfc6485bis draft is intended to clean up errors in RFC6485. That = should progress. Implementations already comply with the corrected = text. >=20 > The bgpsec-algs draft is adding new algorithms to be used in new RPKI = objects and in the bgpsec protocol. The bgpsec-algs draft should be = updating the rfc6485bis document. As there's still work in progress = here, there should be no problem with the order of publication. I can = see that there are several references to RFC6485 in bgpsec-algs that = will have to take the final publication of rfc6485bis draft into = account, in order to clear up the relationships. >=20 this seems to me to be a deliberate decision to proliferate more = documents. - we are updating rfc6485 to clean up an error - we are updating rfc6485 to add crypto profiles for BGPSEC router use And out of this the chair is saying "lets have TWO documents", = RFC6485bis and RFC6485bisupdate If this is what you are saying, then as a WG member I strongly disagree = with this edict from the chair. We should consider the poor consumer of = our various efforts and try to consolidate our work, and not proliferate = the madness across many documents in such a profligate manner! (0.5 :-)) Geoff= From nobody Tue Jul 8 13:57:11 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 7CFD81A0067 for ; Tue, 8 Jul 2014 13:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 zwdke3Jux5FQ for ; Tue, 8 Jul 2014 13:57:06 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id D3D161A005D for ; Tue, 8 Jul 2014 13:57:05 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 840D528B0017; Tue, 8 Jul 2014 16:57:05 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 7D3CD1F8032; Tue, 8 Jul 2014 16:57:05 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_16FCBD2E-C612-4430-BB3D-4114AD313DEC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: <7CDFEAF1-5715-4F11-B6E6-067D7B515426@apnic.net> Date: Tue, 8 Jul 2014 16:57:05 -0400 Message-Id: References: <20140702153455.10414.45146.idtracker@ietfa.amsl.com> <0CA71605-C46F-4BAE-9646-1AB287549CF8@ieca.com> <0AD801E2-D37B-432C-91FE-7983235468A4@apnic.net> <586E1AFE-895F-40AB-A101-271F07774FA6@apnic.net> <134C6F51-689E-4BB0-BEF0-8D7F16DA52F9@ieca.com> <25CFFE15-BA13-488D-92B1-47B53B82AD44@tislabs.com> <7CDFEAF1-5715-4F11-B6E6-067D7B515426@apnic.net> To: Geoff Huston X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/oQp2DcGhV1qteY2OAo8_3eFh_IU Cc: sidr wg list , Sandra Murphy Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 20:57:08 -0000 --Apple-Mail=_16FCBD2E-C612-4430-BB3D-4114AD313DEC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 8, 2014, at 4:23 PM, Geoff Huston wrote: >=20 > On 9 Jul 2014, at 5:02 am, Sandra Murphy wrote: >=20 >>=20 >> The rfc6485bis draft is intended to clean up errors in RFC6485. That = should progress. Implementations already comply with the corrected = text. >>=20 >> The bgpsec-algs draft is adding new algorithms to be used in new RPKI = objects and in the bgpsec protocol. The bgpsec-algs draft should be = updating the rfc6485bis document. As there's still work in progress = here, there should be no problem with the order of publication. I can = see that there are several references to RFC6485 in bgpsec-algs that = will have to take the final publication of rfc6485bis draft into = account, in order to clear up the relationships. >>=20 >=20 > this seems to me to be a deliberate decision to proliferate more = documents. >=20 > - we are updating rfc6485 to clean up an error >=20 > - we are updating rfc6485 to add crypto profiles for BGPSEC router use >=20 > And out of this the chair is saying "lets have TWO documents", = RFC6485bis and RFC6485bisupdate >=20 > If this is what you are saying, then as a WG member I strongly = disagree with this edict from the chair. We should consider the poor = consumer of our various efforts and try to consolidate our work, and not = proliferate the madness across many documents in such a profligate = manner! (0.5 :-)) The RFC6485bis draft corrects errors, where the error corrections are = known.=20 The bgpsec-algs document is new stuff and not yet completely worked out = and not yet implemented or in use. I see those as two different separable issues and do not want to see the = error correction wait for, confused with, the bgpsec-algs completion. RFC6485 is in use and deployment in the RPKI origin validation, as will = the eventual RFC6485bis. The additional algorithms in bgpsec-algs will = be used in path validation in the bgpsec protocol, not in origin = validation. The uses are separable. =20 --Sandy, speaking as one of the co-chairs --Apple-Mail=_16FCBD2E-C612-4430-BB3D-4114AD313DEC 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 iQIcBAEBCgAGBQJTvFshAAoJEHplpQeet0IZ5JgQAMCzZYC3nXnB4wXspT35o0QL Hgt+0rU1+PwbA4YQQNb1lcuBxlqm4VJm+PEXCzoY/kigYdN9gEgam9iTns0tdCnz fNa/+Jr9PUCEq06WKpEtQL7Jlh4EdFdqYTK0tShdhUlmltbgYG1eSJ/uLKIE5I3e WDUQePjek65rgdcSgtLWT6vnXhkPgdz9VKC15NqOWtUmAInKfnunHsJ7qVbAvork bjkrUi/vRerAsgs3bPVpuZJZ7kVoflC3zjSEIa78vunlaAD5h/REEfRUi33y7Q/7 7QcwchPzEbsN8r5VxVsjyPJ/KEjvkZtzqwL36sLnSWpzzc9Z++iKcJcreWeXgeQe uZQj/cLLh6jQQ1EJW9tGcqKunhATDOoPJ6vL0Gk8H1aNX2L4c9ga3G5Jo+Z8jBdO J2cQJg9V93cErLtnlDlphKhkogAXd3TfI80jbWtjawE9tPPNP0bbNr7a//9ql/v5 oeHPKb6gYrNR9ED7K1wLss0qIv1dwzNxR6dhezLkffB+puGbPM+E8fgVOS7kWKMK F6smPwLuHqHyZWB3ATULKV2frKx+0vE/sKpZwVJtM3KQ6K1CQoBT1nM5VbdVLvHV zPfs1iFEDpSM8FXG4T4PXqpk5Xa2oZPdiJzREBXx1F+jYzQ1t60PdMiJSjXbzoR/ YILdv7QkcY/EMw7l910T =L5XW -----END PGP SIGNATURE----- --Apple-Mail=_16FCBD2E-C612-4430-BB3D-4114AD313DEC-- From nobody Thu Jul 10 05:54:03 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 6C8EA1B28E5 for ; Thu, 10 Jul 2014 05:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, WEIRD_PORT=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 7EG1EVEm2tql for ; Thu, 10 Jul 2014 05:53:47 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A0591B28E4 for ; Thu, 10 Jul 2014 05:53:47 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1X5Dr6-0001AD-KM for sidr@ietf.org; Thu, 10 Jul 2014 14:53:46 +0200 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-204.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1X5Dr6-0007bN-H5; Thu, 10 Jul 2014 14:53:44 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_C29AFFAD-3AF9-40D1-9D58-1ECF453F92E4" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Tim Bruijnzeels In-Reply-To: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> Date: Thu, 10 Jul 2014 14:53:45 +0200 Message-Id: <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> To: "sidr@ietf.org list" X-Mailer: Apple Mail (2.1510) X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.5 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 WEIRD_PORT URI: Uses non-standard port number for HTTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719137ca9e7e711d1e63e66fc3a9d4d038d Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/0nIKfIPymd4ixADpQoP1OOrKSyk Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 12:53:51 -0000 --Apple-Mail=_C29AFFAD-3AF9-40D1-9D58-1ECF453F92E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, As you may have noticed my name was added to the author list, so it will = come as no surprise that I read this document and agree with its = content. I believe that all RIRs share both operational concerns outlined in = section 3: (1) Operational fragility, and (2) resource transfers. One = thing to note about the second case is that we don't have this problem = right now because we only offer a hosted service where our members = cannot create delegated certificates. However, this will change when we = enable the provisioning (up-down) system and support non-hosted CAs that = may delegate further. Section 4 describes, in very general terms, two alternative approaches = to counter these concerns. The first approach has my strong preference. I believe it's simple to = explain and implement, effective against both concerns, and I do not see = any security issues with it. The change boils down to this: when doing = top-down validation, just accept the *intersection* of resources listed = on a certificate, and its parent. The idea of keeping track of resources = explicitly is not new: we already have this when using 'inherit'. We = have running code in our validator for this. It took us a day to = implement this. The feature is off by default of course, but it's = enabled without problems on a public instance that we're running: = http://localcert.ripe.net:8088/ The second approach in section 4 was presented at the last IETF = (draft-barnes-sidr-tao). Essentially it allows for transfer signalling = through an up-down like protocol. Technically this approach can help to = deal with transfer issues (2). The 'happy case' scenarios assume though = that all involved parties play nice - and keep playing nice. There are = many moving parts here, and it's not clear to me what happens when one = party walks away (e.g. goes offline permanently). Additionally the = timing of certificate shrinking in case of a cancel is not clear to me = and introduces complexity: live transfer or not?, who signals the = transfer?, when is it canceled, before or after shrinking and/or = swinging? Can a cancel be canceled? But, more importantly, this approach = offers no protection against the operational fragility case (1). = Furthermore it adds a lot of complexity and this has huge costs in = development (many months) and maintenance and introduces more = operational fragility and potential interop issues between = implementations. Tim On Jul 2, 2014, at 3:27 AM, 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 : RPKI Validation Reconsidered > Authors : Geoff Huston > George Michaelson > Carlos M. Martinez > Tim Bruijnzeels > Andrew Lee Newton > Alain Aina > Filename : = draft-ietf-sidr-rpki-validation-reconsidered-00.txt > Pages : 10 > Date : 2014-07-01 >=20 > Abstract: > This document reviews the certificate validation procedure specified > in RFC6487 and highlights aspects of potentially acute operational > fragility in the management of certificates in the RPKI in response > to the movement of resources across registries, and the associated > actions of Certification Authorities to maintain continuity of > validation of certification of resources during this movement. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconside= red/ >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-ietf-sidr-rpki-validation-reconsidered-00= >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_C29AFFAD-3AF9-40D1-9D58-1ECF453F92E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://localcert.ripe.net:8088/

The second approach in section 4 was = presented at the last IETF (draft-barnes-sidr-tao). Essentially it = allows for transfer signalling through an up-down like protocol. = Technically this approach can help to deal with transfer issues (2). The = 'happy case' scenarios assume though that all involved parties play nice = - and keep playing nice. There are many moving parts here, and it's not = clear to me what happens when one party walks away (e.g. goes offline = permanently). Additionally the timing of certificate shrinking in case = of a cancel is not clear to me and introduces complexity: live transfer = or not?, who signals the transfer?, when is it canceled, before or after = shrinking and/or swinging? Can a cancel be canceled? But, more = importantly, this approach offers no protection against the operational = fragility case (1). Furthermore it adds a lot of complexity and this has = huge costs in development (many months) and maintenance and = introduces more operational fragility and potential interop issues = between = implementations.

Tim



On Jul 2, 2014, at 3:27 AM, internet-drafts@ietf.org = wrote:


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

=        Title =           : RPKI = Validation Reconsidered
=        Authors =         : Geoff Huston
=             &n= bsp;           &nbs= p;George Michaelson
=             &n= bsp;           &nbs= p;Carlos M. Martinez
=             &n= bsp;           &nbs= p;Tim Bruijnzeels
=             &n= bsp;           &nbs= p;Andrew Lee Newton
=             &n= bsp;           &nbs= p;Alain Aina
= Filename        : = draft-ietf-sidr-rpki-validation-reconsidered-00.txt
Pages =           : = 10
= Date =            : = 2014-07-01

Abstract:
  This document reviews the = certificate validation procedure specified
  in RFC6487 = and highlights aspects of potentially acute operational
=   fragility in the management of certificates in the RPKI in = response
  to the movement of resources across registries, = and the associated
  actions of Certification Authorities = to maintain continuity of
  validation of certification of = resources during this movement.


The IETF datatracker status = page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-valida= tion-reconsidered/

There's also a htmlized version available = at:
http://tools.ietf.org/html/draft-ietf-sidr-rpki-validation-reconsid= ered-00


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/

________________________= _______________________
sidr mailing = list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

= --Apple-Mail=_C29AFFAD-3AF9-40D1-9D58-1ECF453F92E4-- From nobody Thu Jul 10 08:46:03 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 71D651A0385 for ; Thu, 10 Jul 2014 08:46:02 -0700 (PDT) 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 cdRBE1WABhAN for ; Thu, 10 Jul 2014 08:46:00 -0700 (PDT) Received: from mail.mikesoffice.com (dnsv6.mikesoffice.com [IPv6:2001:470:1f05:274::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E301A0653 for ; Thu, 10 Jul 2014 08:46:00 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f05:274:a64e:31ff:fe1a:40e0]) by mail.mikesoffice.com (Postfix) with ESMTPSA id 5F5F661086; Thu, 10 Jul 2014 08:45:57 -0700 (PDT) From: Michael Baer To: sidr@ietf.org X-Face: "*g#dUT3; 8M9AE5dLk\\b4G\cNCQkRb.g/2QwEXQKf.: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/Xz6Av18bUJPQEZfjYSUSK-kkOa4 Subject: [sidr] An update to the BGPSEC implementation based on BIRD 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, 10 Jul 2014 15:46:02 -0000 Hi all, I wanted to announce a new, 0.3, version of BGPSEC supporting BIRD code. It's currently based on v1.3.9 of BIRD and is available as a patch or as a full source tarball at: http://bgpsec.tislabs.com As an FYI, the code is still at the experimental/testing stage (i.e. obviously unwise to use this version on a productiion server). If any one wants to play with or test the code, please feel free to email me any questions or bug reports. Thanks, Mike -- Michael Baer baerm@tislabs.com Parsons Global Shared Services, Cyber Security Division C: 530.902.3131 From nobody Thu Jul 10 11:23:48 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 1DB2F1A0B06; Thu, 10 Jul 2014 11:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Px9EB59sdjMU; Thu, 10 Jul 2014 11:23:45 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002: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 28D871A0AB2; Thu, 10 Jul 2014 11:23:45 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id f73so3534579yha.8 for ; Thu, 10 Jul 2014 11:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=61MVJu4o8pzuNB89t3LzrOqFaW6PWL4nog3i23/OHqE=; b=CGIJv0FUUEAgKeV1vOzmARUNMiN8M0uNZSjh2NXmRl7x8gKQazxUfMXGM3pHqGkM0V 9JNrnj5lJXNk2ESn5yBhqR6Om+LdEcNZck8WYyF4V+pXW40EoCw7flJWFZcp8iidjWe1 eCrK8zztWQ55CBZW3jqqw4lUlImg1VxkwCh3UHc48a5TP3i2IoEJpuVjAH1pxT5JzPzw 8DcULlfbnJrDF5jk7Lord+YmBmAmuKomGQVgK9P8x7jybpWPjY55JoEMbH+4mhhM9YfS ZUF4ug92uy51kGTigJgWZOsVYaRGlytv+wa4Z+HmeEr3EaHl68B1x21C1MVXWYZduYct pbKg== X-Received: by 10.236.45.10 with SMTP id o10mr73770760yhb.49.1405016624422; Thu, 10 Jul 2014 11:23:44 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy ([200.7.87.67]) by mx.google.com with ESMTPSA id z45sm85310321yhc.17.2014.07.10.11.23.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jul 2014 11:23:43 -0700 (PDT) Message-ID: <53BEDA2C.1090609@gmail.com> Date: Thu, 10 Jul 2014 15:23:40 -0300 From: "Carlos M. Martinez" 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: internet-drafts@ietf.org, i-d-announce@ietf.org References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> In-Reply-To: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/psVlQLdtLOYBvco8yfnGlTuUeps Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 18:23:47 -0000 As newly-added co-author of this document, I obviously share the concerns expressed in Section 3. Although it can be argued that these issues could be worked around by careful coordination among all involved CAs when any change is to be performed on resource sets included in CA certificates, these coordination steps are only viable when only few CAs are involved. Moreover, I believe that in an escenario where the Internet comes to see any signficant deployment of the RPKI Provisioning Protocol this coordination becomes more and more difficult and the chances for possible brokenness in some limbs of the RPKI tree at a a particular point in time will be rather high. This is clearly not acceptable, and I believe the SIDR standards need to be engineered for resiliency as much as for security. In Section 4 two possible paths forward are proposed. The first option presents a simple, understandable and workable alternative that, as Tim has already mentioned, can be implemented by relying parties in a short period of time. Warm regards, -Carlos On 7/1/14, 10:27 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. > > Title : RPKI Validation Reconsidered > Authors : Geoff Huston > George Michaelson > Carlos M. Martinez > Tim Bruijnzeels > Andrew Lee Newton > Alain Aina > Filename : draft-ietf-sidr-rpki-validation-reconsidered-00.txt > Pages : 10 > Date : 2014-07-01 > > Abstract: > This document reviews the certificate validation procedure specified > in RFC6487 and highlights aspects of potentially acute operational > fragility in the management of certificates in the RPKI in response > to the movement of resources across registries, and the associated > actions of Certification Authorities to maintain continuity of > validation of certification of resources during this movement. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-rpki-validation-reconsidered-00 > > > 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/ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From nobody Mon Jul 14 09:15:38 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 C39391A0ACA; Mon, 14 Jul 2014 09:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=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 UDlDCB4L_sKP; Mon, 14 Jul 2014 09:15:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C09AC1A0AB8; Mon, 14 Jul 2014 09:15:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140714161535.31454.78967.idtracker@ietfa.amsl.com> Date: Mon, 14 Jul 2014 09:15:35 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/MDdP_sEeL8W_u9ZO8YJUFkljm1s Cc: sidr@ietf.org Subject: [sidr] I-D ACTION:draft-ietf-sidr-bgpsec-reqs-12.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, 14 Jul 2014 16:15:37 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Security Requirements for BGP Path Validation Author(s) : S. Bellovin, et al Filename : draft-ietf-sidr-bgpsec-reqs Pages : 9 Date : 2014-07-14 This document describes requirements for a BGP security protocol design to provide cryptographic assurance that the origin AS (Autonomous System) had the right to announce the prefix and to provide assurance of the AS Path of the announcement. A URL for this Internet-Draft is: https://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-reqs-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-bgpsec-reqs"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-07-14091535.I-D@ietf.org> --NextPart-- From nobody Mon Jul 14 17:12:10 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 43BE21B27BC for ; Mon, 14 Jul 2014 17:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 crt688D0jHCb for ; Mon, 14 Jul 2014 17:12:06 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 579F81A01EB for ; Mon, 14 Jul 2014 17:12:06 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1X6qLi-0005cu-Bb for sidr@ietf.org; Tue, 15 Jul 2014 00:12:02 +0000 Date: Tue, 15 Jul 2014 09:12:01 +0900 Message-ID: From: Randy Bush To: sidr wg list In-Reply-To: <20140714161535.31454.78967.idtracker@ietfa.amsl.com> References: <20140714161535.31454.78967.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/1lOBaLF8StIbnWVBfsEiRKrof5I Subject: Re: [sidr] I-D ACTION:draft-ietf-sidr-bgpsec-reqs-12.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 00:12:08 -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 : Security Requirements for BGP Path Validation > Author(s) : S. Bellovin, et al > Filename : draft-ietf-sidr-bgpsec-reqs this was to incorporate edits from ietf last call and the iesg the system still does not point you to the diff, and i have given up whining. it is at https://tools.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-reqs-12 randy From nobody Tue Jul 15 07:45:28 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 A95D51B28D1; Tue, 15 Jul 2014 07:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43hBdY6l1i5P; Tue, 15 Jul 2014 07:44:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E3E1B28CC; Tue, 15 Jul 2014 07:43:19 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140715144319.8099.216.idtracker@ietfa.amsl.com> Date: Tue, 15 Jul 2014 07:43:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/MqDRtGB4dRb6GJP66HXlZn_2DCc Cc: sidr mailing list , sidr chair , RFC Editor Subject: [sidr] Document Action: 'Security Requirements for BGP Path Validation' to Informational RFC (draft-ietf-sidr-bgpsec-reqs-12.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: Tue, 15 Jul 2014 14:45:06 -0000 The IESG has approved the following document: - 'Security Requirements for BGP Path Validation' (draft-ietf-sidr-bgpsec-reqs-12.txt) as Informational RFC This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Alia Atlas and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-reqs/ Technical Summary This document describes requirements for a BGP security protocol design to provide cryptographic assurance that the origin AS had the right to announce the prefix and to provide assurance of the AS Path of the announcement. Working Group Summary The document spent quite some time in WG discussion, one particular sticky point was around the lack of notice that 'route leaks are not fixed by this protocol change'. There is a standing discussion about this in this WG, and the agreed upon process is being followed (get the GROW folk to decide if 'route leaks' are a problem, then get IDR to code some bgp changes that might do the detection/notification/etc, and have SIDR properly secure whatever that result was. Document Quality There are two vendors planning on supporting this protocol once it's finished, both are active in the working group (and have been for a while). Personnel Document Shepherd: Chris Morrow Area Director: Alia Atlas From nobody Fri Jul 18 13:03:23 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 687DF1B2973 for ; Fri, 18 Jul 2014 13:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.48 X-Spam-Level: **** X-Spam-Status: No, score=4.48 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FSL_HELO_BARE_IP_2=2, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347, 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 U1wdAv_macsw for ; Fri, 18 Jul 2014 13:03:20 -0700 (PDT) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [67.18.14.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43F971A016F for ; Fri, 18 Jul 2014 13:03:20 -0700 (PDT) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id 3C867B1090A8; Fri, 18 Jul 2014 15:02:57 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 2A807B103AEF for ; Fri, 18 Jul 2014 15:02:57 -0500 (CDT) Received: from [96.231.227.95] (port=57585 helo=192.168.1.6) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X8EMq-0006J3-DG for sidr@ietf.org; Fri, 18 Jul 2014 15:02:56 -0500 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2E5F96B7-1987-4C7A-9167-ED693A0F2709@ieca.com> Date: Fri, 18 Jul 2014 16:02:54 -0400 To: sidr wg list Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) 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: 96.231.227.95 X-Exim-ID: 1X8EMq-0006J3-DG X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.6) [96.231.227.95]:57585 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/-3QWl9nzq4JhlbhpTddA8FIl2Wo Subject: [sidr] drafts on github 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, 18 Jul 2014 20:03:21 -0000 All, I put my working copies of draft-ietf-sidr-bgpsec-pki-profiles and = draft-ietf-sidr-bgpsec-algs up on github: https://github.com/seanturner/draft-ietf-sidr-bgpsec-pki-profiles https://github.com/seanturner/draft-ietf-sidr-bgpsec-algs spt= From nobody Mon Jul 21 11:41: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 AB0791A0360 for ; Mon, 21 Jul 2014 11:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 UHY7jACiogQH for ; Mon, 21 Jul 2014 11:40:58 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id B5EA01A02E0 for ; Mon, 21 Jul 2014 11:40:50 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 7027528B0041 for ; Mon, 21 Jul 2014 14:40:50 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 51BD81F8032; Mon, 21 Jul 2014 14:40:50 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_60EB73D7-2331-43B5-88AA-F96D28860F33"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Mon, 21 Jul 2014 14:40:49 -0400 Message-Id: <7E89EB54-ECEE-470F-BBD9-621080D3D25B@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/0uukcTyTxZJx8E7Af0efX9l_72s Cc: Sandra Murphy Subject: [sidr] jabber scribe and minutes taker 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, 21 Jul 2014 18:41:04 -0000 --Apple-Mail=_60EB73D7-2331-43B5-88AA-F96D28860F33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The meeting is on Friday morning. We will need a jabber scribe and = minutes taker before the business of the meeting can continue. (There's the etherpad to help in collaborative editing for more than one = person to be involved in the minutes taking.) --Sandy, speaking for the wg co-chairs --Apple-Mail=_60EB73D7-2331-43B5-88AA-F96D28860F33 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 iQIcBAEBCgAGBQJTzV6xAAoJEHplpQeet0IZeQAQAKU0ZRve3fW9tF8BGni/j5VS IbIYDN2cdWJ+WXJxZAv6Vx1kWDH61j7UEuE56hfmrVEKNpucwXUETsvSDOqAKy4f QQsaUTwztO6iIH+o3dlUojdd3oJYn3LWH1UOGUruJH1JnaO3u3+V8GH9X90CHsqL 4kIa8D1zhao2f+uAqIgy5Z2xUqRq+k2iBxhIcgHJ3RQ0JIdkO88xtS3f+b9rTfwM c5dNEP5Y9OXeazHbRLi09kBCjr47nO1yJxcLqatkmhscMm4z0hOViZhyNfks3IV+ ZbaJKnazSFdPu4nABo9k02cYCxpWi/B7ykKOM8YviH9B2G73aDBOH9uHV3FimW3i mX6PZdSZmaFqk4zkOPxeIugDjHM7tuexyabcUXdwBVvXbepVkpNNsJmH9U1X737k Sw+mB2wARXJUFFbrqVQurNSUknR/6F616fg1I6EQOAaYq1tnlRtQ+MVOZoL+PMi3 c1dgcHekKaE2O3EPU//U5Z6ghkwtM1qeRiFNq9Au1tUlXAGvK4XNR9aeuIkPogIi Ck69BOpr0AM5RJp6Ou7HVwDU4FttAQwMt8HvAyRdNUEpYeqE2Qe9yh0WcZxkmB9B KzvdBOLbnvyaY7W/v1VVSNVIQfj27ApmgMi6+3crbOfcCxYa8aF2d8GjerkApDeL u0OKGE5tfbK2fAt5MQ9m =HrpG -----END PGP SIGNATURE----- --Apple-Mail=_60EB73D7-2331-43B5-88AA-F96D28860F33-- From nobody Mon Jul 21 11:55: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 8F5351A0172 for ; Mon, 21 Jul 2014 11:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 cZ6pi_MYLLo1 for ; Mon, 21 Jul 2014 11:55:50 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 16D491A0081 for ; Mon, 21 Jul 2014 11:55:50 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id BD71B28B0041 for ; Mon, 21 Jul 2014 14:55:49 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 98AB91F8032; Mon, 21 Jul 2014 14:55:49 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_4825A19E-2754-465B-AD8C-DCAA80213368"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Mon, 21 Jul 2014 14:55:48 -0400 Message-Id: <8AF7799E-20D4-4E28-A2DE-E8DE23D81203@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/G1MZ3kEdXWHyck5M8PXvHzXHhmQ Cc: Sandra Murphy Subject: [sidr] presenters need to send slides 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, 21 Jul 2014 18:55:51 -0000 --Apple-Mail=_4825A19E-2754-465B-AD8C-DCAA80213368 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Those presenting need to send slides to the sidr-chairs@ietf.org alias = before Friday. If you do not have your slides sent in by Thu noon, we'll start nagging. = By Thu end of sessions (before Bits-N-Bytes), we'll start hunting you = down. Fri morning just before the start of session is too late and = risks losing your slot on the agenda. Please, everyone, including the chairs, number your slides. Those who = are trying to keep the jabber room and other remote participants = appraised of what the room is seeing would find that essential. --Sandy, speaking for the co-chairs --Apple-Mail=_4825A19E-2754-465B-AD8C-DCAA80213368 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 iQIcBAEBCgAGBQJTzWI1AAoJEHplpQeet0IZ4UIP/A69JwpEcYX9MmNqHC69GbQ8 gg/SxaVNV5Y2R8b2FC9aPgKEliOVLSawemguhhBNKAy9RJsplg889EGegDX16SPs 4YNzK/YA+T4NSeWwt2nUUYJ/5wmxHU0XTIbUUMMQbgcMd8ourMDuB0gjU0dUHBL8 O5/ZF+vZZA0UDuTPcpeIZbG1HukAzRJXzjKh/WnFqRdjIkexjWdg8/MDSrcvLbWY Sj0DrrvyQmj7rVaHzKoRz5ConaxedeGnPFYfpWsLG9IOkzo1wdah5t3DCyCixBVv vVwFu005VDosaMPrXxP2GAbeHtsxkRIR+v4Qf26+QC+S7zW73NttohVBixl5PCzJ lkNnpfKwrL8I2NDHhkM/k1O1FfzSQCQ8S8RzxlC9z0sLSgbrZn5yjU0HbDhBx9Tg sMXovEwLjLRc38VPZ7fDOCKCcBfSKPr0/psAVFXiVEX+aLHWxHb3c7MIEqSH3JCP qhDRlPuQKHVjlbWxFOg6CA27V3GurFG2qd24GGWYWsGZJA8iqhgwK656dz1ekl3t YsV+xSYHNzpE6Zl42hD+nss8dGKk5nOdgCT4NRSWXEQh5NDfKZ8j8NnrKMSU2lT2 2sUo14ifvLiJqszqOZ6FZLf34l0Q31SUuJr9T9XUnYISg8bS+HJuHXevhRs59tNn jYoi4KTM6m/R+C3M8Hok =d9EP -----END PGP SIGNATURE----- --Apple-Mail=_4825A19E-2754-465B-AD8C-DCAA80213368-- From nobody Mon Jul 21 13:45:08 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 05CB41A0406 for ; Mon, 21 Jul 2014 13:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 OlNtwns__GLT for ; Mon, 21 Jul 2014 13:45:00 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAB01A0328 for ; Mon, 21 Jul 2014 13:45:00 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id DFA0328B0040 for ; Mon, 21 Jul 2014 16:44:59 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 7BD321F8032; Mon, 21 Jul 2014 16:44:57 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_DF2607B1-EEE5-424F-9D23-7DED1B65B1E0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Mon, 21 Jul 2014 16:44:56 -0400 Message-Id: <4004407F-215E-491D-ABBC-2559EA66BE5B@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/dlkQRwJwInC0SjK_yv2odDHsdhQ Cc: Sandra Murphy Subject: [sidr] Meetecho remote participation 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, 21 Jul 2014 20:45:04 -0000 --Apple-Mail=_DF2607B1-EEE5-424F-9D23-7DED1B65B1E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I don't know if you all know, but the last several sidr meetings have = been supported by Meetecho. They will be supporting our session on = Friday. Meetecho provides "A synchronized view of the official jabber room, the = current slides being presented, a shared note taking editor and an = audio/video stream from the room is made available in each Meetecho = room." Recordings are available for the wgs that have been covered. For anyone who has used the Meetecho support, they are looking for = feedback, requests and suggestions. They also have a new project they'd like to people to know about: = http://ietf90.conf.meetecho.com/index.php/UMPIRE_Project. --Sandy, speaking as wg co-chair --Apple-Mail=_DF2607B1-EEE5-424F-9D23-7DED1B65B1E0 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 iQIcBAEBCgAGBQJTzXvIAAoJEHplpQeet0IZk/0P/0VVWrFbObBo6unHEegjG3ab o+hB36DJZVYbJzwk+q14nDJl42qIbCx3A+t1uOC2FPEU7W+Tig84XbFtjfsDgpVK /3/i7e1e9j2sWtNG0R6uxUe2ilIrDIyHh0SqnMxxKNuHXkCU9oE3Owz31EJ8KFHK iaPiOQe6lJFo8wMPX5c1/z6NuGLlLYbKjLsWKwrz7FvP/oz2ufDvjA3EBnWe5TvA 5++Mp52uJe3Hh/L70hK9Jf+P65W3dAo+2u+uMT6qD1W9VlZ6E9pTHDl5WX4Ku3PH 9QzAbCeO+2A1DqxW04s4HMsorsqfYcEUZs/uW0NsODkPUhOUebrJzlWGHMDn8bq8 cLrNWUXLEQDgPy/k2bW9xJrDLUIqeyisxx+EhPPplJfmx7ntV77vCAF1giO9hJGi dZRyPPWviqt8z/7NS96Y3/zanzH0Gnly1mDM42bG5ZZBFT7lUFQmW9Tk9uudnJqs lKBEAelTUdtyJjiohs2LHhu2N1IMofw4HXAT13DhZLceuNI2zaAjXTrXHBFIJRKL YBXYxcLYTTANSRzRkoblPcYUEhUI6+j8csWnRXuau7QE7CF0Cpt0iNnQqpU7dc0h ZV5KKvSC0XSmAN6ZDfJnQGmmSvEm/nDFKB/iXclzDrprSZdVyqLHYrdLGnjC6Ea4 jxvK6+DdSMzj14gjxBK+ =vzbC -----END PGP SIGNATURE----- --Apple-Mail=_DF2607B1-EEE5-424F-9D23-7DED1B65B1E0-- From nobody Wed Jul 23 11:30: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 D567D1B2800 for ; Wed, 23 Jul 2014 11:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, WEIRD_PORT=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 CX3yvQKe4XQ6 for ; Wed, 23 Jul 2014 11:30:23 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE42D1A02F0 for ; Wed, 23 Jul 2014 11:30:22 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:35471 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XA1JC-000D1J-OR for sidr@ietf.org; Wed, 23 Jul 2014 14:30:35 -0400 Message-ID: <53CFFF3C.2040406@bbn.com> Date: Wed, 23 Jul 2014 14:30:20 -0400 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: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> In-Reply-To: <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> Content-Type: multipart/alternative; boundary="------------070907070807080101070007" Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/VXrYUadkFHxPIcMBH3eabPTvUkg Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 18:30:25 -0000 This is a multi-part message in MIME format. --------------070907070807080101070007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tim, > Hi, > > As you may have noticed my name was added to the author list, so it > will come as no surprise that I read this document and agree with its > content. > > I believe that all RIRs share both operational concerns outlined in > section 3: (1) Operational fragility, and (2) resource transfers. One > thing to note about the second case is that we don't have this problem > right now because we only offer a hosted service where our members > cannot create delegated certificates. However, this will change when > we enable the provisioning (up-down) system and support non-hosted CAs > that may delegate further. > > Section 4 describes, in very general terms, two alternative approaches > to counter these concerns. > > The first approach has my strong preference. I believe it's simple to > explain and implement, effective against both concerns, and I do not > see any security issues with it. The change boils down to this: when > doing top-down validation, just accept the *intersection* of resources > listed on a certificate, and its parent. The idea of keeping track of > resources explicitly is not new: we already have this when using > 'inherit'. We have running code in our validator for this. It took us > a day to implement this. The feature is off by default of course, but > it's enabled without problems on a public instance that we're running: > http://localcert.ripe.net:8088/ Since you implemented this capability based on what we all agree is a rough description of the intended functionality, can you be very confident that it is "correct"? More to the point, we all agree that it is very bad for an RIR or NIR to issue a cert that would break the current validation algoroithm. In a prior message I suggested several checks that I thought every CA operating should perform to detect and avoid such errors. Has RIPE been performing check such as these? Might adoption of relaxed validation rules minimize the perceived need to perform such checks, i.e., encourage sloppiness? > The second approach in section 4 was presented at the last IETF > (draft-barnes-sidr-tao). Essentially it allows for transfer signalling > through an up-down like protocol. Technically this approach can help > to deal with transfer issues (2). The cited approach approach is designed expressly to deal with transfer issues, not with the more general problem of errors by CAs. One ought not conflate these two issues. > The 'happy case' scenarios assume though that all involved parties > play nice - and keep playing nice. There are many moving parts here, > and it's not clear to me what happens when one party walks away (e.g. > goes offline permanently). Additionally the timing of certificate > shrinking in case of a cancel is not clear to me and introduces > complexity: live transfer or not?, who signals the transfer?, when is > it canceled, before or after shrinking and/or swinging? Can a cancel > be canceled? But, more importantly, this approach offers no protection > against the operational fragility case (1). Furthermore it adds a lot > of complexity and this has huge costs in development (many months) > and maintenance and introduces more operational fragility and > potential interop issues between implementations. Since we have NO description of resource transfer at the level of detail provided in the TAO I-D, it seems a bit premature to describe it as being more complex than the suggested alternative. Steve --------------070907070807080101070007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Tim,

Hi,

As you may have noticed my name was added to the author list, so it will come as no surprise that I read this document and agree with its content.

I believe that all RIRs share both operational concerns outlined in section 3: (1) Operational fragility, and (2) resource transfers. One thing to note about the second case is that we don't have this problem right now because we only offer a hosted service where our members cannot create delegated certificates. However, this will change when we enable the provisioning (up-down) system and support non-hosted CAs that may delegate further.

Section 4 describes, in very general terms, two alternative approaches to counter these concerns.

The first approach has my strong preference. I believe it's simple to explain and implement, effective against both concerns, and I do not see any security issues with it. The change boils down to this: when doing top-down validation, just accept the *intersection* of resources listed on a certificate, and its parent. The idea of keeping track of resources explicitly is not new: we already have this when using 'inherit'. We have running code in our validator for this. It took us a day to implement this. The feature is off by default of course, but it's enabled without problems on a public instance that we're running: http://localcert.ripe.net:8088/
Since you implemented this capability based on what we all agree is a rough description of the
intended functionality, can you be very confident that it is "correct"?

More to the point, we all agree that it is very bad for an RIR or NIR to issue a cert
that would break the current validation algoroithm. In a prior message I suggested several
checks that I thought every CA operating should perform to detect and avoid such errors.
Has RIPE been performing check such as these? Might adoption of relaxed validation rules
minimize the perceived need to perform such checks, i.e., encourage sloppiness?
The second approach in section 4 was presented at the last IETF (draft-barnes-sidr-tao). Essentially it allows for transfer signalling through an up-down like protocol. Technically this approach can help to deal with transfer issues (2).
The cited approach approach is designed expressly to deal with transfer issues, not with the
more general problem of errors by CAs. One ought not conflate these two issues.
The 'happy case' scenarios assume though that all involved parties play nice - and keep playing nice. There are many moving parts here, and it's not clear to me what happens when one party walks away (e.g. goes offline permanently). Additionally the timing of certificate shrinking in case of a cancel is not clear to me and introduces complexity: live transfer or not?, who signals the transfer?, when is it canceled, before or after shrinking and/or swinging? Can a cancel be canceled? But, more importantly, this approach offers no protection against the operational fragility case (1). Furthermore it adds a lot of complexity and this has huge costs in development (many months) and maintenance and introduces more operational fragility and potential interop issues between implementations.
Since we have NO description of resource transfer at the level of detail provided in the TAO I-D, it seems a bit premature to describe it as being more complex than the suggested alternative.

Steve
--------------070907070807080101070007-- From nobody Wed Jul 23 11:38:03 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 344EF1B299B for ; Wed, 23 Jul 2014 11:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 IeJRH14hb0l5 for ; Wed, 23 Jul 2014 11:37:51 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D6AD1B29A7 for ; Wed, 23 Jul 2014 11:37:51 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:38723 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XA1QD-00005t-TF for sidr@ietf.org; Wed, 23 Jul 2014 14:37:50 -0400 Message-ID: <53D000FD.1030702@bbn.com> Date: Wed, 23 Jul 2014 14:37:49 -0400 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: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <53BEDA2C.1090609@gmail.com> In-Reply-To: <53BEDA2C.1090609@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/0T-zoQs2ydxm3Qw5QD0BF_I_vak Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 18:37:53 -0000 Carols, > As newly-added co-author of this document, I obviously share the > concerns expressed in Section 3. > > Although it can be argued that these issues could be worked around by > careful coordination among all involved CAs when any change is to be > performed on resource sets included in CA certificates, these > coordination steps are only viable when only few CAs are involved. Section 3 addresses two distinct topics: errors by high tier CAs and INR xfers. The former, and arguably the more serious of the two topics, involves one CA making a mistake. The latter may involve 3 or more CAs. Let's try to be precise in our comments. > Moreover, I believe that in an escenario where the Internet comes to see > any signficant deployment of the RPKI Provisioning Protocol this > coordination becomes more and more difficult and the chances for > possible brokenness in some limbs of the RPKI tree at a a particular > point in time will be rather high. This is a very vague comment. > This is clearly not acceptable, and I believe the SIDR standards need to > be engineered for resiliency as much as for security. Both are important. > In Section 4 two possible paths forward are proposed. The first option > presents a simple, understandable and workable alternative that, as Tim > has already mentioned, can be implemented by relying parties in a short > period of time. Section 4 conflates two related, but distinct, issues. A method for INR transfer, by itself, is not going to deal with errors by high tier CAs. Tim is one developer of RP software. We ought to hear from the other two RP software developers before judging how easy or hard it may be to adopt a change that is not fully specified yet. Steve From nobody Wed Jul 23 15:42:34 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 2EE591B29CC for ; Wed, 23 Jul 2014 15:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 AjZFRQ4y540S for ; Wed, 23 Jul 2014 15:42:31 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 066871B29C9 for ; Wed, 23 Jul 2014 15:42:30 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:45664 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XA5Ez-0005BB-AI for sidr@ietf.org; Wed, 23 Jul 2014 18:42:29 -0400 Message-ID: <53D03A55.3080706@bbn.com> Date: Wed, 23 Jul 2014 18:42:29 -0400 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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/FhyFKgT6HEXnewcy1fWbueraVDQ Subject: [sidr] comment on draft-ietf-sidr-rpki-validation-reconsidered 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, 23 Jul 2014 22:42:32 -0000 In my comments to Tim and Carlos, I neglected to say that I do think the WG should provide a detailed, algorithmic description of the proposed relaxed validation procedure. If the authors produce a suitable description of the procedure, and if the other RPKI RP software developers find it reasonable, then I will support the change. I also note that relaxed validation rules probably would simplify the procedure described in the TAO I-D. I suggest that INR transfer, a topic raised by Sandy long ago and not addressed in detail prior to the TAO I-D, should be the topic of a separate I-D, not part of the relaxed validation procedure description. Finally, I assume that the RIRs are not suggesting that errors in cert issuance are a good idea; thus I would like to see the revised validation I-D define procedures of the sort I described earlier to help CAs detect erroneous cert issuance and avoid it, rather than relying solely on relaxed validation by RPs to mitigate the damage of such errors. Steve From nobody Thu Jul 24 07:17:20 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 1A0F11A02EE for ; Thu, 24 Jul 2014 07:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 PjWZ1bxlF4b2 for ; Thu, 24 Jul 2014 07:17:08 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 942901A02D1 for ; Thu, 24 Jul 2014 07:17:07 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 3FD1128B0040 for ; Thu, 24 Jul 2014 10:17:07 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 22B121F8032; Thu, 24 Jul 2014 10:17:07 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_F9D944F9-8760-4E2F-9FA9-678076FE7A2D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 24 Jul 2014 10:17:06 -0400 Message-Id: <37B626D7-DD0C-42AD-B19D-E9FC6DE1F373@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/CdMPoyuudb3lfFQuelFVtcRAM_s Cc: Sandra Murphy Subject: [sidr] sidr agenda shuffling 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, 24 Jul 2014 14:17:19 -0000 --Apple-Mail=_F9D944F9-8760-4E2F-9FA9-678076FE7A2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I spoke at the idr meeting on Tuesday to point them to the bgpsec = protocol and request their attention. They asked when on the agenda the protocol discussion would take place. To facilitate idr attention, the agenda has been shuffled to put the = bgpsec protocol related discussions first. That ended up moving the = validation reconsidered discussion to the end of the presentations. --Sandy --Apple-Mail=_F9D944F9-8760-4E2F-9FA9-678076FE7A2D 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 iQIcBAEBCgAGBQJT0RViAAoJEHplpQeet0IZafQQAMaRcKuyPrDfW/4/2dBUvc4O oU///Hr0EArDXJ+MgpUpOqrsZtYuomsUEQszwITQUZc4ke6djUWGKIX48APOcF75 S14anSjXrbEZ+iuJUO6ADQooQpzp5bLfaY/qzu7mEqp8wRT5vbe+lfOElDcp36qB wsaKJUPh68nKpn6P0ZgPQ44t721uJzqBE3HgLIOGwwaNrn6rvMA6qLjFWpWYqP1Q 28tIi51jClibEEwMx2khC2n0ERI0b6tVYDaQgNSNM+X1jXxfi60zZkSY1aj9w+4c y1LZM4mq+363hwtsnKNm5IXZRjUTYVxr0dKtQRldytSWT166Bvv7UPLhJBjaxQ8o 2DloFonEWW+UeU5kZb2+y9g20RaAeBP0hpu1n6+naxYFwatW8lGgY6SkvHNNgQt1 zOUuLrkarZ9XaWkIUVGY8LZmP7hoWMNvkETqg2/cjnHoI9dGM4jk/j3sX3Cx0cuW UoLjxLWEc+WdnSnqz6Oav8BHEcFD781wyZ0uOijNQeeCgbWMnX+2FZGWtEVn1hVI rxG2PcgZobQsPeoLCOzs5x1OiI7KE21loKTrdxayFXbiGsw0r2ZMpjW5lz4Oc67q V4TdKlMxAFFGSLgYHxtgRInAOJ5SEE2f5ew2wS893MA+01oCghYprMvh9MujS33+ G//bwQAGAPVM2sVMSD9k =OMww -----END PGP SIGNATURE----- --Apple-Mail=_F9D944F9-8760-4E2F-9FA9-678076FE7A2D-- From nobody Thu Jul 24 07:38:10 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 07B8E1A0380 for ; Thu, 24 Jul 2014 07:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIQPFrLFtc2Q for ; Thu, 24 Jul 2014 07:37:59 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 48CF51A024E for ; Thu, 24 Jul 2014 07:37:59 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id E61FCF9C014 for ; Thu, 24 Jul 2014 10:37:48 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id alWZcHQFw0cz for ; Thu, 24 Jul 2014 10:37:23 -0400 (EDT) Received: from dhcp-b67e.meeting.ietf.org (dhcp-b67e.meeting.ietf.org [31.133.182.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 63970F9C043 for ; Thu, 24 Jul 2014 10:37:23 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: Date: Thu, 24 Jul 2014 10:37:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <680AF9DB-5B60-48C7-805A-1E8B6C59642C@vigilsec.com> References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> To: IETF SIDR X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/jc5m5R37RoOqRrrVL2aYtPvYhug Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 14:38:06 -0000 The Introduction says: This document reviews the certificate validation procedure specified in RFC6487 and highlights aspects of potentially acute operational fragility in the management of certificates in the RPKI in response to the movement of resources across registries, and the associated actions of Certification Authorities to maintain continuity of validation of certification of resources during this movement. When this working group was developing the RPKI specifications, the RIRs = essentially asked us not to specify how the "movement of resources = across registries" would take place. I for one accepted this at the = time because it looked like an issue between RIRs. This document is = calling for a make-before-break certificate issuance capability. Maybe = there are other motives too. RFC 3779 has been implemented. For example, OpenSSL implements RFC = 3779, and others make use of this certificate handling software. We are = not talking about a little tweak to such a library. Implementation = would require a path validation parameter to pass the content of the = ROA. As I understand the situation, the existing specification works, but it = imposes some restrictions on the order that certificates that must be = issued and distributed. I really want to see the RPKI deployed, and deployed really soon. I = worry greatly that this proposed change will result in a very = significant delay. To change my mind, I'd need to see a serious impact on operators by the = current specification. Can it be demonstrated with the various = implementations that we already have in front of us? Russ From nobody Thu Jul 24 08:31:14 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 D34631A0354 for ; Thu, 24 Jul 2014 08:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 NK1rNV2nL-1G for ; Thu, 24 Jul 2014 08:31:11 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id B7EE71A0345 for ; Thu, 24 Jul 2014 08:30:53 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 5FF0528B0040; Thu, 24 Jul 2014 11:30:53 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 336641F8032; Thu, 24 Jul 2014 11:30:53 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_A8B111F2-8592-4D66-AAFA-9C60EB0BF8DB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: <680AF9DB-5B60-48C7-805A-1E8B6C59642C@vigilsec.com> Date: Thu, 24 Jul 2014 11:30:52 -0400 Message-Id: References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <680AF9DB-5B60-48C7-805A-1E8B6C59642C@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/zOo6nTXSAd_JmkkJne01YmClx3s Cc: IETF SIDR , Sandra Murphy Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 15:31:13 -0000 --Apple-Mail=_A8B111F2-8592-4D66-AAFA-9C60EB0BF8DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 24, 2014, at 10:37 AM, Russ Housley wrote: > The Introduction says: >=20 > This document reviews the certificate validation procedure specified > in RFC6487 and highlights aspects of potentially acute operational > fragility in the management of certificates in the RPKI in response > to the movement of resources across registries, and the associated > actions of Certification Authorities to maintain continuity of > validation of certification of resources during this movement. >=20 > When this working group was developing the RPKI specifications, the = RIRs essentially asked us not to specify how the "movement of resources = across registries" would take place. I for one accepted this at the = time because it looked like an issue between RIRs. This document is = calling for a make-before-break certificate issuance capability. Maybe = there are other motives too. There are two cases. One is the transfer case and the need to revise certs upward on the = giving side and downward on the receiving side. That's the = make-before-break part. The other is the problem of removing resources from certs - one CA = reissues a "smaller" cert, and reissuing has to take place down the = chain for the resources that are retained, in order to keep the = encompassing rules valid. The pain is felt in the CA's descendants = until other CAs get their re-issuance done. >=20 > RFC 3779 has been implemented. For example, OpenSSL implements RFC = 3779, and others make use of this certificate handling software. We are = not talking about a little tweak to such a library. Implementation = would require a path validation parameter to pass the content of the = ROA. Not sure that's the case. I think all RPKI recipients now need to do a = computation of which of a cert's resources are valid, which are not. = The *recipients* decide what the certificate says. This will impact = interpretation of a ROA but I don't think it requires something that has = to get passed around with the ROA. >=20 > As I understand the situation, the existing specification works, but = it imposes some restrictions on the order that certificates that must be = issued and distributed. There's a order problem in the transfer case and a timing problem in the = reduction case. >=20 > I really want to see the RPKI deployed, and deployed really soon. I = worry greatly that this proposed change will result in a very = significant delay. >=20 > To change my mind, I'd need to see a serious impact on operators by = the current specification. Can it be demonstrated with the various = implementations that we already have in front of us? I think the case they point to can occur - but it is a matter of timing. = It will be a problem until the CA who needs to reissue does the = reissue, and then the world picks that up. >=20 > Russ >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_A8B111F2-8592-4D66-AAFA-9C60EB0BF8DB 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 iQIcBAEBCgAGBQJT0SasAAoJEHplpQeet0IZ4REP/1PxJ6RzIYmjICbosNeISY6z IF6Lqt0PIAcekkmLNPwEvrZqGl8Npz2VLSJRGVCjrd0N6IZ6dvaM0DVNK1ghjgNN SCW4VINwTFL7a86EObfMclo5RswPVNwSHCISMx8UqKqvtV6tr/QItDNxHmRHrZBb a3J23gmiP7boPT4QyR3UKTVz6jQw/ltTlTDu2JFfQQ7icBvetQ6K0FDvJXQmYPjP q4X6EWGTM8++oFxhOtyaeSLGaZDReaL6BWtpZzd6ZvAgTpPSPCbqF7trse0XgB74 tve8eWAjf/4Q5SnisBkT8YJG2byB4kzvKStkIbyDWIn3GUzGYdGaX9CR/ZKUFnV6 43pK++ixb36S5HuovF/Zzxvh26PezM3o6AS7gvKX7s0Khcd9HD3IpSzTi3v+lLDo W85hTkRYfa/1+IcqPYgasJxDvv1YjhrgTef8t+y0z1/2PJQENk8KHvcl3Zfa4Vag Z8Kh3yJ4/cSQriQf1jiMEB3/82ecEmPuv+Pma/bDuPFwgurpCWDKcIGJGv7XBTDm V8ObFLVcYvcroLC6Yy7Uwg1fFo2Fh0+Vcy4e/dNRStpXZWdBgFlnJwmp2dswSGm4 NaIrzw1FPdJLhcgZOQvQ72DADbeubSp+RU/Yb+qsyKXQ2Fw5yhBYWdmJjAw5GhOD G8mn8fDIFIYrZm8a0qi+ =Dpbg -----END PGP SIGNATURE----- --Apple-Mail=_A8B111F2-8592-4D66-AAFA-9C60EB0BF8DB-- From nobody Thu Jul 24 08:41:14 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 2AA8D1A01FF for ; Thu, 24 Jul 2014 08:41:12 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, WEIRD_PORT=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 fO764TXQ1MCl for ; Thu, 24 Jul 2014 08:41:09 -0700 (PDT) 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 D54481A0398 for ; Thu, 24 Jul 2014 08:40:54 -0700 (PDT) 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 1XAL8U-0003Fa-Qm; Thu, 24 Jul 2014 17:40:52 +0200 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-246.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1XAL8U-0001J4-Dh; Thu, 24 Jul 2014 17:40:50 +0200 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_2047C913-BBEF-4A5B-810C-559A9347E5DE" From: Tim Bruijnzeels In-Reply-To: <53CFFF3C.2040406@bbn.com> Date: Thu, 24 Jul 2014 11:40:48 -0400 Message-Id: References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1510) 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 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 WEIRD_PORT URI: Uses non-standard port number for HTTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719dd74b1292ebed18c40a11cece6d80a66 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/9Efmw7El6Cq9a8C4P3Fu0hTqFGk Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 15:41:12 -0000 --Apple-Mail=_2047C913-BBEF-4A5B-810C-559A9347E5DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Steve, all, On Jul 23, 2014, at 2:30 PM, Stephen Kent wrote: > Tim, >=20 >> Hi, >>=20 >> As you may have noticed my name was added to the author list, so it = will come as no surprise that I read this document and agree with its = content. >>=20 >> I believe that all RIRs share both operational concerns outlined in = section 3: (1) Operational fragility, and (2) resource transfers. One = thing to note about the second case is that we don't have this problem = right now because we only offer a hosted service where our members = cannot create delegated certificates. However, this will change when we = enable the provisioning (up-down) system and support non-hosted CAs that = may delegate further. >>=20 >> Section 4 describes, in very general terms, two alternative = approaches to counter these concerns. >>=20 >> The first approach has my strong preference. I believe it's simple to = explain and implement, effective against both concerns, and I do not see = any security issues with it. The change boils down to this: when doing = top-down validation, just accept the *intersection* of resources listed = on a certificate, and its parent. The idea of keeping track of resources = explicitly is not new: we already have this when using 'inherit'. We = have running code in our validator for this. It took us a day to = implement this. The feature is off by default of course, but it's = enabled without problems on a public instance that we're running: = http://localcert.ripe.net:8088/ What I forgot to mention above is that we do issue warnings on over = claiming certificates. So this is visible, although so-far we have not = seen these warnings in the RIR production repositories. > Since you implemented this capability based on what we all agree is a = rough description of the > intended functionality, can you be very confident that it is = "correct"? It's a beta feature for a reason. But I do believe there is value in = running code and getting experience with this. That said I think the approach safe. And what we implemented is my, = quite specific, understanding of the intended approach. I tried to = explain it in brief above, but if this is not clear enough and the WG = prefers, I would be happy to provide more formal text for this. > More to the point, we all agree that it is very bad for an RIR or NIR = to issue a cert > that would break the current validation algoroithm. In a prior message = I suggested several > checks that I thought every CA operating should perform to detect and = avoid such errors. > Has RIPE been performing check such as these? Might adoption of = relaxed validation rules > minimize the perceived need to perform such checks, i.e., encourage = sloppiness? It is not my intention, and I believe it's safe to say that it's not the = intention of others, to encourage sloppiness, but to minimise impact and = improve resiliency if an error does occur. Speaking for our own CA implementation. We have code in place to ensure = that we cannot create over-claiming certificates. We also have code to = re-issue products as needed when resources are shrunk (e.g. omitting = certain ROA prefixes when the resources are no longer held by the CA). = However, there are a lot of moving parts here, and no software is = without bugs. This problem gets worse when certificates are received = from, or issued to third parties. In our current software we manage all = CAs in our hierarchy locally, so we *know* when something changes and we = can do the above. When dealing with 3rd parties there may be a = significant time that parent and child are out of sync about the = resources held by the child. >> The second approach in section 4 was presented at the last IETF = (draft-barnes-sidr-tao). Essentially it allows for transfer signalling = through an up-down like protocol. Technically this approach can help to = deal with transfer issues (2). > The cited approach approach is designed expressly to deal with = transfer issues, not with the > more general problem of errors by CAs. One ought not conflate these = two issues. Okay, fair enough. As long as it's clear that this is the scope. >> The 'happy case' scenarios assume though that all involved parties = play nice - and keep playing nice. There are many moving parts here, and = it's not clear to me what happens when one party walks away (e.g. goes = offline permanently). Additionally the timing of certificate shrinking = in case of a cancel is not clear to me and introduces complexity: live = transfer or not?, who signals the transfer?, when is it canceled, before = or after shrinking and/or swinging? Can a cancel be canceled? But, more = importantly, this approach offers no protection against the operational = fragility case (1). Furthermore it adds a lot of complexity and this has = huge costs in development (many months) and maintenance and introduces = more operational fragility and potential interop issues between = implementations. > Since we have NO description of resource transfer at the level of = detail provided in the TAO I-D, it seems a bit premature to describe it = as being more complex than the suggested alternative. Okay, fair enough as well. I will maintain that in my opinion the TAO = introduces a lot of complexity (and open questions above), but my belief = that it's more complicated than the alternative is based on implicit = interpretation and informal discussions about this, and not on a = detailed document. >=20 > Steve > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_2047C913-BBEF-4A5B-810C-559A9347E5DE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 kent@bbn.com> = wrote:
=20 =20
Tim,

Hi,

As you may have noticed my name was added to the author list, so it will come as no surprise that I read this document and agree with its content.

I believe that all RIRs share both operational concerns outlined in section 3: (1) Operational fragility, and (2) resource transfers. One thing to note about the second case is that we don't have this problem right now because we only offer a hosted service where our members cannot create delegated certificates. However, this will change when we enable the provisioning (up-down) system and support non-hosted CAs that may delegate further.

Section 4 describes, in very general terms, two alternative approaches to counter these concerns.

The first approach has my strong preference. I believe it's simple to explain and implement, effective against both concerns, and I do not see any security issues with it. The change boils down to this: when doing top-down validation, just accept the *intersection* of resources listed on a certificate, and its parent. The idea of keeping track of resources explicitly is not new: we already have this when using 'inherit'. We have running code in our validator for this. It took us a day to implement this. The feature is off by default of course, but it's enabled without problems on a public instance that we're running: http://localcert.ripe.net:8088/


Since you implemented this capability based on what we all agree is a rough description of the
intended functionality, can you be very confident that it is "correct"?

It's a beta = feature for a reason. But I do believe there is value in running code = and getting experience with this.

That said I = think the approach safe. And what we implemented is my, quite specific, = understanding of the intended approach. I tried to explain it in brief = above, but if this is not clear enough and the WG prefers, I would be = happy to provide more formal text for = this.


=20 More to the point, we all agree that it is very bad for an RIR or NIR to issue a cert
that would break the current validation algoroithm. In a prior message I suggested several
checks that I thought every CA operating should perform to detect and avoid such errors.
Has RIPE been performing check such as these? Might adoption of relaxed validation rules
minimize the perceived need to perform such checks, i.e., encourage sloppiness?

It is not my = intention, and I believe it's safe to say that it's not the intention of = others, to encourage sloppiness, but to minimise impact and improve = resiliency if an error does occur.

Speaking for = our own CA implementation. We have code in place to ensure that we = cannot create over-claiming certificates. We also have code to re-issue = products as needed when resources are shrunk (e.g. omitting certain ROA = prefixes when the resources are no longer held by the CA). However, = there are a lot of moving parts here, and no software is without bugs. = This problem gets worse when certificates are received from, or issued = to third parties. In our current software we manage all CAs in our = hierarchy locally, so we *know* when something changes and we can do the = above. When dealing with 3rd parties there may be a significant time = that parent and child are out of sync about the resources held by the = child.


The second approach in section 4 was presented at the last IETF (draft-barnes-sidr-tao). Essentially it allows for transfer signalling through an up-down like protocol. Technically this approach can help to deal with transfer issues (2).
The cited approach approach is designed expressly to deal with transfer issues, not with the
more general problem of errors by CAs. One ought not conflate these two = issues.

Okay, fair = enough. As long as it's clear that this is the = scope.

The 'happy case' scenarios assume though that all involved parties play nice - and keep playing nice. There are many moving parts here, and it's not clear to me what happens when one party walks away (e.g. goes offline permanently). Additionally the timing of certificate shrinking in case of a cancel is not clear to me and introduces complexity: live transfer or not?, who signals the transfer?, when is it canceled, before or after shrinking and/or swinging? Can a cancel be canceled? But, more importantly, this approach offers no protection against the operational fragility case (1). Furthermore it adds a lot of complexity and this has huge costs in development (many = months) and maintenance and introduces more operational fragility = and potential interop issues between implementations.
Since we have NO description of resource transfer at the level of detail provided in the TAO I-D, it seems a bit premature to describe it as being more complex than the suggested = alternative.

Okay, fair enough = as well. I will maintain that in my opinion the TAO introduces a lot of = complexity (and open questions above), but my belief that it's more = complicated than the alternative is based on implicit interpretation and = informal discussions about this, and not on a detailed = document.




= --Apple-Mail=_2047C913-BBEF-4A5B-810C-559A9347E5DE-- From nobody Thu Jul 24 09:09:44 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 88B6A1A03AC for ; Thu, 24 Jul 2014 09:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 jcUKT9Evr0El for ; Thu, 24 Jul 2014 09:09:39 -0700 (PDT) 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 665F21A0371 for ; Thu, 24 Jul 2014 09:09:39 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XALaH-00070G-Ag; Thu, 24 Jul 2014 18:09:34 +0200 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-246.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1XALaH-0004bH-3A; Thu, 24 Jul 2014 18:09:33 +0200 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=windows-1252 From: Tim Bruijnzeels In-Reply-To: Date: Thu, 24 Jul 2014 12:09:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <88B177B6-431E-4D8C-8532-E64BF2FE0EF8@ripe.net> References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <680AF9DB-5B60-48C7-805A-1E8B6C59642C@vigilsec.com> To: Sandra Murphy X-Mailer: Apple Mail (2.1510) 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 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: 784d7acfe6559f2a0b602ec6519a0719ba36256d2caf98d85d03308b6bf3444a Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/MoEf4P118G6I1hKnNS9zOml0viM Cc: IETF SIDR Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 16:09:41 -0000 On Jul 24, 2014, at 11:30 AM, Sandra Murphy wrote: > On Jul 24, 2014, at 10:37 AM, Russ Housley = wrote: > =85 >> RFC 3779 has been implemented. For example, OpenSSL implements RFC = 3779, and others make use of this certificate handling software. We are = not talking about a little tweak to such a library. Implementation = would require a path validation parameter to pass the content of the = ROA. >=20 > Not sure that's the case. I think all RPKI recipients now need to do = a computation of which of a cert's resources are valid, which are not. = The *recipients* decide what the certificate says. This will impact = interpretation of a ROA but I don't think it requires something that has = to get passed around with the ROA. Okay, let me elaborate a bit on how we do this.. We don't use openssl for this. We have our own implementation and the = way we do this is fully top-down. We don't pass the content of the ROA = we are interested in around at all. We just keep track of the resources = we *accept* at each stage in the top-down validation. We then insist (as = know) that the ROA EE certificate has the resources (we accepted) for = all the prefixes mentioned on it, and if not we reject it. Resource certificates can already have the inherit flag in RFC3779. In = such cases we already implicitly copy the parent resources, rather than = reading them from the certificate itself. So we are already keeping a = set of validated resources for each step in the chain in the context of = a top-down validation. The change is that rather than rejecting an over-claiming cert and = everything below, we will only accept the intersection of resources = mentioned on an otherwise valid child certificate and its parent = certificate. And this is applied recursively down the chain. In other = words: we don't necessarily believe what the certificate says, but we = always evaluate this in the context of a top-down walk. The main idea here is that these certificates do nothing more than tying = a set of validated resources to validated keys. Whether over-claiming = actually is a problem is only relevant when we look at other statements = about these resources, such as ROAs, router certificates etc. If they = refer to a resource that was over-claimed, they are rejected. As mentioned before this change was actually trivial to implement for us = as a beta feature. Tim From nobody Thu Jul 24 09:39:08 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 46DB41A03D4 for ; Thu, 24 Jul 2014 09:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 u2CPPKxxIuAE for ; Thu, 24 Jul 2014 09:38:59 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F19CE1A042D for ; Thu, 24 Jul 2014 09:38:58 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:40024 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XAM2w-000Jsh-Rb for sidr@ietf.org; Thu, 24 Jul 2014 12:39:10 -0400 Message-ID: <53D136A1.6010204@bbn.com> Date: Thu, 24 Jul 2014 12:38:57 -0400 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: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <680AF9DB-5B60-48C7-805A-1E8B6C59642C@vigilsec.com> 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/uweDFPl2CJTm5WhUYWLauAW4kHQ Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 16:39:07 -0000 Sandy, > ... > When this working group was developing the RPKI specifications, the RIRs essentially asked us not to specify how the "movement of resources across registries" would take place. I for one accepted this at the time because it looked like an issue between RIRs. This document is calling for a make-before-break certificate issuance capability. Maybe there are other motives too. > There are two cases. > > One is the transfer case and the need to revise certs upward on the giving side and downward on the receiving side. That's the make-before-break part. > The other is the problem of removing resources from certs - one CA reissues a "smaller" cert, and reissuing has to take place down the chain for the resources that are retained, in order to keep the encompassing rules valid. The pain is felt in the CA's descendants until other CAs get their re-issuance done. The second case merits further analysis, I think. If the INRs being removed are not in use at lower tier CAs, then maybe they are not allocated in certs issued to those CAs, and the process is trivial. If the INRs have been allocated to lower tier CAs, and thus they are represented in the certs of the CAs, then one would not expect to remove the INRs in a top down basis anyway, right? One would expect the lowest tier CA holding the INRs that are to be returned to be the fist to relinquish them. Then this would propagate up the chain, consistent with each CA updating its databases to reflect the new allocation status. RPKI docs consistently state that certs are issued ti reflect the INR databases of the entities acting as CAs. These databases ought not be updated to reflect a return of INRs until that return has taken place. So, it seems that the only artificial timing issue is the lag one has to accept in terms of RPKI repository (and cache) propagation. But, we already know that such lags are intrinsic in the RPKI. Also, what are the requirements, vis-a-vis timing, for completing INR removal? How man tiers of CAs are involved? >> RFC 3779 has been implemented. For example, OpenSSL implements RFC 3779, and others make use of this certificate handling software. We are not talking about a little tweak to such a library. Implementation would require a path validation parameter to pass the content of the ROA. > Not sure that's the case. I think all RPKI recipients now need to do a computation of which of a cert's resources are valid, which are not. The *recipients* decide what the certificate says. This will impact interpretation of a ROA but I don't think it requires something that has to get passed around with the ROA. Having looked at our RP software, I believe the revised vaidation approach (based on the current, informal spec) would require that we compute the intersection of parent and child CA certs along each cert path and store the result. This is independent of whether one is later using the path to validate a ROA (with it's embedded EE cert) or a router cert (in BGPSEC). Maybe Russ was alluding to the need to pass that intersection of INR sets to the ROA validation process. > >> As I understand the situation, the existing specification works, but it imposes some restrictions on the order that certificates that must be issued and distributed. > There's a order problem in the transfer case and a timing problem in the reduction case. This seems like a good characterization, but I question whether the timing restrictions are really important. Also, in the INR transfer case, I've seen detailed slides at APNIC meetings showing how inter-RIR xfers work today. It is a process with a number of steps, and some, limited parallelism. It's not clear how much additional parallelism one can achieve with the proposed validation procedure, without violating the CP. We have a spec of the details of INR xfer in TAO. We don't yet have an analogous spec for the proposed validation model. Until we do, we can't accurately compare the proposed scenario vs. the existing one. Steve From nobody Thu Jul 24 10:26: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 3CD521ABB26 for ; Thu, 24 Jul 2014 10:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 o_w30pEv1DLO for ; Thu, 24 Jul 2014 10:26:28 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id AE3661A0B06 for ; Thu, 24 Jul 2014 10:25:27 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 6A01028B0041; Thu, 24 Jul 2014 13:25:27 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 2FDC31F8032; Thu, 24 Jul 2014 13:25:25 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_DB548A84-D4A7-4893-845D-BA26F03C0DE0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: <88B177B6-431E-4D8C-8532-E64BF2FE0EF8@ripe.net> Date: Thu, 24 Jul 2014 13:25:25 -0400 Message-Id: <46C35EC0-BDE3-4A81-94F4-5C4DD1B519E6@tislabs.com> References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <680AF9DB-5B60-48C7-805A-1E8B6C59642C@vigilsec.com> <88B177B6-431E-4D8C-8532-E64BF2FE0EF8@ripe.net> To: Tim Bruijnzeels X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/rkpGbLTJIJ1wlomNmipCdm24V3c Cc: IETF SIDR , Sandra Murphy Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 17:26:30 -0000 --Apple-Mail=_DB548A84-D4A7-4893-845D-BA26F03C0DE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 speaking as regular ol' member On Jul 24, 2014, at 12:09 PM, Tim Bruijnzeels wrote: >=20 > On Jul 24, 2014, at 11:30 AM, Sandra Murphy wrote: >> On Jul 24, 2014, at 10:37 AM, Russ Housley = wrote: >> =85 >=20 >>> RFC 3779 has been implemented. For example, OpenSSL implements RFC = 3779, and others make use of this certificate handling software. We are = not talking about a little tweak to such a library. Implementation = would require a path validation parameter to pass the content of the = ROA. >>=20 >> Not sure that's the case. I think all RPKI recipients now need to do = a computation of which of a cert's resources are valid, which are not. = The *recipients* decide what the certificate says. This will impact = interpretation of a ROA but I don't think it requires something that has = to get passed around with the ROA. I may have misread what Russ meant. When I said "passed around", I = meant passed with the ROA to someone downloading the RPKI data. --Sandy --Apple-Mail=_DB548A84-D4A7-4893-845D-BA26F03C0DE0 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 iQIcBAEBCgAGBQJT0UGFAAoJEHplpQeet0IZDMEP/0EQTNRO2/OBWZGZ1ciSTQZy Y0aNDs2CbvxVUu/bCeChN/Aq77HfofG8oeM9jxOhTpEUdVuQY0ApzIaBAFH8LbIE hImkoltD7dzeSFBw5bS7Qcit/hj2iu4BvdltNxAvBe7ivqmbTHXZKt1PAGX1ONBE I1Tc+4zJu5x92b8p1mrRQkdrZ3LVurwc/s2stkNNAj8oa/ybI4j5vfHfJBjCvhJ8 97Z4k4W0usFFxyXlV2GeHhX474cWaZqhCH0R7/TDXyg5tz14hk/bSHZP3QK73Im+ EytZAP8n3qdb9Aa0a9qjcFcNrc2Ai2WXcrEuQLr1fPQvVscbchmcdg1xB6aMb1gT bJyYsOjxy/2PmsmqOMCvQ1eprCX6OTZ7nnDCtG9MHQ5tp5BbvemmrWTPDrCRj2Wd rPBagkVXq9aSN3oqYuKphMsssT/Lr3tnYgqs9Ygvk1ltQEoNbWGbnm1xwRl9UYGI C82dwhAN9Fo6gRhLsihXglJ3phvVXx2P5NoKMcSVezGqijkbWOjzzPQcG3Wx7InJ BM85pjuiW9zumtsa9DdM8Wu3J+VHD3l2d8xB/Z4uGM8G+C7dr6OoQRPldlDU/k/7 wrcYPZ5bVp/Dk26UT3+/EH9KKIQd83EQBCiKxuEdhCYjFnYbaozWT49f74GM2/qn cictyVVu6FOaU/Duo6h2 =wnbA -----END PGP SIGNATURE----- --Apple-Mail=_DB548A84-D4A7-4893-845D-BA26F03C0DE0-- From nobody Thu Jul 24 10:31: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 BE8621A0AE1 for ; Thu, 24 Jul 2014 10:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 SQutKQTHzrJn for ; Thu, 24 Jul 2014 10:31:22 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF00D1A03EC for ; Thu, 24 Jul 2014 10:31:22 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:47948 helo=dhcp-a77c.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XAMre-000KHp-Oj for sidr@ietf.org; Thu, 24 Jul 2014 13:31:34 -0400 Message-ID: <53D142E9.5030006@bbn.com> Date: Thu, 24 Jul 2014 13:31:21 -0400 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: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <680AF9DB-5B60-48C7-805A-1E8B6C59642C@vigilsec.com> <88B177B6-431E-4D8C-8532-E64BF2FE0EF8@ripe.net> In-Reply-To: <88B177B6-431E-4D8C-8532-E64BF2FE0EF8@ripe.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/Yni0DZ9pUmByy4KLWp9VEWbA0l0 Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 17:31:24 -0000 Tim, Thanks for providing the description of the processing you employ in your RP software. > ... > Okay, let me elaborate a bit on how we do this.. > > We don't use openssl for this. We have our own implementation and the way we do this is fully top-down. We don't pass the content of the ROA we are interested in around at all. We just keep track of the resources we *accept* at each stage in the top-down validation. We then insist (as know) that the ROA EE certificate has the resources (we accepted) for all the prefixes mentioned on it, and if not we reject it. In the 3779 spec, it is not necessary to maintain a list of valid INRs at each tier, so long as one caches only valid certs. It suffices to compare the INRs in a subordinate cert against those in the parent. > Resource certificates can already have the inherit flag in RFC3779. In such cases we already implicitly copy the parent resources, rather than reading them from the certificate itself. So we are already keeping a set of validated resources for each step in the chain in the context of a top-down validation. Yes, the inherit flag does require creating a list of INRs for a cert that contains such a flag. > The change is that rather than rejecting an over-claiming cert and everything below, we will only accept the intersection of resources mentioned on an otherwise valid child certificate and its parent certificate. And this is applied recursively down the chain. In other words: we don't necessarily believe what the certificate says, but we always evaluate this in the context of a top-down walk. > > The main idea here is that these certificates do nothing more than tying a set of validated resources to validated keys. Whether over-claiming actually is a problem is only relevant when we look at other statements about these resources, such as ROAs, router certificates etc. If they refer to a resource that was over-claimed, they are rejected. From an operational perspective I agree that over claiming is a problem when an EE cert for a ROA (or a Manifest, or a GB record, etc.) includes the INRs in question. But, a CA that issues a cert containing resources that have not been allocated to it by its parent is violating the CP. That bothers me, as it undermines a fundamental tenet of the RPKI. Steve From nobody Thu Jul 24 10:53: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 D8C1E1B27B6 for ; Thu, 24 Jul 2014 10:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 bXfkoSvD_uRe for ; Thu, 24 Jul 2014 10:53:33 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91AEC1B27B2 for ; Thu, 24 Jul 2014 10:53:05 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:55958 helo=dhcp-a77c.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XANCf-000KV1-OT for sidr@ietf.org; Thu, 24 Jul 2014 13:53:17 -0400 Message-ID: <53D14800.4030706@bbn.com> Date: Thu, 24 Jul 2014 13:53:04 -0400 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: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <680AF9DB-5B60-48C7-805A-1E8B6C59642C@vigilsec.com> <88B177B6-431E-4D8C-8532-E64BF2FE0EF8@ripe.net> <46C35EC0-BDE3-4A81-94F4-5C4DD1B519E6@tislabs.com> In-Reply-To: <46C35EC0-BDE3-4A81-94F4-5C4DD1B519E6@tislabs.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/NsCStKf2A_6MZFCYumUl8sV8q90 Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 17:53:44 -0000 Sandy, > speaking as regular ol' member > > On Jul 24, 2014, at 12:09 PM, Tim Bruijnzeels wrote: > >> On Jul 24, 2014, at 11:30 AM, Sandra Murphy wrote: >>> On Jul 24, 2014, at 10:37 AM, Russ Housley wrote: >>> … >>>> RFC 3779 has been implemented. For example, OpenSSL implements RFC 3779, and others make use of this certificate handling software. We are not talking about a little tweak to such a library. Implementation would require a path validation parameter to pass the content of the ROA. >>> Not sure that's the case. I think all RPKI recipients now need to do a computation of which of a cert's resources are valid, which are not. The *recipients* decide what the certificate says. This will impact interpretation of a ROA but I don't think it requires something that has to get passed around with the ROA. > I may have misread what Russ meant. When I said "passed around", I meant passed with the ROA to someone downloading the RPKI data. For that interpretation of "passed around" I agree that this is not the case, i.e., no added data need be downloaded from a repository or cache. Steve From nobody Thu Jul 24 11:35:34 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 8FC6E1B27E3 for ; Thu, 24 Jul 2014 11:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, WEIRD_PORT=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 dOs9vmnM4P4L for ; Thu, 24 Jul 2014 11:35:30 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F8A61B27D9 for ; Thu, 24 Jul 2014 11:35:30 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:34465 helo=dhcp-a77c.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XANrU-000OCW-Ar; Thu, 24 Jul 2014 14:35:28 -0400 Message-ID: <53D151F0.80808@bbn.com> Date: Thu, 24 Jul 2014 14:35:28 -0400 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: Tim Bruijnzeels References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040106050505020003030306" Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/mTh0HxZQidhzdwLVFNCcdjcsZs8 Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:35:33 -0000 This is a multi-part message in MIME format. --------------040106050505020003030306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tim, > ... >>> >>> The first approach has my strong preference. I believe it's simple >>> to explain and implement, effective against both concerns, and I do >>> not see any security issues with it. The change boils down to this: >>> when doing top-down validation, just accept the *intersection* of >>> resources listed on a certificate, and its parent. The idea of >>> keeping track of resources explicitly is not new: we already have >>> this when using 'inherit'. We have running code in our validator for >>> this. It took us a day to implement this. The feature is off by >>> default of course, but it's enabled without problems on a public >>> instance that we're running: http://localcert.ripe.net:8088/ > > What I forgot to mention above is that we do issue warnings on over > claiming certificates. So this is visible, although so-far we have not > seen these warnings in the RIR production repositories. Can you says what tests you perform and how will they change if we adopt a relaxed path validation alg? > >> More to the point, we all agree that it is very bad for an RIR or NIR >> to issue a cert >> that would break the current validation algoroithm. In a prior >> message I suggested several >> checks that I thought every CA operating should perform to detect and >> avoid such errors. >> Has RIPE been performing check such as these? Might adoption of >> relaxed validation rules >> minimize the perceived need to perform such checks, i.e., encourage >> sloppiness? > > It is not my intention, and I believe it's safe to say that it's not > the intention of others, to encourage sloppiness, but to minimise > impact and improve resiliency if an error does occur. I understand this motive, but we have seen many examples over time where accepting non-conforming data results in progressive degradation of implementations. This is why the RPKI specs mandate RP enforcement of the criteria that CAs are supposed to follow in issuing certs. This is in contrast to the normal PKI specs which mandate CA cert generation rules, but do no generally require RPs to check that certs have been generated consistent with these rules. In the Web PKI context, this has resulted in a lot of "broken" certs being issued, and then accepted by RPs, with not so great results. So, I think it is hard to increase resilience yet maintain sufficient feedback to CAs to help encourage standards compliance. > Speaking for our own CA implementation. We have code in place to > ensure that we cannot create over-claiming certificates. We also have > code to re-issue products as needed when resources are shrunk (e.g. > omitting certain ROA prefixes when the resources are no longer held by > the CA). However, there are a lot of moving parts here, and no > software is without bugs. This problem gets worse when certificates > are received from, or issued to third parties. In our current software > we manage all CAs in our hierarchy locally, so we *know* when > something changes and we can do the above. When dealing with 3rd > parties there may be a significant time that parent and child are out > of sync about the resources held by the child. see my question above about how you ensure that certs don't over-claim and how the mechanisms would change if path validation were relaxed. > > >>> The second approach in section 4 was presented at the last IETF >>> (draft-barnes-sidr-tao). Essentially it allows for transfer >>> signalling through an up-down like protocol. Technically this >>> approach can help to deal with transfer issues (2). >> The cited approach approach is designed expressly to deal with >> transfer issues, not with the >> more general problem of errors by CAs. One ought not conflate these >> two issues. > > Okay, fair enough. As long as it's clear that this is the scope. The first sentence of the Abstract for TAO says: This document defines an extension to the rpki-updown protocol to provide support for transferring Internet Number Resources from one INR holder to another. That seems pretty clear. Steve --------------040106050505020003030306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Tim,

...

The first approach has my strong preference. I believe it's simple to explain and implement, effective against both concerns, and I do not see any security issues with it. The change boils down to this: when doing top-down validation, just accept the *intersection* of resources listed on a certificate, and its parent. The idea of keeping track of resources explicitly is not new: we already have this when using 'inherit'. We have running code in our validator for this. It took us a day to implement this. The feature is off by default of course, but it's enabled without problems on a public instance that we're running: http://localcert.ripe.net:8088/

What I forgot to mention above is that we do issue warnings on over claiming certificates. So this is visible, although so-far we have not seen these warnings in the RIR production repositories.
Can you says what tests you perform and how will they change if we adopt a relaxed path validation alg?

More to the point, we all agree that it is very bad for an RIR or NIR to issue a cert
that would break the current validation algoroithm. In a prior message I suggested several
checks that I thought every CA operating should perform to detect and avoid such errors.
Has RIPE been performing check such as these? Might adoption of relaxed validation rules
minimize the perceived need to perform such checks, i.e., encourage sloppiness?

It is not my intention, and I believe it's safe to say that it's not the intention of others, to encourage sloppiness, but to minimise impact and improve resiliency if an error does occur.
I understand this motive, but we have seen many examples over time where accepting non-conforming
data results in progressive degradation of implementations. This is why the RPKI specs mandate
RP enforcement of the criteria that CAs are supposed to follow in issuing certs.  This is in
contrast to the normal PKI specs which mandate CA cert generation rules, but do no generally
require RPs to check that certs have been generated consistent with these rules. In the Web PKI
context, this has resulted in a lot of "broken" certs being issued, and then accepted by RPs,
with not so great results. So, I think it is hard to increase resilience yet maintain sufficient
feedback to CAs to help encourage standards compliance.
Speaking for our own CA implementation. We have code in place to ensure that we cannot create over-claiming certificates. We also have code to re-issue products as needed when resources are shrunk (e.g. omitting certain ROA prefixes when the resources are no longer held by the CA). However, there are a lot of moving parts here, and no software is without bugs. This problem gets worse when certificates are received from, or issued to third parties. In our current software we manage all CAs in our hierarchy locally, so we *know* when something changes and we can do the above. When dealing with 3rd parties there may be a significant time that parent and child are out of sync about the resources held by the child.
see my question above about how you ensure that certs don't over-claim and how the mechanisms
would change if path validation were relaxed.


The second approach in section 4 was presented at the last IETF (draft-barnes-sidr-tao). Essentially it allows for transfer signalling through an up-down like protocol. Technically this approach can help to deal with transfer issues (2).
The cited approach approach is designed expressly to deal with transfer issues, not with the
more general problem of errors by CAs. One ought not conflate these two issues.

Okay, fair enough. As long as it's clear that this is the scope.
The first sentence of the Abstract for TAO says:

   This document defines an extension to the rpki-updown protocol to

   provide support for transferring Internet Number Resources from one

   INR holder to another. 

That seems pretty clear.

Steve
--------------040106050505020003030306-- From nobody Thu Jul 24 11:54:12 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 616911A0063 for ; Thu, 24 Jul 2014 11:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 BZXtslCKJ00Y for ; Thu, 24 Jul 2014 11:54:07 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 2F63C1A002A for ; Thu, 24 Jul 2014 11:54:07 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id DE86328B0041 for ; Thu, 24 Jul 2014 14:54:06 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id AE74E1F8032; Thu, 24 Jul 2014 14:54:06 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_9E590C59-02B3-428C-8659-621197C6DD40"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 24 Jul 2014 14:54:06 -0400 Message-Id: <4C2B730F-3BED-40CF-BBD6-90F97B69E22D@tislabs.com> To: IETF SIDR 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/MO7W75jaoPlsYu_5dX9dLmGGjU4 Cc: Sandra Murphy Subject: [sidr] comment on draft-ietf-sidr-bgpsec-protocol and draft-ietf-sidr-bgpsec-ops 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, 24 Jul 2014 18:54:09 -0000 --Apple-Mail=_9E590C59-02B3-428C-8659-621197C6DD40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Speaking as regular ol' member The bgpsec-protocol draft has the following text: Next, the BGPSEC speaker verifies that the origin AS is authorized to advertise the prefix in question. To do this, consult the valid ROA data to obtain a list of AS numbers that are associated with the given IP address prefix in the update message. Then locate the last (least recently added) AS number in the Secure_Path portion of the BGPSEC_Path attribute. If the origin AS in the Secure_Path is not in the set of AS numbers associated with the given prefix, then the BGPSEC update message is 'Not Valid' and the validation algorithm terminates. This text reprises the origin validation algorithm, without some of the = more detailed pieces. I believe it would be better instead to refer to RFC6483 or RFC6811, = rather than try to reprise the algorithm. Something like: "To do this, = the speaker performs the algorithm of RFC6483/RFC6811. If the result is = not Valid, then the BGP Update is 'Not Valid'." (This seems particularly prudent as we might be reconsidering the = validation algorithm.) This also brought to mind a point I'm curious about. =20 Does a bgpsec speaking router have one configuration about the results = of the bgpsec validation, or does it have two configurations, one for = the results of the origin validation and a second for the results of the = bgpsec validation? Are the two validation states separated? Should this be a point to be explained in the bgpsec-ops document?=20 --Sandy, speaking as regular ol' member --Apple-Mail=_9E590C59-02B3-428C-8659-621197C6DD40 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 iQIcBAEBCgAGBQJT0VZPAAoJEHplpQeet0IZteYQAI36ns8RIMuHKTKefSMLsQUM sbA/JDQaPtYCrAkxADallNlcDHcyYCgFEMjgoCE0285vW2hihABWMmhFzdfs2zFD 3Hyv6UU1fTA+Orp1Qx/kb3GLNA3T2hP0NRKgUKkshDgTm04L+/s5tFXBQUXgEGz2 qTNqOgbgs5toeg5FsshTD6obWIdYrpBWYx9NhtVg7VqVXNjS3rYTegRElgp+vLX4 K5jehpbCsKDbSd3JV1YixWAO3OpvvSEe4MFtQpXEmz586GjeyMXfhxyiuLGLcsvx 2boSXIfruN7Igeh5f79xudNeuSWw6ngVurudjCX2l1XlMJaf6XrUW6/nV4GRM2SU XTFVIB4qkETDfP2fxMeS5IYS4xcQ5rpy6YYBZJBZWW8e9OZdoHYKQTSaEyvxjZ97 d2tohbGuGQsobWlQoCtxYFFzQ3ulM6SW5nIas90NI1gc7T1bm2XUOxKJ+fDzJKQR ufrW07ZeYoEvV2GRRiAdAIm6+FFDWVLEv1tzU+UE06kP5xqIQAxAxpXDsUUic82O cuPW7GwVBIPm2E/3yPt/PXf5RXyntlt9Db9p1hdVsTEc9KVeIPCxBBpjnrtxUsMK suNJFEPMP350pym/9Xw/81Z4O34TiQnG8VaRIun2MC5tC9Y2a3hen3QBg+nmJ0/w Z7+jbMlaQDPTYIVOZSXL =croB -----END PGP SIGNATURE----- --Apple-Mail=_9E590C59-02B3-428C-8659-621197C6DD40-- From nobody Thu Jul 24 12:06:10 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 BEA7F1B2877 for ; Thu, 24 Jul 2014 12:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 6-laBXVr968N for ; Thu, 24 Jul 2014 12:05:58 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B617C1B286B for ; Thu, 24 Jul 2014 12:05:57 -0700 (PDT) Received: from BN1PR09MB108.namprd09.prod.outlook.com (10.255.199.24) by BN1PR09MB107.namprd09.prod.outlook.com (10.255.199.23) with Microsoft SMTP Server (TLS) id 15.0.990.7; Thu, 24 Jul 2014 19:05:56 +0000 Received: from BN1PR09MB108.namprd09.prod.outlook.com ([10.255.199.24]) by BN1PR09MB108.namprd09.prod.outlook.com ([10.255.199.24]) with mapi id 15.00.0990.007; Thu, 24 Jul 2014 19:05:56 +0000 From: "Montgomery, Douglas" To: Sandra Murphy , IETF SIDR Thread-Topic: [sidr] comment on draft-ietf-sidr-bgpsec-protocol and draft-ietf-sidr-bgpsec-ops Thread-Index: AQHPp3CrN/u1ra1MPU66wpaRDNDMgJuvUqKA Importance: low X-Priority: 5 Date: Thu, 24 Jul 2014 19:05:55 +0000 Message-ID: References: <4C2B730F-3BED-40CF-BBD6-90F97B69E22D@tislabs.com> In-Reply-To: <4C2B730F-3BED-40CF-BBD6-90F97B69E22D@tislabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [129.6.218.129] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(24454002)(51704005)(377454003)(479174003)(31966008)(85306003)(99396002)(2656002)(101416001)(64706001)(74662001)(105586002)(81542001)(80022001)(106116001)(99286002)(86362001)(77982001)(74502001)(4396001)(20776003)(85852003)(106356001)(92566001)(107046002)(66066001)(36756003)(83322001)(79102001)(107886001)(83506001)(19580405001)(19580395003)(54356999)(76176999)(50986999)(92726001)(81342001)(87936001)(83072002)(21056001)(76482001)(46102001)(95666004)(81686999); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR09MB107; H:BN1PR09MB108.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: <762EBEE3BF8EA1498F354C2A141A84E8@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/ipQxpd5WXv2KFZBsZqj9BG-ehAI Subject: Re: [sidr] comment on draft-ietf-sidr-bgpsec-protocol and draft-ietf-sidr-bgpsec-ops 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, 24 Jul 2014 19:06:04 -0000 On 7/24/14, 2:54 PM, "Sandra Murphy" wrote: >Speaking as regular ol' member > >The bgpsec-protocol draft has the following text: > > Next, the BGPSEC speaker verifies that the origin AS is authorized to > advertise the prefix in question. To do this, consult the valid ROA > data to obtain a list of AS numbers that are associated with the > given IP address prefix in the update message. Then locate the last > (least recently added) AS number in the Secure_Path portion of the > BGPSEC_Path attribute. If the origin AS in the Secure_Path is not in > the set of AS numbers associated with the given prefix, then the > BGPSEC update message is 'Not Valid' and the validation algorithm > terminates. > >This text reprises the origin validation algorithm, without some of the >more detailed pieces. > >I believe it would be better instead to refer to RFC6483 or RFC6811, >rather than try to reprise the algorithm. Something like: "To do this, >the speaker performs the algorithm of RFC6483/RFC6811. If the result is >not Valid, then the BGP Update is 'Not Valid'." > >(This seems particularly prudent as we might be reconsidering the >validation algorithm.) > >This also brought to mind a point I'm curious about. > >Does a bgpsec speaking router have one configuration about the results of >the bgpsec validation, or does it have two configurations, one for the >results of the origin validation and a second for the results of the >bgpsec validation? Are the two validation states separated? > >Should this be a point to be explained in the bgpsec-ops document? =B3Does=B2 is an interesting question. Clearly one can. Our prototype doe= s. So far I thought we were not standardizing the local policy mechanisms that could be built off of the protocol mechanisms. Given that we permit lazy evaluation, one might envision employing RPKI-based OV on a BGPSEC update before getting around to doing PATH validation. Now providing guidance that trusting origin validation when path validation has failed might not be bad. But even there, first the first hop sig might be valid ... =20 >=20 > >--Sandy, speaking as regular ol' member =8B=20 Doug Montgomery, Mgr Internet & Scalable Systems Research NIST/ITL/ANTD From nobody Thu Jul 24 12:17:17 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 4E6CA1B280E for ; Thu, 24 Jul 2014 12:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 281FYLaJrjns for ; Thu, 24 Jul 2014 12:17:13 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0111B2803 for ; Thu, 24 Jul 2014 12:17:11 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id u56so3177386wes.14 for ; Thu, 24 Jul 2014 12:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Wdq5kwllw+xpgSkN8B7uf5A0hRF1xsUt2f6GinP3el4=; b=KYCWiUwmew0F1HZVf53Qwvqv4QSIxFa26bBq/GnvpFNYwQcf0DVtO/JVwTmUoCllWs L85Q3R4HxGzEWI6+esybL2D6qjuPuYItFDl0DwncgSNox6ySG0sGm6nkfK++TXEEVLtv g80ukCliZZNiQUmEmnoBPwviOqMUuEh3VblHvqofF++D3wohc7n/BhC7V6mfYyGek637 82Erh8adLE+GZqoDgLRIAkxmM30TWXPKpq5mex/QC5RA3SEIGQYfqWsvyD19qvKOoKM1 NOWIjEeouhUglnTYCJdLyYWttVXn/Zrih/2Jgf1VwlCjv8/bn+q3pEqnTjuWYEZXvuzL Ka1w== MIME-Version: 1.0 X-Received: by 10.195.18.8 with SMTP id gi8mr14643216wjd.75.1406229428564; Thu, 24 Jul 2014 12:17:08 -0700 (PDT) Received: by 10.216.148.138 with HTTP; Thu, 24 Jul 2014 12:17:08 -0700 (PDT) In-Reply-To: <4C2B730F-3BED-40CF-BBD6-90F97B69E22D@tislabs.com> References: <4C2B730F-3BED-40CF-BBD6-90F97B69E22D@tislabs.com> Date: Thu, 24 Jul 2014 15:17:08 -0400 Message-ID: From: Matthew Lepinski To: Sandra Murphy Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/jp-Ef2Sg0IgRM507AqWgMZi_KPE Cc: IETF SIDR Subject: Re: [sidr] comment on draft-ietf-sidr-bgpsec-protocol and draft-ietf-sidr-bgpsec-ops 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, 24 Jul 2014 19:17:15 -0000 With regards to the bgpsec-protocol document, I agree with Sandy that the protocol document should reference RFC 6811/6483. I will reference the origin validation algorithm in next version of bpgsec-protocol. With regards to the bpgsec-ops document, it isn't at all clear to me what the "right" answer is for how an implementation handles configuration of origin validation and path validation (when both are implemented). Unless there is something that we fear implementations might do that is clearly bad, I don't see value in adding text to bgpsec-ops. On Thu, Jul 24, 2014 at 2:54 PM, Sandra Murphy wrote: > Speaking as regular ol' member > > The bgpsec-protocol draft has the following text: > > Next, the BGPSEC speaker verifies that the origin AS is authorized to > advertise the prefix in question. To do this, consult the valid ROA > data to obtain a list of AS numbers that are associated with the > given IP address prefix in the update message. Then locate the last > (least recently added) AS number in the Secure_Path portion of the > BGPSEC_Path attribute. If the origin AS in the Secure_Path is not in > the set of AS numbers associated with the given prefix, then the > BGPSEC update message is 'Not Valid' and the validation algorithm > terminates. > > This text reprises the origin validation algorithm, without some of the m= ore detailed pieces. > > I believe it would be better instead to refer to RFC6483 or RFC6811, rath= er than try to reprise the algorithm. Something like: "To do this, the sp= eaker performs the algorithm of RFC6483/RFC6811. If the result is not Vali= d, then the BGP Update is 'Not Valid'." > > (This seems particularly prudent as we might be reconsidering the validat= ion algorithm.) > > This also brought to mind a point I'm curious about. > > Does a bgpsec speaking router have one configuration about the results of= the bgpsec validation, or does it have two configurations, one for the res= ults of the origin validation and a second for the results of the bgpsec va= lidation? Are the two validation states separated? > > Should this be a point to be explained in the bgpsec-ops document? > > --Sandy, speaking as regular ol' member > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From nobody Thu Jul 24 12:35: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 D1FF11A03A5 for ; Thu, 24 Jul 2014 12:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 BxLuWcno2BsA for ; Thu, 24 Jul 2014 12:35:50 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6BF31B27A3 for ; Thu, 24 Jul 2014 12:35:50 -0700 (PDT) Received: from minas-ithil.hactrn.net (dhcp-a613.meeting.ietf.org [31.133.166.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 3DC445C82 for ; Thu, 24 Jul 2014 19:35:50 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id E7E0010160EB for ; Thu, 24 Jul 2014 15:35:50 -0400 (EDT) Date: Thu, 24 Jul 2014 15:35:50 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20140724193550.E7E0010160EB@minas-ithil.hactrn.net> Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/HQb2Jd9HmW163eByQDHuQ5TKthk Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 19:35:52 -0000 I don't have much to add to the current discussion that I haven't already said in previous discussion, but do have one additional datum: A few months ago I said that it seemed possible that the validation-reconsidered approach would alleviate some potential race conditions involved in the loosely consistent database model. For what it's worth, I would like to report that in the one timing-related corner case we managed to explore all the way down to the end of the rat hole, it turned out that validation-reconsidered was irrelevant, because the normal certificate revocation process during a resource reduction produced the same effect regardless of the order in which the RP saw the RPKI objects in question. In other words: no smoking gun found. From nobody Thu Jul 24 13:14: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 7B5461ABB2E for ; Thu, 24 Jul 2014 13:14:53 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, WEIRD_PORT=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 dqMIjpoewopA for ; Thu, 24 Jul 2014 13:14:50 -0700 (PDT) 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 EEA711ABB27 for ; Thu, 24 Jul 2014 13:14:49 -0700 (PDT) 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 1XAPPZ-0002pW-Fd; Thu, 24 Jul 2014 22:14:47 +0200 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-73.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1XAPPY-0001u6-58; Thu, 24 Jul 2014 22:14:45 +0200 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_FA0B68B2-4661-408B-8C8B-54699DC88214" From: Tim Bruijnzeels In-Reply-To: <53D151F0.80808@bbn.com> Date: Thu, 24 Jul 2014 16:14:40 -0400 Message-Id: References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1510) 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 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 WEIRD_PORT URI: Uses non-standard port number for HTTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719fd56ae66617bb71b38d3351209aaef67 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/o0UNUSfDeEn955o8aHHmWt5oaW4 Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 20:14:53 -0000 --Apple-Mail=_FA0B68B2-4661-408B-8C8B-54699DC88214 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, a few more comments.. after this I think it's better (from my end) to = discuss tomorrow in the working group. On Jul 24, 2014, at 2:35 PM, Stephen Kent wrote: > Tim, >=20 >> ... >>>>=20 >>>> The first approach has my strong preference. I believe it's simple = to explain and implement, effective against both concerns, and I do not = see any security issues with it. The change boils down to this: when = doing top-down validation, just accept the *intersection* of resources = listed on a certificate, and its parent. The idea of keeping track of = resources explicitly is not new: we already have this when using = 'inherit'. We have running code in our validator for this. It took us a = day to implement this. The feature is off by default of course, but it's = enabled without problems on a public instance that we're running: = http://localcert.ripe.net:8088/ >>=20 >> What I forgot to mention above is that we do issue warnings on over = claiming certificates. So this is visible, although so-far we have not = seen these warnings in the RIR production repositories. > Can you says what tests you perform and how will they change if we = adopt a relaxed path validation alg? pseudo code: Strict: parentresources =3D parentcertificate.getresources childresources =3D certificate.getresources if (parentresources contain childresources) { accept childresources } else { reject } Relaxed: parentresources =3D parentcertificate.getAcceptedResources CLAIMED_childresources =3D certificate.getresources if (parentresources contain CLAIMED_childresources) { accept CLAIMED_childresources } else { warn about over-claimed resources accept remaining } As mentioned in the other part of this thread: this applies to accepting = resources on a certificate, i.e. in connection to a key. For ROAs we do = insist that *all* resources that appear in ROA prefixes are accepted on = the EE certificate used to sign the ROA. For MFT inherit is mandatory so = it's irrelevant. For GBs also use inherit, so here the contact would = only be accepted for remaining resources. For router certificates the = router key would only be associated with accepted ASNs. >>> More to the point, we all agree that it is very bad for an RIR or = NIR to issue a cert >>> that would break the current validation algoroithm. In a prior = message I suggested several >>> checks that I thought every CA operating should perform to detect = and avoid such errors. >>> Has RIPE been performing check such as these? Might adoption of = relaxed validation rules >>> minimize the perceived need to perform such checks, i.e., encourage = sloppiness? >>=20 >> It is not my intention, and I believe it's safe to say that it's not = the intention of others, to encourage sloppiness, but to minimise impact = and improve resiliency if an error does occur. > I understand this motive, but we have seen many examples over time = where accepting non-conforming > data results in progressive degradation of implementations. This is = why the RPKI specs mandate > RP enforcement of the criteria that CAs are supposed to follow in = issuing certs. This is in > contrast to the normal PKI specs which mandate CA cert generation = rules, but do no generally > require RPs to check that certs have been generated consistent with = these rules. In the Web PKI=20 > context, this has resulted in a lot of "broken" certs being issued, = and then accepted by RPs,=20 > with not so great results. So, I think it is hard to increase = resilience yet maintain sufficient > feedback to CAs to help encourage standards compliance. And I understand that a whole tree being invalidated is a pretty strong = motivator for fixing stuff. But I find the operational impact and = liability of this happening at the top of the hierarchy = disproportionate. Therefore I am advocating a model where the impact is = limited to INRs in question. In my opinion that is still bad enough to = motivate fixing things. Very practical example: if we stuff up our TA certificate now we = invalidate 2000+ members. With relaxed validation we would only affect a = few. And yes, this is still bad enough that we would want to fix it = ASAP. >> Speaking for our own CA implementation. We have code in place to = ensure that we cannot create over-claiming certificates. We also have = code to re-issue products as needed when resources are shrunk (e.g. = omitting certain ROA prefixes when the resources are no longer held by = the CA). However, there are a lot of moving parts here, and no software = is without bugs. This problem gets worse when certificates are received = from, or issued to third parties. In our current software we manage all = CAs in our hierarchy locally, so we *know* when something changes and we = can do the above. When dealing with 3rd parties there may be a = significant time that parent and child are out of sync about the = resources held by the child. > see my question above about how you ensure that certs don't over-claim = and how the mechanisms > would change if path validation were relaxed. We currently rely on *pro-active* rules in our software that prevent = this. But I have no issues with setting up *re-active* self-monitoring = on top of this. And I have no problems with appropriate text instructing = CAs that they SHOULD or even MUST do the latter. >>>> The second approach in section 4 was presented at the last IETF = (draft-barnes-sidr-tao). Essentially it allows for transfer signalling = through an up-down like protocol. Technically this approach can help to = deal with transfer issues (2). >>> The cited approach approach is designed expressly to deal with = transfer issues, not with the >>> more general problem of errors by CAs. One ought not conflate these = two issues. >>=20 >> Okay, fair enough. As long as it's clear that this is the scope. > The first sentence of the Abstract for TAO says: > This document defines an extension to the rpki-updown protocol to > provide support for transferring Internet Number Resources from one > INR holder to another. =20 >=20 > That seems pretty clear.=20 That is indeed pretty clear. It is cited under 'alternative approaches' = though, so maybe we would do well to make it clear here that this = approach is designed to address one specific set of problems (i.e. = transfers), or leave it out. --Apple-Mail=_FA0B68B2-4661-408B-8C8B-54699DC88214 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 kent@bbn.com> = wrote:
=20 =20
Tim,

...

The first approach has my strong preference. I believe it's simple to explain and implement, effective against both concerns, and I do not see any security issues with it. The change boils down to this: when doing top-down validation, just accept the *intersection* of resources listed on a certificate, and its parent. The idea of keeping track of resources explicitly is not new: we already have this when using 'inherit'. We have running code in our validator for this. It took us a day to implement this. The feature is off by default of course, but it's enabled without problems on a public instance that we're = running: http://localcert.ripe.net:8088/

What I forgot to mention above is that we do issue warnings on over claiming certificates. So this is visible, although so-far we have not seen these warnings in the RIR production repositories.
Can you says what tests you perform and how will they change if we adopt a relaxed path validation = alg?







More to the = point, we all agree that it is very bad for an RIR or NIR to issue a cert
that would break the current validation algoroithm. In a prior message I suggested several
checks that I thought every CA operating should perform to detect and avoid such errors.
Has RIPE been performing check such as these? Might adoption of relaxed validation rules
minimize the perceived need to perform such checks, i.e., encourage sloppiness?

It is not my intention, and I believe it's safe to say that it's not the intention of others, to encourage sloppiness, but to minimise impact and improve resiliency if an error does occur.
I understand this motive, but we have seen many examples over time where accepting non-conforming
data results in progressive degradation of implementations. This is why the RPKI specs mandate
RP enforcement of the criteria that CAs are supposed to follow in issuing certs.  This is in
contrast to the normal PKI specs which mandate CA cert generation rules, but do no generally
require RPs to check that certs have been generated consistent with these rules. In the Web PKI
context, this has resulted in a lot of "broken" certs being issued, and then accepted by RPs,
with not so great results. So, I think it is hard to increase resilience yet maintain sufficient
feedback to CAs to help encourage standards = compliance.



Speaking for our own CA implementation. We have code in place to ensure that we cannot create over-claiming certificates. We also have code to re-issue products as needed when resources are shrunk (e.g. omitting certain ROA prefixes when the resources are no longer held by the CA). However, there are a lot of moving parts here, and no software is without bugs. This problem gets worse when certificates are received from, or issued to third parties. In our current software we manage all CAs in our hierarchy locally, so we *know* when something changes and we can do the above. When dealing with 3rd parties there may be a significant time that parent and child are out of sync about the resources held by the child.
see my question above about how you ensure that certs don't over-claim and how the mechanisms
would change if path validation were = relaxed.


=20
The second approach in section 4 was presented at the last IETF (draft-barnes-sidr-tao). Essentially it allows for transfer signalling through an up-down like protocol. Technically this approach can help to deal with transfer issues (2).
The cited approach approach is designed expressly to deal with transfer issues, not with the
more general problem of errors by CAs. One ought not conflate these two issues.

Okay, fair enough. As long as it's clear that this is the scope.
The first sentence of the Abstract for TAO says:

   This = document defines an extension to the rpki-updown protocol = to

   provide support for transferring Internet Number Resources from = one

   INR = holder to another. 

That seems pretty clear.

That is indeed pretty clear. It is cited under 'alternative approaches' = though, so maybe we would do well to make it clear here that this = approach is designed to address one specific set of problems (i.e. = transfers), or leave it = out.


= --Apple-Mail=_FA0B68B2-4661-408B-8C8B-54699DC88214-- From nobody Thu Jul 24 14:20: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 E034E1B2815 for ; Thu, 24 Jul 2014 14:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 fujJsxxlh8-q for ; Thu, 24 Jul 2014 14:20:45 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 907571B2885 for ; Thu, 24 Jul 2014 14:20:45 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:52247 helo=dhcp-a77c.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XAQRQ-00023R-3n; Thu, 24 Jul 2014 17:20:44 -0400 Message-ID: <53D178A6.7060502@bbn.com> Date: Thu, 24 Jul 2014 17:20:38 -0400 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: Tim Bruijnzeels References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090404010408000202000609" Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/g9m-rQAaxIQtGqWKgX6VC8qVxIM Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 21:20:48 -0000 This is a multi-part message in MIME format. --------------090404010408000202000609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tim, I think I was not clear in requesting clarification for your tests. I didn't mean to ask what your RP code does. I was asking what your CA code does to detect and reject over-claiming, and what it will do under relaxed validation rules. I ask because it may be harder to perform such checks when there is an explicit intent to issue a CA cert that contains INRs not present in the parent cert. > .... > > And I understand that a whole tree being invalidated is a pretty > strong motivator for fixing stuff. But I find the operational impact > and liability of this happening at the top of the hierarchy > disproportionate. Therefore I am advocating a model where the impact > is limited to INRs in question. In my opinion that is still bad enough > to motivate fixing things. maybe. > Very practical example: if we stuff up our TA certificate now we > invalidate 2000+ members. With relaxed validation we would only affect > a few. And yes, this is still bad enough that we would want to fix it > ASAP. With relaxed validation a CA can make a mistake that erroneously allocates INRs to a child, and there is no validation failure if the child and its descendents don't use the INRs in question. So feedback may not be as forthcoming. > The first sentence of the Abstract for TAO says: >> >> This document defines an extension to the rpki-updown protocol to >> >> provide support for transferring Internet Number Resources from one >> >> INR holder to another. >> >> That seems pretty clear. > > That is indeed pretty clear. It is cited under 'alternative > approaches' though, so maybe we would do well to make it clear here > that this approach is designed to address one specific set of problems > (i.e. transfers), or leave it out. You mean that the doc of which you are a coauthor mischaracterized TAO :-). Steve --------------090404010408000202000609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Tim,

I think I was not clear in requesting clarification for your tests. I didn't mean to
ask what your RP code does. I was asking what your CA code does to detect and reject
over-claiming, and what it will do under relaxed validation rules. I ask because it
may be harder to perform such checks when there is an explicit intent to issue a CA cert
that contains INRs not present in the parent cert.

 ....

And I understand that a whole tree being invalidated is a pretty strong motivator for fixing stuff. But I find the operational impact and liability of this happening at the top of the hierarchy disproportionate. Therefore I am advocating a model where the impact is limited to INRs in question. In my opinion that is still bad enough to motivate fixing things.
maybe.
Very practical example: if we stuff up our TA certificate now we invalidate 2000+ members. With relaxed validation we would only affect a few. And yes, this is still bad enough that we would want to fix it ASAP.
With relaxed validation a CA can make a mistake that erroneously allocates INRs to a child,
and there is no validation failure if the child and its descendents don't use the INRs in question.
So feedback may not be as forthcoming.
The first sentence of the Abstract for TAO says:

   This document defines an extension to the rpki-updown protocol to

   provide support for transferring Internet Number Resources from one

   INR holder to another. 

That seems pretty clear.

That is indeed pretty clear. It is cited under 'alternative approaches' though, so maybe we would do well to make it clear here that this approach is designed to address one specific set of problems (i.e. transfers), or leave it out.
You mean that the doc of which you are a coauthor mischaracterized TAO :-).

Steve

--------------090404010408000202000609-- From nobody Fri Jul 25 02:18:28 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 B283F1A00F1 for ; Fri, 25 Jul 2014 02:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 zWut0L3XYN8K for ; Fri, 25 Jul 2014 02:18:23 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE461A004B for ; Fri, 25 Jul 2014 02:18:23 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 117A928B0040 for ; Fri, 25 Jul 2014 05:18:23 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id E3D651F8032; Fri, 25 Jul 2014 05:18:22 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_5077DBE0-5797-45B0-8DD2-EC7214EF59DF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <24D54F13-C8C8-48AC-A687-F543FF8F2712@tislabs.com> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Fri, 25 Jul 2014 05:18:22 -0400 References: To: IETF SIDR X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/NSydtbL0ob5qPET2RL-uLXda_qY Cc: Sandra Murphy Subject: [sidr] Fwd: [GROW] Meeting information IETF90 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, 25 Jul 2014 09:18:24 -0000 --Apple-Mail=_5077DBE0-5797-45B0-8DD2-EC7214EF59DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii speaking as regular ol' member I noticed this on the GROW list. =20 Sriram mentioned this draft on the sidr list a few weeks ago. It will = be presented in GROW, which is after SIDR this morning. This work proposes adding new info to the bgpsec protocol to detect = route leaks. --Sandy, speaking as regular ol' member Begin forwarded message: > From: Christopher Morrow > Subject: [GROW] Meeting information IETF90 > Date: July 24, 2014 10:47:07 PM EDT > To: "grow@ietf.org grow@ietf.org" >=20 > since we're almost through IETF90, it must mean it's time for a grow = meeting... >=20 > http://tools.ietf.org/wg/grow/agenda >=20 > has the agenda, note that: > draft-sriram-route-leak-protection >=20 > is a new individual (for now) submission looking for some > consideration/reading/review/home. Sriram will be presenting the > content and I believe he's already worked out some arrangement with > the route-leaks-bgpsec-no-help authors for combining efforts in this > area. >=20 > See you folk tomorrow before plane/trains/automobiles commence. >=20 > -chris >=20 > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow --Apple-Mail=_5077DBE0-5797-45B0-8DD2-EC7214EF59DF 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 iQIcBAEBCgAGBQJT0iDeAAoJEHplpQeet0IZWrYP/0OW5VbL03W0Y1jDaER2r2IH Bzk9ZeEr4Kpz1WcvG2679iNXwbYjJZodsBpRPGwLKGTtgnR20DJX6f9E1nvCszkg WGrx3oJ2tFItGlhieOzpC7l9C4DrAhqumppGObS2nSC3vOJkcWgKFG0c1bRA3j8Y 9fneOLffu8kHTA2SEMcS38Gi/6HUrYzYrSngyzkdPBueAdemKfQ8dCi5nbjV5dKb 0xtHAeP4X0nczpkv0DF6tDMVpg9LG1krwltrYrob/syxOx0q5et+8ysjw8Q+cn0o ve6GLstbTS0TsKwY4Fo5rRP7VyAPMerFzLDmuhegG04dPQ3zQXsREKiiL3idRkRx BhbVZN7ZkFP0TzScJ2P/qO9Y17JreVFOrdsyKDyWXI1BFRWSiPxM+8sAD6/eItFp 1CscoizIDk7+qjaDBqk2ovNXorfVcdzHqB/vLyJk2tUKM08UKALnU8M8kf1LfIXt /oqfBh8bLVTQtTZ3xq1s9XOtM7rAeKSlYjX5zvMFx6jKdAa3sodhMigz0nCb8Ag5 DNwHqOm+a5WfMym05bj0HBFTkZUVPlyi2JmoAFGLQTTK8J/K65vV2JG8i4+hHgEF PClvwcLOjHziDL+oN1mIEkXgVtk5YxhZ72Q4HC8Jq9twDnRBFqWUDmpJEGNhuHeA OT7R1O5/hk2LAGJIQMFj =tNc9 -----END PGP SIGNATURE----- --Apple-Mail=_5077DBE0-5797-45B0-8DD2-EC7214EF59DF-- From nobody Fri Jul 25 06:09:51 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 7F76A1B2857 for ; Fri, 25 Jul 2014 06:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 Av6WG1OELQVK for ; Fri, 25 Jul 2014 06:09:44 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45D5A1B2831 for ; Fri, 25 Jul 2014 06:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:x-originating-ip:content-type: mime-version; bh=In1bJP5vfIm7E9GkQuMojYDODU8JQP47JZUFSLfq3kM=; b=yo8jYmXpsDNfnz0tQBaXOHBSRTtYtJBdWc6mvB6f/iJ1OjY9nsA3lkfJ72OoaBcxwHWekvf7xYFVw p6CMWdloy6zdfhJC1s73/nxiLIvEckJqwQUzbyszRnOoqU0b/1KhZLLWD0Si0HIO+602hjN+5CDVSn ayJW60plD22SjxPo= Received: from iamda3.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS; Fri, 25 Jul 2014 23:09:37 +1000 (EST) Received: from NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67]) by iamda3.org.apnic.net ([fe80::e195:c0e8:e814:db75%15]) with mapi id 14.01.0218.012; Fri, 25 Jul 2014 23:09:40 +1000 From: Byron Ellacott To: Stephen Kent , Tim Bruijnzeels Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt Thread-Index: AQHPnD4HqbRCfUo98U+dXEdIyh/oh5utaDEAgAFi9wCAADDNAIAAG7cAgAASbwCAAMYUgA== Date: Fri, 25 Jul 2014 13:09:39 +0000 Message-ID: References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> In-Reply-To: <53D178A6.7060502@bbn.com> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.101.249] Content-Type: multipart/alternative; boundary="_000_CFF7CDF24AB4Bbjeapnicnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/yYvbBffm92s_NKKmmTdzYCIxFP0 Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 13:09:49 -0000 --_000_CFF7CDF24AB4Bbjeapnicnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, From: Stephen Kent > Date: Thursday, 24 July 2014 5:20 pm To: Tim Bruijnzeels > Cc: "sidr@ietf.org" > Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidere= d-00.txt Tim, I think I was not clear in requesting clarification for your tests. I didn'= t mean to ask what your RP code does. I was asking what your CA code does to detect a= nd reject over-claiming, and what it will do under relaxed validation rules. I ask be= cause it may be harder to perform such checks when there is an explicit intent to is= sue a CA cert that contains INRs not present in the parent cert. I can't speak for RIPE, but at APNIC when a child requests a certificate fo= r us, we intersect it with our registry data, and our own CA certificate. = What we cannot do is confirm that our own parent hasn't in the meantime pub= lished a new certificate for us with some resource removed: we can only det= ect that after it has happened, and it would be preferable that detection l= eads to correction without an intermediate step of total invalidation of a = region. In a perfect world, of course, no process would ever lead to a parent shrin= king their child's certificate without adequate communication and preparati= on, but if we were in a perfect world, a large part of the use case for SID= R would be gone, because no router operator would ever make an erroneous BG= P announcement. Byron --_000_CFF7CDF24AB4Bbjeapnicnet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

From: Stephen Kent <kent@bbn.com>
Date: Thursday, 24 July 2014 5:20 p= m
To: Tim Bruijnzeels <tim@ripe.net>
Cc: "sidr@ietf.org" <sidr@i= etf.org>
Subject: Re: [sidr] I-D Action: dra= ft-ietf-sidr-rpki-validation-reconsidered-00.txt

Tim,

I think I was not clear in requesting clarification for your tests. I didn'= t mean to
ask what your RP code does. I was asking what your CA code does to detect a= nd reject
over-claiming, and what it will do under relaxed validation rules. I ask be= cause it
may be harder to perform such checks when there is an explicit intent to is= sue a CA cert
that contains INRs not present in the parent cert.

I can't speak for RIPE, but at APNIC when a child requests a certifica= te for us, we intersect it with our registry data, and our own CA certifica= te.  What we cannot do is confirm that our own parent hasn't in the me= antime published a new certificate for us with some resource removed: we can only detect that after it has happen= ed, and it would be preferable that detection leads to correction without a= n intermediate step of total invalidation of a region.

In a perfect world, of course, no process would ever lead to a parent = shrinking their child's certificate without adequate communication and prep= aration, but if we were in a perfect world, a large part of the use case fo= r SIDR would be gone, because no router operator would ever make an erroneous BGP announcement.

  Byron

--_000_CFF7CDF24AB4Bbjeapnicnet_-- From nobody Fri Jul 25 07:54: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 E768C1B29B6 for ; Fri, 25 Jul 2014 07:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 2AMxn2D1NW0Z for ; Fri, 25 Jul 2014 07:54:34 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A0021B27AF for ; Fri, 25 Jul 2014 07:54:34 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so1139716wiv.7 for ; Fri, 25 Jul 2014 07:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=TshnDjPDmuMhKMFIFmVrt1kdgZbxw9DHbtMsS2YbyIw=; b=ZqpQWetoIx1lAIP0MvEzFWjjBEUG1USvtfYxjatjsrgTayxGFcnuozWSY19KhTjZWO yNPbjHeWx4id4aPQjvSBnyL7zSeEEF0H86aeLw9frfpIGa5AQSYce7AoQJDvHUcp68zW zkpTYBHp5CYd6zu39cRLsZzASR6RuZI3m6RfcDykvp/rs8b9QRgpIT+o0CAhyEf3WW/v fsZt5n0YlOeKmVP20prwM6bpdNzASNVE0oz9c62UHly33/t5oAPUms3NGOZH/N+yYXVo mLZDaWDx7rl5lOxUw9TpssdWLManK5gt3qVQUaGA37PVgikIT+J10vavoQ+0hV0VSGXy dMFg== MIME-Version: 1.0 X-Received: by 10.180.149.161 with SMTP id ub1mr5838902wib.32.1406300071561; Fri, 25 Jul 2014 07:54:31 -0700 (PDT) Sender: sharon.goldbe@gmail.com Received: by 10.194.46.73 with HTTP; Fri, 25 Jul 2014 07:54:31 -0700 (PDT) Date: Fri, 25 Jul 2014 07:54:31 -0700 X-Google-Sender-Auth: u2opR_gDbYIRzP6jRzY7xOAEV7M Message-ID: From: Sharon Goldberg To: sidr wg list Content-Type: multipart/alternative; boundary=001a11c37e5636900f04ff05c045 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/QQluetmmrcd7ssjWo_kp6l6tjc4 Subject: [sidr] Proposal to protect against the "Dutch Police Attack" 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, 25 Jul 2014 14:54:36 -0000 --001a11c37e5636900f04ff05c045 Content-Type: text/plain; charset=UTF-8 All We (at Boston University) have a proposal that protects against the "Dutch Police Attack" where the RPKI is used for IP prefix takedowns. The proposal, which will appear at SIGCOMM next month, is in section 5 of this paper: http://www.cs.bu.edu/~goldbe/papers/sigRPKI_full.pdf This proposal seeks to address some of the issues as the suspenders proposal. We are looking for feedback from the working group about these ideas; based on the feedback we could put an Internet draft together for the next IETF (which I will be attending). Also happy to chat in person today. Sharon http://www.cs.bu.edu/~goldbe/ -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --001a11c37e5636900f04ff05c045 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All

We (at Boston University) have a proposal that prote= cts against the "Dutch Police Attack" where the RPKI is used for = IP prefix=C2=A0takedowns. The proposal, which will appear at SIGCOMM next m= onth, is in section 5 of this paper:

=C2=A0http://www.cs.bu.edu/~goldbe/papers/sigRPKI_full.pdf

This proposal seeks to address some of the issues as=C2= =A0the suspenders proposal.=C2=A0We are looking for feedback from the worki= ng group about these ideas; based on the feedback we could=C2=A0put an Inte= rnet draft together for the next IETF (which I will be attending). Also hap= py to chat in person today.=C2=A0

Sharon



--
Sha= ron Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe
--001a11c37e5636900f04ff05c045-- From nobody Fri Jul 25 09:00: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 0EF561B2999 for ; Fri, 25 Jul 2014 09:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 U8kC4C80vdxs for ; Fri, 25 Jul 2014 09:00:46 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F5071B295F for ; Fri, 25 Jul 2014 09:00:42 -0700 (PDT) Received: from BN1PR09MB108.namprd09.prod.outlook.com (10.255.199.24) by BN1PR09MB108.namprd09.prod.outlook.com (10.255.199.24) with Microsoft SMTP Server (TLS) id 15.0.990.7; Fri, 25 Jul 2014 16:00:41 +0000 Received: from BN1PR09MB108.namprd09.prod.outlook.com ([10.255.199.24]) by BN1PR09MB108.namprd09.prod.outlook.com ([10.255.199.24]) with mapi id 15.00.0990.007; Fri, 25 Jul 2014 16:00:41 +0000 From: "Montgomery, Douglas" To: "sidr@ietf.org" Thread-Topic: RPKI utility vs fragility Thread-Index: AQHPqCGVshEJZJyk2U6ZWItIFyLgKA== Date: Fri, 25 Jul 2014 16:00:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [129.6.222.1] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(99286002)(77982001)(54356999)(107886001)(2351001)(92566001)(83322001)(110136001)(50986999)(81542001)(105586002)(95666004)(2656002)(106356001)(106116001)(99396002)(36756003)(76482001)(80022001)(83506001)(64706001)(81342001)(21056001)(87936001)(4396001)(85852003)(66066001)(74502001)(85306003)(46102001)(74662001)(31966008)(229853001)(86362001)(101416001)(107046002)(20776003)(83072002)(92726001)(79102001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR09MB108; H:BN1PR09MB108.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: <1A57631D458C1B4188C3356257387716@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/2Og3RkneMzS40diS3kfGjXDjW_g Subject: [sidr] RPKI utility vs fragility 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, 25 Jul 2014 16:00:48 -0000 4oCmIFRvIGZvbGxvdyB1cCBvbiB0aGUgbGFzdCBjb3VwbGUgb2YgY29tbWVudHMgb2YgdGhlIHNl c3Npb24g4oCmIHRoZSBsYXJnZQ0KcmVzb3VyY2UgYnVuZGxlcyBhbHNvIGNvbnRhaW4gQVMgbnVt YmVycyDigKYgd2hpbGUgd2UgY2FuIGNsYWltIE5PVEZPVU5EDQptaWdodCBoZWxwIHJvdXRpbmcg cm9idXN0bmVzcyBpbiBSUEtJIG1hbGZ1bmN0aW9ucyDigKYgdGhlcmUgaXMgbm8gc3VjaCAzcmQN CnN0YXRlIGluIHBhdGggdmFsaWRhdGlvbi4gICBUaGUgcGF0aCBiZWNvbWVzIElOVkFMSUQgaW4g c3VjaCBjYXNlcy4NCg0KT2YgY291cnNlIHRoaXMgbWlnaHQgYmUgdGhlIGFuc3dlciB0byBKb2hu 4oCZcyBlYXJsaWVyIHF1ZXN0aW9uIG9mIHdoZW4gb25lDQp3b3VsZCBrZWVwIGEgcm91dGUgd2l0 aCBJTlZBTElEIHBhdGggYnV0IFZhbGlkL05PVEZPVU5EIG9yaWdpbi4gOikNCg0KSSBoYXZlIHBh cnRpY2lwYXRlZCBpbiBzZXZlcmFsIHB1YmxpYy9wcml2YXRlIHdvcmtpbmcgZ3JvdXBzIHdoZXJl DQpvcGVyYXRvcnMgb2Z0ZW4gZXhwcmVzcyBjb25jZXJuIGFib3V0IHRoZSBSUEtJIGZyYWdpbGl0 eSB2cyB1dGlsaXR5DQpxdWVzdGlvbi4gIEFueXRoaW5nIHdlIGNhbiBkbyB0byByZWR1Y2UgdGhl IGZhY3Qgb3IgRlVEIGFib3V0IHRoZQ0KZnJhZ2lsaXR5IGNvbmNlcm5zLCB3b3VsZCBoZWxwIGlu IHRoZXNlIGRpc2N1c3Npb25zLg0KDQpkb3VnbQ0K4oCUIA0KRG91ZyBNb250Z29tZXJ5LCBNZ3Ig SW50ZXJuZXQgJiBTY2FsYWJsZSBTeXN0ZW1zIFJlc2VhcmNoIE5JU1QvSVRML0FOVEQNCg0KDQoN Cg0K From nobody Fri Jul 25 09:21:03 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 750C51B29AB for ; Fri, 25 Jul 2014 09:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 1qoR7YR_HD9C for ; Fri, 25 Jul 2014 09:21:01 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31CC1B293C for ; Fri, 25 Jul 2014 09:21:00 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:59464 helo=dhcp-a77c.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XAiEs-000JvC-EK; Fri, 25 Jul 2014 12:20:58 -0400 Message-ID: <53D283E1.7010602@bbn.com> Date: Fri, 25 Jul 2014 12:20:49 -0400 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: Byron Ellacott References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> 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/oIuxxUwSY9cocDzk14UYAAjG_u0 Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 16:21:02 -0000 Byron, Thanks for providing the details of what APNIC does. Those are precisely the sort of checks I would hope for. I agree that if APNIC had IANA as its parent, then the issue you cited would be relevant, i.e., you can't know if IANA issued a new cert that removed an INR from your cert, which could result in invalidating the whole APNIC cert. Of course, today, this is not an issue, because all RIRs represent themselves as trust anchors. Steve From nobody Fri Jul 25 09:21:20 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 821BD1B29D0 for ; Fri, 25 Jul 2014 09:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 2HewufeQLCbH for ; Fri, 25 Jul 2014 09:21:18 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29D4A1B293C for ; Fri, 25 Jul 2014 09:21:18 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:59465 helo=dhcp-a77c.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XAiFB-000Jw6-AQ for sidr@ietf.org; Fri, 25 Jul 2014 12:21:17 -0400 Message-ID: <53D283FD.4070005@bbn.com> Date: Fri, 25 Jul 2014 12:21:17 -0400 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: <4C2B730F-3BED-40CF-BBD6-90F97B69E22D@tislabs.com> In-Reply-To: <4C2B730F-3BED-40CF-BBD6-90F97B69E22D@tislabs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/Pet-JTYeXehltAiTcqV-jWnznXQ Subject: Re: [sidr] comment on draft-ietf-sidr-bgpsec-protocol and draft-ietf-sidr-bgpsec-ops 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, 25 Jul 2014 16:21:19 -0000 Sandy, > Speaking as regular ol' member > > The bgpsec-protocol draft has the following text: > > Next, the BGPSEC speaker verifies that the origin AS is authorized to > advertise the prefix in question. To do this, consult the valid ROA > data to obtain a list of AS numbers that are associated with the > given IP address prefix in the update message. Then locate the last > (least recently added) AS number in the Secure_Path portion of the > BGPSEC_Path attribute. If the origin AS in the Secure_Path is not in > the set of AS numbers associated with the given prefix, then the > BGPSEC update message is 'Not Valid' and the validation algorithm > terminates. > > This text reprises the origin validation algorithm, without some of the more detailed pieces. > > I believe it would be better instead to refer to RFC6483 or RFC6811, rather than try to reprise the algorithm. Something like: "To do this, the speaker performs the algorithm of RFC6483/RFC6811. If the result is not Valid, then the BGP Update is 'Not Valid'." > > (This seems particularly prudent as we might be reconsidering the validation algorithm.) good point. we should use a reference rather than paraphrase. > This also brought to mind a point I'm curious about. > > Does a bgpsec speaking router have one configuration about the results of the bgpsec validation, or does it have two configurations, one for the results of the origin validation and a second for the results of the bgpsec validation? Are the two validation states separated? > > Should this be a point to be explained in the bgpsec-ops document? For origin validation, a router needs the binding between an AS and a set of prefixes. For BGPsec, it needs a binding between a public key and a set of ASes. So I see these as separate databases. Steve From nobody Fri Jul 25 10:19: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 383A71A035C for ; Fri, 25 Jul 2014 10:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 H-dL9iYvTcjR for ; Fri, 25 Jul 2014 10:19:36 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B9B21A03EB for ; Fri, 25 Jul 2014 10:19:36 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XAj9X-0006Sg-T1; Fri, 25 Jul 2014 19:19:33 +0200 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-164.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1XAj9X-0001QB-GU; Fri, 25 Jul 2014 19:19:31 +0200 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_EB245042-DFDA-43F9-8593-85F24D8A9656" From: Tim Bruijnzeels In-Reply-To: Date: Fri, 25 Jul 2014 13:19:27 -0400 Message-Id: <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> To: Byron Ellacott X-Mailer: Apple Mail (2.1510) 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 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] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719cbaa163fa37a3cee72cddd68c1c703bd Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/WEeq67LirfrZV6ZvsUiPokqa080 Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 17:19:38 -0000 --Apple-Mail=_EB245042-DFDA-43F9-8593-85F24D8A9656 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On Jul 25, 2014, at 9:09 AM, Byron Ellacott wrote: > Hi, >=20 > From: Stephen Kent > Date: Thursday, 24 July 2014 5:20 pm > To: Tim Bruijnzeels > Cc: "sidr@ietf.org" > Subject: Re: [sidr] I-D Action: = draft-ietf-sidr-rpki-validation-reconsidered-00.txt >=20 > Tim, >=20 > I think I was not clear in requesting clarification for your tests. I = didn't mean to=20 > ask what your RP code does. I was asking what your CA code does to = detect and reject > over-claiming, and what it will do under relaxed validation rules. I = ask because it > may be harder to perform such checks when there is an explicit intent = to issue a CA cert > that contains INRs not present in the parent cert. >=20 > I can't speak for RIPE, but at APNIC when a child requests a = certificate for us, we intersect it with our registry data, and our own = CA certificate. Same here. In addition: we include all resources explicitly in our certificate sign = requests from our *online* CA to the offline TA that we manage. This TA = will re-issue the TA certificate itself if needed, to include all = requested resources. I need to double check our code but I am pretty = certain that our online CA also shrinks its own understanding of which = resources it has as soon as it issues a request - i.e. it does not wait = to receive the shrunk certificate before we stop issuing these resources = to child certificates, but we *do* wait until we received the = certificate before we issue from *new* resources. Any modifications to = the TA certificate and online certificates are printed to the console = and the operator needs to confirm before the certificate is cut. We = require 3 out of 10 senior RIPE NCC staff to agree to the transaction = (they have a smart card and need to enter their passphrase). > What we cannot do is confirm that our own parent hasn't in the = meantime published a new certificate for us with some resource removed: = we can only detect that after it has happened, and it would be = preferable that detection leads to correction without an intermediate = step of total invalidation of a region. We will not intentionally break things obviously. And so-far our track = record has been flawless on this. But there are various reasons why, despite our best efforts, our online = CA may still be out of sync. A bug can be introduced in our code, or = there could be problem in publication and yesterday's TA certificate is = not updated but the CA certificate is, and if we would receive a = certificate from an upstream that is not managed by us then we have no = assurance. And as Byron points out we can only find this out after the = fact. We do regularly validate our repository, we don't actively monitor = the exact resources on our certificate, but we do monitor for sudden = drops in valid objects. By that time damage has been done though. The same problems apply on a smaller scale to any of our members that = run a non-hosted CA. We currently don't support this yet in our = production environment, but it's coming. As I said before I think that invalidating *ALL* resources in this case = is disproportionate. I would be much more comfortable with minimising = the impact. And still monitor for any overclaiming-warnings, and still = deal with them ASAP. > In a perfect world, of course, no process would ever lead to a parent = shrinking their child's certificate without adequate communication and = preparation, but if we were in a perfect world, a large part of the use = case for SIDR would be gone, because no router operator would ever make = an erroneous BGP announcement. +1 Tim >=20 > Byron >=20 --Apple-Mail=_EB245042-DFDA-43F9-8593-85F24D8A9656 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii bje@apnic.net> = wrote:

Hi,

From: Stephen Kent <kent@bbn.com>
Date: Thursday, 24 July 2014 = 5:20 pm
To: Tim Bruijnzeels <tim@ripe.net>
Cc: "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] I-D Action: = draft-ietf-sidr-rpki-validation-reconsidered-00.txt

Tim,

I think I was not clear in requesting clarification for your tests. I = didn't mean to
ask what your RP code does. I was asking what your CA code does to = detect and reject
over-claiming, and what it will do under relaxed validation rules. I ask = because it
may be harder to perform such checks when there is an explicit intent to = issue a CA cert
that contains INRs not present in the parent cert.

I can't speak for RIPE, but at APNIC when a child requests a = certificate for us, we intersect it with our registry data, and our own = CA certificate.

Same = here.

In addition: we include all resources = explicitly in our certificate sign requests from our *online* CA to the = offline TA that we manage. This TA will re-issue the TA certificate = itself if needed, to include all requested resources. I need to double = check our code but I am pretty certain that our online CA also shrinks = its own understanding of which resources it has as soon as it issues a = request - i.e. it does not wait to receive the shrunk certificate before = we stop issuing these resources to child certificates, but we *do* wait = until we received the certificate before we issue from *new* = resources. Any modifications to the TA certificate and online = certificates are printed to the console and the operator needs to = confirm before the certificate is cut. We require 3 out of 10 senior = RIPE NCC staff to agree to the transaction (they have a smart card and = need to enter their passphrase).

What we cannot do is confirm that our own = parent hasn't in the meantime published a new certificate for us with some resource removed: we can only detect that after it has = happened, and it would be preferable that detection leads to correction = without an intermediate step of total invalidation of a = region.

We will not = intentionally break things obviously. And so-far our track record has = been flawless on this.

But there are various = reasons why, despite our best efforts, our online CA may still = be out of sync. A bug can be introduced in our code, or there could be = problem in publication and yesterday's TA certificate is not updated but = the CA certificate is, and if we would receive a certificate from an = upstream that is not managed by us then we have no assurance. And as = Byron points out we can only find this out after the fact. We do = regularly validate our repository, we don't actively monitor the exact = resources on our certificate, but we do monitor for sudden drops in = valid objects. By that time damage has been done = though.

The same problems apply on a smaller = scale to any of our members that run a non-hosted CA. We currently don't = support this yet in our production environment, but it's = coming.

As I said before I think that = invalidating *ALL* resources in this case is disproportionate. I would = be much more comfortable with minimising the impact. And still monitor = for any overclaiming-warnings, and still deal with them = ASAP.


In a perfect world, of course, no process would ever lead to a = parent shrinking their child's certificate without adequate = communication and preparation, but if we were in a perfect world, a = large part of the use case for SIDR would be gone, because no router operator would ever make an erroneous BGP = announcement.

+1

Tim


  Byron


= --Apple-Mail=_EB245042-DFDA-43F9-8593-85F24D8A9656-- From nobody Fri Jul 25 11:04:51 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 31AD21A0418 for ; Fri, 25 Jul 2014 11:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_46=0.6, RP_MATCHES_RCVD=-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 9UwLm_X3eAPc for ; Fri, 25 Jul 2014 11:04:46 -0700 (PDT) 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 5DC491A040C for ; Fri, 25 Jul 2014 11:04:46 -0700 (PDT) Received: from PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 25 Jul 2014 11:04:44 -0700 Received: from PMBX112-W1-CA-2.pexch112.icann.org ([64.78.40.23]) by PMBX112-W1-CA-2.PEXCH112.ICANN.ORG ([64.78.40.23]) with mapi id 15.00.0847.030; Fri, 25 Jul 2014 11:04:44 -0700 From: Terry Manderson To: "Montgomery, Douglas" , "sidr@ietf.org" Thread-Topic: [sidr] RPKI utility vs fragility Thread-Index: AQHPqDLpkEANRJtjPkKIRVuTnuVXGQ== Date: Fri, 25 Jul 2014 18:04:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [66.207.202.68] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3489192282_50880139" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/XhYbFf4fBw5q1OTCwvX5-GZbvPI Subject: Re: [sidr] RPKI utility vs fragility 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, 25 Jul 2014 18:04:49 -0000 --B_3489192282_50880139 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Doug, Yes, it is true that BGPSEC only has two states (valid/not valid) and there is also a raft of hand-waving around the implementation of those states, eg the draft cites local policy, for whatever that is worth. Taking a step back, this might well go further than just the Valid/NotFound state of the originating AS. Thus the question regarding what happens to the route path validation that contains a set of RPKI objects (Step I, section 5 in bgpsec-protocol) along the path is raised. My presumption to date (perhaps horrendously wrong) is that it would not be terminal, eg NOT invalidate the routes of all affected parties in BGPSEC enabled islands. If it is the case that it will suffer the same fate related to the 3779 validation question Geoff poses, and I've held off commenting on bgpsec protocol for other-worldly reasons, maybe 2 states is not sufficient? Perhaps a 3rd 'Incomplete' state might be of use for both robustness and detectability? - since after all, a router cert will also invalidate in the case where a RIR/NIR/LIR "screws-up", to use another WG member term. The heretic in me (insert profuse apologies) would also take a further step (nay leap) back from the coal face and proffer the idea that while being stuck between a rock and a hard place the use of RPKI validation and thus the tight binding of RPKI and Path Validation is a step too far architecturally.=20 For many long years I've liked the mantra that the administrative function maintains an arms-length distance to the 'fit for use' of a prefix in routing terms. Case in point, we see this now being raised in such works as SLURM and Suspenders for those non-accidental situations people fear, and the agreement ARIN asks to implement for preservation which Wes also can't engage for near the same reasons. Perhaps the transfer of resources in RPKI is also bound there as well. So sitting there as an operator known to have influence over some infrastructure that helps in the (DNS) stability of the global (big "G") internet I find myself questioning the overall architecture, and wonder if I could actually sleep at night should I implement origination and path validation for that little piece of DNS infrastructure. Especially if some BGPSEC enabled transit provider has all route paths broken (mine and all 'clients') due to a 'higher tree' CA issue. I like the statement of valid resource entitlement, I like the statement about path validation. I'm not comfortable with rpki+bgpsec where they are so married, and divorce appears not to be an option. Ever. As such I, similarly, don't prescribe to the (flippant) statement from Geoff that a 'one RIR' RFC might be written in this context. :) (Although I have associates that will certainly line up for the author queue on that!) As I said, I live in world of double-edged swords. Each decision has a consequence here. And so far I do see a problem. I don't yet know if this validation shift opens up other attack vectors combined with, say, a MiTM of the BGPSEC update. I am much in favour of increasing the fact levels. Happy to contribute where needed. That said there are also many other problems. We have no option for key roll yet, we haven't come out the other side of the TAL and publication points draft, and I'm sure this list is incomplete. Terry On 26/07/2014 2:00 am, "Montgomery, Douglas" wrote: >=8A To follow up on the last couple of comments of the session =8A the large >resource bundles also contain AS numbers =8A while we can claim NOTFOUND >might help routing robustness in RPKI malfunctions =8A there is no such 3rd >state in path validation. The path becomes INVALID in such cases. > >Of course this might be the answer to John=B9s earlier question of when one >would keep a route with INVALID path but Valid/NOTFOUND origin. :) > >I have participated in several public/private working groups where >operators often express concern about the RPKI fragility vs utility >question. Anything we can do to reduce the fact or FUD about the >fragility concerns, would help in these discussions. > >dougm >=8B=20 >Doug Montgomery, Mgr Internet & Scalable Systems Research NIST/ITL/ANTD > > > > >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr --B_3489192282_50880139 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 AQkEMRYEFEYh02VHT2TPYdzz9thxx4X8wksIMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTE0MDcyNTE4MDQ0MVowDQYJKoZIhvcNAQEBBQAEggEAV43ehXjL fZkJDmpOioAQ6CUt2SakgqKQxvGfNMg5Awt64kCwalpg45UyN7y1uYjuKFqVNG0IIRA7rJqf oT/Zrb9t2mJuZqmXlvSoi6b2vjDFcQhFYGxDeYexG260ZSqAowguQQZxsmpnKskGVJG4dndN y477YOSHSOG8i6+WdABOQfViXuXqPEON03Ql0lsHdZxiLjbTrbOtxiHlmFclD0WF97kb0GU9 KkKfdFOkYScsiLw/JE7r07lS7dCykn/KHxxF2emYRiQwTvBY0qGQX0IuGM1xSGZW5TQI/7+T lK1/SmMnt8ZnzXVVy/VXeBIu+afhP5hiWfEcaq1MzxT6TA== --B_3489192282_50880139-- From nobody Fri Jul 25 11:46:01 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 3789A1A0334 for ; Fri, 25 Jul 2014 11:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, HTML_MESSAGE=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 XiLtnvJ9d90z for ; Fri, 25 Jul 2014 11:45:57 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C78B1A03E7 for ; Fri, 25 Jul 2014 11:45:56 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id z11so3739989lbi.31 for ; Fri, 25 Jul 2014 11:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Ik38HrlDREjHnEfLy5ik18IyU42RwCzWsPdi6Nu2DGY=; b=0dVLpePp/ZQuZY7byz0K59RRCZ2mmzkgXBzEoN/t6fTD+oHwRSSQOeD3Abr42b9SQi XDIHVisF0hQCOU1G5VoS/loqMT4AlpYpwS+8wCa2tpyPgf+G2z+sTfwdYXK9pEWQJcfL GVRFLUuyy5O9URqTPGLz6lsJ4i+TFZxK/Hn7nNJ8X4CdQsd6kId+pTt+Kv9D15ojg9fu Q29od3LlfQ/p4Kajn5aWkj1dpEsJ/MZ0rAfwxNInHF0WBvkMUldvp4twHrZ25wzE43Z0 FoQKl94JWRFJSTqrtO6W45gH/DM9h4eWUD4JaxkgA2gth+t2k/XEBLN0ELlCvCAnYbmo Jmbg== MIME-Version: 1.0 X-Received: by 10.112.124.204 with SMTP id mk12mr3787094lbb.101.1406313954731; Fri, 25 Jul 2014 11:45:54 -0700 (PDT) Received: by 10.112.171.72 with HTTP; Fri, 25 Jul 2014 11:45:54 -0700 (PDT) In-Reply-To: <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> Date: Fri, 25 Jul 2014 14:45:54 -0400 Message-ID: From: Carlos Martinez-Cagnazzo To: Tim Bruijnzeels Content-Type: multipart/alternative; boundary=047d7bfd01b2b6efa604ff08fb25 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/g0tk3bmq4SdxXVA_ZnbxwC3U9gw Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 18:45:59 -0000 --047d7bfd01b2b6efa604ff08fb25 Content-Type: text/plain; charset=UTF-8 It is weird that we even need to state here that we the five RIRs are not going to break things intentionally, but, yeah, LACNIC will not break things intentionally either. Engineering for resiliency is as much a necessity as engineering for security. If the damage caused by the failures of the solution itself becomes worse than the damage caused by the problem, well, no one is going to deploy the solution. regards, -Carlos On Fri, Jul 25, 2014 at 1:19 PM, Tim Bruijnzeels wrote: > Hi, > > On Jul 25, 2014, at 9:09 AM, Byron Ellacott wrote: > > Hi, > > From: Stephen Kent > Date: Thursday, 24 July 2014 5:20 pm > To: Tim Bruijnzeels > Cc: "sidr@ietf.org" > Subject: Re: [sidr] I-D Action: > draft-ietf-sidr-rpki-validation-reconsidered-00.txt > > Tim, > > I think I was not clear in requesting clarification for your tests. I > didn't mean to > ask what your RP code does. I was asking what your CA code does to detect > and reject > over-claiming, and what it will do under relaxed validation rules. I ask > because it > may be harder to perform such checks when there is an explicit intent to > issue a CA cert > that contains INRs not present in the parent cert. > > > I can't speak for RIPE, but at APNIC when a child requests a certificate > for us, we intersect it with our registry data, and our own CA certificate. > > > Same here. > > In addition: we include all resources explicitly in our certificate sign > requests from our *online* CA to the offline TA that we manage. This TA > will re-issue the TA certificate itself if needed, to include all requested > resources. I need to double check our code but I am pretty certain that our > online CA also shrinks its own understanding of which resources it has as > soon as it issues a request - i.e. it does not wait to receive the shrunk > certificate before we stop issuing these resources to child certificates, > but we *do* wait until we received the certificate before we issue from > *new* resources. Any modifications to the TA certificate and online > certificates are printed to the console and the operator needs to confirm > before the certificate is cut. We require 3 out of 10 senior RIPE NCC staff > to agree to the transaction (they have a smart card and need to enter their > passphrase). > > What we cannot do is confirm that our own parent hasn't in the meantime > published a new certificate for us with some resource removed: we can only > detect that after it has happened, and it would be preferable that > detection leads to correction without an intermediate step of total > invalidation of a region. > > > We will not intentionally break things obviously. And so-far our track > record has been flawless on this. > > But there are various reasons why, despite our best efforts, our online CA > may still be out of sync. A bug can be introduced in our code, or there > could be problem in publication and yesterday's TA certificate is not > updated but the CA certificate is, and if we would receive a certificate > from an upstream that is not managed by us then we have no assurance. And > as Byron points out we can only find this out after the fact. We do > regularly validate our repository, we don't actively monitor the exact > resources on our certificate, but we do monitor for sudden drops in valid > objects. By that time damage has been done though. > > The same problems apply on a smaller scale to any of our members that run > a non-hosted CA. We currently don't support this yet in our production > environment, but it's coming. > > As I said before I think that invalidating *ALL* resources in this case is > disproportionate. I would be much more comfortable with minimising the > impact. And still monitor for any overclaiming-warnings, and still deal > with them ASAP. > > > In a perfect world, of course, no process would ever lead to a parent > shrinking their child's certificate without adequate communication and > preparation, but if we were in a perfect world, a large part of the use > case for SIDR would be gone, because no router operator would ever make an > erroneous BGP announcement. > > > +1 > > Tim > > > Byron > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > -- -- ========================= Carlos M. Martinez-Cagnazzo h ttp://cagnazzo.me ========================= --047d7bfd01b2b6efa604ff08fb25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It is weird that we even need to state here that we the fi= ve RIRs are not going to break things intentionally, but, yeah, LACNIC will= not break things intentionally either.

Engineering for = resiliency is as much a necessity as engineering for security. If the damag= e caused by the failures of the solution itself becomes worse than the dama= ge caused by the problem, well, no one is going to deploy the solution.

regards,

-Carlos



On Fri, Jul 25, 2014 at 1:19 PM, Tim Bruijnzeels <tim@ripe.net= > wrote:
Hi,
=
On Jul 25, 2014, at 9:09 AM, Byron Ellacott &= lt;bje@apnic.net>= wrote:

Hi,

From: Stephen Kent <kent@bbn.com>
Date: Thursday, 24 July 2014 5:20 p= m
To: Tim Bruijnzeels <tim@ripe.net>
Cc: "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] I-D Action: dra= ft-ietf-sidr-rpki-validation-reconsidered-00.txt

Tim,

I think I was not clear in requesting clarification for your tests. I didn&= #39;t mean to
ask what your RP code does. I was asking what your CA code does to detect a= nd reject
over-claiming, and what it will do under relaxed validation rules. I ask be= cause it
may be harder to perform such checks when there is an explicit intent to is= sue a CA cert
that contains INRs not present in the parent cert.

I can't speak for RIPE, but at APNIC when a child requests a certi= ficate for us, we intersect it with our registry data, and our own CA certi= ficate.

Same here.

In addition: we include all resources explicitly in our= certificate sign requests from our *online* CA to the offline TA that we m= anage. This TA will re-issue the TA certificate itself if needed, to includ= e all requested resources. I need to double check our code but I am pretty = certain that our online CA also shrinks its own understanding of which reso= urces it has as soon as it issues a request - i.e. it does not wait to rece= ive the shrunk certificate before we stop issuing these resources to child = certificates, but we *do* wait until we received the certificate before we = issue from *new* resources.=C2=A0Any modifications to the TA certificate an= d online certificates are printed to the console and the operator needs to = confirm before the certificate is cut. We require 3 out of 10 senior RIPE N= CC staff to agree to the transaction (they have a smart card and need to en= ter their passphrase).

What we cannot do= is confirm that our own parent hasn't in the meantime published a new = certificate for us with some resource removed: we can only detect that after it has happen= ed, and it would be preferable that detection leads to correction without a= n intermediate step of total invalidation of a region.

We will not intentionally break things obviously.= And so-far our track record has been flawless on this.

But there are various reasons why,=C2=A0despite our best efforts,=C2= =A0our online CA may still be out of sync. A bug can be introduced in our c= ode, or there could be problem in publication and yesterday's TA certif= icate is not updated but the CA certificate is, and if we would receive a c= ertificate from an upstream that is not managed by us then we have no assur= ance. And as Byron points out we can only find this out after the fact.=C2= =A0We do regularly validate our repository, we don't actively monitor t= he exact resources on our certificate, but we do monitor for sudden drops i= n valid objects. By that time damage has been done though.

The same problems apply on a smaller scale to any of ou= r members that run a non-hosted CA. We currently don't support this yet= in our production environment, but it's coming.

As I said before I think that invalidating *ALL* resources in this cas= e is disproportionate. I would be much more comfortable with minimising the= impact. And still monitor for any overclaiming-warnings, and still deal wi= th them ASAP.


In a perfect world, of course, no process would ever lead to a parent = shrinking their child's certificate without adequate communication and = preparation, but if we were in a perfect world, a large part of the use cas= e for SIDR would be gone, because no router operator would ever make an erroneous BGP announcement.
=

+1

Tim


=C2=A0 Byron



____________________________________= ___________
sidr mailing list
sidr@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sidr




--
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Carlos M. Martinez-Cagnazzo
http://cagnazzo.me
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
--047d7bfd01b2b6efa604ff08fb25-- From nobody Sun Jul 27 06:47: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 C60AD1A01F2 for ; Sun, 27 Jul 2014 06:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-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 d_hJi3MSFohd for ; Sun, 27 Jul 2014 06:47:24 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 662731A01F1 for ; Sun, 27 Jul 2014 06:47:24 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 0528828B0052; Sun, 27 Jul 2014 09:47:24 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 5BBD41F8032; Sun, 27 Jul 2014 09:47:23 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_F89466E1-F005-4D5E-8010-07BF17AD1E41"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Sun, 27 Jul 2014 09:47:27 -0400 Message-Id: To: IETF SIDR 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/uJwA-rSo5uc7eh1vAEPTy63dqkA Cc: "sidr-chairs@tools.ietf.org chairs" , Sandra Murphy Subject: [sidr] civility in wg interactions 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, 27 Jul 2014 13:47:25 -0000 --Apple-Mail=_F89466E1-F005-4D5E-8010-07BF17AD1E41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Our meeting on Friday saw a couple of cases of inappropriate behavior, = where remarks were made that were of a personal nature or that had no = bearing on the issue under discussion. We are presently considering an important issue with potential for = significant impact on the work. That it even more reason than usual to = try to stick to objectivity and to avoid ad hominem remarks. Derogatory remarks directed at persons or organizations do nothing to = progress our understanding or consensus and are not fair to the target. Please, everyone, do try to remember civility and objectivity in the = discussions we are having. --Sandy, speaking as one of the co-chairs --Apple-Mail=_F89466E1-F005-4D5E-8010-07BF17AD1E41 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 iQIcBAEBCgAGBQJT1QLvAAoJEHplpQeet0IZDFcQALhJqcJvuZb1WNBTKTjrPVpE vFOEKytYlkIqmCA50I3xNC0UTBfSiHAz/4C7/V+VObqUMaEDGXZjZx+UFo13ZaU8 gt5fJSNa8uFhWbP3ICHnlN7K2LSSzW5o7dxPrijDY1sQRTdZAjRM2VIIXU4bVook D1xR7B28YBtIK7428F/jgtGCafTyfmc45RPleOl9yX7lXhQa+AiJkwxyel0eaB2p 3Zo5smIaSMHqqEw57ZM3oFPxp98LJ9xJq8e7BA+1XNgzEDLk0RcU5aRg5Dngl1Ws jzL9A0GIS7NjkI8t/3GmV0zGL6tvR3YXa7StK72XBjRTL/7DGiVIE4hOcimaLHJ5 ZFBwsABSZvBPQzig7g78j+SDtCBfTl4t6Xzl+E13c+bUEuZ2VXGxaw0Dg0Aft5YX cIuTgDhlMBRFBhiErk84+vpqUtcgYwxz/FbQPiWygKXZEQWpA1ntlHxLknWfx+fR IczLC234Q629QvERlrnBS80t8LeVNwznUvUCL5gKxQBym22BAMHMhxUMI1zXtjGy Xj9K7hEWMYdt92nqPAPmJULGNqXb9F91x5+kZgzUCys0QNxkRa1xIWqIXX98vfhm CBaS7RkuMHvhKVDXrPnpFLU7j28RuNQUJC5aNXopLfv7261/dalKQQJvV5Dh3YPS Ch2kpLe1qqxBPE3aeteR =7vxo -----END PGP SIGNATURE----- --Apple-Mail=_F89466E1-F005-4D5E-8010-07BF17AD1E41-- From nobody Sun Jul 27 09:40:51 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 D291B1A0A99 for ; Sun, 27 Jul 2014 09:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 y8Cfa6ZNPERp for ; Sun, 27 Jul 2014 09:40:45 -0700 (PDT) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F8D31A0A96 for ; Sun, 27 Jul 2014 09:40:45 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id w61so6242056wes.37 for ; Sun, 27 Jul 2014 09:40:44 -0700 (PDT) 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=nab70OoBksZ8jThkQvbfkhAyyMsFJeItXOiLKHCFfLk=; b=OJmNxXiejDT2o5AF9bQ4yQmp+Fm7T1/ahesUbKb2yVonz6tfBCyaFjLPaZa9AVtIA7 YW4LhgpwQa2Z0UKLyV0DtuiKelV4pDnma9x8autwkoaNfBLrwUOky06aeIUT/KJLj7aS ulJ3nG6AZGsoeXxSQyycoFj2GvmkOki53h5wQjCw/iLnK1Mc47pmkpD9/fKoV1jv8RJG T/0v10QONwzdQK/8RGaZyOgxEsW1PSNvPFJlmVkXpvGH63EA82oTZpCXYu0Hcr1hxH5O Y/NZjSeAvKnS5QS7U0/WCQpvZQ6Mi03E8wvVV70D98iTCTIlQrILir5VvlPDvyA1GFIB B55A== X-Gm-Message-State: ALoCoQlgoGXAmfHoZu8/QUZPNRWB767XTMU7FBP13LZGFJg0BrNzBF/ZHilsz1hPg7DKfxXgme4i MIME-Version: 1.0 X-Received: by 10.180.73.139 with SMTP id l11mr22107998wiv.30.1406479243992; Sun, 27 Jul 2014 09:40:43 -0700 (PDT) Received: by 10.194.248.233 with HTTP; Sun, 27 Jul 2014 09:40:43 -0700 (PDT) In-Reply-To: References: Date: Sun, 27 Jul 2014 12:40:43 -0400 Message-ID: From: Warren Kumari To: Sandra Murphy Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/djS-5Gva-EAt2SSmo6BD_UmMtiU Cc: "sidr-chairs@tools.ietf.org chairs" , IETF SIDR Subject: Re: [sidr] civility in wg interactions 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, 27 Jul 2014 16:40:48 -0000 On Sun, Jul 27, 2014 at 9:47 AM, Sandra Murphy wrote: > Our meeting on Friday saw a couple of cases of inappropriate behavior, where remarks were made that were of a personal nature or that had no bearing on the issue under discussion. > > We are presently considering an important issue with potential for significant impact on the work. That it even more reason than usual to try to stick to objectivity and to avoid ad hominem remarks. > > Derogatory remarks directed at persons or organizations do nothing to progress our understanding or consensus and are not fair to the target. Hear, hear... They also don't help the person who is making the remark. Evaluation of technical arguments *should* be based purely upon the technical merits, but *who* is making the argument, their reputation, and *how* the argument is made influences the listener - coming off like an ass simply makes the listener think that your argument is not strong enough to stand on it's own merit, and pushes them to give more weight to the other side... Friday's behavior made me lose some of the respect that I have had for some of the SIDR participants. W > > Please, everyone, do try to remember civility and objectivity in the discussions we are having. > > --Sandy, speaking as one of the co-chairs > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From nobody Sun Jul 27 18:16:14 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 B6E691B27D5; Sun, 27 Jul 2014 18:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 l5lu69aqbWwS; Sun, 27 Jul 2014 18:16:08 -0700 (PDT) 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 BC2D61B27D3; Sun, 27 Jul 2014 18:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6517; q=dns/txt; s=iport; t=1406510168; x=1407719768; h=from:to:subject:date:message-id:mime-version; bh=gQCMnGHIXMkSQwdcEEEej+KlQ5KHY8BfLlaeSVhfVFg=; b=iQyoypvE2TyFhMqQu7D7VZqww5TLhcrWAEsth1megNB0tpFp9FnIhpbg jOs4VOG/Gu5s58PulVRetmkeEWNLF+3MftR881S0IDE5EeDu1BFCZmiNo Fr8nZCjOllh0xvrO9POjlmFSFxrvZOIhyH1IhdoLCSPg1K72K78sYwbH0 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAP2j1VOtJV2Y/2dsb2JhbABZgkdHUlvTIwGBERZ3hAUBBC1FGQEqViYBBAEaE4gnvRUXjxuDZ4EbBbAYg0mCMQ X-IronPort-AV: E=Sophos;i="5.01,745,1400025600"; d="scan'208,217";a="343238857" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 28 Jul 2014 01:16:07 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6S1G671017656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jul 2014 01:16:06 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Sun, 27 Jul 2014 20:16:06 -0500 From: "Jakob Heitz (jheitz)" To: IETF SIDR , "Sriram, Kotikalapudi" , "idr@ietf.org" , "grow@ietf.org" Thread-Topic: draft-sriram-route-leak-protection-00 Thread-Index: Ac+p/vnHoWsppmC3R8uDlV6ghI7lHQ== Date: Mon, 28 Jul 2014 01:16:06 +0000 Message-ID: <075DE01702BBC249BE1357EFD20DCFE50CF04B96@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.66.206] Content-Type: multipart/alternative; boundary="_000_075DE01702BBC249BE1357EFD20DCFE50CF04B96xmbalnx02ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/0IEtqxtDyhJc30oW_m-q8Attsq8 Subject: [sidr] draft-sriram-route-leak-protection-00 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, 28 Jul 2014 01:16:09 -0000 --_000_075DE01702BBC249BE1357EFD20DCFE50CF04B96xmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In GROW, at the mike, I proposed another solution: Add a new attribute that means "this route may be advertised up". This attribute must be signed by the originator of the route. Add a second attribute that means "The first attribute was added" This attribute must be included in the BGPSEC signature. If an AS asserts that the route can no longer be advertised up, it simply removes the first attribute along with its signature. Since the first attribute must be signed by the originator, no one else can= add it back. Now, an AS that considers itself a provider of the advertised route to the = peer from which it received the advertisement can filter on the presence of= the second attribute and the lack of the first to prevent the leak. The advantage of this solution is that it will not expose the customer-prov= ider relationship to any customers. --Jakob --_000_075DE01702BBC249BE1357EFD20DCFE50CF04B96xmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In GROW, at the mike, I proposed another s= olution:

 

Add a new attribute that means “this= route may be advertised up”.

This attribute must be signed by the origi= nator of the route.

 

Add a second attribute that means “T= he first attribute was added”

This attribute must be included in the BGP= SEC signature.

 

If an AS asserts that the route can no lon= ger be advertised up,

it simply removes the first attribute alon= g with its signature.

 

Since the first attribute must be signed b= y the originator, no one else can add it back.

 

Now, an AS that considers itself a provide= r of the advertised route to the peer from which it received the advertisem= ent can filter on the presence of the second attribute and the lack of the first to prevent the leak.

 

The advantage of this solution is that it = will not expose the customer-provider relationship to any customers.

 

--Jakob

 

--_000_075DE01702BBC249BE1357EFD20DCFE50CF04B96xmbalnx02ciscoc_-- From nobody Tue Jul 29 10:10:03 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 6E9601B29F5; Tue, 29 Jul 2014 10:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 ZuZBBe0zUIs4; Tue, 29 Jul 2014 10:09:53 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C69D61B2997; Tue, 29 Jul 2014 10:09:52 -0700 (PDT) Received: from BN1PR09MB0274.namprd09.prod.outlook.com (25.160.80.23) by BN1PR09MB0275.namprd09.prod.outlook.com (25.160.80.24) with Microsoft SMTP Server (TLS) id 15.0.995.14; Tue, 29 Jul 2014 17:09:51 +0000 Received: from BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) by BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) with mapi id 15.00.0995.014; Tue, 29 Jul 2014 17:09:51 +0000 From: "Sriram, Kotikalapudi" To: "Jakob Heitz (jheitz)" , IETF SIDR , "idr@ietf.org" , "grow@ietf.org" Thread-Topic: draft-sriram-route-leak-protection-00 Thread-Index: Ac+p/vnHoWsppmC3R8uDlV6ghI7lHQBSoyTQ Date: Tue, 29 Jul 2014 17:09:50 +0000 Message-ID: <671badb13318451098ddea1430afbc2f@BN1PR09MB0274.namprd09.prod.outlook.com> References: <075DE01702BBC249BE1357EFD20DCFE50CF04B96@xmb-aln-x02.cisco.com> In-Reply-To: <075DE01702BBC249BE1357EFD20DCFE50CF04B96@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.100] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0287BBA78D x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(105586002)(99396002)(92566001)(2656002)(561944003)(87936001)(101416001)(107046002)(77096002)(50986999)(85306003)(54356999)(106356001)(99286002)(66066001)(33646002)(2201001)(21056001)(74316001)(107886001)(76176999)(95666004)(76482001)(46102001)(77982001)(4396001)(74502001)(81342001)(86362001)(83072002)(81542001)(31966008)(76576001)(85852003)(80022001)(83322001)(64706001)(74662001)(20776003)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR09MB0275; H:BN1PR09MB0274.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/FNECV3dRcR2fWUP8sYRgWql6hE0 Subject: Re: [sidr] draft-sriram-route-leak-protection-00 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, 29 Jul 2014 17:09:58 -0000 Jacob, Please see comment inline below. Sriram =20 >Add a new attribute that means "this route may be advertised up". >This attribute must be signed by the originator of the route. >Add a second attribute that means "The first attribute was added". >This attribute must be included in the BGPSEC signature. >If an AS asserts that the route can no longer be advertised up,=20 > It simply removes the first attribute along with its signature. >Since the first attribute must be signed by the originator, no one else ca= n add it back. The assertion "no one else can add it back" is not true. In your proposal, as I understand it,=20 only the origin AS is signing the first attribute to its neighbor (i.e. sec= ond AS). Therefore, after an AS along the path removes the first attribute=20 along with the origin's signature, a subsequent adversary AS can always=20 cut and paste that thing back.=20 Please let me know if I misunderstood something. (Note: We carefully avoided this kind of cut and paste problem in Path Signing in BGPSEC by requiring each AS to sign to the next AS in the A= S path.) Sriram >Now, an AS that considers itself a provider of the advertised route to the= peer from which it received the advertisement can filter on the presence o= f the second attribute and the lack of the first to prevent the leak. >The advantage of this solution is that it will not expose the customer-pro= vider relationship to any customers. >--Jakob From nobody Tue Jul 29 10:46:39 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 9F1201B29EA; Tue, 29 Jul 2014 10:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 EIbr-xr64YiK; Tue, 29 Jul 2014 10:46:32 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA2D1B295D; Tue, 29 Jul 2014 10:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2007; q=dns/txt; s=iport; t=1406655992; x=1407865592; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=exztzFjF0ZMvazLLbwO+8EHb3n+gmhoPFOfe32jt57o=; b=hmJPBpDiozPsqyl7KbQjcT4ooRDoMeMZFtrCdKxwpA4rdJjn50EwUs6m RwyVdaRdCHrSDRJ05IcBD4p1EyzRKtaHU3dcZ94mwTcIImlha6fOY1YDm y1Kt3cmIuf0r9UYd3lF3TatjqnD5MaAd4s9SrRR1IrE0KR6rNAQuymAQa o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFALrc11OtJV2Z/2dsb2JhbABZgw6BKQTTOAGBEBZ3hAMBAQEEOjgTBAIBCBEEAQELFAkHMhQJCAEBBAESCBOIJ78tF48bOAaDKYEbAQSwHYNJbIFF X-IronPort-AV: E=Sophos;i="5.01,758,1400025600"; d="scan'208";a="64924286" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP; 29 Jul 2014 17:46:29 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6THkT9q025010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jul 2014 17:46:29 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 29 Jul 2014 12:45:44 -0500 From: "Jakob Heitz (jheitz)" To: "Sriram, Kotikalapudi" , IETF SIDR , "idr@ietf.org" , "grow@ietf.org" Thread-Topic: draft-sriram-route-leak-protection-00 Thread-Index: Ac+p/vnHoWsppmC3R8uDlV6ghI7lHQBSoyTQAALDSrA= Date: Tue, 29 Jul 2014 17:45:43 +0000 Message-ID: <075DE01702BBC249BE1357EFD20DCFE50CF05FC4@xmb-aln-x02.cisco.com> References: <075DE01702BBC249BE1357EFD20DCFE50CF04B96@xmb-aln-x02.cisco.com> <671badb13318451098ddea1430afbc2f@BN1PR09MB0274.namprd09.prod.outlook.com> In-Reply-To: <671badb13318451098ddea1430afbc2f@BN1PR09MB0274.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.165.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/o_xoZMvj0B14mLOKZz5RlCyFRkQ Subject: Re: [sidr] draft-sriram-route-leak-protection-00 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, 29 Jul 2014 17:46:34 -0000 ok. How about: Each AS signs it as having passed it along, just like the BGPSEC. Then after one AS removes it, a subsequent AS cannot add it back. --Jakob > -----Original Message----- > From: Sriram, Kotikalapudi [mailto:kotikalapudi.sriram@nist.gov] > Sent: Tuesday, July 29, 2014 10:10 AM > To: Jakob Heitz (jheitz); IETF SIDR; idr@ietf.org; grow@ietf.org > Subject: RE: draft-sriram-route-leak-protection-00 >=20 > Jacob, >=20 > Please see comment inline below. >=20 > Sriram >=20 > >Add a new attribute that means "this route may be advertised up". > >This attribute must be signed by the originator of the route. >=20 > >Add a second attribute that means "The first attribute was added". > >This attribute must be included in the BGPSEC signature. >=20 > >If an AS asserts that the route can no longer be advertised up, It > >simply removes the first attribute along with its signature. >=20 > >Since the first attribute must be signed by the originator, no one > else can add it back. >=20 > The assertion "no one else can add it back" is not true. > In your proposal, as I understand it, > only the origin AS is signing the first attribute to its neighbor > (i.e. second AS). > Therefore, after an AS along the path removes the first attribute > along with the origin's signature, a subsequent adversary AS can > always cut and paste that thing back. > Please let me know if I misunderstood something. > (Note: We carefully avoided this kind of cut and paste problem in > Path Signing in BGPSEC by requiring each AS to sign to the next AS > in the AS path.) >=20 > Sriram >=20 > >Now, an AS that considers itself a provider of the advertised route > to the peer from which it received the advertisement can filter on > the presence of the second attribute and the lack of the first to > prevent the leak. >=20 > >The advantage of this solution is that it will not expose the > customer-provider relationship to any customers. >=20 > >--Jakob From nobody Tue Jul 29 12:31:05 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 1D7501A066C; Tue, 29 Jul 2014 12:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 6SmBHsU_AQfg; Tue, 29 Jul 2014 12:31:00 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 713171A0657; Tue, 29 Jul 2014 12:31:00 -0700 (PDT) Received: from BN1PR09MB0274.namprd09.prod.outlook.com (25.160.80.23) by BN1PR09MB0275.namprd09.prod.outlook.com (25.160.80.24) with Microsoft SMTP Server (TLS) id 15.0.995.14; Tue, 29 Jul 2014 19:30:54 +0000 Received: from BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) by BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) with mapi id 15.00.0995.014; Tue, 29 Jul 2014 19:30:54 +0000 From: "Sriram, Kotikalapudi" To: "Jakob Heitz (jheitz)" , IETF SIDR , "idr@ietf.org" , "grow@ietf.org" Thread-Topic: draft-sriram-route-leak-protection-00 Thread-Index: Ac+p/vnHoWsppmC3R8uDlV6ghI7lHQBSoyTQAALDSrAAAxfY4A== Date: Tue, 29 Jul 2014 19:30:53 +0000 Message-ID: <9d9616c29f694286b9e0673f5959e715@BN1PR09MB0274.namprd09.prod.outlook.com> References: <075DE01702BBC249BE1357EFD20DCFE50CF04B96@xmb-aln-x02.cisco.com> <671badb13318451098ddea1430afbc2f@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF05FC4@xmb-aln-x02.cisco.com> In-Reply-To: <075DE01702BBC249BE1357EFD20DCFE50CF05FC4@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.100] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0287BBA78D x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(74502001)(4396001)(81342001)(86362001)(77982001)(74662001)(20776003)(85852003)(76576001)(83072002)(81542001)(31966008)(64706001)(83322001)(80022001)(99396002)(87936001)(92566001)(2656002)(107046002)(101416001)(105586002)(2201001)(74316001)(66066001)(33646002)(21056001)(76176999)(95666004)(46102001)(76482001)(107886001)(79102001)(85306003)(50986999)(77096002)(106356001)(54356999)(99286002)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR09MB0275; H:BN1PR09MB0274.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/P-PrHd08jXKdQbj3r9gEIadbByA Subject: Re: [sidr] draft-sriram-route-leak-protection-00 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, 29 Jul 2014 19:31:02 -0000 >ok. How about: >Each AS signs it as having passed it along, just like the BGPSEC. >Then after one AS removes it, a subsequent AS cannot add it back. Jacob, Sorry, but that still doesn't work. The signature validation would break.=20 Say, the update received at AS3 is P [AS2 AS1], where AS1 is the origin. Let us say, AS2 removed the signed attribute (that you proposed), and sent the update to AS3. Then AS3 will not be able to validate AS1's signature,=20 because AS1's sig covered the removed attribute. Sriram >--Jakob From nobody Tue Jul 29 12:38: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 57A911A0ABD; Tue, 29 Jul 2014 12:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 SVtO-jiy04fr; Tue, 29 Jul 2014 12:38:49 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D72A1A0AA1; Tue, 29 Jul 2014 12:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1246; q=dns/txt; s=iport; t=1406662730; x=1407872330; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=98J3lnhYg27fxpvMnbW/8uB6srRIQhIW/c1OGJv63n8=; b=fThQmtNPzNBzFzdks8uLCHozJNXAhOvELDRtZbH9Nmf2icBbgbx8LQzC TWOhljNTmzCHhbqnXxn7UsSrSeCFP6qImSq6ZGrqkoISwsyOEAWxEhhyf 3dz5gBDKR7/kEOa09UgacFxv7XJPgknbq13pHbxhsSQlHH11u622XPY3U o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAHP311OtJV2Q/2dsb2JhbABagw6BKQTTOgGBERZ3hAMBAQEEOksEAgEIEQQBAQsUCQcyFAkIAQEEARIIiDq/RBePGzgGgymBGwEEsB2DSWyBBSQc X-IronPort-AV: E=Sophos;i="5.01,759,1400025600"; d="scan'208";a="64957931" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP; 29 Jul 2014 19:38:49 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6TJcmuh027897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jul 2014 19:38:48 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 29 Jul 2014 14:38:48 -0500 From: "Jakob Heitz (jheitz)" To: "Sriram, Kotikalapudi" , IETF SIDR , "idr@ietf.org" , "grow@ietf.org" Thread-Topic: draft-sriram-route-leak-protection-00 Thread-Index: Ac+p/vnHoWsppmC3R8uDlV6ghI7lHQBSoyTQAALDSrAAAxfY4AAAxGpg Date: Tue, 29 Jul 2014 19:38:47 +0000 Message-ID: <075DE01702BBC249BE1357EFD20DCFE50CF060CA@xmb-aln-x02.cisco.com> References: <075DE01702BBC249BE1357EFD20DCFE50CF04B96@xmb-aln-x02.cisco.com> <671badb13318451098ddea1430afbc2f@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF05FC4@xmb-aln-x02.cisco.com> <9d9616c29f694286b9e0673f5959e715@BN1PR09MB0274.namprd09.prod.outlook.com> In-Reply-To: <9d9616c29f694286b9e0673f5959e715@BN1PR09MB0274.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.165.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/_mo10AYiehhWaa2Fb_Gxygs9Xkg Subject: Re: [sidr] draft-sriram-route-leak-protection-00 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, 29 Jul 2014 19:38:50 -0000 Sriram, I'm not proposing to include it in the BGPSEC signature, It would be a separate signature. Once AS2 removes it, it removes the attribute and its signature chain. The BGPSEC attribute and its signature chain is a different signature chain= and not removed. The second attribute I proposed will be covered by the BGPSEC signature cha= in and not removed. --Jakob > -----Original Message----- > From: Sriram, Kotikalapudi [mailto:kotikalapudi.sriram@nist.gov] > Sent: Tuesday, July 29, 2014 12:31 PM > To: Jakob Heitz (jheitz); IETF SIDR; idr@ietf.org; grow@ietf.org > Subject: RE: draft-sriram-route-leak-protection-00 >=20 > >ok. How about: > >Each AS signs it as having passed it along, just like the BGPSEC. > >Then after one AS removes it, a subsequent AS cannot add it back. >=20 > Jacob, >=20 > Sorry, but that still doesn't work. The signature validation would > break. > Say, the update received at AS3 is P [AS2 AS1], where AS1 is the > origin. > Let us say, AS2 removed the signed attribute (that you proposed), > and sent the update to AS3. > Then AS3 will not be able to validate AS1's signature, because AS1's > sig covered the removed attribute. >=20 > Sriram >=20 > >--Jakob >=20 From nobody Tue Jul 29 13:38: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 EF3DB1A0A9D; Tue, 29 Jul 2014 13:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6mSE1rzsjuz; Tue, 29 Jul 2014 13:38:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCFC1A0AF0; Tue, 29 Jul 2014 13:38:11 -0700 (PDT) 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.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140729203811.26582.62122.idtracker@ietfa.amsl.com> Date: Tue, 29 Jul 2014 13:38:11 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/g03ZM0EDCneL0_arT1RNjXTF4aY Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-as-migration-02.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: Tue, 29 Jul 2014 20:38:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : BGPSec Considerations for AS Migration Authors : Wesley George Sandy Murphy Filename : draft-ietf-sidr-as-migration-02.txt Pages : 14 Date : 2014-07-29 Abstract: This draft discusses considerations and methods for supporting and securing a common method for AS-Migration within the BGPSec protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-as-migration/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-as-migration-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-as-migration-02 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 Tue Jul 29 13:51: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 B59CD1A0B02; Tue, 29 Jul 2014 13:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 C9iKlL7IZ25n; Tue, 29 Jul 2014 13:51:48 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19A111A0AE0; Tue, 29 Jul 2014 13:51:47 -0700 (PDT) Received: from BN1PR09MB0274.namprd09.prod.outlook.com (25.160.80.23) by BN1PR09MB0273.namprd09.prod.outlook.com (25.160.80.22) with Microsoft SMTP Server (TLS) id 15.0.995.14; Tue, 29 Jul 2014 20:51:46 +0000 Received: from BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) by BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) with mapi id 15.00.0995.014; Tue, 29 Jul 2014 20:51:46 +0000 From: "Sriram, Kotikalapudi" To: "Jakob Heitz (jheitz)" , IETF SIDR , "idr@ietf.org" , "grow@ietf.org" Thread-Topic: draft-sriram-route-leak-protection-00 Thread-Index: Ac+p/vnHoWsppmC3R8uDlV6ghI7lHQBSoyTQAALDSrAAAxfY4AAAxGpgAAEXotA= Date: Tue, 29 Jul 2014 20:51:45 +0000 Message-ID: <0608667c14f1402caa404e73f940e416@BN1PR09MB0274.namprd09.prod.outlook.com> References: <075DE01702BBC249BE1357EFD20DCFE50CF04B96@xmb-aln-x02.cisco.com> <671badb13318451098ddea1430afbc2f@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF05FC4@xmb-aln-x02.cisco.com> <9d9616c29f694286b9e0673f5959e715@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF060CA@xmb-aln-x02.cisco.com> In-Reply-To: <075DE01702BBC249BE1357EFD20DCFE50CF060CA@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.100] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0287BBA78D x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(51704005)(189002)(4396001)(79102001)(76576001)(74662001)(107046002)(107886001)(31966008)(21056001)(77982001)(86362001)(87936001)(93886003)(101416001)(2656002)(74502001)(74316001)(95666004)(85306003)(99396002)(77096002)(80022001)(92566001)(83072002)(2201001)(76176999)(54356999)(85852003)(33646002)(81542001)(81342001)(76482001)(105586002)(46102001)(64706001)(99286002)(50986999)(20776003)(66066001)(106356001)(83322001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR09MB0273; H:BN1PR09MB0274.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/GAM8MrIq2AHytQSQp8CA5RRvgOc Subject: Re: [sidr] draft-sriram-route-leak-protection-00 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, 29 Jul 2014 20:51:50 -0000 >I'm not proposing to include it in the BGPSEC signature, It would be a sep= arate signature. >Once AS2 removes it, it removes the attribute and its signature chain. >The BGPSEC attribute and its signature chain is a different signature chai= n and not removed. > >The second attribute I proposed will be covered by the BGPSEC signature ch= ain and not removed. > Jakob, OK, you are proposing a separate signature chain besides the BGPSEC sig cha= in. But any signature chain must continue end-to-end across the whole AS path. Because, if a signature chain is allowed to be removed at any point in the = path, then it becomes vulnerable to cut and paste attack. Again, consider an update received at AS5 as P [AS4 AS3 AS2 AS1], where AS1= is origin. Let us say, AS2 removed your proposed first attribute and the associated si= gnature, and forwarded the update to its customer AS3.=20 Now AS3 forwards the update to its customer AS4. AS4 can somehow learn that AS1 sent the first attribute to AS2 and signed i= t, and it can somehow get that whole 'goop' (i.e. the attribute and the sig of= AS1). Then AS4 can add back the 'goop', and forward the update to its *upstream = provider* AS5, and AS5 would be fooled and oblivious of the leak. (Note: Again think of the reason why partial path signatures are disallowed= in BGPSEC. The same principles should apply here too with any other proposed sig chain= .) Sriram >--Jakob From nobody Tue Jul 29 14:07: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 C09771A00EB; Tue, 29 Jul 2014 14:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 BAOLZbkBSVgx; Tue, 29 Jul 2014 14:07:01 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70D111B28F7; Tue, 29 Jul 2014 14:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2034; q=dns/txt; s=iport; t=1406668016; x=1407877616; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=sH7BxNedUUQajFnsxAhw0irGL+IHeegsb72UP6aOwr4=; b=VUCgXDK+80ReqHsLCfIlXMWnWvFdGu4PjyFwkmWUCeY/ClBeUEzik5Ad zwyOXv2FdrzQ8cVWBzmFbee+6I0WKFcZwsBgwhV1tYvpETxuKQjKdejrj a5thYDmN6zTWjHpeumpW4SCxW7HFCdGDcmwsDV9ZLZVf868Pn+5A0O9u2 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFANQL2FOtJV2d/2dsb2JhbABagw6BKQTTQgGBEhZ3hAMBAQEEOksEAgEIEQQBAQsUCQcyFAkIAgQBEgiIOr9OF48bOAaDKYEbAQSwHYNJbIFF X-IronPort-AV: E=Sophos;i="5.01,759,1400025600"; d="scan'208";a="343707437" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 29 Jul 2014 21:06:56 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s6TL6tVZ030189 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jul 2014 21:06:55 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Tue, 29 Jul 2014 16:06:55 -0500 From: "Jakob Heitz (jheitz)" To: "Sriram, Kotikalapudi" , IETF SIDR , "idr@ietf.org" , "grow@ietf.org" Thread-Topic: draft-sriram-route-leak-protection-00 Thread-Index: Ac+p/vnHoWsppmC3R8uDlV6ghI7lHQBSoyTQAALDSrAAAxfY4AAAxGpgAAEXotAAAfYogA== Date: Tue, 29 Jul 2014 21:06:55 +0000 Message-ID: <075DE01702BBC249BE1357EFD20DCFE50CF061BE@xmb-aln-x02.cisco.com> References: <075DE01702BBC249BE1357EFD20DCFE50CF04B96@xmb-aln-x02.cisco.com> <671badb13318451098ddea1430afbc2f@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF05FC4@xmb-aln-x02.cisco.com> <9d9616c29f694286b9e0673f5959e715@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF060CA@xmb-aln-x02.cisco.com> <0608667c14f1402caa404e73f940e416@BN1PR09MB0274.namprd09.prod.outlook.com> In-Reply-To: <0608667c14f1402caa404e73f940e416@BN1PR09MB0274.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.22.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/9gMrDiXt4f8s70exCZMBD4Q6Zgs Subject: Re: [sidr] draft-sriram-route-leak-protection-00 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, 29 Jul 2014 21:07:03 -0000 No it wouldn't. For AS4 to put the goop back in, it needs to add the signatures of AS2 and = 3 to the goop chain. The chain of ASNs in the new signature chain needs to be= the same AS chain as in the BGPSEC. --Jakob > -----Original Message----- > From: Sriram, Kotikalapudi [mailto:kotikalapudi.sriram@nist.gov] > Sent: Tuesday, July 29, 2014 1:52 PM > To: Jakob Heitz (jheitz); IETF SIDR; idr@ietf.org; grow@ietf.org > Subject: RE: draft-sriram-route-leak-protection-00 >=20 > >I'm not proposing to include it in the BGPSEC signature, It would > be a separate signature. > >Once AS2 removes it, it removes the attribute and its signature > chain. > >The BGPSEC attribute and its signature chain is a different > signature chain and not removed. > > > >The second attribute I proposed will be covered by the BGPSEC > signature chain and not removed. > > >=20 > Jakob, >=20 > OK, you are proposing a separate signature chain besides the BGPSEC > sig chain. > But any signature chain must continue end-to-end across the whole AS > path. > Because, if a signature chain is allowed to be removed at any point > in the path, then it becomes vulnerable to cut and paste attack. > Again, consider an update received at AS5 as P [AS4 AS3 AS2 AS1], > where AS1 is origin. > Let us say, AS2 removed your proposed first attribute and the > associated signature, and forwarded the update to its customer AS3. > Now AS3 forwards the update to its customer AS4. > AS4 can somehow learn that AS1 sent the first attribute to AS2 and > signed it, and it can somehow get that whole 'goop' (i.e. the > attribute and the sig of AS1). > Then AS4 can add back the 'goop', and forward the update to its > *upstream provider* AS5, and AS5 would be fooled and oblivious of > the leak. >=20 > (Note: Again think of the reason why partial path signatures are > disallowed in BGPSEC. > The same principles should apply here too with any other proposed > sig chain.) >=20 > Sriram >=20 > >--Jakob >=20 From nobody Tue Jul 29 16:05:39 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 EC7C71B2A1C; Tue, 29 Jul 2014 16:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_LOW=-0.7, 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 mcTTThtoQUsv; Tue, 29 Jul 2014 16:05:25 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05FD51B2985; Tue, 29 Jul 2014 16:05:24 -0700 (PDT) Received: from BN1PR09MB0274.namprd09.prod.outlook.com (25.160.80.23) by BN1PR09MB0276.namprd09.prod.outlook.com (25.160.80.25) with Microsoft SMTP Server (TLS) id 15.0.995.14; Tue, 29 Jul 2014 23:05:23 +0000 Received: from BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) by BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) with mapi id 15.00.0995.014; Tue, 29 Jul 2014 23:05:23 +0000 From: "Sriram, Kotikalapudi" To: "Jakob Heitz (jheitz)" , IETF SIDR , "idr@ietf.org" , "grow@ietf.org" Thread-Topic: draft-sriram-route-leak-protection-00 Thread-Index: Ac+p/vnHoWsppmC3R8uDlV6ghI7lHQBSoyTQAALDSrAAAxfY4AAAxGpgAAEXotAAAfYogAACw6FA Date: Tue, 29 Jul 2014 23:05:22 +0000 Message-ID: <04c0c88dc1b541abba698499921e417a@BN1PR09MB0274.namprd09.prod.outlook.com> References: <075DE01702BBC249BE1357EFD20DCFE50CF04B96@xmb-aln-x02.cisco.com> <671badb13318451098ddea1430afbc2f@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF05FC4@xmb-aln-x02.cisco.com> <9d9616c29f694286b9e0673f5959e715@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF060CA@xmb-aln-x02.cisco.com> <0608667c14f1402caa404e73f940e416@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF061BE@xmb-aln-x02.cisco.com> In-Reply-To: <075DE01702BBC249BE1357EFD20DCFE50CF061BE@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.100] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0287BBA78D x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(13464003)(189002)(51704005)(377454003)(243025005)(81542001)(46102001)(19580395003)(4396001)(31966008)(74502001)(50986999)(99396002)(76176999)(86362001)(54356999)(101416001)(15202345003)(93886003)(19580405001)(81342001)(87936001)(92566001)(2656002)(64706001)(20776003)(74316001)(2201001)(76576001)(85852003)(83322001)(77982001)(80022001)(66066001)(85306003)(33646002)(107886001)(106356001)(105586002)(99286002)(95666004)(107046002)(83072002)(21056001)(79102001)(15975445006)(77096002)(76482001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR09MB0276; H:BN1PR09MB0274.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/AMnLqnE0YuVDuY4KIZhyBqlzOY8 Subject: Re: [sidr] draft-sriram-route-leak-protection-00 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, 29 Jul 2014 23:05:29 -0000 Jakob, OK, understood. But I still have these additional concerns/questions about your proposed me= thod: 1. People think having one signature chain in updates is bad enough.=20 You are proposing two signature chains. 2. How do you address the issue when an AS that is not the originator Wants to signal to a peer that the update should not be propagated=20 Laterally to another peer or to an upstream provider=20 (I.e., update can only be forwarded to customers). What tagging or attribute can you use to enable this if you were to ext= end your method? Please see what Method 2 does ('10' tag), slide 8 in my presentation:=20 http://www.ietf.org/proceedings/90/slides/slides-90-grow-2.pdf=20 3. The reason for your proposed method is that you wanted=20 ASes not to have to disclose peering relationships. My method (the draft we are discussing) does not require that explicitl= y. Sure, you can infer something from the tagging.=20 But even in your approach, if there were Routeviews/RIPE-RIS like colle= ctors, That collected the signed updates, then it is easy to tell who stripped= the First attribute and towards which neighbor.=20 So there is an implicit discernable peering disclosure there too. Sriram =20 -----Original Message----- From: sidr [mailto:sidr-bounces@ietf.org] On Behalf Of Jakob Heitz (jheitz) Sent: Tuesday, July 29, 2014 5:07 PM To: Sriram, Kotikalapudi; IETF SIDR; idr@ietf.org; grow@ietf.org Subject: Re: [sidr] draft-sriram-route-leak-protection-00 No it wouldn't. For AS4 to put the goop back in, it needs to add the signatures of AS2 and = 3 to the goop chain. The chain of ASNs in the new signature chain needs to = be the same AS chain as in the BGPSEC. --Jakob > -----Original Message----- > From: Sriram, Kotikalapudi [mailto:kotikalapudi.sriram@nist.gov] > Sent: Tuesday, July 29, 2014 1:52 PM > To: Jakob Heitz (jheitz); IETF SIDR; idr@ietf.org; grow@ietf.org > Subject: RE: draft-sriram-route-leak-protection-00 >=20 > >I'm not proposing to include it in the BGPSEC signature, It would > be a separate signature. > >Once AS2 removes it, it removes the attribute and its signature > chain. > >The BGPSEC attribute and its signature chain is a different > signature chain and not removed. > > > >The second attribute I proposed will be covered by the BGPSEC > signature chain and not removed. > > >=20 > Jakob, >=20 > OK, you are proposing a separate signature chain besides the BGPSEC=20 > sig chain. > But any signature chain must continue end-to-end across the whole AS=20 > path. > Because, if a signature chain is allowed to be removed at any point in=20 > the path, then it becomes vulnerable to cut and paste attack. > Again, consider an update received at AS5 as P [AS4 AS3 AS2 AS1],=20 > where AS1 is origin. > Let us say, AS2 removed your proposed first attribute and the=20 > associated signature, and forwarded the update to its customer AS3. > Now AS3 forwards the update to its customer AS4. > AS4 can somehow learn that AS1 sent the first attribute to AS2 and=20 > signed it, and it can somehow get that whole 'goop' (i.e. the=20 > attribute and the sig of AS1). > Then AS4 can add back the 'goop', and forward the update to its=20 > *upstream provider* AS5, and AS5 would be fooled and oblivious of the=20 > leak. >=20 > (Note: Again think of the reason why partial path signatures are=20 > disallowed in BGPSEC. > The same principles should apply here too with any other proposed sig=20 > chain.) >=20 > Sriram >=20 From nobody Tue Jul 29 16:13: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 EF73C1B2985; Tue, 29 Jul 2014 16:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.777 X-Spam-Level: X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, GB_ABOUTYOU=0.5, HTML_MESSAGE=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 Mm-56dwOPMOJ; Tue, 29 Jul 2014 16:12:57 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56EDA1B29F5; Tue, 29 Jul 2014 16:12:56 -0700 (PDT) Received: by mail-ig0-f180.google.com with SMTP id l13so1856717iga.1 for ; Tue, 29 Jul 2014 16:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ssf/X600AK8AVBO7W7HEjZrNz6mJr7TKKApJy9GJG8g=; b=Bh6vT9Upj9VPY1QAqPiMXMBYOUMu0U7EVB2aDFPQy6m6JYuXR26kC6Lc9O38OSACci 3LWLMhppmuhad5sZ5iJBuDN0uspRsYX+k21aMmpT6bx76Mt8SsWQhNWUZsJX6IyWyWn2 rbBCVXK4bBb2D4V8bG7EAEowmBnw3TghL+HJhS6AIlWTDl+Z43fHVkSiRO0CsxFDXYtN rnAdpPc3gzpJveb7yGJSdYiqiZEfTR/iXA1HZnNfq9SEkD0PzIb26DuF91wtGSzjCp0I er3lOfy1K2HxaEmxueiE0+BCu60326jiDPTri5qcVlQud13C35AezBgHugWrNZ/BnBjH fbLA== MIME-Version: 1.0 X-Received: by 10.50.36.106 with SMTP id p10mr48635885igj.9.1406675575539; Tue, 29 Jul 2014 16:12:55 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Tue, 29 Jul 2014 16:12:55 -0700 (PDT) In-Reply-To: <04c0c88dc1b541abba698499921e417a@BN1PR09MB0274.namprd09.prod.outlook.com> References: <075DE01702BBC249BE1357EFD20DCFE50CF04B96@xmb-aln-x02.cisco.com> <671badb13318451098ddea1430afbc2f@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF05FC4@xmb-aln-x02.cisco.com> <9d9616c29f694286b9e0673f5959e715@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF060CA@xmb-aln-x02.cisco.com> <0608667c14f1402caa404e73f940e416@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF061BE@xmb-aln-x02.cisco.com> <04c0c88dc1b541abba698499921e417a@BN1PR09MB0274.namprd09.prod.outlook.com> Date: Wed, 30 Jul 2014 01:12:55 +0200 X-Google-Sender-Auth: Q909SrXu0NkpgHNZdpMRd7Wm-Us Message-ID: From: Robert Raszuk To: "Sriram, Kotikalapudi" Content-Type: multipart/alternative; boundary=089e0115ebd0fe8e7f04ff5d2d8c Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/8Otphv0N8lXNp7cFYZw6hhwR2TU Cc: "idr@ietf.org" , "grow@ietf.org" , IETF SIDR Subject: Re: [sidr] draft-sriram-route-leak-protection-00 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, 29 Jul 2014 23:12:59 -0000 --089e0115ebd0fe8e7f04ff5d2d8c Content-Type: text/plain; charset=UTF-8 > 1. People think having one signature chain in updates is bad enough. > You are proposing two signature chains. That to me has zero practical/real deployment relevance. Cheers, R. On Wed, Jul 30, 2014 at 1:05 AM, Sriram, Kotikalapudi < kotikalapudi.sriram@nist.gov> wrote: > Jakob, > > OK, understood. > But I still have these additional concerns/questions about your proposed > method: > 1. People think having one signature chain in updates is bad enough. > You are proposing two signature chains. > 2. How do you address the issue when an AS that is not the originator > Wants to signal to a peer that the update should not be propagated > Laterally to another peer or to an upstream provider > (I.e., update can only be forwarded to customers). > What tagging or attribute can you use to enable this if you were to > extend your method? > Please see what Method 2 does ('10' tag), slide 8 in my presentation: > http://www.ietf.org/proceedings/90/slides/slides-90-grow-2.pdf > 3. The reason for your proposed method is that you wanted > ASes not to have to disclose peering relationships. > My method (the draft we are discussing) does not require that > explicitly. > Sure, you can infer something from the tagging. > But even in your approach, if there were Routeviews/RIPE-RIS like > collectors, > That collected the signed updates, then it is easy to tell who > stripped the > First attribute and towards which neighbor. > So there is an implicit discernable peering disclosure there too. > > Sriram > > -----Original Message----- > From: sidr [mailto:sidr-bounces@ietf.org] On Behalf Of Jakob Heitz > (jheitz) > Sent: Tuesday, July 29, 2014 5:07 PM > To: Sriram, Kotikalapudi; IETF SIDR; idr@ietf.org; grow@ietf.org > Subject: Re: [sidr] draft-sriram-route-leak-protection-00 > > No it wouldn't. > For AS4 to put the goop back in, it needs to add the signatures of AS2 and > 3 to the goop chain. The chain of ASNs in the new signature chain needs to > be the same AS chain as in the BGPSEC. > > --Jakob > > > > -----Original Message----- > > From: Sriram, Kotikalapudi [mailto:kotikalapudi.sriram@nist.gov] > > Sent: Tuesday, July 29, 2014 1:52 PM > > To: Jakob Heitz (jheitz); IETF SIDR; idr@ietf.org; grow@ietf.org > > Subject: RE: draft-sriram-route-leak-protection-00 > > > > >I'm not proposing to include it in the BGPSEC signature, It would > > be a separate signature. > > >Once AS2 removes it, it removes the attribute and its signature > > chain. > > >The BGPSEC attribute and its signature chain is a different > > signature chain and not removed. > > > > > >The second attribute I proposed will be covered by the BGPSEC > > signature chain and not removed. > > > > > > > Jakob, > > > > OK, you are proposing a separate signature chain besides the BGPSEC > > sig chain. > > But any signature chain must continue end-to-end across the whole AS > > path. > > Because, if a signature chain is allowed to be removed at any point in > > the path, then it becomes vulnerable to cut and paste attack. > > Again, consider an update received at AS5 as P [AS4 AS3 AS2 AS1], > > where AS1 is origin. > > Let us say, AS2 removed your proposed first attribute and the > > associated signature, and forwarded the update to its customer AS3. > > Now AS3 forwards the update to its customer AS4. > > AS4 can somehow learn that AS1 sent the first attribute to AS2 and > > signed it, and it can somehow get that whole 'goop' (i.e. the > > attribute and the sig of AS1). > > Then AS4 can add back the 'goop', and forward the update to its > > *upstream provider* AS5, and AS5 would be fooled and oblivious of the > > leak. > > > > (Note: Again think of the reason why partial path signatures are > > disallowed in BGPSEC. > > The same principles should apply here too with any other proposed sig > > chain.) > > > > Sriram > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --089e0115ebd0fe8e7f04ff5d2d8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> 1. People = think having one signature chain in updates is bad enough.
> =C2=A0 =C2=A0 You are proposing two = signature chains.

That to me has = zero practical/real deployment relevance.=C2=A0

Cheers,
= R.


On Wed, Jul 30, 2014 at 1:05 AM, Sriram, Kotikalapudi <ko= tikalapudi.sriram@nist.gov> wrote:
Jakob,

OK, understood.
But I still have these additional concerns/questions about your proposed me= thod:
1. People think having one signature chain in updates is bad enough.
=C2=A0 =C2=A0 You are proposing two signature chains.
2. How do you address the issue when an AS that is not the originator
=C2=A0 =C2=A0 Wants to signal to a peer that the update should not be propa= gated
=C2=A0 =C2=A0 Laterally to another peer or to an upstream provider
=C2=A0 =C2=A0 (I.e., update can only be forwarded to customers).
=C2=A0 =C2=A0 What tagging or attribute can you use to enable this if you w= ere to extend your method?
=C2=A0 =C2=A0 Please see what Method 2 does ('10' tag), slide 8 in = my presentation:
=C2=A0 =C2=A0 =C2=A0http://www.ietf.org/proceedings/90/sl= ides/slides-90-grow-2.pdf
3. The reason for your proposed method is that you wanted
=C2=A0 =C2=A0 ASes not to have to disclose peering relationships.
=C2=A0 =C2=A0 My method (the draft we are discussing) does not require that= explicitly.
=C2=A0 =C2=A0 Sure, you can infer something from the tagging.
=C2=A0 =C2=A0 But even in your approach, if there were Routeviews/RIPE-RIS = like collectors,
=C2=A0 =C2=A0 That collected the signed updates, then it is easy to tell wh= o stripped the
=C2=A0 =C2=A0 First attribute and towards which neighbor.
=C2=A0 =C2=A0 So there is an implicit discernable peering disclosure there = too.

Sriram

-----Original Message-----
From: sidr [mailto:sidr-bounces@ie= tf.org] On Behalf Of Jakob Heitz (jheitz)
Sent: Tuesday, July 29, 2014 5:07 PM
To: Sriram, Kotikalapudi; IETF SIDR; idr@ie= tf.org; grow@ietf.org
Subject: Re: [sidr] draft-sriram-route-leak-protection-00

No it wouldn't.
For AS4 to put the goop back in, it needs to add the signatures of AS2 and = 3 to the goop chain. The chain of ASNs in the new signature chain needs to = be the same AS chain as in the BGPSEC.

--Jakob


> -----Original Message-----
> From: Sriram, Kotikalapudi [mailto:kotikalapudi.sriram@nist.gov]
> Sent: Tuesday, July 29, 2014 1:52 PM
> To: Jakob Heitz (jheitz); IETF SIDR; i= dr@ietf.org; grow@ietf.org
> Subject: RE: draft-sriram-route-leak-protection-00
>
> >I'm not proposing to include it in the BGPSEC signature, It wo= uld
> be a separate signature.
> >Once AS2 removes it, it removes the attribute and its signature > chain.
> >The BGPSEC attribute and its signature chain is a different
> signature chain and not removed.
> >
> >The second attribute I proposed will be covered by the BGPSEC
> signature chain and not removed.
> >
>
> Jakob,
>
> OK, you are proposing a separate signature chain besides the BGPSEC > sig chain.
> But any signature chain must continue end-to-end across the whole AS > path.
> Because, if a signature chain is allowed to be removed at any point in=
> the path, then it becomes vulnerable to cut and paste attack.
> Again, consider an update received at AS5 as P [AS4 AS3 AS2 AS1],
> where AS1 is origin.
> Let us say, AS2 removed your proposed first attribute and the
> associated signature, and forwarded the update to its customer AS3. > Now AS3 forwards the update to its customer AS4.
> AS4 can somehow learn that AS1 sent the first attribute to AS2 and
> signed it, and it can somehow get that whole 'goop' (i.e. the<= br> > attribute and the sig of AS1).
> Then AS4 can add =C2=A0back the 'goop', and forward the update= to its
> *upstream provider* AS5, and AS5 would be fooled and oblivious of the<= br> > leak.
>
> (Note: Again think of the reason why partial path signatures are
> disallowed in BGPSEC.
> The same principles should apply here too with any other proposed sig<= br> > chain.)
>
> Sriram
>

_______________________________________________
sidr mailing list
sidr@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sidr

--089e0115ebd0fe8e7f04ff5d2d8c-- From nobody Tue Jul 29 17:02: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 568D21A03E5; Tue, 29 Jul 2014 17:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.002 X-Spam-Level: X-Spam-Status: No, score=-14.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 x7NEMXRbz4Oj; Tue, 29 Jul 2014 17:01:58 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 850671A038D; Tue, 29 Jul 2014 17:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4683; q=dns/txt; s=iport; t=1406678518; x=1407888118; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=k8CL3rc9FONxI9edMf8PfU3osBKePdCCDSlgL7LWpF4=; b=OxmuZ3MOOVxXgcYFXHHTnp/sVe3e6rXdcEc5buB+b8/iwVEYn71/3a8H 2B7JXDMnj2dVRC03YYWvD3unDEl2KkrLGsgAl2whFOLOjNJaSB2CuxPFZ qZWsetny6u1kTn++/XPQqSaqU4FMlWOqaeFBGyjxhO/UK1DLEf95encJS Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAN802FOtJA2K/2dsb2JhbABagw5SVwTLfIdLAYEPFneEAwEBAQICOjgTBAIBCBEEAQELFAkHMhQJCAIEARIIAYg5Db9WF48bOAaDKYEbBbAdg0lsAYECBzs X-IronPort-AV: E=Sophos;i="5.01,760,1400025600"; d="scan'208";a="343738140" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-8.cisco.com with ESMTP; 30 Jul 2014 00:01:57 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s6U01vNj003049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jul 2014 00:01:57 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 29 Jul 2014 19:01:57 -0500 From: "Jakob Heitz (jheitz)" To: "Sriram, Kotikalapudi" , IETF SIDR , "idr@ietf.org" , "grow@ietf.org" Thread-Topic: draft-sriram-route-leak-protection-00 Thread-Index: Ac+p/vnHoWsppmC3R8uDlV6ghI7lHQBSoyTQAALDSrAAAxfY4AAAxGpgAAEXotAAAfYogAACw6FAAAJGnhA= Date: Wed, 30 Jul 2014 00:01:56 +0000 Message-ID: <075DE01702BBC249BE1357EFD20DCFE50CF063C1@xmb-aln-x02.cisco.com> References: <075DE01702BBC249BE1357EFD20DCFE50CF04B96@xmb-aln-x02.cisco.com> <671badb13318451098ddea1430afbc2f@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF05FC4@xmb-aln-x02.cisco.com> <9d9616c29f694286b9e0673f5959e715@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF060CA@xmb-aln-x02.cisco.com> <0608667c14f1402caa404e73f940e416@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF061BE@xmb-aln-x02.cisco.com> <04c0c88dc1b541abba698499921e417a@BN1PR09MB0274.namprd09.prod.outlook.com> In-Reply-To: <04c0c88dc1b541abba698499921e417a@BN1PR09MB0274.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.217] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/XRgH7FUh4Y3Ym8g7b8qCVjMddwM Subject: Re: [sidr] draft-sriram-route-leak-protection-00 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, 30 Jul 2014 00:02:00 -0000 There is no need to send this attribute to a collector. If a provider respects his customer's wishes to privacy, he will strip the attribute before sending it to a collector. The worst thing is sending only one prefix per update and having to sign it differently for each AS you send it to. Compared with that, another signature chain is a drop in the bucket. Maybe we can combine ideas. Take your RLP attribute and sign it in another signature chain. Each AS adds its bits and signs it again. First AS to remove it means "propagate to customers only" You still need the "The RLP was added" bit in the BGPSEC signature. Something like that? --Jakob > -----Original Message----- > From: Sriram, Kotikalapudi [mailto:kotikalapudi.sriram@nist.gov] > Sent: Tuesday, July 29, 2014 4:05 PM > To: Jakob Heitz (jheitz); IETF SIDR; idr@ietf.org; grow@ietf.org > Subject: RE: draft-sriram-route-leak-protection-00 >=20 > Jakob, >=20 > OK, understood. > But I still have these additional concerns/questions about your > proposed method: > 1. People think having one signature chain in updates is bad enough. > You are proposing two signature chains. > 2. How do you address the issue when an AS that is not the > originator > Wants to signal to a peer that the update should not be > propagated > Laterally to another peer or to an upstream provider > (I.e., update can only be forwarded to customers). > What tagging or attribute can you use to enable this if you were > to extend your method? > Please see what Method 2 does ('10' tag), slide 8 in my > presentation: > http://www.ietf.org/proceedings/90/slides/slides-90-grow-2.pdf > 3. The reason for your proposed method is that you wanted > ASes not to have to disclose peering relationships. > My method (the draft we are discussing) does not require that > explicitly. > Sure, you can infer something from the tagging. > But even in your approach, if there were Routeviews/RIPE-RIS > like collectors, > That collected the signed updates, then it is easy to tell who > stripped the > First attribute and towards which neighbor. > So there is an implicit discernable peering disclosure there too. >=20 > Sriram >=20 > -----Original Message----- > From: sidr [mailto:sidr-bounces@ietf.org] On Behalf Of Jakob Heitz > (jheitz) > Sent: Tuesday, July 29, 2014 5:07 PM > To: Sriram, Kotikalapudi; IETF SIDR; idr@ietf.org; grow@ietf.org > Subject: Re: [sidr] draft-sriram-route-leak-protection-00 >=20 > No it wouldn't. > For AS4 to put the goop back in, it needs to add the signatures of > AS2 and 3 to the goop chain. The chain of ASNs in the new signature > chain needs to be the same AS chain as in the BGPSEC. >=20 > --Jakob >=20 >=20 > > -----Original Message----- > > From: Sriram, Kotikalapudi [mailto:kotikalapudi.sriram@nist.gov] > > Sent: Tuesday, July 29, 2014 1:52 PM > > To: Jakob Heitz (jheitz); IETF SIDR; idr@ietf.org; grow@ietf.org > > Subject: RE: draft-sriram-route-leak-protection-00 > > > > >I'm not proposing to include it in the BGPSEC signature, It would > > be a separate signature. > > >Once AS2 removes it, it removes the attribute and its signature > > chain. > > >The BGPSEC attribute and its signature chain is a different > > signature chain and not removed. > > > > > >The second attribute I proposed will be covered by the BGPSEC > > signature chain and not removed. > > > > > > > Jakob, > > > > OK, you are proposing a separate signature chain besides the > BGPSEC > > sig chain. > > But any signature chain must continue end-to-end across the whole > AS > > path. > > Because, if a signature chain is allowed to be removed at any > point in > > the path, then it becomes vulnerable to cut and paste attack. > > Again, consider an update received at AS5 as P [AS4 AS3 AS2 AS1], > > where AS1 is origin. > > Let us say, AS2 removed your proposed first attribute and the > > associated signature, and forwarded the update to its customer AS3. > > Now AS3 forwards the update to its customer AS4. > > AS4 can somehow learn that AS1 sent the first attribute to AS2 and > > signed it, and it can somehow get that whole 'goop' (i.e. the > > attribute and the sig of AS1). > > Then AS4 can add back the 'goop', and forward the update to its > > *upstream provider* AS5, and AS5 would be fooled and oblivious of > the > > leak. > > > > (Note: Again think of the reason why partial path signatures are > > disallowed in BGPSEC. > > The same principles should apply here too with any other proposed > sig > > chain.) > > > > Sriram > > From nobody Wed Jul 30 11:16: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 42B221A0203 for ; Wed, 30 Jul 2014 11:16:48 -0700 (PDT) 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 xo2NmLes2KGx for ; Wed, 30 Jul 2014 11:16:46 -0700 (PDT) Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [69.93.243.9]) (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 6AE8E1A035D for ; Wed, 30 Jul 2014 11:16:25 -0700 (PDT) Received: by gateway11.websitewelcome.com (Postfix, from userid 500) id DEB9F4D7A1108; Wed, 30 Jul 2014 13:10:53 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway11.websitewelcome.com (Postfix) with ESMTP id 076D04D77184C for ; Wed, 30 Jul 2014 13:10:08 -0500 (CDT) Received: from [96.231.227.95] (port=50461 helo=[192.168.1.18]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XCYKF-0003O5-GS for sidr@ietf.org; Wed, 30 Jul 2014 13:10:07 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <938CD198-AF49-42DF-8415-0FF844420BFD@ieca.com> Date: Wed, 30 Jul 2014 14:10:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <75C51A68-FEC3-40B0-BC6C-A8A2471FF4CD@tislabs.com> <53B181C7.4000701@bbn.com> <20140701223419.3E6B9F4380E@minas-ithil.hactrn.net> <53B41070.7040902@bbn.com> <938CD198-AF49-42DF-8415-0FF844420BFD@ieca.com> To: sidr@ietf.org 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: 96.231.227.95 X-Exim-ID: 1XCYKF-0003O5-GS X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.18]) [96.231.227.95]:50461 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/2_-6Rnx6ajk2H4DjsMc8HH-PZNI Subject: Re: [sidr] EST (was Re: about the thread "Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487") 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, 30 Jul 2014 18:16:48 -0000 On Jul 02, 2014, at 11:16, Sean Turner wrote: > On Jul 02, 2014, at 10:00, Stephen Kent wrote: >=20 >> Rob, >>=20 >>> At Mon, 30 Jun 2014 11:27:03 -0400, Stephen Kent wrote: >>>> I did suggest we might use other cert request mechanisms. EST is = the >>>> obvious, current, standards-based option for this, if folks want to >>>> consider alternatives to PKCS#10. Since it was authored by a Cisco >>>> guy, there is some chance it might become available in their >>>> routers. I would suggest this path only for router certs, not for >>>> the RPKI certs. That might make it unpalatable, as a CA operated by >>>> an ISP would have to deal with two cert request formats: PKCS#1- = for >>>> child CA certs (if the ISP is not a stub in the RPKI tree) and EST >>>> for router certs. >>> Is there any real benefit to EST, given that we already have to >>> support PKCS #10 and given that PKCS #10 implementations are almost >>> certainly easier to find than EST implementations? >> As I noted, I am aware of only a Cisco implementation, but we could = check with >> Max Pritikin to see if he is aware of others. >>> Absent some serious advantage that I'm not seeing, this doesn't seem >>> particularly attractive. >>>=20 >>>> I'm just pointing out options. >>> Understood. >>=20 >=20 > Dan=92s got an implementation on github: >=20 > https://github.com/danharkins/est >=20 > spt Here=92s the link for Cisco's: https://github.com/cisco/libest spt= From nobody Wed Jul 30 18:21:18 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 960EA1A039F; Wed, 30 Jul 2014 18:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 cGvcu66UjPVn; Wed, 30 Jul 2014 18:21:11 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76DC31A016D; Wed, 30 Jul 2014 18:21:11 -0700 (PDT) Received: from BN1PR09MB0274.namprd09.prod.outlook.com (25.160.80.23) by BN1PR09MB0276.namprd09.prod.outlook.com (25.160.80.25) with Microsoft SMTP Server (TLS) id 15.0.995.14; Thu, 31 Jul 2014 01:21:09 +0000 Received: from BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) by BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) with mapi id 15.00.0995.014; Thu, 31 Jul 2014 01:21:09 +0000 From: "Sriram, Kotikalapudi" To: Christopher Morrow , Doug Montgomery Thread-Topic: [GROW] Route leaks Thread-Index: AQHPqC+L+pthRCwHxUq5zj1Ayx7LMZuxKGaAgAAEMYCAAAJggIAAHfwAgAFhWYCAA64xgIADA4Og Date: Thu, 31 Jul 2014 01:21:08 +0000 Message-ID: <2c1f9feb72ff4042b3ff329292b93ea2@BN1PR09MB0274.namprd09.prod.outlook.com> References: <8D378E8B-13DB-4733-91B2-5F9D000AF454@puck.nether.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.100] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0289B6431E x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(52314003)(51704005)(199002)(189002)(107046002)(105586002)(95666004)(77096002)(83072002)(33646002)(85306003)(99286002)(106356001)(79102001)(21056001)(76482001)(80022001)(76176999)(101416001)(93886003)(106116001)(86362001)(50986999)(74662001)(81542001)(46102001)(74502001)(4396001)(31966008)(83322001)(2656002)(85852003)(54356999)(20776003)(66066001)(77982001)(76576001)(99396002)(92566001)(81342001)(87936001)(74316001)(64706001)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR09MB0276; H:BN1PR09MB0274.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/Khada5ntBP48R531XiU3NRncKkc Cc: "grow@ietf.org grow@ietf.org" , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] [GROW] Route leaks 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, 31 Jul 2014 01:21:13 -0000 >> In some ways I think building a taxonomy of scenarios that could be=20 >> called route-leaks is useful, but I do think there is a danger is=20 >> overly fixating on a precise definition of a commonly used term ... > > The state today is: "I know it when I see it" > which isn't super helpful in the 'gosh, it'd sure be nice to stop=20 > having ISPA leaking my routes all over creation' fight. Chris, If we step back for a moment and look at how we tackled prefix hijacks,=20 there is a valuable lesson there that applies also to tackling route leaks. Initially, we classified prefix hijacks into two types: 1. Prefix hijack, 2. Subprefix hijack. This was based on commonly observed hijack incidents. We started looking at solutions, and determined that generating=20 ROAs for the prefixes would be a solution for the first one. Then we thought a bit more, and determined that specifying=20 MaxLength in the ROA would be a partial solution for the second one. After we included ROAs in our design, we realized that there are these=20 two new classes of prefix hijacks that try to defy ROAs and maxLength: 3. Subprefix hijack where maxLength is not violated,=20 4. Faked-origin (prefix/subprefix) hijack. Thus, our understanding evolved to classify prefix hijacks into four types,= =20 each calling for possibly a different solution component. This was, in part, the consequence of the solutions we were considering. Then we thought that perhaps we can put two ASes in the ROA (origin AS and = the second AS)=20 to try to disadvantage the faked-origin hijacks.=20 Because then the hijacked route is at least two hops longer compared to the= legitimate one. But eventually, we decided to do the path signatures since we had to protec= t AS path anyway,=20 and path signatures approach also solved prefix hijacks of Type 3 and Type = 4 above -- because they are essentially path modifications. Viola: Now we have the solution for all four classes of hijacks plus full A= S path protection! (Granted -- our solution is not yet complete because it doesn't solve route= leaks.) The essential lesson that I think we learned from the above is that=20 classification based on observed or easily conjectured scenarios works! So yes, classify and conquer should be the motto here. As is evident from the above, starting to propose solutions based on what w= e know -- even if it is partial knowledge -- is helpful. And with some solution components in place, further taxonomy naturally evol= ves=20 to provide greater clarity into problem definition and classification. Sriram From nobody Thu Jul 31 13:03:19 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 DCD3A1A00C2 for ; Thu, 31 Jul 2014 13:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 OwoL3L0yQq1E for ; Thu, 31 Jul 2014 13:03:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DCC41A00DF for ; Thu, 31 Jul 2014 13:03:14 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:51497) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XCwZF-000ErH-Cd for sidr@ietf.org; Thu, 31 Jul 2014 16:03:13 -0400 Message-ID: <53DAA101.8020305@bbn.com> Date: Thu, 31 Jul 2014 16:03:13 -0400 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: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> 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/C2BKCtR4h0o33AKGGj0g_tyqjj0 Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 20:03:18 -0000 Carlos, > It is weird that we even need to state here that we the five RIRs are > not going to break things intentionally, but, yeah, LACNIC will not > break things intentionally either. I don't think anyone requested that each RIR pledge to not try to break the RPKI. I did ask that RIRs describe what measures they take to detect possible errors, prior to issuing certs that might cause subordinate CAs to fail 3779 validation criteria. I thought the replies from RIPE and APNIC were very encouraging. > Engineering for resiliency is as much a necessity as engineering for > security. If the damage caused by the failures of the solution itself > becomes worse than the damage caused by the problem, well, no one is > going to deploy the solution. Terry has reminded us that, even if such accidents occur, the world does not end, at least wrt origin validation. Thus, for the current set of SIDR RFCs, the damage that would occur is not nearly so great as some have suggested; until the error is fixed (which one would presume would be fairly quickly), origin validation would treat the affected routes as no worse than they are treated today. Terry's message from 7/25 suggested that we revisit details of BGPSEC to see if we might want to address the the concerns about errors in the RPKI in a more accommodating fashion. I think he has a good point. We are still working on BGPSEC and so we have the leeway to revisit details of this sort. In the SIDR meeting last week Geoff cited a problem that relaxing the 3779 validation criteria was supposed to address (though not explicitly mentioned in his I-D): an operator who asserts that it holds an ASN, at odds with the RIR that is supposed to be authoritative for the assignment of that ASN. This case is illustrative of the concern I tried to raise in my comments to Tim, i.e., I worried that relaxing 3779 validation rules might encourage sloppiness in managing the RPKI, e.g., causing CAs to violate the CP by not maintaining the RPKI as a representation of their allocation databases. Geoff's example seems to suggest that my concern is warranted. Relaxing 3779 validation "fixes" the cited problem by making the deviation from the allocation hierarchy acceptable, at the expense of the CP. Finally, the point I tried to make near the end of the session was that if we are worrying about errors by high-tier CAs that break certs (via 3779 validation), then that worry also should extend to errors that revoke certs. Relaxing 3779 validation rules will not help with that problem. The Suspenders proposal does address that, and a broader range of behaviors by CAs. So while Suspenders may not be the answer, I believe that the current problem statement in draft-ietf-sidr-rpki-validation-reconsidered is way too narrow, as it fails to address the wider set of errors (or compelled behavior) by (high tier) CAs in the RPKI. Steve