From sidr-bounces@ietf.org Mon Nov 3 10:26:28 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9456F3A69FD; Mon, 3 Nov 2008 10:26:28 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C87328C0FF for ; Mon, 3 Nov 2008 10:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxpjinUFm4g0 for ; Mon, 3 Nov 2008 10:26:25 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 608053A6979 for ; Mon, 3 Nov 2008 10:26:25 -0800 (PST) Received: from dhcp89-089-234.bbn.com ([128.89.89.234] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Kx482-00066k-Er; Mon, 03 Nov 2008 13:26:18 -0500 Message-ID: <490F41D6.1020901@bbn.com> Date: Mon, 03 Nov 2008 13:24:22 -0500 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "sidr@ietf.org" , Resource Cert List Content-Type: multipart/mixed; boundary="------------030002020503060402070206" Subject: [sidr] ROA Format -04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org This is a multi-part message in MIME format. --------------030002020503060402070206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have submitted a revision to the ROA Format specification (see attached). As per recent discussions on the SIDR list, I have changed the validation text in Section 3 to indicate that a ROA is valid if its IP address prefix(es) are contained within the set of IP addresses specified by the RFC 3779 extension in the EE certificate (previously the text had required an exact match between the IP addresses in a ROA and the Ip addresses in the RFC 3779 extension of the EE cert). The draft remains silent with regards to multiple signatures on a single ROA (as the discussion of this issue did not seem to yield any concensus). - Matt Lepinski --------------030002020503060402070206 Content-Type: text/plain; name="draft-ietf-sidr-roa-format-04.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-sidr-roa-format-04.txt" Secure Inter-Domain Routing (sidr) M. Lepinski Internet Draft S. Kent Expires: May 2009 D. Kong Intended Status: Proposed Standard BBN Technologies November 3, 2008 A Profile for Route Origin Authorizations (ROAs) draft-ietf-sidr-roa-format-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 8, 2008. Abstract This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to that one or more prefixes within the address block. Table of Contents 1. Introduction...................................................2 2. Basic Format...................................................3 Lepinski, Kent and Kong Expires May 2009 [Page 1] Internet-Draft Route Origin Attestation Profile November 2008 2.1. Signed-Data Content Type..................................3 2.1.1. version..............................................4 2.1.2. digestAlgorithms.....................................4 2.1.3. encapContentInfo.....................................4 2.1.3.1. eContentType....................................4 2.1.3.2. eContent........................................4 2.1.3.2.1. version....................................5 2.1.3.2.2. asID.......................................5 2.1.3.2.3. ipAddrBlocks...............................5 2.1.4. certificates.........................................6 2.1.5. crls.................................................6 2.1.6. signerInfos..........................................6 2.1.6.1. version.........................................6 2.1.6.2. sid.............................................6 2.1.6.3. digestAlgorithm.................................6 2.1.6.4. signedAttrs.....................................7 2.1.6.4.1. ContentType Attribute......................7 2.1.6.4.2. MessageDigest Attribute....................7 2.1.6.4.3. SigningTime Attribute......................8 2.1.6.4.4. BinarySigningTimeAttribute.................8 2.1.6.5. signatureAlgorithm..............................8 2.1.6.6. signature.......................................9 2.1.6.7. unsignedAttrs...................................9 3. ROA Validation.................................................9 4. Security Considerations.......................................10 5. IANA Considerations...........................................11 6. Acknowledgments...............................................11 7. References....................................................12 7.1. Normative References.....................................12 7.2. Informative References...................................12 Authors' Addresses...............................................13 Intellectual Property Statement..................................14 Disclaimer of Validity...........................................14 Copyright Statement..............................................14 1. Introduction The primary purpose of the Internet IP Address and AS Number Resource Public Key Infrastructure (RPKI) system is to improve routing security. As part of this system, a mechanism is needed to allow entities to verify that an AS has been given permission by an IP address block holder to advertise routes to one or more prefixes within that block. A ROA provides this function. A ROA is a digitally signed object that makes use of Cryptographic Message Syntax (CMS) [RFC3852] as a standard encapsulation format. Lepinski, Kent and Kong Expires May 2009 [Page 2] Internet-Draft Route Origin Attestation Profile November 2008 CMS was chosen to take advantage of existing open source software available for processing messages in this format. 1.1. Terminology It is assumed that the reader is familiar with the terms and concepts described in "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280] and "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 2. Basic Format Using CMS syntax, a ROA is a type of signed-data object. The general format of a CMS object is: ContentInfo ::= SEQUENCE { contentType ContentType, content [0] EXPLICIT ANY DEFINED BY contentType } ContentType ::= OBJECT IDENTIFIER As a ROA is a signed-data object, it uses the corresponding OID, 1.2.840.113549.1.7.2. [RFC3852] 2.1. Signed-Data Content Type According to the CMS standard, the signed-data content type shall have ASN.1 type SignedData: SignedData ::= SEQUENCE { version CMSVersion, digestAlgorithms DigestAlgorithmIdentifiers, encapContentInfo EncapsulatedContentInfo, certificates [0] IMPLICIT CertificateSet OPTIONAL, crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, signerInfos SignerInfos } DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier SignerInfos ::= SET OF SignerInfo Lepinski, Kent and Kong Expires May 2009 [Page 3] Internet-Draft Route Origin Attestation Profile November 2008 2.1.1. version The version is the syntax version number. It MUST be 3, corresponding to the signerInfo structure having version number 3. 2.1.2. digestAlgorithms The digestAlgorithms set MUST include only SHA-256, the OID for which is 2.16.840.1.101.3.4.2.1. [RFC4055] It MUST NOT contain any other algorithms. 2.1.3. encapContentInfo encapContentInfo is the signed content, consisting of a content type identifier and the content itself. EncapsulatedContentInfo ::= SEQUENCE { eContentType ContentType, eContent [0] EXPLICIT OCTET STRING OPTIONAL } ContentType ::= OBJECT IDENTIFIER 2.1.3.1. eContentType The ContentType for a ROA is defined as routeOriginAttestation and has the numerical value of 1.2.840.113549.1.9.16.1.24. id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 } id-ct OBJECT INDENTIFIER ::= { id-smime 1 } routeOriginAttestion OBJECT IDENTIFIER ::= { id-ct 24 } 2.1.3.2. eContent The content of a ROA identifies a single AS that has been authorized by the address space holder to originate routes and a list of one or more IP address prefixes that will be advertised. If the address space holder needs to authorize multiple ASes to advertise the same set of address prefixes, the holder issues multiple ROAs, one per AS number. A ROA is formally defined as: RouteOriginAttestation ::= SEQUENCE { version [0] INTEGER DEFAULT 0, asID ASID, ipAddrBlocks SEQUENCE OF ROAIPAddressFamily } Lepinski, Kent and Kong Expires May 2009 [Page 4] Internet-Draft Route Origin Attestation Profile November 2008 ASID ::= INTEGER ROAIPAddressFamily ::= SEQUENCE { addressFamily OCTET STRING (SIZE (2..3)), addresses SEQUENCE OF ROAIPAddress } ROAIPAddress ::= SEQUENCE { address IPAddress, maxLength INTEGER OPTIONAL } IPAddress ::= BIT STRING 2.1.3.2.1. version The version number of the RouteOriginAttestation MUST be 0. 2.1.3.2.2. asID The asID field contains the AS number that is authorized to originate routes to the given IP address prefixes. 2.1.3.2.3. ipAddrBlocks The ipAddrBlocks field encodes the set of IP address prefixes to which the AS is authorized to originate routes. Note that the syntax here is more restrictive than that used in the IP Address Delegation extension defined in RFC 3779. That extension can represent arbitrary address ranges, whereas ROAs need to represent only prefixes. Within the ROAIPAddressFamily structure, addressFamily contains the Address Family Identifier (AFI) of an IP address family. This specification only supports IPv4 and IPv6. Therefore, addressFamily MUST be either 0001 or 0002. Within a ROAIPAddress structure, the addresses field represents prefixes as a sequence of type IPAddress. (See [RFC3779] for more details). If present, the maxLength must be an integer greater than or equal to the length of the accompanying prefix and less than or equal to the length (in bits) of an IP address in the address family (32 for IPv4 and 128 for IPv6). When present, the maxLength specifies the maximum length of IP address prefix that the AS is authorized to advertise. (For example, if the IP Address prefix is 10.0/16 and the maxLength is 24, the AS is authorized to advertise any more specific prefix having length at most 24. That is, in this example, the AS would be authorized to advertise 10.0/16, 10.0.128/20, or Lepinski, Kent and Kong Expires May 2009 [Page 5] Internet-Draft Route Origin Attestation Profile November 2008 10.0.255/24, but not 10.0.255.0/25.) When the maxLength is not present, the AS is only authorized to advertise exactly the prefix specified in the ROA. 2.1.4. certificates The certificates field MUST be included and MUST contain only the end entity certificate needed to validate this ROA. 2.1.5. crls The crls field MUST be omitted. 2.1.6. signerInfos SignerInfo is defined under CMS as: SignerInfo ::= SEQUENCE { version CMSVersion, sid SignerIdentifier, digestAlgorithm DigestAlgorithmIdentifier, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signatureAlgorithm SignatureAlgorithmIdentifier, signature SignatureValue, unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 2.1.6.1. version The version number MUST be 3, corresponding with the choice of SubjectKeyIdentifier for the sid. 2.1.6.2. sid The sid is defined as: SignerIdentifier ::= CHOICE { issuerAndSerialNumber IssuerAndSerialNumber, subjectKeyIdentifier [0] SubjectKeyIdentifier } For a ROA, the sid MUST be a SubjectKeyIdentifier. 2.1.6.3. digestAlgorithm The digestAlgorithm MUST be SHA-256, the OID for which is 2.16.840.1.101.3.4.2.1. [RFC4055] Lepinski, Kent and Kong Expires May 2009 [Page 6] Internet-Draft Route Origin Attestation Profile November 2008 2.1.6.4. signedAttrs The signedAttrs is defined as: SignedAttributes ::= SET SIZE (1..MAX) OF Attribute Attribute ::= SEQUENCE { attrType OBJECT IDENTIFIER, attrValues SET OF AttributeValue } AttributeValue ::= ANY The signedAttr element MUST be present and MUST include the content- type and message-digest attributes. The signer MAY also include the signing-time signed attribute, the binary-signing-time signed attribute, or both signed attributes. Other signed attributes that are deemed appropriate MAY also be included. The intent is to allow additional signed attributes to be included if a future need is identified. This does not cause an interoperability concern because unrecognized signed attributes are ignored by the relying party. The signedAttr MUST include only a single instance of any particular attribute. Additionally, even though the syntax allows for a SET OF AttributeValue, in a ROA the attrValues must consist of only a single AttributeValue. 2.1.6.4.1. ContentType Attribute The ContentType attribute MUST be present. The attrType OID for the ContentType attribute is 1.2.840.113549.1.9.3. The attrValues for the ContentType attribute in a ROA MUST be 1.2.840.113549.1.9.16.1.24 (matching the eContentType in the EncapsulatedContentInfo). 2.1.6.4.2. MessageDigest Attribute The MessageDigest Attribute MUST be present. The attrType OID for the MessageDigest Attribute is 1.2.840.113549.1.9.4. The attrValues for the MessageDigest attribute contains the output of the digest algorithm applied to the content being signed, as specified in Section 11.1 of RFC 3852. Lepinski, Kent and Kong Expires May 2009 [Page 7] Internet-Draft Route Origin Attestation Profile November 2008 2.1.6.4.3. SigningTime Attribute The SigningTime Attribute MAY be present. If it is present it MUST be ignored by the relying party. The presence of absence of the SigningTime attribute in no way affects the validation of the ROA (as specified in Section 3). The attrType OID for the SigningTime attribute is 1.2.840.113549.1.9.5. The attrValues for the SigningTime attribute is defined as: SigningTime ::= Time Time ::= CHOICE { utcTime UTCTime, generalizedTime GeneralizedTime } The Time element specifies the time, based on the local system clock, at which the digital signature was applied to the content. 2.1.6.4.4. BinarySigningTimeAttribute The BinarySigningTime Attribute MAY be present. If it is present it MUST be ignored by the relying party. The presence of absence of the BinarySigningTime attribute in no way affects the validation of the ROA (as specified in Section 3). The attrType OID for the SigningTime attribute is 1.2.840.113549.1.9.16.2.46. The attrValues for the SigningTime attribute is defined as: BinarySigningTime ::= BinaryTime BinaryTime ::= INTEGER (0..MAX) The BinaryTime element specifies the time, based on the local system clock, at which the digital signature was applied to the content. 2.1.6.5. signatureAlgorithm The signatureAlgorithm MUST be RSA (rsaEncryption), the OID for which is 1.2.840.113549.1.1.1. Lepinski, Kent and Kong Expires May 2009 [Page 8] Internet-Draft Route Origin Attestation Profile November 2008 2.1.6.6. signature The signature value is defined as: SignatureValue ::= OCTET STRING The signature characteristics are defined by the digest and signature algorithms. 2.1.6.7. unsignedAttrs unsignedAttrs MUST be omitted. 3. ROA Validation Before a relying party can use a ROA to validate a routing announcement, the relying party must first validate the ROA by verifying that all of the following conditions hold. 1. The ROA syntax complies with this specification. In particular, that each of the following is true: a. The contentType of the CMS object is SignedData (OID 1.2.840.113549.1.7.2) b. The version of the SignedData object is 3. c. The digestAlgorithm in the SignedData object is SHA-256 (OID 2.16.840.1.101.3.4.2.1). d. The certificates field in the SignedData object is present and contains an EE certificate whose Subject Key Identifier (SKI) matches the sid field of the SignerInfo object. e. The crls field in the SignedData object is omitted. f. The eContentType in the EncapsulatedContentInfo is routeOriginAttestation (OID 1.2.840.113549.1.9.16.1.24) g. The version of the RouteOriginAttestation is 0. h. The addressFamily in the ROAIPAddressFamily is either IPv4 or IPv6 (0001 and 0002, respectively). i. The version of the SignerInfo is 3. Lepinski, Kent and Kong Expires May 2009 [Page 9] Internet-Draft Route Origin Attestation Profile November 2008 j. The digestAlgorithm in the SignerInfo object is SHA-256 (OID 2.16.840.1.101.3.4.2.1). k. The signatureAlgorithm in the SignerInfo object is RSA (OID 1.2.840.113549.1.1.1). l. The signedAttrs field in the SignerInfo object is present and contains both the ContentType attribute (OID 1.2.840.113549.1.9.3) and the MessageDigest attribute (OID 1.2.840.113549.1.9.4). m. The unsignedAttrs field in the SignerInfo object is omitted. 2. The public key of the EE certificate (contained within the ROA) can be used to verify the signature on the ROA. 3. The IP Address Delegation extension [RFC3779] is present in the EE certificate (contained within the ROA) and each IP address prefix(es) in ROA is contained within the set of IP addresses specified by the EE certificate's IP address delegation extension. 4. The EE certificate (contained within the ROA) is a valid end- entity certificate in the resource PKI as specified by [RESCERT]. (In particular, there exists a valid certification path from a trust anchor to the EE certificate.) 4. Security Considerations There is no assumption of confidentiality for the data in a ROA; it is anticipated that ROAs will be stored in repositories that are accessible to all ISPs, and perhaps to all Internet users. There is no explicit authentication associated with a ROA, since the PKI used for ROA validation provides authorization but not authentication. Although the ROA is a signed, application layer object, there is no intent to convey non-repudiation via a ROA. The purpose of a ROA is to convey authorization for an AS to originate a route to the prefix(es) in the ROA. Thus the integrity of a ROA must be established. The ROA makes use of the CMS signed message format for integrity, and thus inherits the security considerations associated with that data structure. The right of the ROA signer to authorize the target AS to originate routes to the prefix(es) is established through use of the address space and AS number PKI described in [ARCH]. Specifically one must verify the signature on the ROA using an X.509 certificate issued under this PKI, and check that the prefix(es) in the ROA match those in the address space extension in the certificate. Lepinski, Kent and Kong Expires May 2009 [Page 10] Internet-Draft Route Origin Attestation Profile November 2008 5. IANA Considerations None. 6. Acknowledgments The authors wish to thank Charles Gardiner, Russ Housley and George Michaelson for their help and contributions. Lepinski, Kent and Kong Expires May 2009 [Page 11] Internet-Draft Route Origin Attestation Profile November 2008 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3852] Housley, R., ''Cryptographic Message Syntax'', RFC 3852, July 2004. [RFC4055] Schaad, J., Kaliski, B., and Housley, R., ''Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile'', RFC 4055, June 2005. [RFC3779] Lynn, C., Kent, S., and Seo, K., ''X.509 Extensions for IP Addresses and AS Identifiers'', RFC 3779, June 2004. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. 7.2. Informative References [RSA] Rivest, R., Shamir, A., and Adelman, L. M. 1978. A method for obtaining digital signatures and public-key cryptosystems. Commun. ACM 21, 2 (Feb.), 120-126. [ARCH] Lepinski, M., Kent, S., and Barnes, R., "An Infrastructure to Support Secure Internet Routing," draft-ietf-sidr-arch- 03.txt, February, 2008 (work in progress). [RESCERT] Huston, G., Michaelson, G., and Loomans, R., ''A Profile for X.509 PKIX Resource Certificates,'' draft-ietf-sidr- res-certs-14.txt, October, 2008 (work in progress). Lepinski, Kent and Kong Expires May 2009 [Page 12] Internet-Draft Route Origin Attestation Profile November 2008 Authors' Addresses Matt Lepinski BBN Technologies 10 Moulton Street Cambridge MA 02138 Email: mlepinski@bbn.com Stephen Kent BBN Technologies 10 Moulton Street Cambridge MA 02138 Email: skent@bbn.com Derrick Kong BBN Technologies 10 Moulton Street Cambridge MA 02138 Email: dkong@bbn.com Lepinski, Kent and Kong Expires May 2009 [Page 13] Internet-Draft Route Origin Attestation Profile November 2008 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Lepinski, Kent and Kong Expires May 2009 [Page 14] --------------030002020503060402070206 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --------------030002020503060402070206-- From sidr-bounces@ietf.org Mon Nov 3 10:30:05 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6051728C1AB; Mon, 3 Nov 2008 10:30:05 -0800 (PST) X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8F6933A6BBA; Mon, 3 Nov 2008 10:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103183001.8F6933A6BBA@core3.amsl.com> Date: Mon, 3 Nov 2008 10:30:01 -0800 (PST) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-roa-format-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Profile for Route Origin Authorizations (ROAs) Author(s) : M. Lepinski, et al. Filename : draft-ietf-sidr-roa-format-04.txt Pages : 14 Date : 2008-11-03 This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to that one or more prefixes within the address block. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-format-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-roa-format-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03102624.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Mon Nov 3 13:36:22 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BD133A68B6; Mon, 3 Nov 2008 13:36:22 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32CEE3A68B6 for ; Mon, 3 Nov 2008 13:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2D9wUwfaxxB8 for ; Mon, 3 Nov 2008 13:36:20 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 741613A6774 for ; Mon, 3 Nov 2008 13:36:20 -0800 (PST) Received: from tamerlane.bbn.com ([128.89.88.22]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Kx75t-0008Rd-Eo; Mon, 03 Nov 2008 16:36:17 -0500 Mime-Version: 1.0 Message-Id: Date: Mon, 3 Nov 2008 16:19:11 -0400 To: "sidr@ietf.org" , Resource Cert List From: Karen Seo Subject: [sidr] CPS's for RIRs and ISPs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Folks, We just re-submitted the following two I-Ds so as to re-activate them. The submission system indicated it would take up to 2 days before the draft was processed. There were no changes except for updating the dates. So if you wish to review them prior to their being posted, you can use the previous versions of these drafts at http://tools.ietf.org/wg/sidr/ Template for an Internet Service Provider's Certification Practice Statement (CPS) for the Resource PKI (RPKI) draft-ietf-sidr-cps-isp-03.txt Template for an Internet Registry's Certification Practice Statement (CPS) for the Resource PKI (RPKI) draft-ietf-sidr-cps-irs-04.txt Looking forward to your feedback. Thank you, Karen _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 3 13:45:06 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6B7128C2DE; Mon, 3 Nov 2008 13:45:06 -0800 (PST) X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5D4FF28C26A; Mon, 3 Nov 2008 13:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103214501.5D4FF28C26A@core3.amsl.com> Date: Mon, 3 Nov 2008 13:45:01 -0800 (PST) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-arch-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org --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 : An Infrastructure to Support Secure Internet Routing Author(s) : M. Lepinski, S. Kent Filename : draft-ietf-sidr-arch-04.txt Pages : 27 Date : 2008-11-03 This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a public key infrastructure (PKI) that represents the allocation hierarchy of IP address space and Autonomous System Numbers; and a distributed repository system for storing and disseminating the data objects that comprise the PKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-arch-04.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-arch-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03134236.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Mon Nov 3 15:30:04 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8524A28C3BD; Mon, 3 Nov 2008 15:30:04 -0800 (PST) X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4A6DA28C3AE; Mon, 3 Nov 2008 15:30:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103233001.4A6DA28C3AE@core3.amsl.com> Date: Mon, 3 Nov 2008 15:30:01 -0800 (PST) Cc: sidr@ietf.org Subject: [sidr] I-D ACTION:draft-ietf-sidr-cps-irs-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org --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 : Template for an Internet Registry's Certification Practice Statement (CPS) for the Resource PKI (RPKI) Author(s) : D. Kong, K. Seo, S. Kent Filename : draft-ietf-sidr-cps-irs-04.txt Pages : 45 Date : 2008-11-3 This document contains a template to be used for creating a Certification Practice Statement (CPS) for an Internet Registry (e.g., NIR or RIR) that is part of the Resource Public Key Infrastructure (RPKI). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-cps-irs-04.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-cps-irs-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-3152433.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Mon Nov 3 16:00:04 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61B0928C412; Mon, 3 Nov 2008 16:00:04 -0800 (PST) X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 68C003A6CB5; Mon, 3 Nov 2008 16:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081104000001.68C003A6CB5@core3.amsl.com> Date: Mon, 3 Nov 2008 16:00:01 -0800 (PST) Cc: sidr@ietf.org Subject: [sidr] I-D ACTION:draft-ietf-sidr-cps-isp-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org --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 : Template for an Internet Service Provider's Certification Practice Statement (CPS) for the Resource PKI (RPKI) Author(s) : K. Seo, S. Kent, D. Kong Filename : draft-ietf-sidr-cps-isp-03.txt Pages : 48 Date : 2008-11-3 This document contains a template to be used for creating a Certification Practice Statement (CPS) for a Local Internet Registry (LIR) or Internet Service Provider (ISP) that is part of the Resource Public Key Infrastructure (PKI). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-cps-isp-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-cps-isp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-3155132.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Mon Nov 3 16:00:04 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B98928C418; Mon, 3 Nov 2008 16:00:04 -0800 (PST) X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 728863A6CB3; Mon, 3 Nov 2008 16:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081104000001.728863A6CB3@core3.amsl.com> Date: Mon, 3 Nov 2008 16:00:01 -0800 (PST) Cc: sidr@ietf.org Subject: [sidr] I-D ACTION:draft-ietf-sidr-cp-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org --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 : Certificate Policy (CP) for the Resource PKI (RPKI) Author(s) : S. Kent, D. Kong, K. Seo Filename : draft-ietf-sidr-cp-04.txt Pages : 47 Date : 2008-11-3 This document describes the certificate policy for a PKI used to support improved routing security. Each organization that allocates IP addresses or Autonomous System (AS) numbers to an organization will, in parallel, issue a certificate reflecting this allocation. These certificates will enable verification that the holder of the associated private key has been allocated the resources indicated in the certificate, and is the current, unique holder of these resources. The PKI in which the certificates issued under this policy are employed, in conjunction with ancillary digitally signed data structures, will provide critical inputs for routing security mechanisms, e.g., generation of route filters by ISPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-cp-04.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-cp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-3155857.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Tue Nov 4 07:46:12 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F79F3A69AF; Tue, 4 Nov 2008 07:46:12 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE4543A69AF for ; Tue, 4 Nov 2008 07:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXJiU+g2OW9j for ; Tue, 4 Nov 2008 07:46:09 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 323753A69A4 for ; Tue, 4 Nov 2008 07:46:09 -0800 (PST) Received: from tamerlane.bbn.com ([128.89.88.22]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1KxO6X-0004PE-Av; Tue, 04 Nov 2008 10:46:05 -0500 Mime-Version: 1.0 Message-Id: Date: Tue, 4 Nov 2008 10:29:01 -0400 To: "sidr@ietf.org" , Resource Cert List From: Karen Seo Subject: [sidr] Certificate Policy for the RPKI -- new draft submitted X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1934639391==" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org --===============1934639391== Content-Type: multipart/alternative; boundary="============_-986313552==_ma============" --============_-986313552==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Folks, We just submitted a revised version of the following I-D: Certificate Policy (CP) for the Resource PKI (RPKI) draft-ietf-sidr-cp-04.txt Thanks go to Geoff Huston, Randy Bush, and Tim Christensen for their feedback. The main changes from the 03 version are listed below (not including date changes, typo corrections and various minor wording changes). Note that many of them but NOT all were in the non-IETF version distributed to the rescert mailing list in May. Apologies in advance if I missed any significant changes. Looking forward to receiving your feedback (and completing this document :-)). Karen a. Corrected definition of a "bogus" route to include unauthorized advertisement of an unallocated address (not just one that has been allocated) b. Changed text throughout the draft to allow the possibility of additional as-yet-unagreed-upon signed objects (as opposed to just ROAs). c. Changed text throughout the draft from "distributing" PKI data to "publishing PKI data in/into/at the RPKI distributed repository system" (or similar text). d. Added text throughout the draft to allow the possibility of other routing-related uses of the RPKI data besides route filters. e. 1.3.1 Certification authorities -- Added IANA and rewrote this in attempt to clarify. It now says: The organizations that allocate IP addresses (IANA, RIRs, NIRs, LIRs/ISPs) and AS numbers (IANA, RIRs and NIRs) act as CAs in this PKI. Organizations that hold address space and create and sign objects such as ROAs and manifests also act as CAs in this PKI. Such organizations will include internet number registries, LIRs/ISPs, provider-independent subscribers and some dual-homed subscribers. For each signed object an organization creates, it will issue a corresponding EE certificate that will be used to validate the digital signature on the signed object. (Organizations may issue other types of EE certificates in the future). See [ARCH] for more details. f. 1.3.5 Other Participants -- Now says: Every organization that undertakes a role as a CA in this PKI is responsible for populating the RPKI distributed repository system with the certificates, CRLs, and other signed objects that it issues. The organization can operate its own publication point or outsource this function (See sections 2.1 and 2.2.) g. 1.5.1 Organization administering the document -- Now says: This CP is co-administered by IANA and the five Regional Internet Registries (RIRs), which act as default trust anchors for the PKI: and lists them with their addresses. h. 1.5.2 Contact person -- Now lists general contact info for IANA and the five RIRs. i. The registries (IANA and the 5 RIRs) are now listed in alphabetic order wherever they appear. j. 3.1.1 Types of names -- Addition of IANA whose name will be a "directory distinguished" name. Addition of NIRs to list of organizations whose names "consist of a single CN attribute with a value generated by the issuer." k. 5.6 Key changeover -- Changed text to indicate that "Ideally, the private key that a CA uses to sign a certificate or CRL should have a validity period that is at least as long as that of any certificate being signed. However, since a certificate issued under this PKI will have a validity period that reflects the contractual relationship between the issuer and subject, this may lead to situations where an issued certificate has a validity period longer than that of the key used to sign the certificate." l. 5.8 CA or RA termination -- Changed text to indicate that "If an organization acting as a CA in this PKI terminates operation without identifying a replacement, then the effective control of the IP addresses and AS numbers revert back to the issuing organization, and address space and AS number allocations that have been previously validated via that CA are invalidated as of revocation of the CA's certificate." m. 6.1.4 CA public key delivery to relying parties -- Added IANA to list of entities whose public keys are distributed out of band, i.e., trust anchors. Deleted (RIRs) from the sentence that says "Public key values and associated data for the default trust anchors will be distributed out of band..." n. 6.3.2 Certificate operational periods and key pair usage periods -- Updated as follows to say: IANA holds all IP address and AS number space, i.e., all the resources which form the base of the RPKI hierarchy, Because a self- signed IANA certificate represents this base, it should have a very long life time. Because RIRs and NIRs receive periodic new allocations, it is appropriate for their key pairs and certificates to have lifetimes that match the periodicity of these allocations. However, to minimize disruption, the key pairs should be maintained across certificate changes. LIR/ISP and subscriber certificates typically will have validity periods commensurate with the duration of service agreements. The validity periods will be chosen by the issuing CA and described in its CPS. o. 9. Other Business and Legal Matters - Changed almost all subsections to be "[OMITTED]" because there is no single set of responses that would cover every relevant organization in the RPKI, i.e., each of these organizations will have to specify this information in its CPS or other document. p. 9.12 Amendments -- Changed as follows -- NOTE that this needs to be changed to match Secton 1.5.1. My apologies, I missed this. 9.12.1. Procedure for amendment The procedure for amendments to this CP is via written notice from the Secretary of the NRO. 9.12.2. Notification mechanism and period The NRO will provide one month's notice of a change to this CP. 9.12.3. Circumstances under which OID must be changed [OMITTED] If the Secretary judges that the change(s) will not materially reduce the acceptability of certificates for RPKI purposes, then there will be no change to the CP OID. If the Secretary judges that the change(s) will materially change the acceptability of certificates for RPKI purposes, then there will be a new CP OID. q. References -- Added: [REPOS] Huston, G., Loomans, R., and Michaelson, G., A Profile for Resource Certificate Repository Structure, draft-huston-sidr- repos-struct-01.txt, work in progress. --============_-986313552==_ma============ Content-Type: text/html; charset="us-ascii" Certificate Policy for the RPKI -- new draft submitted
Folks,
We just submitted a revised version of the following I-D:
        Certificate Policy (CP) for the Resource PKI (RPKI)
        draft-ietf-sidr-cp-04.txt

Thanks go to Geoff Huston, Randy Bush, and Tim Christensen for their feedback.  The main changes from the 03 version are listed below (not including date changes, typo corrections and various minor wording changes).  Note that many of them but NOT all were in the non-IETF version distributed to the rescert mailing list in May.  Apologies in advance if I missed any significant changes.

Looking forward to receiving your feedback (and completing this document :-)).
Karen
 

a. Corrected definition of a "bogus" route to include unauthorized advertisement of an unallocated address (not just one that has been allocated)

b. Changed text throughout the draft to allow the possibility of additional as-yet-unagreed-upon signed objects (as opposed to just ROAs).

c. Changed text throughout the draft from "distributing" PKI data to "publishing PKI data in/into/at the RPKI distributed repository system" (or similar text).

d. Added text throughout the draft to allow the possibility of other routing-related uses of the RPKI data besides route filters.

e. 1.3.1 Certification authorities -- Added IANA and rewrote this in attempt to clarify. It now says:

   The organizations that allocate IP addresses (IANA, RIRs, NIRs,
   LIRs/ISPs) and AS numbers (IANA, RIRs and NIRs) act as CAs in this
   PKI. 
   Organizations that hold address space and create and sign objects
   such as ROAs and manifests also act as CAs in this PKI. Such
   organizations will include internet number registries, LIRs/ISPs,
   provider-independent subscribers and some dual-homed subscribers.
   For each signed object an organization creates, it will issue a
   corresponding EE certificate that will be used to validate the
   digital signature on the signed object. (Organizations may issue
   other types of EE certificates in the future). See [ARCH] for more
   details.

f. 1.3.5 Other Participants -- Now says:

   Every organization that undertakes a role as a CA in this PKI is
   responsible for populating the RPKI distributed repository system
   with the certificates, CRLs, and other signed objects that it
   issues. The organization can operate its own publication point or
   outsource this function (See sections 2.1 and 2.2.)

g. 1.5.1 Organization administering the document -- Now says:

   This CP is co-administered by IANA and the five Regional Internet
   Registries (RIRs), which act as default trust anchors for the PKI:

   and lists them with their addresses.

h. 1.5.2 Contact person -- Now lists general contact info for IANA and the five RIRs.

i. The registries (IANA and the 5 RIRs) are now listed in alphabetic order wherever they appear.

j. 3.1.1 Types of names -- Addition of IANA whose name will be a "directory distinguished" name.  Addition of NIRs to list of organizations whose names "consist of a single CN attribute with a value generated by the issuer."

k. 5.6 Key changeover -- Changed text to indicate that "Ideally, the private key that a CA uses to sign a certificate or CRL should have a validity period that is at least as long as that of any certificate being signed.  However, since a certificate issued under this PKI will have a validity period that reflects the contractual relationship between the issuer and subject, this may lead to situations where an issued certificate has a validity period longer than that of the key used to sign the certificate."

l. 5.8 CA or RA termination -- Changed text to indicate that "If an organization acting as a CA in this PKI terminates operation without identifying a replacement, then the effective control of the IP addresses and AS numbers revert back to the issuing organization, and address space and AS number allocations that have been previously validated via that CA are invalidated as of revocation of the CA's certificate."

m. 6.1.4 CA public key delivery to relying parties -- Added IANA to list of entities whose public keys are distributed out of band, i.e., trust anchors. Deleted (RIRs) from the sentence that says "Public key values and associated data for the default trust anchors will be distributed out of band..."

n. 6.3.2 Certificate operational periods and key pair usage periods -- Updated as follows to say:

   IANA holds all IP address and AS number space, i.e., all the
   resources which form the base of the RPKI hierarchy, Because a self-
   signed IANA certificate represents this base, it should have a very
   long life time.  
   Because RIRs and NIRs receive periodic new allocations, it is
   appropriate for their key pairs and certificates to have lifetimes
   that match the periodicity of these allocations.  However, to
   minimize disruption, the key pairs should be maintained across
   certificate changes. 
   LIR/ISP and subscriber certificates typically will have validity
   periods commensurate with the duration of service agreements. The
   validity periods will be chosen by the issuing CA and described in
   its CPS.

o. 9. Other Business and Legal Matters - Changed almost all subsections to be "[OMITTED]" because there is no single set of responses that would cover every relevant organization in the RPKI, i.e., each of these organizations will have to specify this information in its CPS or other document.

p. 9.12 Amendments -- Changed as follows -- NOTE that this needs to be changed to match Secton 1.5.1.  My apologies, I missed this.

   9.12.1. Procedure for amendment

   The procedure for amendments to this CP is via written notice from
   the Secretary of the NRO.
   9.12.2. Notification mechanism and period

   The NRO will provide one month's notice of a change to this CP.

   9.12.3. Circumstances under which OID must be changed [OMITTED]

   If the Secretary judges that the change(s) will not materially
   reduce the  acceptability of certificates for RPKI purposes, then
   there will be no change to the CP OID.  If the Secretary judges that
   the change(s) will materially change the acceptability of
   certificates for RPKI purposes, then there will be a new CP OID.

q. References -- Added:
 
   [REPOS] Huston, G., Loomans, R., and Michaelson, G., A Profile for
       Resource Certificate Repository Structure, draft-huston-sidr-
       repos-struct-01.txt, work in progress.

--============_-986313552==_ma============-- --===============1934639391== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --===============1934639391==-- From sidr-bounces@ietf.org Wed Nov 5 12:40:41 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 610D13A6915; Wed, 5 Nov 2008 12:40:41 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D6193A6A79 for ; Wed, 5 Nov 2008 12:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PCX-B-AdAL9 for ; Wed, 5 Nov 2008 12:40:39 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 3C8513A6842 for ; Wed, 5 Nov 2008 12:40:39 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id mA5KeI19029562 for ; Wed, 5 Nov 2008 14:40:21 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id mA5KeJRR002610 for ; Wed, 5 Nov 2008 14:40:19 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.111]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Nov 2008 15:40:18 -0500 Date: Wed, 5 Nov 2008 15:40:18 -0500 (Eastern Standard Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 05 Nov 2008 20:40:18.0632 (UTC) FILETIME=[B7119480:01C93F86] Subject: [sidr] light agenda? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org I've seen only one suggestion for an agenda item. Hopefully authors of some of the new versions that have been submitted recently will be able to present. I will post an agenda today but I hope to have reason to amend it later. --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Nov 6 11:55:54 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 408A73A6A4D; Thu, 6 Nov 2008 11:55:54 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31A9828C0FB for ; Thu, 6 Nov 2008 11:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDUf7iw9dp6A for ; Thu, 6 Nov 2008 11:55:52 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id E7F323A6A4D for ; Thu, 6 Nov 2008 11:55:51 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id mA6Jt7PO012171 for ; Thu, 6 Nov 2008 13:55:08 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id mA6Jt8AS005900 for ; Thu, 6 Nov 2008 13:55:08 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.191]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 14:55:07 -0500 Date: Thu, 6 Nov 2008 14:55:06 -0500 (Eastern Standard Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 06 Nov 2008 19:55:07.0519 (UTC) FILETIME=[918850F0:01C94049] Subject: [sidr] status of draft-ietf-sidr-res-certs-14 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 26 Oct 2008 08:12:06 +1100, Geoff Huston wrote: >This version (14) incorporates review comments received during the last >call on the document. The section on trust anchors was revised for >clarity with suggestions from Steven kent, but no changes in the >specification of the certificates have been made. Steve Kent's text added to the Trust Anchor section has never been seen by the wg and represents a change from the previous text's representation and handling of trust anchor material. I have therefoere decided that this draft as is can not be passed to the IESG without a SHORT last call for the wg to comment on this change. Because this draft has been through last call twice before, I believe that a last call of one week is all that is required. The last call will end November 13, 2008. To avoid a subsequent last call to approve any changes, all comments suggesting changes in the draft should be made to the list and accompanied by suggested new text. This way, the wg can see and comment on suggested changes so we won't need ANY MORE LAST CALLs on this document. The substantive changed text occurs in Section 6.3. All changes can be seen at http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=http://tools.ietf.org/id/draft-ietf-sidr-res-certs-14.txt --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Nov 6 12:02:50 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBD5928C10C; Thu, 6 Nov 2008 12:02:50 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7B8A3A6A0B for ; Thu, 6 Nov 2008 12:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.924 X-Spam-Level: X-Spam-Status: No, score=-5.924 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NozhraJek14l for ; Thu, 6 Nov 2008 12:02:48 -0800 (PST) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 25C413A6AB1 for ; Thu, 6 Nov 2008 12:01:34 -0800 (PST) Received: from dhcp10.potaroo.net (dhcp10.potaroo.net [203.10.60.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 88A09D5F2D; Fri, 7 Nov 2008 06:00:46 +1000 (EST) Message-Id: From: Geoff Huston To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 7 Nov 2008 07:00:45 +1100 X-Mailer: Apple Mail (2.929.2) Subject: [sidr] draft-ietf-res-certs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG Chair Hat OFF Since Sandy's Last Call on this document there have been a few changes to the document which I should note here. The first set of changes concerns the revision from -13 to -14 (http://smakd.potaroo.net/cgi-bin/htmlwdiff?f1=..%2fall-ids%2fdraft-ietf-sidr-res-certs-14.txt&f2=..%2fall-ids%2fdraft-ietf-sidr-res-certs-13.txt ) Following advice from Steve Kent, the section on Trust Anchors was revised (section 6). The change has concerned the terminology used to described the various structures proposed in the TA model. Other changes include typography, and some clarification regarding the treatment of signed objects and EE certificates with key rollover. The -14 rev of the document was submitted to the drafts repository on the 25th October. I have prepared a -15 rev of the document to address a couple of other concerns that appeared after the draft cut off date. This document is at: http://www.potaroo.net/drafts/draft-ietf-sidr-res-certs-15.txt until the draft submission process reopens in a couple of weeks. The differences are: a) consistent use of OID labels (GeneralNames, accessMethod, accessLocation) throughout the document b) typo referring to id-ad-rpkiManifest c) redraft part of section 3.9.7 old: When an EE certificate is intended for use in verifying multiple objects, EE certificate MUST include in the SIA an access method OID of id-ad-rpkiManifest, where the associated access location refers to the publication point of the objects that are verified using this EE certificate. new: When an EE certificate is intended for use in verifying multiple objects, EE certificate MUST include in the SIA an accessMethod OID of id-ad-rpkiManifest, where the associated accessLocation refers to the EE's published manifest object as an object URL. d) provide a new example certificate in Appendix that conforms to the spec! new: The following is an example Resource Certificate. Certificate Name: 9JfgAEcq7Q-47IwMC5CJIJr6EJs.cer Data: Version: 3 (0x2( Serial: 1500 (0x5dc) Signature Algorithm: SHA256WithRSEEncryption Issuer: CN=APNIC Production-CVPQSgUkLy7pOXdNeVWGvnFX_0s Validity Not Before: Oct 25 12:50:00 2008 GMT Not After : Jan 31 00:00:00 2010 GMT Subject: CN=A91872ED Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:bb:fb:4a:af:a4:b9:dc:d0:fa:6f:67:cc:27:39: 34:d1:80:40:37:de:88:d1:64:a2:f1:b3:fa:c6:7f: bb:51:df:e1:c7:13:92:c3:c8:a2:aa:8c:d1:11:b3: aa:99:c0:ac:54:d3:65:83:c6:13:bf:0d:9f:33:2d: 39:9f:ab:5f:cd:a3:e9:a1:fb:80:7d:1d:d0:2b:48: a5:55:e6:24:1f:06:41:35:1d:00:da:1f:99:85:13: 26:39:24:c5:9a:81:15:98:fb:5f:f9:84:38:e5:d6: 70:ce:5a:02:ca:dd:61:85:b3:43:2d:0b:35:d5:91: 98:9d:da:1e:0f:c2:f6:97:b7:97:3e:e6:fc:c1:c4: 3f:30:c4:81:03:25:99:09:4c:e2:4a:85:e7:46:4b: 60:63:02:43:46:51:4d:ed:fd:a1:06:84:f1:4e:98: 32:da:27:ee:80:82:d4:6b:cf:31:ea:21:af:6f:bd: 70:34:e9:3f:d7:e4:24:cd:b8:e0:0f:8e:80:eb:11: 1f:bc:c5:7e:05:8e:5c:7b:96:26:f8:2c:17:30:7d: 08:9e:a4:72:66:f5:ca:23:2b:f2:ce:54:ec:4d:d9: d9:81:72:80:19:95:57:da:91:00:d9:b1:e8:8c:33: 4a:9d:3c:4a:94:bf:74:4c:30:72:9b:1e:f5:8b:00: 4d:e3 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: F4:97:E0:00:47:2A:ED:0F:B8:EC:8C:0C:0B:90:89: 20:9A:FA:10:9B X509v3 Authority Key Identifier: keyid:09:53:D0:4A:05:24:2F:2E:E9:39:77:4D:79: 55:86:BE:71:57:FF:4B X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE X509v3 CRL Distribution Points: URI:rsync://rpki.apnic.net/repository/A3C38A24 D60311DCAB08F31979BDBE39/CVPQSgUkLy7pOXdNe VWGvnFX_0s.crl Authority Information Access: CA Issuers - URI:rsync://rpki.apnic.net/repos itory/8BDFC7DED5FD11DCB14CF4B1A703F9B7/CVP QSgUkLy7pOXdNeVWGvnFX_0s.cer X509v3 Certificate Policies: critical Policy: 1.3.6.1.5.5.7.14.2 Subject Information Access: CA Repository - URI:rsync://rpki.apnic.net/mem ber_repository/A91872ED/06A83982887911DD81 3F432B2086D636/ Manifest - URI:rsync://rpki.apnic.net/member_r epository/A91872ED/06A83982887911DD813F432 B2086D636/9JfgAEcq7Q-47IwMC5CJIJr6EJs.mft sbgp-autonomousSysNum: critical Autonomous System Numbers: 24021 38610 131072 131074 sbgp-ipAddrBlock: critical IPv4: 203.133.248.0/22 203.147.108.0/23 Signature Algorithm: sha256WithRSAEncryption 51:4c:77:e4:21:64:80:e9:35:30:20:9f:d8:4b:88:60:b8:1f: 73:24:9d:b5:17:60:65:6a:28:cc:43:4b:68:97:ca:76:07:eb: dc:bd:a2:08:3c:8c:56:38:c6:0a:1e:a8:af:f5:b9:42:02:6b: 77:e0:b1:1c:4a:88:e6:6f:b6:17:d3:59:41:d7:a0:62:86:59: 29:79:26:76:34:d1:16:2d:75:05:cb:b2:99:bf:ca:c6:68:1b: b6:a9:b0:f4:43:2e:df:e3:7f:3c:b3:72:1a:99:fa:5d:94:a1: eb:57:9c:9a:2c:87:d6:40:32:c9:ff:a6:54:b8:91:87:fd:90: 55:ef:12:3e:1e:2e:cf:c5:ea:c3:4c:09:62:4f:88:00:a0:7f: cd:67:83:bc:27:e1:74:2c:18:4e:3f:12:1d:ef:29:0f:e3:27: 00:ce:14:eb:f0:01:f0:36:25:a2:33:a8:c6:2f:31:18:22:30: cf:ca:97:43:ed:84:75:53:ab:b7:6c:75:f7:2f:55:5c:2e:82: 0a:be:91:59:bf:c9:06:ef:bb:b4:a2:71:9e:03:b1:25:8e:29: 7a:30:88:66:b4:f2:16:6e:df:ad:78:ff:d3:b2:9c:29:48:e3: be:87:5c:fc:20:2b:df:da:ca:30:58:c3:04:c9:63:72:48:8c: 0a:5f:97:71 Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Nov 6 13:03:46 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4077B3A6A7C; Thu, 6 Nov 2008 13:03:46 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 699D83A6A84 for ; Thu, 6 Nov 2008 13:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNw9zYQeVIc6 for ; Thu, 6 Nov 2008 13:03:44 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 8BB543A6A6D for ; Thu, 6 Nov 2008 13:03:44 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id mA6L3dJL013655; Thu, 6 Nov 2008 15:03:39 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id mA6L3dPH009139; Thu, 6 Nov 2008 15:03:39 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.191]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 16:03:35 -0500 Date: Thu, 6 Nov 2008 16:03:29 -0500 (Eastern Standard Time) From: Sandra Murphy To: Terry Manderson In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 06 Nov 2008 21:03:35.0264 (UTC) FILETIME=[21F07600:01C94053] Cc: sidr@ietf.org Subject: Re: [sidr] am I missing something? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Fri, 24 Oct 2008, Terry Manderson wrote: > I was re-reading draft-ietf-sidr-res-certs-13 to get something clear in my > head about SIA values and I got wildly side-tracked. > > in section 1, it says: > > "In the context of the public Internet, and the use of public number > resources within this context, it is intended that Resource Certificates are > used in a manner that is explicitly aligned to the public number resource > distribution function" > > My impression is that the allocation chain goes IANA->RIR->NIR/LIR->ORG. And > for legacy space there is a IANA->ORG structure. That is the way public > numbers are distributed, yes? > > Wouldn't/Shouldn't there be a request for IANA to sign over "stuff" in the > IANA considerations section? (or have I got the purpose of that section > completely wrong?) One clarification in res-cert-14 (section 1, page 4-5) indicates: While this profile describes the structure of a default Trust Anchor for this PKI, Relying Parties (RPs) in this PKI are free to select the trust anchors upon which they rely, and thus the PKI as viewed by RPs need not match the public resource allocation hierarchy as described here. So while the intent of the RPKI is to mirror the allocation hierarchy, the relying party may select a trust anchor that is not the IANA, so the RPKI mirrors only the allocation relationship of the public resource allocation hierarchy, not necessarily the tree itself with IANA at the apex. There's no requirement that IANA sign anything (or any requirement that any other part of the existing public resource allocation hierarchy sign anything), so there's no need for an IANA considerations section. Does that clear up your question? --Sandy > > Apologies for the newbie-ness of the question. > > Terry > Speaking for Terry, I don't get to speak for anyone else.. and sometimes not > even me! (just don't ask ;) > _______________________________________________ > 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 sidr-bounces@ietf.org Fri Nov 7 12:51:41 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6D3C3A69A4; Fri, 7 Nov 2008 12:51:41 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D092D3A6985 for ; Fri, 7 Nov 2008 12:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.336 X-Spam-Level: X-Spam-Status: No, score=-10.336 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, URI_NOVOWEL=1.62, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdLxKeB-nunY for ; Fri, 7 Nov 2008 12:51:19 -0800 (PST) Received: from host-84-221-169-188.cust-adsl.tiscali.it (host-84-221-169-188.cust-adsl.tiscali.it [84.221.169.188]) by core3.amsl.com (Postfix) with ESMTP id 3F7843A68A6 for ; Fri, 7 Nov 2008 12:51:17 -0800 (PST) To: From: MIME-Version: 1.0 Importance: High Message-Id: <20081107205118.3F7843A68A6@core3.amsl.com> Date: Fri, 7 Nov 2008 12:51:17 -0800 (PST) Subject: [sidr] confirm please X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1411316987==" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org --===============1411316987== Content-Type: text/html
Click Here!
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

?2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
--===============1411316987== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --===============1411316987==-- From sidr-bounces@ietf.org Tue Nov 11 15:33:02 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32ADF3A69C1; Tue, 11 Nov 2008 15:33:02 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D83E3A69C1 for ; Tue, 11 Nov 2008 15:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHH9GlXfqZV7 for ; Tue, 11 Nov 2008 15:33:00 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 86F273A67A3 for ; Tue, 11 Nov 2008 15:33:00 -0800 (PST) Received: from dhcp104.yarralumla.aarnet.edu.au (dhcp104.yarralumla.aarnet.edu.au [192.94.63.104]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id B0FEF110041; Wed, 12 Nov 2008 09:32:59 +1000 (EST) Message-Id: From: Geoff Huston To: Sandra Murphy Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 12 Nov 2008 10:32:57 +1100 X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG Co-Chair hat _OFF_ Sandy, The authors of these two drafts now believe that all SIDR WG comments have been integrated into these documents, and there are no further outstanding comments to be addressed. Accordingly, we would like to request that you conduct a WG Last Call for these documents in order to ensure that the WG is now comfortable with these documents and all comments have been made, and to assess whether the WG is now ready to move these two documents to the IESG for IESG review. regards, Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 11 15:41:21 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7DD3A6AAF; Tue, 11 Nov 2008 15:41:21 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43BD13A6AAF for ; Tue, 11 Nov 2008 15:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghkDlJW5wHit for ; Tue, 11 Nov 2008 15:41:20 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 698603A6A9F for ; Tue, 11 Nov 2008 15:41:20 -0800 (PST) Received: from c-98-201-168-196.hsd1.tx.comcast.net ([98.201.168.196] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L02rE-0000gA-Jx; Tue, 11 Nov 2008 23:41:16 +0000 Message-ID: <491A181B.5000308@psg.com> Date: Tue, 11 Nov 2008 17:41:15 -0600 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Geoff Huston References: In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > The authors of these two drafts now believe that all SIDR WG comments > have been integrated into these documents only withdrawal of the bogons draft would address my comments randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 11 16:38:16 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 031B73A67B2; Tue, 11 Nov 2008 16:38:16 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49D013A67B2 for ; Tue, 11 Nov 2008 16:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DztqUoUKsR5j for ; Tue, 11 Nov 2008 16:38:11 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 087A53A67A3 for ; Tue, 11 Nov 2008 16:38:11 -0800 (PST) Received: from dhcp182.apnic.net (dhcp182.apnic.net [202.12.29.182]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id EA5BA110057; Wed, 12 Nov 2008 10:38:10 +1000 (EST) Message-Id: From: George Michaelson To: Randy Bush In-Reply-To: <491A181B.5000308@psg.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 12 Nov 2008 10:38:10 +1000 References: <491A181B.5000308@psg.com> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 12/11/2008, at 9:41 AM, Randy Bush wrote: >> The authors of these two drafts now believe that all SIDR WG comments >> have been integrated into these documents > > only withdrawal of the bogons draft would address my comments > > randy I believe the BOA draft documents a structure which is going to be very useful in the partial deployment world of the RPKI, especially, partial deployments of origination attestation. Its going to allow relying parties to tell the difference between a bogon, and an as-yet un-attested route object. Thats documented in the validation draft. The BOA is closely modelled on the ROA. Its logical structure, associated certification processes, CMS representation, are all close analogues. I fail to see a structural criticism which is valid, which does not also go to the ROA, which you seem (from other comments) to accept as a useful structure. -George _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 11 16:40:46 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ECA53A67B2; Tue, 11 Nov 2008 16:40:46 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D49773A67B2 for ; Tue, 11 Nov 2008 16:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GCrkVRerIna for ; Tue, 11 Nov 2008 16:40:44 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id D78173A67A3 for ; Tue, 11 Nov 2008 16:40:43 -0800 (PST) Received: from c-98-201-168-196.hsd1.tx.comcast.net ([98.201.168.196] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L03ml-00014t-CY; Wed, 12 Nov 2008 00:40:43 +0000 Message-ID: <491A260A.2010306@psg.com> Date: Tue, 11 Nov 2008 18:40:42 -0600 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: George Michaelson References: <491A181B.5000308@psg.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org George Michaelson wrote: > > On 12/11/2008, at 9:41 AM, Randy Bush wrote: > >>> The authors of these two drafts now believe that all SIDR WG comments >>> have been integrated into these documents >> >> only withdrawal of the bogons draft would address my comments >> >> randy > > I believe the BOA draft documents a structure which is going to be very > useful in the partial deployment world of the RPKI, especially, partial > deployments of origination attestation. > > Its going to allow relying parties to tell the difference between a > bogon, and an as-yet un-attested route object. Thats documented in the > validation draft. > > The BOA is closely modelled on the ROA. Its logical structure, > associated certification processes, CMS representation, are all close > analogues. I fail to see a structural criticism which is valid, which > does not also go to the ROA, which you seem (from other comments) to > accept as a useful structure. i believe you believe all that. this does not alter one iota that the new draft does not address my comment. the security model of the boa is seriously flawed. it mixes a negative model with the existing positive one. this will vastly complicate things and to little utility. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 11 17:02:12 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 134A53A67E6; Tue, 11 Nov 2008 17:02:12 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58B4E3A67E6 for ; Tue, 11 Nov 2008 17:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuUlW0nxojNt for ; Tue, 11 Nov 2008 17:02:10 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 4CAD23A67A4 for ; Tue, 11 Nov 2008 17:02:09 -0800 (PST) Received: from dhcp104.yarralumla.aarnet.edu.au (dhcp104.yarralumla.aarnet.edu.au [192.94.63.104]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id DC59D110057; Wed, 12 Nov 2008 11:02:09 +1000 (EST) Message-Id: <35EE6272-6436-44AA-AF46-55B39A13607A@apnic.net> From: Geoff Huston To: Randy Bush In-Reply-To: <491A260A.2010306@psg.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 12 Nov 2008 12:02:07 +1100 References: <491A181B.5000308@psg.com> <491A260A.2010306@psg.com> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 12/11/2008, at 11:40 AM, Randy Bush wrote: > George Michaelson wrote: >> >> On 12/11/2008, at 9:41 AM, Randy Bush wrote: >> >>>> The authors of these two drafts now believe that all SIDR WG >>>> comments >>>> have been integrated into these documents >>> >>> only withdrawal of the bogons draft would address my comments >>> >>> randy >> >> I believe the BOA draft documents a structure which is going to be >> very >> useful in the partial deployment world of the RPKI, especially, >> partial >> deployments of origination attestation. >> >> Its going to allow relying parties to tell the difference between a >> bogon, and an as-yet un-attested route object. Thats documented in >> the >> validation draft. >> >> The BOA is closely modelled on the ROA. Its logical structure, >> associated certification processes, CMS representation, are all close >> analogues. I fail to see a structural criticism which is valid, which >> does not also go to the ROA, which you seem (from other comments) to >> accept as a useful structure. > > i believe you believe all that. this does not alter one iota that the > new draft does not address my comment. > > the security model of the boa is seriously flawed. it mixes a > negative > model with the existing positive one. this will vastly complicate > things and to little utility. WG Chair hat off So to head away from generalities, what parts of either draft are the issue here? The BOA draft is essentially a mirror of the ROA draft so I assume that the BOA draft is in and of itself. The interpretation and use of the BOA and ROA are described in the ROA Validation draft. What parts of that draft present such vast complications? I would also be interested to learn whether this is a common concern or not and also interested to learn what other meaningful options relying parties have in a world of partial deployment, because, as it stands without BOAs, a world of ROAs and the absence of ROAS is pretty much completely useless in terms of relying parties being able to detect a routing lie. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 11 17:10:34 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 115493A698D; Tue, 11 Nov 2008 17:10:34 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF07A3A698D for ; Tue, 11 Nov 2008 17:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIW2Xsaro7YM for ; Tue, 11 Nov 2008 17:10:32 -0800 (PST) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.225]) by core3.amsl.com (Postfix) with ESMTP id 4E2233A67E6 for ; Tue, 11 Nov 2008 17:10:30 -0800 (PST) Received: by qb-out-0506.google.com with SMTP id e12so2821241qbe.1 for ; Tue, 11 Nov 2008 17:10:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer:sender; bh=QXvH2OdUs7N1uNY8v4adzl6fWl4FD49T2qJTBZDW0iI=; b=oRdA+0TQMrlvNCCH3MAqQRYSUsMZ9PhfUpaz5/pI68Ct9F3AndT4c1TeSHeioULJyO 1+LFXtvLp3rpjeTqZQyd2VEbB/OoYeGxcvU9SA1W0Hcvu4Vwh5wukrW1+fk0F4Y9DNLg mlOj8+4HAQIMtFxA3mf0dG2HdQtGIOcUhYCT4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer:sender; b=sSgH4b8AlGjF1/7AmO/SpNta8sF+W5/T3MH+p86zq35RgJRc41KYSLvRPTOVKXf7J3 G+LmFIcnIFyYuGn7+ZaqrKp1nzSPQeypVXx0tEMpek5+Z335BhhZrkG3cOU2blKgDi1M FQo49F4KNVlP8Q+OIctP68VLLrAqzAs+xYo6c= Received: by 10.142.109.8 with SMTP id h8mr3257775wfc.139.1226452229223; Tue, 11 Nov 2008 17:10:29 -0800 (PST) Received: from ?192.168.1.103? (c58-108-241-164.fitzg1.qld.optusnet.com.au [58.108.241.164]) by mx.google.com with ESMTPS id 9sm15048450wfc.19.2008.11.11.17.10.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 11 Nov 2008 17:10:28 -0800 (PST) Message-Id: <269F5D3F-CD39-41DE-9942-788F60D26924@terrym.net> From: Terry Manderson To: sidr@ietf.org In-Reply-To: <491A260A.2010306@psg.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 12 Nov 2008 11:10:24 +1000 References: <491A181B.5000308@psg.com> <491A260A.2010306@psg.com> X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Hi Randy, On 12/11/2008, at 10:40 AM, Randy Bush wrote: > > the security model of the boa is seriously flawed. it mixes a > negative > model with the existing positive one. this will vastly complicate > things and to little utility. > As I see it the BOA draft introduces and allows for the reality of several shades of routing intent, as exists on the internet today and will also exist in the future, but adds a strong level of predictability. Certainly it does add an additional function that you could argue as complexity - however I see benefits of the BOA as we have cases that don't fall into a singularly positive stance (and logically what is not positive - is negative). Progressing through the world of a partial deployment (thinking that is the only level of deployment we will probably ever see) there are states of, 'must route', 'must not route' and the horrible greyness of local relying party' policy mixed with various resources that compound the corner cases. We know 'must route' is well understood, and using a singularly positive stance that implies everything else is negative or black, or grey-ish as mixed with local policy. Having the BOA provides for the 'must not route', eg reserved resources, unallocated resources, and prefixes that a publishing entity simply does not want routed on the internet (a way to enforce their own policy transcending configuration errors). So even when mixed with local policy it also provides for a clean line of fairly universal and well known bogon behaviours that can't go stale. What it further allows, is the greyness of global anycast prefixes (somewhat known as problem resources in RPKI) like 6to4, and AS23456 (AS-TRANS). Here the prefix can fall nicely into a grey area by not having a ROA, and not having a BOA. The concerns of local policy become much simpler on weather to accept this route or not regardless of who announces the resource. Terry _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Nov 13 20:20:14 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7524C3A67E7; Thu, 13 Nov 2008 20:20:14 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72C663A67E7 for ; Thu, 13 Nov 2008 20:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNAXZ5kwIB2Z for ; Thu, 13 Nov 2008 20:20:11 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 60C533A63D2 for ; Thu, 13 Nov 2008 20:20:11 -0800 (PST) Received: from dhcp154.apnic.net (dhcp154.apnic.net [202.12.29.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id A3A50110061 for ; Fri, 14 Nov 2008 14:20:10 +1000 (EST) Message-Id: <62346107-A330-4B1D-BDA4-1BB460D82817@apnic.net> From: George Michaelson To: sidr@ietf.org In-Reply-To: <491A260A.2010306@psg.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 14 Nov 2008 14:20:10 +1000 References: <491A181B.5000308@psg.com> <491A260A.2010306@psg.com> X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org In looking at the BGP security requirements document, http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-10.txt I find these points (for instance): 4.2. Incremental deployment "Any proposed solution MUST support an incremental deployment which will provide some benefit for those who participate." "In an environment where both secured and non-secured systems are interoperating a mechanism MUST exist for secured systems to identify whether an originator intended the information to be secured." This language is very strong guidance that we need both partial deployment technology, and mechanisms to allow the ORIGINATOR to say if its covered or not. In that sense, a BOA is a strong statement by the prefix owner they intend all more specifics to be covered by explicit security, ie casual more specifics without ROA are being actively dis-allowed. I do not see methods using the ROA alone which can convey this, with the same purpose or precision. The ROA validation draft: http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-validation-01.txt has: 3. Applying Validation Outcomes to BGP Route Selection (second para) In the case of partial deployment of ROAs there are a very limited set of circumstances where the outcome of ROA validation can be used as grounds to reject all consideration of the route object as an invalid advertisement. While the presence of a valid ROA that matches the advertisement is a strong indication that an advertisement matches the authority provided by the prefix holder to advertise the prefix into the routing system, the absence of a ROA or the invalidity of a covering ROA does not provide a conclusive indication that the advertisement has been undertaken without the address holder's permission, unless the object is described in a BOA. I still believe this. I think the BOA substantively adds information into the system about routing security, and I think it is *completely* on- charter for us given the bgpsecrec draft guidance. -G _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Nov 14 02:58:46 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F41A28C0D0; Fri, 14 Nov 2008 02:58:46 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 976273A6A68 for ; Fri, 14 Nov 2008 02:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uhax14RQZT7V for ; Fri, 14 Nov 2008 02:58:43 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by core3.amsl.com (Postfix) with ESMTP id 915E728C0D0 for ; Fri, 14 Nov 2008 02:58:43 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id ADEC86F06A; Fri, 14 Nov 2008 05:45:53 -0500 (EST) Received: from ex.arin.net (ex.arin.net [192.136.136.237]) by smtp1.arin.net (Postfix) with ESMTP id 5687F6F06A; Fri, 14 Nov 2008 05:45:47 -0500 (EST) Received: from EDAMAME.arin.net ([192.136.136.195]) by ex.arin.net ([192.136.136.237]) with mapi; Fri, 14 Nov 2008 05:58:37 -0500 From: Andy Newton To: George Michaelson , "sidr@ietf.org" Date: Fri, 14 Nov 2008 05:58:35 -0500 Thread-Topic: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt Thread-Index: AclGEFYTOIPnFDtzT2iD3n8tUfn3qAAN5qEX Message-ID: In-Reply-To: <62346107-A330-4B1D-BDA4-1BB460D82817@apnic.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org George, I do not follow your argument. Yes, I understand using the BOA to restrict everything and using more specific ROAs to specify valid IP space. What I don't understand is how that helps partial deployment. In fact, doesn't this make necessary full deployment? If a major provider blankets their space with a BOA, then all the downstreams MUST be covered by ROAs. Or did I miss something? And who is to be in the business of publishing trusted BOAs for bogons? Seems to me that it would be fraught with peril if they screw it up. I am not convinced that this is necessary. But then, it is early and the coffee hasn't kicked in. -andy On 11/13/08 11:20 PM, "George Michaelson" wrote: > In looking at the BGP security requirements document, > > http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-10.txt > > I find these points (for instance): > > > 4.2. Incremental deployment > > "Any proposed solution MUST support an incremental > deployment which will provide some benefit for those who > participate." > > "In an environment where both secured and non-secured systems are > interoperating a mechanism MUST exist for secured systems to > identify whether an originator intended the information to be > secured." > > This language is very strong guidance that we need both partial > deployment > technology, and mechanisms to allow the ORIGINATOR to say if its > covered or not. > > In that sense, a BOA is a strong statement by the prefix owner they > intend all > more specifics to be covered by explicit security, ie casual more > specifics without > ROA are being actively dis-allowed. I do not see methods using the ROA > alone which > can convey this, with the same purpose or precision. > > The ROA validation draft: > > http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-validation-01.txt > > has: > > > 3. Applying Validation Outcomes to BGP Route Selection > > (second para) > > In the case of partial deployment of ROAs there are a very limited > set of circumstances where the outcome of ROA validation can be used > as grounds to reject all consideration of the route object as an > invalid advertisement. While the presence of a valid ROA that > matches the advertisement is a strong indication that an > advertisement matches the authority provided by the prefix holder to > advertise the prefix into the routing system, the absence of a ROA or > the invalidity of a covering ROA does not provide a conclusive > indication that the advertisement has been undertaken without the > address holder's permission, unless the object is described in a BOA. > > > I still believe this. I think the BOA substantively adds information > into the > system about routing security, and I think it is *completely* on- > charter for us given > the bgpsecrec draft guidance. > > -G > _______________________________________________ > 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 sidr-bounces@ietf.org Fri Nov 14 12:07:52 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33FF43A6A5A; Fri, 14 Nov 2008 12:07:52 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 723BB3A6945 for ; Fri, 14 Nov 2008 12:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFH57REIGDBm for ; Fri, 14 Nov 2008 12:07:49 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 1F9353A6851 for ; Fri, 14 Nov 2008 12:07:49 -0800 (PST) Received: from dhcp10.potaroo.net (dhcp10.potaroo.net [203.10.60.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 89F94110041; Sat, 15 Nov 2008 06:07:47 +1000 (EST) Message-Id: From: Geoff Huston To: Andy Newton In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 15 Nov 2008 07:07:46 +1100 References: X-Mailer: Apple Mail (2.929.2) Cc: "sidr@ietf.org" Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG Chair hat off On 14/11/2008, at 9:58 PM, Andy Newton wrote: > George, > > I do not follow your argument. Yes, I understand using the BOA to > restrict > everything and using more specific ROAs to specify valid IP space. > What I > don't understand is how that helps partial deployment. In fact, > doesn't > this make necessary full deployment? If a major provider blankets > their > space with a BOA, then all the downstreams MUST be covered by ROAs. > Or did > I miss something? The problem with a model of using only ROAs is that while the presence of a ROA that matches a route advertisement can provide the relying party some level of reassurance that accepting the route matches the intentions of the originator, the absence of a corresponding ROA for a route object tells the relying party absolutely nothing. The only way the absence of a ROA can be interpreted by a relying party is by forcing the relying party to make an assumption about the state of ROA use. One possible answer is that relying parties simply assume that ROAs are universally used and any and every route object that does not match a currently valid ROA is discarded. I trust you would agree that this would be an unwise assumption for a relying party yo make. In a world of incremental deployment where only a few prefix holders are generating ROAs this assumption would effectively cause a relying party to reject all of the (valid) routing table with the exception of the set of objects covered by ROAs. Not good. Even in a world of comprehensive deployment this would be an unwise move. Because prefix holders essentially publish their own signed objects in a repository of their choosing, relying parties, if they wish to avoid using the services of RPKI aggregators or middle-agents will need to access wach and every repository in order to collect the ROAs and the necessary certificate material that is required to validate each ROA. But what if the ROA for a prefix is contained in a repository that is located at an address that is described in the ROA. i.e. you can't get the ROA until you treat the corresponding route object as valid, and you can;t treat it as valid until you have the ROA. The other option is that the relying party assumes that ROAs are not universally deployed, and that implies that a relying party must assume that there exists valid route objects for which there is no corresponding ROA. In a world of partial deployment where a relying party has no idea whether the absence of a ROA indicates an attempted routing hijack of the simple absence of a ROA, then the relying party really is no better off than if there were no ROAs whatsoever! So how could this situation be improved for relying parties? A good example for me in thinking about this has been the YouTube hijack at the start of this year. A salient question I asked myslef was: what mechanisms could YouTube have used to alert relying parties to the unauthorised advertisement of more specifics from a different origin AS? ROAs alone are not a good answer here, in that a ROA does not say what is bogus. The only way that ROAs can do this is when a relying party is justified in assuming that _absolutely everything_ is covered by a ROA. In a world of incremental deployment this assumption does not hold, and therefore the absence of a ROA conveys no information at all. In this case BOAs can assist. Lets say that MeTube has published a ROA to allow 10.1.0.0/16, max length=16 to be advertised from origin AS 1, and a relying party sees an advertisement for 10.1.1.0/24 originating from AS 2 (a hijack attempt). In this case the relying party has no grounds to assume that the /24 advertisement is bogus, and will accept the advertisement and the hijack will be effective. But what if MeTube also published a BOA for 10.1.0.0/16 at the same time as the ROA. Now as a ROA "trumps" a BOA then any advertisement for 10.1.0.0/16 with an origination of AS 1 will be regarded as valid by a relying party, while any other use of 10.1.0.0/16 or any more specific will be regarded as bogus. So, as far as I can tell, BOAs are a simple and effective mechanism to allow relying parties to detect attempts at origination hijack even in a world of partial use of origination attestations - i.e. they meet the criteria of the RPSEC document relating to incremental deployment, as referenced in George's message, without relying on comprehensive ROA deployment. Andy, your example is somewhat different, because you posit the existence of some intermediate IR that has issued portable address space to clients of the service and allows the clients of this space to independently announce their address space. In this example your comment was that if the IR blankets the space with a BOA then that forces the clients to use ROAs to have their independent routes treated as valid, if I have got this right. Yes, that would be the case, and if the IR did not want that outcome then the IR should not issue a BOA in the first place. On the other hand if the IR, being a major provider, had a policy that all space allocated by the IR was NOT portable address space, then the BOA would be a means to announce that provider-dependent routing policy to all others in the inter- domain routing cloud. What I don't see in this example is the leap from this case to the conclusion that the potential for prefix holder to publish BOAs necessarily implies that prefix holders are _all_ forced to publish ROAS, i.e. I don't see how you get to the assertion that "this make[s] necessary full deployment" (Where I interpret "full deployment" as the situation each and every prefix holder that authorizes routes in to the inter-domain routing space is required to publish a ROA.) > > And who is to be in the business of publishing trusted BOAs for > bogons? > Seems to me that it would be fraught with peril if they screw it up. > Only the certified holder of an address block can generate a BOA. So I suppose the answer to your question would depend on your preferred interpretation of what is a "bogon". > But then, it is early and the > coffee hasn't kicked in. > ditto. Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Nov 14 13:37:15 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18343A6A06; Fri, 14 Nov 2008 13:37:15 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D6363A69DD for ; Fri, 14 Nov 2008 13:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mjlr5dsqiGpg for ; Fri, 14 Nov 2008 13:37:14 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 96DA83A68EC for ; Fri, 14 Nov 2008 13:37:14 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id mAELbD92003694 for ; Fri, 14 Nov 2008 15:37:13 -0600 Received: from cronus.sandiego.ads.sparta.com ([157.185.24.3]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id mAELbE2w006051 for ; Fri, 14 Nov 2008 15:37:14 -0600 Received: from nemo.columbia.ads.sparta.com ([157.185.80.75]) by cronus.sandiego.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Nov 2008 13:37:13 -0800 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.160]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Nov 2008 16:37:11 -0500 Date: Fri, 14 Nov 2008 16:37:13 -0500 (Eastern Standard Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 14 Nov 2008 21:37:11.0894 (UTC) FILETIME=[273FC760:01C946A1] Subject: [sidr] new agenda X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org There have been a few requests for agenda slots, both to discuss updates to existing drafts and to discuss new drafts. I've been generous with time for the presentations, so if there are any other requests for agenda slots, they can be accommodated. Many of the drafts are mature and approaching last call. So please come and pay attention, as later may be too late. --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Nov 16 10:23:12 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 821AF3A6AAA; Sun, 16 Nov 2008 10:23:12 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B79583A6AAA for ; Sun, 16 Nov 2008 10:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7wb-rh6S182 for ; Sun, 16 Nov 2008 10:23:11 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by core3.amsl.com (Postfix) with ESMTP id C839D3A6AA9 for ; Sun, 16 Nov 2008 10:23:10 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id 2156CA6876; Sun, 16 Nov 2008 13:23:10 -0500 (EST) Received: from ex.arin.net (ex.arin.net [192.136.136.237]) by smtp2.arin.net (Postfix) with ESMTP id 5385FA6876; Sun, 16 Nov 2008 13:23:09 -0500 (EST) Received: from EDAMAME.arin.net ([192.136.136.195]) by ex.arin.net ([192.136.136.237]) with mapi; Sun, 16 Nov 2008 13:23:09 -0500 From: Andy Newton To: Geoff Huston Date: Sun, 16 Nov 2008 13:23:06 -0500 Thread-Topic: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt Thread-Index: AclGmBGEA4DfyX/FQZCgwoU/YxmjMwBgE0SW Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 11/14/08 3:07 PM, "Geoff Huston" wrote: > WG Chair hat off Minneapolis hat soon to be on! Brrrrrr..... > > One possible answer is that relying parties simply assume that ROAs > are universally used and any and every route object that does not > match a currently valid ROA is discarded. I trust you would agree that > this would be an unwise assumption for a relying party yo make. In a > world of incremental deployment where only a few prefix holders are > generating ROAs this assumption would effectively cause a relying > party to reject all of the (valid) routing table with the exception of > the set of objects covered by ROAs. Not good. Even in a world of > comprehensive deployment this would be an unwise move. Because prefix > holders essentially publish their own signed objects in a repository > of their choosing, relying parties, if they wish to avoid using the > services of RPKI aggregators or middle-agents will need to access wach > and every repository in order to collect the ROAs and the necessary > certificate material that is required to validate each ROA. But what > if the ROA for a prefix is contained in a repository that is located > at an address that is described in the ROA. i.e. you can't get the ROA > until you treat the corresponding route object as valid, and you can;t > treat it as valid until you have the ROA. > > The other option is that the relying party assumes that ROAs are not > universally deployed, and that implies that a relying party must > assume that there exists valid route objects for which there is no > corresponding ROA. In a world of partial deployment where a relying > party has no idea whether the absence of a ROA indicates an attempted > routing hijack of the simple absence of a ROA, then the relying party > really is no better off than if there were no ROAs whatsoever! This reminds me of the +all/-all,~all SPF wars, where die-hards insisted on -all but nearly everybody did ~all. There are likely to be 3 types of route objects: - those covered by ROAs - those covered by BOAs (and perhaps a wider BOA) - those covered by neither Given that incremental deployment means the Internet will start out with route objects covered by neither, policy will have to determine what to do when a route object is not covered by a ROA (the bad situation you mention above). BOAs do not get us out of this. >> And who is to be in the business of publishing trusted BOAs for >> bogons? >> Seems to me that it would be fraught with peril if they screw it up. >> > > Only the certified holder of an address block can generate a BOA. So I > suppose the answer to your question would depend on your preferred > interpretation of what is a "bogon". Clear as mud! But this just re-enforces what I just said. There will be route objects not covered by either a BOA or a ROA. That being said, I'm not gonna fall on my sword over this. In the end, BOAs may likely end up like SPF -all, ignored. -andy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Nov 16 10:32:49 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0036D3A6905; Sun, 16 Nov 2008 10:32:49 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DF263A6905 for ; Sun, 16 Nov 2008 10:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjOL18g+TDSQ for ; Sun, 16 Nov 2008 10:32:47 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 6285F3A68BC for ; Sun, 16 Nov 2008 10:32:47 -0800 (PST) Received: from [130.129.95.247] (helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L1mQI-000DgK-C2; Sun, 16 Nov 2008 18:32:38 +0000 Message-ID: <49206745.3030506@psg.com> Date: Sun, 16 Nov 2008 12:32:37 -0600 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Andy Newton References: In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: "sidr@ietf.org" Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > There are likely to be 3 types of route objects: > - those covered by ROAs > - those covered by BOAs (and perhaps a wider BOA) > - those covered by neither and the more painful case, when they are covered by both. iana issues a boa for 0/0 i announce 0/0 to a bunch of my downstreams in case any of them do validation, i have to issue a roa for 0/0 where do i publish it? randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Nov 16 10:50:48 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6BA13A6AB3; Sun, 16 Nov 2008 10:50:48 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 086C63A6AA4 for ; Sun, 16 Nov 2008 10:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKbUYilgEquL for ; Sun, 16 Nov 2008 10:50:46 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 283943A6997 for ; Sun, 16 Nov 2008 10:50:46 -0800 (PST) Received: from dhcp10.potaroo.net (dhcp10.potaroo.net [203.10.60.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id C5E79110041; Mon, 17 Nov 2008 04:50:44 +1000 (EST) Message-Id: From: Geoff Huston To: Andy Newton In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 17 Nov 2008 05:50:44 +1100 References: X-Mailer: Apple Mail (2.929.2) Cc: "sidr@ietf.org" Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG Chair hat off On 17/11/2008, at 5:23 AM, Andy Newton wrote: > > Given that incremental deployment means the Internet will start out > with > route objects covered by neither, policy will have to determine what > to do > when a route object is not covered by a ROA (the bad situation you > mention > above). BOAs do not get us out of this. > You may want to read through draft-ietf-sidr-roa-validation. The draft has details of this - section 2 of the document goes through the case. >>> And who is to be in the business of publishing trusted BOAs for >>> bogons? >>> Seems to me that it would be fraught with peril if they screw it up. >>> >> >> Only the certified holder of an address block can generate a BOA. >> So I >> suppose the answer to your question would depend on your preferred >> interpretation of what is a "bogon". > > Clear as mud! But this just re-enforces what I just said. There > will be > route objects not covered by either a BOA or a ROA. > of course - but the objective here is incremental capabilities that increase the levels of assurance that is available to relying parties to allow them to make reasonable decisions about what they can reject and how they can apply relative preference to route objects. Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Nov 16 10:53:42 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 127073A6ABF; Sun, 16 Nov 2008 10:53:42 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91C983A6AB4 for ; Sun, 16 Nov 2008 10:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FblVm-SuWBwu for ; Sun, 16 Nov 2008 10:53:39 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id BF8923A6AB3 for ; Sun, 16 Nov 2008 10:53:39 -0800 (PST) Received: from dhcp10.potaroo.net (dhcp10.potaroo.net [203.10.60.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 1E27B110041; Mon, 17 Nov 2008 04:53:39 +1000 (EST) Message-Id: <2EEA5463-910B-4DD9-9981-7E9C827BCE7C@apnic.net> From: Geoff Huston To: sidr@ietf.org In-Reply-To: <49206745.3030506@psg.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 17 Nov 2008 05:53:38 +1100 References: <49206745.3030506@psg.com> X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG Chair hat off On 17/11/2008, at 5:32 AM, Randy Bush wrote: >> There are likely to be 3 types of route objects: >> - those covered by ROAs >> - those covered by BOAs (and perhaps a wider BOA) >> - those covered by neither > > and the more painful case, when they are covered by both. > > iana issues a boa for 0/0 This appears to be a very fanciful notion to me. > > > i announce 0/0 to a bunch of my downstreams > > in case any of them do validation, i have to issue a roa for 0/0 > > where do i publish it? wherever you want - assuming that some relying party has chosen to use the certificate you issue as a TA. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Nov 16 11:49:39 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE38C3A68EB; Sun, 16 Nov 2008 11:49:39 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6F1A3A68EB for ; Sun, 16 Nov 2008 11:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZxTzE6OLv7V for ; Sun, 16 Nov 2008 11:49:33 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 26EA83A67AA for ; Sun, 16 Nov 2008 11:49:33 -0800 (PST) Received: from [130.129.95.247] (helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L1nce-000Dn3-Oe; Sun, 16 Nov 2008 19:49:28 +0000 Message-ID: <49207948.90800@psg.com> Date: Sun, 16 Nov 2008 13:49:28 -0600 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Geoff Huston References: <49206745.3030506@psg.com> <2EEA5463-910B-4DD9-9981-7E9C827BCE7C@apnic.net> In-Reply-To: <2EEA5463-910B-4DD9-9981-7E9C827BCE7C@apnic.net> X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org >> iana issues a boa for 0/0 > This appears to be a very fanciful notion to me. it was iana's first intent, and, from an ops pov, dead obvious. see rfc 3330. >> i announce 0/0 to a bunch of my downstreams >> in case any of them do validation, i have to issue a roa for 0/0 >> where do i publish it? > wherever you want - assuming that some relying party has chosen to use > the certificate you issue as a TA. i just don't think i want to be authoritative for 0/0. and i do not think we want a hundred or two roas for 0/0 in the public rpki. boas are not a path that is prudent to follow. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Nov 16 12:14:13 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDB003A698C; Sun, 16 Nov 2008 12:14:13 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A6FF3A698C for ; Sun, 16 Nov 2008 12:14:12 -0800 (PST) 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=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRiVDz5lAM5q for ; Sun, 16 Nov 2008 12:14:11 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 9E6263A6918 for ; Sun, 16 Nov 2008 12:14:11 -0800 (PST) Received: from dhcp10.potaroo.net (dhcp10.potaroo.net [203.10.60.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id D21E0110041 for ; Mon, 17 Nov 2008 06:14:10 +1000 (EST) Message-Id: From: Geoff Huston To: sidr@ietf.org In-Reply-To: <49207948.90800@psg.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 17 Nov 2008 07:14:10 +1100 References: <49206745.3030506@psg.com> <2EEA5463-910B-4DD9-9981-7E9C827BCE7C@apnic.net> <49207948.90800@psg.com> X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG Chair Hat OFF On 17/11/2008, at 6:49 AM, Randy Bush wrote: >>> iana issues a boa for 0/0 >> This appears to be a very fanciful notion to me. > > it was iana's first intent, and, from an ops pov, dead obvious. see > rfc > 3330. > Either your copy of RFC3330 is different from my copy of RFC3330, or you are putting an interpretation on the white spaces in that document that entirely unobvious and opaque to me. I can't see IANA claiming in RFC3330 that 0/0 is a bogon. Do you want me to send you my copy of RFC3330 to check that we are referring to the same document here? >>> i announce 0/0 to a bunch of my downstreams >>> in case any of them do validation, i have to issue a roa for 0/0 >>> where do i publish it? >> wherever you want - assuming that some relying party has chosen to >> use >> the certificate you issue as a TA. > > i just don't think i want to be authoritative for 0/0. the choice of TAs is a relying party choice - You can do whatever you want and unless I am prepared to nominate your assertions as something I, as a relying party, am prepared to trust, then whatever you chose to do is your problem. > and i do not > think we want a hundred or two roas for 0/0 in the public rpki. I think you may have a basic misunderstanding of the trust model for this PKI - your use of the term "in the public RPKI" conjoined with "a hundred or two roas for 0/0" is a somewhat fanciful conjunction, unless of course you are advocating that relying parties use a universal acceptance policy for nominated TAs, in which case the entire concept of a "public RPKI" is a complete waste of time. > > > boas are not a path that is prudent to follow. > So you are claiming. Others have different views and have backed them up with documents and reasoning to support their views. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Nov 16 15:28:26 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A05253A693A; Sun, 16 Nov 2008 15:28:26 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 184893A693A for ; Sun, 16 Nov 2008 15:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.633 X-Spam-Level: X-Spam-Status: No, score=-0.633 tagged_above=-999 required=5 tests=[AWL=0.484, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7fyg-vXbeUN for ; Sun, 16 Nov 2008 15:28:25 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 4FD3E3A6358 for ; Sun, 16 Nov 2008 15:28:25 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 0B97E26866A; Sun, 16 Nov 2008 16:28:25 -0700 (MST) Received: from [130.129.31.72] (northu.arbor.net [204.181.64.60]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sun, 16 Nov 2008 16:28:24 -0700 (MST) (envelope-from danny@tcb.net) Message-Id: From: Danny McPherson To: Geoff Huston In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 16 Nov 2008 16:28:09 -0700 References: X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Nov 14, 2008, at 1:07 PM, Geoff Huston wrote: > > A good example for me in thinking about this has been the YouTube > hijack at the start of this year. A salient question I asked myslef > was: what mechanisms could YouTube have used to alert relying > parties to the unauthorised advertisement of more specifics from a > different origin AS? > > ROAs alone are not a good answer here, in that a ROA does not say > what is bogus. But does the existence of a ROA, with origin authorization not make this implicit enough? > The only way that ROAs can do this is when a relying party is > justified in assuming that _absolutely everything_ is covered by a > ROA. In a world of incremental deployment this assumption does not > hold, and therefore the absence of a ROA conveys no information at > all. > > In this case BOAs can assist. Lets say that MeTube has published a > ROA to allow 10.1.0.0/16, max length=16 to be advertised from origin > AS 1, and a relying party sees an advertisement for 10.1.1.0/24 > originating from AS 2 (a hijack attempt). In this case the relying > party has no grounds to assume that the /24 advertisement is bogus, > and will accept the advertisement and the hijack will be effective. > But what if MeTube also published a BOA for 10.1.0.0/16 at the same > time as the ROA. Now as a ROA "trumps" a BOA then any advertisement > for 10.1.0.0/16 with an origination of AS 1 will be regarded as > valid by a relying party, while any other use of 10.1.0.0/16 or any > more specific will be regarded as bogus. So wouldn't this mean that in the current model everyone would publish ROAs and BOAs? Do we really want that? Perhaps I'm missing something here? -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Nov 16 16:25:47 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 648AF3A67AA; Sun, 16 Nov 2008 16:25:47 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC0CD3A67AA for ; Sun, 16 Nov 2008 16:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZvTbrw6BB61 for ; Sun, 16 Nov 2008 16:25:44 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 28E4B3A6405 for ; Sun, 16 Nov 2008 16:25:43 -0800 (PST) Received: from dhcp104.yarralumla.aarnet.edu.au (dhcp104.yarralumla.aarnet.edu.au [192.94.63.104]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id C75EC110041; Mon, 17 Nov 2008 10:25:41 +1000 (EST) Message-Id: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> From: Geoff Huston To: Danny McPherson In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 17 Nov 2008 11:25:40 +1100 References: X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG chair hat off On 17/11/2008, at 10:28 AM, Danny McPherson wrote: > > On Nov 14, 2008, at 1:07 PM, Geoff Huston wrote: >> >> A good example for me in thinking about this has been the YouTube >> hijack at the start of this year. A salient question I asked myslef >> was: what mechanisms could YouTube have used to alert relying >> parties to the unauthorised advertisement of more specifics from a >> different origin AS? >> >> ROAs alone are not a good answer here, in that a ROA does not say >> what is bogus. > > But does the existence of a ROA, with origin authorization not > make this implicit enough? I assume you are referring to the situation where, for example, a ROA exists for 10.1.0.0/16 origin AS 1, and NO ROA exists for 10.1.0.0/16 origin AS2, and you are seeing a route object for 10.1.0.0/16 with origin AS 2, yes? The problem is that as a relying party you can't tell whether the problem is with the retrieval of ROA objects or whether the route object is bogus. i.e. what if the ROA for 10.1.0.0/16 origin AS 2 was published a few seconds ago, whereas your local cache of ROA objects was last refreshed a day ago. i.e. everything you have at hand is valid, the manifests are good, and you are seeing something that is not oin a locally held ROA, _but_ it is still valid. If there was also a BOA published for 10.1.0.0/16 then as a relying party you now have grounds to believe that anything not described in a valid ROA can be regarded as an invalid object. In this case there is still the issue of time lag, and if the prefix holder had intended to authorize 10.1.0.0/16 using AS 2 as an origination in addition to AS1 then it would be incumbent on the prefix holder to generate and publish the new ROA well in advance of the advertisement of the new route. Of course there is also the other case where AS 1 insists on a ROA as a precondition for originating the route, and AS 2 does not, and the prefix holder performs only what is required and no more. In this case both routes are valid, but only one as a ROA. In tis case the problem is not one of timing at the relying party side, and will not be resolved by bring the relying party into sync with the authority publisher. > > >> The only way that ROAs can do this is when a relying party is >> justified in assuming that _absolutely everything_ is covered by a >> ROA. In a world of incremental deployment this assumption does not >> hold, and therefore the absence of a ROA conveys no information at >> all. >> >> In this case BOAs can assist. Lets say that MeTube has published a >> ROA to allow 10.1.0.0/16, max length=16 to be advertised from >> origin AS 1, and a relying party sees an advertisement for >> 10.1.1.0/24 originating from AS 2 (a hijack attempt). In this case >> the relying party has no grounds to assume that the /24 >> advertisement is bogus, and will accept the advertisement and the >> hijack will be effective. But what if MeTube also published a BOA >> for 10.1.0.0/16 at the same time as the ROA. Now as a ROA "trumps" >> a BOA then any advertisement for 10.1.0.0/16 with an origination of >> AS 1 will be regarded as valid by a relying party, while any other >> use of 10.1.0.0/16 or any more specific will be regarded as bogus. > > So wouldn't this mean that in the current model everyone would publish > ROAs and BOAs? Do we really want that? Perhaps I'm missing something > here? > Well if relying parties could safely assume that _everyone_ was publishing ROAs then there would be no need for BOAs as the absence of a positive authority in the form of a ROA could be reliably inferred to be unauthorized. But in a world where that assumption does not hold, and where there is incremental partial deployment of publication of these origination credentials, when relying parties cannot assume that the absence of a positive authority means anything at all. All it means is that if the route object matches the ROA then its been authorized by the prefix holder. But if there is no matching ROA then the relying party cannot assume anything at all. The problem here is similar to the problem of filter generation: There is a qualitative difference in these two statements: "I give my authority for AS 1 to advertise a route object for 10.1.0.0/16" "I give my authority for AS1 and only AS1 to advertise a route object for 10.1.0.0/16" If you want the second statement, then we either need to change the ROA to offer closure ("i.e. include "any only") or introduce a new object that allows the authorizing party to state the "and only" part explicitly). I contend that leaving this part of the authority as something implicit that relying parties may or may not choose to infer from the authority is a compromised model, imho. So the BOA is a way of implementing the RPSEC requirement of being able to support environments of incremental deployment, where it is not assured that everyone is publishing these authorities. Now if you are of the view that the requirement of devising mechanisms to support incremental piecemeal deployment is daft or unnecessary, then perhaps this is a debate that in the IETF context should be held in the context of the RPSEC WG, as the SIDR requirement here is one that was gather up from the earlier RPSEC work and generate mechanisms that met those requirements as stated in the RPSEC documents. regards, Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Nov 16 20:44:15 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BDBA3A67E7; Sun, 16 Nov 2008 20:44:15 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 096973A67E7 for ; Sun, 16 Nov 2008 20:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.683 X-Spam-Level: X-Spam-Status: No, score=-0.683 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2Q8zoYX62IR for ; Sun, 16 Nov 2008 20:44:13 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 4BAC33A63D2 for ; Sun, 16 Nov 2008 20:44:13 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 2F7BB26866A; Sun, 16 Nov 2008 21:44:13 -0700 (MST) Received: from [192.168.248.244] (northu.arbor.net [204.181.64.60]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sun, 16 Nov 2008 21:44:12 -0700 (MST) (envelope-from danny@tcb.net) Message-Id: <32C36BBA-B660-4875-B199-74391652B5FB@tcb.net> From: Danny McPherson To: Sandra Murphy In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 16 Nov 2008 21:43:57 -0700 References: X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] am I missing something? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Nov 6, 2008, at 2:03 PM, Sandra Murphy wrote: > > One clarification in res-cert-14 (section 1, page 4-5) indicates: > > > While this profile describes the structure of a default Trust Anchor > for this PKI, Relying Parties (RPs) in this PKI are free to select > the trust anchors upon which they rely, and thus the PKI as viewed > by > RPs need not match the public resource allocation hierarchy as > described here. > > So while the intent of the RPKI is to mirror the allocation hierarchy, Is it? > the relying party may select a trust anchor that is not the IANA, so > the RPKI mirrors only the allocation relationship of the public > resource allocation hierarchy, not necessarily the tree itself with > IANA at the apex. > > There's no requirement that IANA sign anything (or any requirement > that any other part of the existing public resource allocation > hierarchy sign anything), so there's no need for an IANA > considerations section. > > Does that clear up your question? This discussion, and that of BOAs et al. have me wondering if we shouldn't be talking more about where that apex falls, and if it's one or six, and the implications of all these things, as they're sure to have considerable impact on operational and deployability work we do here. I believe there are indeed considerable IANA implications in this discussion and this is something that needs to be well understood when architecting solutions in this area. With that, I'm quite interested in understanding any perspectives folks are willing to provide. Thanks! -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Nov 16 23:00:28 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 854763A682A; Sun, 16 Nov 2008 23:00:28 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAA863A67FA for ; Sun, 16 Nov 2008 23:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYUWMJjUnjqN for ; Sun, 16 Nov 2008 23:00:25 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 26F673A682A for ; Sun, 16 Nov 2008 23:00:25 -0800 (PST) Received: from [130.129.79.176] (helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L1y5q-000FSI-GL; Mon, 17 Nov 2008 07:00:18 +0000 Message-ID: <49211681.9020803@psg.com> Date: Mon, 17 Nov 2008 01:00:17 -0600 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Danny McPherson References: <32C36BBA-B660-4875-B199-74391652B5FB@tcb.net> In-Reply-To: <32C36BBA-B660-4875-B199-74391652B5FB@tcb.net> X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] am I missing something? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > I believe there are indeed considerable IANA implications in this > discussion and this is something that needs to be well understood > when architecting solutions in this area. perhaps, given the origin of the document, an iana hating section would be more expected. there are only two parties with authority to say publicly what is or is not route-able, the iana, who owns all the special kink, and the public holder of the space in question. this seems trivially obvious. in addition, if there are private routing domains, then there are likely to be corresponding trust systems. as these exceptions will have to be manually configured, the anathema of the wise operator, it would seem prudent to minimize their occurrence. > With that, I'm quite interested in understanding any perspectives > folks are willing to provide. the iana is the root of the allocation tree. hence it should be the root of rpki trust. this is also trivially obvious. it is just not acceptable to some folk who focus on power as opposed to technology. i assume they will not be getting their next /8 from the iana. but pig wrestling is futile and boring. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 17 00:15:05 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56E5A3A6991; Mon, 17 Nov 2008 00:15:05 -0800 (PST) X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 02FAF3A6886; Mon, 17 Nov 2008 00:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081117081502.02FAF3A6886@core3.amsl.com> Date: Mon, 17 Nov 2008 00:15:01 -0800 (PST) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-res-certs-15.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Profile for X.509 PKIX Resource Certificates Author(s) : G. Huston, et al. Filename : draft-ietf-sidr-res-certs-15.txt Pages : 44 Date : 2008-11-17 This document defines a standard profile for X.509 certificates for the purposes of supporting validation of assertions of "right-of-use" of an Internet Number Resource (IP Addresses and Autonomous System Numbers). This profile is used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of- use" of the IP addresses and AS numbers that are described in the issued certificate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-res-certs-15.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-res-certs-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-17001107.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Mon Nov 17 08:28:40 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C71773A6A22; Mon, 17 Nov 2008 08:28:40 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D194F3A6A22 for ; Mon, 17 Nov 2008 08:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2lBpv8GQ5b7 for ; Mon, 17 Nov 2008 08:28:39 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id DF6CE3A69C5 for ; Mon, 17 Nov 2008 08:28:38 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.2) with ESMTP id mAHGSbx9090477 for ; Mon, 17 Nov 2008 11:28:37 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.2/Submit) with ESMTP id mAHGSbJ2090474 for ; Mon, 17 Nov 2008 11:28:37 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 17 Nov 2008 11:28:37 -0500 (EST) From: Samuel Weiler To: sidr@ietf.org Message-ID: User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (fledge.watson.org [127.0.0.1]); Mon, 17 Nov 2008 11:28:37 -0500 (EST) Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org draft-ietf-sidr-bogons-02 contains a number of things that are either inconsistent or where I found it difficult to determine the intent. While some examples are discussed below and can be addressed piecemeal, I think it would be more effective to address them through a comprehensive re-editting of the document, looking to simplify the language and make it significantly more readable. Accordingly, I do not think this document is ready for WGLC. Item 1: May BOAs be issued only by RIRs or also by entities further down the heirarchy? From section 1: "This document defines an application of the Resource Public Key Infrastructure (RPKI) to validate the attestations of INTERNET REGISTERIES that certain addresses are currently neither allocated nor assigned to any party,..." (emphasis added) Yet section 4 says: "ANY PARTY with a validly assigned Internet resource set and a CA certificate that describes this delegation can publish a BOA, independently of the actions of the actions of the party that assigned the resource set." (emphasis added) Item 2: Why must a BOA contain both ASNs and addresses? Section 2.1.3.2: "The content of a BOA identifies a list of one or more AS's and one or more IP address prefixes..." Item 3: Reading the document the first time, I was very confused by section 5, in part because the second paragraph, which talks about AS's, and the third paragraph, which talks about addresses, looked so similar. Just to help the reader, I suggest adding two subsections, one referring to AS's, the other to addresses or prefixes. Perhaps add a sentence referring to the differences (e.g., that AS's listed in a BOA may be regarded as bogons even if ROAs list those ASs, but ROAs take precendence over BOAs when it comes to addresses.) Furthermore, I'm not sure the addresses section (the third paragraph) is complete. When a BOA referes to an address block that's more specific than one in the ROA, which takes precedence? (It looks like the ROA, but I got lost somewhere in the six-line sentence.) In general, I found this document harder to read than most i-d's, and I suspect part of it is due to the terminology. I hope the editors will look for ways to improved the terminology, substituting shorter names when possible. At the very least, change the name of BOAs so that there's more visual difference from "ROA". While not technically substantive, such readability improvements may make it easier for others to review the document. And given the confusions above, I think more review is sorely needed. -- Sam _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 17 11:00:03 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A1D03A696D; Mon, 17 Nov 2008 11:00:03 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56DC43A696D for ; Mon, 17 Nov 2008 11:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 484yqgX8xNcT for ; Mon, 17 Nov 2008 11:00:01 -0800 (PST) Received: from davinci.fing.edu.uy (davinci.fing.edu.uy [164.73.32.2]) by core3.amsl.com (Postfix) with ESMTP id CF0A83A689E for ; Mon, 17 Nov 2008 11:00:00 -0800 (PST) Received: from [130.129.95.209] ([130.129.95.209]) (authenticated bits=0) by davinci.fing.edu.uy with ESMTP id mAHIxecM024332 for ; Mon, 17 Nov 2008 16:59:45 -0200 (UYST) Message-Id: From: Roque Gagliano To: sidr@ietf.org In-Reply-To: <20081103214501.5D4FF28C26A@core3.amsl.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 17 Nov 2008 12:59:26 -0600 References: <20081103214501.5D4FF28C26A@core3.amsl.com> X-Pgp-Agent: GPGMail d51 (Leopard) X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (davinci.fing.edu.uy [164.73.32.2]); Mon, 17 Nov 2008 16:59:46 -0200 (UYST) X-Scanned-By: MIMEDefang 2.63 on 164.73.32.2 Subject: Re: [sidr] I-D Action:draft-ietf-sidr-arch-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0378833341==" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0378833341== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-90--466936869" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-90--466936869 Content-Type: multipart/alternative; boundary=Apple-Mail-89--466936917 --Apple-Mail-89--466936917 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, Some comments: 1) Section 2.5: I believe we should remove the reference to DNSSEC root key signing in section 2.5, different scenario here and there. 2) Section 2.6: I would like that the last paragraph from section 2.5 be included in this section, because de "various registry" space is the "ERX space". Also, In the figure 1, I know it is just an example but LACNIC only has ERX space from /8 where ARIN and APNIC are majority, so just to keep it "real" I will suggest replacing RIPE by APNIC. 3) Trust Anchor Material. I believe we agreed to include the description of the trust anchor material in the arch document, I cant find it here. Is it though for a new revision? Regards, r. On Nov 3, 2008, at 3:45 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Secure Inter-Domain Routing Working > Group of the IETF. > > > Title : An Infrastructure to Support Secure Internet > Routing > Author(s) : M. Lepinski, S. Kent > Filename : draft-ietf-sidr-arch-04.txt > Pages : 27 > Date : 2008-11-03 > > This document describes an architecture for an infrastructure to > support improved security of Internet routing. The foundation of this > architecture is a public key infrastructure (PKI) that represents the > allocation hierarchy of IP address space and Autonomous System > Numbers; and a distributed repository system for storing and > disseminating the data objects that comprise the PKI, as well as > > > other signed objects necessary for improved routing security. As an > initial application of this architecture, the document describes how > a holder of IP address space can explicitly and verifiably authorize > one or more ASes to originate routes to that address space. Such > verifiable authorizations could be used, for example, to more > securely construct BGP route filters. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-arch-04.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. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-89--466936917 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi,

Some = comments:

1) Section 2.5: I believe we should = remove the reference to DNSSEC root key signing in section 2.5, = different scenario here and there.

2) Section = 2.6: I would like that the last paragraph from section 2.5 be included = in this section, because de "various registry" space is the "ERX space". = Also, In the figure 1, I know it is just an example but LACNIC only has = ERX space from /8 where ARIN and APNIC are majority, so just to keep it = "real" I will suggest replacing RIPE by = APNIC.

3) Trust Anchor Material. I believe we = agreed to include the description of the trust anchor material in the = arch document, I cant find it here. Is it though for a new = revision?

Regards,
r.




On Nov 3, 2008, at = 3:45 PM, Internet-Drafts@ietf.org = wrote:

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


Title =           : An = Infrastructure to Support Secure Internet Routing
Author(s) =       : M. Lepinski, S. Kent
Filename =        : = draft-ietf-sidr-arch-04.txt
Pages =           : = 27
= Date =            : = 2008-11-03

This document describes an architecture for an = infrastructure to
support improved security of Internet routing. The = foundation of this
architecture is a public key infrastructure (PKI) = that represents the
allocation hierarchy of IP address space and = Autonomous System
Numbers; and a distributed repository system for = storing and
disseminating the data objects that comprise the PKI, as = well as


other signed objects necessary for improved routing = security. As an
initial application of this architecture, the = document describes how
a holder of IP address space can explicitly = and verifiably authorize
one or more ASes to originate routes to = that address space. Such
verifiable authorizations could be used, = for example, to more
securely construct BGP route filters.

A = URL for this Internet-Draft is:
h= ttp://www.ietf.org/internet-drafts/draft-ietf-sidr-arch-04.txt

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

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of = the
Internet-Draft.
<mime-attachment>_______________= ________________________________
sidr mailing = list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

= --Apple-Mail-89--466936917-- --Apple-Mail-90--466936869 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkkhvw4ACgkQnk+WSgHpbO5HNgCeMUnXHLPiYHIYNzxBVI+i9Vbm QZoAn2LJCwTVKTa6IUs+WonE5sAoHQ32 =keUc -----END PGP SIGNATURE----- --Apple-Mail-90--466936869-- --===============0378833341== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --===============0378833341==-- From sidr-bounces@ietf.org Mon Nov 17 13:03:33 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D165D3A6A1F; Mon, 17 Nov 2008 13:03:33 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E91033A6A1F for ; Mon, 17 Nov 2008 13:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIpYt61+9v2t for ; Mon, 17 Nov 2008 13:03:32 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 2C2703A68A2 for ; Mon, 17 Nov 2008 13:03:32 -0800 (PST) Received: from [128.89.255.121] (helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1L2BFr-0003pL-Em for sidr@ietf.org; Mon, 17 Nov 2008 16:03:31 -0500 Message-ID: <4921DB9F.10205@bbn.com> Date: Mon, 17 Nov 2008 16:01:19 -0500 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "sidr@ietf.org" Subject: [sidr] Two ROA Format issues from the meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Two issues came up during the ROA Format presentation at IETF 73: 1) Should the ROA Format draft explicitly prohibit a ROA with overlapping prefixes? (E.g. A ROA that says AS # 1 can originate routes to 10/8, 10.10/16 and 10.20/16) 2) Should the ROA Format draft prohibit the use of the "Inherit" Flag in the RFC 3779 IP Address extension of the EE certificate corresponding to the ROA? In both cases, implementors have claimed that the prohibition would improve implementation efficiency and/or ease of coding/testing. The trade off is that in certain cases such prohibitations would require putting additional bits in the repository (I.e. in the first case, an ISP may sometimes need to issue an additional ROA; and in the second case, some ISPs may need to create larger EE certificates). I don't have a strong opinion, although my inclination is towards writing both of these prohibitions into the document. In any case, I'd very much like to resolve these issues quickly. (Since I believe that the ROA Format draft is otherwise ready for last call). - Matt Lepinski _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 17 13:40:28 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED5303A689E; Mon, 17 Nov 2008 13:40:27 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97DB028C0F3 for ; Mon, 17 Nov 2008 13:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEmGwVqS5oVO for ; Mon, 17 Nov 2008 13:40:25 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id BCD113A6876 for ; Mon, 17 Nov 2008 13:40:25 -0800 (PST) Received: from dhcp10.potaroo.net (dhcp10.potaroo.net [203.10.60.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 87AB8110041; Tue, 18 Nov 2008 07:40:24 +1000 (EST) Message-Id: <7893364D-FE9B-4F00-984E-9F97BA22ECCB@apnic.net> From: Geoff Huston To: Matt Lepinski In-Reply-To: <4921DB9F.10205@bbn.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 18 Nov 2008 08:40:23 +1100 References: <4921DB9F.10205@bbn.com> X-Mailer: Apple Mail (2.929.2) Cc: "sidr@ietf.org" Subject: Re: [sidr] Two ROA Format issues from the meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG Chair hat off On 18/11/2008, at 8:01 AM, Matt Lepinski wrote: > Two issues came up during the ROA Format presentation at IETF 73: > > 1) Should the ROA Format draft explicitly prohibit a ROA with > overlapping prefixes? > (E.g. A ROA that says AS # 1 can originate routes to 10/8, 10.10/16 > and 10.20/16) What do you mean by overlap Matt? a) 10.0.0.0/8 maxlength=9 and 10.0.0.0/24 maxlength=24 or b) 10.0.0.0/8 maxlength=24 and 10.0.0.0/16 maxlength=16 or c) 10.0.0.0/8 maxlength=17 and 10.0.0.0/16 maxlength=24 seems to me that b) is the only case where the second item is completely subsumed by the first, yet all three contain "overlapping prefixes" It also seems to me that all these cases are essentially harmless. My opinion is NOT to put this prohibition into the document, assuming of course that there is some clarity over what is meant precisely by "overlapping prefixes" in the first place Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 17 13:54:09 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426D33A6A1C; Mon, 17 Nov 2008 13:54:09 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D292A28C11A for ; Mon, 17 Nov 2008 13:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMhkizJzEG-R for ; Mon, 17 Nov 2008 13:54:08 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 1E6923A6907 for ; Mon, 17 Nov 2008 13:54:08 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id B790F26866A; Mon, 17 Nov 2008 14:54:07 -0700 (MST) Received: from [130.129.31.72] (130.129.31.72 [130.129.31.72]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Mon, 17 Nov 2008 14:54:07 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=130.129.31.72; client-port=61817; syn-fingerprint=65535:50:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: <587FB6ED-8792-4443-A698-AAA173B4806D@tcb.net> From: Danny McPherson To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 17 Nov 2008 14:53:52 -0700 X-Mailer: Apple Mail (2.929.2) Subject: [sidr] Comments on draft-pmohapat-sidr-pfx-validate-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Just to reiterate and expand upon my comments on the presentation John gave on this draft in SIDR today.. In short, I like the idea as it seems like a viable stepping stone to employ the work SIDR has been doing for a while now. I look forward to newer versions of this work, and believe it should be adopted under the SIDR WG, with charter update if need be. -danny --- A few specific things: 1) AS path origin-based policies alone are insufficient, as any targeted attack could most easily spoof the origin AS. 2) When I brought up the issue about targeted attacks John said this is meant to accommodate the 80/20 rule with route leaks, etc. When routes are leaked, which appears to be the most common 'hijack' case today, the origin is preserved. This wouldn't necessarily protect against that. 3) No inherent ability in the current validation modes to prefer shorter validated prefixes over longer non- validated ones means that most hijacks would still prefer the hijacked more-specific prefix. Most actual hijacks, and even leaks such as the YouTube incident, are from more specific prefixes and given preference. 4) Requiring implementations to store prefixes in their respective Adj-RIB-In, even if they've been filtered, such that they're available if policies changes, is a bad idea. Instead, as Jeff suggested at the microphone, employing route refresh in these scenarios would be much more scalable. E.g., in the case of CTBC last week there were like 267k prefixes leaked that would have been stored and filtered, were these capabilities in place. This could easily become a DOS vector itself. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 17 14:30:19 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 694FD3A6A7D; Mon, 17 Nov 2008 14:30:19 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 938463A6A7D for ; Mon, 17 Nov 2008 14:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MthH0pjf88s for ; Mon, 17 Nov 2008 14:30:17 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id B8D0D3A6907 for ; Mon, 17 Nov 2008 14:30:17 -0800 (PST) Received: from [128.89.255.48] (helo=[127.0.0.1]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1L2Cbj-0008EV-BT; Mon, 17 Nov 2008 17:30:11 -0500 Message-ID: <4921EFEF.50409@bbn.com> Date: Mon, 17 Nov 2008 17:27:59 -0500 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoff Huston References: <4921DB9F.10205@bbn.com> <7893364D-FE9B-4F00-984E-9F97BA22ECCB@apnic.net> In-Reply-To: <7893364D-FE9B-4F00-984E-9F97BA22ECCB@apnic.net> Cc: "sidr@ietf.org" Subject: Re: [sidr] Two ROA Format issues from the meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Geoff, My understanding of the discussion at the meeting was that the proposed prohibition would cover all three cases that you list below. The proposal was raised by Rob Kisteleki and Rob Austein, so I defer to either of them who would like to clarify. Either way, it seems to be a small issue, and so I'm inclined to do whatever makes implementation of the spec easiest. - Matt Lepinski Geoff Huston wrote: > WG Chair hat off > > On 18/11/2008, at 8:01 AM, Matt Lepinski wrote: > >> Two issues came up during the ROA Format presentation at IETF 73: >> >> 1) Should the ROA Format draft explicitly prohibit a ROA with >> overlapping prefixes? >> (E.g. A ROA that says AS # 1 can originate routes to 10/8, 10.10/16 >> and 10.20/16) > > > What do you mean by overlap Matt? > > a) 10.0.0.0/8 maxlength=9 and 10.0.0.0/24 maxlength=24 > > or > > b) 10.0.0.0/8 maxlength=24 and 10.0.0.0/16 maxlength=16 > > or > > c) 10.0.0.0/8 maxlength=17 and 10.0.0.0/16 maxlength=24 > > seems to me that b) is the only case where the second item is > completely subsumed by the first, yet all three contain "overlapping > prefixes" > > It also seems to me that all these cases are essentially harmless. > > My opinion is NOT to put this prohibition into the document, assuming > of course that there is some clarity over what is meant precisely by > "overlapping prefixes" in the first place > > Geoff > > > > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 17 14:35:06 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2870E28C145; Mon, 17 Nov 2008 14:35:06 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4937B28C145 for ; Mon, 17 Nov 2008 14:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1GPlejIc1Ai for ; Mon, 17 Nov 2008 14:35:01 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id D2A1C3A6907 for ; Mon, 17 Nov 2008 14:35:00 -0800 (PST) Received: from [130.129.95.247] (helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2CgJ-000HQH-95; Mon, 17 Nov 2008 22:34:55 +0000 Message-ID: <4921F18E.9070801@psg.com> Date: Mon, 17 Nov 2008 16:34:54 -0600 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Matt Lepinski References: <4921DB9F.10205@bbn.com> <7893364D-FE9B-4F00-984E-9F97BA22ECCB@apnic.net> <4921EFEF.50409@bbn.com> In-Reply-To: <4921EFEF.50409@bbn.com> X-Enigmail-Version: 0.95.7 Cc: "sidr@ietf.org" Subject: Re: [sidr] Two ROA Format issues from the meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > My understanding of the discussion at the meeting was that the proposed > prohibition would cover all three cases that you list below. yep. i would just say prohibit please except ... ruediger was the only user/rp to express concerns. so i would like to have a chance to discuss further with him before finalizing. and, of course, to hear from any other roa producers/consumers. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 17 15:25:31 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D7603A6A73; Mon, 17 Nov 2008 15:25:31 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 416AC3A6A8D for ; Mon, 17 Nov 2008 15:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOxYdSVCG6Em for ; Mon, 17 Nov 2008 15:25:29 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id 353853A6944 for ; Mon, 17 Nov 2008 15:25:29 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1L2DTA-0002Ky-F1 for sidr@ietf.org; Tue, 18 Nov 2008 00:25:27 +0100 Received: from Kistel-Mac.local (chimp.ripe.net [193.0.1.199]) by herring.ripe.net (Postfix) with ESMTP id 2FFE52F583 for ; Tue, 18 Nov 2008 00:25:24 +0100 (CET) Message-ID: <4921FD63.2070702@ripe.net> Date: Mon, 17 Nov 2008 17:25:23 -0600 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: "sidr@ietf.org" References: <4921DB9F.10205@bbn.com> <7893364D-FE9B-4F00-984E-9F97BA22ECCB@apnic.net> <4921EFEF.50409@bbn.com> In-Reply-To: <4921EFEF.50409@bbn.com> X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274bdf216f163e8a4fd31286543358a0909 Subject: Re: [sidr] Two ROA Format issues from the meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Hi, I'd defer the actual decision to those with more operational experience. My only wish is that whatever the decision is, it should be explicitly documented in the document (ie. "overlaps can happen and they are fine" or "there should be no overlaps at all"). Geoff: my definition of overlap would be (B) and (C) - ie. one or more IP addresses covered by two or more entries. (A) does not contain an overlap. I think this is consistent with what Ruediger said at the mike. Cheers, Robert Matt Lepinski wrote: > Geoff, > > My understanding of the discussion at the meeting was that the proposed > prohibition would cover all three cases that you list below. The > proposal was raised by Rob Kisteleki and Rob Austein, so I defer to > either of them who would like to clarify. > > Either way, it seems to be a small issue, and so I'm inclined to do > whatever makes implementation of the spec easiest. > > - Matt Lepinski > > Geoff Huston wrote: > >> WG Chair hat off >> >> On 18/11/2008, at 8:01 AM, Matt Lepinski wrote: >> >>> Two issues came up during the ROA Format presentation at IETF 73: >>> >>> 1) Should the ROA Format draft explicitly prohibit a ROA with >>> overlapping prefixes? >>> (E.g. A ROA that says AS # 1 can originate routes to 10/8, 10.10/16 >>> and 10.20/16) >> >> >> What do you mean by overlap Matt? >> >> a) 10.0.0.0/8 maxlength=9 and 10.0.0.0/24 maxlength=24 >> >> or >> >> b) 10.0.0.0/8 maxlength=24 and 10.0.0.0/16 maxlength=16 >> >> or >> >> c) 10.0.0.0/8 maxlength=17 and 10.0.0.0/16 maxlength=24 >> >> seems to me that b) is the only case where the second item is >> completely subsumed by the first, yet all three contain "overlapping >> prefixes" >> >> It also seems to me that all these cases are essentially harmless. >> >> My opinion is NOT to put this prohibition into the document, assuming >> of course that there is some clarity over what is meant precisely by >> "overlapping prefixes" in the first place >> >> Geoff >> >> >> >> > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 17 15:40:07 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08EA33A6A8D; Mon, 17 Nov 2008 15:40:07 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86E303A6A8D for ; Mon, 17 Nov 2008 15:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48fWEvp0W1Qg for ; Mon, 17 Nov 2008 15:40:04 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 628063A6944 for ; Mon, 17 Nov 2008 15:40:04 -0800 (PST) Received: from webmail.nist.gov (webmail.nist.gov [129.6.16.34]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAHNdm1K025056; Mon, 17 Nov 2008 18:39:48 -0500 Received: from apache by webmail.nist.gov with local (Exim 4.63) (envelope-from ) id 1L2Dh6-0005wX-J6; Mon, 17 Nov 2008 18:39:48 -0500 Received: from 130.129.29.130 ([130.129.29.130]) by webmail.nist.gov (Horde Framework) with HTTP; Mon, 17 Nov 2008 18:39:48 -0500 Message-ID: <20081117183948.220948mkrs54optw@webmail.nist.gov> Date: Mon, 17 Nov 2008 18:39:48 -0500 From: ksriram@nist.gov To: "Geoff Huston" References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> In-Reply-To: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: ksriram@nist.gov Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="Yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Geoff Huston wrote: > "I give my authority for AS1 and only AS1 to advertise a route > object for 10.1.0.0/16" Does the ROA format already permit this or would it require a modification? If you allow this, what about a subprefix,say, 10.1.0.0/24? Would that be precluded from having a ROA with a different AS? Sriram Quoting "Geoff Huston" : > WG chair hat off > > On 17/11/2008, at 10:28 AM, Danny McPherson wrote: > >> >> On Nov 14, 2008, at 1:07 PM, Geoff Huston wrote: >>> >>> A good example for me in thinking about this has been the YouTube >>> hijack at the start of this year. A salient question I asked >>> myslef was: what mechanisms could YouTube have used to alert >>> relying parties to the unauthorised advertisement of more >>> specifics from a different origin AS? >>> >>> ROAs alone are not a good answer here, in that a ROA does not say >>> what is bogus. >> >> But does the existence of a ROA, with origin authorization not >> make this implicit enough? > > > I assume you are referring to the situation where, for example, a > ROA exists for 10.1.0.0/16 origin AS 1, and NO ROA exists for > 10.1.0.0/16 origin AS2, and you are seeing a route object for > 10.1.0.0/16 with origin AS 2, yes? > > The problem is that as a relying party you can't tell whether the > problem is with the retrieval of ROA objects or whether the route > object is bogus. i.e. what if the ROA for 10.1.0.0/16 origin AS 2 > was published a few seconds ago, whereas your local cache of ROA > objects was last refreshed a day ago. i.e. everything you have at > hand is valid, the manifests are good, and you are seeing something > that is not oin a locally held ROA, _but_ it is still valid. > > If there was also a BOA published for 10.1.0.0/16 then as a relying > party you now have grounds to believe that anything not described in > a valid ROA can be regarded as an invalid object. In this case there > is still the issue of time lag, and if the prefix holder had > intended to authorize 10.1.0.0/16 using AS 2 as an origination in > addition to AS1 then it would be incumbent on the prefix holder to > generate and publish the new ROA well in advance of the > advertisement of the new route. > > Of course there is also the other case where AS 1 insists on a ROA > as a precondition for originating the route, and AS 2 does not, and > the prefix holder performs only what is required and no more. In > this case both routes are valid, but only one as a ROA. In tis case > the problem is not one of timing at the relying party side, and > will not be resolved by bring the relying party into sync with the > authority publisher. > >> >> >>> The only way that ROAs can do this is when a relying party is >>> justified in assuming that _absolutely everything_ is covered by a >>> ROA. In a world of incremental deployment this assumption does not >>> hold, and therefore the absence of a ROA conveys no information at >>> all. >>> >>> In this case BOAs can assist. Lets say that MeTube has published a >>> ROA to allow 10.1.0.0/16, max length=16 to be advertised from >>> origin AS 1, and a relying party sees an advertisement for >>> 10.1.1.0/24 originating from AS 2 (a hijack attempt). In this case >>> the relying party has no grounds to assume that the /24 >>> advertisement is bogus, and will accept the advertisement and the >>> hijack will be effective. But what if MeTube also published a BOA >>> for 10.1.0.0/16 at the same time as the ROA. Now as a ROA "trumps" >>> a BOA then any advertisement for 10.1.0.0/16 with an origination >>> of AS 1 will be regarded as valid by a relying party, while any >>> other use of 10.1.0.0/16 or any more specific will be regarded as >>> bogus. >> >> So wouldn't this mean that in the current model everyone would publish >> ROAs and BOAs? Do we really want that? Perhaps I'm missing something >> here? >> > > Well if relying parties could safely assume that _everyone_ was > publishing ROAs then there would be no need for BOAs as the absence > of a positive authority in the form of a ROA could be reliably > inferred to be unauthorized. But in a world where that assumption > does not hold, and where there is incremental partial deployment of > publication of these origination credentials, when relying parties > cannot assume that the absence of a positive authority means > anything at all. All it means is that if the route object matches > the ROA then its been authorized by the prefix holder. But if there > is no matching ROA then the relying party cannot assume anything at > all. > > The problem here is similar to the problem of filter generation: > There is a qualitative difference in these two statements: > > "I give my authority for AS 1 to advertise a route object for 10.1.0.0/16" > > "I give my authority for AS1 and only AS1 to advertise a route > object for 10.1.0.0/16" > > If you want the second statement, then we either need to change the > ROA to offer closure ("i.e. include "any only") or introduce a new > object that allows the authorizing party to state the "and only" > part explicitly). I contend that leaving this part of the authority > as something implicit that relying parties may or may not choose to > infer from the authority is a compromised model, imho. > > So the BOA is a way of implementing the RPSEC requirement of being > able to support environments of incremental deployment, where it is > not > assured that everyone is publishing these authorities. Now if you > are of the view that the requirement of devising mechanisms to > support incremental piecemeal deployment is daft or unnecessary, > then perhaps this is a debate that in the IETF context should be > held in the context of the RPSEC WG, as the SIDR requirement here is > one that was gather up from the earlier RPSEC work and generate > mechanisms that met those requirements as stated in the RPSEC > documents. > > > regards, > > Geoff > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 17 16:45:01 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7235C3A697F; Mon, 17 Nov 2008 16:45:01 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 779063A697F for ; Mon, 17 Nov 2008 16:44:59 -0800 (PST) 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=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcY19ZSBRkuT for ; Mon, 17 Nov 2008 16:44:58 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id A5D463A67F3 for ; Mon, 17 Nov 2008 16:44:58 -0800 (PST) Received: from [192.168.0.69] (eth502.act.adsl.internode.on.net [150.101.125.245]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 458E6110041; Tue, 18 Nov 2008 10:44:56 +1000 (EST) Message-Id: <8BED9B1D-B603-4E33-BDAF-EC0BA1899ECC@apnic.net> From: Geoff Huston To: ksriram@nist.gov In-Reply-To: <20081117183948.220948mkrs54optw@webmail.nist.gov> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 18 Nov 2008 11:44:55 +1100 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <20081117183948.220948mkrs54optw@webmail.nist.gov> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG Chair Hat _off_ On 18/11/2008, at 10:39 AM, ksriram@nist.gov wrote: > Geoff Huston wrote: >> "I give my authority for AS1 and only AS1 to advertise a route >> object for 10.1.0.0/16" > > Does the ROA format already permit this It is my understanding that the ROA, as defined today, does NOT permit this - i.e. the presence of a ROA does not in and of itself do the negation of the ROA. i.e. a ROA does not explicitly state "and everything else is invalid" > or would it require a modification? I believe it requires a modification - either a modification to the ROA to say "and invalidate all others" or via a BOA to state "and invalidate all others" > > If you allow this, what about a subprefix,say, 10.1.0.0/24? I assume that you are talking about a ROA for 10.0.0.0/8 with a maximum length=8. Again I would say that the ROA as it stands does not invalidate other route objects. > > Would that be precluded from having a ROA with a different AS? Again my interpretation is that a ROA is a positive assertion and not a negative assertion about all other possible route objects. If you want to extend this then the choices are either to extend the semantics of the ROA, either implicitly or explicitly, or introduce a new object, other the AS0 concept, or the explicit negation concept of the BOA draft. The BOA concept makes this negations explicit. Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 17 17:22:02 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3678928C0E6; Mon, 17 Nov 2008 17:22:02 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C77303A6A31 for ; Mon, 17 Nov 2008 17:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRsQ24AJHp0S for ; Mon, 17 Nov 2008 17:22:00 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EEC743A6922 for ; Mon, 17 Nov 2008 17:21:59 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,621,1220227200"; d="scan'208";a="196548561" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 18 Nov 2008 01:21:59 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id mAI1Lv3P017363; Mon, 17 Nov 2008 17:21:57 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mAI1Lv25005689; Tue, 18 Nov 2008 01:21:57 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Nov 2008 17:21:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Nov 2008 17:21:29 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5408278283@xmb-sjc-215.amer.cisco.com> In-Reply-To: <587FB6ED-8792-4443-A698-AAA173B4806D@tcb.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sidr] Comments on draft-pmohapat-sidr-pfx-validate-00.txt Thread-Index: AclI/wy2Kf4YmFcqTCeBufGlhMS62gAHJjEQ References: <587FB6ED-8792-4443-A698-AAA173B4806D@tcb.net> From: "Pradosh Mohapatra (pmohapat)" To: "Danny McPherson" , X-OriginalArrivalTime: 18 Nov 2008 01:21:57.0478 (UTC) FILETIME=[0C85D860:01C9491C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2923; t=1226971317; x=1227835317; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pmohapat@cisco.com; z=From:=20=22Pradosh=20Mohapatra=20(pmohapat)=22=20 |Subject:=20RE=3A=20[sidr]=20Comments=20on=20draft-pmohapat -sidr-pfx-validate-00.txt |Sender:=20; bh=/9eAUPdmD2lQ6+4UIHvawyyDqbrbkEpUx9oqYKLBXv8=; b=goIQ4C2ByV0F0ww1wnrdQ0+0WqonGm/HLCsRpIIKXMxdgeB12NAbQNbQK2 8E6A5qNyDZLJJ+Y2J1zg5fCtfomhEjoca4/85JNJmujUBFCXbCaHK/77uIAe JJgBOVX3Uc; Authentication-Results: sj-dkim-3; header.From=pmohapat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [sidr] Comments on draft-pmohapat-sidr-pfx-validate-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Hi Danny, Thanks for the comments. | A few specific things: | | 1) AS path origin-based policies alone are insufficient, as any | targeted attack could most easily spoof the origin AS. Yes, and that's why complete path attestation is still required and needs to be addressed. | 2) When I brought up the issue about targeted attacks John said this | is meant to accommodate the 80/20 rule with route leaks, etc. When | routes are leaked, which appears to be the most common 'hijack' | case today, the origin is preserved. This wouldn't necessarily | protect against that. I am not quite sure I follow this. But if the origin is preserved and the AS_PATH is not, it should again be addressed by path attestation. | | 3) No inherent ability in the current validation modes to prefer | shorter validated prefixes over longer non- validated ones means | that most hijacks would still prefer the hijacked more-specific | prefix. Most actual hijacks, and even leaks such as the YouTube | incident, are from more specific prefixes and given preference. >From the point of view of origin validation, prefixes with different mask lens are treated as completely different route advertisements and validated separately. So if a BGP speaker receives both 10.1.1/24 and 10.1/16, they are two separate prefixes, each undergoing the validation check. If the rightful owner of 10.1/16 prefix block is AS#1, I would expect AS#1 to have originated an ROA as {10.1/16, max_length=24}. When the BGP speaker receives 10.1/16 with origin AS 1, that would be declared "valid". However when it receives 10.1.1/24 with origin AS 2, since the ASs do not match for the ROA found, it would be declared "invalid". So that seems to take care of the issue you raise. | 4) Requiring implementations to store prefixes in their respective | Adj-RIB-In, even if they've been filtered, such that they're | available if policies changes, is a bad idea. Instead, as Jeff | suggested at the microphone, employing route refresh in these | scenarios would be much more scalable. | | E.g., in the case of CTBC last week there were like 267k prefixes | leaked that would have been stored and filtered, were these | capabilities in place. This could easily become a DOS vector itself. It's a trade-off. With route refresh mechanism, you will be forced to send a route refresh request to each of your peerings when the policy changes and receive all of the 267K prefixes again. That's not nice from CPU viewpoint. Agree you can be clever about storing some hints of which peers had sent you invalid routes and send the request to them or build a prefix ORF based on what prefixes have database updates etc..., but that's ugly. If you choose to store them, you are storing them only from your configured peers. So it's not an unbounded problem. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 17 21:05:41 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC3328C138; Mon, 17 Nov 2008 21:05:41 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D08E28C138 for ; Mon, 17 Nov 2008 21:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6FhWdKov-q5 for ; Mon, 17 Nov 2008 21:05:39 -0800 (PST) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) by core3.amsl.com (Postfix) with ESMTP id 928913A6934 for ; Mon, 17 Nov 2008 21:05:39 -0800 (PST) Received: from khazad-dum.hactrn.net (unknown [IPv6:2001:df8:0:16:215:afff:fe7f:ae5d]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "khazad-dum.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id C1E9CB884 for ; Tue, 18 Nov 2008 05:05:37 +0000 (UTC) Received: from khazad-dum.hactrn.net (localhost [IPv6:::1]) by khazad-dum.hactrn.net (Postfix) with ESMTP id B0C86733C3 for ; Tue, 18 Nov 2008 05:05:36 +0000 (UTC) Date: Mon, 17 Nov 2008 23:05:36 -0600 From: Rob Austein To: sidr@ietf.org In-Reply-To: <4921EFEF.50409@bbn.com> References: <4921DB9F.10205@bbn.com> <7893364D-FE9B-4F00-984E-9F97BA22ECCB@apnic.net> <4921EFEF.50409@bbn.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20081118050536.B0C86733C3@khazad-dum.hactrn.net> Subject: Re: [sidr] Two ROA Format issues from the meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At Mon, 17 Nov 2008 17:27:59 -0500, Matt Lepinski wrote: > > My understanding of the discussion at the meeting was that the proposed > prohibition would cover all three cases that you list below. The > proposal was raised by Rob Kisteleki and Rob Austein, so I defer to > either of them who would like to clarify. For those who didn't hear my comments at the meeting: RFC 3779 doesn't allow overlaps. Checking whether a ROA is covered by an RFC 3779 certificate is a bit easier if one doesn't need to implement the merge operation necessary to allow overlaps when converting from a ROA to an RFC 3779 resource set. If there's a useful purpose served by allowing overlaps, fine, I'll implement the merge, but until Ruidiger's comments today I had not heard anybody claim that allowing these overlaps serves a useful purpose. So at this point I'm waiting for the outcome of the discussion between Randy and Ruidiger to find out whether these overlaps are useful. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 17 21:44:45 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E6DB3A67B4; Mon, 17 Nov 2008 21:44:45 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F8B93A679F for ; Mon, 17 Nov 2008 21:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01VjvfnvvANj for ; Mon, 17 Nov 2008 21:44:43 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 201E93A68B3 for ; Mon, 17 Nov 2008 21:44:42 -0800 (PST) Received: from [192.168.0.69] (eth502.act.adsl.internode.on.net [150.101.125.245]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 6AAB6110041; Tue, 18 Nov 2008 15:44:40 +1000 (EST) Message-Id: From: Geoff Huston To: Matt Lepinski In-Reply-To: <4921EFEF.50409@bbn.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 18 Nov 2008 16:44:39 +1100 References: <4921DB9F.10205@bbn.com> <7893364D-FE9B-4F00-984E-9F97BA22ECCB@apnic.net> <4921EFEF.50409@bbn.com> X-Mailer: Apple Mail (2.929.2) Cc: "sidr@ietf.org" Subject: Re: [sidr] Two ROA Format issues from the meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Wg chair hat off On 18/11/2008, at 9:27 AM, Matt Lepinski wrote: > Geoff, > > My understanding of the discussion at the meeting was that the > proposed prohibition would cover all three cases that you list > below. The proposal was raised by Rob Kisteleki and Rob Austein, so > I defer to either of them who would like to clarify. > > Either way, it seems to be a small issue, and so I'm inclined to do > whatever makes implementation of the spec easiest. I could possibly understand this "prohibition" if it was restricted to enumeration of those cases where the 'overlap' was one where there was no additional information provided in the overlap. But in the cases I enumerated below only in case b) is the overlap redundant in that the announced prefixes that would be matched by the ROA are identical with or without the overlapping more specific. In cases a) and c) the overlap defines additional more specifics Why are cases a) and c) potentially useful? One possible scenario is in TE use, where a prefix holder wants to load share across two upstreams through the use of more specifics and have mutual backup via an aggregate ROA 1: 10.0.0.0/8 maxlength = 8 10.0.0.0/16 maxlength=16, AS 1 ROA 2: 10.0.0.0/8 maxlength = 8 10.128.0.0/16 maxlength=16, AS 1 now if I have this right what this equates to is an explicit authority for AS 1 and AS 2 to advertise only a certain subset of more specifics as well as the covering aggregate. There may well be other scenarios of such selective authorities. > > > - Matt Lepinski > > Geoff Huston wrote: > >> WG Chair hat off >> >> On 18/11/2008, at 8:01 AM, Matt Lepinski wrote: >> >>> Two issues came up during the ROA Format presentation at IETF 73: >>> >>> 1) Should the ROA Format draft explicitly prohibit a ROA with >>> overlapping prefixes? >>> (E.g. A ROA that says AS # 1 can originate routes to 10/8, >>> 10.10/16 and 10.20/16) >> >> >> What do you mean by overlap Matt? >> >> a) 10.0.0.0/8 maxlength=9 and 10.0.0.0/24 maxlength=24 >> >> or >> >> b) 10.0.0.0/8 maxlength=24 and 10.0.0.0/16 maxlength=16 >> >> or >> >> c) 10.0.0.0/8 maxlength=17 and 10.0.0.0/16 maxlength=24 >> >> seems to me that b) is the only case where the second item is >> completely subsumed by the first, yet all three contain >> "overlapping prefixes" >> >> It also seems to me that all these cases are essentially harmless. >> >> My opinion is NOT to put this prohibition into the document, >> assuming of course that there is some clarity over what is meant >> precisely by "overlapping prefixes" in the first place >> >> Geoff >> >> >> >> > > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 18 07:17:20 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C2283A6932; Tue, 18 Nov 2008 07:17:20 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74F173A6784 for ; Tue, 18 Nov 2008 07:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTm4KZJA5jdO for ; Tue, 18 Nov 2008 07:17:18 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by core3.amsl.com (Postfix) with ESMTP id B7E4E3A68A4 for ; Tue, 18 Nov 2008 07:17:18 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id E83456F07C; Tue, 18 Nov 2008 10:03:05 -0500 (EST) Received: from ex.arin.net (ex.arin.net [192.136.136.237]) by smtp1.arin.net (Postfix) with ESMTP id 840976F076 for ; Tue, 18 Nov 2008 10:03:05 -0500 (EST) Received: from EDAMAME.arin.net ([192.136.136.194]) by ex.arin.net ([192.136.136.237]) with mapi; Tue, 18 Nov 2008 10:17:02 -0500 From: Andy Newton To: "sidr@ietf.org" Date: Tue, 18 Nov 2008 10:17:01 -0500 Thread-Topic: One and only one RPKI Thread-Index: AclJkLSMVxIkHbQQxkOwOQdGnPQP6g== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [sidr] One and only one RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org After witnessing the CP document discussion, I'm left wondering if there is to be one and only one RPKI. Does the IETF endorse a specific RPKI? Can the IETF restrict any RPKI use to policies of this CP? -andy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 18 07:40:26 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 018BE3A68F9; Tue, 18 Nov 2008 07:40:26 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31CBF3A68F9 for ; Tue, 18 Nov 2008 07:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzXGmoT6-X3E for ; Tue, 18 Nov 2008 07:40:24 -0800 (PST) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id 5D1583A68A5 for ; Tue, 18 Nov 2008 07:40:24 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1L2Sge-00015g-5h for sidr@ietf.org; Tue, 18 Nov 2008 16:40:22 +0100 Received: from Kistel-Mac.local (chimp.ripe.net [193.0.1.199]) by herring.ripe.net (Postfix) with ESMTP id E13A92F583 for ; Tue, 18 Nov 2008 16:40:19 +0100 (CET) Message-ID: <4922E1E3.4020608@ripe.net> Date: Tue, 18 Nov 2008 09:40:19 -0600 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: "sidr@ietf.org" X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274f000e7cd45863c3da2f948971a344e22 Subject: [sidr] RPSLSIG adoption? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Hi, After my (rushed) presentation yesterday I'd like to ask if there are people in the WG who think that this idea is worth pursuing and should it be a WG item? http://www.ietf.org/internet-drafts/draft-kisteleki-sidr-rpsl-sig-00.txt http://www3.ietf.org/proceedings/08nov/slides/sidr-3.pdf Regards, Robert _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 18 07:43:35 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43B663A68F9; Tue, 18 Nov 2008 07:43:35 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0E143A68A4 for ; Tue, 18 Nov 2008 07:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFCeiQqVbQfP for ; Tue, 18 Nov 2008 07:43:33 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 334363A6A24 for ; Tue, 18 Nov 2008 07:43:33 -0800 (PST) Received: from [130.129.95.222] (unknown [130.129.95.222]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id D6235110041; Wed, 19 Nov 2008 01:43:30 +1000 (EST) Message-Id: From: George Michaelson To: Robert Kisteleki In-Reply-To: <4922E1E3.4020608@ripe.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 18 Nov 2008 09:43:23 -0600 References: <4922E1E3.4020608@ripe.net> X-Mailer: Apple Mail (2.929.2) Cc: "sidr@ietf.org" Subject: Re: [sidr] RPSLSIG adoption? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org I would support adoption of this item by the WG. it think its entirely on-charter for SIDR, and I think its a substantive body of work we should document. -George On 18/11/2008, at 9:40 AM, Robert Kisteleki wrote: > Hi, > > After my (rushed) presentation yesterday I'd like to ask if there > are people in the WG who think that this idea is worth pursuing and > should it be a WG item? > > http://www.ietf.org/internet-drafts/draft-kisteleki-sidr-rpsl-sig-00.txt > http://www3.ietf.org/proceedings/08nov/slides/sidr-3.pdf > > Regards, > Robert > _______________________________________________ > 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 sidr-bounces@ietf.org Tue Nov 18 08:01:16 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0F9F28C138; Tue, 18 Nov 2008 08:01:15 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3F7428C1D0 for ; Tue, 18 Nov 2008 08:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdX3DX+-emps for ; Tue, 18 Nov 2008 08:01:14 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 4CB4F28C138 for ; Tue, 18 Nov 2008 08:00:49 -0800 (PST) Received: from [130.129.95.247] (helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2T0P-000JZK-U0; Tue, 18 Nov 2008 16:00:46 +0000 Message-ID: <4922E6AD.8090203@psg.com> Date: Tue, 18 Nov 2008 10:00:45 -0600 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Robert Kisteleki References: <4922E1E3.4020608@ripe.net> In-Reply-To: <4922E1E3.4020608@ripe.net> X-Enigmail-Version: 0.95.7 Cc: "sidr@ietf.org" Subject: Re: [sidr] RPSLSIG adoption? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Robert Kisteleki wrote: > Hi, > > After my (rushed) presentation yesterday I'd like to ask if there are > people in the WG who think that this idea is worth pursuing and should > it be a WG item? > > http://www.ietf.org/internet-drafts/draft-kisteleki-sidr-rpsl-sig-00.txt > http://www3.ietf.org/proceedings/08nov/slides/sidr-3.pdf i think it is one of many possible interesting side uses of the rpki. it should be done in a wg for the application use, e.g. rps not sidr. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 18 08:02:05 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1EF3A69CF; Tue, 18 Nov 2008 08:02:05 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3C453A69CF for ; Tue, 18 Nov 2008 08:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uMgZDXspOp1 for ; Tue, 18 Nov 2008 08:02:03 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 128E13A68A9 for ; Tue, 18 Nov 2008 08:02:02 -0800 (PST) Received: from [130.129.95.247] (helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2T1b-000JZS-2G; Tue, 18 Nov 2008 16:01:59 +0000 Message-ID: <4922E6F6.9050206@psg.com> Date: Tue, 18 Nov 2008 10:01:58 -0600 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Andy Newton References: In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: "sidr@ietf.org" Subject: Re: [sidr] One and only one RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Andy Newton wrote: > After witnessing the CP document discussion, I'm left wondering if there is > to be one and only one RPKI. nothing else makes any sense. arin does not like that the cp has to be agreed by the entire community affected by it? randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 18 08:07:14 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0937F3A69E5; Tue, 18 Nov 2008 08:07:14 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF8253A69E5 for ; Tue, 18 Nov 2008 08:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbUYk9pcWXxd for ; Tue, 18 Nov 2008 08:07:10 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id D9D3B3A69CF for ; Tue, 18 Nov 2008 08:07:10 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 39930244194; Tue, 18 Nov 2008 16:07:10 +0000 (UTC) Date: Tue, 18 Nov 2008 11:07:10 -0500 From: Jeffrey Haas To: Robert Kisteleki Message-ID: <20081118160710.GA21730@slice> References: <4922E1E3.4020608@ripe.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4922E1E3.4020608@ripe.net> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Cc: "sidr@ietf.org" Subject: Re: [sidr] RPSLSIG adoption? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Robert, On Tue, Nov 18, 2008 at 09:40:19AM -0600, Robert Kisteleki wrote: > After my (rushed) presentation yesterday I'd like to ask if there are > people in the WG who think that this idea is worth pursuing and should it > be a WG item? > > http://www.ietf.org/internet-drafts/draft-kisteleki-sidr-rpsl-sig-00.txt > http://www3.ietf.org/proceedings/08nov/slides/sidr-3.pdf I think this work is probably worth pursuing but I will echo a concern raised at the session: This work is tightly bound to the stability of the current object format drafts. You may wish to either consider delaying your work until those have finished stabilizing or simply plan on having your document go against a moving target. Also, please excuse a silly question since it's been a number of years since I've been very RPSL savvy: How does this interact with RFC 2725, if at all? -- Jeff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 18 08:19:11 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A89DC3A6AF5; Tue, 18 Nov 2008 08:19:11 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE25C3A69CF for ; Tue, 18 Nov 2008 08:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcEf2NRMKaQo for ; Tue, 18 Nov 2008 08:19:09 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by core3.amsl.com (Postfix) with ESMTP id 24BF73A6AA9 for ; Tue, 18 Nov 2008 08:19:09 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 932A86F07C; Tue, 18 Nov 2008 11:05:10 -0500 (EST) Received: from ex.arin.net (cas2.arin.net [192.136.136.239]) by smtp1.arin.net (Postfix) with ESMTP id 1B6776F04F; Tue, 18 Nov 2008 11:05:10 -0500 (EST) Received: from EDAMAME.arin.net ([192.136.136.194]) by cas2.arin.net ([192.136.136.239]) with mapi; Tue, 18 Nov 2008 11:19:07 -0500 From: Andy Newton To: Randy Bush Date: Tue, 18 Nov 2008 11:19:06 -0500 Thread-Topic: [sidr] One and only one RPKI Thread-Index: AclJlwGf3zUIhXieTt+qRycXtnYzawAAl8yI Message-ID: In-Reply-To: <4922E6F6.9050206@psg.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] One and only one RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 11/18/08 11:01 AM, "Randy Bush" wrote: > Andy Newton wrote: >> After witnessing the CP document discussion, I'm left wondering if there is >> to be one and only one RPKI. > > nothing else makes any sense. So, the IETF does not sanction the use of the RPKI specs for a set of cooperative network providers who wish to establish their own trust anchors? Or the use of the RPKI specs to a government or collective of governments who wish to establish their own trust anchors? > arin does not like that the cp has to be agreed by the entire community > affected by it? To which entire community are you making a reference? And how did you draw your inference, given the definition of IETF participation? -andy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 18 08:23:28 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D74F03A6A30; Tue, 18 Nov 2008 08:23:28 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 469BE3A6A73 for ; Tue, 18 Nov 2008 08:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtUm5xKEu0KX for ; Tue, 18 Nov 2008 08:23:26 -0800 (PST) Received: from magus.merit.edu (magus.merit.edu [198.108.1.13]) by core3.amsl.com (Postfix) with ESMTP id 96CD53A6A30 for ; Tue, 18 Nov 2008 08:23:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by magus.merit.edu (Postfix) with ESMTP id DA3C3B0620; Tue, 18 Nov 2008 11:23:25 -0500 (EST) X-Virus-Scanned: amavisd-new at Received: from magus.merit.edu ([127.0.0.1]) by localhost (magus.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8T0nvAXjCFU2; Tue, 18 Nov 2008 11:23:25 -0500 (EST) Received: from ablate.merit.edu (ablate.merit.edu [198.108.62.151]) by magus.merit.edu (Postfix) with ESMTP id 8DA12B061A; Tue, 18 Nov 2008 11:23:25 -0500 (EST) Message-ID: <4922EBFD.60806@merit.edu> Date: Tue, 18 Nov 2008 11:23:25 -0500 From: Larry Blunk User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Robert Kisteleki References: <4922E1E3.4020608@ripe.net> In-Reply-To: <4922E1E3.4020608@ripe.net> Cc: "sidr@ietf.org" Subject: Re: [sidr] RPSLSIG adoption? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org I would support adoption. Would perhaps like to see some consideration of hierarchical named sets (i.e. ASXXXX:AS-CUSTOMERS). -Larry Blunk Robert Kisteleki wrote: > Hi, > > After my (rushed) presentation yesterday I'd like to ask if there are > people in the WG who think that this idea is worth pursuing and should > it be a WG item? > > http://www.ietf.org/internet-drafts/draft-kisteleki-sidr-rpsl-sig-00.txt > http://www3.ietf.org/proceedings/08nov/slides/sidr-3.pdf > > Regards, > Robert > _______________________________________________ > 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 sidr-bounces@ietf.org Tue Nov 18 08:25:23 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81A153A6A30; Tue, 18 Nov 2008 08:25:23 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B56B63A6A30 for ; Tue, 18 Nov 2008 08:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgVKcitVjlEm for ; Tue, 18 Nov 2008 08:25:16 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id 74DC53A68E7 for ; Tue, 18 Nov 2008 08:25:14 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1L2TO2-00081n-Ju; Tue, 18 Nov 2008 17:25:13 +0100 Received: from Kistel-Mac.local (chimp.ripe.net [193.0.1.199]) by herring.ripe.net (Postfix) with ESMTP id 39DD52F583; Tue, 18 Nov 2008 17:25:10 +0100 (CET) Message-ID: <4922EC65.6020205@ripe.net> Date: Tue, 18 Nov 2008 10:25:09 -0600 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Jeffrey Haas References: <4922E1E3.4020608@ripe.net> <20081118160710.GA21730@slice> In-Reply-To: <20081118160710.GA21730@slice> X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274059450419bc5f2d68f7abbedff2207ff Cc: "sidr@ietf.org" Subject: Re: [sidr] RPSLSIG adoption? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Jeffrey Haas wrote: > Robert, > > On Tue, Nov 18, 2008 at 09:40:19AM -0600, Robert Kisteleki wrote: >> After my (rushed) presentation yesterday I'd like to ask if there are >> people in the WG who think that this idea is worth pursuing and should it >> be a WG item? >> >> http://www.ietf.org/internet-drafts/draft-kisteleki-sidr-rpsl-sig-00.txt >> http://www3.ietf.org/proceedings/08nov/slides/sidr-3.pdf > > I think this work is probably worth pursuing but I will echo a concern > raised at the session: This work is tightly bound to the stability of > the current object format drafts. You may wish to either consider > delaying your work until those have finished stabilizing or simply plan > on having your document go against a moving target. The document that this one directly refers to is in WG last call, so I hope it's going to settle down soon. But even then, this is a fair advice. > Also, please excuse a silly question since it's been a number of years > since I've been very RPSL savvy: How does this interact with RFC 2725, > if at all? It's not the intention of this draft to modify authentication/authorization behavior. Rather, it's an extension to the objects themselves. Robert > -- Jeff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 18 08:26:03 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A33B33A68E7; Tue, 18 Nov 2008 08:26:03 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0EE83A68E7 for ; Tue, 18 Nov 2008 08:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IY+IJooFLl3A for ; Tue, 18 Nov 2008 08:26:02 -0800 (PST) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id CE5CD3A6808 for ; Tue, 18 Nov 2008 08:26:01 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1L2TOj-0001cI-Pj for sidr@ietf.org; Tue, 18 Nov 2008 17:25:56 +0100 Received: from RIPE-NCC-101045.local (gw.office.nsrp.ripe.net [193.0.1.126]) by herring.ripe.net (Postfix) with ESMTP id 658502F583; Tue, 18 Nov 2008 17:25:53 +0100 (CET) Message-ID: <4922EC8F.4050406@ripe.net> Date: Tue, 18 Nov 2008 17:25:51 +0100 From: Henk Uijterwaal User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Robert Kisteleki References: <4922E1E3.4020608@ripe.net> In-Reply-To: <4922E1E3.4020608@ripe.net> X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5c552d1b4661b778aca461314d8d2d2bc Cc: "sidr@ietf.org" Subject: Re: [sidr] RPSLSIG adoption? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Robert Kisteleki wrote: > Hi, > > After my (rushed) presentation yesterday I'd like to ask if there are > people in the WG who think that this idea is worth pursuing and should > it be a WG item? I like the idea but I think this question should be asked on the RPSL list as well before deciding which group should pick it up. Henk > > http://www.ietf.org/internet-drafts/draft-kisteleki-sidr-rpsl-sig-00.txt > http://www3.ietf.org/proceedings/08nov/slides/sidr-3.pdf > > Regards, > Robert > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Ceterum censeo Asplain esse delendam (Cato & Henk) _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 18 08:26:43 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97F4528C131; Tue, 18 Nov 2008 08:26:43 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261D128C131 for ; Tue, 18 Nov 2008 08:26:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgkdtfbAJKTA for ; Tue, 18 Nov 2008 08:26:42 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 1157D28C115 for ; Tue, 18 Nov 2008 08:26:42 -0800 (PST) Received: from [130.129.95.222] (dhcp188.apnic.net [202.12.29.188]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 15C0C110041; Wed, 19 Nov 2008 02:26:39 +1000 (EST) Message-Id: <540CEE45-5ADC-45C7-99C5-583E6BB5D3DF@apnic.net> From: George Michaelson To: Larry Blunk In-Reply-To: <4922EBFD.60806@merit.edu> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 18 Nov 2008 10:26:36 -0600 References: <4922E1E3.4020608@ripe.net> <4922EBFD.60806@merit.edu> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] RPSLSIG adoption? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org I may misunderstand this, but my belief is that *ONLY* hierarchical AS- SET form of named sets can logistically be signed over, because they are the only ones which have a single entity (the hierarchical tagger) that can claim to own the set relationship. Which RPKi EE cert would glue all the set elements together? Ie, anonymous named sets are 'hard' to sign. but the hierarchical ones are sort-of definitionally the best ones to use, and sign. The signing cert will relate to the single ASXXXX binding the list set. -George On 18/11/2008, at 10:23 AM, Larry Blunk wrote: > > I would support adoption. Would perhaps like to > see some consideration of hierarchical named sets > (i.e. ASXXXX:AS-CUSTOMERS). > > -Larry Blunk > > > Robert Kisteleki wrote: >> Hi, >> >> After my (rushed) presentation yesterday I'd like to ask if there >> are people in the WG who think that this idea is worth pursuing and >> should it be a WG item? >> >> http://www.ietf.org/internet-drafts/draft-kisteleki-sidr-rpsl-sig-00.txt >> http://www3.ietf.org/proceedings/08nov/slides/sidr-3.pdf >> >> Regards, >> Robert >> _______________________________________________ >> 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 sidr-bounces@ietf.org Tue Nov 18 08:26:59 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD92328C1E2; Tue, 18 Nov 2008 08:26:59 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19213A69E5 for ; Tue, 18 Nov 2008 08:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqZh+HQ4iEfY for ; Tue, 18 Nov 2008 08:26:58 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by core3.amsl.com (Postfix) with ESMTP id E56123A6808 for ; Tue, 18 Nov 2008 08:26:57 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 4D23D6F07F; Tue, 18 Nov 2008 11:12:59 -0500 (EST) Received: from ex.arin.net (ex.arin.net [192.136.136.237]) by smtp1.arin.net (Postfix) with ESMTP id C2FD46F07D; Tue, 18 Nov 2008 11:12:58 -0500 (EST) Received: from EDAMAME.arin.net ([192.136.136.194]) by ex.arin.net ([192.136.136.237]) with mapi; Tue, 18 Nov 2008 11:26:57 -0500 From: Andy Newton To: Geoff Huston Date: Tue, 18 Nov 2008 11:26:54 -0500 Thread-Topic: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt Thread-Index: AclJFudqcNAKD4uCTeGPmAaPB5FNmwAg5BYY Message-ID: In-Reply-To: <8BED9B1D-B603-4E33-BDAF-EC0BA1899ECC@apnic.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 11/17/08 7:44 PM, "Geoff Huston" wrote: > Again my interpretation is that a ROA is a positive assertion and not > a negative assertion about all other possible route objects. If you > want to extend this then the choices are either to extend the > semantics of the ROA, either implicitly or explicitly, or introduce a > new object, other the AS0 concept, or the explicit negation concept of > the BOA draft. The BOA concept makes this negations explicit. This all makes sense, and the BOA seems to be straightforward way of implementing a negative assertion. After Steve Kent's description of ROAs flowing from the top and being constantly reshaped based on allocations, I'd like to withdraw my objection to BOAs. It would seem they are necessary. -andy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 18 08:30:17 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC85D28C200; Tue, 18 Nov 2008 08:30:17 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A68128C218 for ; Tue, 18 Nov 2008 08:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzuTyfk0IdQb for ; Tue, 18 Nov 2008 08:30:15 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by core3.amsl.com (Postfix) with ESMTP id 87B1528C217 for ; Tue, 18 Nov 2008 08:30:15 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id CE6666F087; Tue, 18 Nov 2008 11:16:16 -0500 (EST) Received: from ex.arin.net (ex.arin.net [192.136.136.237]) by smtp1.arin.net (Postfix) with ESMTP id BF77F6F07D; Tue, 18 Nov 2008 11:16:04 -0500 (EST) Received: from EDAMAME.arin.net ([192.136.136.194]) by ex.arin.net ([192.136.136.237]) with mapi; Tue, 18 Nov 2008 11:30:03 -0500 From: Andy Newton To: Larry Blunk , Robert Kisteleki Date: Tue, 18 Nov 2008 11:30:01 -0500 Thread-Topic: [sidr] RPSLSIG adoption? Thread-Index: AclJmf9ZjfZuiw0TR12dfhdBgujQNgAAOfgL Message-ID: In-Reply-To: <4922EBFD.60806@merit.edu> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] RPSLSIG adoption? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org I concur with Larry. Additionally, I agree with several of the participants who said this is good work. I don't believe good work should be discouraged just because of administrative square-peg/round-hole problems. -andy On 11/18/08 11:23 AM, "Larry Blunk" wrote: > > > I would support adoption. Would perhaps like to > see some consideration of hierarchical named sets > (i.e. ASXXXX:AS-CUSTOMERS). > > -Larry Blunk > > > Robert Kisteleki wrote: >> Hi, >> >> After my (rushed) presentation yesterday I'd like to ask if there are >> people in the WG who think that this idea is worth pursuing and should >> it be a WG item? >> >> http://www.ietf.org/internet-drafts/draft-kisteleki-sidr-rpsl-sig-00.txt >> http://www3.ietf.org/proceedings/08nov/slides/sidr-3.pdf >> >> Regards, >> Robert >> _______________________________________________ >> 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 sidr-bounces@ietf.org Tue Nov 18 08:46:13 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB47228C13D; Tue, 18 Nov 2008 08:46:13 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26A483A6AA9 for ; Tue, 18 Nov 2008 08:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thndscyhosPf for ; Tue, 18 Nov 2008 08:46:12 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 6939028C1AC for ; Tue, 18 Nov 2008 08:45:54 -0800 (PST) Received: from webmail.nist.gov (webmail.nist.gov [129.6.16.34]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAIGjh8D003394; Tue, 18 Nov 2008 11:45:43 -0500 Received: from apache by webmail.nist.gov with local (Exim 4.63) (envelope-from ) id 1L2Thv-0003E0-6P; Tue, 18 Nov 2008 11:45:43 -0500 Received: from 130.129.29.130 ([130.129.29.130]) by webmail.nist.gov (Horde Framework) with HTTP; Tue, 18 Nov 2008 11:45:43 -0500 Message-ID: <20081118114543.19691ajqyrtory2f@webmail.nist.gov> Date: Tue, 18 Nov 2008 11:45:43 -0500 From: ksriram@nist.gov To: "Geoff Huston" References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <20081117183948.220948mkrs54optw@webmail.nist.gov> <8BED9B1D-B603-4E33-BDAF-EC0BA1899ECC@apnic.net> In-Reply-To: <8BED9B1D-B603-4E33-BDAF-EC0BA1899ECC@apnic.net> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: ksriram@nist.gov Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="Yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Thanks. "ROA as only a positive assertion" as you have stated is good. If we do modify ROA format to include "ASx and only ASx" to advertise a route object for a prefix, it appears correctly acceptable that I as the owner of 10.0.0.0/8 can still issue these two ROAs: ROA#1: Prefix = 10.0.0.0/8; origin = AS1 and only AS1; maxlength = 12 ROA#2: Prefix = 10.1.0.0/16; origin = AS2 and only AS2; maxlength = 24 ROA users have to be careful in their implementation not to "disregard" the second ROA based on the first. If they go with "ROA as only a positive assertion" then there should be no problem in the implementation. Sriram Quoting "Geoff Huston" : > WG Chair Hat _off_ > > On 18/11/2008, at 10:39 AM, ksriram@nist.gov wrote: > >> Geoff Huston wrote: >>> "I give my authority for AS1 and only AS1 to advertise a route >>> object for 10.1.0.0/16" >> >> Does the ROA format already permit this > > It is my understanding that the ROA, as defined today, does NOT > permit this - i.e. the presence of a ROA does not in and of itself > do the negation of the ROA. i.e. a ROA does not explicitly state > "and everything else is invalid" > > >> or would it require a modification? > > I believe it requires a modification - either a modification to the > ROA to say "and invalidate all others" or via a BOA to state "and > invalidate all others" > > >> >> If you allow this, what about a subprefix,say, 10.1.0.0/24? > > I assume that you are talking about a ROA for 10.0.0.0/8 with a > maximum length=8. Again I would say that the ROA as it stands does > not invalidate other route objects. > >> >> Would that be precluded from having a ROA with a different AS? > > Again my interpretation is that a ROA is a positive assertion and > not a negative assertion about all other possible route objects. If > you want to extend this then the choices are either to extend the > semantics of the ROA, either implicitly or explicitly, or introduce > a new object, other the AS0 concept, or the explicit negation > concept of the BOA draft. The BOA concept makes this negations > explicit. > > > Geoff > > > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 18 09:07:25 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F21693A6AFE; Tue, 18 Nov 2008 09:07:24 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D3E328C1D9 for ; Tue, 18 Nov 2008 09:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KO3xc1Dg9A-W for ; Tue, 18 Nov 2008 09:07:23 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 9E1223A6808 for ; Tue, 18 Nov 2008 09:07:23 -0800 (PST) Received: from [130.129.95.247] (helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2U2r-000Jjf-Pe; Tue, 18 Nov 2008 17:07:21 +0000 Message-ID: <4922F649.4000308@psg.com> Date: Tue, 18 Nov 2008 11:07:21 -0600 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Andy Newton References: In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: "sidr@ietf.org" Subject: Re: [sidr] One and only one RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org >>> After witnessing the CP document discussion, I'm left wondering if there is >>> to be one and only one RPKI. >> nothing else makes any sense. > So, the IETF does not sanction the use of the RPKI specs for a set of > cooperative network providers who wish to establish their own trust anchors? > Or the use of the RPKI specs to a government or collective of governments > who wish to establish their own trust anchors? sorry. i was confusing. i am talking about the rpki instance we as the operational internet community use. anyone is welcome to build their own private universes, of course. have fun. >> arin does not like that the cp has to be agreed by the entire community >> affected by it? > To which entire community are you making a reference? the one moving your packets. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 18 09:08:28 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 220593A6961; Tue, 18 Nov 2008 09:08:28 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BF083A6961 for ; Tue, 18 Nov 2008 09:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVh5Wc9vlACO for ; Tue, 18 Nov 2008 09:08:26 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 7CEBB3A6808 for ; Tue, 18 Nov 2008 09:08:26 -0800 (PST) Received: from [130.129.95.247] (helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2U3q-000Jk6-Dy; Tue, 18 Nov 2008 17:08:22 +0000 Message-ID: <4922F685.5030104@psg.com> Date: Tue, 18 Nov 2008 11:08:21 -0600 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Andy Newton References: In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: "sidr@ietf.org" Subject: Re: [sidr] RPSLSIG adoption? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > I agree with several of the participants who said this is good work. > I don't believe good work should be discouraged just because of > administrative square-peg/round-hole problems. i have not heard one voice discouraging this work. did you want to do so? where there seems to be disagreement is where the work should be done. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 18 09:27:17 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AFFC3A6B07; Tue, 18 Nov 2008 09:27:17 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA9763A6847 for ; Tue, 18 Nov 2008 09:27:15 -0800 (PST) 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=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vko-9uLrCFEp for ; Tue, 18 Nov 2008 09:27:15 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by core3.amsl.com (Postfix) with ESMTP id 1F0643A67D9 for ; Tue, 18 Nov 2008 09:27:15 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id BEF1F6F085; Tue, 18 Nov 2008 12:13:15 -0500 (EST) Received: from ex.arin.net (cas2.arin.net [192.136.136.239]) by smtp1.arin.net (Postfix) with ESMTP id 4A5146F07E; Tue, 18 Nov 2008 12:13:15 -0500 (EST) Received: from EDAMAME.arin.net ([192.136.136.194]) by cas2.arin.net ([192.136.136.239]) with mapi; Tue, 18 Nov 2008 12:27:13 -0500 From: Andy Newton To: Randy Bush Date: Tue, 18 Nov 2008 12:27:12 -0500 Thread-Topic: [sidr] RPSLSIG adoption? Thread-Index: AclJoEXoLqQMduRzTOaUCW2UQCjYIwAAp5f4 Message-ID: In-Reply-To: <4922F685.5030104@psg.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] RPSLSIG adoption? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 11/18/08 12:08 PM, "Randy Bush" wrote: > i have not heard one voice discouraging this work. did you want to do so? How did you get there from here? I said I agreed that it is good work. > where there seems to be disagreement is where the work should be done. Yes. Let us let the good work get done instead of batting it back-and-forth. -andy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 18 09:35:43 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA6F3A6821; Tue, 18 Nov 2008 09:35:43 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDF333A6821 for ; Tue, 18 Nov 2008 09:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9a8RSYzX1vV for ; Tue, 18 Nov 2008 09:35:41 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 201D43A6808 for ; Tue, 18 Nov 2008 09:35:41 -0800 (PST) Received: from [130.129.95.247] (helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2UU9-000Jo0-Io; Tue, 18 Nov 2008 17:35:33 +0000 Message-ID: <4922FCE4.70709@psg.com> Date: Tue, 18 Nov 2008 11:35:32 -0600 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Andy Newton References: In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: "sidr@ietf.org" Subject: Re: [sidr] RPSLSIG adoption? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org >> i have not heard one voice discouraging this work. did you want to do so? > How did you get there from here? you said the work was being discouraged. no one else was discouraging it. so process of elimination. >> where there seems to be disagreement is where the work should be done. > Yes. Let us let the good work get done instead of batting it back-and-forth. your annoyance at ietf process is likely not as large as mine. but discussing where a particular work should be done is a legitimate part of the process. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 18 10:50:36 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A0C33A68A4; Tue, 18 Nov 2008 10:50:36 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 454273A69E3 for ; Tue, 18 Nov 2008 10:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jI+Nm7SHSFsD for ; Tue, 18 Nov 2008 10:50:34 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 353D73A6407 for ; Tue, 18 Nov 2008 10:50:34 -0800 (PST) Received: from dhcp16.potaroo.net (dhcp16.potaroo.net [203.10.60.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 3F897110041; Wed, 19 Nov 2008 04:50:32 +1000 (EST) Message-Id: <6B33F40E-ADA9-442D-9FBE-895856B5B745@apnic.net> From: Geoff Huston To: ksriram@nist.gov In-Reply-To: <20081118114543.19691ajqyrtory2f@webmail.nist.gov> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 05:50:31 +1100 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <20081117183948.220948mkrs54optw@webmail.nist.gov> <8BED9B1D-B603-4E33-BDAF-EC0BA1899ECC@apnic.net> <20081118114543.19691ajqyrtory2f@webmail.nist.gov> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG CHair Hat Off Yes, I agree that there are some potential issues in correct interpretation if there are combinations of ROAs where there is implicit negation associated with the ROA. This should be basic 3 dimensional set work (prefix, AS, yes/no) and I think that the result is always deterministic for any collection of ROAs, but that does not make it always trivial to construct a desired origination policy. But as ROAs are only a positive assertion then this is probably a moot point. Geoff On 19/11/2008, at 3:45 AM, ksriram@nist.gov wrote: > Thanks. > "ROA as only a positive assertion" as you have stated is good. > If we do modify ROA format to include "ASx and only ASx" to advertise > a route object for a prefix, it appears correctly acceptable that > I as the owner of 10.0.0.0/8 can still issue these two ROAs: > > ROA#1: Prefix = 10.0.0.0/8; origin = AS1 and only AS1; maxlength = 12 > ROA#2: Prefix = 10.1.0.0/16; origin = AS2 and only AS2; maxlength = 24 > > ROA users have to be careful in their implementation > not to "disregard" the second ROA based on the first. > If they go with "ROA as only a positive assertion" > then there should be no problem in the implementation. > > Sriram > > Quoting "Geoff Huston" : > >> WG Chair Hat _off_ >> >> On 18/11/2008, at 10:39 AM, ksriram@nist.gov wrote: >> >>> Geoff Huston wrote: >>>> "I give my authority for AS1 and only AS1 to advertise a route >>>> object for 10.1.0.0/16" >>> >>> Does the ROA format already permit this >> >> It is my understanding that the ROA, as defined today, does NOT >> permit this - i.e. the presence of a ROA does not in and of itself >> do the negation of the ROA. i.e. a ROA does not explicitly state >> "and everything else is invalid" >> >> >>> or would it require a modification? >> >> I believe it requires a modification - either a modification to the >> ROA to say "and invalidate all others" or via a BOA to state "and >> invalidate all others" >> >> >>> >>> If you allow this, what about a subprefix,say, 10.1.0.0/24? >> >> I assume that you are talking about a ROA for 10.0.0.0/8 with a >> maximum length=8. Again I would say that the ROA as it stands does >> not invalidate other route objects. >> >>> >>> Would that be precluded from having a ROA with a different AS? >> >> Again my interpretation is that a ROA is a positive assertion and >> not a negative assertion about all other possible route objects. If >> you want to extend this then the choices are either to extend the >> semantics of the ROA, either implicitly or explicitly, or introduce >> a new object, other the AS0 concept, or the explicit negation >> concept of the BOA draft. The BOA concept makes this negations >> explicit. >> >> >> Geoff >> >> >> > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 18 10:55:08 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BACB33A6A0C; Tue, 18 Nov 2008 10:55:08 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E8533A6A0C for ; Tue, 18 Nov 2008 10:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORxOcWwgmaZJ for ; Tue, 18 Nov 2008 10:55:06 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 9E6B63A6977 for ; Tue, 18 Nov 2008 10:55:06 -0800 (PST) Received: from [130.129.95.247] (helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2Vj2-000KAp-KC; Tue, 18 Nov 2008 18:55:00 +0000 Message-ID: <49230F83.6040509@psg.com> Date: Tue, 18 Nov 2008 12:54:59 -0600 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Geoff Huston References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <20081117183948.220948mkrs54optw@webmail.nist.gov> <8BED9B1D-B603-4E33-BDAF-EC0BA1899ECC@apnic.net> <20081118114543.19691ajqyrtory2f@webmail.nist.gov> <6B33F40E-ADA9-442D-9FBE-895856B5B745@apnic.net> In-Reply-To: <6B33F40E-ADA9-442D-9FBE-895856B5B745@apnic.net> X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > Yes, I agree that there are some potential issues in correct > interpretation if there are combinations of ROAs where there is implicit > negation associated with the ROA. This should be basic 3 dimensional set > work (prefix, AS, yes/no) and I think that the result is always > deterministic for any collection of ROAs, but that does not make it > always trivial to construct a desired origination policy. But as ROAs > are only a positive assertion then this is probably a moot point. roas with magic as numbers vs boas is syntactic sugar. the semantic problem you mention applies to both. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 18 11:55:28 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98153A6B0F; Tue, 18 Nov 2008 11:55:28 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23E813A6B16 for ; Tue, 18 Nov 2008 11:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbfTBNcVOPeQ for ; Tue, 18 Nov 2008 11:55:27 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 0A6083A6AF1 for ; Tue, 18 Nov 2008 11:55:27 -0800 (PST) Received: from [130.129.95.222] (unknown [130.129.95.222]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id EF862110041 for ; Wed, 19 Nov 2008 05:55:24 +1000 (EST) Message-Id: <1BD44807-C700-40C9-8458-E47C8A2C7C09@apnic.net> From: George Michaelson To: sidr@ietf.org In-Reply-To: <49230F83.6040509@psg.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 18 Nov 2008 13:55:21 -0600 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <20081117183948.220948mkrs54optw@webmail.nist.gov> <8BED9B1D-B603-4E33-BDAF-EC0BA1899ECC@apnic.net> <20081118114543.19691ajqyrtory2f@webmail.nist.gov> <6B33F40E-ADA9-442D-9FBE-895856B5B745@apnic.net> <49230F83.6040509@psg.com> X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 18/11/2008, at 12:54 PM, Randy Bush wrote: >> Yes, I agree that there are some potential issues in correct >> interpretation if there are combinations of ROAs where there is >> implicit >> negation associated with the ROA. This should be basic 3 >> dimensional set >> work (prefix, AS, yes/no) and I think that the result is always >> deterministic for any collection of ROAs, but that does not make it >> always trivial to construct a desired origination policy. But as ROAs >> are only a positive assertion then this is probably a moot point. > > roas with magic as numbers vs boas is syntactic sugar. the semantic > problem you mention applies to both. > > randy I do not accept that ROA to AS0 and BOA is just syntactic sugar. They are substantially different in their logic, and semantic intent. A BOA is a positive assertion by the resource holder of the exact behaviors in respect of their prefix and a purported origin AS that they DO NOT wish to see expressed. Of course they can be used to simply do a negation of things not seen in the ROA, but they have far more expressive capability and can say things, materially useful to achieve the range of origination policies used by network operators at the present time. We drew on the ROA *syntax* precisely to seek a syntactic similarity, to ease coding, We chose CMS deliberately for consistency with other signed object construction. Please do not allow that syntactic similarity to the ROA to hide the quite clear SEMANTIC DIFFERENCE which we hold in the BOA. I still stand by the BOA draft. I think it adds useful tools into routing security for operators. -George _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 18 12:53:20 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5572D3A68C4; Tue, 18 Nov 2008 12:53:20 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 989F93A68C4 for ; Tue, 18 Nov 2008 12:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuraUgq5Lv0d for ; Tue, 18 Nov 2008 12:53:18 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 133AB3A677C for ; Tue, 18 Nov 2008 12:53:17 -0800 (PST) Received: from webmail.nist.gov (webmail.nist.gov [129.6.16.34]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAIKr4H5014592; Tue, 18 Nov 2008 15:53:04 -0500 Received: from apache by webmail.nist.gov with local (Exim 4.63) (envelope-from ) id 1L2XZI-0001Av-T0; Tue, 18 Nov 2008 15:53:04 -0500 Received: from 130.129.29.130 ([130.129.29.130]) by webmail.nist.gov (Horde Framework) with HTTP; Tue, 18 Nov 2008 15:53:04 -0500 Message-ID: <20081118155304.13816lhd3a6a10kw@webmail.nist.gov> Date: Tue, 18 Nov 2008 15:53:04 -0500 From: ksriram@nist.gov To: "Pradosh Mohapatra (pmohapat)" References: <587FB6ED-8792-4443-A698-AAA173B4806D@tcb.net> <04CAD96D4C5A3D48B1919248A8FE0D5408278283@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5408278283@xmb-sjc-215.amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: ksriram@nist.gov Cc: sidr@ietf.org Subject: Re: [sidr] Comments on draft-pmohapat-sidr-pfx-validate-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="Yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Quoting "Pradosh Mohapatra (pmohapat)" : > From the point of view of origin validation, prefixes with different > mask lens are treated as completely different route advertisements and > validated separately. So if a BGP speaker receives both 10.1.1/24 and > 10.1/16, they are two separate prefixes, each undergoing the > validation check. If the rightful owner of 10.1/16 prefix block is > AS#1, I would expect AS#1 to have originated an ROA as {10.1/16, > max_length=24}. When the BGP speaker receives 10.1.0.0/16 with origin AS > 1, that would be declared "valid". However when it receives 10.1.1/24 > with origin AS 2, since the ASs do not match for the ROA found, it > would be declared "invalid". So that seems to take care of the issue > you raise. The capability in any algorithm to distinguish between an update due to path or origin change by legitimate owner's action vs. that due to a hijack/misconfiguration attack would remain challenging as long as RPKI adoption and creation of ROAs is partial. The legitimate owner of 10.1/16 can be multi-homed to, say, AS#1 and AS#2. They may have created a ROA for 10.1.0.0/16, Origin = AS#1, but may not have yet created a ROA for 10.1.1.0/24, Origin = AS#2. There is also the lag issue. They may have created the second ROA in the last few hours and propagated an update with different origin (AS#2) shortly after that, but the algorithm downloads ROAs only once every 24 hours. So the algorithm fails to validate based on the currently known ROAs at the BGP speaker. During the evolution period of RPKI, origin and path validation algorithms can benefit from combining (prefix, origin AS) pairing information from different sources, including trace data (e.g., routeviews, RIPE-RIS) and even RPSL/SWIP route registration data from IRR/RADB. This would be especially useful when there is incompleteness in the ROA repository. Some examples of ideas (research) along these lines: http://www.cs.unm.edu/~treport/tr/06-06/pgbgp3.pdf http://www.antd.nist.gov/~ksriram/NIST_BGP_Robustness.pdf Sriram _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 18 13:12:46 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 657983A6885; Tue, 18 Nov 2008 13:12:46 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 408463A6885 for ; Tue, 18 Nov 2008 13:12:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fO83xfkL5Z1c for ; Tue, 18 Nov 2008 13:12:44 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 631633A6809 for ; Tue, 18 Nov 2008 13:12:44 -0800 (PST) Received: from dhcp16.potaroo.net (dhcp16.potaroo.net [203.10.60.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 1541F110041; Wed, 19 Nov 2008 07:12:43 +1000 (EST) Message-Id: From: Geoff Huston To: sidr@ietf.org In-Reply-To: <4922E1E3.4020608@ripe.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 08:12:42 +1100 References: <4922E1E3.4020608@ripe.net> X-Mailer: Apple Mail (2.929.2) Subject: [sidr] WG adoption of draft-kisteleki-sidr-rpsl-sig-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG co-Chair hat ON Thanks for this request Robert. I'd like to put the question to the WG to adopt this draft as a WG document. Please send in your comments to the WG by Friday November 28th on this. I'll note the comments already posted on this thread so there is no need to post again if you've already voiced your views on this question. thanks, Geoff On 19/11/2008, at 2:40 AM, Robert Kisteleki wrote: > Hi, > > After my (rushed) presentation yesterday I'd like to ask if there > are people in the WG who think that this idea is worth pursuing and > should it be a WG item? > > http://www.ietf.org/internet-drafts/draft-kisteleki-sidr-rpsl-sig-00.txt > http://www3.ietf.org/proceedings/08nov/slides/sidr-3.pdf > > Regards, > Robert > _______________________________________________ > 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 sidr-bounces@ietf.org Tue Nov 18 13:14:11 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3D0E3A6B22; Tue, 18 Nov 2008 13:14:11 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC8CD3A6B22 for ; Tue, 18 Nov 2008 13:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.573 X-Spam-Level: X-Spam-Status: No, score=-0.573 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_RU=0.595, HELO_IS_SMALL6=0.556, HOST_EQ_RU=0.875] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqcxugeW4bhY for ; Tue, 18 Nov 2008 13:14:10 -0800 (PST) Received: from aha.ru (backend13.aha.ru [62.113.86.202]) by core3.amsl.com (Postfix) with ESMTP id AAD303A6A73 for ; Tue, 18 Nov 2008 13:14:09 -0800 (PST) Received: from [92.243.166.226] (account dburk@burkov.aha.ru HELO [192.168.0.132]) by backend13.aha.ru (CommuniGate Pro SMTP 4.3.11) with ESMTPSA id 172483924; Wed, 19 Nov 2008 00:14:05 +0300 Message-ID: <4923301F.70305@burkov.aha.ru> Date: Wed, 19 Nov 2008 00:14:07 +0300 From: Dmitry Burkov User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Randy Bush References: <4922F649.4000308@psg.com> In-Reply-To: <4922F649.4000308@psg.com> Cc: "sidr@ietf.org" Subject: Re: [sidr] One and only one RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Randy Bush wrote: >>>> After witnessing the CP document discussion, I'm left wondering if there is >>>> to be one and only one RPKI. >>>> >>> nothing else makes any sense. >>> >> So, the IETF does not sanction the use of the RPKI specs for a set of >> cooperative network providers who wish to establish their own trust anchors? >> Or the use of the RPKI specs to a government or collective of governments >> who wish to establish their own trust anchors? >> > > sorry. i was confusing. i am talking about the rpki instance we as the > operational internet community use. anyone is welcome to build their > own private universes, of course. have fun. > we will get immediatelly - as I tried to explain you before on RIPE meeteng in Dubai - do you like it or not or I mistaken? Dima > >>> arin does not like that the cp has to be agreed by the entire community >>> affected by it? >>> >> To which entire community are you making a reference? >> > > the one moving your packets. > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 18 13:14:40 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06D983A6885; Tue, 18 Nov 2008 13:14:40 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11BFD3A6885 for ; Tue, 18 Nov 2008 13:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIksybfpT7Hw for ; Tue, 18 Nov 2008 13:14:37 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 2CA683A6809 for ; Tue, 18 Nov 2008 13:14:37 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id mAILETWm014777; Tue, 18 Nov 2008 15:14:29 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id mAILESJP020854; Tue, 18 Nov 2008 15:14:28 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([130.129.29.89]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 16:14:20 -0500 Date: Tue, 18 Nov 2008 16:14:17 -0500 (Eastern Standard Time) From: Sandra Murphy To: Andy Newton In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 18 Nov 2008 21:14:20.0472 (UTC) FILETIME=[9F786380:01C949C2] Cc: "sidr@ietf.org" Subject: Re: [sidr] One and only one RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Tue, 18 Nov 2008, Andy Newton wrote: > > > > On 11/18/08 11:01 AM, "Randy Bush" wrote: > >> Andy Newton wrote: >>> After witnessing the CP document discussion, I'm left wondering if there is >>> to be one and only one RPKI. >> >> nothing else makes any sense. > > So, the IETF does not sanction the use of the RPKI specs for a set of > cooperative network providers who wish to establish their own trust anchors? > Or the use of the RPKI specs to a government or collective of governments > who wish to establish their own trust anchors? I don't understand the change from talking about the CP to talking about trust anchors. Could you explain what I'm missing? > >> arin does not like that the cp has to be agreed by the entire community >> affected by it? > > To which entire community are you making a reference? And how did you draw > your inference, given the definition of IETF participation? > Incidentally, I thought I heard Russ Housley say at the mike that the cert format says what CP appliels and it points to this CP. If I understand, using a different CP means changing the cert format. Am I wrong? I see the following, which I presume is what Russ was referring to: 3.9.8. Certificate Policies This extension MUST reference the Resource Certificate Policy, using the OID Policy Identifier value of "1.3.6.1.5.5.7.14.2". This field MUST be present and MUST contain only this value for Resource Certificates. No PolicyQualifiers are defined for use with this policy and thus none must be included in this extension. This extension MUST be present and it is critical. > -andy > > _______________________________________________ > 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 sidr-bounces@ietf.org Tue Nov 18 13:35:36 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A847228C0E8; Tue, 18 Nov 2008 13:35:36 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CFED28C22E for ; Tue, 18 Nov 2008 13:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uBt9rl1Xktb for ; Tue, 18 Nov 2008 13:35:34 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id CC77B3A6885 for ; Tue, 18 Nov 2008 13:35:34 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so3065823rvf.49 for ; Tue, 18 Nov 2008 13:35:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer:sender; bh=H5BUp5SQ4sAp96N81Phn06USfNMDqjwE8c4FU6ezeP0=; b=gkn9l+LBGGoqw31M9fGUTZBTj/Q/dW+bKpNR1pnIUgxqJ7n1EJ7TSRqWXHErGWrEit u4cHKFwhvhwLIlq0ScAF7qh9T/f5KUqg4c0kGiXE7q4hl99wUy/O11/c+iZrSA8vA8e0 GgIWiddSFZN/09pOUqxxuJL3AyY6RwUScy2FI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer:sender; b=Hi2ZtgRtrRmhpcJXWa5PX1UTUvejRpc2tzNx70A3oXhD7MLjUW+y6mUKH4f6eRKhmY 2eap+dD1ZRSAQEgkor9Oz3fJ2wVc3YKKOmh33cUjG+B+cHrNdWY3PkVo7Nsn4kENmc4F QGemZ6HY9ROSjCdkbxtcT6llAtLcBo3BI9SfY= Received: by 10.140.193.15 with SMTP id q15mr147711rvf.274.1227044133170; Tue, 18 Nov 2008 13:35:33 -0800 (PST) Received: from ?130.129.31.159? ([130.129.31.159]) by mx.google.com with ESMTPS id f21sm13738259rvb.5.2008.11.18.13.35.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 Nov 2008 13:35:32 -0800 (PST) Message-Id: <4543B5E8-9F77-4DA3-9685-24239E777BA6@terrym.net> From: Terry Manderson To: sidr@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 07:35:28 +1000 References: <4922E1E3.4020608@ripe.net> X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] WG adoption of draft-kisteleki-sidr-rpsl-sig-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org In re-reading the WG Charter, I note: Lead-in paragraph: "A related question concerns the level of trust than can be ascribed to attributes of a route object in terms of their authenticity" Scope: "Document the use of certification objects within this secure routing architecture" It doesn't prescribe what a certification object is exactly, and with the above in mind I believe the SIDR working group is a suitable place for this work, and I think the WG should adopt this draft as a workgroup item and I am willing to read and review. Thanks Terry On 19/11/2008, at 7:12 AM, Geoff Huston wrote: > WG co-Chair hat ON > > Thanks for this request Robert. > > I'd like to put the question to the WG to adopt this draft as a WG > document. > > Please send in your comments to the WG by Friday November 28th on > this. > > I'll note the comments already posted on this thread so there is no > need to post again if you've already voiced your views on this > question. > > thanks, > > Geoff > > > > > > On 19/11/2008, at 2:40 AM, Robert Kisteleki wrote: > >> Hi, >> >> After my (rushed) presentation yesterday I'd like to ask if there >> are people in the WG who think that this idea is worth pursuing and >> should it be a WG item? >> >> http://www.ietf.org/internet-drafts/draft-kisteleki-sidr-rpsl-sig-00.txt >> http://www3.ietf.org/proceedings/08nov/slides/sidr-3.pdf >> >> Regards, >> Robert >> _______________________________________________ >> 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 sidr-bounces@ietf.org Tue Nov 18 14:38:38 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FCCC28C241; Tue, 18 Nov 2008 14:38:38 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D34A3A68F5 for ; Tue, 18 Nov 2008 14:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfwQPJX4J2eA for ; Tue, 18 Nov 2008 14:38:35 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 680B328C241 for ; Tue, 18 Nov 2008 14:38:35 -0800 (PST) Received: from [130.129.95.222] (unknown [130.129.95.222]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id AA35A110041 for ; Wed, 19 Nov 2008 08:38:32 +1000 (EST) Message-Id: From: George Michaelson To: sidr@ietf.org In-Reply-To: <4921EFEF.50409@bbn.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 18 Nov 2008 16:38:29 -0600 References: <4921DB9F.10205@bbn.com> <7893364D-FE9B-4F00-984E-9F97BA22ECCB@apnic.net> <4921EFEF.50409@bbn.com> X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] Two ROA Format issues from the meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org As a matter of record, the APNIC implementation allows for creation of overlapping prefixes in a ROA. We do not support any change to this. -George On 17/11/2008, at 4:27 PM, Matt Lepinski wrote: > Geoff, > > My understanding of the discussion at the meeting was that the > proposed prohibition would cover all three cases that you list > below. The proposal was raised by Rob Kisteleki and Rob Austein, so > I defer to either of them who would like to clarify. > > Either way, it seems to be a small issue, and so I'm inclined to do > whatever makes implementation of the spec easiest. > > - Matt Lepinski > > Geoff Huston wrote: > >> WG Chair hat off >> >> On 18/11/2008, at 8:01 AM, Matt Lepinski wrote: >> >>> Two issues came up during the ROA Format presentation at IETF 73: >>> >>> 1) Should the ROA Format draft explicitly prohibit a ROA with >>> overlapping prefixes? >>> (E.g. A ROA that says AS # 1 can originate routes to 10/8, >>> 10.10/16 and 10.20/16) >> >> >> What do you mean by overlap Matt? >> >> a) 10.0.0.0/8 maxlength=9 and 10.0.0.0/24 maxlength=24 >> >> or >> >> b) 10.0.0.0/8 maxlength=24 and 10.0.0.0/16 maxlength=16 >> >> or >> >> c) 10.0.0.0/8 maxlength=17 and 10.0.0.0/16 maxlength=24 >> >> seems to me that b) is the only case where the second item is >> completely subsumed by the first, yet all three contain >> "overlapping prefixes" >> >> It also seems to me that all these cases are essentially harmless. >> >> My opinion is NOT to put this prohibition into the document, >> assuming of course that there is some clarity over what is meant >> precisely by "overlapping prefixes" in the first place >> >> Geoff >> >> >> >> > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 18 16:35:08 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 472273A6947; Tue, 18 Nov 2008 16:35:08 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7630F3A6947 for ; Tue, 18 Nov 2008 16:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQI39aOvCBp9 for ; Tue, 18 Nov 2008 16:35:05 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 23DB13A680F for ; Tue, 18 Nov 2008 16:35:05 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id mAJ0Z2mR017606; Tue, 18 Nov 2008 18:35:02 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id mAJ0Z15f027545; Tue, 18 Nov 2008 18:35:01 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([130.129.77.151]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 19:35:00 -0500 Date: Tue, 18 Nov 2008 19:34:59 -0500 (Eastern Standard Time) From: Sandra Murphy To: "Pradosh Mohapatra (pmohapat)" In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5408278283@xmb-sjc-215.amer.cisco.com> Message-ID: References: <587FB6ED-8792-4443-A698-AAA173B4806D@tcb.net> <04CAD96D4C5A3D48B1919248A8FE0D5408278283@xmb-sjc-215.amer.cisco.com> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 19 Nov 2008 00:35:00.0932 (UTC) FILETIME=[A824C840:01C949DE] Cc: sidr@ietf.org Subject: Re: [sidr] Comments on draft-pmohapat-sidr-pfx-validate-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Mon, 17 Nov 2008, Pradosh Mohapatra (pmohapat) wrote: > Hi Danny, > > Thanks for the comments. > > | A few specific things: > | > | 1) AS path origin-based policies alone are insufficient, as any > | targeted attack could most easily spoof the origin AS. > > Yes, and that's why complete path attestation is still required and > needs to be addressed. SIDR was chartered to fulfill the security requirements established by the rpsec working group. That group was able to set path origination as a security requirement but failed to come to consensus of what sort of additional path security should be required. No one in the rpsec wg argued that additional path security is NOT required, it was just setting the exact security requirements for security for the AS_PATH past the origination AS that was contentious. So everyone recognizes that the origination of a route to a prefix is not sufficient. But it is necessary. It is the starting point of every suggested BGP protection that provides more protection of the AS_PATH. (That I have seen.) So we'll get done with this (someday!) and we can continue with more work to further protect the AS_PATH and this current work will be useful in the meantime and the basis for the more work (i.e., not wasted). --Sandy > > | 2) When I brought up the issue about targeted attacks John said this > | is meant to accommodate the 80/20 rule with route leaks, etc. When > | routes are leaked, which appears to be the most common 'hijack' > | case today, the origin is preserved. This wouldn't necessarily > | protect against that. > > I am not quite sure I follow this. But if the origin is preserved and > the AS_PATH is not, it should again be addressed by path attestation. > > | > | 3) No inherent ability in the current validation modes to prefer > | shorter validated prefixes over longer non- validated ones means > | that most hijacks would still prefer the hijacked more-specific > | prefix. Most actual hijacks, and even leaks such as the YouTube > | incident, are from more specific prefixes and given preference. > > From the point of view of origin validation, prefixes with different > mask lens are treated as completely different route advertisements and > validated separately. So if a BGP speaker receives both 10.1.1/24 and > 10.1/16, they are two separate prefixes, each undergoing the > validation check. If the rightful owner of 10.1/16 prefix block is > AS#1, I would expect AS#1 to have originated an ROA as {10.1/16, > max_length=24}. When the BGP speaker receives 10.1/16 with origin AS > 1, that would be declared "valid". However when it receives 10.1.1/24 > with origin AS 2, since the ASs do not match for the ROA found, it > would be declared "invalid". So that seems to take care of the issue > you raise. > > | 4) Requiring implementations to store prefixes in their respective > | Adj-RIB-In, even if they've been filtered, such that they're > | available if policies changes, is a bad idea. Instead, as Jeff > | suggested at the microphone, employing route refresh in these > | scenarios would be much more scalable. > | > | E.g., in the case of CTBC last week there were like 267k prefixes > | leaked that would have been stored and filtered, were these > | capabilities in place. This could easily become a DOS vector itself. > > It's a trade-off. With route refresh mechanism, you will be forced to > send a route refresh request to each of your peerings when the policy > changes and receive all of the 267K prefixes again. That's not nice > from CPU viewpoint. Agree you can be clever about storing some hints > of which peers had sent you invalid routes and send the request to > them or build a prefix ORF based on what prefixes have database > updates etc..., but that's ugly. If you choose to store them, you are > storing them only from your configured peers. So it's not an unbounded > problem. > _______________________________________________ > 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 sidr-bounces@ietf.org Tue Nov 18 16:49:51 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E028B28C284; Tue, 18 Nov 2008 16:49:51 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EDFA28C278 for ; Tue, 18 Nov 2008 16:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpeuBQ87R8cJ for ; Tue, 18 Nov 2008 16:49:50 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 14D9B28C27C for ; Tue, 18 Nov 2008 16:49:50 -0800 (PST) Received: from [192.168.0.69] (eth502.act.adsl.internode.on.net [150.101.125.245]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id AEC0D110062; Wed, 19 Nov 2008 10:49:48 +1000 (EST) Message-Id: <51D173A7-CC03-4BD7-9585-C8672388978C@apnic.net> From: Geoff Huston To: sidr@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 11:49:47 +1100 References: <587FB6ED-8792-4443-A698-AAA173B4806D@tcb.net> <04CAD96D4C5A3D48B1919248A8FE0D5408278283@xmb-sjc-215.amer.cisco.com> X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] Comments on draft-pmohapat-sidr-pfx-validate-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 19/11/2008, at 11:34 AM, Sandra Murphy wrote: > > > On Mon, 17 Nov 2008, Pradosh Mohapatra (pmohapat) wrote: > >> Hi Danny, >> >> Thanks for the comments. >> >> | A few specific things: >> | >> | 1) AS path origin-based policies alone are insufficient, as any >> | targeted attack could most easily spoof the origin AS. >> >> Yes, and that's why complete path attestation is still required and >> needs to be addressed. > > SIDR was chartered to fulfill the security requirements established > by the rpsec working group. That group was able to set path > origination as a security requirement but failed to come to > consensus of what sort of additional path security should be required. > > No one in the rpsec wg argued that additional path security is NOT > required, it was just setting the exact security requirements for > security for the AS_PATH past the origination AS that was contentious. > > So everyone recognizes that the origination of a route to a prefix > is not sufficient. But it is necessary. It is the starting point > of every suggested BGP protection that provides more protection of > the AS_PATH. (That I have seen.) > > So we'll get done with this (someday!) and we can continue with more > work to further protect the AS_PATH and this current work will be > useful in the meantime and the basis for the more work (i.e., not > wasted). > WG Co-Chair Hat ON To add a couple more words here to Sandy's, when RPSEC can resolve their outstanding considerations related to the specification of requirements with respect to securing the AS paths of BGP route updates, then the charter of SIDR indicates that we can then work on ways to meet such requirements. And in saying this I am aware that this has been outstanding for some years now, and the RPSEC draft, draft-ietf-rpsec-bgpsecrec-10.txt is still awaiting a clear consensus from the RPSEC WG. However the alternative, of enjoying a word-for- word replay of the entire RPSEC discussion on possible AS path validation approaches and their relative merits in SIDR does not strike this particular WG co-chair as a productive activity for the SIDR WG. So at this point we are still awaiting RPSEC to complete on its charter before heading off into AS Path validation approaches. Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Nov 19 14:18:41 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FD533A6B83; Wed, 19 Nov 2008 14:18:41 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E7033A6B57 for ; Wed, 19 Nov 2008 14:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mS-V0zEYP1m for ; Wed, 19 Nov 2008 14:18:39 -0800 (PST) Received: from davinci.fing.edu.uy (davinci.fing.edu.uy [164.73.32.2]) by core3.amsl.com (Postfix) with ESMTP id 8F8AB3A6B3A for ; Wed, 19 Nov 2008 14:18:37 -0800 (PST) Received: from [130.129.95.209] ([130.129.95.209]) (authenticated bits=0) by davinci.fing.edu.uy with ESMTP id mAJMHjkt002478; Wed, 19 Nov 2008 20:17:46 -0200 (UYST) Message-Id: <4B6263E8-FB74-4B73-ADBD-D36865669DAD@fing.edu.uy> From: Roque Gagliano To: Geoff Huston In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 16:17:29 -0600 References: <4921DB9F.10205@bbn.com> <7893364D-FE9B-4F00-984E-9F97BA22ECCB@apnic.net> <4921EFEF.50409@bbn.com> X-Pgp-Agent: GPGMail d51 (Leopard) X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (davinci.fing.edu.uy [164.73.32.2]); Wed, 19 Nov 2008 20:17:50 -0200 (UYST) X-Scanned-By: MIMEDefang 2.63 on 164.73.32.2 Cc: "sidr@ietf.org" Subject: Re: [sidr] Two ROA Format issues from the meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0634702504==" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0634702504== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-28--282253188" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-28--282253188 Content-Type: multipart/alternative; boundary=Apple-Mail-27--282253274 --Apple-Mail-27--282253274 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Geoff, I have been thinking on the scenario introduced by a ccTLD that has its DNS server inside a University network and has a different routing policy even if inside the network. They may want to avoid accidental de-aggregation of the university block at large and only allowed it for a small portion (example the ccTLD). There is even ROA 1: University: ROA 1: 10.0.0.0/16 maxlength = 16, AS 1. ROA 2: ccTLD Net: ROA 2: 10.0.0.0/23 maxlength = 24, AS 1. I can also see a case in local anycast implementations where you only want a more specific for the prefix you are anycasting and not necessarily for the rest of the possibilities. In conclusion, I believe that overlapped ROAs will be useful and should be supported in RPKI architecture. r. On Nov 17, 2008, at 11:44 PM, Geoff Huston wrote: > Wg chair hat off > > On 18/11/2008, at 9:27 AM, Matt Lepinski wrote: > >> Geoff, >> >> My understanding of the discussion at the meeting was that the >> proposed prohibition would cover all three cases that you list >> below. The proposal was raised by Rob Kisteleki and Rob Austein, so >> I defer to either of them who would like to clarify. >> >> Either way, it seems to be a small issue, and so I'm inclined to do >> whatever makes implementation of the spec easiest. > > > I could possibly understand this "prohibition" if it was restricted > to enumeration of those cases where the 'overlap' was one where > there was no additional information provided in the overlap. But in > the cases I enumerated below only in case b) is the overlap > redundant in that the announced prefixes that would be matched by > the ROA are identical with or without the overlapping more specific. > In cases a) and c) the overlap defines additional more specifics > > Why are cases a) and c) potentially useful? > > One possible scenario is in TE use, where a prefix holder wants to > load share across two upstreams through the use of more specifics > and have mutual backup via an aggregate > > > ROA 1: 10.0.0.0/8 maxlength = 8 10.0.0.0/16 maxlength=16, AS 1 > > ROA 2: 10.0.0.0/8 maxlength = 8 10.128.0.0/16 maxlength=16, AS 1 > > now if I have this right what this equates to is an explicit > authority for AS 1 and AS 2 to advertise only a certain subset of > more specifics as well as the covering aggregate. > > There may well be other scenarios of such selective authorities. > > >> >> >> - Matt Lepinski >> >> Geoff Huston wrote: >> >>> WG Chair hat off >>> >>> On 18/11/2008, at 8:01 AM, Matt Lepinski wrote: >>> >>>> Two issues came up during the ROA Format presentation at IETF 73: >>>> >>>> 1) Should the ROA Format draft explicitly prohibit a ROA with >>>> overlapping prefixes? >>>> (E.g. A ROA that says AS # 1 can originate routes to 10/8, >>>> 10.10/16 and 10.20/16) >>> >>> >>> What do you mean by overlap Matt? >>> >>> a) 10.0.0.0/8 maxlength=9 and 10.0.0.0/24 maxlength=24 >>> >>> or >>> >>> b) 10.0.0.0/8 maxlength=24 and 10.0.0.0/16 maxlength=16 >>> >>> or >>> >>> c) 10.0.0.0/8 maxlength=17 and 10.0.0.0/16 maxlength=24 >>> >>> seems to me that b) is the only case where the second item is >>> completely subsumed by the first, yet all three contain >>> "overlapping prefixes" >>> >>> It also seems to me that all these cases are essentially harmless. >>> >>> My opinion is NOT to put this prohibition into the document, >>> assuming of course that there is some clarity over what is meant >>> precisely by "overlapping prefixes" in the first place >>> >>> Geoff >>> >>> >>> >>> >> >> > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-27--282253274 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Geoff,

I = have been thinking on the scenario introduced by a ccTLD that has its = DNS server inside a University network and has a different routing = policy even if inside the network. They may want to avoid accidental = de-aggregation of the university block at large and only allowed it for = a small portion (example the ccTLD). There is even =  

ROA 1: University: ROA 1: = 10.0.0.0/16 maxlength =3D 16, AS 1.
ROA 2: ccTLD Net: ROA 2: = 10.0.0.0/23 maxlength =3D 24, AS 1.

I can also = see a case in local anycast implementations where you only want a more = specific for the prefix you are anycasting and = not necessarily for the rest of the = possibilities.

In conclusion, I believe = that overlapped ROAs will be useful and should be supported in = RPKI architecture. =  

r.



On Nov 17, 2008, at 11:44 PM, Geoff Huston = wrote:

Wg chair hat off

On 18/11/2008, at 9:27 AM, = Matt Lepinski wrote:

Geoff,

My = understanding of the discussion at the meeting was that the proposed = prohibition would cover all three cases that you list below. The = proposal was raised by Rob Kisteleki and Rob Austein, so I defer to = either of them who would like to clarify.

Either way, it = seems to be a small issue, and so I'm inclined to do whatever makes = implementation of the spec easiest.


I could = possibly understand this "prohibition" if it was restricted to = enumeration of those cases where the 'overlap' was one where there was = no additional information provided in the overlap. But in the cases I = enumerated below only in case b) is the overlap redundant in that the = announced prefixes that would be matched by the ROA are identical with = or without the overlapping more specific. In cases a) and c) the overlap = defines additional more specifics

Why are cases a) and c) = potentially useful?

One possible scenario is  in TE use, = where a prefix holder wants to load share across two upstreams through = the use of more specifics and have mutual backup via an = aggregate


ROA 1: 10.0.0.0/8 maxlength =3D 8 10.0.0.0/16 = maxlength=3D16, AS 1

ROA 2: 10.0.0.0/8 maxlength =3D 8 = 10.128.0.0/16 maxlength=3D16, AS 1

now if I have this right what = this equates to is an explicit authority for AS 1 and AS 2 to advertise = only a certain subset of more specifics as well as the covering = aggregate.

There may well be other scenarios of such selective = authorities.




- Matt = Lepinski

Geoff Huston = wrote:

WG Chair hat off

On 18/11/2008, at 8:01 AM, Matt = Lepinski wrote:

Two = issues came up during the ROA Format presentation at IETF = 73:

1) = Should the ROA Format draft explicitly prohibit a ROA with =  overlapping = prefixes?
(E.g. = A ROA that says AS # 1 can originate routes to 10/8, 10.10/16  and = 10.20/16)


What do you mean by overlap = Matt?

a) 10.0.0.0/8 maxlength=3D9 and = 10.0.0.0/24 maxlength=3D24

or

b) 10.0.0.0/8 maxlength=3D24 and = 10.0.0.0/16 maxlength=3D16

or

c) 10.0.0.0/8 maxlength=3D17 and = 10.0.0.0/16 maxlength=3D24

seems to me that b) is the only = case where the second item is  completely subsumed by the first, = yet all three contain "overlapping =  prefixes"

It also seems to me that all = these cases are essentially = harmless.

My opinion is NOT to put this = prohibition into the document, assuming  of course that there is = some clarity over what is meant precisely by  "overlapping = prefixes" in the first place

= Geoff







_______________________________________= ________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/m= ailman/listinfo/sidr

= --Apple-Mail-27--282253274-- --Apple-Mail-28--282253188 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkkkkHoACgkQnk+WSgHpbO6jKwCg1G9maOT+ygAfxC9MTTvGlAiu u28An0YJ7j/sjl5EebFzCL0inPL3FeJC =WgDu -----END PGP SIGNATURE----- --Apple-Mail-28--282253188-- --===============0634702504== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --===============0634702504==-- From sidr-bounces@ietf.org Thu Nov 20 08:11:46 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 912873A69F9; Thu, 20 Nov 2008 08:11:46 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFBCA28C212 for ; Thu, 20 Nov 2008 08:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8XSuq+ZRDgO for ; Thu, 20 Nov 2008 08:11:44 -0800 (PST) Received: from davinci.fing.edu.uy (smtp.fing.edu.uy [164.73.32.2]) by core3.amsl.com (Postfix) with ESMTP id 1790028C213 for ; Thu, 20 Nov 2008 08:11:42 -0800 (PST) Received: from [130.129.95.209] ([130.129.95.209]) (authenticated bits=0) by davinci.fing.edu.uy with ESMTP id mAKGBX9c010261; Thu, 20 Nov 2008 14:11:34 -0200 (UYST) Message-Id: From: Roque Gagliano To: Samuel Weiler In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 20 Nov 2008 10:11:18 -0600 References: X-Pgp-Agent: GPGMail d51 (Leopard) X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (davinci.fing.edu.uy [164.73.32.2]); Thu, 20 Nov 2008 14:11:37 -0200 (UYST) X-Scanned-By: MIMEDefang 2.63 on 164.73.32.2 Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Samuel. On Nov 17, 2008, at 10:28 AM, Samuel Weiler wrote: > > > Item 1: May BOAs be issued only by RIRs or also by entities further > down the heirarchy? From section 1: > > "This document defines an application of the Resource Public Key > Infrastructure (RPKI) to validate the attestations of INTERNET > REGISTERIES that certain addresses are currently neither allocated > nor assigned to any party,..." (emphasis added) > Internet Registry > Regional Internet Registry. It includes National Internet Registry and Local Internet Registry. The architecture document uses the term: "internet registry or LIR/ISP". Roque. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkkljCcACgkQnk+WSgHpbO62mQCeMifdEO34/awFjuGt0vItpzcj CqkAnAhpoYbwvJg1e/mHPA5h2mpm7+Xd =erP4 -----END PGP SIGNATURE----- _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Nov 20 08:23:00 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E1A428C20F; Thu, 20 Nov 2008 08:23:00 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FA6B3A67B5 for ; Thu, 20 Nov 2008 08:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lc12ift71rA2 for ; Thu, 20 Nov 2008 08:22:58 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 85C3E3A69D7 for ; Thu, 20 Nov 2008 08:22:58 -0800 (PST) Received: from [130.129.95.247] (helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L3CIo-000Q0f-R1; Thu, 20 Nov 2008 16:22:46 +0000 Message-ID: <49258ED5.7000305@psg.com> Date: Thu, 20 Nov 2008 10:22:45 -0600 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Roque Gagliano References: In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: Samuel Weiler , sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > Internet Registry > Regional Internet Registry. It includes National > Internet Registry and Local Internet Registry. and iana. all register ip addresses and asns. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Nov 20 08:54:58 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 754E328C225; Thu, 20 Nov 2008 08:54:58 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6536928C234 for ; Thu, 20 Nov 2008 08:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBqZaDSNst4z for ; Thu, 20 Nov 2008 08:54:56 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id D397F28C225 for ; Thu, 20 Nov 2008 08:54:55 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id mAKGskZS009691; Thu, 20 Nov 2008 10:54:46 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id mAKGsWxV021163; Thu, 20 Nov 2008 10:54:47 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([130.129.29.89]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 11:51:38 -0500 Date: Thu, 20 Nov 2008 11:51:36 -0500 (Eastern Standard Time) From: Sandra Murphy To: Roque Gagliano In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 20 Nov 2008 16:51:38.0527 (UTC) FILETIME=[4171F2F0:01C94B30] Cc: Samuel Weiler , sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Thu, 20 Nov 2008, Roque Gagliano wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Samuel. > On Nov 17, 2008, at 10:28 AM, Samuel Weiler wrote: >> >> >> Item 1: May BOAs be issued only by RIRs or also by entities further down >> the heirarchy? From section 1: >> >> "This document defines an application of the Resource Public Key >> Infrastructure (RPKI) to validate the attestations of INTERNET >> REGISTERIES that certain addresses are currently neither allocated >> nor assigned to any party,..." (emphasis added) >> > > Internet Registry > Regional Internet Registry. It includes National Internet > Registry and Local Internet Registry. The architecture document uses the > term: "internet registry or LIR/ISP". The use of the terms NIR and LIR are more common in some regions than in others. Those areas where NIR and LIR are seldom used hear "RIR" when "registry" is mentioned. The architecture draft goes through all the possibilities, but does not introduce the "Internet Registry" as the generic term. Given the potential confusion on the part of some, it might be best to inject a parenthetical "(RIR, NIR, LIR/ISP)" in any doc that uses the generic term. But the question still stands, I think. Some entities that receive addresses are not RIR/NIR/LIR. Or so I believe. Is an enterprise that receives address space considered a registry, even if it does not sub-allocate? Hm. What about cell phones that are being handed huge blocks of IPv6 addresses? Don't know that anyone is thinking of running BGP from their cell phone, so maybe the question is moot. --Sandy > > Roque. > > >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > > iEYEARECAAYFAkkljCcACgkQnk+WSgHpbO62mQCeMifdEO34/awFjuGt0vItpzcj > CqkAnAhpoYbwvJg1e/mHPA5h2mpm7+Xd > =erP4 > -----END PGP SIGNATURE----- > _______________________________________________ > 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 sidr-bounces@ietf.org Thu Nov 20 10:53:57 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6D723A6906; Thu, 20 Nov 2008 10:53:57 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66CBA3A6831 for ; Thu, 20 Nov 2008 10:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fs34sgOq0Rhd for ; Thu, 20 Nov 2008 10:53:55 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 36E843A67AF for ; Thu, 20 Nov 2008 10:53:55 -0800 (PST) Received: from CPE-121-222-243-105.qld.bigpond.net.au (CPE-121-222-243-105.qld.bigpond.net.au [121.222.243.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 30150110062; Fri, 21 Nov 2008 04:53:52 +1000 (EST) Message-Id: From: Geoff Huston To: Sandra Murphy In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 21 Nov 2008 05:53:47 +1100 References: X-Mailer: Apple Mail (2.929.2) Cc: Samuel Weiler , sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG chair hat off - speaking as a co-author of the drafts in question On 21/11/2008, at 3:51 AM, Sandra Murphy wrote: > > > On Thu, 20 Nov 2008, Roque Gagliano wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Samuel. >> On Nov 17, 2008, at 10:28 AM, Samuel Weiler wrote: >>> Item 1: May BOAs be issued only by RIRs or also by entities >>> further down the heirarchy? From section 1: >>> >>> "This document defines an application of the Resource Public Key >>> Infrastructure (RPKI) to validate the attestations of INTERNET >>> REGISTERIES that certain addresses are currently neither allocated >>> nor assigned to any party,..." (emphasis added) >> >> Internet Registry > Regional Internet Registry. It includes >> National Internet Registry and Local Internet Registry. The >> architecture document uses the term: "internet registry or LIR/ISP". > > The use of the terms NIR and LIR are more common in some regions > than in others. Those areas where NIR and LIR are seldom used hear > "RIR" when "registry" is mentioned. The architecture draft goes > through all the possibilities, but does not introduce the "Internet > Registry" as the generic term. Given the potential confusion on the > part of some, it might be best to inject a parenthetical "(RIR, NIR, > LIR/ISP)" in any doc that uses the generic term. I hear your request, but the textual change suggested seems to me to be no better - the generic term of an "internet registry" is used to describe those entities who perform an allocation / assignment function for Internet number resources. If Sam's a priori interpretation of the term is more restricted than that broad intention then I can see some merit in making the change as a note in terminology, but I don't see it as such a big issue that it warrants a new rev of the documents just for this point. > > > But the question still stands, I think. Some entities that receive > addresses are not RIR/NIR/LIR. Or so I believe. Is an enterprise > that receives address space considered a registry, even if it does > not sub-allocate? > > > Hm. What about cell phones that are being handed huge blocks of > IPv6 addresses? Don't know that anyone is thinking of running BGP > from their cell phone, so maybe the question is moot. > I smell a reductio absurdum argument being made here - I don't think it leads anywhere useful for me! Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Nov 20 11:25:06 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE9E03A6BDA; Thu, 20 Nov 2008 11:25:06 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C61E63A6BB8 for ; Thu, 20 Nov 2008 11:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTbntQmMj9B3 for ; Thu, 20 Nov 2008 11:25:01 -0800 (PST) Received: from davinci.fing.edu.uy (smtp.fing.edu.uy [164.73.32.2]) by core3.amsl.com (Postfix) with ESMTP id 5DECF3A6BAD for ; Thu, 20 Nov 2008 11:25:00 -0800 (PST) Received: from [130.129.95.209] ([130.129.95.209]) (authenticated bits=0) by davinci.fing.edu.uy with ESMTP id mAKJOmsa013933; Thu, 20 Nov 2008 17:24:50 -0200 (UYST) Message-Id: <380A5082-6B9D-4CE3-8008-B3F55F928331@fing.edu.uy> From: Roque Gagliano To: Sandra Murphy In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 20 Nov 2008 13:24:34 -0600 References: X-Pgp-Agent: GPGMail d51 (Leopard) X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (davinci.fing.edu.uy [164.73.32.2]); Thu, 20 Nov 2008 17:24:54 -0200 (UYST) X-Scanned-By: MIMEDefang 2.63 on 164.73.32.2 Cc: Samuel Weiler , sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > The architecture draft goes through all the possibilities, but does > not introduce the "Internet Registry" as the generic term. RFC 2050 does (The Internet Registry system) , maybe a ref. is enough. > Given the potential confusion on the part of some, it might be best > to inject a parenthetical "(RIR, NIR, LIR/ISP)" in any doc that uses > the generic term. > > But the question still stands, I think. Some entities that receive > addresses are not RIR/NIR/LIR. Or so I believe. Is an enterprise > that receives address space considered a registry, even if it does > not sub-allocate? In the "registry policy" world, they are called "End Users". Why we do not just use the term: "Certificate Holders", independently of where they are in the hierarchy? Roque -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkkluXIACgkQnk+WSgHpbO5BzQCgql5e+j0EtAC+isZfpiL8lkij ZOEAniwEMI+0oL0CoIwYNHKibmq7xjCV =wa0e -----END PGP SIGNATURE----- _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Nov 20 11:58:44 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB83E28C22A; Thu, 20 Nov 2008 11:58:44 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D923E28C1F4 for ; Thu, 20 Nov 2008 11:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEFUU9YUdcVH for ; Thu, 20 Nov 2008 11:58:42 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id CB92928C0FD for ; Thu, 20 Nov 2008 11:58:41 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id mAKJwItr013275; Thu, 20 Nov 2008 13:58:18 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id mAKJwH7s029589; Thu, 20 Nov 2008 13:58:18 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([130.129.29.89]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 14:58:16 -0500 Date: Thu, 20 Nov 2008 14:58:13 -0500 (Eastern Standard Time) From: Sandra Murphy To: Geoff Huston In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 20 Nov 2008 19:58:16.0555 (UTC) FILETIME=[53FD6BB0:01C94B4A] Cc: Samuel Weiler , sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Fri, 21 Nov 2008, Geoff Huston wrote: > WG chair hat off - speaking as a co-author of the drafts in question > > On 21/11/2008, at 3:51 AM, Sandra Murphy wrote: > >> >> >> On Thu, 20 Nov 2008, Roque Gagliano wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Samuel. >>> On Nov 17, 2008, at 10:28 AM, Samuel Weiler wrote: >>>> Item 1: May BOAs be issued only by RIRs or also by entities further down >>>> the heirarchy? From section 1: >>>> >>>> "This document defines an application of the Resource Public Key >>>> Infrastructure (RPKI) to validate the attestations of INTERNET >>>> REGISTERIES that certain addresses are currently neither allocated >>>> nor assigned to any party,..." (emphasis added) >>> >>> Internet Registry > Regional Internet Registry. It includes National >>> Internet Registry and Local Internet Registry. The architecture document >>> uses the term: "internet registry or LIR/ISP". >> >> The use of the terms NIR and LIR are more common in some regions than in >> others. Those areas where NIR and LIR are seldom used hear "RIR" when >> "registry" is mentioned. The architecture draft goes through all the >> possibilities, but does not introduce the "Internet Registry" as the >> generic term. Given the potential confusion on the part of some, it might >> be best to inject a parenthetical "(RIR, NIR, LIR/ISP)" in any doc that >> uses the generic term. > > I hear your request, but the textual change suggested seems to me to be no > better - the generic term of an "internet registry" is used to describe those > entities who perform an allocation / assignment function for Internet number > resources. If Sam's a priori interpretation of the term is more restricted > than that broad intention then I can see some merit in making the change as a > note in terminology, but I don't see it as such a big issue that it warrants > a new rev of the documents just for this point. Agree not important enough to warrant a new rev on its own, but should be considered if a new rev is necessary for other more pressing reasons. > > >> >> >> But the question still stands, I think. Some entities that receive >> addresses are not RIR/NIR/LIR. Or so I believe. Is an enterprise that >> receives address space considered a registry, even if it does not >> sub-allocate? >> >> >> Hm. What about cell phones that are being handed huge blocks of IPv6 >> addresses? Don't know that anyone is thinking of running BGP from their >> cell phone, so maybe the question is moot. >> > > I smell a reductio absurdum argument being made here - I don't think it leads > anywhere useful for me! If you mean the cell phone comment, that was an idle thought that made its way to my fingertips while I typed. You can ignore it. I would however like you to answer the question of whether there exist entities that might do ROAs and BOAs but are not Internet Registries. I am one of those people who do not normally use the term Internet Registry and I do not know if it covers enterprises that receive allocations and do BGP. --Sandy > > > Geoff > > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Nov 20 13:53:46 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AE213A68D4; Thu, 20 Nov 2008 13:53:46 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 088E93A68D4 for ; Thu, 20 Nov 2008 13:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evE7Yxaa0kNR for ; Thu, 20 Nov 2008 13:53:44 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 32DA33A677D for ; Thu, 20 Nov 2008 13:53:44 -0800 (PST) Received: from [58.163.12.74] (unknown [58.163.12.74]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 1241C110062; Fri, 21 Nov 2008 07:53:40 +1000 (EST) Message-Id: <6C79205F-06A5-45B5-9E7F-47F8CB7B3FD1@apnic.net> From: Geoff Huston To: Sandra Murphy In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 21 Nov 2008 08:53:38 +1100 References: X-Mailer: Apple Mail (2.929.2) Cc: Samuel Weiler , sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > WG Chair hat OFF. > I would however like you to answer the question of whether there > exist entities that might do ROAs and BOAs but are not Internet > Registries. I am one of those people who do not normally use the > term Internet Registry and I do not know if it covers enterprises > that receive allocations and do BGP. > In some parts of the world such entities are termed "LIRs" and fall within the category of "Internet Registry". In other parts of the world they are generically referred to as ISPs, even though the term is loosely used to encompass all types of entities that "receive allocations and do BGP". Others use a mix of terms, including "End User" where in the context of use it is explicitly not referring to an individual person or an end user in the traditional sense. The draft used the term in the broad sense of the first usage quoted here. Obviously there is a wealth of terms for such use. Whatever usage convention SIDR might attempt to invent over and above the existing set might well have a rather limited context of use, and may well serve to add to the resultant terminology confusion rather than reduce it. Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Nov 20 14:49:57 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307E03A6898; Thu, 20 Nov 2008 14:49:57 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94BBF3A6898 for ; Thu, 20 Nov 2008 14:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmMKmNF0fC+v for ; Thu, 20 Nov 2008 14:49:55 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id C0AA23A677D for ; Thu, 20 Nov 2008 14:49:55 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.78.165]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1L3ILP-0002kQ-BO for sidr@ietf.org; Thu, 20 Nov 2008 17:49:51 -0500 Mime-Version: 1.0 Message-Id: Date: Thu, 20 Nov 2008 17:49:49 -0500 To: sidr@ietf.org From: Stephen Kent Subject: [sidr] BOA comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Folks, At the SIDR meeting this week, I proposed that we add text to the ROA I-D to explicitly describe issuing a ROA with a reserved ASN, e.g., 0. The intent of this convention is to prevent unauthenticated assertions about prefixes from being accepted during the very long, incremental deployment period. I received a rousing, negative response to this proposal, so It will not be added to the ROA format I-D. (I do note that, even without establishing this convention, any ROA issuer is free to achieve the effect I described by issuing a ROA to any ASN that is not going to be allocated, e.g., ASN 0 or the ASN's being reserved for documentation use in an forthcoming RFC.) Based on this response, I believe that the BOA I-D would have received an equally negative reception, if it had been briefed. I note that BOA processing requires additional logic to achieve what appears to be an largely equivalent effect, while the ROA convention I proposed has the desired effect without any new processing logic. I am surprised that the BOA I-D, which is now in WGLC, has not generated any comments. So, I suggest, with regret, that the BOA I-D is not acceptable to the WG, but has simply not received negative comments because of the focus on other WG documents at this time. If folks believe otherwise, I'd like to hear why. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Nov 20 16:33:56 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14BF23A6898; Thu, 20 Nov 2008 16:33:56 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 629043A6898 for ; Thu, 20 Nov 2008 16:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUpfhN1q2q0z for ; Thu, 20 Nov 2008 16:33:54 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id BD5183A6873 for ; Thu, 20 Nov 2008 16:33:54 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.78.165]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1L3Jy2-0003uo-CV; Thu, 20 Nov 2008 19:33:50 -0500 Mime-Version: 1.0 Message-Id: Date: Thu, 20 Nov 2008 19:33:49 -0500 To: sidr@ietf.org From: Stephen Kent Subject: [sidr] whoops X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org I have been informed by Sandy that there has been considerable discussion on the bogon and ROA validation drafts on the SIDR list over the last few days. It turns out that I have NOT been receiving SIDR list messages since 11/11. I apologize for the tone of my message, given the lack of context. I will now try to catch up, by reading those messages. Sorry 'bout that, Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Nov 20 16:45:43 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2BF33A6873; Thu, 20 Nov 2008 16:45:43 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8CFF3A6873 for ; Thu, 20 Nov 2008 16:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfJ0eYbWYR8N for ; Thu, 20 Nov 2008 16:45:42 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 2EE7D3A67F0 for ; Thu, 20 Nov 2008 16:45:42 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.78.165]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1L3K9U-00042P-Aq; Thu, 20 Nov 2008 19:45:40 -0500 Mime-Version: 1.0 Message-Id: Date: Thu, 20 Nov 2008 19:41:28 -0500 To: sidr@ietf.org From: Stephen Kent Subject: Re: [sidr] only one RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Andy, In looking through the SIDR archives (since I am not getting messages directly from the list) I saw the following posting: >Incidentally, I thought I heard Russ Housley say at the mike that >the cert format says what CP appliels and it points to this CP. If I >understand, using a different CP means changing the cert format. Am >I wrong? >I see the following, which I presume is what Russ was referring to: > >3.9.8. Certificate Policies > > This extension MUST reference the Resource Certificate Policy, using > the OID Policy Identifier value of "1.3.6.1.5.5.7.14.2". This field > MUST be present and MUST contain only this value for Resource > Certificates. > > No PolicyQualifiers are defined for use with this policy and thus > none must be included in this extension. > > This extension MUST be present and it is critical. If you do not follow the CP that has the OID in the CP that is under discussion in SIDR, then you must not issue certs containing that OID in the cert policy field. You could issue certs with a different policy OID, or with no policy OID. Niether would meet the criteria for RPKI Certs, and thus should be rejected by compliant relying party software. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Nov 20 17:48:09 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC5633A689E; Thu, 20 Nov 2008 17:48:09 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FB623A689E for ; Thu, 20 Nov 2008 17:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hexmcV9B33H for ; Thu, 20 Nov 2008 17:48:08 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id 0DC8A3A6873 for ; Thu, 20 Nov 2008 17:48:08 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1L3L7r-0004Ap-5O; Fri, 21 Nov 2008 02:48:05 +0100 Received: from andrei-robachevskys-macbook-pro-15.local (gw.office.nsrp.ripe.net [193.0.1.126]) by herring.ripe.net (Postfix) with ESMTP id AA4A62F583; Fri, 21 Nov 2008 02:48:02 +0100 (CET) Message-ID: <49261352.8010409@ripe.net> Date: Fri, 21 Nov 2008 02:48:02 +0100 From: Andrei Robachevsky User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Stephen Kent References: In-Reply-To: X-Enigmail-Version: 0.95.7 X-RIPE-Spam-Level: ---- X-RIPE-Signature: 4330a47f43bd7e517cd9d6f2bba43afb11319eab01efbf00942064a4f6fb037c Cc: sidr@ietf.org Subject: Re: [sidr] only one RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Steve, Am I correct assuming that the OID will be assigned once the I-D becomes an RFC? But I find it rather strange that cp(14) is not registered as well. Has it not been used in the pkix context? Thanks, Andrei Stephen Kent wrote on 21-11-2008 01:41: > Andy, > > In looking through the SIDR archives (since I am not getting messages > directly from the list) I saw the following posting: > >> Incidentally, I thought I heard Russ Housley say at the mike that the >> cert format says what CP appliels and it points to this CP. If I >> understand, using a different CP means changing the cert format. Am I >> wrong? >> I see the following, which I presume is what Russ was referring to: >> >> 3.9.8. Certificate Policies >> >> This extension MUST reference the Resource Certificate Policy, using >> the OID Policy Identifier value of "1.3.6.1.5.5.7.14.2". This field >> MUST be present and MUST contain only this value for Resource >> Certificates. >> >> No PolicyQualifiers are defined for use with this policy and thus >> none must be included in this extension. >> >> This extension MUST be present and it is critical. > > If you do not follow the CP that has the OID in the CP that is under > discussion in SIDR, then you must not issue certs containing that OID in > the cert policy field. You could issue certs with a different policy > OID, or with no policy OID. Niether would meet the criteria for RPKI > Certs, and thus should be rejected by compliant relying party software. > > Steve > _______________________________________________ > 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 sidr-bounces@ietf.org Thu Nov 20 23:26:56 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 598F63A68DF; Thu, 20 Nov 2008 23:26:56 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15F193A68DF for ; Thu, 20 Nov 2008 23:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdFugVX5SYL5 for ; Thu, 20 Nov 2008 23:26:53 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 47D433A679F for ; Thu, 20 Nov 2008 23:26:53 -0800 (PST) Received: from dhcp180.apnic.net (dhcp180.apnic.net [202.12.29.180]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 07FB4110062; Fri, 21 Nov 2008 17:26:51 +1000 (EST) Message-Id: From: Robert Loomans To: Andrei Robachevsky In-Reply-To: <49261352.8010409@ripe.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 21 Nov 2008 17:26:47 +1000 References: <49261352.8010409@ripe.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] only one RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1573524185==" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org --===============1573524185== Content-Type: multipart/signed; boundary=Apple-Mail-1--162892423; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-1--162892423 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 21/11/2008, at 11:48, Andrei Robachevsky wrote: > Steve, > > Am I correct assuming that the OID will be assigned once the I-D > becomes > an RFC? > > But I find it rather strange that cp(14) is not registered as well. > Has > it not been used in the pkix context? > The PKIX OIDs are maintained at http://www.imc.org/ietf-pkix/pkix-oid.asn Both id-cp(id-pkix 14) and id-cp-sbgpCertificatePolicy(id-cp 1) are already assigned. Cheers, Rob -- Robert Loomans Email: robertl@apnic.net Senior Software Engineer, APNIC Phone: +61 7 3858 3100 http://www.apnic.net Fax: +61 7 3858 3199 --Apple-Mail-1--162892423 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFdDCCBXAw ggRYoAMCAQICAithMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UEChMFQVBO SUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmljLm5l dDAeFw0wODA5MjYwNzQ1MDlaFw0wOTA5MjYwNzQ1MDlaMEkxCzAJBgNVBAYTAkFQMREwDwYDVQQK EwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDjAMBgNVBAUTBTExMTA1MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3z92063wWTukPtRv0ZrOumNcHII4mWyKdZqOY2M8 TjgTtwuSLfyXz1kJgM4EzeL4Di9VCPHxiIeOpOh5lBLz0BOZi9cs9Wr7HpiaaKSj5bMGrYleg3tV p1d2zUA3J1ar7bblTjlIOmO8YaazpPLmu4jtaO7XsGZq1zYNIPpsTdpliHSjipHPp0vIogXd/omA ZdmCSTVplS/XDYWwoY5fByctVZkMmaV1kLdMJatuB5nOQ2OJna9ChQ4q95OJmTWtWj7txQJiBC7n rMVnhVb/lXA4EyEo/UpuBqClGPB+SNQsyu+4MtSucyIM5brqUSvZvG5dY1p2aG1LfdhtEG8k9QID AQABo4ICGjCCAhYwCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCcG CWCGSAGG+EIBDQQaFhhBUE5JQyBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFBA9EWg0YXaM 16SWXYapPuroBl6wMIG7BgNVHSMEgbMwgbCAFBSGArCuuEux79Pr4vuSKIV3jATpoYGUpIGRMIGO MQswCQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNl czEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqG SIb3DQEJARYTY2FtYW5hZ2VyQGFwbmljLm5ldIIBADAcBgNVHREEFTATgRFyb2JlcnRsQGFwbmlj Lm5ldDAeBgNVHRIEFzAVgRNjYW1hbmFnZXJAYXBuaWMubmV0MDcGA1UdHwQwMC4wLKAqoCiGJmh0 dHBzOi8vd3d3LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBBAQoFiZodHRw czovL3d3dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cHM6 Ly93d3cuYXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAI2Uphkw UOLXzEaRdOUFJ4qQNH9qST2531GY9BUTF6/Otapl2/4q7VFH9xyqOQr+pqNq4ytu5zRo/1hV6N4g pCdLAAcGj/ntNKM02y4FtR2Q+GZdL/S5xNb4t5GzZYFGGqD1uq0HFXQdCkP1zgxZXvL8oUZFyYNG 49X7En8h+ETtjd4+nzDUpNRxlVmDGYuk2sHhrM1jyBJRoKp5pwOj4n5wbTsjqF9blQd11gu1aAxa rCPpj3LGjrZBDS2ZJ2YAWvCQEA0VQX4kTTdtje33ercxc1GiaV/fQ9PLTRJy0ROLo0aKFdddvZJt S2QtQIEIAk8QU51W64ho/y12+/1cjQYxggNyMIIDbgIBATCBlTCBjjELMAkGA1UEBhMCQVUxDjAM BgNVBAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNVBAMTJUFQTklD IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0BCQEWE2NhbWFuYWdl ckBhcG5pYy5uZXQCAithMAkGBSsOAwIaBQCgggGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MTEyMTA3MjY0OFowIwYJKoZIhvcNAQkEMRYEFLdKurwY/jb7xFdM wBZIVpvAGG4MMIGmBgkrBgEEAYI3EAQxgZgwgZUwgY4xCzAJBgNVBAYTAkFVMQ4wDAYDVQQKEwVB UE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQDEyVBUE5JQyBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkBFhNjYW1hbmFnZXJAYXBuaWMu bmV0AgIrYTCBqAYLKoZIhvcNAQkQAgsxgZiggZUwgY4xCzAJBgNVBAYTAkFVMQ4wDAYDVQQKEwVB UE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQDEyVBUE5JQyBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkBFhNjYW1hbmFnZXJAYXBuaWMu bmV0AgIrYTANBgkqhkiG9w0BAQEFAASCAQB4IdcJJ/2oIFwfiyEN/20tYHdFlkKMFKF1pGrg3lVj C8XtgexSoplmrHbCrH9Ne0tQmV2aRrXjgaddasu7H7sqthn6zPPGynU7UHm5jYWQA7IlSqvkNWcE 7fgDCeEvl5ejAgegDl7D5a3jWKki0PWUhAoAnWgfLa5wYjx5+t5mcoi0i+oc6m2kK2UVuZ2v7gL1 qDEPLXaya4n3I9OZZczV/ZntnIWen8bNpk0NHLjf58S2mA2y2fcaFfD6e8GFV0JUchCoZqy9KcHn DA8SCu+mIs4V3MAYD97BZdTAsntolAB2+yJkzqyM4BUSJXXMX5qm1foutM4gXKB8Jzfvh9kxAAAA AAAA --Apple-Mail-1--162892423-- --===============1573524185== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --===============1573524185==-- From sidr-bounces@ietf.org Fri Nov 21 06:16:42 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 440ED3A691C; Fri, 21 Nov 2008 06:16:42 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E86363A691C for ; Fri, 21 Nov 2008 06:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r94vwqD-GKOv for ; Fri, 21 Nov 2008 06:16:40 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id 0079F3A67ED for ; Fri, 21 Nov 2008 06:16:39 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1L3WoF-00018y-75; Fri, 21 Nov 2008 15:16:37 +0100 Received: from andrei-robachevskys-macbook-pro-15.local (gw.office.nsrp.ripe.net [193.0.1.126]) by herring.ripe.net (Postfix) with ESMTP id B5C052F598; Fri, 21 Nov 2008 15:16:34 +0100 (CET) Message-ID: <4926C2C2.9030600@ripe.net> Date: Fri, 21 Nov 2008 15:16:34 +0100 From: Andrei Robachevsky User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Robert Loomans References: <49261352.8010409@ripe.net> In-Reply-To: X-Enigmail-Version: 0.95.7 X-RIPE-Spam-Level: ---- X-RIPE-Signature: 4330a47f43bd7e517cd9d6f2bba43afb547a633fd983ed1b1fdf48995d5bcb3e Cc: sidr@ietf.org Subject: Re: [sidr] only one RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Thanks for clarification Rob. Andrei Robert Loomans wrote on 21-11-2008 08:26: > > On 21/11/2008, at 11:48, Andrei Robachevsky wrote: > >> Steve, >> >> Am I correct assuming that the OID will be assigned once the I-D becomes >> an RFC? >> >> But I find it rather strange that cp(14) is not registered as well. Has >> it not been used in the pkix context? >> > > The PKIX OIDs are maintained at http://www.imc.org/ietf-pkix/pkix-oid.asn > > Both id-cp(id-pkix 14) and id-cp-sbgpCertificatePolicy(id-cp 1) are > already assigned. > > Cheers, > Rob > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Nov 21 06:34:52 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01BE83A67ED; Fri, 21 Nov 2008 06:34:52 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECF493A67ED for ; Fri, 21 Nov 2008 06:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqchmL1pgjcG for ; Fri, 21 Nov 2008 06:34:49 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by core3.amsl.com (Postfix) with ESMTP id C865B3A679C for ; Fri, 21 Nov 2008 06:34:49 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id 35541A68BE; Fri, 21 Nov 2008 09:34:48 -0500 (EST) Received: from ex.arin.net (cas2.arin.net [192.136.136.239]) by smtp2.arin.net (Postfix) with ESMTP id A69B4A68BE; Fri, 21 Nov 2008 09:34:47 -0500 (EST) Received: from EDAMAME.arin.net ([192.136.136.194]) by cas2.arin.net ([192.136.136.239]) with mapi; Fri, 21 Nov 2008 09:34:47 -0500 From: Andy Newton To: Stephen Kent , "sidr@ietf.org" Date: Fri, 21 Nov 2008 09:34:46 -0500 Thread-Topic: [sidr] only one RPKI Thread-Index: AclLcn77ewju/9FpS2ek+hYzamRcugAc83Wz Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [sidr] only one RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 11/20/08 7:41 PM, "Stephen Kent" wrote: > If you do not follow the CP that has the OID in the CP that is under > discussion in SIDR, then you must not issue certs containing that OID > in the cert policy field. You could issue certs with a different > policy OID, or with no policy OID. Niether would meet the criteria > for RPKI Certs, and thus should be rejected by compliant relying > party software. Steve, This explanation helps my understanding significantly. Thanks. Regarding the rejection by complaint relying party software: this is because the validation step includes looking for the specific OID assigned by the CP draft? In other words, if another CP assigned another OID and the relying party software could be configured to additionally accommodate said OID, then this specification suite could be used in a slightly different context? -andy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Nov 21 12:03:25 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 335D13A688B; Fri, 21 Nov 2008 12:03:25 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 856F23A6964 for ; Fri, 21 Nov 2008 10:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wp1XgMurmYjq for ; Fri, 21 Nov 2008 10:24:04 -0800 (PST) Received: from midgard.seastrom.com (midgard.seastrom.com [IPv6:2610:178:1:1:203:47ff:fefd:df3e]) by core3.amsl.com (Postfix) with ESMTP id A75B33A6452 for ; Fri, 21 Nov 2008 10:24:04 -0800 (PST) Received: from [216.12.128.172] (helo=[172.27.1.100]) by midgard.seastrom.com with esmtpsa (TLSv1:AES128-SHA:128) (authenticated id=box0219) id 1L3afi-000NGM-0R for sidr@ietf.org; Fri, 21 Nov 2008 13:24:02 -0500 Message-Id: <036B042D-D58A-4CE2-8216-26C8D2DD12BC@istaff.org> From: John Curran To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 21 Nov 2008 13:23:59 -0500 X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] only one RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0919368261==" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org --===============0919368261== Content-Type: multipart/alternative; boundary=Apple-Mail-4--123463528 --Apple-Mail-4--123463528 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Andy Newton wrote: > > Steve, This explanation helps my understanding significantly. Thanks. > Regarding the rejection by complaint relying party software: this is > because the validation step includes looking for the specific OID > assigned by the CP draft? In other words, if another CP assigned > another OID and the relying party software could be configured to > additionally accommodate said OID, then this specification suite > could be used in a slightly different context? This would, of course, presume that there was a pressing need for the community to have two CP's for two different systems that both looked like rPKI infrastructures, and I'll admit that I'm having trouble imagining why that would be desirable for our community. /John --Apple-Mail-4--123463528 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
Andy Newton <andy@arin.net> wrote:
Steve,

This explanation helps my understanding significantly.  Thanks.
Regarding the rejection by complaint relying party software: this is because
the validation step includes looking for the specific OID assigned by the CP
draft?  In other words, if another CP assigned another OID and the relying
party software could be configured to additionally accommodate said OID,
then this specification suite could be used in a slightly different context? 
This would, of course, presume that there was a pressing need for the community to have two CP's for two different systems that both looked like rPKI infrastructures, and I'll admit that I'm having trouble imagining why that would be desirable for our community.

/John

--Apple-Mail-4--123463528-- --===============0919368261== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --===============0919368261==-- From sidr-bounces@ietf.org Sat Nov 22 19:38:54 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31A853A6B5C; Sat, 22 Nov 2008 19:38:54 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B5A53A6B5C for ; Sat, 22 Nov 2008 19:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BeKSosDXIl2 for ; Sat, 22 Nov 2008 19:38:51 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id DFCC73A67A3 for ; Sat, 22 Nov 2008 19:38:51 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 7F0242684EC; Sat, 22 Nov 2008 20:38:49 -0700 (MST) Received: from [192.168.0.100] (97-122-99-176.hlrn.qwest.net [97.122.99.176]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sat, 22 Nov 2008 20:38:49 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.99.176; client-port=56983; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: From: Danny McPherson To: Henk Uijterwaal In-Reply-To: <4922EC8F.4050406@ripe.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 22 Nov 2008 20:38:47 -0700 References: <4922E1E3.4020608@ripe.net> <4922EC8F.4050406@ripe.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] RPSLSIG adoption? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Nov 18, 2008, at 9:25 AM, Henk Uijterwaal wrote: > Robert Kisteleki wrote: >> Hi, >> After my (rushed) presentation yesterday I'd like to ask if there >> are people in the WG who think that this idea is worth pursuing and >> should it be a WG item? I support the work as well, and am quite interested in any work items that further enable employment of RPKI. I too am left wondering if scope creep of SIDR is going to be an issue, but I'm not sure where else in the IETF this work would be done at the moment. Either we need the charter here explicitly extended to include more work on deployment and extensions to adjacent protocols (e.g., RPSL) if the relevant working groups are defunct, or we need a 'sidrd' WG, or an RPS WG resurrection, or we need to discuss just how to address the issue. I'd also note that the very expired WG Goals and Milestones aren't useful in providing guidance. > I like the idea but I think this question should be asked on the RPSL > list as well before deciding which group should pick it up. What RPSL list are you referring to here? -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sat Nov 22 20:49:14 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4253B3A686C; Sat, 22 Nov 2008 20:49:14 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D9033A686C for ; Sat, 22 Nov 2008 20:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CUKTBPJuw7b for ; Sat, 22 Nov 2008 20:49:12 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 145E23A6405 for ; Sat, 22 Nov 2008 20:49:12 -0800 (PST) Received: from [192.168.10.30] (203-214-125-230.dyn.iinet.net.au [203.214.125.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id DF916110062 for ; Sun, 23 Nov 2008 14:49:08 +1000 (EST) Message-ID: <4928E0C4.1090009@apnic.net> Date: Sun, 23 Nov 2008 14:49:08 +1000 From: Robert Loomans Organization: APNIC - http://www.apnic.net/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: "sidr@ietf.org" References: <4922E1E3.4020608@ripe.net> In-Reply-To: <4922E1E3.4020608@ripe.net> X-Enigmail-Version: 0.95.7 OpenPGP: id=C6B3AE7E; url=http://robert.loomans.org/0xC6B3AE7E.asc Subject: Re: [sidr] RPSLSIG adoption? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0522842971==" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0522842971== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080705030305000307080902" This is a cryptographically signed message in MIME format. --------------ms080705030305000307080902 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Robert Kisteleki wrote: > Hi, > > After my (rushed) presentation yesterday I'd like to ask if there are > people in the WG who think that this idea is worth pursuing and should > it be a WG item? > > http://www.ietf.org/internet-drafts/draft-kisteleki-sidr-rpsl-sig-00.txt > http://www3.ietf.org/proceedings/08nov/slides/sidr-3.pdf I'm happy to see this adopted as a WG item... and I will participate in discussion and review. Rob -- Robert Loomans Email: robertl@apnic.net Senior Software Engineer, APNIC Phone: +61 7 3858 3100 http://www.apnic.net Fax: +61 7 3858 3199 --------------ms080705030305000307080902 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK6DCC BXAwggRYoAMCAQICAithMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UE ChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5h Z2VyQGFwbmljLm5ldDAeFw0wODA5MjYwNzQ1MDlaFw0wOTA5MjYwNzQ1MDlaMEkxCzAJBgNV BAYTAkFQMREwDwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDjAM BgNVBAUTBTExMTA1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3z92063wWTuk PtRv0ZrOumNcHII4mWyKdZqOY2M8TjgTtwuSLfyXz1kJgM4EzeL4Di9VCPHxiIeOpOh5lBLz 0BOZi9cs9Wr7HpiaaKSj5bMGrYleg3tVp1d2zUA3J1ar7bblTjlIOmO8YaazpPLmu4jtaO7X sGZq1zYNIPpsTdpliHSjipHPp0vIogXd/omAZdmCSTVplS/XDYWwoY5fByctVZkMmaV1kLdM JatuB5nOQ2OJna9ChQ4q95OJmTWtWj7txQJiBC7nrMVnhVb/lXA4EyEo/UpuBqClGPB+SNQs yu+4MtSucyIM5brqUSvZvG5dY1p2aG1LfdhtEG8k9QIDAQABo4ICGjCCAhYwCQYDVR0TBAIw ADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCcGCWCGSAGG+EIBDQQaFhhBUE5J QyBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFBA9EWg0YXaM16SWXYapPuroBl6wMIG7 BgNVHSMEgbMwgbCAFBSGArCuuEux79Pr4vuSKIV3jATpoYGUpIGRMIGOMQswCQYDVQQGEwJB VTEOMAwGA1UEChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UE AxMlQVBOSUMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJ ARYTY2FtYW5hZ2VyQGFwbmljLm5ldIIBADAcBgNVHREEFTATgRFyb2JlcnRsQGFwbmljLm5l dDAeBgNVHRIEFzAVgRNjYW1hbmFnZXJAYXBuaWMubmV0MDcGA1UdHwQwMC4wLKAqoCiGJmh0 dHBzOi8vd3d3LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBBAQoFiZo dHRwczovL3d3dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDA1BglghkgBhvhCAQMEKBYm aHR0cHM6Ly93d3cuYXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAI2UphkwUOLXzEaRdOUFJ4qQNH9qST2531GY9BUTF6/Otapl2/4q7VFH9xyqOQr+pqNq 4ytu5zRo/1hV6N4gpCdLAAcGj/ntNKM02y4FtR2Q+GZdL/S5xNb4t5GzZYFGGqD1uq0HFXQd CkP1zgxZXvL8oUZFyYNG49X7En8h+ETtjd4+nzDUpNRxlVmDGYuk2sHhrM1jyBJRoKp5pwOj 4n5wbTsjqF9blQd11gu1aAxarCPpj3LGjrZBDS2ZJ2YAWvCQEA0VQX4kTTdtje33ercxc1Gi aV/fQ9PLTRJy0ROLo0aKFdddvZJtS2QtQIEIAk8QU51W64ho/y12+/1cjQYwggVwMIIEWKAD AgECAgIrYTANBgkqhkiG9w0BAQUFADCBjjELMAkGA1UEBhMCQVUxDjAMBgNVBAoTBUFQTklD MRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNVBAMTJUFQTklDIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0BCQEWE2NhbWFuYWdlckBhcG5p Yy5uZXQwHhcNMDgwOTI2MDc0NTA5WhcNMDkwOTI2MDc0NTA5WjBJMQswCQYDVQQGEwJBUDER MA8GA1UEChMIQVBOSUMtQVAxFzAVBgNVBAMTDlJvYmVydCBMb29tYW5zMQ4wDAYDVQQFEwUx MTEwNTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN8/dtOt8Fk7pD7Ub9Gazrpj XByCOJlsinWajmNjPE44E7cLki38l89ZCYDOBM3i+A4vVQjx8YiHjqToeZQS89ATmYvXLPVq +x6Ymmiko+WzBq2JXoN7VadXds1ANydWq+225U45SDpjvGGms6Ty5ruI7Wju17Bmatc2DSD6 bE3aZYh0o4qRz6dLyKIF3f6JgGXZgkk1aZUv1w2FsKGOXwcnLVWZDJmldZC3TCWrbgeZzkNj iZ2vQoUOKveTiZk1rVo+7cUCYgQu56zFZ4VW/5VwOBMhKP1KbgagpRjwfkjULMrvuDLUrnMi DOW66lEr2bxuXWNadmhtS33YbRBvJPUCAwEAAaOCAhowggIWMAkGA1UdEwQCMAAwEQYJYIZI AYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAnBglghkgBhvhCAQ0EGhYYQVBOSUMgQ2xpZW50 IENlcnRpZmljYXRlMB0GA1UdDgQWBBQQPRFoNGF2jNekll2GqT7q6AZesDCBuwYDVR0jBIGz MIGwgBQUhgKwrrhLse/T6+L7kiiFd4wE6aGBlKSBkTCBjjELMAkGA1UEBhMCQVUxDjAMBgNV BAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNVBAMTJUFQTklD IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0BCQEWE2NhbWFu YWdlckBhcG5pYy5uZXSCAQAwHAYDVR0RBBUwE4ERcm9iZXJ0bEBhcG5pYy5uZXQwHgYDVR0S BBcwFYETY2FtYW5hZ2VyQGFwbmljLm5ldDA3BgNVHR8EMDAuMCygKqAohiZodHRwczovL3d3 dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDA1BglghkgBhvhCAQQEKBYmaHR0cHM6Ly93 d3cuYXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHBzOi8v d3d3LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQCNlKYZ MFDi18xGkXTlBSeKkDR/akk9ud9RmPQVExevzrWqZdv+Ku1RR/ccqjkK/qajauMrbuc0aP9Y VejeIKQnSwAHBo/57TSjNNsuBbUdkPhmXS/0ucTW+LeRs2WBRhqg9bqtBxV0HQpD9c4MWV7y /KFGRcmDRuPV+xJ/IfhE7Y3ePp8w1KTUcZVZgxmLpNrB4azNY8gSUaCqeacDo+J+cG07I6hf W5UHddYLtWgMWqwj6Y9yxo62QQ0tmSdmAFrwkBANFUF+JE03bY3t93q3MXNRomlf30PTy00S ctETi6NGihXXXb2SbUtkLUCBCAJPEFOdVuuIaP8tdvv9XI0GMYIDxjCCA8ICAQEwgZUwgY4x CzAJBgNVBAYTAkFVMQ4wDAYDVQQKEwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZp Y2VzMS4wLAYDVQQDEyVBUE5JQyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIw IAYJKoZIhvcNAQkBFhNjYW1hbmFnZXJAYXBuaWMubmV0AgIrYTAJBgUrDgMCGgUAoIICBTAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODExMjMwNDQ5MDha MCMGCSqGSIb3DQEJBDEWBBRH+LrsBxRipgu4m2/mdga/hmLyhzBSBgkqhkiG9w0BCQ8xRTBD MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzAN BggqhkiG9w0DAgIBKDCBpgYJKwYBBAGCNxAEMYGYMIGVMIGOMQswCQYDVQQGEwJBVTEOMAwG A1UEChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBO SUMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2Ft YW5hZ2VyQGFwbmljLm5ldAICK2EwgagGCyqGSIb3DQEJEAILMYGYoIGVMIGOMQswCQYDVQQG EwJBVTEOMAwGA1UEChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwG A1UEAxMlQVBOSUMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3 DQEJARYTY2FtYW5hZ2VyQGFwbmljLm5ldAICK2EwDQYJKoZIhvcNAQEBBQAEggEAhZrSTGuc koUeUYajBkCcDby0krWEcvxiZSyrz1ESe6stNYSBAQF56NKyyzMTUh28V99mdy5Wj2E+396W Ar1MT5PK8aitvfGfYpuBGFL4jmqtETBXpHL2SJRvk2XDINaazW9OClJ+5XS1DYa/6McrOYNq +MGQ16w3V19BWCRdkH3BSfjbTrMc7d4QgFzUZuVM83LNgeqyIKbYgNcSsJ7X966bo4mPRD87 ESmQrlpK3+8mKrkQ6s/6CHegYYOqZ5n4TaZLFW1ESXt4FQgDB67oeF4FJRYEL4gxSQWiGxv2 ZJpFWD1kv5o3t7gD1PIvRo5hic2AD/lFrSm+tapxpjlNkgAAAAAAAA== --------------ms080705030305000307080902-- --===============0522842971== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --===============0522842971==-- From sidr-bounces@ietf.org Sat Nov 22 21:37:36 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83B463A697E; Sat, 22 Nov 2008 21:37:36 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4FC3A697E for ; Sat, 22 Nov 2008 21:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ixFTAW6oMst for ; Sat, 22 Nov 2008 21:37:35 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 4BD9B3A6961 for ; Sat, 22 Nov 2008 21:37:35 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id A158A268686; Sat, 22 Nov 2008 22:37:33 -0700 (MST) Received: from [192.168.0.100] (97-122-99-176.hlrn.qwest.net [97.122.99.176]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sat, 22 Nov 2008 22:37:33 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.99.176; client-port=57869; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> From: Danny McPherson To: Geoff Huston In-Reply-To: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 22 Nov 2008 22:37:32 -0700 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Nov 16, 2008, at 5:25 PM, Geoff Huston wrote: > > I assume you are referring to the situation where, for example, a > ROA exists for 10.1.0.0/16 origin AS 1, and NO ROA exists for > 10.1.0.0/16 origin AS2, and you are seeing a route object for > 10.1.0.0/16 with origin AS 2, yes? Or perhaps 10.1.0.0/24, sure.. > The problem is that as a relying party you can't tell whether the > problem is with the retrieval of ROA objects or whether the route > object is bogus. i.e. what if the ROA for 10.1.0.0/16 origin AS 2 > was published a few seconds ago, whereas your local cache of ROA > objects was last refreshed a day ago. i.e. everything you have at > hand is valid, the manifests are good, and you are seeing something > that is not oin a locally held ROA, _but_ it is still valid. This is one of the reasons timing issues need to be considered, and one of the many reasons people stopped using explicit prefix filters. The route would be announced, the prefix was dropped, the filters were updated to support the announcement, but the route wouldn't be accepted unless the session was reset or a route re-announcement was triggered. You can imagine how painful this can be across multiple AS hops. > If there was also a BOA published for 10.1.0.0/16 then as a relying > party you now have grounds to believe that anything not described in > a valid ROA can be regarded as an invalid object. In this case there > is still the issue of time lag, and if the prefix holder had > intended to authorize 10.1.0.0/16 using AS 2 as an origination in > addition to AS1 then it would be incumbent on the prefix holder to > generate and publish the new ROA well in advance of the > advertisement of the new route. So clearly, the same case holds true for the BOA. If a BOA was just removed from the repository a few seconds ago but as a relying party I don't update my "accept policies" because of a problem with the retrieval of the BOA, it's just perturbing the issue. This could be especially problematic during natural disasters or other similar events where a publisher of a BOA can't update a repository or it can't be accessed by a relying party, and therefore, route changes that are common during those events can't happen. > Of course there is also the other case where AS 1 insists on a ROA > as a precondition for originating the route, and AS 2 does not, and > the prefix holder performs only what is required and no more. In > this case both routes are valid, but only one as a ROA. In tis case > the problem is not one of timing at the relying party side, and > will not be resolved by bring the relying party into sync with the > authority publisher. Yes, I think there are lots of issues of this nature, issues which BOAs only exacerbate. > So the BOA is a way of implementing the RPSEC requirement of being > able to support environments of incremental deployment, where it is > not > assured that everyone is publishing these authorities. Now if you > are of the view that the requirement of devising mechanisms to > support incremental piecemeal deployment is daft or unnecessary, > then perhaps this is a debate that in the IETF context should be > held in the context of the RPSEC WG, as the SIDR requirement here is > one that was gather up from the earlier RPSEC work and generate > mechanisms that met those requirements as stated in the RPSEC > documents. I'm not entirely convinced of this yet... Also, Sam had a query about BOAs including AS numbers, and I think that's a good point. Is the goal for an issue to say AS n can announce prefix x, but no one else, that would take one ROA and two BOAs, right? Why wouldn't that just be done implicitly with a ROA? -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Nov 23 01:40:49 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC9AA3A6811; Sun, 23 Nov 2008 01:40:48 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB0FC3A6774 for ; Sun, 23 Nov 2008 01:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MADbj+k+e5G8 for ; Sun, 23 Nov 2008 01:40:47 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id B446C3A6811 for ; Sun, 23 Nov 2008 01:40:46 -0800 (PST) Received: from dhcp18.potaroo.net (dhcp18.potaroo.net [203.10.60.18]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 71EED110065; Sun, 23 Nov 2008 19:40:43 +1000 (EST) Message-Id: <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> From: Geoff Huston To: Danny McPherson In-Reply-To: <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 23 Nov 2008 20:40:40 +1100 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG Chair Hat _OFF_ Thanks for your comments Danny. I'll interleave some further responses across this. > > On Nov 16, 2008, at 5:25 PM, Geoff Huston wrote: >> >> I assume you are referring to the situation where, for example, a >> ROA exists for 10.1.0.0/16 origin AS 1, and NO ROA exists for >> 10.1.0.0/16 origin AS2, and you are seeing a route object for >> 10.1.0.0/16 with origin AS 2, yes? > > Or perhaps 10.1.0.0/24, sure.. > >> The problem is that as a relying party you can't tell whether the >> problem is with the retrieval of ROA objects or whether the route >> object is bogus. i.e. what if the ROA for 10.1.0.0/16 origin AS 2 >> was published a few seconds ago, whereas your local cache of ROA >> objects was last refreshed a day ago. i.e. everything you have at >> hand is valid, the manifests are good, and you are seeing something >> that is not oin a locally held ROA, _but_ it is still valid. > > > This is one of the reasons timing issues need to be considered, > and one of the many reasons people stopped using explicit prefix > filters. The route would be announced, the prefix was dropped, > the filters were updated to support the announcement, but the > route wouldn't be accepted unless the session was reset or a > route re-announcement was triggered. You can imagine how painful > this can be across multiple AS hops. Entirely true, but I'm not sure where this part of the thread is leading in terms of the SIDR work in particular. > > >> If there was also a BOA published for 10.1.0.0/16 then as a relying >> party you now have grounds to believe that anything not described >> in a valid ROA can be regarded as an invalid object. In this case >> there is still the issue of time lag, and if the prefix holder had >> intended to authorize 10.1.0.0/16 using AS 2 as an origination in >> addition to AS1 then it would be incumbent on the prefix holder to >> generate and publish the new ROA well in advance of the >> advertisement of the new route. > > So clearly, the same case holds true for the BOA. If a BOA was > just removed from the repository a few seconds ago but as a relying > party I don't update my "accept policies" because of a problem with > the retrieval of the BOA, it's just perturbing the issue. This could > be especially problematic during natural disasters or other similar > events where a publisher of a BOA can't update a repository or it > can't be accessed by a relying party, and therefore, route changes > that are common during those events can't happen. yes - part of the underlying consideration is the manner in which the validation information is propagated in relation to the route object - in this model the validation information is in terms of the contents of rpki publication point repositories, as distinct from attaching the validation information to the route update itself. This is what is referred to in the roa-validation draft as a distinction between "decoupled" validation, as compared to "linked" validation. There are relative timing issues in the decoupled model, of course. > > >> Of course there is also the other case where AS 1 insists on a ROA >> as a precondition for originating the route, and AS 2 does not, and >> the prefix holder performs only what is required and no more. In >> this case both routes are valid, but only one as a ROA. In tis case >> the problem is not one of timing at the relying party side, and >> will not be resolved by bring the relying party into sync with the >> authority publisher. > > Yes, I think there are lots of issues of this nature, issues which > BOAs only exacerbate. I don't see the reasoning which leads to your observation that BOAs _exacerbate_ the issue. There are much the same as the issues with ROAs but I don;t see the case that makes the situation worse because of the addition of these negative attestations in the form of BOAs. Perhaps an example or two may help me (and possibly others) understand precisely what you mean by "exacerbate" ? > > >> So the BOA is a way of implementing the RPSEC requirement of being >> able to support environments of incremental deployment, where it is >> not >> assured that everyone is publishing these authorities. Now if you >> are of the view that the requirement of devising mechanisms to >> support incremental piecemeal deployment is daft or unnecessary, >> then perhaps this is a debate that in the IETF context should be >> held in the context of the RPSEC WG, as the SIDR requirement here >> is one that was gather up from the earlier RPSEC work and generate >> mechanisms that met those requirements as stated in the RPSEC >> documents. > > I'm not entirely convinced of this yet... fair enough - what might help? worked examples? other perspectives? > > > Also, Sam had a query about BOAs including AS numbers, and I think > that's a good point. Is the goal for an issue to say AS n can > announce > prefix x, but no one else, that would take one ROA and two > BOAs, right? Why wouldn't that just be done implicitly with a ROA? > The inclusion of the AS number had just a little to do with origination and probably more to do with the AS path - the semantic intent of the inclusion of the AS number in a BOA was to say "I'm the holder of this AS number and I'm not using it in routing at all. If you see a BGP update with this AS number anywhere in the AS Path then that's a lie!" regards, Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Nov 23 09:02:58 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BE7E3A6912; Sun, 23 Nov 2008 09:02:58 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27C9C3A693B for ; Sun, 23 Nov 2008 09:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.817 X-Spam-Level: X-Spam-Status: No, score=-0.817 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KctDtbZn8hmK for ; Sun, 23 Nov 2008 09:02:56 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 6EC9E3A67DB for ; Sun, 23 Nov 2008 09:02:56 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 620BE268693; Sun, 23 Nov 2008 10:02:54 -0700 (MST) Received: from [192.168.0.100] (97-122-99-176.hlrn.qwest.net [97.122.99.176]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sun, 23 Nov 2008 10:02:54 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.99.176; client-port=63608; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> From: Danny McPherson To: Geoff Huston In-Reply-To: <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 23 Nov 2008 10:02:51 -0700 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Nov 23, 2008, at 2:40 AM, Geoff Huston wrote: >> Yes, I think there are lots of issues of this nature, issues which >> BOAs only exacerbate. > > I don't see the reasoning which leads to your observation that BOAs > _exacerbate_ the issue. There are much the same as the issues with > ROAs but I don;t see the case that makes the situation worse because > of the addition of these negative attestations in the form of BOAs. > Perhaps an example or two may help me (and possibly others) > understand precisely what you mean by "exacerbate" ? To follow your previous example, you've now got 2x or more objects and if you can't access one, or you miss publication of one by seconds, you're increasing your vulnerability surface. > The inclusion of the AS number had just a little to do with > origination and probably more to do with the AS path - the semantic > intent of the inclusion of the AS number in a BOA was to say "I'm > the holder of this AS number and I'm not using it in routing at all. > If you see a BGP update with this AS number anywhere in the AS Path > then that's a lie!" But this requires full enumeration of the AS number space with each BOA, at least two ranges spanning all but the AS(s) listed in the ROA(s). This seems like a bad idea to me, as a matter of security policy expecting folks to explicitly fully enumerate what they will not accept, or what others should not accept, rather than letting it be an implicit "deny everything else". -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Nov 23 11:40:41 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DADAC3A69FD; Sun, 23 Nov 2008 11:40:40 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E8C13A69FD for ; Sun, 23 Nov 2008 11:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.416 X-Spam-Level: X-Spam-Status: No, score=-1.416 tagged_above=-999 required=5 tests=[AWL=-1.552, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, SARE_OBFU_PART_ING=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKU20ofP+rGj for ; Sun, 23 Nov 2008 11:40:38 -0800 (PST) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id 01A2B3A6767 for ; Sun, 23 Nov 2008 11:40:37 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1L4Kom-0007xl-SD; Sun, 23 Nov 2008 20:40:32 +0100 Received: from RIPE-NCC-101045.local (gw.office.nsrp.ripe.net [193.0.1.126]) by herring.ripe.net (Postfix) with ESMTP id C53932F592; Sun, 23 Nov 2008 20:40:28 +0100 (CET) Message-ID: <492947CF.40900@ripe.net> Date: Sun, 23 Nov 2008 13:08:47 +0100 From: Henk Uijterwaal User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Danny McPherson References: <4922E1E3.4020608@ripe.net> <4922EC8F.4050406@ripe.net> In-Reply-To: X-RIPE-Spam-Level: --- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5dc9b3846f5a5a3af477625847b33265b Cc: sidr@ietf.org Subject: Re: [sidr] RPSLSIG adoption? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Danny McPherson wrote: >> I like the idea but I think this question should be asked on the RPSL >> list as well before deciding which group should pick it up. > > What RPSL list are you referring to here? The RPSLng WG group kept its mailing list to discuss future extensions (and a possible restart if necessary) of RPSL. The addres was rpslng@ripe.net. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Ceterum censeo Asplain esse delendam (Cato & Henk) _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 24 15:13:52 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2060D3A68DC; Mon, 24 Nov 2008 15:13:52 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91C643A68DC for ; Mon, 24 Nov 2008 15:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyK4te5BPu9W for ; Mon, 24 Nov 2008 15:13:50 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 9360D3A689E for ; Mon, 24 Nov 2008 15:13:49 -0800 (PST) Received: from dhcp18.potaroo.net (dhcp18.potaroo.net [203.10.60.18]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id A902C110062; Tue, 25 Nov 2008 09:13:46 +1000 (EST) Message-Id: <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> From: Geoff Huston To: Danny McPherson In-Reply-To: <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 25 Nov 2008 10:13:46 +1100 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > WG Chair Hat Off > >> The inclusion of the AS number had just a little to do with >> origination and probably more to do with the AS path - the semantic >> intent of the inclusion of the AS number in a BOA was to say "I'm >> the holder of this AS number and I'm not using it in routing at >> all. If you see a BGP update with this AS number anywhere in the AS >> Path then that's a lie!" > > But this requires full enumeration of the AS number > space with each BOA, at least two ranges spanning all > but the AS(s) listed in the ROA(s). > > This seems like a bad idea to me, as a matter of security > policy expecting folks to explicitly fully enumerate what > they will not accept, or what others should not accept, > rather than letting it be an implicit "deny everything > else". I'm confused here Danny - are you explicitly advocating that a ROA should explicitly carry the semantics of "deny all else"? Is that is the case, then from such a perspective of a ROA having a "deny all else" interpretation, how should incremental use / piecemeal deployment of ROAs be handled? Does a ROA for 10.0.0.0/8 Origin AS1 explicitly deny all other non-ROA advertisements of any prefix that is equal to, or a more specific of 10.0.0./8 using any other origin AS other than AS1? I'm not sure that this would be your intention, but it seem to me that this logically follows from a "deny everything else" semantic interpretation applied to a ROA. regards, Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 24 15:29:27 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A5403A6B88; Mon, 24 Nov 2008 15:29:27 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85BE13A6B88 for ; Mon, 24 Nov 2008 15:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40ExLncsxpzU for ; Mon, 24 Nov 2008 15:29:25 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id DE70D3A68DC for ; Mon, 24 Nov 2008 15:29:25 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id E043D2686B0; Mon, 24 Nov 2008 16:29:23 -0700 (MST) Received: from [192.168.0.100] (97-122-99-176.hlrn.qwest.net [97.122.99.176]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 24 Nov 2008 16:29:23 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.99.176; client-port=63931; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: From: Danny McPherson To: Geoff Huston In-Reply-To: <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 24 Nov 2008 16:29:22 -0700 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Nov 24, 2008, at 4:13 PM, Geoff Huston wrote: > > I'm confused here Danny - are you explicitly advocating that a ROA > should explicitly carry the semantics of "deny all else"? > Is that is the case, then from such a perspective of a ROA having a > "deny all else" interpretation, how should incremental use / > piecemeal deployment of ROAs be handled? Does a ROA for 10.0.0.0/8 > Origin AS1 explicitly deny all other non-ROA advertisements of any > prefix that is equal to, or a more specific of 10.0.0./8 using any > other origin AS other than AS1? I'm not sure that this would be your > intention, but it seem to me that this logically follows from a > "deny everything else" semantic interpretation applied to a ROA. No, I'm saying that if a ROA is published indicating *who* is authorized to originate a route do I really need to fully enumerate everyone that is NOT authorized? Part of your case for BOAs was in case an object couldn't be accessed - increasing the size of the database at least 3x by adding BOAs doesn't seem entirely amenable to supporting that motivation. In an incremental deployment model an attestation as to the authorized originator of a route accommodates the incremental deployment model - if there's no ROA do what you want with it - depref, tag, discard, whatever you want. -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 24 15:50:55 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 094CC3A6B03; Mon, 24 Nov 2008 15:50:55 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C6AA3A69C1 for ; Mon, 24 Nov 2008 15:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgHW6Se-564Y for ; Mon, 24 Nov 2008 15:50:52 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 49BF13A6826 for ; Mon, 24 Nov 2008 15:50:52 -0800 (PST) Received: from dhcp18.potaroo.net (dhcp18.potaroo.net [203.10.60.18]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 49E12110065; Tue, 25 Nov 2008 09:50:49 +1000 (EST) Message-Id: From: Geoff Huston To: Danny McPherson In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 25 Nov 2008 10:50:48 +1100 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG chair hat off On 25/11/2008, at 10:29 AM, Danny McPherson wrote: > > On Nov 24, 2008, at 4:13 PM, Geoff Huston wrote: >> >> I'm confused here Danny - are you explicitly advocating that a ROA >> should explicitly carry the semantics of "deny all else"? > >> Is that is the case, then from such a perspective of a ROA having a >> "deny all else" interpretation, how should incremental use / >> piecemeal deployment of ROAs be handled? Does a ROA for 10.0.0.0/8 >> Origin AS1 explicitly deny all other non-ROA advertisements of any >> prefix that is equal to, or a more specific of 10.0.0./8 using any >> other origin AS other than AS1? I'm not sure that this would be >> your intention, but it seem to me that this logically follows from >> a "deny everything else" semantic interpretation applied to a ROA. > > No, I'm saying that if a ROA is published indicating *who* is > authorized to originate a route do I really need to fully > enumerate everyone that is NOT authorized? Part of your case > for BOAs was in case an object couldn't be accessed - increasing > the size of the database at least 3x by adding BOAs doesn't seem > entirely amenable to supporting that motivation. > So if I understand you correctly you are advocating that a ROA has an explicit semantic intention of "deny everything else" could you explain the precise semantics of a ROA for 10.0.0.0/8 maxlength = 9, origin AS1 as if would apply to an advertisement of 10.1.1.0/24 origin AS1 without any ROA, and to an advertisement of 10.1.1.0/24 origin AS2 without any ROA? > In an incremental deployment model an attestation as to the > authorized originator of a route accommodates the incremental > deployment model - if there's no ROA do what you want with > it - depref, tag, discard, whatever you want. but hang on - you are not saying that Danny in your previous paragraph - you are saying that in a deny everything else, the presence of a ROA implicitly denies a class of other routes. I'm very confused about what you are saying here as you seem to me to be saying two different things at once. regards, Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 24 16:12:02 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 484BC3A697F; Mon, 24 Nov 2008 16:12:02 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0CB13A697F for ; Mon, 24 Nov 2008 16:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.045 X-Spam-Level: X-Spam-Status: No, score=-1.045 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJ2iIXkZ4Npc for ; Mon, 24 Nov 2008 16:11:59 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id D9FEB3A6885 for ; Mon, 24 Nov 2008 16:11:59 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 6D9042686B0; Mon, 24 Nov 2008 17:11:57 -0700 (MST) Received: from [192.168.0.100] (97-122-99-176.hlrn.qwest.net [97.122.99.176]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 24 Nov 2008 17:11:57 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.99.176; client-port=64018; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: From: Danny McPherson To: Geoff Huston In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 24 Nov 2008 17:11:56 -0700 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Nov 24, 2008, at 4:50 PM, Geoff Huston wrote: > > So if I understand you correctly you are advocating that a ROA has > an explicit semantic intention of "deny everything else" > > could you explain the precise semantics of a ROA for 10.0.0.0/8 > maxlength = 9, origin AS1 as if would apply to an advertisement of > 10.1.1.0/24 origin AS1 without any ROA, and to an advertisement of > 10.1.1.0/24 origin AS2 without any ROA? > > >> In an incremental deployment model an attestation as to the >> authorized originator of a route accommodates the incremental >> deployment model - if there's no ROA do what you want with >> it - depref, tag, discard, whatever you want. > > but hang on - you are not saying that Danny in your previous > paragraph - you are saying that in a deny everything else, the > presence of a ROA implicitly denies a class of other routes. I'm > very confused about what you are saying here as you seem to me to be > saying two different things at once. In an incremental deployment model non-existence of a ROA should mean an operator can do whatever they deem necessary. If it were me, and there was a ROA for 10.0.0.0/8 origin AS 1, and I implemented filtering (whatever that means) based on ROAs, and no other ROA exists for anything equal to or longer than that 10.0.0.0/8 origin AS 1, AS 1 would be the only AS from which I would accept that prefix - I wouldn't accept ANY more-specifics from AS 1, and I certainly wouldn't accept any route equal to or longer than 10.0.0.0/8 from anyone else. That'd be my incentive as an operator. A ROA exists, I trust it, and I trust no one else. Then de-aggregation of that prefix or route hijacks don't affect me for that prefix. If you don't have a ROA for your prefix, I can't filter on it, from you or anyone else. You want me to only accept it from you, see that it and any associated ROAs exists and that'll be the only place I accept those prefixes, with the explicit specified origin AS. That's my peers incentive as an operator. So, by your interpretation, yes. But that's me, and that's how I'd configure my routers, and each operator can configure their routing policy how they like in this regard. Requiring full enumeration of who not to accept what from is only going to induce lots of unnecessary overhead, in both policy specification and policy application, AND certainly, churn, frequency, and number of objects that need to be maintained in the system. -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 24 16:12:43 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D953A6885; Mon, 24 Nov 2008 16:12:43 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E03B3A6885 for ; Mon, 24 Nov 2008 16:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUIj6WZi-HOl for ; Mon, 24 Nov 2008 16:12:40 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id BAFFE3A677E for ; Mon, 24 Nov 2008 16:12:40 -0800 (PST) Received: from dhcp152.apnic.net (dhcp152.apnic.net [202.12.29.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 60BA8110062 for ; Tue, 25 Nov 2008 10:12:38 +1000 (EST) Message-Id: From: George Michaelson To: sidr@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 24 Nov 2008 18:12:37 -0600 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Some people now appear to want an *implicit* meaning of 'if not in ROA, then excluded' -but, they also somehow want this to be conditional. Secondly, there is a semantic difference between 'all which is not explicitly permitted is forbidden' and 'this is explicitly forbidden'. We have tried to make an explicit semantic around the word NOT: NOT prefix / ie do NOT accept / as a valid route. Thats what a BOA says. its explicit what prefixes are being knocked out. Others seem to want an *implicit* NOT. But, it appears to be a conditionally implicit NOT: how can you decide when it does, or does not apply? This is of course two different problems: 1) how do you conditionally flag it does or doesn't apply? The ROA has no syntax for this 2) what is the scope of the "NOT" logic? in an explicit (BOA) world, the scope can be any prefix(s) you like: its an explicit statement of intent around the NOT word. in a world of ROA only, the only NOT you can have is "anything else" so its demonstrably semantically weaker. -George _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 24 16:27:11 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4C063A691E; Mon, 24 Nov 2008 16:27:11 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE0253A677E for ; Mon, 24 Nov 2008 16:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hv4V6uTV1xeI for ; Mon, 24 Nov 2008 16:27:09 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 83E603A67EE for ; Mon, 24 Nov 2008 16:27:08 -0800 (PST) Received: from [202.12.29.155] (dhcp155.apnic.net [202.12.29.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id DA9CA110062; Tue, 25 Nov 2008 10:27:05 +1000 (EST) Message-ID: <492B4659.8070506@apnic.net> Date: Tue, 25 Nov 2008 10:27:05 +1000 From: Robert Loomans Organization: APNIC - http://www.apnic.net/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.18) Gecko/20081105 Lightning/0.9 Thunderbird/2.0.0.18 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Danny McPherson References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> In-Reply-To: <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> X-Enigmail-Version: 0.95.7 OpenPGP: id=C6B3AE7E; url=http://robert.loomans.org/0xC6B3AE7E.asc Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAMAAABg3Am1AAAAGFBMVEUbGxs1NTVVVVVycnKO jo6tra3MzMzg4OAC8PijAAACVElEQVR42pWVW3bjMAxDKT6U/e94AJBWXLcfHrRJpBhXoKjj2D7Q hqoyI8Jv4vTxTW6b4ZLOcD6do3XzA1g9qEKK0orGmeSuWGIHKCZE1KZkwgtA4oOzwjsMB4DRehID ULFgqc+ls49gwOami0xcwI41ipkfFRzWTWKlqZCi1ZpwRVRGQtHXG6gqRyHtN1tH1X0gMF0x+pPV 5fKs+/pSfh4yrh8AmvD11C9gM8CjQERgv+ds5/TiCWTSwYjKjc7kD8ViCT8AnzOBdppreyOOnSVc iLrkI/j3+g2E9fTItHjbEmVrcAfWmlFRTOhhJgImIUv/Uph57VmAS1+JWTt82brC8gCIHQub0yWl gAXAG5AGABGcBp0NdIs2zxjwXZGBVBIYUwL8DuhUhPEuOGePAAhllAUdAtzSMl0OgMANQAiIPXdZ GV6KKwCxMATBzaVTTOwISQCkDe6wORG91zVJARioOQK6Zzw3ekaV0gHKg0oCImKXr/wFxAMIAgrw rDAYngm9a/sCBbF3jojlDaj8KS8agGmA7jcAr8K1cXWHJmCAbIBT+Um4tekoES6dCgV4KxFBj86S IQcwdbkB/2pVyUQ7pOGpaLpaBI6i6IrZhLJcwCz1TFBEDDHt8gkIXTjAUYV6OgoBE6DsEKDnxgCW Kr7tNE0AgXtbPRrAxRi1p3TDzcEc4MjMco9ZjgTg8h/gKf465/d54GZXESr7DyD4a5vZ/m0vVE3I X/ZGG5oHiL3T/uCPcntPLBX0Hgh2y18DVf3AfQ/sD/U+IUoPKvsPLV/2p/4BtMMZxXNLW/wAAAAA SUVORK5CYII= Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0853876636==" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0853876636== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030300050902080805080404" This is a cryptographically signed message in MIME format. --------------ms030300050902080805080404 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit >> The inclusion of the AS number had just a little to do with >> origination and probably more to do with the AS path - the semantic >> intent of the inclusion of the AS number in a BOA was to say "I'm the >> holder of this AS number and I'm not using it in routing at all. If >> you see a BGP update with this AS number anywhere in the AS Path then >> that's a lie!" > > But this requires full enumeration of the AS number > space with each BOA, at least two ranges spanning all > but the AS(s) listed in the ROA(s). > > This seems like a bad idea to me, as a matter of security > policy expecting folks to explicitly fully enumerate what > they will not accept, or what others should not accept, > rather than letting it be an implicit "deny everything > else". I think there is a lack of clarity in the BOA draft as to what the list of ASs actually is saying: My understanding is that the list of ASs and the list of IP prefixes is independent (ie, logical OR), and unlike with ROAs, only the holder of an AS can sign a BOA with that AS in it. That is, if AS5 and 10.0.0.0/8 appear in a BOA, it means that neither AS5 *nor* prefixes 10.0.0.0/8 and more specific should *ever* appear in routing, together or separately. Geoff, George, Terry, is my understanding correct? Rob -- Robert Loomans Email: robertl@apnic.net Senior Software Engineer, APNIC Phone: +61 7 3858 3100 http://www.apnic.net Fax: +61 7 3858 3199 --------------ms030300050902080805080404 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK6DCC BXAwggRYoAMCAQICAithMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UE ChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5h Z2VyQGFwbmljLm5ldDAeFw0wODA5MjYwNzQ1MDlaFw0wOTA5MjYwNzQ1MDlaMEkxCzAJBgNV BAYTAkFQMREwDwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDjAM BgNVBAUTBTExMTA1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3z92063wWTuk PtRv0ZrOumNcHII4mWyKdZqOY2M8TjgTtwuSLfyXz1kJgM4EzeL4Di9VCPHxiIeOpOh5lBLz 0BOZi9cs9Wr7HpiaaKSj5bMGrYleg3tVp1d2zUA3J1ar7bblTjlIOmO8YaazpPLmu4jtaO7X sGZq1zYNIPpsTdpliHSjipHPp0vIogXd/omAZdmCSTVplS/XDYWwoY5fByctVZkMmaV1kLdM JatuB5nOQ2OJna9ChQ4q95OJmTWtWj7txQJiBC7nrMVnhVb/lXA4EyEo/UpuBqClGPB+SNQs yu+4MtSucyIM5brqUSvZvG5dY1p2aG1LfdhtEG8k9QIDAQABo4ICGjCCAhYwCQYDVR0TBAIw ADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCcGCWCGSAGG+EIBDQQaFhhBUE5J QyBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFBA9EWg0YXaM16SWXYapPuroBl6wMIG7 BgNVHSMEgbMwgbCAFBSGArCuuEux79Pr4vuSKIV3jATpoYGUpIGRMIGOMQswCQYDVQQGEwJB VTEOMAwGA1UEChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UE AxMlQVBOSUMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJ ARYTY2FtYW5hZ2VyQGFwbmljLm5ldIIBADAcBgNVHREEFTATgRFyb2JlcnRsQGFwbmljLm5l dDAeBgNVHRIEFzAVgRNjYW1hbmFnZXJAYXBuaWMubmV0MDcGA1UdHwQwMC4wLKAqoCiGJmh0 dHBzOi8vd3d3LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBBAQoFiZo dHRwczovL3d3dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDA1BglghkgBhvhCAQMEKBYm aHR0cHM6Ly93d3cuYXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAI2UphkwUOLXzEaRdOUFJ4qQNH9qST2531GY9BUTF6/Otapl2/4q7VFH9xyqOQr+pqNq 4ytu5zRo/1hV6N4gpCdLAAcGj/ntNKM02y4FtR2Q+GZdL/S5xNb4t5GzZYFGGqD1uq0HFXQd CkP1zgxZXvL8oUZFyYNG49X7En8h+ETtjd4+nzDUpNRxlVmDGYuk2sHhrM1jyBJRoKp5pwOj 4n5wbTsjqF9blQd11gu1aAxarCPpj3LGjrZBDS2ZJ2YAWvCQEA0VQX4kTTdtje33ercxc1Gi aV/fQ9PLTRJy0ROLo0aKFdddvZJtS2QtQIEIAk8QU51W64ho/y12+/1cjQYwggVwMIIEWKAD AgECAgIrYTANBgkqhkiG9w0BAQUFADCBjjELMAkGA1UEBhMCQVUxDjAMBgNVBAoTBUFQTklD MRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNVBAMTJUFQTklDIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0BCQEWE2NhbWFuYWdlckBhcG5p Yy5uZXQwHhcNMDgwOTI2MDc0NTA5WhcNMDkwOTI2MDc0NTA5WjBJMQswCQYDVQQGEwJBUDER MA8GA1UEChMIQVBOSUMtQVAxFzAVBgNVBAMTDlJvYmVydCBMb29tYW5zMQ4wDAYDVQQFEwUx MTEwNTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN8/dtOt8Fk7pD7Ub9Gazrpj XByCOJlsinWajmNjPE44E7cLki38l89ZCYDOBM3i+A4vVQjx8YiHjqToeZQS89ATmYvXLPVq +x6Ymmiko+WzBq2JXoN7VadXds1ANydWq+225U45SDpjvGGms6Ty5ruI7Wju17Bmatc2DSD6 bE3aZYh0o4qRz6dLyKIF3f6JgGXZgkk1aZUv1w2FsKGOXwcnLVWZDJmldZC3TCWrbgeZzkNj iZ2vQoUOKveTiZk1rVo+7cUCYgQu56zFZ4VW/5VwOBMhKP1KbgagpRjwfkjULMrvuDLUrnMi DOW66lEr2bxuXWNadmhtS33YbRBvJPUCAwEAAaOCAhowggIWMAkGA1UdEwQCMAAwEQYJYIZI AYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAnBglghkgBhvhCAQ0EGhYYQVBOSUMgQ2xpZW50 IENlcnRpZmljYXRlMB0GA1UdDgQWBBQQPRFoNGF2jNekll2GqT7q6AZesDCBuwYDVR0jBIGz MIGwgBQUhgKwrrhLse/T6+L7kiiFd4wE6aGBlKSBkTCBjjELMAkGA1UEBhMCQVUxDjAMBgNV BAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNVBAMTJUFQTklD IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0BCQEWE2NhbWFu YWdlckBhcG5pYy5uZXSCAQAwHAYDVR0RBBUwE4ERcm9iZXJ0bEBhcG5pYy5uZXQwHgYDVR0S BBcwFYETY2FtYW5hZ2VyQGFwbmljLm5ldDA3BgNVHR8EMDAuMCygKqAohiZodHRwczovL3d3 dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDA1BglghkgBhvhCAQQEKBYmaHR0cHM6Ly93 d3cuYXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHBzOi8v d3d3LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQCNlKYZ MFDi18xGkXTlBSeKkDR/akk9ud9RmPQVExevzrWqZdv+Ku1RR/ccqjkK/qajauMrbuc0aP9Y VejeIKQnSwAHBo/57TSjNNsuBbUdkPhmXS/0ucTW+LeRs2WBRhqg9bqtBxV0HQpD9c4MWV7y /KFGRcmDRuPV+xJ/IfhE7Y3ePp8w1KTUcZVZgxmLpNrB4azNY8gSUaCqeacDo+J+cG07I6hf W5UHddYLtWgMWqwj6Y9yxo62QQ0tmSdmAFrwkBANFUF+JE03bY3t93q3MXNRomlf30PTy00S ctETi6NGihXXXb2SbUtkLUCBCAJPEFOdVuuIaP8tdvv9XI0GMYIDxjCCA8ICAQEwgZUwgY4x CzAJBgNVBAYTAkFVMQ4wDAYDVQQKEwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZp Y2VzMS4wLAYDVQQDEyVBUE5JQyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIw IAYJKoZIhvcNAQkBFhNjYW1hbmFnZXJAYXBuaWMubmV0AgIrYTAJBgUrDgMCGgUAoIICBTAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODExMjUwMDI3MDVa MCMGCSqGSIb3DQEJBDEWBBQ41W48W6Sa+rSiKk0GI+OUZ0UD9zBSBgkqhkiG9w0BCQ8xRTBD MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzAN BggqhkiG9w0DAgIBKDCBpgYJKwYBBAGCNxAEMYGYMIGVMIGOMQswCQYDVQQGEwJBVTEOMAwG A1UEChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBO SUMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2Ft YW5hZ2VyQGFwbmljLm5ldAICK2EwgagGCyqGSIb3DQEJEAILMYGYoIGVMIGOMQswCQYDVQQG EwJBVTEOMAwGA1UEChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwG A1UEAxMlQVBOSUMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3 DQEJARYTY2FtYW5hZ2VyQGFwbmljLm5ldAICK2EwDQYJKoZIhvcNAQEBBQAEggEAqRjxITRC 14B3zaxUlSxBleoDp9Wgv89I6oJn0nPEj/UQV6jqs6uDAobxPyxqJOSdR5zXXj6JWYbF+dJ4 LneHultRxWF0gTmSF9eLWOwb6A5rkKCEflG/4V3UEvhGnTN0Ghq7nEd4x3zM5F0GhfPhUoEM HiSStj9ysWRgtGHHbFxRfJ7j9nmu8oCC2uK2Tbvx0GwULSLrqlEugQ4lsvdc0GRZhilOzH4C +gznRwLHkdEOm76JbNWb0xAjmOCLNPIwZjx6zwBVfsuca/lviUw9edIgC3Vw3VfPXqCbuIkx Lz6tPL5N0R8UrSbpU+YljdBaS6aX7PRH12DPv/pnDpcAGQAAAAAAAA== --------------ms030300050902080805080404-- --===============0853876636== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --===============0853876636==-- From sidr-bounces@ietf.org Mon Nov 24 16:51:45 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 359CB3A6885; Mon, 24 Nov 2008 16:51:45 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ADA23A6885 for ; Mon, 24 Nov 2008 16:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOg2b9WROrxM for ; Mon, 24 Nov 2008 16:51:42 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 67CC03A67FB for ; Mon, 24 Nov 2008 16:51:42 -0800 (PST) Received: from dhcp18.potaroo.net (dhcp18.potaroo.net [203.10.60.18]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id C5B78110062; Tue, 25 Nov 2008 10:51:39 +1000 (EST) Message-Id: From: Geoff Huston To: Robert Loomans In-Reply-To: <492B4659.8070506@apnic.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 25 Nov 2008 11:51:38 +1100 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <492B4659.8070506@apnic.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org wG Chair Hat Off On 25/11/2008, at 11:27 AM, Robert Loomans wrote: > >>> The inclusion of the AS number had just a little to do with >>> origination and probably more to do with the AS path - the semantic >>> intent of the inclusion of the AS number in a BOA was to say "I'm >>> the >>> holder of this AS number and I'm not using it in routing at all. If >>> you see a BGP update with this AS number anywhere in the AS Path >>> then >>> that's a lie!" >> >> But this requires full enumeration of the AS number >> space with each BOA, at least two ranges spanning all >> but the AS(s) listed in the ROA(s). >> >> This seems like a bad idea to me, as a matter of security >> policy expecting folks to explicitly fully enumerate what >> they will not accept, or what others should not accept, >> rather than letting it be an implicit "deny everything >> else". > > I think there is a lack of clarity in the BOA draft as to what the > list > of ASs actually is saying: > > My understanding is that the list of ASs and the list of IP prefixes > is > independent (ie, logical OR), and unlike with ROAs, only the holder of > an AS can sign a BOA with that AS in it. > > That is, if AS5 and 10.0.0.0/8 appear in a BOA, it means that neither > AS5 *nor* prefixes 10.0.0.0/8 and more specific should *ever* appear > in > routing, together or separately. > > Geoff, George, Terry, is my understanding correct? yes, that understanding is correct. Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 24 17:45:42 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 516BB3A6947; Mon, 24 Nov 2008 17:45:42 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C97A3A67FB for ; Mon, 24 Nov 2008 17:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1dPGQRZnd1C for ; Mon, 24 Nov 2008 17:45:40 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 503823A6947 for ; Mon, 24 Nov 2008 17:45:40 -0800 (PST) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L4mzh-000BgN-0s; Tue, 25 Nov 2008 01:45:37 +0000 Message-ID: <492B58BF.6000204@psg.com> Date: Tue, 25 Nov 2008 10:45:35 +0900 From: Randy Bush User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Geoff Huston References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> In-Reply-To: <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Geoff Huston wrote: > Does a ROA for 10.0.0.0/8 Origin AS1 explicitly deny all other > non-ROA advertisements of any prefix that is equal to, or a more > specific of 10.0.0./8 using any other origin AS other than AS1? almost. there might also be a roa for 10/8-33 to as42. and we're ignoring max prefix len here. but the owner of the prefix has spoken formally. things are no longer ambiguous. end. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 25 00:51:36 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0D083A6A90; Tue, 25 Nov 2008 00:51:36 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 965793A6A70 for ; Tue, 25 Nov 2008 00:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.766 X-Spam-Level: X-Spam-Status: No, score=-9.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_PART_ING=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBcB0OZNh3Vt for ; Tue, 25 Nov 2008 00:51:34 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id 41A2D3A6A90 for ; Tue, 25 Nov 2008 00:51:34 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1L4tdo-0005IZ-0R; Tue, 25 Nov 2008 09:51:30 +0100 Received: from andrei-robachevskys-macbook-pro-15.local (gw.office.nsrp.ripe.net [193.0.1.126]) by herring.ripe.net (Postfix) with ESMTP id EF38E2F592; Tue, 25 Nov 2008 09:51:27 +0100 (CET) Message-ID: <492BBC8F.9070509@ripe.net> Date: Tue, 25 Nov 2008 09:51:27 +0100 From: Andrei Robachevsky User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Henk Uijterwaal References: <4922E1E3.4020608@ripe.net> <4922EC8F.4050406@ripe.net> <492947CF.40900@ripe.net> In-Reply-To: <492947CF.40900@ripe.net> X-Enigmail-Version: 0.95.7 X-RIPE-Spam-Level: ---- X-RIPE-Signature: 4330a47f43bd7e517cd9d6f2bba43afb395651b3c1a53c564be931c6ecc02a5e Cc: sidr@ietf.org Subject: Re: [sidr] RPSLSIG adoption? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Henk Uijterwaal wrote on 23-11-2008 13:08: > Danny McPherson wrote: > >>> I like the idea but I think this question should be asked on the RPSL >>> list as well before deciding which group should pick it up. >> >> What RPSL list are you referring to here? > > The RPSLng WG group kept its mailing list to discuss future extensions > (and a possible restart if necessary) of RPSL. The addres was > rpslng@ripe.net. > As far as I remember there was no formal RPSLng WG at the IETF. All work has been carried out through an individual submission on the mailinglist Henk mentioned. As for the rpslsig work, I support it. We might be worried a bit about the scope creep of SIDR, but I think that essentially the same group of people are going to be involved in reviewing rsplsig. So I support that SIDR takes this as a WG item. Andrei > Henk > > ------------------------------------------------------------------------------ > > Henk Uijterwaal Email: > henk.uijterwaal(at)ripe.net > RIPE Network Coordination Centre http://www.amsterdamned.org/~henk > P.O.Box 10096 Singel 258 Phone: +31.20.5354414 > 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 > The Netherlands The Netherlands Mobile: +31.6.55861746 > ------------------------------------------------------------------------------ > > > Ceterum censeo Asplain esse delendam (Cato & Henk) > > _______________________________________________ > 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 sidr-bounces@ietf.org Tue Nov 25 01:30:04 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45F2828C0E0; Tue, 25 Nov 2008 01:30:04 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6204628C0DE for ; Tue, 25 Nov 2008 01:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKu9xmnusiQZ for ; Tue, 25 Nov 2008 01:30:01 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 658FA28C0D7 for ; Tue, 25 Nov 2008 01:30:01 -0800 (PST) Received: from [58.163.111.41] (unknown [58.163.111.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 7963E110066; Tue, 25 Nov 2008 19:29:57 +1000 (EST) Message-Id: From: Geoff Huston To: Danny McPherson In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 25 Nov 2008 20:28:46 +1100 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org wg chair hat off > So, by your interpretation, yes. But that's me, and that's how I'd > configure my routers, and each operator can configure their routing > policy how they like in this regard. So what I think you are saying here Danny is that: - there should no standard for the interpretation of ROAs and its up to each relying party to figure out what they want to do - i.e. you are in effect advocating that the WG that the WG has erred in taking on the roa-validation draft and that the WG should abandon the roa- validation draft completely. - you want to configure your environment such that you, as a relying party, want to interpret a ROA as including the semantics of denial of all other possible route objects, irrespective of the intended semantics of the ROA publisher. - you do not want to use a BOA in your environment, and you want to stop anyone else from using as BOA in terms of a BOA as defined by an IETF standards document in any case. Obviously I disagree with this approach, in that if the semantics of route attestations are in the eye of the beholder this entire effort is a complete waste of everyone's time. If the intentions of the creator of the object can be variably interpreted by relying parties then what you don't have as a result is a secure system. I'm not sure what you would call the outcome, but "secure" would not be a part of it as far as I can figure out. I'm not sure where this line of reasoning you are using here Danny is headed, and I really can't understand how it fits into the overall architecture being developed in SIDR. Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 25 02:11:55 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 992EE3A6B74; Tue, 25 Nov 2008 02:11:55 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BABEE3A6B74 for ; Tue, 25 Nov 2008 02:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMmU4EfpK8yP for ; Tue, 25 Nov 2008 02:11:54 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id F31913A6B03 for ; Tue, 25 Nov 2008 02:11:51 -0800 (PST) Received: from [58.163.111.46] (unknown [58.163.111.46]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 8171E110062 for ; Tue, 25 Nov 2008 20:11:48 +1000 (EST) Message-Id: From: Geoff Huston To: sidr@ietf.org In-Reply-To: <4922E1E3.4020608@ripe.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 25 Nov 2008 21:11:47 +1100 References: <4922E1E3.4020608@ripe.net> X-Mailer: Apple Mail (2.929.2) Subject: [sidr] WG adoption of draft-kisteleki-sidr-rpsl-sig-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG co-Chair hat ON Reminder: this call for comment on WG adoption of this draft finishes on November 28th (this Friday) Geoff ----------------------------------------- Thanks for this request Robert. I'd like to put the question to the WG to adopt this draft as a WG document. Please send in your comments to the WG by Friday November 28th on this. I'll note the comments already posted on this thread so there is no need to post again if you've already voiced your views on this question. thanks, Geoff On 19/11/2008, at 2:40 AM, Robert Kisteleki wrote: > Hi, > > After my (rushed) presentation yesterday I'd like to ask if there > are people in the WG who think that this idea is worth pursuing and > should it be a WG item? > > http://www.ietf.org/internet-drafts/draft-kisteleki-sidr-rpsl-sig-00.txt > http://www3.ietf.org/proceedings/08nov/slides/sidr-3.pdf > > Regards, > Robert > _______________________________________________ > 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 sidr-bounces@ietf.org Tue Nov 25 02:27:44 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B64528C0DE; Tue, 25 Nov 2008 02:27:44 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0401B3A684F for ; Tue, 25 Nov 2008 02:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IyCObeBMq4A for ; Tue, 25 Nov 2008 02:27:42 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 4287528C0DE for ; Tue, 25 Nov 2008 02:27:42 -0800 (PST) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L4v8r-000Cds-P7; Tue, 25 Nov 2008 10:27:37 +0000 Message-ID: <492BD318.1050508@psg.com> Date: Tue, 25 Nov 2008 19:27:36 +0900 From: Randy Bush User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Geoff Huston References: <4922E1E3.4020608@ripe.net> In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] WG adoption of draft-kisteleki-sidr-rpsl-sig-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org i think this could be useful work. i do not think it should be a sidr work item. it belongs in some ops group, not routing. and that is where rps used to be. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 25 03:24:08 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6F353A6B74; Tue, 25 Nov 2008 03:24:08 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51FB3A6A49 for ; Tue, 25 Nov 2008 03:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhpOTFjqFpsK for ; Tue, 25 Nov 2008 03:24:07 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id C0E833A698D for ; Tue, 25 Nov 2008 03:24:06 -0800 (PST) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L4w1R-000Ckj-Sh; Tue, 25 Nov 2008 11:24:02 +0000 Message-ID: <492BE04E.9020201@psg.com> Date: Tue, 25 Nov 2008 20:23:58 +0900 From: Randy Bush User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Geoff Huston References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > - there should no standard for the interpretation of ROAs and its up to > each relying party to figure out what they want to do > ... and a lot of other argument by extreme perhaps you could look at draft-pmohapat-sidr-pfx-validate-00.txt. i do not buy it entirely, and have sent edits to the authors. but how the roa fits into bgp decision making is pretty simple. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 25 06:34:41 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF83228C156; Tue, 25 Nov 2008 06:34:40 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B12828C179 for ; Tue, 25 Nov 2008 06:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.045 X-Spam-Level: X-Spam-Status: No, score=-1.045 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsGaR1PTkvFL for ; Tue, 25 Nov 2008 06:34:39 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 0092828C156 for ; Tue, 25 Nov 2008 06:34:39 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id BDD492686BB; Tue, 25 Nov 2008 07:34:36 -0700 (MST) Received: from [192.168.0.100] (97-122-99-176.hlrn.qwest.net [97.122.99.176]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 25 Nov 2008 07:34:36 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.99.176; client-port=52330; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: From: Danny McPherson To: Geoff Huston In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 25 Nov 2008 07:34:35 -0700 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Nov 25, 2008, at 2:28 AM, Geoff Huston wrote: > - you do not want to use a BOA in your environment, and you want to > stop anyone else from using as BOA in terms of a BOA as defined by > an IETF standards document in any case. For you to come to the list of conclusions above simply because I don't like the idea of BOAs is quite a leap. I'd prefer you not speculate what you believe to be my position, and instead, address the issue which lead to this discussion - convince me of the positive value of BOAs, which I've yet to realize. Perhaps if you'd outline a couple use cases of BOAs I'd better understand how this is useful and provides more net benefits than offshoots? Thanks! -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 25 13:12:28 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C4B03A6C55; Tue, 25 Nov 2008 13:12:28 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1946A3A6C62 for ; Tue, 25 Nov 2008 13:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUdGECVKokP5 for ; Tue, 25 Nov 2008 13:12:26 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id EEAA23A697D for ; Tue, 25 Nov 2008 13:12:25 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id mAPLCKAM003150; Tue, 25 Nov 2008 15:12:20 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id mAPLCK10010725; Tue, 25 Nov 2008 15:12:21 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.183]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Nov 2008 16:12:20 -0500 Date: Tue, 25 Nov 2008 16:12:20 -0500 (Eastern Standard Time) From: Sandra Murphy To: Geoff Huston In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 25 Nov 2008 21:12:20.0445 (UTC) FILETIME=[80D1F8D0:01C94F42] Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Wed, 12 Nov 2008, Geoff Huston wrote: > WG Co-Chair hat _OFF_ > > Sandy, > > The authors of these two drafts now believe that all SIDR WG comments have > been integrated into these documents, and there are no further outstanding > comments to be addressed. > > Accordingly, we would like to request that you conduct a WG Last Call for > these documents in order to ensure that the WG is now comfortable with these > documents and all comments have been made, and to assess whether the WG is > now ready to move these two documents to the IESG for IESG review. > It is clear from the ensuing discussion that we are not close enough to consensus in this matter to conduct a last call. We do need to work out the issues being raised before we can reasonably conduct a last call. --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 25 13:12:55 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4E73A6C62; Tue, 25 Nov 2008 13:12:55 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 872A13A6C68 for ; Tue, 25 Nov 2008 13:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxCXCekNrovr for ; Tue, 25 Nov 2008 13:12:53 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id A32993A6C62 for ; Tue, 25 Nov 2008 13:12:53 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id mAPLCotR003175 for ; Tue, 25 Nov 2008 15:12:50 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id mAPLCnkD010769 for ; Tue, 25 Nov 2008 15:12:49 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.183]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Nov 2008 16:12:49 -0500 Date: Tue, 25 Nov 2008 16:12:49 -0500 (Eastern Standard Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 25 Nov 2008 21:12:49.0383 (UTC) FILETIME=[92118F70:01C94F42] Subject: [sidr] Two important points X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org I've seen two points in this latest discussion that I think are important (both brought up by Geoff in some of his messages). I'd like the wg to keep them in mind when analyzing validation. First is the thorny issue of incremental deployment. As ISPs begin to use this work, we will undoubtedly have cases such as: ATT understand the RPKI and uses certs and ROAs, but their multihomed customer in Bolivia, to whom they have sub-allocated some of their space, does not. Just exactly what can ATT do (what gets signed by whom and what gets checked by whom) that will prevent a more-specific prefix hijacking but will not dis-enfranchize their legitimate but clueless customer? An RIR has been delegation 64/8. Just exactly how (what gets signed by whom and what gets checked by whom) do we prevent annoucements of superblocks of and within this delegation? We must know exactly how to validate routes with RPKI material, so we must settle this. Second is the exact semantics of the ROA itself or a set of ROAs. It is clear that everyone is not reading from the same page for this (which is troubling to show up this late in the specification game). This has shown up in several messages, and the popular alternatives are a set of ROAs grants right to use a prefix to a set of ASs a set of ROAs grants right to use a prefix to a set of ASs and no others. Knowing how to validate BGP route advertisements depends completely on the semantics of a ROA, so we must settle this also. Proponents of a solution to the first set of problems should be clear about what semantics they are using. Opponents of a solution to the first set of problems should be clear about what semantics they are assuming are to be used. Proponents and opponents of one of the semantics should be clear about what solution they see that is supported by the semantics they choose. --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 25 15:21:42 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6C7C3A6AA2; Tue, 25 Nov 2008 15:21:42 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 784CB3A6AA2 for ; Tue, 25 Nov 2008 15:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+xyOsXsLtLw for ; Tue, 25 Nov 2008 15:21:41 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id A88E53A699F for ; Tue, 25 Nov 2008 15:21:41 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so162047rvf.49 for ; Tue, 25 Nov 2008 15:21:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer:sender; bh=GvxiUJAfOylsaCUxj+xoYN/WdRX5T7iExQlMbyUAEbI=; b=nOnXGRD3hBcAgczyKNztCuIoNC2T4jzw72nq75eFj5+yAG95EjdN7FHOBG6g0I0veB 9psfcuue4KDmLLtSJAIVydZyLICr/rEm91s6CDO5Rw4QJ0Dq0e7sNHLQAfVrsZYxRo9M KE4v9P5jfI0x0zJMB915m5R6X65/yFrygFVSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer:sender; b=ADee3hbsgGwvoHovmF4j/vQmcPB1iv/Cgxiuj13/U5MlCXo7MdFKOOtkACP/41IcBx 8+Sf+hfEaD9eu/rxe+8z8FK8mcpwaa8ngofaQYgzNKWhV+Kc6phZVl1gp2RIYH1BhXcn 5pbdGjLpXB61O4mNzPjkB0/cg/MShJjIIgmAk= Received: by 10.140.132.4 with SMTP id f4mr2614492rvd.201.1227655298518; Tue, 25 Nov 2008 15:21:38 -0800 (PST) Received: from ?192.168.1.101? (c58-108-227-223.fitzg1.qld.optusnet.com.au [58.108.227.223]) by mx.google.com with ESMTPS id g31sm16219384rvb.7.2008.11.25.15.21.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 25 Nov 2008 15:21:37 -0800 (PST) Message-Id: From: Terry Manderson To: Danny McPherson In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 26 Nov 2008 09:21:32 +1000 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Hey Danny, On 26/11/2008, at 12:34 AM, Danny McPherson wrote: > > > Perhaps if you'd outline a couple use cases of BOAs I'd better > understand how this is useful and provides more net benefits than > offshoots? There are several use cases that come to mind, but only one I can anonymise and present with the organisation's permission. Lets say XYZ Bank has a significant address holding, due to their engineering design they actually use globally routable unique addresses for all of their internal infrastructure as it makes their redundancy and fail-over mechanisms clean. This "infrastructure" set of addresses is never meant to be seen in global routing tables. (yes even though they have firewalls and all types of black-boxes protecting it). In partial deployment the BOA gives the XYZ Bank the higher level _policy_ power which goes beyond router configuration to say "our infrastructure prefixes are not to be accepted and certainly not routed" irrespective of any router config fumbles. I guess in someway this might be similar to a large cable provider that could use a specific IPv6 range for managing their SOHO units. Equally those prefixes aren't intended to ever see the light of a DFZ. So they also might issue a BOA to that effect. If a BOA is not available to them, the interpretation of just a ROA for the intended routable address space is that the prefix for the ROA IS accepted, but the other prefixes MAY be accepted, based on local (theirs and third party) router config. There is no high level statement to the effect of 'ONLY route prefix x/y' until full deployment. I'll do my best to get permission to discuss other examples that cover BOA use in a full deployment environment. Cheers Terry _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 25 17:39:23 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 574B73A6B1B; Tue, 25 Nov 2008 17:39:23 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 247753A6B1B for ; Tue, 25 Nov 2008 17:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0u-N2iWeg5y for ; Tue, 25 Nov 2008 17:39:21 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id DD7C83A6B08 for ; Tue, 25 Nov 2008 17:39:20 -0800 (PST) Received: from [172.16.19.23] (unknown [210.188.139.188]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id ED42D110066; Wed, 26 Nov 2008 11:39:16 +1000 (EST) Message-Id: From: Geoff Huston To: Danny McPherson In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 26 Nov 2008 12:39:07 +1100 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG Chair Hat OFF On 26/11/2008, at 1:34 AM, Danny McPherson wrote: > > On Nov 25, 2008, at 2:28 AM, Geoff Huston wrote: > >> - you do not want to use a BOA in your environment, and you want to >> stop anyone else from using as BOA in terms of a BOA as defined by >> an IETF standards document in any case. > > For you to come to the list of conclusions above simply because > I don't like the idea of BOAs is quite a leap. I'd prefer you not > speculate what you believe to be my position, and instead, address > the issue which lead to this discussion - convince me of the > positive value of BOAs, which I've yet to realize. One way to reach understanding in a dialogue Danny is for one party to to reiterate their understanding of what was said by the other, to check that there is some level of mutual appreciation of what is being said. You failed to quote above, and perhaps failed to appreciate, that this remark of mine that you have quoted was prefaced by the comment: "So what I think you are saying here Danny is that:" Evidently I was mistaken in my understanding of what you were saying Danny, and I apologise if this process of reiteration has caused you any personal offense or triggered some personal sensitivity, but, frankly, if we keep on talking past each other then nothing useful will result in any case. So I still believe that there is some merit in attempting to understand the argument that is being advanced here. So I do want to understand your position, and yes, in so doing I find it helpful to reiterate back what I understand you to be saying here, and yes, you may interpret that as speculation on my part, and I trust you will continue to correct such speculation until you are happy that I am accurately phrasing your arguments here. If that process is not acceptable to you then I'm not sure where we go from here, as I evidently still really don't understand the argument you are advancing at all. > > > Perhaps if you'd outline a couple use cases of BOAs I'd better > understand how this is useful and provides more net benefits than > offshoots? > Sure. So here's some use cases of BOAs: 1. I have been allocated 203.10.61.0/24. I do not use it today in any public routing context. It should not appear in BGP at all. I do not give my authorization to any AS to originate a route for this prefix, or any more specific of this prefix. If I generate a BOA for 203.10.61.0/24 then my intention of saying that any use of this prefix in the public Internet is unauthorized is clear. 2. I have been allocated AS 131074 as an AS number. I do not use it today in any public routing context. It should not appear in BGP at all either as an origination AS nor as a transit AS in any AS path. If I generate a BOA for AS131074 then my intention of saying that any use of this AS number in the public Internet is unauthorized is clear. 3. I have been allocated 203.10.60.0/22. I wish to ensure that any more specific advertisement of this prefix is unauthorized. If I generate a BOA for 203.10.60.0/23 AND 203.10.62.0/23 then my intention is clear. And a non-use case of BOAs: 4. I am a wholesale ISP, and while I allocate address space to my clients from my aggregate address block (10.0.0.0/8) I also permit my clients to use their more specific prefix at local exchanges. My AS number is 131072 and I have generated a ROA for 10.0.0.0/8 , maxlength=8 origin AS 131072. I do not have a problem with more specifics of 10.0.0.0/8 being used in routing contexts, as part of my wholesale stance. I would prefer that my ROA did not cause my customer's more specifics to be treated as unauthorized routes, irrespective of whether they are ready to use a ROA today or not. regards, Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 25 18:06:19 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A7183A6C88; Tue, 25 Nov 2008 18:06:19 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EEBE3A6C87 for ; Tue, 25 Nov 2008 18:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFGQrMonFMWa for ; Tue, 25 Nov 2008 18:06:17 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 4C05B3A6C84 for ; Tue, 25 Nov 2008 18:06:17 -0800 (PST) Received: from [172.16.19.23] (unknown [210.188.139.188]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id A55F1110065; Wed, 26 Nov 2008 12:06:11 +1000 (EST) Message-Id: <172E78ED-6301-4BDF-AFF4-0C37962F0133@apnic.net> From: Geoff Huston To: Sandra Murphy In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 26 Nov 2008 13:06:09 +1100 References: X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 26/11/2008, at 8:12 AM, Sandra Murphy wrote: > > > On Wed, 12 Nov 2008, Geoff Huston wrote: > >> WG Co-Chair hat _OFF_ >> >> Sandy, >> >> The authors of these two drafts now believe that all SIDR WG >> comments have been integrated into these documents, and there are >> no further outstanding comments to be addressed. >> >> Accordingly, we would like to request that you conduct a WG Last >> Call for these documents in order to ensure that the WG is now >> comfortable with these documents and all comments have been made, >> and to assess whether the WG is now ready to move these two >> documents to the IESG for IESG review. >> > > It is clear from the ensuing discussion that we are not close enough > to consensus in this matter to conduct a last call. > > We do need to work out the issues being raised before we can > reasonably conduct a last call. > > --Sandy > WG Co-Chair hat OFF Thanks for your response Sandy. To the extent that this request for a WGLC on these documents has provoked reading of these drafts and discussion of the issues in the WG, this has been a very useful exercise so far. I trust that the deferral of this call is not seen as an excuse by interested folk to defer the WG discussion as well, as the debate so far has, I think, managed to expose some substantive issues relating to the semantics of these objects that I feel remain as yet unresolved in terms of achieving consensus, rough or otherwise. regards, Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 25 18:25:43 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 129123A6938; Tue, 25 Nov 2008 18:25:43 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 707873A6938 for ; Tue, 25 Nov 2008 18:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6nTbjY4VH8O for ; Tue, 25 Nov 2008 18:25:41 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by core3.amsl.com (Postfix) with ESMTP id 79C383A68B7 for ; Tue, 25 Nov 2008 18:25:41 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id 3C473A688A; Tue, 25 Nov 2008 21:25:36 -0500 (EST) Received: from ex.arin.net (ex.arin.net [192.136.136.237]) by smtp2.arin.net (Postfix) with ESMTP id 9919DA6888; Tue, 25 Nov 2008 21:25:35 -0500 (EST) Received: from EDAMAME.arin.net ([192.136.136.194]) by ex.arin.net ([192.136.136.237]) with mapi; Tue, 25 Nov 2008 21:25:35 -0500 From: Andy Newton To: Geoff Huston , Danny McPherson Date: Tue, 25 Nov 2008 21:25:33 -0500 Thread-Topic: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt Thread-Index: AclPZ9m8IAdeMjTIS8aWcB954uvAOgABmhSV Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Perhaps these should be considered for informative text in an I-D. -andy On 11/25/08 8:39 PM, "Geoff Huston" wrote: > Sure. So here's some use cases of BOAs: > > 1. I have been allocated 203.10.61.0/24. I do not use it today in any > public routing context. It should not appear in BGP at all. I do not > give my authorization to any AS to originate a route for this prefix, > or any more specific of this prefix. If I generate a BOA for > 203.10.61.0/24 then my intention of saying that any use of this prefix > in the public Internet is unauthorized is clear. > > 2. I have been allocated AS 131074 as an AS number. I do not use it > today in any public routing context. It should not appear in BGP at > all either as an origination AS nor as a transit AS in any AS path. If > I generate a BOA for AS131074 then my intention of saying that any use > of this AS number in the public Internet is unauthorized is clear. > > 3. I have been allocated 203.10.60.0/22. I wish to ensure that any > more specific advertisement of this prefix is unauthorized. If I > generate a BOA for 203.10.60.0/23 AND 203.10.62.0/23 then my intention > is clear. > > And a non-use case of BOAs: > > 4. I am a wholesale ISP, and while I allocate address space to my > clients from my aggregate address block (10.0.0.0/8) I also permit my > clients to use their more specific prefix at local exchanges. My AS > number is 131072 and I have generated a ROA for 10.0.0.0/8 , > maxlength=8 origin AS 131072. I do not have a problem with more > specifics of 10.0.0.0/8 being used in routing contexts, as part of my > wholesale stance. I would prefer that my ROA did not cause my > customer's more specifics to be treated as unauthorized routes, > irrespective of whether they are ready to use a ROA today or not. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 25 19:56:18 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B496A3A6A0D; Tue, 25 Nov 2008 19:56:18 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B36FE3A6A0D for ; Tue, 25 Nov 2008 19:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94OazGvztdHy for ; Tue, 25 Nov 2008 19:56:17 -0800 (PST) Received: from pirate.partan.com (pirate.partan.com [198.6.255.242]) by core3.amsl.com (Postfix) with ESMTP id 00C003A692C for ; Tue, 25 Nov 2008 19:56:16 -0800 (PST) Received: from pirate.partan.com (localhost.partan.com [127.0.0.1]) by pirate.partan.com (8.14.2/8.14.2) with ESMTP id mAQ3u5wc074556; Tue, 25 Nov 2008 22:56:05 -0500 (EST) (envelope-from asp@pirate.partan.com) Received: (from asp@localhost) by pirate.partan.com (8.14.2/8.14.2/Submit) id mAQ3u594074553; Tue, 25 Nov 2008 22:56:05 -0500 (EST) (envelope-from asp) Date: Tue, 25 Nov 2008 22:56:05 -0500 From: Andrew Partan To: Geoff Huston Message-ID: <20081126035605.GA74504@partan.com> References: <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Wed, Nov 26, 2008 at 12:39:07PM +1100, Geoff Huston wrote: > 3. I have been allocated 203.10.60.0/22. I wish to ensure that any > more specific advertisement of this prefix is unauthorized. If I > generate a BOA for 203.10.60.0/23 AND 203.10.62.0/23 then my intention > is clear. How far down do you have to generate the BOAs? Do you have to generate BOAS for the 4 /24s and the 8 /25s and the ... ? Or do the two /23s cover all the possible more specifics? Andrew Partan _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 25 20:07:44 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08A733A6A72; Tue, 25 Nov 2008 20:07:44 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 041273A6A72 for ; Tue, 25 Nov 2008 20:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqD+uVi0CNIU for ; Tue, 25 Nov 2008 20:07:41 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 73A743A67A3 for ; Tue, 25 Nov 2008 20:07:41 -0800 (PST) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L5BgY-000Erp-EG; Wed, 26 Nov 2008 04:07:30 +0000 Message-ID: <492CCB80.2030501@psg.com> Date: Wed, 26 Nov 2008 13:07:28 +0900 From: Randy Bush User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Andy Newton References: In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: "sidr@ietf.org" Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Andy Newton wrote: > Perhaps these should be considered for informative text in an I-D. i think we are missing something more basic, a clear, simple, concise, terse, and rigorous definition of the semantics of a roa. then, and only then, can we start to discuss the need/use of a boa. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 25 20:44:03 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A65A03A67A1; Tue, 25 Nov 2008 20:44:03 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1B4D3A6804 for ; Tue, 25 Nov 2008 20:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xx6zmg7c+gtF for ; Tue, 25 Nov 2008 20:44:02 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id EA7F23A67A1 for ; Tue, 25 Nov 2008 20:44:01 -0800 (PST) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L5CFo-000EvR-Be; Wed, 26 Nov 2008 04:43:56 +0000 Message-ID: <492CD40A.3040606@psg.com> Date: Wed, 26 Nov 2008 13:43:54 +0900 From: Randy Bush User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Geoff Huston References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org 1, 2, and 4 are uninteresting to me, not worth the additional complexity. > 3. I have been allocated 203.10.60.0/22. I wish to ensure that any more > specific advertisement of this prefix is unauthorized. If I generate a > BOA for 203.10.60.0/23 AND 203.10.62.0/23 then my intention is clear. ROA 203.10.60.0/22-22 the owner of the prefix has spoken. that is what may be announced and that is all that may be announced. as nw once said "i did not leave that out because i ran out of ink." randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 25 20:46:40 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCEE03A67A5; Tue, 25 Nov 2008 20:46:40 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48ADB3A67A5 for ; Tue, 25 Nov 2008 20:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1cUIf+XAIz0 for ; Tue, 25 Nov 2008 20:46:38 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 6C6B53A67A1 for ; Tue, 25 Nov 2008 20:46:38 -0800 (PST) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L5CIL-000Ew7-U2; Wed, 26 Nov 2008 04:46:34 +0000 Message-ID: <492CD4A8.10502@psg.com> Date: Wed, 26 Nov 2008 13:46:32 +0900 From: Randy Bush User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Terry Manderson References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > Lets say XYZ Bank has a significant address holding, due to their > engineering design they actually use globally routable unique addresses > for all of their internal infrastructure as it makes their redundancy > and fail-over mechanisms clean. so they are not harmed if, during transition, others fat finger it into the dfz. next. if they really care, issue a roa for it to their real provider, to a private asn, to asn 0, or whatever. no one cares, least of all the owner. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 25 21:28:49 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 048373A6B1C; Tue, 25 Nov 2008 21:28:49 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6366F3A6B1C for ; Tue, 25 Nov 2008 21:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54EgOSsqtvJR for ; Tue, 25 Nov 2008 21:28:47 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id A48263A6B07 for ; Tue, 25 Nov 2008 21:28:47 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so282714rvf.49 for ; Tue, 25 Nov 2008 21:28:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer:sender; bh=gtoDM/5LSSzXfCGxO29g/r+Rj+7hZ2X6uhiQP0V3GZM=; b=SgYIgM8vrTdAW7l8iUE9rkidKe6bNadf9PxvM9HAfhxkZxhp0BI/2pWi7liGJDl/xM arpS+cQUtL1OxemIjvzJXcgsA1eznCb08U2TOjss4bYm4d42h9PkxF7fBTqcx1pFwdbP RVWZf0dl2h36DckH/ngGFpsJL0NCbY4nx0BdA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer:sender; b=LRM1jF3iujXIb9g2j7pnETUc01epI+EQv/66OWfzSF7eiX1eP9Vu09yry/K1oUG6Fb tdDYVFIIpDPAer0A9ufp9iYGtT92h5AdlRVaxPnSfkCryGBl3zXvXmoQvkokDWGaXuja yTnkjy/bQ6iwzeImNaO3GozF6r66Uh0yCjtxY= Received: by 10.142.173.14 with SMTP id v14mr2455442wfe.53.1227677324625; Tue, 25 Nov 2008 21:28:44 -0800 (PST) Received: from ?192.168.1.101? (c58-108-227-223.fitzg1.qld.optusnet.com.au [58.108.227.223]) by mx.google.com with ESMTPS id 22sm8855674wfi.38.2008.11.25.21.28.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 25 Nov 2008 21:28:43 -0800 (PST) Message-Id: <10FB08BE-E4CC-4230-B959-BAF10A5CED3C@terrym.net> From: Terry Manderson To: Randy Bush In-Reply-To: <492CD4A8.10502@psg.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 26 Nov 2008 15:28:37 +1000 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> <492CD4A8.10502@psg.com> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 26/11/2008, at 2:46 PM, Randy Bush wrote: >> Lets say XYZ Bank has a significant address holding, due to their >> engineering design they actually use globally routable unique >> addresses >> for all of their internal infrastructure as it makes their redundancy >> and fail-over mechanisms clean. > > so they are not harmed if, during transition, others fat finger it > into > the dfz. next. > I wouldn't say they are 'not harmed'. What they consider harm, is clearly different to a network purist sense. > if they really care, issue a roa for it to their real provider, to a > private asn, to asn 0, or whatever. no one cares, least of all the > owner. > They certainly care. The issue I see with either a AS0 or private AS use is that it isn't allocated in the resource allocation hierarchy, unless all RIRs are issued with AS0 and AS64512 through to AS65535 by IANA, and then the RIRs subsequently simultaneously issued to all RIR members. Knowing that ROA's can only be issued based on the AS and IP resources allocated by the parent. This just seems wrong to me. I made the comment at the mic that this type of de-attestation is contrary to the allocation hierarchy function as it stands - I guess people missed the underlying issue I was getting at focusing only on the label. Terry _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 25 22:08:58 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65E2E3A6895; Tue, 25 Nov 2008 22:08:58 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 093BB3A6B28 for ; Tue, 25 Nov 2008 22:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+RcpkAKWXiW for ; Tue, 25 Nov 2008 22:08:56 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 13C4D3A680F for ; Tue, 25 Nov 2008 22:08:56 -0800 (PST) Received: from dhcp151.apnic.net (dhcp151.apnic.net [202.12.29.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id E7915110067 for ; Wed, 26 Nov 2008 16:08:52 +1000 (EST) Message-Id: <98DB313D-3883-425B-92F6-08FA24575680@apnic.net> From: George Michaelson To: sidr@ietf.org In-Reply-To: <492CD40A.3040606@psg.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 26 Nov 2008 16:08:52 +1000 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> <492CD40A.3040606@psg.com> X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 26/11/2008, at 2:43 PM, Randy Bush wrote: > 1, 2, and 4 are uninteresting to me, not worth the additional > complexity. > >> 3. I have been allocated 203.10.60.0/22. I wish to ensure that any >> more >> specific advertisement of this prefix is unauthorized. If I >> generate a >> BOA for 203.10.60.0/23 AND 203.10.62.0/23 then my intention is clear. > > ROA 203.10.60.0/22-22 > > the owner of the prefix has spoken. that is what may be announced and > that is all that may be announced. > > as nw once said "i did not leave that out because i ran out of ink." > > randy > _______________________________________________ In the context of BOA, you complained Randy, that a BOA compelled people lower, more specific to issue ROA to override the BOA. you complained, that they are unnecessarily brought into the process and cannot exist as non-secured routing people, unless they do this. You complained about the compulsion element. But, your statement above COMPELS any more specific, to issue a valid ROA, to prove their routes are acceptable. It has exactly the same property. Exactly. Whereas, with a BOA, you can choose to formally disclaim, or not disclaim, more specifics. The choice is left with the relying party, *unless* a BOA is issued. -george _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 25 22:20:11 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A16DE3A6B2B; Tue, 25 Nov 2008 22:20:11 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBE493A6B2B for ; Tue, 25 Nov 2008 22:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCEpEJ-b+xJf for ; Tue, 25 Nov 2008 22:20:10 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id EC44E3A680F for ; Tue, 25 Nov 2008 22:20:09 -0800 (PST) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L5Dkq-000F61-OS; Wed, 26 Nov 2008 06:20:05 +0000 Message-ID: <492CEA93.6070704@psg.com> Date: Wed, 26 Nov 2008 15:20:03 +0900 From: Randy Bush User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: George Michaelson References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> <492CD40A.3040606@psg.com> <98DB313D-3883-425B-92F6-08FA24575680@apnic.net> In-Reply-To: <98DB313D-3883-425B-92F6-08FA24575680@apnic.net> X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org George Michaelson wrote: > > On 26/11/2008, at 2:43 PM, Randy Bush wrote: > >> 1, 2, and 4 are uninteresting to me, not worth the additional complexity. >> >>> 3. I have been allocated 203.10.60.0/22. I wish to ensure that any more >>> specific advertisement of this prefix is unauthorized. If I generate a >>> BOA for 203.10.60.0/23 AND 203.10.62.0/23 then my intention is clear. >> >> ROA 203.10.60.0/22-22 >> >> the owner of the prefix has spoken. that is what may be announced and >> that is all that may be announced. >> >> as nw once said "i did not leave that out because i ran out of ink." >> >> randy >> _______________________________________________ > > In the context of BOA, you complained Randy, that a BOA compelled people > lower, more specific to issue ROA to override the BOA. you complained, > that they are unnecessarily brought into the process and cannot exist as > non-secured routing people, unless they do this. You complained about > the compulsion element. > > But, your statement above COMPELS any more specific, to issue a valid > ROA, to prove their routes are acceptable. if the owner wanted to allow longer prefix(es) to be announced, they could have issued roa(s) for the longer prefix(es). yes, once you have secured a prefix, longer matches must also be secured. this is a good thing. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 25 22:22:14 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF58E3A6B2A; Tue, 25 Nov 2008 22:22:14 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF8323A6B2A for ; Tue, 25 Nov 2008 22:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miRsmZMNJaYY for ; Tue, 25 Nov 2008 22:22:13 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 010713A680F for ; Tue, 25 Nov 2008 22:22:13 -0800 (PST) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L5Dmo-000F6X-E2; Wed, 26 Nov 2008 06:22:06 +0000 Message-ID: <492CEB0D.3000608@psg.com> Date: Wed, 26 Nov 2008 15:22:05 +0900 From: Randy Bush User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Terry Manderson References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> <492CD4A8.10502@psg.com> <10FB08BE-E4CC-4230-B959-BAF10A5CED3C@terrym.net> In-Reply-To: <10FB08BE-E4CC-4230-B959-BAF10A5CED3C@terrym.net> X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > Knowing that ROA's can only be issued based on the AS and IP resources > allocated by the parent. whoops! no. the asn in the roa is not signed or otherwise authorized. if the prefix owner chooses to issue a road for P to A, that does not mean A must announce it or A agrees. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 25 22:23:48 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F31AB3A6B2C; Tue, 25 Nov 2008 22:23:47 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 989D53A6B2E for ; Tue, 25 Nov 2008 22:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uClJ2n3KktJI for ; Tue, 25 Nov 2008 22:23:45 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id BB1E63A6B2C for ; Tue, 25 Nov 2008 22:23:45 -0800 (PST) Received: from dhcp151.apnic.net (dhcp151.apnic.net [202.12.29.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 22D6811006C for ; Wed, 26 Nov 2008 16:23:43 +1000 (EST) Message-Id: From: George Michaelson To: sidr@ietf.org In-Reply-To: <492CCB80.2030501@psg.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 26 Nov 2008 16:23:42 +1000 References: <492CCB80.2030501@psg.com> X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 26/11/2008, at 2:07 PM, Randy Bush wrote: > Andy Newton wrote: >> Perhaps these should be considered for informative text in an I-D. > > i think we are missing something more basic, a clear, simple, concise, > terse, and rigorous definition of the semantics of a roa. > > then, and only then, can we start to discuss the need/use of a boa. > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr from the roa draft: 2.1.3.2. eContent The content of a ROA identifies a single AS that has been authorized by the address space holder to originate routes and a list of one or more IP address prefixes that will be advertised. If the address space holder needs to authorize multiple ASes to advertise the same set of address prefixes, the holder issues multiple ROAs, one per AS number. and 4. Security Considerations .... The purpose of a ROA is to convey authorization for an AS to originate a route to the prefix(es) in the ROA. these are basic, clear, simple, concise, terse, and rigorous definition of the semantics of a roa. -George _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 25 22:26:30 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E39183A6B34; Tue, 25 Nov 2008 22:26:30 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E90653A6B34 for ; Tue, 25 Nov 2008 22:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssL2HP63Ipkg for ; Tue, 25 Nov 2008 22:26:29 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 193053A6A31 for ; Tue, 25 Nov 2008 22:26:29 -0800 (PST) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L5Dqz-000F77-Fm; Wed, 26 Nov 2008 06:26:25 +0000 Message-ID: <492CEC10.1070109@psg.com> Date: Wed, 26 Nov 2008 15:26:24 +0900 From: Randy Bush User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: George Michaelson References: <492CCB80.2030501@psg.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > 2.1.3.2. eContent > > The content of a ROA identifies a single AS that has been authorized > by the address space holder to originate routes and a list of one or > more IP address prefixes that will be advertised. If the address > space holder needs to authorize multiple ASes to advertise the same > set of address prefixes, the holder issues multiple ROAs, one per AS > number. > > and > > 4. Security Considerations > > > .... The purpose of a ROA is to convey authorization for an AS to > originate a route to the prefix(es) in the ROA. > > these are basic, clear, simple, concise, terse, and rigorous definition > of the semantics of a roa. and incomplete. for example, this does not deal with netmask and max len issues. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 25 22:31:00 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 385353A6B2A; Tue, 25 Nov 2008 22:31:00 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC1E83A6B2A for ; Tue, 25 Nov 2008 22:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPmDjm+fHSlu for ; Tue, 25 Nov 2008 22:30:58 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id C69533A6A0D for ; Tue, 25 Nov 2008 22:30:58 -0800 (PST) Received: from dhcp151.apnic.net (dhcp151.apnic.net [202.12.29.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 2E93C11006A for ; Wed, 26 Nov 2008 16:30:56 +1000 (EST) Message-Id: <41F912C2-9F6E-4DD9-9D94-2359944DDA5F@apnic.net> From: George Michaelson To: sidr@ietf.org In-Reply-To: <492CEC10.1070109@psg.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 26 Nov 2008 16:30:55 +1000 References: <492CCB80.2030501@psg.com> <492CEC10.1070109@psg.com> X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 26/11/2008, at 4:26 PM, Randy Bush wrote: (quoting ggm, who quotes the roa draft) >> 2.1.3.2. eContent >> >> The content of a ROA identifies a single AS that has been authorized >> by the address space holder to originate routes and a list of one or >> more IP address prefixes that will be advertised. If the address >> space holder needs to authorize multiple ASes to advertise the same >> set of address prefixes, the holder issues multiple ROAs, one per AS >> number. >> >> and >> >> 4. Security Considerations >> >> >> .... The purpose of a ROA is to convey authorization for an AS to >> originate a route to the prefix(es) in the ROA. >> >> these are basic, clear, simple, concise, terse, and rigorous >> definition >> of the semantics of a roa. > > and incomplete. for example, this does not deal with netmask and max > len issues. > > randy As Yakov Rekhter might say in IDR "please send text" ie, if you dislike these words, please instead of just knocking down, can you help construct? noting netmask, maxlen, which clearly removed the 'rigorous' -what else is wrong with the text? -George _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 25 22:44:46 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 809883A6B31; Tue, 25 Nov 2008 22:44:46 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E3EE3A6B2E for ; Tue, 25 Nov 2008 22:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skSq5TqpvBi9 for ; Tue, 25 Nov 2008 22:44:44 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id 7A8393A6A31 for ; Tue, 25 Nov 2008 22:44:44 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so308041rvf.49 for ; Tue, 25 Nov 2008 22:44:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer:sender; bh=Wt8keiA8DXC+jW8dq8EooL6RVAIgnV2CdXx75Xo1MK4=; b=orplC2IEcgO29U6YIVPCtz7BznAHB4CzNsMgtvLRcOLoHF/7lDVZmQnhu0bO4XeqrG 8sQdNKtD+26IFuHREW1u7IRBiUUB/+8xAOzea7EqGFpfydVt6va2mRg1VyKsdJM4OkCM mkI4JH2LBYp9UUJquCRsshDXm/tXJCg4oyv7s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer:sender; b=Akuqs6+dLiQdjLUWYQeYf+KmvzVlWY5K5Q94E1Y3yGqvWyuyprA90aM7LAeNj9u6PS xuw7sxdY9rdW9g0XJOxpPTaSUrB/4i40xpBKXRRwHMZkW5HnJ6QnRZF8gxOmfzKKLVRs vLBAJxH+Esb/dgDpZTGzX6R/EslItp7nx0TBg= Received: by 10.140.185.1 with SMTP id i1mr2794840rvf.72.1227681880607; Tue, 25 Nov 2008 22:44:40 -0800 (PST) Received: from ?192.168.1.101? (c58-108-227-223.fitzg1.qld.optusnet.com.au [58.108.227.223]) by mx.google.com with ESMTPS id g31sm16395371rvb.7.2008.11.25.22.44.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 25 Nov 2008 22:44:39 -0800 (PST) Message-Id: <4AE0CB31-6683-4203-8EED-4560B83C2DFD@terrym.net> From: Terry Manderson To: Randy Bush In-Reply-To: <492CEB0D.3000608@psg.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 26 Nov 2008 16:44:34 +1000 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> <492CD4A8.10502@psg.com> <10FB08BE-E4CC-4230-B959-BAF10A5CED3C@terrym.net> <492CEB0D.3000608@psg.com> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 26/11/2008, at 4:22 PM, Randy Bush wrote: >> Knowing that ROA's can only be issued based on the AS and IP >> resources >> allocated by the parent. > > whoops! no. the asn in the roa is not signed or otherwise > authorized. ..sigh.. I'm _sure_ I read in one of the many documents that an ASN had to be in a signed state somewhere. (off looking...) Terry _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 25 22:54:05 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D25D13A6B33; Tue, 25 Nov 2008 22:54:05 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 030713A6B33 for ; Tue, 25 Nov 2008 22:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEjFZD1+GcMa for ; Tue, 25 Nov 2008 22:54:03 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 017D23A6A31 for ; Tue, 25 Nov 2008 22:54:03 -0800 (PST) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L5EHe-000F9k-S7; Wed, 26 Nov 2008 06:53:59 +0000 Message-ID: <492CF285.6090900@psg.com> Date: Wed, 26 Nov 2008 15:53:57 +0900 From: Randy Bush User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: George Michaelson References: <492CCB80.2030501@psg.com> <492CEC10.1070109@psg.com> <41F912C2-9F6E-4DD9-9D94-2359944DDA5F@apnic.net> In-Reply-To: <41F912C2-9F6E-4DD9-9D94-2359944DDA5F@apnic.net> X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > ie, if you dislike these words, please instead of just knocking down, > can you help construct? see wrestling with pigs. and this is my last go on this for today. > noting netmask, maxlen, which clearly removed the 'rigorous' -what else > is wrong with the text? it does not even say that if there is a roa specifying that A may announce P, that, in the absence of a roa saying that B may also announce P, an announcement of P by B should be rejected. it should. the owner stated their intent. if they had intended B to announce, they could and should have said so. they did not run out of ink or lack the pen. in fact, it strangely says the opposite, "While the presence of a valid ROA that matches the advertisement is a strong indication that an advertisement matches the authority provided by the prefix holder to advertise the prefix into the routing system, the absence of a ROA or the invalidity of a covering ROA does not provide a conclusive indication that the advertisement has been undertaken without the address holder's permission ..." to me that is a whole lot of broken words merely in order to justify boas. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Nov 26 02:21:33 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04A6B28C1C8; Wed, 26 Nov 2008 02:21:33 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 004C728C1B4 for ; Wed, 26 Nov 2008 02:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7pFjaB+cytQ for ; Wed, 26 Nov 2008 02:21:31 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id 3975128C0ED for ; Wed, 26 Nov 2008 02:21:31 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so383455rvf.49 for ; Wed, 26 Nov 2008 02:21:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer:sender; bh=18lzUmw6zlFsK5COILlF6hf9RZnpvQbplN4HfnQq1eU=; b=ujjC1RwvWjPon5mc6jDQGTNqS0MBRpxpztHsyh6E+UbSq5jSeJI9KifESMZlY//JMs YH4r5TJHb8hBFQoG6kquFfchHT06HqPfD9WeaE4Ch5+9/9+L+bET/Ld35O/zKQ/hOjt/ SHbCac6/gj5sUxAAZaoXCOcX8c+bO3mPtMD3s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer:sender; b=t9ucghNNbGtfBXdIuBGWxY8l2FPiWz4NNtmGMY10y2Ba0BnSZ0i7rxO2OwPBfs8JMH jpqyRC88Njikx/eI1PeMIgzcseK2XA0pUgusworszyau1sE/1PPIf2FqmotWVGB5TeS0 rDVNwViAKWO618+uqfwTBkv0tloi0P0Aa18Hk= Received: by 10.140.226.14 with SMTP id y14mr2867954rvg.59.1227694887569; Wed, 26 Nov 2008 02:21:27 -0800 (PST) Received: from ?192.168.1.101? (c58-108-227-223.fitzg1.qld.optusnet.com.au [58.108.227.223]) by mx.google.com with ESMTPS id k37sm1497603rvb.1.2008.11.26.02.21.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 26 Nov 2008 02:21:26 -0800 (PST) Message-Id: <2AB607B7-1B26-4769-8A0D-EB86516C4350@terrym.net> From: Terry Manderson To: sidr@ietf.org In-Reply-To: <10FB08BE-E4CC-4230-B959-BAF10A5CED3C@terrym.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 26 Nov 2008 20:21:20 +1000 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> <492CD4A8.10502@psg.com> <10FB08BE-E4CC-4230-B959-BAF10A5CED3C@terrym.net> X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 26/11/2008, at 3:28 PM, Terry Manderson wrote: > The issue I see with either a AS0 or private AS use is that it > isn't allocated in the resource allocation hierarchy, unless all > RIRs are issued with AS0 and AS64512 through to AS65535 by IANA, and > then the RIRs subsequently simultaneously issued to all RIR members. > Knowing that ROA's can only be issued based on the AS and IP > resources allocated by the parent. I'll walk back from this politely.. Indeed there is nothing in the RPKI drafts which requires that any ASN be in a signed or certified state. (I must have been smoking something really good at the time ;-) Terry _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Nov 26 05:10:16 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2F7C3A68DA; Wed, 26 Nov 2008 05:10:16 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5835828C12E for ; Wed, 26 Nov 2008 05:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GBgQavtIJjF for ; Wed, 26 Nov 2008 05:10:13 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 45DB03A68B6 for ; Wed, 26 Nov 2008 05:10:13 -0800 (PST) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L5K9d-000FqM-Lw; Wed, 26 Nov 2008 13:10:06 +0000 Message-ID: <492D4AAC.9050703@psg.com> Date: Wed, 26 Nov 2008 22:10:04 +0900 From: Randy Bush User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Sandra Murphy References: In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] Two important points X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > ATT understand the RPKI and uses certs and ROAs, but their multihomed > customer in Bolivia, to whom they have sub-allocated some of their > space, does not. Just exactly what can ATT do (what gets signed by > whom and what gets checked by whom) that will prevent a more-specific > prefix hijacking but will not dis-enfranchize their legitimate but > clueless customer? AT&T owns the prefix. they are responsible for the routing. they issue o a ROA for the whole prefix to their own ASN with max-len as they announce it o a ROA for the sub-alloc to customer's ASN with max-len that AT&T is willing to get whines for routing table pollution > An RIR has been delegation 64/8. Just exactly how (what gets signed by > whom and what gets checked by whom) do we prevent annoucements of > superblocks of and within this delegation? the rir has no authority to prevent anything of the superblock, e.g. 64/7, because 65/8 is not theirs to control. blocks within 64/8 will be ROAed by the folk to whom the rir allocates. blocks within 64/8 which have not been allocated may be announced by anyone, and there is no roa to contradict them. the rir should not issue a roa for 64/8-8 to itself because then they would have to become involved in issuing ROAs for the allocatees which are not capable of issuing ROAs themselves. yes, during roll-out, the spammers can still source from unused rir space, though not unused iana space, as iana can blackhole ROA the whole /8. but the primary goal is to secure correct routing, not to prevent spam. > Second is the exact semantics of the ROA itself or a set of ROAs. It is > clear that everyone is not reading from the same page for this > (which is troubling to show up this late in the specification game). > This has shown up in several messages, and the popular alternatives are > a set of ROAs grants right to use a prefix to a set of ASs > a set of ROAs grants right to use a prefix to a set of ASs and no > others. as i said in a previous message, imiho the latter. note that, in the first section, if the rir was to issue 64/8-8 A(rir) and an allocatee issues 64.42/24-24 A(allocatee) the router has to recognize that the latter means accept an announcement of 64.42/24 from A(allocatee) despite the mismatch to 64/8-8 A(rir). but, as i said above, i do not advise the rir to issue the 64/8-8 A(rir). they are the only ones in the chain, iana, rir, nir, lir, lir, user, which is ill advised to do so. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Nov 26 08:39:01 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EA8628C127; Wed, 26 Nov 2008 08:39:01 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 386503A6B68 for ; Wed, 26 Nov 2008 08:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaDcok8hP5pk for ; Wed, 26 Nov 2008 08:38:59 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 149B93A6B67 for ; Wed, 26 Nov 2008 08:38:58 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id mAQGcoB7012447; Wed, 26 Nov 2008 10:38:50 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id mAQGcoTC001416; Wed, 26 Nov 2008 10:38:50 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([192.168.1.103]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Nov 2008 11:38:49 -0500 Date: Wed, 26 Nov 2008 11:38:48 -0500 (Eastern Standard Time) From: Sandra Murphy To: Andy Newton In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 26 Nov 2008 16:38:49.0996 (UTC) FILETIME=[75D7ECC0:01C94FE5] Cc: "sidr@ietf.org" Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org I've seen use cases developed into an i-d in other working groups, but that involves a lot of effort to ensure the list is complete and consistent. I mention two, Geoff has added four more. It would take time to be complete - do we want to take the time? One aspect of the use cases is new operational practices that may arise from different approaches. (For example: if I'm worried that my customers may be impacted if they do not sign ROAs, perhaps I automatically do it for all customers as part of allocation. But then we'd have to look carefully about moving out-sourced-CA services from me to my customer at some point. This is NOT NOT NOT a definite suggestion, just an example of my belief that operational practices will be induced by any solution.) --Sandy On Tue, 25 Nov 2008, Andy Newton wrote: > Perhaps these should be considered for informative text in an I-D. > > -andy > > > On 11/25/08 8:39 PM, "Geoff Huston" wrote: > >> Sure. So here's some use cases of BOAs: >> >> 1. I have been allocated 203.10.61.0/24. I do not use it today in any >> public routing context. It should not appear in BGP at all. I do not >> give my authorization to any AS to originate a route for this prefix, >> or any more specific of this prefix. If I generate a BOA for >> 203.10.61.0/24 then my intention of saying that any use of this prefix >> in the public Internet is unauthorized is clear. >> >> 2. I have been allocated AS 131074 as an AS number. I do not use it >> today in any public routing context. It should not appear in BGP at >> all either as an origination AS nor as a transit AS in any AS path. If >> I generate a BOA for AS131074 then my intention of saying that any use >> of this AS number in the public Internet is unauthorized is clear. >> >> 3. I have been allocated 203.10.60.0/22. I wish to ensure that any >> more specific advertisement of this prefix is unauthorized. If I >> generate a BOA for 203.10.60.0/23 AND 203.10.62.0/23 then my intention >> is clear. >> >> And a non-use case of BOAs: >> >> 4. I am a wholesale ISP, and while I allocate address space to my >> clients from my aggregate address block (10.0.0.0/8) I also permit my >> clients to use their more specific prefix at local exchanges. My AS >> number is 131072 and I have generated a ROA for 10.0.0.0/8 , >> maxlength=8 origin AS 131072. I do not have a problem with more >> specifics of 10.0.0.0/8 being used in routing contexts, as part of my >> wholesale stance. I would prefer that my ROA did not cause my >> customer's more specifics to be treated as unauthorized routes, >> irrespective of whether they are ready to use a ROA today or not. > > _______________________________________________ > 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 sidr-bounces@ietf.org Wed Nov 26 08:48:18 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C4F53A6B6C; Wed, 26 Nov 2008 08:48:18 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 769B83A6B6C for ; Wed, 26 Nov 2008 08:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGUL6Pf01G9J for ; Wed, 26 Nov 2008 08:48:16 -0800 (PST) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id C3D5C3A6B67 for ; Wed, 26 Nov 2008 08:48:16 -0800 (PST) Received: from zx80.arin.net ([::ffff:192.136.136.49]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 26 Nov 2008 11:48:12 -0500 id 0158872D.492D7DCC.000044A1 Message-Id: From: Andrew Newton To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 26 Nov 2008 11:48:12 -0500 X-Mailer: Apple Mail (2.929.2) Subject: [sidr] the meaning of the RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > i think we are missing something more basic, a clear, simple, concise, > terse, and rigorous definition of the semantics of a roa. > > then, and only then, can we start to discuss the need/use of a boa. This seems to be a divergent view from the recent proclamation that BOAs are nothing more than ROA "syntactic sugar". Or is it an evolved (mis)understanding? If nothing else, BOAs have brought to our attention that there is lack of coherent understanding regarding the deployment of a catholic RPKI. Is its true purpose merely to give us faith that what has been published is the true word, or must all relying parties interpret the bits devoutly? If there is no strict adherence to devotion, shouldn't the available expression of the bits also be less limiting? -andy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Nov 26 11:11:43 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30BCE3A6852; Wed, 26 Nov 2008 11:11:43 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 017C83A6852 for ; Wed, 26 Nov 2008 11:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBsEEzApUPK1 for ; Wed, 26 Nov 2008 11:11:40 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id AA28F3A67DB for ; Wed, 26 Nov 2008 11:11:40 -0800 (PST) Received: from dhcp89-089-227.bbn.com ([128.89.89.227] helo=[128.89.89.71]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1L5PnT-00060V-AS for sidr@ietf.org; Wed, 26 Nov 2008 14:11:35 -0500 Mime-Version: 1.0 Message-Id: Date: Wed, 26 Nov 2008 14:11:32 -0500 To: sidr@ietf.org From: Stephen Kent Subject: [sidr] test message X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Pardon this message as I try to find out while I still am not receiving SIDR messages in my BBN mailbox. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Nov 26 12:53:27 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37CAB3A6B60; Wed, 26 Nov 2008 12:53:27 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CF6B3A6877 for ; Wed, 26 Nov 2008 12:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERK3MnwUnh8F for ; Wed, 26 Nov 2008 12:53:25 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 4F2853A67AC for ; Wed, 26 Nov 2008 12:53:25 -0800 (PST) Received: from dhcp89-089-227.bbn.com ([128.89.89.227]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1L5RNu-0007h8-CL; Wed, 26 Nov 2008 15:53:18 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4922E1E3.4020608@ripe.net> Date: Wed, 26 Nov 2008 15:53:15 -0500 To: Geoff Huston From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [sidr] WG adoption of draft-kisteleki-sidr-rpsl-sig-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org I have mixed feelings about this proposal. I do not object in principle to signed RPSL, and using an EE cert from the RPKI to verify signed RPSL data seems reasonable as well. However, I worry that we need to tightly restrict which RPSL data can be validated using an RPKI cert. My concern is that it would be easy for folks to misinterpret the extent of what an RPLI cert attests to, and thus accord signed RPSL data more trust than it deserves. I also worry that using RPKI certs for this purpose might cause folks to want to have Subject names be meaningful, not arbitrary, as now required by our specs. So, if Robert is comfortable with imposing these sorts of constraints, I think it appropriate to make this a work item. Finally, I am also very sympathetic to the non-technical issue Randy cited, i.e., will adoption of this as a WG item distract us from the rest of the work we are already pursuing? Our first priority should be to focus on the 11 extant WG documents, achieve consensus, and progress them to RFCs. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Nov 26 16:18:01 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EA453A6C96; Wed, 26 Nov 2008 16:18:01 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B38713A6C96 for ; Wed, 26 Nov 2008 16:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRByXmSrMxJe for ; Wed, 26 Nov 2008 16:18:00 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id A06683A6C90 for ; Wed, 26 Nov 2008 16:17:59 -0800 (PST) Received: from dhcp151.apnic.net (dhcp151.apnic.net [202.12.29.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 4B301110068 for ; Thu, 27 Nov 2008 10:17:56 +1000 (EST) Message-Id: <02154410-86D5-47E1-9EED-491D7FD55346@apnic.net> From: George Michaelson To: sidr@ietf.org In-Reply-To: <492CF285.6090900@psg.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 27 Nov 2008 10:17:56 +1000 References: <492CCB80.2030501@psg.com> <492CEC10.1070109@psg.com> <41F912C2-9F6E-4DD9-9D94-2359944DDA5F@apnic.net> <492CF285.6090900@psg.com> X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 26/11/2008, at 4:53 PM, Randy Bush wrote: >> ie, if you dislike these words, please instead of just knocking down, >> can you help construct? > > see wrestling with pigs. and this is my last go on this for today. I find this comment offensive, and if the intention was to belittle me, then it has certainly succeeded. > >> noting netmask, maxlen, which clearly removed the 'rigorous' -what >> else >> is wrong with the text? > > it does not even say that if there is a roa specifying that A may > announce P, that, in the absence of a roa saying that B may also > announce P, an announcement of P by B should be rejected. So, although previously you have said that you do not wish downstream players to be brought into this process involuntarily, and you have also stated that we should respect current ISP/Operator practice, which includes holders of aggregate/covering blocks announcing that block, but permitting specific prefixes to be multihomed and announced as more specifics, you now say that in this emerging reality, if a ROA exists for the superblock then a consequence is that *ALL* announcements for more specifics *MUST* be covered by a ROA, even during the partial deployment scenario. IE you are now a 'maximalist' and believe that the act of a superior delegate LIR/ISP issuing a ROA requires all downstream participants with routing rights in that block, to become full-blown players in RPKI? Can I just confirm that on-record Randy? > > > it should. the owner stated their intent. if they had intended B to > announce, they could and should have said so. they did not run out of > ink or lack the pen. > > in fact, it strangely says the opposite, > > "While the presence of a valid ROA that matches the advertisement is a > strong indication that an advertisement matches the authority provided > by the prefix holder to advertise the prefix into the routing system, > the absence of a ROA or the invalidity of a covering ROA does not > provide a conclusive indication that the advertisement has been > undertaken without the address holder's permission ..." > > to me that is a whole lot of broken words merely in order to justify > boas. Randy, the text *I* posted to you, came from the ---> R.O.A. <--- draft, which is authored by Steve Kent and others. It has *NO* reference to BOA, none at all. If you wish to critique the formalisms over a ROA, the canonical text is in the ROA draft, and if you wish to discuss the ROA draft, and its definitional language, then I think you should discuss the ROA draft. Not the BOA draft, which of course, is a different draft. Nor this draft you cite in fact. What you quoted was the validation draft. This does not define the ROA. It is a draft where we discuss validation of routing, as it says in the title: Validation of Route Origination in BGP using the Resource Certificate PKI -George > > > randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Nov 27 06:39:50 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477FA3A6844; Thu, 27 Nov 2008 06:39:50 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F32B83A687D for ; Thu, 27 Nov 2008 06:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7IktlP33Ng3 for ; Thu, 27 Nov 2008 06:39:48 -0800 (PST) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id 20CC63A67B0 for ; Thu, 27 Nov 2008 06:39:48 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1L5i1v-0002vT-Lx; Thu, 27 Nov 2008 15:39:44 +0100 Received: from Kistel-Mac.local (chimp.ripe.net [193.0.1.199]) by herring.ripe.net (Postfix) with ESMTP id 9FBCB2F592; Thu, 27 Nov 2008 15:39:43 +0100 (CET) Message-ID: <492EB12F.4090107@ripe.net> Date: Thu, 27 Nov 2008 15:39:43 +0100 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Stephen Kent References: <4922E1E3.4020608@ripe.net> In-Reply-To: X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a2749711594af63695d8a0bc5bb821da7e8e Cc: sidr@ietf.org Subject: Re: [sidr] WG adoption of draft-kisteleki-sidr-rpsl-sig-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Stephen Kent wrote: > However, I worry that we need to tightly restrict which RPSL data can be > validated using an RPKI cert. My concern is that it would be easy for > folks to misinterpret the extent of what an RPLI cert attests to, and > thus accord signed RPSL data more trust than it deserves. I also worry > that using RPKI certs for this purpose might cause folks to want to have > Subject names be meaningful, not arbitrary, as now required by our > specs. So, if Robert is comfortable with imposing these sorts of > constraints, I think it appropriate to make this a work item. Section (2) of the draft says: "2. Meaning of a signature By signing an RPSL object, the signer of the object expresses that: o they have the right to use the resource that the object refers to (ie. found as the primary key or in some other field of the object); o ..." So in fact I already restrict the usage to only those type of objects that have something to to with actual number resources (ie. this excludes person objects). I'd be less comfortable to state *in this document* that the certificate subject names should not be meaningful; I'd defer that to the higher level documents such as the certificate profile and architecture documents. However, since this is only redundancy, not a new requirement, I'm not specifically against this. Robert _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Nov 28 00:18:21 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A38353A6A57; Fri, 28 Nov 2008 00:18:21 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CF373A6847 for ; Fri, 28 Nov 2008 00:18:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbUxS3U1eOJs for ; Fri, 28 Nov 2008 00:18:20 -0800 (PST) Received: from dist1.nic.ad.jp (dist1.nic.ad.jp [202.12.30.42]) by core3.amsl.com (Postfix) with ESMTP id E4F8F3A6A57 for ; Fri, 28 Nov 2008 00:18:19 -0800 (PST) Received: from dist1.nic.ad.jp (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 85B5A80C9 for ; Fri, 28 Nov 2008 17:18:15 +0900 (JST) Received: from mbox1.nic.ad.jp (mbox1.nic.ad.jp [10.10.24.1]) by dist1.nic.ad.jp (Postfix) with ESMTP id 5105D80C2 for ; Fri, 28 Nov 2008 17:18:15 +0900 (JST) Received: from [88.69.59.1] (extsv3.nic.ad.jp [202.12.30.170]) by mbox1.nic.ad.jp (Postfix) with ESMTP id 29B5574002; Fri, 28 Nov 2008 17:18:15 +0900 (JST) Message-ID: <492FA96E.8090907@nic.ad.jp> Date: Fri, 28 Nov 2008 17:18:54 +0900 From: Taiji Kimura User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: sidr@ietf.org References: <4922E1E3.4020608@ripe.net> In-Reply-To: <4922E1E3.4020608@ripe.net> Subject: Re: [sidr] RPSLSIG adoption? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org I would support adoption of the draft. and would like to read and review. In Japan, an implementing project for digital signature in IRR is going on. It has a tentative specification for operational test. It has different assumptions on signers from the draft. But essentials of its syntax and motivation of securing mirrored objects are very similar. The implementers seems having interest on the draft as a working item of the WG. -- kimura taiji _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Nov 28 00:40:01 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1BFD3A6A84; Fri, 28 Nov 2008 00:40:01 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DF3F3A6A84 for ; Fri, 28 Nov 2008 00:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[AWL=-1.028, BAYES_20=-0.74, DATE_IN_PAST_24_48=1.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSSR6OZWfF-B for ; Fri, 28 Nov 2008 00:40:00 -0800 (PST) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 222A33A6A57 for ; Fri, 28 Nov 2008 00:39:59 -0800 (PST) X-Trace: 56220137/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.175 X-SBRS: None X-RemoteIP: 62.188.105.175 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvAEADQ9L0k+vGmv/2dsb2JhbACDRDiJGcRGB4J2 X-IronPort-AV: E=Sophos;i="4.33,680,1220223600"; d="scan'208";a="56220137" X-IP-Direction: IN Received: from 1cust175.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.175]) by smtp.pipex.tiscali.co.uk with SMTP; 28 Nov 2008 08:39:54 +0000 Message-ID: <003201c9512c$9bb96840$0601a8c0@allison> From: "tom.petch" To: References: Date: Wed, 26 Nov 2008 19:40:44 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [sidr] One and only one RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org piggybacking, a question that has been bugging me , what is an RPKI? Is it an 'object class' of which the one discussed within sidr is an object instance? or is it something invented by sidr/RPSEC/IETF etc and does not exist outside this? I have been through the I-Ds and they all seem to take this knowledge as a prerequisite but without any normative reference thereto. Perhaps draft-ietf-sidr-arch could contain an explanation (and an expansion of RPKI when first it appears:-). Tom Petch ----- Original Message ----- From: "Andy Newton" To: Sent: Tuesday, November 18, 2008 4:17 PM Subject: [sidr] One and only one RPKI > After witnessing the CP document discussion, I'm left wondering if there is > to be one and only one RPKI. Does the IETF endorse a specific RPKI? Can > the IETF restrict any RPKI use to policies of this CP? > > -andy > > _______________________________________________ > 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 sidr-bounces@ietf.org Fri Nov 28 00:58:05 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DFD03A6A7C; Fri, 28 Nov 2008 00:58:05 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC0713A6A7C for ; Fri, 28 Nov 2008 00:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.336 X-Spam-Level: X-Spam-Status: No, score=-5.336 tagged_above=-999 required=5 tests=[AWL=1.263, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wgMaLyaujsR for ; Fri, 28 Nov 2008 00:58:04 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id F1CC63A6847 for ; Fri, 28 Nov 2008 00:58:03 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id mAS8vq2i023395; Fri, 28 Nov 2008 08:57:52 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id mAS8vpFa023394; Fri, 28 Nov 2008 08:57:51 GMT Date: Fri, 28 Nov 2008 08:57:51 +0000 From: bmanning@vacation.karoshi.com To: andy@arin.net Message-ID: <20081128085751.GA23357@vacation.karoshi.com.> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.4.1i Cc: sidr@ietf.org Subject: Re: [sidr] One and only one RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org if indeed there is agreement on one and only one RPKI, then one of the primary advantages of using the IP protocols will be lost. there is -zero- requirement for full, continious interconnectivity in the base IP protocol. creation of a mandate for a single, one and only RPKI, forces folks into an always on, always connected mode ... and i am not sure how well this presumption will work for things like mannet/monnet networking. --bill _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sat Nov 29 07:48:51 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 073013A6403; Sat, 29 Nov 2008 07:48:51 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44DCD3A6403 for ; Sat, 29 Nov 2008 07:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8pd7Y3XlVbv for ; Sat, 29 Nov 2008 07:48:48 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 590A43A63D2 for ; Sat, 29 Nov 2008 07:48:48 -0800 (PST) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L6S3m-0005El-LF; Sat, 29 Nov 2008 15:48:42 +0000 Message-ID: <49316459.6010904@psg.com> Date: Sun, 30 Nov 2008 00:48:41 +0900 From: Randy Bush User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: bmanning@vacation.karoshi.com References: <20081128085751.GA23357@vacation.karoshi.com.> In-Reply-To: <20081128085751.GA23357@vacation.karoshi.com.> X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] One and only one RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org bmanning@vacation.karoshi.com wrote: > if indeed there is agreement on one and only one RPKI, then > one of the primary advantages of using the IP protocols will > be lost. > > there is -zero- requirement for full, continious interconnectivity > in the base IP protocol. creation of a mandate for a single, one > and only RPKI, forces folks into an always on, always connected > mode ... and i am not sure how well this presumption will work > for things like mannet/monnet networking. it's even worse than that. an rpki based on rfc 3779 extensions to x.509 does not even work with the martian/venusian network which uses campai routing with non-contiguous netmasks as desribed in Paul Tsuchiya*, "Efficient and Flexible Hierarchical Address Assignment," Proceedings INET 92, Kobe Japan, June 1992 [0] and rfc 1219. randy -- [0] - embarrassingly, the isoc seems unable to keep all papers presented at its conferences online. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr