From sidr-bounces@ietf.org Mon Jul 7 06:00:37 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 A78C528C10E; Mon, 7 Jul 2008 06:00:37 -0700 (PDT) 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 0E03A28C106 for ; Mon, 7 Jul 2008 06:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIYz05Vk3enA for ; Mon, 7 Jul 2008 06:00:34 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 6A6FA28C0F9 for ; Mon, 7 Jul 2008 06:00:34 -0700 (PDT) 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 1KFqKb-0005PG-4j; Mon, 07 Jul 2008 09:00:37 -0400 Message-ID: <48721263.6050807@bbn.com> Date: Mon, 07 Jul 2008 08:56:03 -0400 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Resource Cert List , "sidr@ietf.org" Content-Type: multipart/mixed; boundary="------------090808090406020008040803" Subject: [Sidr] ROA Format -03 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. --------------090808090406020008040803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have submitted the attached file as draft-sidr-roa-format-03. The significant changes in this version are: - The EE certificate used to verify a ROA must be included in the CMS wrapper of the ROA. - The signed attributes ContentType and MessageDigest must be included in the CMS wrapper for the ROA, other signed attributes may be included. - As proposed in Philidelphia, the syntax of the ROA was changed to allow the issuer to authorize the advertisement of prefixes up to a given maxLength. Please let me know if you have any comments on improving the clarity or content of the draft. - Matt Lepinski --------------090808090406020008040803 Content-Type: text/plain; name="draft-ietf-sidr-roa-format-03.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-sidr-roa-format-03.txt" Secure Inter-Domain Routing (sidr) M. Lepinski Internet Draft S. Kent Expires: January 2009 D. Kong Intended Status: Proposed Standard BBN Technologies July 7, 2008 A Profile for Route Origin Authorizations (ROAs) draft-ietf-sidr-roa-format-03.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. Conventions used in this document 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]. Lepinski, Kent and Kong Expires January 2009 [Page 1] Internet-Draft Route Origin Attestation Profile July 2008 Table of Contents 1. Introduction...................................................2 2. Basic Format...................................................3 2.1. Signed-Data Content Type..................................3 2.1.1. version..............................................3 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.....................................6 2.1.6.4.1. ContentType Attribute......................7 2.1.6.4.2. MessageDigest Attribute....................7 2.1.6.4.3. SigningTime Attribute......................7 2.1.6.4.4. BinarySigningTimeAttribute.................8 2.1.6.5. signatureAlgorithm..............................8 2.1.6.6. signature.......................................8 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 Lepinski, Kent and Kong Expires January 2009 [Page 2] Internet-Draft Route Origin Attestation Profile July 2008 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. CMS was chosen to take advantage of existing open source software available for processing messages in this format. 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 2.1.1. version The version is the syntax version number. It MUST be 3, corresponding to the signerInfo structure having version number 3. Lepinski, Kent and Kong Expires January 2009 [Page 3] Internet-Draft Route Origin Attestation Profile July 2008 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 } ASID ::= INTEGER ROAIPAddressFamily ::= SEQUENCE { Lepinski, Kent and Kong Expires January 2009 [Page 4] Internet-Draft Route Origin Attestation Profile July 2008 addressFamily OCTET STRING (SIZE (2..3)), addresses SEQUENCE OF ROAIPAddress } ROAIPAddress ::= SEQUENCE { address IPAdress, 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 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. Lepinski, Kent and Kong Expires January 2009 [Page 5] Internet-Draft Route Origin Attestation Profile July 2008 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] 2.1.6.4. signedAttrs The signedAttrs is defined as: Lepinski, Kent and Kong Expires January 2009 [Page 6] Internet-Draft Route Origin Attestation Profile July 2008 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. 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 Lepinski, Kent and Kong Expires January 2009 [Page 7] Internet-Draft Route Origin Attestation Profile July 2008 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. 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. Lepinski, Kent and Kong Expires January 2009 [Page 8] Internet-Draft Route Origin Attestation Profile July 2008 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 use the resource PKI to validate the ROA by performing the following steps. 1. Verify that the ROA syntax complies with this specification. In particular, verify the following: 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. 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). Lepinski, Kent and Kong Expires January 2009 [Page 9] Internet-Draft Route Origin Attestation Profile July 2008 m. The unsignedAttrs field in the SignerInfo object is omitted. 2. Use the public key in the EE certificate to verify the signature on the ROA. 3. Verify that the EE certificate has an IP Address Delegation extension [RFC3779] and that the IP address prefix(es) in that extension exactly matches the IP address prefix(es) in the ROA. 4. Verify that the EE certificate is a valid end-entity certificate in the resource PKI by constructing a valid certificate path to a trust anchor. (See [RESCERT] for more details.) Note that requiring an exact match between the IP address prefix(es) in a ROA and the IP address prefix(es) in the corresponding EE certificate does not place any limitations on ROA use. Indeed, since each EE certificate in the resource RPKI architecture is used to verify only a single ROA, it is natural to have the IP address prefixes in the certificate match those in the corresponding ROA. When the issuer of a ROA does not require an exact match between the IP address prefix(es) in the ROA and the prefix(es) advertised by the AS (when it originates routes for the prefix), the issuer includes the maxLength element within the ROAIPAddress to indicate that the AS is authorized to advertise more specific prefixes than those indicated in the ROA (up to the specified maxLength values). 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 January 2009 [Page 10] Internet-Draft Route Origin Attestation Profile July 2008 5. IANA Considerations None. 6. Acknowledgments The authors wish to thank Charles Gardiner and Russ Housley for their help and contributions. Lepinski, Kent and Kong Expires January 2009 [Page 11] Internet-Draft Route Origin Attestation Profile July 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. 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-10.txt, June, 2008 (work in progress). Lepinski, Kent and Kong Expires January 2009 [Page 12] Internet-Draft Route Origin Attestation Profile July 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 January 2009 [Page 13] Internet-Draft Route Origin Attestation Profile July 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 January 2009 [Page 14] --------------090808090406020008040803 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 --------------090808090406020008040803-- From sidr-bounces@ietf.org Mon Jul 7 14:15: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 528F428C25D; Mon, 7 Jul 2008 14:15:04 -0700 (PDT) X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EC0E728C250; Mon, 7 Jul 2008 14:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080707211501.EC0E728C250@core3.amsl.com> Date: Mon, 7 Jul 2008 14:15:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [Sidr] I-D ACTION:draft-ietf-sidr-roa-format-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 : A Profile for Route Origin Authorizations (ROAs) Author(s) : S. Kent Filename : draft-ietf-sidr-roa-format-03.txt Pages : 14 Date : 2008-7-7 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-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-roa-format-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-7-7140526.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 Wed Jul 9 12: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 24B9E3A68E0; Wed, 9 Jul 2008 12:27:17 -0700 (PDT) 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 46B0B3A68E0 for ; Wed, 9 Jul 2008 12:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECWdPdJgh6Tw for ; Wed, 9 Jul 2008 12:27:14 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 72B663A6892 for ; Wed, 9 Jul 2008 12:27:14 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id m69JRQvo008214 for ; Wed, 9 Jul 2008 14:27:26 -0500 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 m69JROdn009240 for ; Wed, 9 Jul 2008 14:27:26 -0500 Received: from localhost ([157.185.81.215]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jul 2008 15:14:27 -0400 Date: Wed, 9 Jul 2008 15:14:25 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 09 Jul 2008 19:14:27.0393 (UTC) FILETIME=[0188A310:01C8E1F8] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Wed, 09 Jul 2008 14:27:26 -0500 (CDT) Subject: [Sidr] request for agenda items 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 agendas are due one week from today. If you would like to present a topic in the upcoming wg meeting, please send the request to the list. Or directly to the wg chairs, if you wish. Please send the agenda request as soon as possible. Keep in mind that the wg chairs must compose and upload the agendas by next Wed, July 16, 17:00 PDT. --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Jul 14 13:15: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 CC6D528C2A9; Mon, 14 Jul 2008 13:15:04 -0700 (PDT) X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AC6DB28C227; Mon, 14 Jul 2008 13:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080714201501.AC6DB28C227@core3.amsl.com> Date: Mon, 14 Jul 2008 13:15:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [Sidr] I-D Action:draft-ietf-sidr-rpki-manifests-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: , 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 : Manifests for the Resource Public Key Infrastructure Author(s) : R. Austein, et al. Filename : draft-ietf-sidr-rpki-manifests-01.txt Pages : 25 Date : 2008-07-14 This document defines a "manifest" for use in the Resource Public Key Infrastructure. A "manifest" is a signed object that contains a listing of all the signed objects in the repository publication point associated with an authority responsible for publishing in the repository. For each certificate, or other forms of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object, and a hash of the file content. Manifests are intended to expose potential attacks against relying parties of the RPKI, such as a man-in-the middle withholding repository data or replaying stale repository data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-manifests-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-rpki-manifests-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-14131021.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 Jul 14 13:35:29 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 C3F8C28C320; Mon, 14 Jul 2008 13:35:29 -0700 (PDT) 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 77CA728C31C for ; Mon, 14 Jul 2008 13:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-MWLE-Ez1Aa for ; Mon, 14 Jul 2008 13:35:27 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 590983A6C23 for ; Mon, 14 Jul 2008 13:33:34 -0700 (PDT) Received: from gih-mpro.local (238.099.dsl.brs.iprimus.net.au [211.26.64.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id C1B61D5F33; Tue, 15 Jul 2008 06:33:59 +1000 (EST) Message-ID: <487BB837.3070000@apnic.net> Date: Tue, 15 Jul 2008 06:33:59 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Sandra Murphy References: In-Reply-To: Cc: Rob Austein , sidr@ietf.org Subject: Re: [Sidr] request for agenda items 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 Sandra Murphy wrote: > Draft agendas are due one week from today. > > If you would like to present a topic in the upcoming wg meeting, please > send the request to the list. Or directly to the wg chairs, if you wish. > > Please send the agenda request as soon as possible. Keep in mind that > the wg chairs must compose and upload the agendas by next Wed, July 16, > 17:00 PDT. > One of the authors of draft-ietf-sidr-rpki-manifests will present (for approx 10 minutes) on the changes to that draft in the -01 version. Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Jul 14 13:39:10 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 DCE5B3A6ABD; Mon, 14 Jul 2008 13:39:10 -0700 (PDT) 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 82ADF3A68DF for ; Mon, 14 Jul 2008 13:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asCdwgOg2H-D for ; Mon, 14 Jul 2008 13:39:08 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id A9E4B3A6BFC for ; Mon, 14 Jul 2008 13:39:07 -0700 (PDT) Received: from gih-mpro.local (238.099.dsl.brs.iprimus.net.au [211.26.64.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 9318DD5F34; Tue, 15 Jul 2008 06:39:33 +1000 (EST) Message-ID: <487BB985.60208@apnic.net> Date: Tue, 15 Jul 2008 06:39:33 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Sandra Murphy References: In-Reply-To: Cc: sidr@ietf.org Subject: Re: [Sidr] request for agenda items 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 Sandra Murphy wrote: > Draft agendas are due one week from today. > > If you would like to present a topic in the upcoming wg meeting, please > send the request to the list. Or directly to the wg chairs, if you wish. > > Please send the agenda request as soon as possible. Keep in mind that > the wg chairs must compose and upload the agendas by next Wed, July 16, > 17:00 PDT. The only change to the resource certificate profile draft (draft-ietf-sidr-res-certs-10.txt) is the addition of text about "single use" and "multiple use" EE certificates. It might make sense to have a 15 minute agenda item to expose this distinction and see if it raises any issues for the WG. If not, then the authors would like to poll the WG to see if we are done with this draft and do a WG Last Call. Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Jul 14 13:49: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 71AC03A6B38; Mon, 14 Jul 2008 13:49:26 -0700 (PDT) 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 6E1D33A6BDD for ; Mon, 14 Jul 2008 13:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2f3eoIUuExGB for ; Mon, 14 Jul 2008 13:49:24 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 6FE5E3A6B38 for ; Mon, 14 Jul 2008 13:49:24 -0700 (PDT) Received: from gih-mpro.local (238.099.dsl.brs.iprimus.net.au [211.26.64.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 4E14FD5F2D; Tue, 15 Jul 2008 06:49:50 +1000 (EST) Message-ID: <487BBBED.2020307@apnic.net> Date: Tue, 15 Jul 2008 06:49:49 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Steve Kent , dkong@bbn.com, sidr@ietf.org Subject: [Sidr] Question about draft-ietf-sidr-roa-format-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: , 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, In reading draft-ietf-sidr-roa-format-03.txt with the changes to the ROA format arising from the last WG meeting, I was wondering if there was a "canonical form" for a ROA, or not. e.g. If I have a ROA that includes 10.0.0.0/8, maxlength=32 and 10.0.0.0/24 maxlength=32 then obviously the second entry is redundant. Also there are more "compressed" formats and less "compressed" formats e.g. 10.0.0.0/8 maxlength=8 10.0.0.0/9 maxlength=9 could be "compressed" to 10.0.0.0/8 maxlength=9 My question is: is it of any value to define a "canonical" format for a ROA? Is there an obvious answer to this question that I am missing? Would you like to lead a WG discussion of this question at the SIDR WG meeting, as an agenda item? regards, Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Jul 14 13:53: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 99DFC3A6C14; Mon, 14 Jul 2008 13:53:59 -0700 (PDT) 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 8542E3A6B38 for ; Mon, 14 Jul 2008 13:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7lrWN3T1T1c for ; Mon, 14 Jul 2008 13:53:57 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 5F4973A6A0F for ; Mon, 14 Jul 2008 13:53:55 -0700 (PDT) Received: from gih-mpro.local (238.099.dsl.brs.iprimus.net.au [211.26.64.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 4B3D2D5F35; Tue, 15 Jul 2008 06:54:21 +1000 (EST) Message-ID: <487BBCFC.50305@apnic.net> Date: Tue, 15 Jul 2008 06:54:20 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Sandra Murphy References: In-Reply-To: Cc: sidr@ietf.org Subject: Re: [Sidr] request for agenda items 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 Sandra Murphy wrote: > Draft agendas are due one week from today. > > If you would like to present a topic in the upcoming wg meeting, please > send the request to the list. Or directly to the wg chairs, if you wish. > > Please send the agenda request as soon as possible. Keep in mind that > the wg chairs must compose and upload the agendas by next Wed, July 16, > 17:00 PDT. One of the authors would like to present on the changes to draft-huston-sidr-repos-struct for approx 15 minutes, and call upon the other WG chair (Sandy) with a request for WG adoption of this draft. thanks, Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Jul 14 13:55: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 8DC333A6C14; Mon, 14 Jul 2008 13:55:11 -0700 (PDT) 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 196C23A6C55 for ; Mon, 14 Jul 2008 13:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 eIvTLCofbsh8 for ; Mon, 14 Jul 2008 13:55:10 -0700 (PDT) Received: from nutshell.tislabs.com (nutshell.tislabs.com [192.94.214.100]) by core3.amsl.com (Postfix) with ESMTP id A0CBB3A6C14 for ; Mon, 14 Jul 2008 13:55:08 -0700 (PDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id m6EKqGBa003719; Mon, 14 Jul 2008 16:52:16 -0400 (EDT) Received: from nodnsquery(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAACaWqh; Mon, 14 Jul 08 16:52:16 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 9E3763F469; Mon, 14 Jul 2008 16:54:42 -0400 (EDT) To: gih@apnic.net, sandy@sparta.com In-Reply-To: <487BB837.3070000@apnic.net> Message-Id: <20080714205442.9E3763F469@pecan.tislabs.com> Date: Mon, 14 Jul 2008 16:54:42 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) Cc: sidr@ietf.org Subject: Re: [Sidr] request for agenda items 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org >One of the authors of draft-ietf-sidr-rpki-manifests will present (for approx 10 >minutes) on the changes to that draft in the -01 version. This is the only request for an agenda item that we've had so far. Is there no one else who has a topic to discuss? --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Jul 14 15:30: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 814D63A6A35; Mon, 14 Jul 2008 15:30:20 -0700 (PDT) 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 B51C23A6943 for ; Mon, 14 Jul 2008 15:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jcqdo+i9wN9N for ; Mon, 14 Jul 2008 15:30:19 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 92DEC28C480 for ; Mon, 14 Jul 2008 15:30:18 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 26E6C28440 for ; Mon, 14 Jul 2008 22:30:44 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 8F7F322807 for ; Mon, 14 Jul 2008 18:30:43 -0400 (EDT) Date: Mon, 14 Jul 2008 18:30:43 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <487BBBED.2020307@apnic.net> References: <487BBBED.2020307@apnic.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080714223043.8F7F322807@thrintun.hactrn.net> Subject: Re: [Sidr] Question about draft-ietf-sidr-roa-format-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At Tue, 15 Jul 2008 06:49:49 +1000, Geoff Huston wrote: > > In reading draft-ietf-sidr-roa-format-03.txt with the changes to the > ROA format arising from the last WG meeting, I was wondering if > there was a "canonical form" for a ROA, or not. > > e.g. If I have a ROA that includes > > 10.0.0.0/8, maxlength=32 > and > 10.0.0.0/24 maxlength=32 > > then obviously the second entry is redundant. Yes. > Also there are more "compressed" formats and less "compressed" formats > > e.g. > > 10.0.0.0/8 maxlength=8 > 10.0.0.0/9 maxlength=9 > > could be "compressed" to > > 10.0.0.0/8 maxlength=9 No. 10.0.0.0/8-9 isn't 10.0.0.0/8,10.0.0.0/9. 10.0.0.0/8-9 is 10.0.0.0/8,10.0.0.0/9,10.128.0.0/9. This stuff is trickier than it looks. ABNF for those who haven't seen the above text notation before: ::=
"/" [ "-" ] ; Where defaults to the same ; value as . ::= *( "," ) > My question is: is it of any value to define a "canonical" format > for a ROA? Perhaps, but the definition would likely be hard to get right and harder to implement. The only real definition I can think of would involve computing the union of the set of prefixes expressed by each prefix-maxLength pair, then attempting to compute some kind of minimal expression of that set. This also begs the question of whether it's an error to specify a redundant set of prefix-maxLength pairs. I suspect that in the vast majority of cases there will not be any useful canonicalization to be performed, ie, the output of the canonicalization function will end up being the same as the input. In the absence of a useful definition of canonicalization, my own implementation just includes the prefix-maxLength pairs as specified by the user. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Jul 15 07:11: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 302FC3A6ACF; Tue, 15 Jul 2008 07:11:08 -0700 (PDT) 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 7555F3A6ACF for ; Tue, 15 Jul 2008 07:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 gPNS6USsFX17 for ; Tue, 15 Jul 2008 07:11:03 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id 9BA9C3A69F1 for ; Tue, 15 Jul 2008 07:11:03 -0700 (PDT) Received: from dhcp89-089-227.bbn.com ([128.89.89.227]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1KIlFY-0008Me-68; Tue, 15 Jul 2008 10:11:29 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <487BBBED.2020307@apnic.net> References: <487BBBED.2020307@apnic.net> Date: Tue, 15 Jul 2008 10:12:15 -0400 To: Geoff Huston From: Stephen Kent Cc: dkong@bbn.com, Steve Kent , sidr@ietf.org Subject: Re: [Sidr] Question about draft-ietf-sidr-roa-format-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 6:49 AM +1000 7/15/08, Geoff Huston wrote: >Hi, > >In reading draft-ietf-sidr-roa-format-03.txt with the changes to the >ROA format arising from the last WG meeting, I was wondering if >there was a "canonical form" for a ROA, or not. > >e.g. If I have a ROA that includes > >10.0.0.0/8, maxlength=32 >and >10.0.0.0/24 maxlength=32 > >then obviously the second entry is redundant. > >Also there are more "compressed" formats and less "compressed" formats > >e.g. > >10.0.0.0/8 maxlength=8 >10.0.0.0/9 maxlength=9 > > >could be "compressed" to > >10.0.0.0/8 maxlength=9 > >My question is: is it of any value to define a "canonical" format for a ROA? >Is there an obvious answer to this question that I am missing? >Would you like to lead a WG discussion of this question at the SIDR >WG meeting, as an agenda item? > >regards, > > Geoff A canonical format is required for any signed object. ASN.1 will yield a canonical rep for the ipAddressBlocks SEQUENCE, but that is a different from the higher level canonical rep you're asking about. There the advantage to having such a rep is to better enable comparisons between the values in the ROAs and the associated EE certs. There is also the matter of being able to match BGP UPDATE prefixes against these values. Prior to adding the max prefix length value, we had a canonical representation algorithm, based on the one defined for RFC 3779 address extensions. The only issue is how that changes based on the inclusion of the maxlength parameter. I think we can define a new canonical representation by making an arbitrary decision about how to represent a given value when the use of the explicit maxlength value might introduce ambiguity. I'll leave the details for Matt to work out when he returns from vacation ;-). Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Jul 15 07:57: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 1F2983A6A53; Tue, 15 Jul 2008 07:57:27 -0700 (PDT) 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 2570E3A6A07 for ; Tue, 15 Jul 2008 07:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 i-45bbohbQVE for ; Tue, 15 Jul 2008 07:57:20 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id AFECB3A6A91 for ; Tue, 15 Jul 2008 07:57:20 -0700 (PDT) Received: from dhcp89-089-227.bbn.com ([128.89.89.227]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1KIlyN-0000RI-6F; Tue, 15 Jul 2008 10:57:48 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20080714223043.8F7F322807@thrintun.hactrn.net> References: <487BBBED.2020307@apnic.net> <20080714223043.8F7F322807@thrintun.hactrn.net> Date: Tue, 15 Jul 2008 10:58:34 -0400 To: Rob Austein From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [Sidr] Question about draft-ietf-sidr-roa-format-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Rob, Geoff's question was about representing data in ROAs. The ABNF you cite is for RPSL, right? This has become a complicated discussion because the max length parameter is taken from RPSL, but a ROA does not directly represent RPSL. Moreover, as I noted in my message to Geoff, one thing we do with a ROA is to check that the EE cert used to verify the signature on a ROA authorizes the assertion made by the ROA. So, we have to begin by comparing the ROA address prefixes against the RFC 3779 address ranges in the EE cert. That motivates the adoption of a canonical (at a high level) representation for these prefixes, augmented by the max length parameter. So, we have to deal with two external data sources simultaneously: 3779 extensions in the EE cert and the RPSL-inspired max length parameter. Also, after we have validated a ROA, we will use it to generate RPSL, so we have to keep that in mind as well :-). Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Jul 15 08:27: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 4536028C110; Tue, 15 Jul 2008 08:27:38 -0700 (PDT) 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 4CA593A6882 for ; Tue, 15 Jul 2008 08:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qiq1+r5js++a for ; Tue, 15 Jul 2008 08:27:36 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 59E043A6A91 for ; Tue, 15 Jul 2008 08:27:36 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 6F3D228445 for ; Tue, 15 Jul 2008 15:28:01 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 1D7D622807 for ; Tue, 15 Jul 2008 11:28:01 -0400 (EDT) Date: Tue, 15 Jul 2008 11:28:01 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <487BBBED.2020307@apnic.net> <20080714223043.8F7F322807@thrintun.hactrn.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080715152801.1D7D622807@thrintun.hactrn.net> Subject: Re: [Sidr] Question about draft-ietf-sidr-roa-format-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At Tue, 15 Jul 2008 10:58:34 -0400, Steve Kent wrote: > > Geoff's question was about representing data in ROAs. I know. > The ABNF you cite is for RPSL, right? No. It's a text format that a friend and I cooked up in order to have a way to write down ROA prefix lists as ASCII text, since some of us need such a format in our implementations and it seemed potentially useful to have one generally agreed upon text format rather than having each implementation invent a new one. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Jul 15 09:05: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 133FF3A693A; Tue, 15 Jul 2008 09:05:39 -0700 (PDT) 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 6FDF53A693A for ; Tue, 15 Jul 2008 09:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ffCL+Nd3iBt for ; Tue, 15 Jul 2008 09:05:37 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id A34663A6881 for ; Tue, 15 Jul 2008 09:05:37 -0700 (PDT) Received: from dhcp89-089-227.bbn.com ([128.89.89.227]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1KIn2Q-0000Cx-5t; Tue, 15 Jul 2008 12:06:02 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20080715152801.1D7D622807@thrintun.hactrn.net> References: <487BBBED.2020307@apnic.net> <20080714223043.8F7F322807@thrintun.hactrn.net> <20080715152801.1D7D622807@thrintun.hactrn.net> Date: Tue, 15 Jul 2008 11:53:07 -0400 To: Rob Austein From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [Sidr] Question about draft-ietf-sidr-roa-format-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 11:28 AM -0400 7/15/08, Rob Austein wrote: >At Tue, 15 Jul 2008 10:58:34 -0400, Steve Kent wrote: >> >> Geoff's question was about representing data in ROAs. > >I know. > >> The ABNF you cite is for RPSL, right? > >No. It's a text format that a friend and I cooked up in order to have >a way to write down ROA prefix lists as ASCII text, since some of us >need such a format in our implementations and it seemed potentially >useful to have one generally agreed upon text format rather than >having each implementation invent a new one. Oh, now I'm really confused. Geoff gave an example motivated by data from a ROA, and used a syntax for his example. I didn't see where Geoff indicated that the syntax he used in his example was the one you and a fried cooked up, vs. anything else. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Jul 15 09:15: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 C9E9628C201; Tue, 15 Jul 2008 09:15:20 -0700 (PDT) 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 8876D28C17D for ; Tue, 15 Jul 2008 09:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOwBcXWuhTyR for ; Tue, 15 Jul 2008 09:15:18 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 962CB3A6ADD for ; Tue, 15 Jul 2008 09:15:18 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id DE1BB28429; Tue, 15 Jul 2008 16:15:43 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 9D29A22807; Tue, 15 Jul 2008 12:15:43 -0400 (EDT) Date: Tue, 15 Jul 2008 12:15:43 -0400 From: Rob Austein To: Stephen Kent In-Reply-To: References: <487BBBED.2020307@apnic.net> <20080714223043.8F7F322807@thrintun.hactrn.net> <20080715152801.1D7D622807@thrintun.hactrn.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080715161543.9D29A22807@thrintun.hactrn.net> Cc: sidr@ietf.org Subject: Re: [Sidr] Question about draft-ietf-sidr-roa-format-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At Tue, 15 Jul 2008 11:53:07 -0400, Steve Kent wrote: > > Oh, now I'm really confused. Geoff gave an example motivated by data > from a ROA, and used a syntax for his example. I didn't see where > Geoff indicated that the syntax he used in his example was the one > you and a fried cooked up, vs. anything else. I know that the authors of the ROA specification have seen the text syntax I was using before, because it was after seeing that ABNF that one of your co-authors decided to make the maxLength field optional in the ROA ASN.1. But perhaps, rather than arguing about notation, it might be more useful to go back to my response to Geoff, now that you understand that I was talking about ROAs, not RPSL. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Jul 15 11: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 AAF973A68F4; Tue, 15 Jul 2008 11:37:36 -0700 (PDT) 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 5C8043A6882 for ; Tue, 15 Jul 2008 11:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9rfX+Pu63uE for ; Tue, 15 Jul 2008 11:37:34 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id 9C57C3A67CF for ; Tue, 15 Jul 2008 11:37:34 -0700 (PDT) Received: from dhcp89-089-227.bbn.com ([128.89.89.227]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1KIpPT-0002nE-5p; Tue, 15 Jul 2008 14:38:00 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20080715161543.9D29A22807@thrintun.hactrn.net> References: <487BBBED.2020307@apnic.net> <20080714223043.8F7F322807@thrintun.hactrn.net> <20080715152801.1D7D622807@thrintun.hactrn.net> <20080715161543.9D29A22807@thrintun.hactrn.net> Date: Tue, 15 Jul 2008 13:34:33 -0400 To: Rob Austein From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [Sidr] Question about draft-ietf-sidr-roa-format-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 12:15 PM -0400 7/15/08, Rob Austein wrote: >At Tue, 15 Jul 2008 11:53:07 -0400, Steve Kent wrote: >> >> Oh, now I'm really confused. Geoff gave an example motivated by data >> from a ROA, and used a syntax for his example. I didn't see where >> Geoff indicated that the syntax he used in his example was the one >> you and a fried cooked up, vs. anything else. > >I know that the authors of the ROA specification have seen the text >syntax I was using before, because it was after seeing that ABNF that >one of your co-authors decided to make the maxLength field optional in >the ROA ASN.1. I am one of the two active co-authors, and I didn't remember it :-). >But perhaps, rather than arguing about notation, Agreed. >it might be more >useful to go back to my response to Geoff, now that you understand >that I was talking about ROAs, not RPSL. My response was in the the part of my previous message that you elided in your response. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Jul 16 13:58: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 D64923A6986; Wed, 16 Jul 2008 13:58:08 -0700 (PDT) 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 8B79A3A6969 for ; Wed, 16 Jul 2008 13:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdCGhJKWeC-c for ; Wed, 16 Jul 2008 13:58:06 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 860213A6984 for ; Wed, 16 Jul 2008 13:58:06 -0700 (PDT) Received: from gih-mpro.local (238.099.dsl.brs.iprimus.net.au [211.26.64.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id DD03CD5F34; Thu, 17 Jul 2008 06:58:35 +1000 (EST) Message-ID: <487E60FA.8090203@apnic.net> Date: Thu, 17 Jul 2008 06:58:34 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Rob Austein References: <487BBBED.2020307@apnic.net> <20080714223043.8F7F322807@thrintun.hactrn.net> In-Reply-To: <20080714223043.8F7F322807@thrintun.hactrn.net> Cc: sidr@ietf.org Subject: Re: [Sidr] Question about draft-ietf-sidr-roa-format-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Rob Austein wrote: > At Tue, 15 Jul 2008 06:49:49 +1000, Geoff Huston wrote: >> In reading draft-ietf-sidr-roa-format-03.txt with the changes to the >> ROA format arising from the last WG meeting, I was wondering if >> there was a "canonical form" for a ROA, or not. [...] > > Perhaps, but the definition would likely be hard to get right and > harder to implement. The only real definition I can think of would > involve computing the union of the set of prefixes expressed by each > prefix-maxLength pair, then attempting to compute some kind of minimal > expression of that set. This also begs the question of whether it's > an error to specify a redundant set of prefix-maxLength pairs. Well the middle of that paragraph is an algorithm, to be sure, but is it the same as the specification of a "canonical form"? To put it in a slightly different way, what I wondering was is there a means of specifying this "minimal expression" you refer to? > > I suspect that in the vast majority of cases there will not be any > useful canonicalization to be performed, ie, the output of the > canonicalization function will end up being the same as the input. My intuition about use cases leads me to a different conclusion, but its all speculation at this stage, of course. My question was motivated by working through some interface issues in terms of tools to manage ROAs, and the concepts of comparison operators and equivalence came up. I was wondering how to compare the address part of ROAs for equivalence and from this I was lead to the question of canonical representations, since at some point you either have to fully expand (this could be potentially yicky - 10.0.0.0/8-24 would be a relatively large set I guess) or fully compress the ROA into some "canonical form" in order to undertake the comparison operation. regards, Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Jul 16 20:07:24 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 880C23A6962; Wed, 16 Jul 2008 20:07:24 -0700 (PDT) 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 4F59C3A6962 for ; Wed, 16 Jul 2008 20:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.085, 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 D7DwTmsIXT+4 for ; Wed, 16 Jul 2008 20:07:22 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id A406B3A690E for ; Wed, 16 Jul 2008 20:07:22 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6673B244181; Thu, 17 Jul 2008 03:07:53 +0000 (UTC) Date: Wed, 16 Jul 2008 23:07:53 -0400 From: Jeffrey Haas To: Geoff Huston Message-ID: <20080717030753.GD21614@slice> References: <487BBBED.2020307@apnic.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <487BBBED.2020307@apnic.net> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Cc: dkong@bbn.com, Steve Kent , sidr@ietf.org Subject: Re: [Sidr] Question about draft-ietf-sidr-roa-format-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Tue, Jul 15, 2008 at 06:49:49AM +1000, Geoff Huston wrote: > My question is: is it of any value to define a "canonical" format for a > ROA? I don't think it adds much in the way of value to enforce this within the ROA. The noise it adds is harmless. -- Jeff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Jul 16 21:03: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 81F373A6A4C; Wed, 16 Jul 2008 21:03:19 -0700 (PDT) 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 8A5413A6A4A for ; Wed, 16 Jul 2008 21:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+ff3Y9zIWmH for ; Wed, 16 Jul 2008 21:03:17 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 1EE0C3A6A44 for ; Wed, 16 Jul 2008 21:03:17 -0700 (PDT) Received: from [202.12.29.245] (dhcp245.apnic.net [202.12.29.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id DFEDBD5F34 for ; Thu, 17 Jul 2008 14:03:42 +1000 (EST) Message-ID: <487EC49E.8040206@apnic.net> Date: Thu, 17 Jul 2008 14:03:42 +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: <487BBBED.2020307@apnic.net> <20080717030753.GD21614@slice> In-Reply-To: <20080717030753.GD21614@slice> X-Enigmail-Version: 0.95.6 OpenPGP: id=C6B3AE7E; url=http://robert.loomans.org/0xC6B3AE7E.asc Subject: Re: [Sidr] Question about draft-ietf-sidr-roa-format-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: , Content-Type: multipart/mixed; boundary="===============1789832844==" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1789832844== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040708000103040601070306" This is a cryptographically signed message in MIME format. --------------ms040708000103040601070306 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Jeffrey Haas wrote: > On Tue, Jul 15, 2008 at 06:49:49AM +1000, Geoff Huston wrote: >> My question is: is it of any value to define a "canonical" format for a >> ROA? I believe that we should have a canonical form for the resources in a ROA, and that we mandate that form in the ROA. If you cannot define a canonical form, how do you define equivalence? (Yes, you can define equivalence algorithmically, but that algorithm is essentially a method for deriving a canonical form...) Are we saying we don't need a definition of equivalence? > I don't think it adds much in the way of value to enforce this within > the ROA. The noise it adds is harmless. Having a canonical form can reduce the number of interoperability problems and makes writing test cases easier. 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 --------------ms040708000103040601070306 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5jCC BW8wggRXoAMCAQICAiMDMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UE ChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5h Z2VyQGFwbmljLm5ldDAeFw0wNzEwMjUwNjMxMDBaFw0wODEwMjQwNjMxMDBaMEgxCzAJBgNV BAYTAkFQMREwDwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTAL BgNVBAUTBDg5NjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcSon3OuumUDjF QP4OmyB73NE86ZN+/IMs8CmJ2f4k9RCns8CJ3CL/PO+OIcCq/+H9QJwfYUeKFqenx4/l/DWs 02JKEd4Kwap6eYMUxfbLffW+prRdBJjFYo6N03bGOu6CSU5AOT8AlFXu5D2kWFLzD3YjYgkH 0PvpZNWiV3uBqhItdPpgBqeBXtFMRpgfkK8YwyHol5Ger6N9fB1OqzIk6t963uI3zAD2U2wR 7r2SJDQ8SXiUJy5Mx853CqS5/IROi0kELuxE7/rPEIGEAasiFX167dRQ6WLMZqvkljICkIU+ uyZcsqAE7VVX0rRKeOa+K3UoFkPqOeda4yp7dXt/AgMBAAGjggIaMIICFjAJBgNVHRMEAjAA MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklD IENsaWVudCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUKEo+2/IFBV8W2/KazvPHSH7jSJIwgbsG A1UdIwSBszCBsIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFV MQ4wDAYDVQQKEwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQD EyVBUE5JQyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkB FhNjYW1hbmFnZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0 MB4GA1UdEgQXMBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0 cHM6Ly93d3cuYXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0 dHBzOi8vd3d3LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZo dHRwczovL3d3dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOC AQEAhtnqJUiql+tfUKqvezpfcla+4EX3DSkz8E5Kfru7UiyEdZCwm3F6ou2rRz6LNDQUqQYq 32x4R8YHDgfUwq8nkQh9kfpOq5FDBJ7eKrKMSgcZrl4Q8AbkpFIBj9L4B0ymjyy2wWYA0tiC gPx/wQ72Eyj6DNdhCU/6Fsr6saTPKFn2OC7d9OwCey57/z08ih1/7A58mhk1AnrlWd4NUQgk f2Qk5n8RiNEpzzvm1cQbNOydfDfe1DRUYvcBkHkDNtB1bs1twDFTYH4z3wdU8evWqV6FUcKT H3fAz9RQC3zprZZK4AWxXqfsb1C3T4aStx+biDOhUO3OCbE1kbd0mi0hQjCCBW8wggRXoAMC AQICAiMDMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMx GzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmlj Lm5ldDAeFw0wNzEwMjUwNjMxMDBaFw0wODEwMjQwNjMxMDBaMEgxCzAJBgNVBAYTAkFQMREw DwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTALBgNVBAUTBDg5 NjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcSon3OuumUDjFQP4OmyB73NE8 6ZN+/IMs8CmJ2f4k9RCns8CJ3CL/PO+OIcCq/+H9QJwfYUeKFqenx4/l/DWs02JKEd4Kwap6 eYMUxfbLffW+prRdBJjFYo6N03bGOu6CSU5AOT8AlFXu5D2kWFLzD3YjYgkH0PvpZNWiV3uB qhItdPpgBqeBXtFMRpgfkK8YwyHol5Ger6N9fB1OqzIk6t963uI3zAD2U2wR7r2SJDQ8SXiU Jy5Mx853CqS5/IROi0kELuxE7/rPEIGEAasiFX167dRQ6WLMZqvkljICkIU+uyZcsqAE7VVX 0rRKeOa+K3UoFkPqOeda4yp7dXt/AgMBAAGjggIaMIICFjAJBgNVHRMEAjAAMBEGCWCGSAGG +EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklDIENsaWVudCBD ZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUKEo+2/IFBV8W2/KazvPHSH7jSJIwgbsGA1UdIwSBszCB sIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFVMQ4wDAYDVQQK EwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQDEyVBUE5JQyBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkBFhNjYW1hbmFn ZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0MB4GA1UdEgQX MBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0cHM6Ly93d3cu YXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0dHBzOi8vd3d3 LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwczovL3d3 dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAhtnqJUiq l+tfUKqvezpfcla+4EX3DSkz8E5Kfru7UiyEdZCwm3F6ou2rRz6LNDQUqQYq32x4R8YHDgfU wq8nkQh9kfpOq5FDBJ7eKrKMSgcZrl4Q8AbkpFIBj9L4B0ymjyy2wWYA0tiCgPx/wQ72Eyj6 DNdhCU/6Fsr6saTPKFn2OC7d9OwCey57/z08ih1/7A58mhk1AnrlWd4NUQgkf2Qk5n8RiNEp zzvm1cQbNOydfDfe1DRUYvcBkHkDNtB1bs1twDFTYH4z3wdU8evWqV6FUcKTH3fAz9RQC3zp rZZK4AWxXqfsb1C3T4aStx+biDOhUO3OCbE1kbd0mi0hQjGCA8YwggPCAgEBMIGVMIGOMQsw CQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNl czEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAG CSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmljLm5ldAICIwMwCQYFKw4DAhoFAKCCAgUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwNzE3MDQwMzQyWjAj BgkqhkiG9w0BCQQxFgQUCgcADYbLleE/VRNjzg1J4kR0vy0wUgYJKoZIhvcNAQkPMUUwQzAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgaYGCSsGAQQBgjcQBDGBmDCBlTCBjjELMAkGA1UEBhMCQVUxDjAMBgNV BAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNVBAMTJUFQTklD IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0BCQEWE2NhbWFu YWdlckBhcG5pYy5uZXQCAiMDMIGoBgsqhkiG9w0BCRACCzGBmKCBlTCBjjELMAkGA1UEBhMC QVUxDjAMBgNVBAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNV BAMTJUFQTklDIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0B CQEWE2NhbWFuYWdlckBhcG5pYy5uZXQCAiMDMA0GCSqGSIb3DQEBAQUABIIBAKCeBPR0Ye7W guVq46da370g97HVt+72TP+mOWFh53csxWuEoKJ2pj4jezEBQmXf4ncgdRMFRyL4ZBGKYBdB Ovb2QzCYf84iHsUCBaqKo+CKnKmWHago601vSOMrUQM2wvKais2j7kMfEPay5YngKv4nIit/ dydhbfVt0wftvGR6z6xPNkzInouI3758gthwnA0jT/UCpL6Nuit4giep8MLquiC7XYiE2xIU EYKhDKX3ioW4A0dNQeoFn00QAsaXbP47mDJGpqrkwtadRyI0CachqNTxTLOHiXwmlbMF5Hvo iUVEPpzfOVf6JKz5tVAZJI38TlwaoE7FHKHPKvie5fcAAAAAAAA= --------------ms040708000103040601070306-- --===============1789832844== 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 --===============1789832844==-- From sidr-bounces@ietf.org Thu Jul 17 00:13: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 3851228C165; Thu, 17 Jul 2008 00:13:05 -0700 (PDT) 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 AE05D28C162 for ; Thu, 17 Jul 2008 00:13:03 -0700 (PDT) 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 lv0T3gH3KOSP for ; Thu, 17 Jul 2008 00:13:03 -0700 (PDT) Received: from postman.ripe.net (postman.ripe.net [193.0.19.2]) by core3.amsl.com (Postfix) with ESMTP id D462828C141 for ; Thu, 17 Jul 2008 00:13:02 -0700 (PDT) Received: by postman.ripe.net (Postfix, from userid 4008) id CD29A23FBD; Thu, 17 Jul 2008 09:13:32 +0200 (CEST) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id 9EB1023FB8; Thu, 17 Jul 2008 09:13:32 +0200 (CEST) Received: from [127.0.0.1] (chimp.ripe.net [193.0.1.199]) by herring.ripe.net (Postfix) with ESMTP id 9218C2F583; Thu, 17 Jul 2008 09:13:32 +0200 (CEST) Message-ID: <487EF119.2030005@ripe.net> Date: Thu, 17 Jul 2008 09:13:29 +0200 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Robert Loomans References: <487BBBED.2020307@apnic.net> <20080717030753.GD21614@slice> <487EC49E.8040206@apnic.net> In-Reply-To: <487EC49E.8040206@apnic.net> X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000304 / -4.4 X-RIPE-Signature: 22dc9b6d6bb3f62cd9bc9a1aab813b52 Cc: sidr@ietf.org Subject: Re: [Sidr] Question about draft-ietf-sidr-roa-format-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: , 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 Loomans wrote: > Jeffrey Haas wrote: >> On Tue, Jul 15, 2008 at 06:49:49AM +1000, Geoff Huston wrote: >>> My question is: is it of any value to define a "canonical" format for >>> a ROA? > > I believe that we should have a canonical form for the resources in a > ROA, and that we mandate that form in the ROA. > > If you cannot define a canonical form, how do you define equivalence? > > (Yes, you can define equivalence algorithmically, but that algorithm is > essentially a method for deriving a canonical form...) > > Are we saying we don't need a definition of equivalence? Can you give an example of where this would be useful? Robert _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Jul 17 01:02: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 208F63A68EF; Thu, 17 Jul 2008 01:02:13 -0700 (PDT) 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 AF9A83A69EB for ; Thu, 17 Jul 2008 01:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpuZtR4VAWxQ for ; Thu, 17 Jul 2008 01:02:10 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 962DF3A68EF for ; Thu, 17 Jul 2008 01:02:08 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id E35902845C for ; Thu, 17 Jul 2008 08:02:34 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id A672622807 for ; Thu, 17 Jul 2008 04:02:34 -0400 (EDT) Date: Thu, 17 Jul 2008 04:02:34 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <487E60FA.8090203@apnic.net> References: <487BBBED.2020307@apnic.net> <20080714223043.8F7F322807@thrintun.hactrn.net> <487E60FA.8090203@apnic.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080717080234.A672622807@thrintun.hactrn.net> Subject: Re: [Sidr] Question about draft-ietf-sidr-roa-format-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At Thu, 17 Jul 2008 06:58:34 +1000, Geoff Huston wrote: > > > Perhaps, but the definition would likely be hard to get right and > > harder to implement. The only real definition I can think of would > > involve computing the union of the set of prefixes expressed by each > > prefix-maxLength pair, then attempting to compute some kind of minimal > > expression of that set. This also begs the question of whether it's > > an error to specify a redundant set of prefix-maxLength pairs. > > Well the middle of that paragraph is an algorithm, to be sure, but is it > the same as the specification of a "canonical form"? Almost certainly not, since the whole point of the maxLength parameter in the ASN.1 is to avoid having to specify the full expansion of the set of prefixes in the ROA. > To put it in a slightly different way, what I wondering was is there a > means of specifying this "minimal expression" you refer to? Aye, that is the question. I've tried to specify an algorithm for this twice already, and failed both times. I have a third approach in mind as I type this, dunno yet whether it'll work, and I haven't even gotten to the point of trying to optimize this. I'm not saying this can't be done, but it's significantly harder than figuring out whether a ROA covers a particular prefix or figuring out what RFC 3779 resources a certificate must contain to cover a ROA. > My question was motivated by working through some interface issues in > terms of tools to manage ROAs, and the concepts of comparison operators > and equivalence came up. I was wondering how to compare the address part > of ROAs for equivalence and from this I was lead to the question of > canonical representations, since at some point you either have to fully > expand (this could be potentially yicky - 10.0.0.0/8-24 would be a relatively > large set I guess) or fully compress the ROA into some "canonical form" in > order to undertake the comparison operation. As Jeff and the other Robs have been discussing, there's some question of whether one actually needs an equivalence operation; more precisely, whether one needs an efficient equivalence operation. Absent somebody being very clever, either the ROA producer or the ROA consumer will have to perform the icky expansion, whether to generate the canonical form or to do the comparision. If equivalence tests are an operation that we expect consumers to need to do frequently, it makes sense for the producer to do the work of generating a canonical form. But it's far from clear to me that ROA equivalence per se is an important operation for the consumer. If most consumer don't care, perhaps we should leave the work to the few consumers that do care. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Jul 17 05:51: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 4A0743A6902; Thu, 17 Jul 2008 05:51:16 -0700 (PDT) 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 EFF1D3A6902 for ; Thu, 17 Jul 2008 05:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.077, 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 LgIIVKnSgnra for ; Thu, 17 Jul 2008 05:51:15 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 344F93A68A1 for ; Thu, 17 Jul 2008 05:51:15 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B3E9C2441F5; Thu, 17 Jul 2008 12:51:46 +0000 (UTC) Date: Thu, 17 Jul 2008 08:51:46 -0400 From: Jeffrey Haas To: Rob Austein Message-ID: <20080717125146.GD26021@slice> References: <487BBBED.2020307@apnic.net> <20080714223043.8F7F322807@thrintun.hactrn.net> <487E60FA.8090203@apnic.net> <20080717080234.A672622807@thrintun.hactrn.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080717080234.A672622807@thrintun.hactrn.net> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Cc: sidr@ietf.org Subject: Re: [Sidr] Question about draft-ietf-sidr-roa-format-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Thu, Jul 17, 2008 at 04:02:34AM -0400, Rob Austein wrote: > > To put it in a slightly different way, what I wondering was is there a > > means of specifying this "minimal expression" you refer to? > > Aye, that is the question. I've tried to specify an algorithm for > this twice already, and failed both times. Unless I have missed something about the subtleties of an ROA, the prefixes contained therein are of the form: [maxlen ] | n >= prefix-length. Given any two prefixes, A and B of the above form where A has the shorter prefix length: If prefix A covers prefix B and maxlength A >= maxlength B Then A completely covers B and B is redundant. If prefix A covers prefix B and maxlength B > maxlength A Then B has a portion of it's address space that is not covered by A. Given the above, you can pair-wise compare each prefix and eliminate redundant prefixes. (Insert common optimizations of pre-sorting by prefix length, etc.) I'd honestly just expect implementors to toss the prefixes into a prefix trie and not worry about the redundant nodes. > As Jeff and the other Robs have been discussing, there's some question > of whether one actually needs an equivalence operation; more > precisely, whether one needs an efficient equivalence operation. The main concern would be someone's ROA having so much noise in it that it's consider a resource exhaustion attack. Given that people would be using these things to say "hey, I want traffic to reach my network!" it seems less than likely that someone would intentionally try to do that, especially since the response is to blacklist the ROA. -- Jeff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Jul 17 10:28: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 704483A6912; Thu, 17 Jul 2008 10:28:31 -0700 (PDT) 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 AA1833A6806 for ; Wed, 16 Jul 2008 13:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] 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 acXS-uMG0AZc for ; Wed, 16 Jul 2008 13:03:23 -0700 (PDT) Received: from limes.NIC.DTAG.DE (limes.NIC.DTAG.DE [194.25.1.113]) by core3.amsl.com (Postfix) with ESMTP id 715063A6853 for ; Wed, 16 Jul 2008 13:03:22 -0700 (PDT) Received: from kronos.NIC.DTAG.DE (kronos.NIC.DTAG.DE [194.25.1.92]) by limes.NIC.DTAG.DE (8.8.5/8.8.3) with ESMTP id WAA20492; Wed, 16 Jul 2008 22:03:50 +0200 (MET DST) Received: from x37.NIC.DTAG.DE (x37.NIC.DTAG.DE [194.25.1.186]) by kronos.NIC.DTAG.DE (8.8.5/8.7.1) with ESMTP id WAA26431; Wed, 16 Jul 2008 22:03:48 +0200 (MET DST) To: Sandra Murphy In-Reply-To: Your message of "Wed, 09 Jul 2008 15:14:25 EDT." Date: Wed, 16 Jul 2008 22:03:48 +0200 Message-ID: <9163.1216238628@x37.NIC.DTAG.DE> From: Ruediger Volk X-Mailman-Approved-At: Thu, 17 Jul 2008 10:28:31 -0700 Cc: sidr@ietf.org Subject: Re: [sidr] [Sidr] request for agenda items 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > Draft agendas are due one week from today. > > If you would like to present a topic in the upcoming wg meeting, please > send the request to the list. Or directly to the wg chairs, if you wish. > > Please send the agenda request as soon as possible. Keep in mind that the > wg chairs must compose and upload the agendas by next Wed, July 16, 17:00 > PDT. I'd like to ramble a bit about "Using RPKI secured data for existing routing policy tools" Regards, Ruediger _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Jul 23 14:47: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 35D543A6819; Wed, 23 Jul 2008 14:47:56 -0700 (PDT) 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 8AEB33A6819 for ; Wed, 23 Jul 2008 14:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 NYT4zAw6YpLQ for ; Wed, 23 Jul 2008 14:47:53 -0700 (PDT) Received: from nutshell.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by core3.amsl.com (Postfix) with ESMTP id 8FBC13A6809 for ; Wed, 23 Jul 2008 14:47:53 -0700 (PDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id m6NLjJWa018302 for ; Wed, 23 Jul 2008 17:45:19 -0400 (EDT) Received: from nodnsquery(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAA8taOVJ; Wed, 23 Jul 08 17:45:19 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 78F4F3F476; Wed, 23 Jul 2008 17:47:40 -0400 (EDT) To: sidr@ietf.org Message-Id: <20080723214740.78F4F3F476@pecan.tislabs.com> Date: Wed, 23 Jul 2008 17:47:40 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) Cc: sandy@tislabs.com Subject: [sidr] new agenda uploaded X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org I have uploaded a new agenda, adding Ruediger's requested agenda slot. --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Jul 28 11:07: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 8D5F13A6A21; Mon, 28 Jul 2008 11:07:40 -0700 (PDT) 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 49F7F3A6A03 for ; Mon, 28 Jul 2008 11:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.917 X-Spam-Level: X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[AWL=0.200, 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 ZNWBCW2pNpnm for ; Mon, 28 Jul 2008 11:07:38 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 9B26928C299 for ; Mon, 28 Jul 2008 11:07:38 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id D4D9E26866F; Mon, 28 Jul 2008 12:07:48 -0600 (MDT) Received: from pork.meeting.ietf.org (130.129.23.44 [130.129.23.44]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Mon, 28 Jul 2008 12:07:48 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=130.129.23.44; client-port=49739; syn-fingerprint=65535:50:1:64:M1450,N,W3,N,N,T,S; data-bytes=0 Message-Id: From: Danny McPherson To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 28 Jul 2008 12:07:31 -0600 X-Mailer: Apple Mail (2.926) Subject: [sidr] draft-sidr-fetch-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 Terry et al., I just had a chance to read this.. As I stated at the microphone, I'm quite interested in understanding the motivations for an alternative mechanism at this point, as I'm concerned that given all the other work that needs to be done, this will increase attack surfaces without adding needed capabilities. Do you mind iterating the motivations for this work, they're not in the current version of the draft? I'm genuinely interested in your input here, as given that you're going to be the one that has to implement, there's likely some obvious gaps (beyond "to scale") you're aiming to fill, gaps which aren't entirely obvious for me yet. Thanks! -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Jul 28 11:29: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 D0F183A6861; Mon, 28 Jul 2008 11:29:30 -0700 (PDT) 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 C039B3A6861 for ; Mon, 28 Jul 2008 11:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.394 X-Spam-Level: X-Spam-Status: No, score=-1.394 tagged_above=-999 required=5 tests=[AWL=1.205, 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 HK3eAEmUR+7P for ; Mon, 28 Jul 2008 11:29:29 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by core3.amsl.com (Postfix) with ESMTP id 0D3103A67A5 for ; Mon, 28 Jul 2008 11:29:29 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 3CE846FF65; Mon, 28 Jul 2008 14:29:39 -0400 (EDT) Received: from ex.arin.net (ex.arin.net [192.136.136.237]) by smtp1.arin.net (Postfix) with ESMTP id CE67B6FF3F; Mon, 28 Jul 2008 14:29:04 -0400 (EDT) Received: from EDAMAME.arin.net ([192.136.136.195]) by ex.arin.net ([192.136.136.237]) with mapi; Mon, 28 Jul 2008 14:29:04 -0400 From: Andy Newton To: Danny McPherson , "sidr@ietf.org" Date: Mon, 28 Jul 2008 14:29:03 -0400 Thread-Topic: [sidr] draft-sidr-fetch-00.txt Thread-Index: Acjw3OGSQqqtpAlURcC51RnkVhnmeQAAu3z0 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] draft-sidr-fetch-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 On 7/28/08 2:07 PM, "Danny McPherson" wrote: > Do you mind iterating the motivations for this work, they're not > in the current version of the draft? I'm genuinely interested in > your input here, as given that you're going to be the one that has > to implement, there's likely some obvious gaps (beyond "to > scale") you're aiming to fill, gaps which aren't entirely obvious > for me yet. Not being Terry, but I'd like to expand on Terry's scalability point. The number of tools available to for scaling HTTP are far greater than that for rsync. The same is true about monitoring tools, which is important for large installations. Additionally, if there were ever a need to put any "intelligence" on the server side, the number of ways to do so with HTTP are far, far greater than the number of ways to do that with rsync. Of course, at the moment such a need does not exist. -andy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Jul 29 06:10: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 BF28028C266; Tue, 29 Jul 2008 06:10:39 -0700 (PDT) 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 AF1553A68EB for ; Tue, 29 Jul 2008 06:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFYKmCnaV4zk for ; Tue, 29 Jul 2008 06:10:36 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id B42B928C266 for ; Tue, 29 Jul 2008 06:10:35 -0700 (PDT) Received: from [130.129.23.58] (unknown [130.129.23.58]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 274E1D5F2D; Tue, 29 Jul 2008 23:10:45 +1000 (EST) Message-Id: <16F13FA6-ED32-41F0-958F-6D5E1BD68EEB@apnic.net> From: Terry Manderson To: Danny McPherson In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 29 Jul 2008 23:10:35 +1000 References: X-Mailer: Apple Mail (2.926) Cc: sidr@ietf.org Subject: Re: [sidr] draft-sidr-fetch-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 Hi Danny, There are several motivations for an additional / alternative mechanism for retrieval as I see it. We know that RSYNC is a MUST in the SIA of the issued RPKI certificate, and it then allows further multiple additional fetch URIs where order of those URIs is the preferred order of use according to the issuer. Putting on the hat of a relying party, if for some reason the highest order URI is not immediately available it would be preferable to have access to a heterogeneous method and location to retrieve the information. From the perspective of the issuer, I should (I think) do whatever it takes to ensure that this information is available whenever a relying party requires it. Having a second valid and known mechanism to do this helps enormously for the obvious reasons. As Andy mentioned there are a plethora of tools and techniques for building robust http(s) services, remembering that I'm not the only one who needs to do this. Every single entity that issues their own RPKI objects needs to place these objects in a repository, some will opt to use the repositories of their RIRs, other will not. Those others will need to create a robust repository structure and they may have their own preference for the server infrastructure in their organisation, this allows them to put focus on their preference, being either RSYNC or HTTP. The ubiquity of HTTP provides a strong platform for both server and client development. I'm not sure it would expose an attack surface by adding http. It may be that specifying just https may eliminate additional vectors. Do you have any in mind? A social aspect that I'm cognisant of is that there appeared to be reluctance by some parties to accept the rescerts draft because it had a non-ietf reference implementation which potentially could raise issues about interoperability between releases. This draft should nullify those as it does provide an IETF standard for retrieval - so with luck allowing the pivotal draft in question to gain adoption faster. I'm not forgetting Rob A's mic comments about looking deeper into the TCP behaviours and the overall efficiency of the entire retrieval of all the objects at a publication point. Similarly Andy N's comments about making HTTP 1.1 a MUST and also to look at connection creation in light of HTTPS. An attraction for me with the algorithm as stated is making the manifest the synchronisation point and unambiguously giving the retrieval decisions to the client, that is the client then has the explicit choice. Does that help or add to your understand of where I'm coming from with this work? Cheers Terry On 29/07/2008, at 4:07 AM, Danny McPherson wrote: > Terry et al., > I just had a chance to read this.. As I stated at the microphone, > I'm quite interested in understanding the motivations for an > alternative mechanism at this point, as I'm concerned that given > all the other work that needs to be done, this will increase attack > surfaces without adding needed capabilities. > > Do you mind iterating the motivations for this work, they're not > in the current version of the draft? I'm genuinely interested in > your input here, as given that you're going to be the one that has > to implement, there's likely some obvious gaps (beyond "to > scale") you're aiming to fill, gaps which aren't entirely obvious > for me yet. > > Thanks! > > -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Jul 31 10:00: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 0FF7328C24D; Thu, 31 Jul 2008 10:00:18 -0700 (PDT) X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A4BDF3A6CE8; Thu, 31 Jul 2008 10:00:06 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080731170007.A4BDF3A6CE8@core3.amsl.com> Date: Thu, 31 Jul 2008 10:00:06 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-res-certs-11.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-11.txt Pages : 31 Date : 2008-07-31 This document defines a standard profile for X.509 certificates for the purposes of supporting validation of assertions of "right-to-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-11.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-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-31095836.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--