From kseo@bbn.com Sat Oct 2 14:20:19 2010 Return-Path: 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 20F743A6DCE for ; Sat, 2 Oct 2010 14:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJsqYWeAwx9y for ; Sat, 2 Oct 2010 14:20:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id E0B5D3A6D08 for ; Sat, 2 Oct 2010 14:20:14 -0700 (PDT) Received: from [128.89.254.176] (port=49152 helo=[192.168.1.151]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P29Vx-0000Xb-OH; Sat, 02 Oct 2010 17:21:06 -0400 Mime-Version: 1.0 Message-Id: Date: Sat, 2 Oct 2010 17:21:04 -0400 To: sidr@ietf.org From: Karen Seo Content-Type: multipart/alternative; boundary="============_-926068031==_ma============" Cc: skent@bbn.com Subject: [sidr] Certificate policy -- new draft (version 12 or 13) 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: , X-List-Received-Date: Sat, 02 Oct 2010 21:20:19 -0000 --============_-926068031==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Folks, Please note that draft 12 is the same as draft 13 except for the end-of-line characters. So you should compare 13 to 11 (or an earlier version depending on when you last reviewed the document.) NOTE: Version 13 has end-of-line characters (linefeeds) that Rfcdiff will handle. However, as uploaded, versions 9, 10, 11, and 12 have carriage returns as their end-of-line characters and don't work with Rfcdiff. I believe that if you substitute LF for all the CRs, Rfcdiff will work with them. I'm told that downloading with IE automatically does the end-of-line changes. And Word let me select the end-of-line terminator when I used it to open and then save the files. In addition to some clarifications, addition of references, and correction of typos and minor errors, the following revisions were made between draft 11 and 12/13 to address feedback from Tim Polk and Sean Turner. Karen 1. Introduction From: Note: This document is based on the template specified in the Internet Engineering Task Force (IETF) standards document RFC 3647. A number of sections contained in the template were omitted from this policy because they did not apply to this PKI. However, we have retained the section numbering scheme employed in the RFC to facilitate comparison with the outline in Section 6 of the RFC. To: Note: This document is based on the template specified in the Internet Engineering Task Force (IETF) standards document RFC 3647 [RFC3647]. In the interest of keeping the document as short as reasonable, a number of sections contained in the template are omitted from this policy because they did not apply to this PKI. However, we have retained the section numbering scheme employed in the RFC to facilitate comparison with the outline in Section 6 of the RFC. Each of these omitted sections should be read as "No stipulation" in CP/CPS parlance. 1.2. Overview -- replaced 2nd paragraph with 2 paragraphs From: This PKI parallels the existing INR distribution hierarchy. These resources are distributed by the Internet Assigned Numbers Authority (IANA) to the Regional Internet Registries. In some regions, National Internet Registries (NIRs) form a tier of the hierarchy below the RIRs for internet number resource (INR) distribution. ISPs and network subscribers form additional tiers below registries. To: The structure of the RPKI is modeled on the existing organizational structure that is already responsible for IP address and AS number resource allocation. In this allocation hierarchy, IANA allocates resources to five Regional Internet Registries (RIRs), each of which manages address and AS number allocation within a defined geopolitical region. The RIRs in turn allocate resources to Internet Service Providers, to subscribers with so-called provider- independent ("portable") allocations, and in some regions, to National Internet Registries (NIRs). (The term LIR is used in some regions to refer to what other regions define as an ISP. Throughout the rest of this document we will use the term ISP to simplify references to these entities.) As noted in the RPKI architecture document [ARCH], although IANA and/or the five RIRs are obvious candidates to be default TAs for the RPKI, each RP ultimately chooses the set of trust anchors it will use for certificate validation. For example, an RP (e.g., an LIR/ISP) could create a trust anchor to which all address space and/or all AS numbers are assigned, and for which the RP knows the corresponding private key. The RP could then issue certificates under this trust anchor to whatever entities in the PKI it wishes, with the result that the certification paths terminating at this locally-installed trust anchor will satisfy the RFC 3779 validation requirements. 1.4.1. Certification authorities -- 2nd paragraph From: Organizations that do not distribute INRs, but hold such resources also act as CAs when they create EE certificates. To: Organizations that do not distribute INRs, but hold such resources also act as CAs when they create EE certificates. Subscribers with PI space are the principle examples of this class of CAs. 1.6.4. CP approval procedures From: IESG MUST approve a replacement BCP, following the procedures of the IETF Standards Process as defined in RFC 2026. To: The IESG MUST approve a replacement BCP that either updates or obsoletes this BCP, following the procedures of the IETF Standards Process as defined in RFC 2026 [RFC2026]. 1.7 Definitions and acronyms Added: LIR - In some regions, the term Local Internet Registry (LIR) is used to refer to what is called an ISP in other regions. Provider-independent (PI) address space - PI address space is allocated directly by an Internet Registry to a subscriber. This space cannot be further allocated by the subscriber to other entities. The subscriber must contract with an ISP to obtain routing of the address block within the Internet. PI space enables the subscriber to change service providers without renumbering its networks and to use multiple ISPs in a multi-homed configuration. 2.2 Publication of certification information Added: Each CA MUST publish its CPS. 3.1.2 Need for names to be meaningful From: The Subject name in each certificate MUST be unique relative to all Subject names certified by the same Issuer, but the name does not need to be meaningful. There is no requirement, and no guarantee, that subject names are globally unique in this PKI. The certificates issued under this PKI are used for authorization in support of applications that make use of attestations of Internet resource holding, not for identification. The PKI binds a public key to sets of INRs. The name of the holder of the INR is not intended to be "meaningful". To: The Subject name in each certificate does not need to be meaningful. The certificates issued under this PKI are used for authorization in support of applications that make use of attestations of Internet resource holdings, not for identification. The PKI binds a public key to sets of INRs. The name of the holder of the INR is not intended to be "meaningful". 3.1.5. Uniqueness of names From: Each CA certifies Subject names that MUST be unique among the certificates that it issues. Although it is desirable that these Subject names be unique throughout the PKI, to facilitate certificate path discovery, such uniqueness is neither mandated nor enforced through technical means. To: There is no guarantee that subject names are globally unique in this PKI. Each CA certifies Subject names that MUST be unique among the certificates that it issues. Although it is desirable that these Subject names be unique throughout the PKI, name uniqueness within the RPKI cannot be guaranteed. However, Subject names in certificates SHOULD be constructed in a way that minimizes the chances that two entities in the RPKI will be assigned the same name. 3.1.6. Recognition, authentication, and role of trademarks From: Because the Subject names are not intended to be meaningful, there is no provision to recognize or authenticate trademarks, service marks, etc. To: Since Subject names are not intended to be meaningful, there is no provision to recognize or authenticate trademarks, service marks, etc. When generating subject names, CAs should use a mechanism that is unlikely to result in Subject names that include trademarks, service marks, etc. CAs MUST NOT knowingly issue a certificate with a Subject name that a court of competent jurisdiction has determined infringes on the trademark of another individual or organization. 4.2. Certificate application processing From: CAs SHOULD make use of existing standards for certificate application processing. Relevant standards include RFC 4210, Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP), RFC 2797, Certificate Management Messages over CMS, and RSA Labs standards PKCS #7 and PKCS #10. Each CA MUST define the certificate request/response standards that it employs, via its CPS. To: CAs SHOULD make use of existing standards for certificate application processing. Section 6 of the resource certificate profile [RFCyyyy] defines the standard certificate request formats that MUST be supported Each CA MUST define the certificate request/response standards that it employs, via its CPS. 4.5.2. Relying party public key and certificate usage -- last paragraph From: If a relying party determines that use of the certificate is appropriate, the relying party must utilize appropriate software and/or hardware to perform digital signature verification as a condition of relying on the certificate. Moreover the relying party MUST validate the certificate in a manner consistent with the algorithms specified in RFC 5280 and RFC 3779. To: If a relying party determines that use of the certificate is appropriate, the relying party must utilize appropriate software and/or hardware to perform digital signature verification as a condition of relying on the certificate. Moreover the relying party MUST validate the certificate in a manner consistent with the RPKI certificate profile [RFCyyyy], which specifies the extended validation algorithm for RPKI certificates. 4.6 Certificate renewal Added: This section describes the procedures for certificate renewal. Certificate renewal is the issuance of a new certificate to replace an old one prior to its expiration. Only the validity dates and the serial number are changed. The public key and all other information remain the same. 4.6.1. Circumstance for certificate renewal -- first paragraph. Added: An overlap period of at least 24 hours is RECOMMENDED. Sections 4.X.4, 4.X.5, 4.X.6, 4.X.7 Made consistent with each other as follows: 4.6.4, 4.7.4, 4.8.4 Notification of new certificate issuance to subscriber No additional stipulations beyond those of section 4.3.2. 4.6.5, 4.7.5, 4.8.5 Conduct constituting acceptance of a [renewal, re-keyed, modified] certificate No additional stipulations beyond those of section 4.4.1. 4.6.6, 4.7.6, 4.8.6 Publication of the [renewal, rekeyed, modified] certificate by the CA No additional stipulations beyond those of section 4.4.2. 4.6.7, 4.7.7, 4.8.7 Notification of certificate issuance by the CA to other entities No additional stipulations beyond those of section 4.3.3. 4.7. Certificate re-key Added: This section describes the procedures for certificate re-key. Certificate re-key is the issuance of a new certificate to replace an old one because the key needs to be replaced. Unlike with certificate renewal, the public key is changed. 4.7.1. Circumstance for certificate re-key -- 3rd paragraph From: Note that if a certificate is revoked to replace the RFC 3779 extensions, the replacement certificate MUST incorporate the same public key rather than a new key. To: Note that if a certificate is revoked to replace the RFC 3779 extensions, the replacement certificate MUST incorporate the same public key rather than a new key. This applies to when one is adding INRs (revocation not required) and to when one is removing INRs (revocation required (see Section 4.8.1). 4.9.3. Procedure for revocation request From: A subscriber MAY submit a request to the certificate issuer for a revocation. A certificate issuer MUST notify the subscriber when revoking a certificate, however this notification requirement MAY be satisfied by publication of a CRL by the issuer. If means other than CRL publication are employed, the CPS for a CA MUST indicate by what means the CA will inform a subscriber of certificate revocation, To: A subscriber MAY submit a request to the certificate issuer for a revocation. This request MUST identify the certificate to be revoked and MUST be authenticated. The procedures for making the request MUST be described in the CPS for each CA. The RPKI provisioning document [PROV] describes a protocol that MAY be used to make revocation requests. A certificate issuer MUST notify the subscriber when revoking a certificate. The notification requirement is satisfied by CRL publication. The CPS for a CA MUST indicate the means by which the CA will inform a subscriber of certificate revocation. 4.10. Certificate status services From: This PKI does not make provision for use of OCSP or SCVP, because it is anticipated that the primary relying parties (ISPs) will acquire and validate certificates for all participating resource holders on a daily basis. These protocols are not designed for such large- scale, bulk certificate status checking. Instead, retrieval of all changed or new certificates and CRLs on a daily basis is the anticipated mode of certificate status verification. To: This PKI does not make provision for use of OCSP or SCVP, because it is anticipated that the primary RPs (ISPs) will acquire and validate certificates for all participating resource holders. These protocols are not designed for such large-scale, bulk certificate status checking. RPs MUST check for new CRLs at least daily. It is RECOMMENDED that RPs perform this check several times per day, but no more than 8-12 times per day (to avoid excessive repository accesses). 5.1. Physical controls Added: Possible topics include: . Site location and construction, such as the construction requirements for high-security zones and the use of locked rooms, cages, safes, and cabinets . Physical access, i.e., mechanisms to control access from one area of the facility to another or access into high-security zones, such as locating CA operations in a secure computer room monitored by guards or security alarms and requiring movement from zone to zone to be accomplished using a token, biometric readers, and/or access control lists . Power and air conditioning . Water exposures . Fire prevention and protection . Media storage, for example, requiring the storage of backup media in a separate location that is physically secure and protected from fire and water damage . Waste disposal . Off-site backup 5.2. Procedural controls Added: Topics covered SHOULD include: . Requirements for recognizing trusted roles . Responsibilities for each role (Examples of trusted roles include system administrators, security officers, and system auditors.) . For each task identified, the number of individuals required to perform the task (n out of m rule) for each role. . Identification and authentication requirements for each role . When role separation is employed and how it is effected (if employed) 5.4.1. Types of events recorded -- 2nd sentence From: Audit records SHOULD include the date, time, responsible user or process, and summary content data relating to the event. To: Audit records MUST include the date, time, responsible user or process, and summary content data relating to the event. Also added the following auditable events: . Key generation . Software and/or configuration updates to the CA . Clock adjustments 5.8. CA or RA termination From: In the RPKI, each subscriber acts as a CA authoritative for the specified INRs that were distributed to that entity. Procedures associated with the termination of a CA MUST be described in the CPS for that CA. To: In the RPKI, each subscriber acts as a CA authoritative for the specified INRs that were distributed to that entity. Procedures associated with the termination of a CA MUST be described in the CPS for that CA. These procedures MUST include a provision to notify each entity that issued a certificate to the organization that is operating the CA that is terminating. Since the RA function MUST be provided by the same entity operating as the CA (see Section 1.4.2), there are no separate stipulations for RAs. 6.1.1. Key pair generation Added sentence in the middle of the paragraph: (The CA has to check the quality of the keys only if it generates them (see 6.1.6)). 6.1.6. Public key parameters generation and quality checking From: The public key parameters used in the RPKI are specified in RFC ZZZZ [RFCzzzz]. Each subscriber is responsible for performing checks on the quality of its key pair. CAs are not responsible for performing such checks for subscribers. To: The public key parameters used in the RPKI are specified in RFC ZZZZ [RFCzzzz]. Each subscriber is responsible for performing checks on the quality of its key pair. A CA is not responsible for performing such checks for subscribers except in the case where the CA generates the key pair on behalf of the subscriber. 6.3.2. Certificate operational periods and key pair usage periods From: The INRs held by RIRs and the NIRs periodically change because these registries receive new distributions. Therefore it is appropriate for their certificates to hae lifetimes that match the periodicity of these changes To: The INRs held by a CA may periodically change because it receives new distributions. Therefore it is appropriate for its certificate to hae a lifetime that matches the periodicity of these changes. 9.12.2. Notification mechanism and period From: The IESG MUST provide at least a six month advance notice of a change to this CP. To: Successive versions of the CP will be published with the statement "This CP takes effect on MM/DD/YYYY." MM/DD/YYYY MUST be a minimum of 6 months from the date of publication. 10. Security Considerations Added: Since name uniqueness within the RPKI cannot be guaranteed, there is a risk that two or more CAs in the RPKI will issue certificates and CRLs under the same Issuer name. Path validation implementations that conform to the resource certification path validation algorithm [see RFCyyyy] verify that the same key was used to sign both the target (the resource certificate) and the corresponding CRL. So a name collision will not change the result. Use of the basic X.509 path validation algorithm, which assumes name uniqueness, could result in a revoked certificate being accepted as valid or a valid certificate being rejected as revoked. Relying parties must ensure that the software they use to validate certificates issued under this policy verifies that the same key was used to sign both the certificate and the corresponding CRL, as specified in [RFCyyyy]. 13.1. Normative References Added: [RFC2026] Bradner, S., "The Internet Standards Process - Revision 3," BCP 9, RFC 2026, October 1996. [RFC3779] Lynn, C., Kent, S., Seo, K., "X.509 Extensions for IP Addresses and AS Identifiers," RFC 3779, June 2004. 13.2. Informative References Added: [PROV] Huston, G., Loomans, R., Ellacott, B., Austein, R., "A Protocol for Provisioning Resource Certificates," work in progress. [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., Wu, S., "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework," RFC 3647, November 2003. --============_-926068031==_ma============ Content-Type: text/html; charset="us-ascii" Certificate policy -- new draft (version 12 or 13)
Folks,

Please note that draft 12 is the same as draft 13 except for the end-of-line characters. So you should compare 13 to 11 (or an earlier version depending on when you last reviewed the document.)

NOTE: Version 13 has end-of-line characters (linefeeds) that Rfcdiff will handle. However, as uploaded, versions 9, 10, 11, and 12 have carriage returns as their end-of-line characters and don't work with Rfcdiff. I believe that if you substitute LF for all the CRs, Rfcdiff will work with them. I'm told that downloading with IE automatically does the end-of-line changes. And Word let me select the end-of-line terminator when I used it to open and then save the files.

In addition to some clarifications, addition of references, and correction of typos and minor errors, the following revisions were made between draft 11 and 12/13 to address feedback from Tim Polk and Sean Turner.

Karen

1. Introduction

From: Note: This document is based on the template specified in the
   Internet Engineering Task Force (IETF) standards document RFC 3647.
   A number of sections contained in the template were omitted from
   this policy because they did not apply to this PKI. However, we have
   retained the section numbering scheme employed in the RFC to
   facilitate comparison with the outline in Section 6 of the RFC.

To:   Note: This document is based on the template specified in the
   Internet Engineering Task Force (IETF) standards document RFC 3647
   [RFC3647].  In the interest of keeping the document as short as
   reasonable, a number of sections contained in the template are
   omitted from this policy because they did not apply to this PKI.
   However, we have retained the section numbering scheme employed in
   the RFC to facilitate comparison with the outline in Section 6 of
   the RFC. Each of these omitted sections should be read as "No
   stipulation" in CP/CPS parlance.


1.2. Overview -- replaced 2nd paragraph with 2 paragraphs

From: This PKI parallels the existing INR distribution hierarchy. These
   resources are distributed by the Internet Assigned Numbers Authority
   (IANA) to the Regional Internet Registries. In some regions,
   National Internet Registries (NIRs) form a tier of the hierarchy
   below the RIRs for internet number resource (INR) distribution. ISPs
   and network subscribers form additional tiers below registries.

To:   The structure of the RPKI is modeled on the existing organizational
   structure that is already responsible for IP address and AS number
   resource allocation. In this allocation hierarchy, IANA allocates
   resources to five Regional Internet Registries (RIRs), each of which
   manages address and AS number allocation within a defined
   geopolitical region. The RIRs in turn allocate resources to Internet
   Service Providers, to subscribers with so-called provider-
   independent ("portable") allocations, and in some regions, to
   National Internet Registries (NIRs). (The term LIR is used in some
   regions to refer to what other regions define as an ISP. Throughout
   the rest of this document we will use the term ISP to simplify
   references to these entities.)

   As noted in the RPKI architecture document [ARCH], although IANA
   and/or the five RIRs are obvious candidates to be default TAs for
   the RPKI, each RP ultimately chooses the set of trust anchors it
   will use for certificate validation. For example, an RP (e.g., an
   LIR/ISP) could create a trust anchor to which all address space
   and/or all AS numbers are assigned, and for which the RP knows the
   corresponding private key. The RP could then issue certificates
   under this trust anchor to whatever entities in the PKI it wishes,
   with the result that the certification paths terminating at this
   locally-installed trust anchor will satisfy the RFC 3779 validation
   requirements.

1.4.1. Certification authorities -- 2nd paragraph
From: Organizations that do not distribute INRs, but hold such resources
   also act as CAs when they create EE certificates.
To:   Organizations that do not distribute INRs, but hold such resources
   also act as CAs when they create EE certificates. Subscribers with
   PI space are the principle examples of this class of CAs.


1.6.4. CP approval procedures

From: IESG MUST approve a replacement BCP, following the procedures of the
   IETF Standards Process as defined in RFC 2026.

To:   The IESG MUST approve a replacement BCP that either updates or
   obsoletes this BCP, following the procedures of the IETF Standards
   Process as defined in RFC 2026 [RFC2026].


1.7 Definitions and acronyms

Added:
       LIR -  In some regions, the term Local Internet Registry (LIR) is
    used to refer to what is called an ISP in other regions.

       Provider-independent (PI) address space - PI address space is
    allocated directly by an Internet Registry to a subscriber. This space
    cannot be further allocated by the subscriber to other entities. The
    subscriber must contract with an ISP to obtain routing of the address
    block within the Internet. PI space enables the subscriber to change
    service providers without renumbering its networks and to use multiple
    ISPs in a multi-homed configuration.


2.2 Publication of certification information

Added:
    Each CA MUST publish its CPS.


3.1.2 Need for names to be meaningful

From: The Subject name in each certificate MUST be unique relative to all
   Subject names certified by the same Issuer, but the name does not
   need to be meaningful. There is no requirement, and no guarantee,
   that subject names are globally unique in this PKI. The certificates
   issued under this PKI are used for authorization in support of
   applications that make use of attestations of Internet resource
   holding, not for identification. The PKI binds a public key to sets
   of INRs. The name of the holder of the INR is not intended to be
   "meaningful".
To:   The Subject name in each certificate does not need to be meaningful.
   The certificates issued under this PKI are used for authorization in
   support of applications that make use of attestations of Internet
   resource holdings, not for identification. The PKI binds a public
   key to sets of INRs. The name of the holder of the INR is not
   intended to be "meaningful".


3.1.5. Uniqueness of names
From: Each CA certifies Subject names that MUST be unique among the
   certificates that it issues. Although it is desirable that these
   Subject names be unique throughout the PKI, to facilitate
   certificate path discovery, such uniqueness is neither mandated nor
   enforced through technical means.

To:   There is no guarantee that subject names are globally unique in this
   PKI. Each CA certifies Subject names that MUST be unique among the
   certificates that it issues. Although it is desirable that these
   Subject names be unique throughout the PKI, name uniqueness within
   the RPKI cannot be guaranteed.

   However, Subject names in certificates SHOULD be constructed in a
   way that minimizes the chances that two entities in the RPKI will be
   assigned the same name.

3.1.6. Recognition, authentication, and role of trademarks

From: Because the Subject names are not intended to be meaningful, there
   is no provision to recognize or authenticate trademarks, service
   marks, etc.
To:   Since Subject names are not intended to be meaningful, there is no
   provision to recognize or authenticate trademarks, service marks,
   etc. When generating subject names, CAs should use a mechanism that
   is unlikely to result in Subject names that include trademarks,
   service marks, etc. CAs MUST NOT knowingly issue a certificate with
   a Subject name that a court of competent jurisdiction has determined
   infringes on the trademark of another individual or organization.

4.2. Certificate application processing

From: CAs SHOULD make use of existing standards for certificate
   application processing.  Relevant standards include RFC 4210,
   Internet X.509 Public Key Infrastructure Certificate Management
   Protocol (CMP), RFC 2797, Certificate Management Messages over CMS,
   and RSA Labs standards PKCS #7 and PKCS #10. Each CA MUST define the
   certificate request/response standards that it employs, via its CPS.

To:   CAs SHOULD make use of existing standards for certificate
   application processing. Section 6 of the resource certificate
   profile [RFCyyyy] defines the standard certificate request formats
   that MUST be supported

   Each CA MUST define the certificate request/response standards that
   it employs, via its CPS.


4.5.2. Relying party public key and certificate usage -- last paragraph

From: If a relying party determines that use of the certificate is
   appropriate, the relying party must utilize appropriate software
   and/or hardware to perform digital signature verification as a
   condition of relying on the certificate. Moreover the relying party
   MUST validate the certificate in a manner consistent with the
   algorithms specified in RFC 5280 and RFC 3779.

To:   If a relying party determines that use of the certificate is
   appropriate, the relying party must utilize appropriate software
   and/or hardware to perform digital signature verification as a
   condition of relying on the certificate. Moreover the relying party
   MUST validate the certificate in a manner consistent with the RPKI
   certificate profile [RFCyyyy], which specifies the extended
   validation algorithm for RPKI certificates.

4.6 Certificate renewal

Added: This section describes the procedures for certificate renewal. Certificate renewal is the issuance of a new certificate to replace an old one prior to its expiration. Only the validity dates and the serial number are changed. The public key and all other information remain the same.


4.6.1. Circumstance for certificate renewal -- first paragraph.

Added: An overlap period of at least 24 hours is RECOMMENDED.


Sections 4.X.4, 4.X.5, 4.X.6, 4.X.7

Made consistent with each other as follows:

4.6.4, 4.7.4, 4.8.4 Notification of new certificate issuance to subscriber
        No additional stipulations beyond those of section 4.3.2.

4.6.5, 4.7.5, 4.8.5 Conduct constituting acceptance of a [renewal, re-keyed, modified] certificate
        No additional stipulations beyond those of section 4.4.1.

4.6.6, 4.7.6, 4.8.6 Publication of the [renewal, rekeyed, modified] certificate by the CA
        No additional stipulations beyond those of section 4.4.2.

4.6.7, 4.7.7, 4.8.7 Notification of certificate issuance by the CA to other entities
        No additional stipulations beyond those of section 4.3.3.


4.7. Certificate re-key

Added: This section describes the procedures for certificate re-key. Certificate re-key is the issuance of a new certificate to replace an old one because the key needs to be replaced. Unlike with certificate renewal, the public key is changed.


4.7.1. Circumstance for certificate re-key -- 3rd paragraph

From: Note that if a certificate is revoked to replace the RFC 3779
   extensions, the replacement certificate MUST incorporate the same
   public key rather than a new key.
To:    Note that if a certificate is revoked to replace the RFC 3779
   extensions, the replacement certificate MUST incorporate the same
   public key rather than a new key.  This applies to when one is
   adding INRs (revocation not required) and to when one is removing
   INRs (revocation required (see Section 4.8.1).


4.9.3. Procedure for revocation request
From: A subscriber MAY submit a request to the certificate issuer for a
   revocation. A certificate issuer MUST notify the subscriber when
   revoking a certificate, however this notification requirement MAY be
   satisfied by publication of a CRL by the issuer. If means other than
   CRL publication are employed, the CPS for a CA MUST indicate by what
   means the CA will inform a subscriber of certificate revocation,
To:   A subscriber MAY submit a request to the certificate issuer for a
   revocation. This request MUST identify the certificate to be revoked
   and MUST be authenticated. The procedures for making the request
   MUST be described in the CPS for each CA. The RPKI provisioning
   document [PROV] describes a protocol that MAY be used to make
   revocation requests.

   A certificate issuer MUST notify the subscriber when revoking a
   certificate. The notification requirement is satisfied by CRL
   publication. The CPS for a CA MUST indicate the means by which the
   CA will inform a subscriber of certificate revocation.

4.10. Certificate status services
From: This PKI does not make provision for use of OCSP or SCVP, because it
   is anticipated that the primary relying parties (ISPs) will acquire
   and validate certificates for all participating resource holders on
   a daily basis. These protocols are not designed for such large-
   scale, bulk certificate status checking. Instead, retrieval of all
   changed or new certificates and CRLs on a daily basis is the
   anticipated mode of certificate status verification.

To:   This PKI does not make provision for use of OCSP or SCVP, because it
   is anticipated that the primary RPs (ISPs) will acquire and validate
   certificates for all participating resource holders. These protocols
   are not designed for such large-scale, bulk certificate status
   checking. RPs MUST check for new CRLs at least daily. It is
   RECOMMENDED that RPs perform this check several times per day, but
   no more than 8-12 times per day (to avoid excessive repository
   accesses).

5.1. Physical controls
Added:  Possible topics include:

     .  Site location and construction, such as the construction
        requirements for high-security zones and the use of locked
        rooms, cages, safes, and cabinets

     .  Physical access, i.e., mechanisms to control access from one
        area of the facility to another or access into high-security
        zones, such as locating CA operations in a secure computer room
        monitored by guards or security alarms and requiring movement
        from zone to zone to be accomplished using a token, biometric
        readers, and/or access control lists

     .  Power and air conditioning

     .  Water exposures

     .  Fire prevention and protection

     .  Media storage, for example, requiring the storage of backup
        media in a separate location that is physically secure and
        protected from fire and water damage

     .  Waste disposal

     .  Off-site backup


5.2. Procedural controls

Added:  Topics covered SHOULD include:

     .  Requirements for recognizing trusted roles

     .  Responsibilities for each role (Examples of trusted roles
        include system administrators, security officers, and system
        auditors.)

     .  For each task identified, the number of individuals required
        to perform the task (n out of m rule) for each role.

     .  Identification and authentication requirements for each role

     .  When role separation is employed and how it is effected (if
        employed)

5.4.1. Types of events recorded -- 2nd sentence

From:  Audit records SHOULD include the date, time, responsible user
   or process, and summary content data relating to the event. 

To:    Audit records MUST include the date, time, responsible user
   or process, and summary content data relating to the event. 

Also added the following auditable events:

  . Key generation

  . Software and/or configuration updates to the CA
  . Clock adjustments

5.8. CA or RA termination

From: In the RPKI, each subscriber acts as a CA authoritative for the
   specified INRs that were distributed to that entity. Procedures
   associated with the termination of a CA MUST be described in the CPS
   for that CA.
To:  In the RPKI, each subscriber acts as a CA authoritative for the
   specified INRs that were distributed to that entity. Procedures
   associated with the termination of a CA MUST be described in the CPS
   for that CA. These procedures MUST include a provision to notify
   each entity that issued a certificate to the organization that is
   operating the CA that is terminating.

   Since the RA function MUST be provided by the same entity operating
   as the CA (see Section 1.4.2), there are no separate stipulations
   for RAs.
6.1.1. Key pair generation

Added sentence in the middle of the paragraph:
   (The CA has to check the quality of the keys only if it generates
   them (see 6.1.6)).


6.1.6. Public key parameters generation and quality checking
From: The public key parameters used in the RPKI are specified in RFC ZZZZ
   [RFCzzzz]. Each subscriber is responsible for performing checks on
   the quality of its key pair. CAs are not responsible for performing
   such checks for subscribers.
To:   The public key parameters used in the RPKI are specified in RFC ZZZZ
   [RFCzzzz]. Each subscriber is responsible for performing checks on
   the quality of its key pair. A CA is not responsible for performing
   such checks for subscribers except in the case where the CA
   generates the key pair on behalf of the subscriber.

6.3.2. Certificate operational periods and key pair usage periods

From: The INRs held by RIRs and the NIRs periodically change because these
   registries receive new distributions. Therefore it is appropriate for
   their certificates to hae lifetimes that match the periodicity of these
   changes

To:   The INRs held by a CA may periodically change because it receives
   new distributions. Therefore it is appropriate for its certificate to
   hae a lifetime that matches the periodicity of these changes.


9.12.2. Notification mechanism and period

From: The IESG MUST provide at least a six month advance notice of a
   change to this CP.

To:   Successive versions of the CP will be published with the statement
   "This CP takes effect on MM/DD/YYYY." MM/DD/YYYY MUST be a minimum
   of 6 months from the date of publication.


10. Security Considerations

Added: Since name uniqueness within the RPKI cannot be guaranteed, there is
   a risk that two or more CAs in the RPKI will issue certificates and
   CRLs under the same Issuer name. Path validation implementations
   that conform to the resource certification path validation algorithm
   [see RFCyyyy] verify that the same key was used to sign both the
   target (the resource certificate) and the corresponding CRL. So a
   name collision will not change the result. Use of the basic X.509
   path validation algorithm, which assumes name uniqueness, could
   result in a revoked certificate being accepted as valid or a valid
   certificate being rejected as revoked. Relying parties must ensure
   that the software they use to validate certificates issued under
   this policy verifies that the same key was used to sign both the
   certificate and the corresponding CRL, as specified in [RFCyyyy].


13.1. Normative References

Added:

[RFC2026]   Bradner, S., "The Internet Standards Process - Revision 3,"
       BCP 9, RFC 2026, October 1996.

[RFC3779]   Lynn, C., Kent, S., Seo, K., "X.509 Extensions for IP
       Addresses and AS Identifiers," RFC 3779, June 2004.

13.2. Informative References
Added:

[PROV] Huston, G., Loomans, R., Ellacott, B., Austein, R., "A Protocol
       for Provisioning Resource Certificates," work in progress.

[RFC3647]   Chokhani, S., Ford, W., Sabett, R., Merrill, C., Wu, S.,
       "Internet X.509 Public Key Infrastructure Certificate Policy and
       Certification Practices Framework," RFC 3647, November 2003.


--============_-926068031==_ma============-- From randy@psg.com Sat Oct 2 18:17:52 2010 Return-Path: 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 2F13C3A6E0E for ; Sat, 2 Oct 2010 18:17:51 -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 EtcrjmW+6Hs4 for ; Sat, 2 Oct 2010 18:17:49 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 8F0163A6E05 for ; Sat, 2 Oct 2010 18:17:48 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P2DDp-0003Wh-Sk; Sun, 03 Oct 2010 01:18:38 +0000 Date: Sun, 03 Oct 2010 10:18:36 +0900 Message-ID: From: Randy Bush To: Karen Seo In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Certificate policy -- new draft (version 12 or 13) 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: , X-List-Received-Date: Sun, 03 Oct 2010 01:17:52 -0000 > To: The structure of the RPKI is modeled on the existing organizational > structure that is already responsible for IP address and AS number > resource allocation. In this allocation hierarchy, IANA allocates > resources to five Regional Internet Registries (RIRs), each of > which the iana has, and will continue to have, direct allocations to others than the rirs > To: The IESG MUST approve a replacement BCP that either updates or > obsoletes this BCP, following the procedures of the IETF Standards > Process as defined in RFC 2026 [RFC2026]. the ietf must approve, by whatever means it currently uses as an approval process. do not forget 1992, and we seem to have bread massively more process wonks. > Provider-independent (PI) address space - PI address space is > allocated directly by an Internet Registry to a subscriber. This space > cannot be further allocated by the subscriber to other entities. i do not believe that last condition is firm, especially for legacy space. as a well-known example, 135.whatever was split when bell split. > The subscriber must contract with an ISP to obtain routing of the > address block within the Internet. the holder of pi space may very well be an isp > 2.2 Publication of certification information > > Added: > Each CA MUST publish its CPS. and up above, you say a ca is someone who makes an ee to sign a roa. most of them just ain't gonna publish a cps. and when an rir or large isp acts as a proxy privatekey/cert holder for a customer and generates a roa for them (the current rir model), who specifically is the ca that will publish their policy? > To: The Subject name in each certificate does not need to be meaningful. > The certificates issued under this PKI are used for authorization in > support of applications that make use of attestations of Internet > resource holdings, not for identification. The PKI binds a public > key to sets of INRs. The name of the holder of the INR is not > intended to be "meaningful". i am confused on the status of this. once upon a time it was must not be meainingful. then there was a move to make it meaningful for rirs but no one else. and now? can uu issue child certs with customer subnect names? should they? > However, Subject names in certificates SHOULD be constructed in a > way that minimizes the chances that two entities in the RPKI will be > assigned the same name. and how they heck will that be done? and why? > To: Since Subject names are not intended to be meaningful, there is no > provision to recognize or authenticate trademarks, service marks, > etc. When generating subject names, CAs should use a mechanism that > is unlikely to result in Subject names that include trademarks, > service marks, etc. CAs MUST NOT knowingly issue a certificate with > a Subject name that a court of competent jurisdiction has determined > infringes on the trademark of another individual or organization. great! and my sn generator should check the 200+ trademark databases of the world to be sure blorzlpktz is not trademarked? like hell. how about just the stuff from the beginning, do try not to generate meaningful names, period. taking a position on enforcing trademarks is something we learned to stay many kms away from dns registries. > Added: This section describes the procedures for certificate re-key. > Certificate re-key is the issuance of a new certificate to replace an > old one because the key needs to be replaced. Unlike with certificate > renewal, the public key is changed. s/with// > To: This PKI does not make provision for use of OCSP or SCVP, because it > is anticipated that the primary RPs (ISPs) will acquire and validate > certificates for all participating resource holders. These protocols > are not designed for such large-scale, bulk certificate status > checking. RPs MUST check for new CRLs at least daily. It is > RECOMMENDED that RPs perform this check several times per day, but > no more than 8-12 times per day (to avoid excessive repository > accesses). i am not sure i am comfortable with the timing here. first, does this cover where a local relying cache pulls and validates from a 'parent' trusted cache (note these are not publication points)? secondly, this places a lower bound on repairing a hijack or mistake. while, admittedly, the 12 times a day might not be an even distribution, it is sure to be interpreted that way. but i am not sure i see a fix. > 5.1. Physical controls come on. this is a bit of a pita for widget corp who has a cert for their space and wants to issue a roa. and i am not sure a ca with security or privacy concerns is gonna want to say anything. > 5.2. Procedural controls > Added: Topics covered SHOULD include: same issues as 5.1 for folk with security or privacy concerns. > 5.4.1. Types of events recorded -- 2nd sentence > . Clock adjustments got a logging ntpd? > To: In the RPKI, each subscriber acts as a CA authoritative for the > specified INRs that were distributed to that entity. which answers my question above. if i am a holder with a parent (isp or ror) acting as my key/cert proxy, then i am still a ca. i do not disagree with this. but note that puts all the cp obligations on jillions of end holders. randy From turners@ieca.com Sun Oct 3 07:06:00 2010 Return-Path: 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 AB9EA3A6C96 for ; Sun, 3 Oct 2010 07:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.334 X-Spam-Level: X-Spam-Status: No, score=-102.334 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jniPfw40hLTT for ; Sun, 3 Oct 2010 07:05:58 -0700 (PDT) Received: from smtp115.biz.mail.re2.yahoo.com (smtp115.biz.mail.re2.yahoo.com [66.196.116.35]) by core3.amsl.com (Postfix) with SMTP id C57213A6BF6 for ; Sun, 3 Oct 2010 07:05:58 -0700 (PDT) Received: (qmail 49912 invoked from network); 3 Oct 2010 14:06:49 -0000 Received: from thunderfish.local (turners@96.231.120.254 with plain) by smtp115.biz.mail.re2.yahoo.com with SMTP; 03 Oct 2010 07:06:48 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 99htbvwVM1nbQflI9T0R23CvUIK6jI0j.S1GTAAOipGSHfX XR83g8WJVtTa65xhlgz9Bn_ZLOR1L8Ck4tuX5gOWsA3MepXregX0J26oMajh VdEQTujPoAAuBjt_HDSLbZtRpZporbiQ5JOAn3.3msGruEzp8OKMrsMjUTLN 1aori70YqvdMtRm2lpiFtGJBVKkY7NB8NHXNNl9imrKUJqoDSslCP2_FBIS4 crYntlLeRvKd7pP4ViIHqdel42.OOPUq0bRUqpwq5xknFSBdKkMcMAtpbjx8 XVCJAbWUuUuRJkEhCR2lp6eZ.qyQ1eD2PMKOjl2HT_A_H5XryZwaL7f37P96 yk_w5vFjVw1SICZ9VDRDc8RBecb0knJKYTXdoPCT2HW.yrduxjnRse4XRcbo K2ZBHLjNI56PCNOK4ty_0CKY66EFUIY32WymeWmLZONAzVkagOdMGKzq2Ief wS6E6qg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CA88DF8.6060809@ieca.com> Date: Sun, 03 Oct 2010 10:06:48 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Randy Bush References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] Certificate policy -- new draft (version 12 or 13) 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: , X-List-Received-Date: Sun, 03 Oct 2010 14:06:00 -0000 Randy, Some thoughts below. spt Randy Bush wrote: >> 5.1. Physical controls > > come on. this is a bit of a pita for widget corp who has a cert for > their space and wants to issue a roa. and i am not sure a ca with > security or privacy concerns is gonna want to say anything. The text I suggested adding is really about giving hints on what might be included that section. Before it just said the CPS must say something about physical controls and didn't really give any hint about what kind of things might be there. Now it says "Possible topics include: ..." There are many CAs that have privacy and security concerns that post CPSs: http://www.verisign.com/repository/CPS/ http://www.identrust.com/certificates/index.html (there's 4 lists on the right) I'm sure comodo also publishes their CPSs too. >> 5.2. Procedural controls >> Added: Topics covered SHOULD include: > > same issues as 5.1 for folk with security or privacy concerns. See above. >> 5.4.1. Types of events recorded -- 2nd sentence >> . Clock adjustments > > got a logging ntpd? I don't think you have to go that far. If you look in the logs of say a mac (because I've got one), you can see that I tweaked the time this morning: Oct 3 09:49:54 computername SecurityAgent[2165]: system.preferences|2010-10-03 09:49:54 -0400 Oct 3 08:50:48 computername SecurityAgent[2165]: system.preferences|2010-10-03 09:50:48 -0400 That's pretty much what you need. spt From gih@apnic.net Sun Oct 3 11:19:31 2010 Return-Path: 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 8FF553A6DF8 for ; Sun, 3 Oct 2010 11:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.704 X-Spam-Level: X-Spam-Status: No, score=-94.704 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_NET=0.311, RCVD_IN_PBL=0.905, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqmbxPbJMBpP for ; Sun, 3 Oct 2010 11:19:28 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 90EE03A6DFB for ; Sun, 3 Oct 2010 11:19:26 -0700 (PDT) Received: from 54.75.240.10.in-addr.arpa (m150436d0.tmodns.net [208.54.4.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 64212D589F; Mon, 4 Oct 2010 04:20:10 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Mon, 4 Oct 2010 05:20:08 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <3BA4DE22-A362-46C6-8E9B-6D50A164D387@apnic.net> References: To: Karen Seo X-Mailer: Apple Mail (2.1081) Cc: skent@bbn.com, sidr@ietf.org Subject: Re: [sidr] Certificate policy -- new draft (version 12 or 13) 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: , X-List-Received-Date: Sun, 03 Oct 2010 18:19:31 -0000 Here are my comments on the CP. I do not believe that this document is = ready for the IESG at this stage. On 03/10/2010, at 8:21 AM, Karen Seo wrote: > 1.2. Overview -- replaced 2nd paragraph with 2 paragraphs >=20 > From: This PKI parallels the existing INR distribution hierarchy. = These > resources are distributed by the Internet Assigned Numbers Authority > (IANA) to the Regional Internet Registries. In some regions, > National Internet Registries (NIRs) form a tier of the hierarchy > below the RIRs for internet number resource (INR) distribution. ISPs > and network subscribers form additional tiers below registries. >=20 > To: The structure of the RPKI is modeled on the existing = organizational > structure that is already responsible for IP address and AS number > resource allocation. In this allocation hierarchy, IANA allocates > resources to five Regional Internet Registries (RIRs), each of which > manages address and AS number allocation within a defined > geopolitical region. The RIRs in turn allocate resources to Internet > Service Providers, to subscribers with so-called provider- > independent ("portable") allocations, and in some regions, to > National Internet Registries (NIRs). (The term LIR is used in some > regions to refer to what other regions define as an ISP. Throughout > the rest of this document we will use the term ISP to simplify > references to these entities.) >=20 > As noted in the RPKI architecture document [ARCH], although IANA > and/or the five RIRs are obvious candidates to be default TAs for > the RPKI, each RP ultimately chooses the set of trust anchors it > will use for certificate validation. For example, an RP (e.g., an > LIR/ISP) could create a trust anchor to which all address space > and/or all AS numbers are assigned, and for which the RP knows the > corresponding private key. The RP could then issue certificates > under this trust anchor to whatever entities in the PKI it wishes, > with the result that the certification paths terminating at this > locally-installed trust anchor will satisfy the RFC 3779 validation > requirements. >=20 there is much to be said for brevity and simplicity and the original = section 1.2 had both - the expanded version of this description is not a = good fit, and the introduction of the TA considerations into the CP does = not appear to sit easily in the context of this document, in my opinion = - I prefer the original words! > 1.4.1. Certification authorities -- 2nd paragraph > From: Organizations that do not distribute INRs, but hold such = resources > also act as CAs when they create EE certificates. > To: Organizations that do not distribute INRs, but hold such = resources > also act as CAs when they create EE certificates. Subscribers with > PI space are the principle examples of this class of CAs. >=20 I'd drop this change - the distinction between PI space and otherwise is = poorly made here. Again. I prefer the original words, >=20 >=20 > 1.7 Definitions and acronyms >=20 > Added: > LIR - In some regions, the term Local Internet Registry (LIR) = is > used to refer to what is called an ISP in other regions. >=20 > Provider-independent (PI) address space - PI address space is > allocated directly by an Internet Registry to a subscriber. This = space > cannot be further allocated by the subscriber to other entities. = The > subscriber must contract with an ISP to obtain routing of the = address > block within the Internet. PI space enables the subscriber to = change > service providers without renumbering its networks and to use = multiple > ISPs in a multi-homed configuration. >=20 >=20 I'd drop reference to PI space altogether - again it sits uncomfortably = in the context of the CP and the distinction is unclear here.=20 section 2.3=20 please change the formatting to make the list explicit (use bullets or = similar?) Also that is the purpose of "Also, please note" in para 3 - are the = other sentences in this section not worthy of noting? :-) >=20 > 3.1.2 Need for names to be meaningful >=20 > From: The Subject name in each certificate MUST be unique relative to = all > Subject names certified by the same Issuer, but the name does not > need to be meaningful. There is no requirement, and no guarantee, > that subject names are globally unique in this PKI. The certificates > issued under this PKI are used for authorization in support of > applications that make use of attestations of Internet resource > holding, not for identification. The PKI binds a public key to sets > of INRs. The name of the holder of the INR is not intended to be > "meaningful". > To: The Subject name in each certificate does not need to be = meaningful. > The certificates issued under this PKI are used for authorization in > support of applications that make use of attestations of Internet > resource holdings, not for identification. The PKI binds a public > key to sets of INRs. The name of the holder of the INR is not intended to be "meaningful". This is still unclear for me. The first sentence says that a subject "does not need to be meaningful". = yet sentence 4 states that the name is "not intended to be meaningful". = I'm no wiser whether meaningful subject names are permitted or not by = this text. >=20 > 3.1.6. Recognition, authentication, and role of trademarks >=20 > From: Because the Subject names are not intended to be meaningful, = there > is no provision to recognize or authenticate trademarks, service > marks, etc. > To: Since Subject names are not intended to be meaningful, there is = no > provision to recognize or authenticate trademarks, service marks, > etc. When generating subject names, CAs should use a mechanism that > is unlikely to result in Subject names that include trademarks, > service marks, etc. CAs MUST NOT knowingly issue a certificate with > a Subject name that a court of competent jurisdiction has determined > infringes on the trademark of another individual or organization. >=20 is that a "should" or a "SHOULD" in sentence 2? Again my preference is for the original text - the revised text is an = unrealistic imposition on the CA and is discordant with section 3.1.2 3.2.2: s/bedescribed/be described/ 3.2.3: Could you explain the purpose of 3.2.3? It does not appear to be = referenced elsewhere, nor is there any statement relating to the = currency of such individuals so identified. It seems out of place to me = and I would recommend dropping this section. >=20 >=20 > 4.6 Certificate renewal >=20 > Added: This section describes the procedures for certificate renewal. = Certificate renewal is the issuance of a new certificate to replace an = old one prior to its expiration. Only the validity dates and the serial = number are changed. The public key and all other information remain the = same. >=20 >=20 > 4.6.1. Circumstance for certificate renewal -- first paragraph. >=20 > Added: An overlap period of at least 24 hours is RECOMMENDED. if the name of the renewed certificate at the repository publication = point is the same as that of the previous certificate then this = "overlap" recommendation is confusing. If this section is limited to = referring to the valid times in the certificates, and that a renewed = certificate SHOULD be issued prior to 24 hours before the validto time, = then why not say so? 4.8.1. Circumstance for certificate modification Modification of a certificate occurs to implement changes to selected attribute values in a certificate. In the context of this PKI, the only changes that are accommodated by certificate modification are additions to the INR holdings described by the RFC 3779 extension. what if the subject wishes to change their SIA? 4.8.1 ..." When a certificate modification is approved, a new = certificate is issued. The new certificate MUST contain the same public key and the same expiration date as the original certificate, but with the incidental information corrected and/or the INRs expanded. Revocation of the previous certificate is not required." but if the INR shrinks, then revocation of the previous cert IS required = (section 4.9.1). I'm confused by what this says. 5.6 This certificate SHOULD have a validity period that is at least as long as that of any certificate being issued under that certificate. I believe that this is not correct, and that certificate lifetimes = reflect business relationships. It is admissible in the RPKI for a = subordinate CA to issue a cert with valid to times in excess of the CA = cert of the issuers. >=20 > 6.3.2. Certificate operational periods and key pair usage periods >=20 > From: The INRs held by RIRs and the NIRs periodically change because = these > registries receive new distributions. Therefore it is appropriate = for > their certificates to hae lifetimes that match the periodicity of = these > changes >=20 > To: The INRs held by a CA may periodically change because it = receives > new distributions. Therefore it is appropriate for its certificate = to > hae a lifetime that matches the periodicity of these changes. I would like to see the CP accommodate an operating practice where the = issued certificate has a lifetime that reflects the nature of the = business relationship between the INR distributor and the INR recipient. Geoff= From randy@psg.com Sun Oct 3 15:45:59 2010 Return-Path: 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 7DD313A6E9A for ; Sun, 3 Oct 2010 15:45:59 -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 k+Lt3lS-TScF for ; Sun, 3 Oct 2010 15:45:58 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 793383A6EB6 for ; Sun, 3 Oct 2010 15:45:58 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P2XKQ-00066e-1q; Sun, 03 Oct 2010 22:46:46 +0000 Date: Mon, 04 Oct 2010 07:46:44 +0900 Message-ID: From: Randy Bush To: Geoff Huston In-Reply-To: <3BA4DE22-A362-46C6-8E9B-6D50A164D387@apnic.net> References: <3BA4DE22-A362-46C6-8E9B-6D50A164D387@apnic.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: skent@bbn.com, sidr@ietf.org Subject: Re: [sidr] Certificate policy -- new draft (version 12 or 13) 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: , X-List-Received-Date: Sun, 03 Oct 2010 22:45:59 -0000 >> 1.4.1. Certification authorities -- 2nd paragraph >> From: Organizations that do not distribute INRs, but hold such resources >> also act as CAs when they create EE certificates. >> To: Organizations that do not distribute INRs, but hold such resources >> also act as CAs when they create EE certificates. Subscribers with >> PI space are the principle examples of this class of CAs. > > I'd drop this change - the distinction between PI space and otherwise > is poorly made here. Again. I prefer the original words, the pa/pa distinction is irrelevant. if i have pa space and want to announce it bgp, the parent still has to cut a cert for me and i still have to cut a roa. > I would like to see the CP accommodate an operating practice where the > issued certificate has a lifetime that reflects the nature of the > business relationship between the INR distributor and the INR > recipient. i suggest not getting into business relationships. surely we can deal with expiry without crossing that line. randy From gih@apnic.net Sun Oct 3 17:21:24 2010 Return-Path: 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 B31513A6DFD for ; Sun, 3 Oct 2010 17:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.704 X-Spam-Level: X-Spam-Status: No, score=-94.704 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_NET=0.311, RCVD_IN_PBL=0.905, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+Q1DnNPp5oZ for ; Sun, 3 Oct 2010 17:21:23 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 049313A6DDA for ; Sun, 3 Oct 2010 17:21:21 -0700 (PDT) Received: from 38.95.240.10.in-addr.arpa (m295636d0.tmodns.net [208.54.86.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 98AA0D58D3; Mon, 4 Oct 2010 10:22:02 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Mon, 4 Oct 2010 11:21:58 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3BA4DE22-A362-46C6-8E9B-6D50A164D387@apnic.net> To: Randy Bush X-Mailer: Apple Mail (2.1081) Cc: skent@bbn.com, sidr@ietf.org Subject: Re: [sidr] Certificate policy -- new draft (version 12 or 13) 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: , X-List-Received-Date: Mon, 04 Oct 2010 00:21:24 -0000 On 04/10/2010, at 9:46 AM, Randy Bush wrote: >>> 1.4.1. Certification authorities -- 2nd paragraph >>> From: Organizations that do not distribute INRs, but hold such = resources >>> also act as CAs when they create EE certificates. >>> To: Organizations that do not distribute INRs, but hold such = resources >>> also act as CAs when they create EE certificates. Subscribers with >>> PI space are the principle examples of this class of CAs. >>=20 >> I'd drop this change - the distinction between PI space and otherwise >> is poorly made here. Again. I prefer the original words, >=20 > the pa/pa distinction is irrelevant. if i have pa space and want to > announce it bgp, the parent still has to cut a cert for me and i still > have to cut a roa. agreed >=20 >> I would like to see the CP accommodate an operating practice where = the >> issued certificate has a lifetime that reflects the nature of the >> business relationship between the INR distributor and the INR >> recipient. >=20 > i suggest not getting into business relationships. surely we can deal > with expiry without crossing that line. While it's a personal preference of mine, at the same time its not a = strongly held personal conviction such that I'm prepared to advocate = that this needs to be chiseled into a CP document. I can pass on this. Geoff From randy@psg.com Sun Oct 3 17:26:05 2010 Return-Path: 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 0BFC53A6DFD for ; Sun, 3 Oct 2010 17:26:05 -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 rcquTkJ7eZEh for ; Sun, 3 Oct 2010 17:26:04 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id F14A73A6D77 for ; Sun, 3 Oct 2010 17:26:03 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P2YtK-0006dq-DM; Mon, 04 Oct 2010 00:26:54 +0000 Date: Mon, 04 Oct 2010 09:26:52 +0900 Message-ID: From: Randy Bush To: Geoff Huston In-Reply-To: References: <3BA4DE22-A362-46C6-8E9B-6D50A164D387@apnic.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: skent@bbn.com, sidr@ietf.org Subject: Re: [sidr] Certificate policy -- new draft (version 12 or 13) 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: , X-List-Received-Date: Mon, 04 Oct 2010 00:26:05 -0000 >>> I would like to see the CP accommodate an operating practice where the >>> issued certificate has a lifetime that reflects the nature of the >>> business relationship between the INR distributor and the INR >>> recipient. >> >> i suggest not getting into business relationships. surely we can deal >> with expiry without crossing that line. > > While it's a personal preference of mine, at the same time its not a > strongly held personal conviction such that I'm prepared to advocate > that this needs to be chiseled into a CP document. I can pass on this. if you did not get serious jet lag, perhaps you can whack me enough to understand how to go down this path a very short way without entering a deep swamp? randy From root@core3.amsl.com Mon Oct 4 09:30:20 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8A7453A6D8A; Mon, 4 Oct 2010 09:30:17 -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: <20101004163020.8A7453A6D8A@core3.amsl.com> Date: Mon, 4 Oct 2010 09:30:17 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-signed-object-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: , X-List-Received-Date: Mon, 04 Oct 2010 16:30:20 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Signed Object Template for the Resource Public Key Infrastructure Author(s) : M. Lepinski, et al. Filename : draft-ietf-sidr-signed-object-01.txt Pages : 13 Date : 2010-10-04 This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-signed-object-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-signed-object-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-04092219.I-D@ietf.org> --NextPart-- From achi@bbn.com Mon Oct 4 09:38:22 2010 Return-Path: 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 9E15B3A703D for ; Mon, 4 Oct 2010 09:38:21 -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 RBJLMemvYsIi for ; Mon, 4 Oct 2010 09:38:18 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 5292A3A703A for ; Mon, 4 Oct 2010 09:36:12 -0700 (PDT) Received: from dhcp89-089-053.bbn.com ([128.89.89.53]:2403 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P2o1B-00059D-Ir for sidr@ietf.org; Mon, 04 Oct 2010 12:36:01 -0400 Message-ID: <4CAA026D.9080604@bbn.com> Date: Mon, 04 Oct 2010 12:35:57 -0400 From: Andrew Chi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: sidr@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [sidr] New version: draft-ietf-sidr-signed-object-01 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: , X-List-Received-Date: Mon, 04 Oct 2010 16:38:22 -0000 A new version of the generic signed object I-D (draft-ietf-sidr-signed-object-01) has been uploaded. This revision fixes a reference, explicitly requires DER encoding for RPKI signed objects, and adds a corresponding validation step for DER. -Andrew From andrei@ripe.net Tue Oct 5 04:06:40 2010 Return-Path: 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 C8F083A6F22 for ; Tue, 5 Oct 2010 04:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYV0gVMbbTuK for ; Tue, 5 Oct 2010 04:06:39 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 7F8593A6E60 for ; Tue, 5 Oct 2010 04:06:39 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1P35Mm-0004h4-M7; Tue, 05 Oct 2010 13:07:34 +0200 Received: from andrei.vpn.ripe.net ([193.0.21.36] helo=Andrei-Robachevskys-MacBook-Air.local) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1P35Mk-0007tx-PE; Tue, 05 Oct 2010 13:07:27 +0200 Message-ID: <4CAB06EE.6060705@ripe.net> Date: Tue, 05 Oct 2010 13:07:26 +0200 From: Andrei Robachevsky User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Karen Seo References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Signature: 4330a47f43bd7e517cd9d6f2bba43afb4cfc1c566400e4b154382cf04a8837f5 X-RIPE-Spam-Level: -- X-RIPE-Signature: 4330a47f43bd7e517cd9d6f2bba43afb4cfc1c566400e4b154382cf04a8837f5 Cc: skent@bbn.com, sidr@ietf.org Subject: Re: [sidr] Certificate policy -- new draft (version 12 or 13) 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: , X-List-Received-Date: Tue, 05 Oct 2010 11:06:40 -0000 Thank you Karen for this work. I have a question regarding 1.6.3., a section that was always confusing to me. It says: > 1.6.3. Person determining CP suitability for the policy > > The IESG MUST judge consensus of the IETF community for changes to > this policy. But from my reading of RFC3647 the suitability that is meant here is "whether a CA should be allowed to operate within or interoperate with a PKI". If that is indeed the case, I am not sure if the IESG plays any role here. If we look at the current INR distribution system, such determination is done by a parent registry by establishing business relationships and allocating resources downstream. Usually, there are certain checks and conditions in place and checking for all the MUSTS in the CPS and approving it might be included. That would be, IMO, the most natural way of building a compliant RPKI. However, I don't think we need this in the CP, at least not at this stage of RPKI development. I'd recommend that we make 1.6.3. "not applicable" and relax the requirements for the CPS, by removing all "MUST"s that must be in there, including the requirement that each CA MUST publish a CPS. In general, I agree with most of the previous comments and think that the CP itself won't make routing more secure. I'd prefer to have this document as lightweight and simple as possible and hope it can be published as an RFC before the RIRs start issuing production certificates. Thanks, Andrei From kseo@bbn.com Tue Oct 5 21:38:42 2010 Return-Path: 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 6C3333A70C9 for ; Tue, 5 Oct 2010 21:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.502, 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 3G1Vmd6eNowP for ; Tue, 5 Oct 2010 21:38:41 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 633B23A6FC7 for ; Tue, 5 Oct 2010 21:38:41 -0700 (PDT) Received: from [128.89.254.144] (port=49410 helo=[192.168.1.151]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P3Lmw-000AnM-G8; Wed, 06 Oct 2010 00:39:34 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 6 Oct 2010 00:39:31 -0400 To: Randy Bush , Sean Turner , Geoff Huston , Andrei Robachevsky From: Karen Seo Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: skent@bbn.com, sidr@ietf.org Subject: Re: [sidr] Certificate policy -- new draft (version 12 or 13) 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: , X-List-Received-Date: Wed, 06 Oct 2010 04:38:42 -0000 Randy, Sean, Geoff, Andrei, Thank you for the prompt review. This is just a quick email to say, we've been following the exchanges and are working on a reply addressing your comments. Karen From david.cooper@nist.gov Wed Oct 6 12:59:47 2010 Return-Path: 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 CC2C63A7238 for ; Wed, 6 Oct 2010 12:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.267 X-Spam-Level: X-Spam-Status: No, score=-6.267 tagged_above=-999 required=5 tests=[AWL=0.332, 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 RLjAus0YqxWv for ; Wed, 6 Oct 2010 12:59:47 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id B1CED3A723E for ; Wed, 6 Oct 2010 12:59:46 -0700 (PDT) Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o96JxTAQ009727; Wed, 6 Oct 2010 15:59:29 -0400 Message-ID: <4CACD521.3060601@nist.gov> Date: Wed, 06 Oct 2010 15:59:29 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100921 Mandriva/3.0.8-0.1mdv2010.1 (2010.1) Thunderbird/3.0.8 MIME-Version: 1.0 To: Randy Bush References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Cc: "sidr@ietf.org" Subject: Re: [sidr] Certificate policy -- new draft (version 12 or 13) 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: , X-List-Received-Date: Wed, 06 Oct 2010 19:59:47 -0000 I presented several examples of methods that CAs may use to create Subject names in a way that minimizes the chances that two entities will be assigned the same name in a previous email (http://www.ietf.org/mail-archive/web/sidr/current/msg01739.html). On 10/02/2010 09:18 PM, Randy Bush wrote: >> However, Subject names in certificates SHOULD be constructed in a >> way that minimizes the chances that two entities in the RPKI will be >> assigned the same name. >> > and how they heck will that be done? and why? > From kent@bbn.com Wed Oct 6 15:19:43 2010 Return-Path: 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 E45B93A71DE for ; Wed, 6 Oct 2010 15:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.392 X-Spam-Level: X-Spam-Status: No, score=-102.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQKxOT3a26+E for ; Wed, 6 Oct 2010 15:19:42 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 4A1F03A6F95 for ; Wed, 6 Oct 2010 15:19:42 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49196) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P3cLq-0001rs-Qt for sidr@ietf.org; Wed, 06 Oct 2010 18:20:43 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 6 Oct 2010 18:20:38 -0400 To: sidr@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [sidr] responses to CP comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 22:19:44 -0000 Folks, Based on feedback from Randy, Geoff and Andrei, plus comments from Sean, we plan to make the following changes to the CP: - 1.2: we will delete the 3rd paragraph, but keep the first, as it parallels the Arch doc (as Sean noted). Randy, can you elaborate on the nature of current IANA allocations made to non-RIRs? Legacy allocations are not addressed in this paragraph, just the current allocation system. - 1.4.1: we will remove the reference to PI space here (i.e., delete the last sentence in the second paragraph). - 1.6.3: we will delete this (equivalent to "not applicable") section, since 3647 really focuses on the suitability of a CPS relative to the policy expressed by a CP. Andrei: I do not agree with your suggestion to remove the CPS MUSTs in the CP. The intent is to help ensure that each CA (as amended below, in 2.2) has a CPS, and that the CPS covers certain basic info. If each parent registry were to act as an approver for a subordinate CPS, this would not encourage RPKI-wide uniformity re CPS's. - 1.7: we will remove the definition of PI space from this section. - 2.2: it is the norm in a CP to require every CA covered by the CP to publish a CPS. For orgs that avail themselves of managed CA services, that burden is accepted by the supplier of that service. However, we agree that a CA in the RPKI that does not issue certificates to other subscribers really need not have to publish a CPS (since it has no "subjects" outside of its own administrative domain). So, how about the following change: OLD : Each CA MUST publish its CPS. NEW: Each CA that issues certificates to entities outside of its administrative domain MUST create and publish a CPS that meets the requirements set forth in this CP. Publication means that the entities to which the CA issues certificates MUST be able to acquire a copy of the CPS, and MUST be able to ascertain when the CPS changes. (An organization that does not allocate or assign INRs need not create nor publish a CPS.) - 3.1.2: I disagree with Randy's recollection of the history of this requirement. First it was no meaningful names for any subject other than IANA and the RIRs. Then, at Randy's request (a reasonable one :-)) it was changed to the current form, i.e., NO meaningful names for any subject. It's now uniform and egalitarian. If, in Randy's question, "uu" is uunet, then the answer is no, they ought not issue certificates with customer subject names. Geoff had a different concern here, i.e., that the text was not clear. We propose the following change: OLD: The Subject name in each certificate does not need to be meaningful. The certificates issued under this PKI are used for authorization in support of applications that make use of attestations of Internet resource holdings, not for identification. The PKI binds a public key to sets of INRs. The name of the holder of the INR is not intended to be "meaningful". NEW: The Subject name in each certificate SHOULD not be "meaningful", i.e., the name is NOT intended to convey the identity of the Subject to relying parties. The rationale here is that certificates issued under this PKI are used for authorization in support of applications that make use of attestations of INRs. They are not used for to identify Subjects. - 3.1.5: we will add a reference to the cert profile here. That doc includes an example of how to generate (meaningless) subject names in a way that minimizes the likelihood of collisions. I understand that this is what several instances of RIR software do anyway. - 3.1.6: The new text re trademarks is typical for a CP, but it does seem a bit harsh. The Subject name generation mechanisms described in the revised cert profile doc makes it unlikely that one would generate a name that would conflict with a trademark, but nothing is impossible. How about the following: OLD: When generating subject names, CAs should use a mechanism that is unlikely to result in Subject names that include trademarks, service marks, etc. CAs MUST NOT knowingly issue a certificate with a Subject name that a court of competent jurisdiction has determined infringes on the trademark of another individual or organization. NEW: When generating subject names, CAs SHOULD use a mechanism (such as those described [cert-profile]) to minimize the likelihood that the subject name is a trademark, service mark, etc. There is no requirement that a CA perform a search to verify that a subject name generated in this fashion does not infringe on a trademark, service mark, etc. - 4.10: The intent of this paragraph is to establish a minimum interval for an RP to check the repository system (not a local copy thereof), and to recommend a max rate of checking. The minimum interval is tied to the timing established in Geoff's key rollover document, the "staging period." The max is also a suggestion from Geoff. I'm open to a better wording here, but, like, you, I don't see a good fix. - 3.2.3: The purpose of this section is to require a CA to have a means of identifying and authenticating a person who acts as a representative for the organization that is responsible for the INRs for which the RPKI cert is issued. This is a typical requirement for a CA, i.e., there needs to be someone at an organization who acts as the liaison to the CA. Geoff is right that there is no explicit mention of whether the liaison info is current. However, the final sentence establishes the standard for satisfying this requirement, i.e., whatever the organization operating the CA already does for INR relationships. - 4.6.1: Geoff, by definition, certificate renewal does not entail a name change, so your first comment is not applicable. To clarify that we want the new certificate to be issued at least 24 hours before expiration of the old certificate, we propose the following change: OLD: An overlap period of at least 24 hours is RECOMMENDED. NEW: It is RECOMMENDED that the renewed certificate be issued and published at least 24 hours prior to the expiration of the certificate that it replaces. - 4.8.1: Here is our proposed text modification: OLD: Modification of a certificate occurs to implement changes to selected attribute values in a certificate. In the context of this PKI, the only changes that are accommodated by certificate modification are additions to the INR holdings described by the RFC 3779 extension. When previously distributed INRs are removed from a certificate, then the old certificate MUST be revoked and a new certificate MUST be issued. When a certificate modification is approved, a new certificate is issued. The new certificate MUST contain the same public key and the same expiration date as the original certificate, but with the incidental information corrected and/or the INRs expanded. Revocation of the previous certificate is not required. NEW: Modification of a certificate occurs to implement changes to selected attribute values in a certificate. In the context of the RPKI, the only changes that are accommodated by certificate modification are changes to the INR holdings described by the RFC 3779 extension and changes to the SIA extension. When a certificate modification is approved, a new certificate is issued. If no INR holdings are removed from the certificate, the new certificate MUST contain the same public key and the same expiration date as the original certificate (but with the SIA extension and/or and/or the INR set expanded). In this case, revocation of the previous certificate is not required. When previously distributed INRs are removed from a certificate, then the old certificate MUST be revoked and a new certificate MUST be issued, reflecting the changed INR holdings. (The SIA extension also may be changed during this action, if requested.) - 5.1: These are possible topics; their inclusion in a CPS is not mandated. Also, , I reworded 2.2 to make it clear that a non-registry/ISP need not publish a CPS, so the CPS mandates affect fewer folks. - 5.2: How about the following rewording: OLD: Each CA MUST maintain procedural security controls that are commensurate with those employed by the organization in the management of INR distribution. The details for each CA MUST be specified in its CPS. Topics covered SHOULD include: NEW: Each CA MUST maintain procedural security controls that are commensurate with those employed by the organization in the management of INR distribution. The procedural security controls employed for CA operation MUST be specified in its CPS. Possible topics to be covered in the CPS include: - 5.4.1: I think Sean addressed Randy's question here. - 5.6: I'll reference the key rollover document and delete the second sentence, I suggest the following text: OLD: When a CA wishes to change keys, it MUST acquire a new certificate containing its new public key, well in advance of the scheduled change. This certificate SHOULD have a validity period that is at least as long as that of any certificate being issued under that certificate. NEW: When a CA wishes to change keys, it MUST acquire a new certificate containing its new public key. See [key-rollover] for a description of how key changeover is effected on the RPKI. - 6.3.2: Randy and Geoff do not agree on whether/how to change this. I will delete the offending sentence, since it was not precise enough to be normative anyway. Also, the next sentence is not consistent with what we said in 4.8.1. I propose the following text for the 1st paragraph: OLD: The INRs held by a CA may periodically change because it receives new distributions. Therefore it is appropriate for its certificate to have a lifetime that matches the periodicity of these changes. However, to minimize disruption, the key pairs SHOULD be maintained across certificate changes (if no INRs are removed as a result of the certificate change). NEW: The INRs held by a CA may periodically change when it receives new distributions. To minimize disruption, the CA key MUST NOT change when INRs are added to it's certificate. From randy@psg.com Wed Oct 6 17:11:38 2010 Return-Path: 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 6F6043A6EAC for ; Wed, 6 Oct 2010 17:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=1.043, BAYES_00=-2.599, GB_I_INVITATION=-2] 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 AH-TTQqC1cvv for ; Wed, 6 Oct 2010 17:11:36 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 4851A3A6D97 for ; Wed, 6 Oct 2010 17:11:36 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P3e67-000IfT-Hw; Thu, 07 Oct 2010 00:12:35 +0000 Date: Thu, 07 Oct 2010 09:12:34 +0900 Message-ID: From: Randy Bush To: Stephen Kent In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] responses to CP comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 00:11:38 -0000 > Randy, can you elaborate on the nature of current IANA allocations > made to non-RIRs? Legacy allocations are not addressed in this > paragraph, just the current allocation system. we're talking about certs. iana will be issuing certs for those allocations, whether legacy, strawberry, or cowboy junkies. > The intent is to help ensure that each CA (as amended below, in 2.2) > has a CPS nice intent. i am not sure it will be met and not sure it MUST be for the internet to keep working. maybe a SHOULD is more realistic. > - 3.1.2: I disagree with Randy's recollection of the history of this > requirement. First it was no meaningful names for any subject other > than IANA and the RIRs. then you came in late. the IANA/RIR was a wg proposal you made in san fran, i think, about two years into this. > NEW: The Subject name in each certificate SHOULD not be "meaningful", > i.e., the name is NOT intended to convey the identity of the > Subject to relying parties. The rationale here is that > certificates issued under this PKI are used for authorization in > support of applications that make use of attestations of > INRs. They are not used for to identify Subjects. wfm > NEW: When generating subject names, CAs SHOULD use a mechanism (such as > those described [cert-profile]) to minimize the likelihood that > the subject name is a trademark, service mark, etc. why not stick to has no meaning? mentioning trade/service marks is an unnecessary invitation to people we would rather not have to talk to about this stuff. > NEW: It is RECOMMENDED that the renewed certificate be issued and > published at least 24 hours prior to the expiration of the > certificate that it replaces. and hopefully considerably earlier. if i am four down the chain, and someone a hop or two up has a cert soon to expire, that 24 hour window is a great cause of unnecessary adrenaline. if you have a time there, i would prefer a week, especially considering long processing cycles discussed by rirs. > NEW: Each CA MUST maintain procedural security controls that are > commensurate with those employed by the organization in the > management of INR distribution. The procedural security controls > employed for CA operation MUST be specified in its CPS. Possible > topics to be covered in the CPS include: > > - 5.4.1: I think Sean addressed Randy's question here. not to my satisfaction > - 6.3.2: Randy and Geoff do not agree on whether/how to change this. hmmm, i honestly do not remember. but i must be right because geoff is more jet lagged. :) > NEW: The INRs held by a CA may periodically change when it receives > new distributions. To minimize disruption, the CA key MUST NOT > change when INRs are added to it's certificate. i do not have enough coffee (and it is dishwater here in the icnp conf hotel) to think this through. but isn't my parent the one who adds the new resources to my cert? so you are telling me that i need to coordinate submitting a req to change my key with an unknown time when my parent decides to give me resources? as i said, need caffeine. randy From root@core3.amsl.com Thu Oct 7 06:00:01 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7816A3A6E75; Thu, 7 Oct 2010 06:00: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: <20101007130001.7816A3A6E75@core3.amsl.com> Date: Thu, 7 Oct 2010 06:00:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-keyroll-02.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: , X-List-Received-Date: Thu, 07 Oct 2010 13:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : CA Key Rollover in the RPKI Author(s) : G. Huston, et al. Filename : draft-ietf-sidr-keyroll-02.txt Pages : 10 Date : 2010-10-07 This document describes an algorithm to allow an entity who undertakes the role of a Certification Authority in the Resource Public Key Infrastructure to perform a rollover of its key pair. This document also notes the requirements placed on Relying Parties who maintain a local cache of the objects that have been published in the distributed Resource Public Key Infrastructure repository publication structure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-keyroll-02.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-keyroll-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-07055826.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu Oct 7 06:45:01 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A299D3A7068; Thu, 7 Oct 2010 06:45: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: <20101007134501.A299D3A7068@core3.amsl.com> Date: Thu, 7 Oct 2010 06:45:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-rpki-algs-02.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: , X-List-Received-Date: Thu, 07 Oct 2010 13:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure Author(s) : G. Huston Filename : draft-ietf-sidr-rpki-algs-02.txt Pages : 4 Date : 2010-10-07 This document defines a profile for the algorithm and key size to be used for signatures applied to certificates, Certificate Revocation Lists, and signed objects in the context of the Resource Public Key Infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-algs-02.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-algs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-07064059.I-D@ietf.org> --NextPart-- From gih@apnic.net Thu Oct 7 11:37:07 2010 Return-Path: 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 F29EE3A6F35 for ; Thu, 7 Oct 2010 11:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raNCnFmzdP3F for ; Thu, 7 Oct 2010 11:37:06 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 443A33A6DD4 for ; Thu, 7 Oct 2010 11:37:05 -0700 (PDT) Received: from host86.nanog.merit.net (host86.nanog.merit.net [192.35.164.155]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id A414DD589D; Fri, 8 Oct 2010 04:37:56 +1000 (EST) From: Geoff Huston Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 8 Oct 2010 05:37:48 +1100 Message-Id: To: draft-sidr-signed-object@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Cc: "sidr@ietf.org wg" Subject: [sidr] Question on draft-ietf-sidr-signed-object draft 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: , X-List-Received-Date: Thu, 07 Oct 2010 18:37:07 -0000 I am a little confused in reading section 4 of this draft. The intro to this section states that: "Each RPKI signed object MUST be defined in an Internet standards track document based on this profile, by specifying the following data elements and validation procedure:" My question is: Why is the Content-Type Attribute listed as a distinct data element that requires specification? The relevant text (item 3) states that: "Content-Type Attribute: The mandatory Content-Type Attribute MUST have its attrValues field set to the same OID as eContentType in item 1." So I understand that in writing a document that uses a RPKI signed object I have to define the eContentType, but I DO NOT need to also define the Content-Type Attribute. If this is the case then why is this data element listed in Section 4 of the draft as being a data element that MUST be separately specified in the specific object specification? regards, Geoff From housley@vigilsec.com Thu Oct 7 13:12:19 2010 Return-Path: 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 B3D6C3A7171 for ; Thu, 7 Oct 2010 13:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2puRRGXcCscs for ; Thu, 7 Oct 2010 13:12:16 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id D0B103A6FA3 for ; Thu, 7 Oct 2010 13:12:16 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id C6CC39A474E; Thu, 7 Oct 2010 16:13:20 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 5k5kjBWe7KH5; Thu, 7 Oct 2010 16:13:19 -0400 (EDT) Received: from [192.168.2.104] (pool-96-231-149-87.washdc.fios.verizon.net [96.231.149.87]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 2D41B9A471B; Thu, 7 Oct 2010 16:13:20 -0400 (EDT) Message-ID: <4CAE29E4.906@vigilsec.com> Date: Thu, 07 Oct 2010 16:13:24 -0400 From: Russ Housley User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Geoff Huston References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-sidr-signed-object@tools.ietf.org, "sidr@ietf.org wg" Subject: Re: [sidr] Question on draft-ietf-sidr-signed-object draft 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: , X-List-Received-Date: Thu, 07 Oct 2010 20:12:19 -0000 Geoff: The same OID is carried in two places, one that is covered by the digital signature (the attribute) and one that is used to properly perform the ASN.1 decode (the eContentType). Russ On 10/7/2010 2:37 PM, Geoff Huston wrote: > I am a little confused in reading section 4 of this draft. > > The intro to this section states that: > > "Each RPKI signed object MUST be defined in an Internet standards > track document based on this profile, by specifying the following > data elements and validation procedure:" > > My question is: Why is the Content-Type Attribute listed as a distinct > data element that requires specification? > > The relevant text (item 3) states that: > > "Content-Type Attribute: The mandatory Content-Type Attribute > MUST have its attrValues field set to the same OID as > eContentType in item 1." > > So I understand that in writing a document that uses a RPKI signed object I > have to define the eContentType, but I DO NOT need to also define the > Content-Type Attribute. If this is the case then why is this data element > listed in Section 4 of the draft as being a data element that MUST > be separately specified in the specific object specification? > > regards, > > Geoff From randy@psg.com Thu Oct 7 16:14:23 2010 Return-Path: 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 A69BE3A7076 for ; Thu, 7 Oct 2010 16:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 QUZTgblZjOfJ for ; Thu, 7 Oct 2010 16:14:09 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 7064D3A6EB7 for ; Thu, 7 Oct 2010 16:14:05 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P3zg2-000M6F-Tl for sidr@ietf.org; Thu, 07 Oct 2010 23:15:07 +0000 Date: Fri, 08 Oct 2010 08:15:05 +0900 Message-ID: From: Randy Bush To: sidr wg User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: [sidr] testbed sprint sat before ietf 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: , X-List-Received-Date: Thu, 07 Oct 2010 23:14:23 -0000 saturday november 6, we will be doing an rpki testbed workshop and hackathon in the ietf terminal room. bring unix/macosx/linux laptop, or access to a system on which you can do the install and configure. randy From drc@virtualized.org Thu Oct 7 16:26:58 2010 Return-Path: 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 B8FB03A6E2C for ; Thu, 7 Oct 2010 16:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=-0.286, 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 dZyVvycEKp6p for ; Thu, 7 Oct 2010 16:26:54 -0700 (PDT) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 1E5EE3A6D43 for ; Thu, 7 Oct 2010 16:26:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id B2367E9865D; Thu, 7 Oct 2010 16:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxvYFQbnkB8v; Thu, 7 Oct 2010 16:27:55 -0700 (PDT) Received: from [10.0.1.7] (cpe-70-95-123-210.hawaii.res.rr.com [70.95.123.210]) by virtualized.org (Postfix) with ESMTP id ED5F0E9864C; Thu, 7 Oct 2010 16:27:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: Date: Thu, 7 Oct 2010 13:27:53 -1000 Content-Transfer-Encoding: 7bit Message-Id: <13311E83-BBFC-4F4E-9195-D0908FAAD27D@virtualized.org> References: To: Randy Bush X-Mailer: Apple Mail (2.1081) Cc: sidr wg Subject: Re: [sidr] testbed sprint sat before ietf 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: , X-List-Received-Date: Thu, 07 Oct 2010 23:26:58 -0000 On Oct 7, 2010, at 1:15 PM, Randy Bush wrote: > saturday november 6, we will be doing an rpki testbed workshop and > hackathon in the ietf terminal room. bring unix/macosx/linux laptop, > or access to a system on which you can do the install and configure. For public information, what code will you be using for this? Thanks, -drc From randy@psg.com Thu Oct 7 16:31:55 2010 Return-Path: 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 A999E3A702E for ; Thu, 7 Oct 2010 16:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 jo2hSM+DxE1B for ; Thu, 7 Oct 2010 16:31:51 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 288263A6D43 for ; Thu, 7 Oct 2010 16:31:51 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P3zxF-000M9a-Q4; Thu, 07 Oct 2010 23:32:54 +0000 Date: Fri, 08 Oct 2010 08:32:50 +0900 Message-ID: From: Randy Bush To: David Conrad In-Reply-To: <13311E83-BBFC-4F4E-9195-D0908FAAD27D@virtualized.org> References: <13311E83-BBFC-4F4E-9195-D0908FAAD27D@virtualized.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg Subject: Re: [sidr] testbed sprint sat before ietf 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: , X-List-Received-Date: Thu, 07 Oct 2010 23:31:55 -0000 >> saturday november 6, we will be doing an rpki testbed workshop and >> hackathon in the ietf terminal room. bring unix/macosx/linux laptop, >> or access to a system on which you can do the install and configure. > For public information, what code will you be using for this? the open source full implementation (rpki, up/down, publication, relying party, gui, mocha ice cream), implementation at http://www.rpki.net/. and this goes all the way to some test routers to do origin validation. we hope to have easy-install packages in time, as opposed to the current python install. you may join the ongoing active testbed now, or participate remotely on the 6th. there is a mailing list. we just converted to non-tls per sidr discussion in maastricht. randy From christopher.morrow@gmail.com Thu Oct 7 18:48:07 2010 Return-Path: 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 4FB3A3A677E for ; Thu, 7 Oct 2010 18:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.403 X-Spam-Level: X-Spam-Status: No, score=-102.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KTi+KQ8wLOg for ; Thu, 7 Oct 2010 18:48:04 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id AE4D73A63EC for ; Thu, 7 Oct 2010 18:48:04 -0700 (PDT) Received: by iwn10 with SMTP id 10so683936iwn.31 for ; Thu, 07 Oct 2010 18:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=bzKOQCtnl/83B0OCdJ/a1FHcpY6w2XHah4c1Eai10qk=; b=RMIu+s8kduYQTgQXFAy7DhPhcdaXJ0qnjPQnkOWwV/t94svTF1VP/f/7WZ0Cv2iG+k 7dOxTlTSdl82LBU6/f2GBkn+bKYbvG6YMGpDnDryGaJFQeU2DaDoEJglSaqawky+fj9O mGQCo3M0PQJf3f9Mnj8eyn2/JxSslGh9lFGdA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=HnbUMR7R47gvB+1ADlGTlv2wVLUM83vdRHEWq3v+BfDF52KGAXtEfj0forqsKsG1fx 6Eo/tzvnN5eKJMnR4Kau7K9R5Xmx2Jo/WjJWi0PGHEC5QMASl63/c6WyxfA+1hTYEtHr ACuCIfMC6DzNjLGFR6XkwaaNOlW5zJjCIHVR8= MIME-Version: 1.0 Received: by 10.231.148.85 with SMTP id o21mr1754629ibv.26.1286502547666; Thu, 07 Oct 2010 18:49:07 -0700 (PDT) Received: by 10.231.120.195 with HTTP; Thu, 7 Oct 2010 18:49:07 -0700 (PDT) Date: Thu, 7 Oct 2010 21:49:07 -0400 Message-ID: From: Christopher Morrow To: sidr@ietf.org, Sandra Murphy , Chris Morrow Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] Call for WG Adoption - draft-pmohapat-sidr-origin-validation-signaling-00 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: , X-List-Received-Date: Fri, 08 Oct 2010 01:48:08 -0000 Howdy WG-folk, Pradosh has asked that we consider: for adoption in SIDR, could we hear back before 10/22/2010 pls? -Chris (wg-chair-belt-buckle == on) From christopher.morrow@gmail.com Thu Oct 7 18:48:34 2010 Return-Path: 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 3D4523A67A3 for ; Thu, 7 Oct 2010 18:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2tJ1Rtx+csd for ; Thu, 7 Oct 2010 18:48:26 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id A8F0C3A679F for ; Thu, 7 Oct 2010 18:48:24 -0700 (PDT) Received: by mail-iw0-f172.google.com with SMTP id 10so683936iwn.31 for ; Thu, 07 Oct 2010 18:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=zjv4EZx6xlbZmBk34rVGNpE0GzUqwq7a7R8w/w+8/2Y=; b=k2YGWM2bdxAKPP0pKxXdRWmQMAWSBg2rRAHUaJRCITm8qcyERUlSoyA5+HFtBhlA8z zasBeDUMQ37RywpCgDvuMIy819QqgBEJjJlpHsXY11LJuWEZC9PE3oeXrZ+6qJXRmi6l I5RoJ8k0ea1yHnxsh/PIGkQQ+rE64QvVo8K+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=AG8XFaNyYhnp9qpvfM5e/VSSXfTj8Q7a3gKt5rLYjwHvuIEl2ReqJmaD7XGpV6ViTe srvxs6928fGQ9VMK8QGbBtRvtKJ26sA2R/TWWZARmfpnWGU7vGWJh4nCo0PCfPx6v27L ic3xN23YcQlc4IAEPZQQBYqAC97DCWzcfAkr0= MIME-Version: 1.0 Received: by 10.42.97.10 with SMTP id l10mr155451icn.138.1286502567284; Thu, 07 Oct 2010 18:49:27 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.120.195 with HTTP; Thu, 7 Oct 2010 18:49:27 -0700 (PDT) In-Reply-To: References: Date: Thu, 7 Oct 2010 21:49:27 -0400 X-Google-Sender-Auth: G1ZkqR6UGBW2qTgHX4a-zl-i_Dk Message-ID: From: Christopher Morrow To: sidr@ietf.org, Sandra Murphy , Chris Morrow Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [sidr] Call for WG Adoption - draft-pmohapat-sidr-origin-validation-signaling-00 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: , X-List-Received-Date: Fri, 08 Oct 2010 01:48:35 -0000 On Thu, Oct 7, 2010 at 9:49 PM, Christopher Morrow wrote: > Howdy WG-folk, > Pradosh has asked that we consider: > > > for adoption in SIDR, could we hear back before 10/22/2010 pls? > > -Chris > (wg-chair-belt-buckle == on) s/chair/co-chair/ From randy@psg.com Thu Oct 7 18:54:30 2010 Return-Path: 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 998013A677E for ; Thu, 7 Oct 2010 18:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 fC4tBluJ9Jwl for ; Thu, 7 Oct 2010 18:54:29 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 7B8803A63EC for ; Thu, 7 Oct 2010 18:54:29 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P42BG-000NaO-U2; Fri, 08 Oct 2010 01:55:31 +0000 Date: Fri, 08 Oct 2010 10:55:28 +0900 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Sandra Murphy , sidr@ietf.org Subject: Re: [sidr] Call for WG Adoption - draft-pmohapat-sidr-origin-validation-signaling-00 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: , X-List-Received-Date: Fri, 08 Oct 2010 01:54:30 -0000 > Pradosh has asked that we consider: > > for adoption in SIDR, could we hear back before 10/22/2010 pls? yes From andrei@ripe.net Fri Oct 8 00:19:32 2010 Return-Path: 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 E2DE13A6828 for ; Fri, 8 Oct 2010 00:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7PQlUFHHDdm for ; Fri, 8 Oct 2010 00:19:32 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id B1C2E3A67FC for ; Fri, 8 Oct 2010 00:19:31 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1P47Fk-00026K-H9; Fri, 08 Oct 2010 09:20:34 +0200 Received: from andrei.vpn.ripe.net ([193.0.21.36] helo=Andrei-Robachevskys-MacBook-Air.local) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1P47Fj-00031s-NN; Fri, 08 Oct 2010 09:20:27 +0200 Message-ID: <4CAEC63B.5080707@ripe.net> Date: Fri, 08 Oct 2010 09:20:27 +0200 From: Andrei Robachevsky User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Stephen Kent References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Signature: 4330a47f43bd7e517cd9d6f2bba43afb9bb31dd0ea3ef660c23346f03423a5c6 X-RIPE-Spam-Level: -- X-RIPE-Signature: 4330a47f43bd7e517cd9d6f2bba43afb9bb31dd0ea3ef660c23346f03423a5c6 Cc: sidr@ietf.org Subject: Re: [sidr] responses to CP comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 07:19:33 -0000 Steve, Stephen Kent wrote on 7/10/10 12:20 AM: [...] > Andrei: I do not agree with your suggestion to remove the CPS MUSTs in > the CP. The intent is to help ensure that each CA (as amended below, in > 2.2) has a CPS, and that the CPS covers certain basic info. If each > parent registry were to act as an approver for a subordinate CPS, this > would not encourage RPKI-wide uniformity re CPS's. > The third parties are machines in the PKI. No one will ever read a CPS, not check if it is there (with an exception of RIRs and IANA, maybe). The only way to make it less pro forma is to request the parent to sign off on the compliance of the child CA (hence my comment re 1.6.3.). But, IMO, this will be an overkill at this stage. I understand the intention, but suggest relaxing it to at least SHOULD to make it more realistic. Andrei From root@core3.amsl.com Fri Oct 8 01:00:02 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 50A8D3A6827; Fri, 8 Oct 2010 01:00:02 -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: <20101008080002.50A8D3A6827@core3.amsl.com> Date: Fri, 8 Oct 2010 01:00:02 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-rpki-algs-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: , X-List-Received-Date: Fri, 08 Oct 2010 08:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure Author(s) : G. Huston Filename : draft-ietf-sidr-rpki-algs-03.txt Pages : 6 Date : 2010-10-08 This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size and signature format for the Resource Public Key Infrastructure subscribers that generate digital signatures on certificates, Certificate Revocation Lists, and signed objects as well as for the Relying Parties (RPs) that verify these digital signatures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-algs-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-rpki-algs-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-08005306.I-D@ietf.org> --NextPart-- From gih@apnic.net Fri Oct 8 05:02:23 2010 Return-Path: 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 B3C5F3A689B for ; Fri, 8 Oct 2010 05:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBr--McQL5dp for ; Fri, 8 Oct 2010 05:02:22 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id C5AD93A6898 for ; Fri, 8 Oct 2010 05:02:21 -0700 (PDT) Received: from [192.168.57.233] (unknown [208.52.153.128]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 05B49D58BC; Fri, 8 Oct 2010 22:03:21 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Fri, 8 Oct 2010 23:03:19 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5464D945-5FBB-4BDF-BE8C-53272D6CD228@kumari.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1081) Cc: sidr@ietf.org Subject: Re: [sidr] removing TLS from the provisioning protocol 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: , X-List-Received-Date: Fri, 08 Oct 2010 12:02:23 -0000 sure! If I scrub the HTTPS constructs from the draft what I'm left with are = "naked" CMS objects (and they look a lot like rpki-signed objects, but = they are not signed by keys certified by rpki certificates so I guess = that technically they are NOT spki-signed-objects). My question is: What is the end-to-end substrate for these objects? Or = should I just scrub HTTPS and leave the rest undefined? guidance please. thanks, Geoff (no clothing specified) On 15/09/2010, at 4:45 AM, Christopher Morrow wrote: > SIDR-WG Folks, > Hey, pulling up a note from the grave, this seems to have gotten no > dissent so, could the authors (and implementors) go scrub the stink of > tls off? >=20 > -Chris > (wg-chair-scarf on) >=20 > On Mon, Aug 30, 2010 at 11:25 AM, Warren Kumari = wrote: >>=20 >> On Aug 25, 2010, at 4:18 AM, Sandra Murphy wrote: >>=20 >>> We had a discussion in April on the list regarding removing TLS from = the >>> provisioning protocol. Rob Austein presented his views on the issue = at the >>> sidr meeting at the IETF78 in Maastricht. >>>=20 >>> I am calling for wg consensus on the question. Should the authors = of >>> draft-ietf-sidr-rescerts-provisioning-06 revise that draft to remove = TLS >>> from the protocol? >>=20 >> Yes, yes they should... >>=20 >> W >>=20 >>>=20 >>> Please respond to the list by 8 Sept, so the authors can represent = wg >>> consensus in the draft. >>>=20 >>> --Sandy >>>=20 >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>=20 >> -- >> No man is an island, But if you take a bunch of dead guys and tie = them >> together, they make a pretty good raft. >> --Anon. >>=20 >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr -- Geoff Huston Chief Scientist, APNIC +61 7 3858 3100 gih@apnic.net From sra@hactrn.net Fri Oct 8 05:31:37 2010 Return-Path: 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 224773A68A4 for ; Fri, 8 Oct 2010 05:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.135 X-Spam-Level: X-Spam-Status: No, score=-102.135 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMfZUKjHsrc2 for ; Fri, 8 Oct 2010 05:31: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 BE8B53A68A2 for ; Fri, 8 Oct 2010 05:31:35 -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 DEA2728441 for ; Fri, 8 Oct 2010 12:32:37 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 8F8B422829 for ; Fri, 8 Oct 2010 08:32:37 -0400 (EDT) Date: Fri, 08 Oct 2010 08:32:37 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <5464D945-5FBB-4BDF-BE8C-53272D6CD228@kumari.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") Content-Type: text/plain; charset=US-ASCII Message-Id: <20101008123237.8F8B422829@thrintun.hactrn.net> Subject: Re: [sidr] removing TLS from the provisioning protocol 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: , X-List-Received-Date: Fri, 08 Oct 2010 12:31:37 -0000 At Fri, 8 Oct 2010 23:03:19 +1100, Geoff Huston wrote: > > If I scrub the HTTPS constructs from the draft what I'm left with > are "naked" CMS objects I would have thought we'd be left with CMS objects wrapped in HTTP, replacing CMS objects wrapped in HTTPS. Strictly speaking, what we're doing here is removing the TLS encapsulation of HTTP. > (and they look a lot like rpki-signed objects, but they are not > signed by keys certified by rpki certificates so I guess that > technically they are NOT spki-signed-objects). Different CMS eContentType OIDs too: 1.2.840.113549.1.9.16.1.24 id-ct-routeOriginAttestation 1.2.840.113549.1.9.16.1.26 id-ct-rpkiManifest 1.2.840.113549.1.9.16.1.28 id-ct-xml From gih@apnic.net Fri Oct 8 06:15:40 2010 Return-Path: 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 E9F7D3A68BB for ; Fri, 8 Oct 2010 06:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDuOsBGPugsW for ; Fri, 8 Oct 2010 06:15:39 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id D13253A68A7 for ; Fri, 8 Oct 2010 06:15:38 -0700 (PDT) Received: from host86.nanog.merit.net (host86.nanog.merit.net [192.35.164.155]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 2399BD58AC; Fri, 8 Oct 2010 23:16:30 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: <20101008123237.8F8B422829@thrintun.hactrn.net> Date: Sat, 9 Oct 2010 00:16:22 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <40ED19F1-21DF-4341-9768-63DE3459D9DF@apnic.net> References: <5464D945-5FBB-4BDF-BE8C-53272D6CD228@kumari.net> <20101008123237.8F8B422829@thrintun.hactrn.net> To: Rob Austein X-Mailer: Apple Mail (2.1081) Cc: "sidr@ietf.org wg" Subject: Re: [sidr] removing TLS from the provisioning protocol 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: , X-List-Received-Date: Fri, 08 Oct 2010 13:15:41 -0000 On 08/10/2010, at 11:32 PM, Rob Austein wrote: > At Fri, 8 Oct 2010 23:03:19 +1100, Geoff Huston wrote: >>=20 >> If I scrub the HTTPS constructs from the draft what I'm left with >> are "naked" CMS objects >=20 > I would have thought we'd be left with CMS objects wrapped in HTTP, > replacing CMS objects wrapped in HTTPS. Strictly speaking, what we're > doing here is removing the TLS encapsulation of HTTP. ok - I can do that >=20 >> (and they look a lot like rpki-signed objects, but they are not >> signed by keys certified by rpki certificates so I guess that >> technically they are NOT spki-signed-objects). >=20 > Different CMS eContentType OIDs too: >=20 > 1.2.840.113549.1.9.16.1.24 id-ct-routeOriginAttestation=20 > 1.2.840.113549.1.9.16.1.26 id-ct-rpkiManifest=20 > 1.2.840.113549.1.9.16.1.28 id-ct-xml=20 that too! I assume that in addition to the CMS requirement that: "The signing-time attribute MUST be present" there is an additional requirement that reads (approximately) "Each party MUST ensure that the signing-time attribute value is = strictly greater than the signing-time attribute value of the previous = message sent to the same recipient. Messages received with a = signing-time value less than that of the most recently received and = accepted message from the same sender MUST be rejected." I'm also pretty sure that this text is inadequate in various corner = cases, and of there are suggestions on how to improve this skeletal text = to allow he CMS signing-time attribute as a reasonable form of replay = attack protection would be appreciated. thanks Geoff From sra@hactrn.net Fri Oct 8 06:34:32 2010 Return-Path: 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 825853A6892 for ; Fri, 8 Oct 2010 06:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.29 X-Spam-Level: X-Spam-Status: No, score=-102.29 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCxDa-+7+jyl for ; Fri, 8 Oct 2010 06:34:31 -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 CC7693A6835 for ; Fri, 8 Oct 2010 06:34:30 -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 2E92F28441 for ; Fri, 8 Oct 2010 13:35:33 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id C5F0F22829 for ; Fri, 8 Oct 2010 09:35:32 -0400 (EDT) Date: Fri, 08 Oct 2010 09:35:32 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <40ED19F1-21DF-4341-9768-63DE3459D9DF@apnic.net> References: <5464D945-5FBB-4BDF-BE8C-53272D6CD228@kumari.net> <20101008123237.8F8B422829@thrintun.hactrn.net> <40ED19F1-21DF-4341-9768-63DE3459D9DF@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") Content-Type: text/plain; charset=US-ASCII Message-Id: <20101008133532.C5F0F22829@thrintun.hactrn.net> Subject: Re: [sidr] removing TLS from the provisioning protocol 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: , X-List-Received-Date: Fri, 08 Oct 2010 13:34:32 -0000 At Sat, 9 Oct 2010 00:16:22 +1100, Geoff Huston wrote: > > I assume that in addition to the CMS requirement that: > > "The signing-time attribute MUST be present" Yes. > there is an additional requirement that reads (approximately) > > "Each party MUST ensure that the signing-time attribute value is > strictly greater than the signing-time attribute value of the > previous message sent to the same recipient. Messages received with > a signing-time value less than that of the most recently received > and accepted message from the same sender MUST be rejected." Close. I think the proposal was that the signing time attribute must be greater than or equal to the signing-time attribute of previous messages sent by the same originator to the same recipient. "Greater than or equal to" vs "strictly greater than" is important, and is a tradeoff. The advantage is that it removes the problem of unintended rate limiting to one message per second (don't really know if that's a real issue, but in theory it might be). Disadvantage is that it leaves one open to replay of the latest message, but with the protocol as currently written, I haven't been able to think of anything evil an attacker could do by replaying the most recent message, and it's easy for the sender to add one-second delays (if neede) to the middle of a command stream that really should not be inverted. So greater-than-or-equal-to seems right to me. There probably should also to be a note somewhere stating that there must be -some- way (even if only manually typing SQL commands, that's an implementation detail) for an operator to reset this value, to handle the case where a sender accidently signs with a time far in the future (read: "wait two years and call me in the morning" is not the preferred answer from the help desk in such cases). From kent@bbn.com Fri Oct 8 08:14:09 2010 Return-Path: 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 803683A6900 for ; Fri, 8 Oct 2010 08:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.135 X-Spam-Level: X-Spam-Status: No, score=-103.135 tagged_above=-999 required=5 tests=[AWL=0.864, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8pFOXSXmgnu for ; Fri, 8 Oct 2010 08:14:06 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 716C13A68D9 for ; Fri, 8 Oct 2010 08:14:06 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:57917 helo=[192.168.1.10]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P4Ef9-0004qh-0D; Fri, 08 Oct 2010 11:15:11 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 8 Oct 2010 11:15:08 -0400 To: Randy Bush From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] responses to CP comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 15:14:09 -0000 Randy, Thanks for the quick feedback. I'll reply on,y to what appear to be the remaining, unresolved issues: > > Randy, can you elaborate on the nature of current IANA allocations >> made to non-RIRs? Legacy allocations are not addressed in this >> paragraph, just the current allocation system. > >we're talking about certs. iana will be issuing certs for those >allocations, whether legacy, strawberry, or cowboy junkies. I don't mean to seem dense, but I still don't see a characterization here that I could cite in the CP. > > The intent is to help ensure that each CA (as amended below, in 2.2) >> has a CPS > >nice intent. i am not sure it will be met and not sure it MUST be for >the internet to keep working. maybe a SHOULD is more realistic. We'll change this to a SHOULD, which also is consistent with Andrei's most recent message as well. > > NEW: When generating subject names, CAs SHOULD use a >mechanism (such as >> those described [cert-profile]) to minimize the likelihood that >> the subject name is a trademark, service mark, etc. > >why not stick to has no meaning? mentioning trade/service marks is an >unnecessary invitation to people we would rather not have to talk to >about this stuff. Sean asked us to add the trademark text, because it is common in CPs. I agree that it is inappropriate to impose a burden of this sort on the orgs that we are asking to act as CAs here. Not mentioning this issue does not provide "cover" for these orgs. Saying that a CA that employs the recommended name gen technique, or an analogous mechanism, gets a pass, may provide cover, so I think it is worthwhile. But, if most WG members are more comfortable with deleting this, let us know, and we'll remove it. > >> NEW: It is RECOMMENDED that the renewed certificate be issued and >> published at least 24 hours prior to the expiration of the >> certificate that it replaces. > >and hopefully considerably earlier. > >if i am four down the chain, and someone a hop or two up has a cert soon >to expire, that 24 hour window is a great cause of unnecessary >adrenaline. if you have a time there, i would prefer a week, especially >considering long processing cycles discussed by rirs. At first I though this interacted with the key rollover doc, but this text talks about cert renewal, so we can make the recommended renewal interval "at least 1 week" instead of "at lest 24 hours." > >> NEW: Each CA MUST maintain procedural security controls that are >> commensurate with those employed by the organization in the >> management of INR distribution. The procedural security controls >> employed for CA operation MUST be specified in its CPS. Possible >> topics to be covered in the CPS include: >> >> - 5.4.1: I think Sean addressed Randy's question here. > >not to my satisfaction You asked about the requirement to audit clock adjustments, and mentioned ntpd. Sean said: I don't think you have to go that far. If you look in the logs of say a mac (because I've got one), you can see that I tweaked the time this morning: Oct 3 09:49:54 computername SecurityAgent[2165]: system.preferences|2010-10-03 09:49:54 -0400 Oct 3 08:50:48 computername SecurityAgent[2165]: system.preferences|2010-10-03 09:50:48 -0400 That's pretty much what you need. So, what would you like to see here re this topic? Are you saying that it's too hard to log clock adjustments on a machine acting as a CA, and that we should omit this item, or are you asking for more guidance re how to perform the logging? > > - 6.3.2: Randy and Geoff do not agree on whether/how to change this. > >hmmm, i honestly do not remember. but i must be right because geoff is >more jet lagged. :) > >> NEW: The INRs held by a CA may periodically change when it receives >> new distributions. To minimize disruption, the CA key MUST NOT >> change when INRs are added to it's certificate. > >i do not have enough coffee (and it is dishwater here in the icnp conf >hotel) to think this through. but isn't my parent the one who adds the >new resources to my cert? so you are telling me that i need to >coordinate submitting a req to change my key with an unknown time when >my parent decides to give me resources? as i said, need caffeine. Yes, it is your parent that inserts new INRs into your cert. This text says that when this operation is done, your key stays the same, so that all of the objects that you signed do NOT have to be re-signed. So, the effect is the opposite of what you are worried about, i.e., when your parent adds resources to your cert, you do not have to do anything, until you decide to issue ROAs (or subordinate CA certs) that make use of the newly added resources. Are we OK on this? Steve From kent@bbn.com Fri Oct 8 08:18:14 2010 Return-Path: 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 F21EC3A690F for ; Fri, 8 Oct 2010 08:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYCHAIWFCdN7 for ; Fri, 8 Oct 2010 08:18:12 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 3BF7E3A6905 for ; Fri, 8 Oct 2010 08:18:12 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:50660 helo=[192.168.1.10]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P4Ej6-0004uL-4G; Fri, 08 Oct 2010 11:19:16 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4CAEC63B.5080707@ripe.net> References: <4CAEC63B.5080707@ripe.net> Date: Fri, 8 Oct 2010 11:19:14 -0400 To: Andrei Robachevsky From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] responses to CP comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 15:18:14 -0000 At 9:20 AM +0200 10/8/10, Andrei Robachevsky wrote: >Steve, > >Stephen Kent wrote on 7/10/10 12:20 AM: >[...] >> Andrei: I do not agree with your suggestion to remove the CPS MUSTs in >> the CP. The intent is to help ensure that each CA (as amended below, in >> 2.2) has a CPS, and that the CPS covers certain basic info. If each >> parent registry were to act as an approver for a subordinate CPS, this >> would not encourage RPKI-wide uniformity re CPS's. >> >The third parties are machines in the PKI. No one will ever read a CPS, >not check if it is there (with an exception of RIRs and IANA, maybe). >The only way to make it less pro forma is to request the parent to sign >off on the compliance of the child CA (hence my comment re 1.6.3.). But, >IMO, this will be an overkill at this stage. I understand the intention, >but suggest relaxing it to at least SHOULD to make it more realistic. > >Andrei Andrei, A CA is not a machine. A CA is an entity, usually an organizational entity, that uses people to execute procedures and uses a computer to perform algorithmic functions. If a registry (at any tier) offers a managed CA service for folks to whom it has allocates resources, it is the registry that is acting as a CA in conjunction with the org that took advantage of the managed service offer. (pardon the overly long sentence.) Noentheless, we'll change the text from MUST to SHOULD. Steve From gih@apnic.net Fri Oct 8 08:30:38 2010 Return-Path: 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 6AB223A690F for ; Fri, 8 Oct 2010 08:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anfT0B9iU7vk for ; Fri, 8 Oct 2010 08:30:36 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id A30F63A6930 for ; Fri, 8 Oct 2010 08:30:29 -0700 (PDT) Received: from host86.nanog.merit.net (host86.nanog.merit.net [192.35.164.155]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 7B798D58BC; Sat, 9 Oct 2010 01:31:21 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Sat, 9 Oct 2010 02:31:13 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Stephen Kent X-Mailer: Apple Mail (2.1081) Cc: sidr@ietf.org Subject: Re: [sidr] responses to CP comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 15:30:38 -0000 On 09/10/2010, at 2:15 AM, Stephen Kent wrote: >=20 >> > NEW: When generating subject names, CAs SHOULD use a = mechanism (such as >>> those described [cert-profile]) to minimize the likelihood that >>> the subject name is a trademark, service mark, etc. >>=20 >> why not stick to has no meaning? mentioning trade/service marks is = an >> unnecessary invitation to people we would rather not have to talk to >> about this stuff. >=20 > Sean asked us to add the trademark text, because it is common in CPs. = I agree that it is inappropriate to impose a burden of this sort on the = orgs that we are asking to act as CAs here. Not mentioning this issue = does not provide "cover" for these orgs. Saying that a CA that employs = the recommended name gen technique, or an analogous mechanism, gets a = pass, may provide cover, so I think it is worthwhile. But, if most WG = members are more comfortable with deleting this, let us know, and we'll = remove it. >=20 I, for one, am more comfortable with deleting this. thanks Geoff= From root@core3.amsl.com Sun Oct 10 03:45:02 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D38B33A67D3; Sun, 10 Oct 2010 03:45:02 -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: <20101010104502.D38B33A67D3@core3.amsl.com> Date: Sun, 10 Oct 2010 03:45:02 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-roa-validation-07.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: , X-List-Received-Date: Sun, 10 Oct 2010 10:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Validation of Route Origination using the Resource Certificate PKI and ROAs Author(s) : G. Huston, G. Michaelson Filename : draft-ietf-sidr-roa-validation-07.txt Pages : 10 Date : 2010-10-10 This document defines the semantics of a Route Origin Authorization (ROA) in terms of the context of an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-validation-07.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-validation-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-10033208.I-D@ietf.org> --NextPart-- From gih@apnic.net Sun Oct 10 03:47:23 2010 Return-Path: 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 8E0703A67E5 for ; Sun, 10 Oct 2010 03:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.929 X-Spam-Level: X-Spam-Status: No, score=-99.929 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKTsMd+jBLHy for ; Sun, 10 Oct 2010 03:47:22 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id EF2903A676A for ; Sun, 10 Oct 2010 03:47:20 -0700 (PDT) Received: from [38.97.127.19] (unknown [38.97.127.19]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 15121D589D for ; Sun, 10 Oct 2010 20:48:22 +1000 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Geoff Huston In-Reply-To: Date: Sun, 10 Oct 2010 21:48:20 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "sidr@ietf.org wg" X-Mailer: Apple Mail (2.1081) Subject: [sidr] draft-ietf-sidr-roa-validation-07 submitted X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2010 10:47:23 -0000 Hi, The draft's authors have reviewed the WG discussion and have decided to = use, with acknowledgement in the draft, and an expression of thanks = here, the terminology in a related WG draft, = draft-ietf-sidr-pfx-validate. The revised terminology does not refer to = a route as being "valid", "invalid" or "unknown", but refers to an = attribute of the route, namely its "validity state", and this attribute = has the values of "valid", "invalid" or "unknown", and notes that "not = found" is synonymous to "unknown" in this context. The authors trust = that this distinction addresses the issues WG members had over the = terminology in the previous version of this draft, that used such state = attributions directly on the route itself, rather than on a nominated = attribute of the route. The announcement of the submission of this revised draft is below. regards, Geoff A new version of I-D, draft-ietf-sidr-roa-validation-07.txt has been = successfully submitted by Geoff Huston and posted to the IETF = repository. Filename: draft-ietf-sidr-roa-validation Revision: 07 Title: Validation of Route Origination using the Resource = Certificate PKI and ROAs Creation_date: 2010-10-10 WG ID: sidr Number_of_pages: 10 Abstract: This document defines the semantics of a Route Origin Authorization (ROA) in terms of the context of an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol. On 08/06/2010, at 11:01 PM, Sandra Murphy wrote: > The WG LC has ended. >=20 > There were no responses to this LC. None. Zip. Zero. >=20 > This draft has gone through many changes through the years as it has = been discussed in IETF meetings. >=20 > So the silence must be regarded as proof that the wg had no further = comments to make. >=20 > I do note that the discussion of terminology (valid/unknown/invalid) = in the draft-pmohapat-sidr-pfx-validate-07 draft apply equally to this = draft and that an author of this draft had alternative terms to suggest = in that discussion. >=20 > I believe that that energetic discussion is indication that the wg = would prefer different terminology be used in this draft as well. >=20 > I invite the authors to continue that discussion to come to consensus = of what terms best capture the desired semantics. >=20 > Any final last call on this draft would be very short indeed. >=20 > --Sandy, speaking as wg chair >=20 > On Tue, 18 May 2010, Sandra Murphy wrote: >=20 >> The presentation "ROA Validation Update" = (http://www.ietf.org/proceedings/77/slides/sidr-8.pdf) at IETF 77 = requested a WG LC for draft "Validation of Route Origination using the = Resource Certificate PKI and ROAs". >>=20 >> The document (and the draft version history) is at available at >> http://tools.ietf.org/html/draft-ietf-sidr-roa-validation-06. >>=20 >> The Last Call will end on Wednesday 2 June 2010. >>=20 >> As usual, please address all comments to the WG mailing list, and = please be clear in your comments to this last call if you are supporting = the document's submission to the IESG or if you are opposed. If you are = opposed, please indicate why. >>=20 >> --Sandy >>=20 >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr -- Geoff Huston Chief Scientist, APNIC +61 7 3858 3100 gih@apnic.net From gih@apnic.net Sun Oct 10 03:49:08 2010 Return-Path: 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 9109D3A67A6 for ; Sun, 10 Oct 2010 03:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.929 X-Spam-Level: X-Spam-Status: No, score=-99.929 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8qWbTXqfuvs for ; Sun, 10 Oct 2010 03:49:07 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 5C9273A676A for ; Sun, 10 Oct 2010 03:49:07 -0700 (PDT) Received: from [38.97.127.19] (unknown [38.97.127.19]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 4E947D589D; Sun, 10 Oct 2010 20:50:14 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Sun, 10 Oct 2010 21:50:11 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sandra Murphy , Christopher Morrow X-Mailer: Apple Mail (2.1081) Cc: sidr@ietf.org Subject: [sidr] WG LC request for draft-ietf-sidr-roa-validation-07 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: , X-List-Received-Date: Sun, 10 Oct 2010 10:49:08 -0000 Hi, The draft's authors believe that the document = draft-ietf-sidr-roa-validation-07 is ready for WG Last Call, and in this = note we are requesting the WG Chairs to conduct such a WG Last Call. thanks, Geoff On 08/06/2010, at 11:01 PM, Sandra Murphy wrote: > The WG LC has ended. >=20 > There were no responses to this LC. None. Zip. Zero. >=20 > This draft has gone through many changes through the years as it has = been discussed in IETF meetings. >=20 > So the silence must be regarded as proof that the wg had no further = comments to make. >=20 > I do note that the discussion of terminology (valid/unknown/invalid) = in the draft-pmohapat-sidr-pfx-validate-07 draft apply equally to this = draft and that an author of this draft had alternative terms to suggest = in that discussion. >=20 > I believe that that energetic discussion is indication that the wg = would prefer different terminology be used in this draft as well. >=20 > I invite the authors to continue that discussion to come to consensus = of what terms best capture the desired semantics. >=20 > Any final last call on this draft would be very short indeed. >=20 > --Sandy, speaking as wg chair >=20 > On Tue, 18 May 2010, Sandra Murphy wrote: >=20 >> The presentation "ROA Validation Update" = (http://www.ietf.org/proceedings/77/slides/sidr-8.pdf) at IETF 77 = requested a WG LC for draft "Validation of Route Origination using the = Resource Certificate PKI and ROAs". >>=20 >> The document (and the draft version history) is at available at >> http://tools.ietf.org/html/draft-ietf-sidr-roa-validation-06. >>=20 >> The Last Call will end on Wednesday 2 June 2010. >>=20 >> As usual, please address all comments to the WG mailing list, and = please be clear in your comments to this last call if you are supporting = the document's submission to the IESG or if you are opposed. If you are = opposed, please indicate why. >>=20 >> --Sandy >>=20 >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr -- Geoff Huston Chief Scientist, APNIC +61 7 3858 3100 gih@apnic.net From rogaglia@cisco.com Sun Oct 10 13:21:51 2010 Return-Path: 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 50BE93A6856 for ; Sun, 10 Oct 2010 13:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.935 X-Spam-Level: X-Spam-Status: No, score=-9.935 tagged_above=-999 required=5 tests=[AWL=0.664, 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 TvdbVR+ySZ6I for ; Sun, 10 Oct 2010 13:21:50 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2011A3A6855 for ; Sun, 10 Oct 2010 13:21:49 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgDAAS+sUyQ/khMgWdsb2JhbACiDxUBARYiIqFKm3KFSASKQQ X-IronPort-AV: E=Sophos;i="4.57,310,1283731200"; d="scan'208";a="66302133" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 10 Oct 2010 20:22:59 +0000 Received: from dhcp-10-55-81-221.cisco.com (dhcp-10-55-81-221.cisco.com [10.55.81.221]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o9AKMweP017341; Sun, 10 Oct 2010 20:22:58 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Roque Gagliano In-Reply-To: Date: Sun, 10 Oct 2010 22:23:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3B34FA89-4751-4358-BD3B-AB167A5908CA@cisco.com> References: To: Sandra Murphy X-Mailer: Apple Mail (2.1081) Cc: sidr@ietf.org Subject: Re: [sidr] WG adoption of draft-reynolds-rpki-ltamgmt-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: , X-List-Received-Date: Sun, 10 Oct 2010 20:21:51 -0000 Hi Sandra, I support this document. Doing a quick read, when mentioning SKI as a 40 bytes field, the author = is sticking to SHA-1 to calculate it. I do not see why to impose the = restriction here.=20 Regards, Roque On Sep 28, 2010, at 12:03 AM, Sandra Murphy wrote: > The wg chairs have received a request that the working group adopt the = draft "Local Trust Anchor Management for the Resource Public Key = Infrastructure" as a wg work item. >=20 > This material of this draft was presented at >=20 > IETF 75 = (http://www.ietf.org/proceedings/75/slides/sidr-3/sidr-3_files/v3_document= .htm) > IETF 76 (http://www.ietf.org/proceedings/76/slides/sidr-11.pdf) > and IETF 77 = (http://www.ietf.org/proceedings/77/slides/sidr-6/sidr-6_files/v3_document= .htm) >=20 > A draft was requested by the audience at IETF 75. The -00 version was = submitted in Mar 2010 and wg adoption was requested. Response to that = request did not indicate wg consensus - the responses were positive but = there were only three replies. >=20 > A new version of the draft is available at > http://www.ietf.org/id/draft-reynolds-rpki-ltamgmt-01.txt > http://tools.ietf.org/html/draft-reynolds-rpki-ltamgmt-01 >=20 > The authors request that the wg consider this new version again for wg = adoption. >=20 > Recall that active support for adoption is necessary for the wg chairs = to judge acceptance as a working group work item, so silence works = against adoption. The wg chairs also want to know who would be willing = to work on the draft. The wg chairs also want to know if you oppose = adoption. >=20 > Please respond to the list, giving your recommendation for or against = adoption of the draft as a wg work item as well as your intention to = work on the draft if adopted. The call for adoption will end in two = weeks on 11 Oct 2010. >=20 > --Sandy, wg chair bowler on >=20 >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From rogaglia@cisco.com Sun Oct 10 13:27:35 2010 Return-Path: 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 3A4113A6856 for ; Sun, 10 Oct 2010 13:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.953 X-Spam-Level: X-Spam-Status: No, score=-9.953 tagged_above=-999 required=5 tests=[AWL=0.646, 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 z4ZyQy9OhyTs for ; Sun, 10 Oct 2010 13:27:34 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 16CCD3A6801 for ; Sun, 10 Oct 2010 13:27:33 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgDACe/sUyQ/khMgWdsb2JhbACiDxUBARYiIqFSm3KFSASKQQ X-IronPort-AV: E=Sophos;i="4.57,310,1283731200"; d="scan'208";a="66302195" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 10 Oct 2010 20:28:43 +0000 Received: from dhcp-10-55-81-221.cisco.com (dhcp-10-55-81-221.cisco.com [10.55.81.221]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o9AKSgPY018139; Sun, 10 Oct 2010 20:28:42 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Roque Gagliano In-Reply-To: Date: Sun, 10 Oct 2010 22:29:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9EAF36BA-154B-4FBD-923C-D57D26A8C1B8@cisco.com> References: To: Christopher Morrow X-Mailer: Apple Mail (2.1081) Cc: Sandra Murphy , "sidr@ietf.org wg" Subject: Re: [sidr] Call for WG Adoption - draft-pmohapat-sidr-origin-validation-signaling-00 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: , X-List-Received-Date: Sun, 10 Oct 2010 20:27:35 -0000 yes. On Oct 8, 2010, at 3:49 AM, Christopher Morrow wrote: > Howdy WG-folk, > Pradosh has asked that we consider: > = >=20 > for adoption in SIDR, could we hear back before 10/22/2010 pls? >=20 > -Chris > (wg-chair-belt-buckle =3D=3D on) > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From root@core3.amsl.com Mon Oct 11 03:15:10 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5CEFA3A6943; Mon, 11 Oct 2010 03:15:05 -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: <20101011101506.5CEFA3A6943@core3.amsl.com> Date: Mon, 11 Oct 2010 03:15:05 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-repos-struct-05.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: , X-List-Received-Date: Mon, 11 Oct 2010 10:15:11 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Profile for Resource Certificate Repository Structure Author(s) : G. Huston, et al. Filename : draft-ietf-sidr-repos-struct-05.txt Pages : 14 Date : 2010-10-11 This document defines a profile for the structure of repository publication points that contain X.509 / PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile contains the proposed object naming scheme, the contents of repository publication points, and a suggested internal structure of a local repository cache that is intended to facilitate synchronisation across a distributed collection of repository publication points and facilitate certification path construction. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-repos-struct-05.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-repos-struct-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-11030507.I-D@ietf.org> --NextPart-- From kotikalapudi.sriram@nist.gov Mon Oct 11 07:13:55 2010 Return-Path: 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 3EA463A6A8E for ; Mon, 11 Oct 2010 07:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 7iCKeEiM8zV8 for ; Mon, 11 Oct 2010 07:13:53 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 403833A6A8B for ; Mon, 11 Oct 2010 07:13:52 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (WSXGHUB2.xchange.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o9BEEfnd020170; Mon, 11 Oct 2010 10:14:41 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 11 Oct 2010 10:14:11 -0400 From: "Sriram, Kotikalapudi" To: Geoff Huston , "sidr@ietf.org wg" Date: Mon, 11 Oct 2010 10:14:11 -0400 Thread-Topic: [sidr] draft-ietf-sidr-roa-validation-07 submitted Thread-Index: ActoaKwhOY8WRmsORXexcooKw66iqQA3+nLQ Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Subject: Re: [sidr] draft-ietf-sidr-roa-validation-07 submitted X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 14:13:55 -0000 Geoff: I have a concern about the way the origin is determined when AS_SET is present in an update. Quoting from draft-ietf-sidr-roa-validation-07: "If the final path segment of the AS_PATH is of type AS_SET, indicating that the route is an aggregate, then the origin AS is taken as the AS component of the AGGREGATOR attribute [RFC4271], if present. Otherwise the route's origin AS cannot be determined." At the Maastricht SIDR WG meeting, I gave a presentation in which I highlighted a new attack vector that is possible due to the above quoted way of determining the origin AS. Please see slide 7 of said presentation: http://www.ietf.org/proceedings/78/slides/sidr-4.pdf http://www.antd.nist.gov/~ksriram/AS_SET_Aggregator_Stats.pdf (The second link has slightly revised slides with corrections.) In the presentation, I also pointed out a simple method for avoiding the new type of attack (also on slide 7). This method (or remedy) draws support from the data that I presented in the preceding slides (slide 2-4). After my presentation, there was significant interest in this topic and some good discussions followed on the list; links to some of which are: http://www.ietf.org/mail-archive/web/sidr/current/msg01780.html http://www.ietf.org/mail-archive/web/sidr/current/msg01794.html http://www.ietf.org/mail-archive/web/sidr/current/msg01791.html Of course, a different take on all this is to deprecate the AS_SET. http://www.ietf.org/mail-archive/web/sidr/current/msg01772.html Warren Kumari has submitted a draft to IDR to try to accomplish that. Until that is accomplished, if we think we have to be compliant with RFC 4271, then I think my suggested solution makes sense. You may also factor in some comments/augmentation that Jeff Hass and Pradosh have made to my proposal: http://www.ietf.org/mail-archive/web/sidr/current/msg01791.html http://www.ietf.org/mail-archive/web/sidr/current/msg01794.html Regards, Sriram ________________________________________ From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] On Behalf Of Geoff Huston [gih@apnic.net] Sent: Sunday, October 10, 2010 6:48 AM To: sidr@ietf.org wg Subject: [sidr] draft-ietf-sidr-roa-validation-07 submitted Hi, The draft's authors have reviewed the WG discussion and have decided to use, with acknowledgement in the draft, and an expression of thanks here, the terminology in a related WG draft, draft-ietf-sidr-pfx-validate. The revised terminology does not refer to a route as being "valid", "invalid" or "unknown", but refers to an attribute of the route, namely its "validity state", and this attribute has the values of "valid", "invalid" or "unknown", and notes that "not found" is synonymous to "unknown" in this context. The authors trust that this distinction addresses the issues WG members had over the terminology in the previous version of this draft, that used such state attributions directly on the route itself, rather than on a nominated attribute of the route. The announcement of the submission of this revised draft is below. regards, Geoff A new version of I-D, draft-ietf-sidr-roa-validation-07.txt has been successfully submitted by Geoff Huston and posted to the IETF repository. Filename: draft-ietf-sidr-roa-validation Revision: 07 Title: Validation of Route Origination using the Resource Certificate PKI and ROAs Creation_date: 2010-10-10 WG ID: sidr Number_of_pages: 10 Abstract: This document defines the semantics of a Route Origin Authorization (ROA) in terms of the context of an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol. From Sandra.Murphy@cobham.com Mon Oct 11 12:27:55 2010 Return-Path: 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 1752C3A6B2B for ; Mon, 11 Oct 2010 12:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.472 X-Spam-Level: X-Spam-Status: No, score=-102.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XotDlZ9PCnCM for ; Mon, 11 Oct 2010 12:27:52 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id B3E113A6B65 for ; Mon, 11 Oct 2010 12:27:50 -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 o9BJT2Nt010311 for ; Mon, 11 Oct 2010 14:29:02 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o9BJT2Hh014152 for ; Mon, 11 Oct 2010 14:29:02 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.93]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Oct 2010 15:29:02 -0400 Date: Mon, 11 Oct 2010 15:29:02 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 11 Oct 2010 19:29:02.0400 (UTC) FILETIME=[8F761C00:01CB697A] Subject: [sidr] upcoming important dates for IETF 79 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: , X-List-Received-Date: Mon, 11 Oct 2010 19:27:55 -0000 Here are upcoming important dates for the Beijing meeting: 2010-10-15 (Friday): Final agenda to be published. 2010-10-18 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (24:00 UTC) 2010-10-25 (Monday): Internet Draft final submission cut-off by 17:00 PT (24:00 UTC) 2010-10-27 (Wednesday): Draft Working Group agendas due by 17:00 PT (24:00 UTC) 2010-10-29 (Friday): Early Bird registration and payment cut-off at 17:00 PT (24:00 UTC) --Sandy From christopher.morrow@gmail.com Mon Oct 11 12:39:14 2010 Return-Path: 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 00B573A6BA1 for ; Mon, 11 Oct 2010 12:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.213 X-Spam-Level: X-Spam-Status: No, score=-102.213 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsetL+lUiv6m for ; Mon, 11 Oct 2010 12:39:11 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 4F7B83A6BB1 for ; Mon, 11 Oct 2010 12:38:58 -0700 (PDT) Received: by yxp4 with SMTP id 4so1053378yxp.31 for ; Mon, 11 Oct 2010 12:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=r8RtL4otM6Icssi4bZoxvY+s9oVJDaNR5nAAPazQK9w=; b=A0/qs+3YfUHNGr/J/m3MrFOgbt8PVyWNj7QfqmaQzdtbz6ZRFy1Lsv/QXYDGErqzMx J2jeD/wR2gNssbm9Qhf0luJDO2aDKZ1R3yC0QfjF6tBPWNdLHKybEMkP/vLq3/e6Bk/e qgYU141fLLHSJLVuNjR6aMJp1vHcyvUhGJMbc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=sve/OXdMcNzytXFNXQ//s/a04FTufbdKvLssnU/7eKW1M9+XSYtYUPwGiO911XkuT9 XFX0U9FtZ3TVBciTfXSy4zYyZ7DD0GZeBNF3dfcaNp3h3emF6ex7rXAePgVI+wc4RRX+ GKB0TCrgD+YzR5N6MvcFH1AoVnIPS3DECZPeU= MIME-Version: 1.0 Received: by 10.42.214.10 with SMTP id gy10mr2398622icb.370.1286825903356; Mon, 11 Oct 2010 12:38:23 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.120.195 with HTTP; Mon, 11 Oct 2010 12:38:23 -0700 (PDT) In-Reply-To: References: Date: Mon, 11 Oct 2010 15:38:23 -0400 X-Google-Sender-Auth: XF33pPKxanaLI6gQJiP2Fa36atI Message-ID: From: Christopher Morrow To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [sidr] WG Adoption: draft-weiler-sidr-publication-00 (changed subject sorry for the spamz) 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: , X-List-Received-Date: Mon, 11 Oct 2010 19:39:14 -0000 Hey, it was 14 days... (or more) no one dissented WG-item it is! Sam, could you please spin a re-titled -00 into the process machine? -Chris (wg-co-chair-airplane-neck-pillow-on) On Tue, Sep 14, 2010 at 3:14 PM, Christopher Morrow wrote: > (just a change in subject to make things more clear) > > vote early, vote often. > > thanks > -Chris > (wg-co-char bowtie on) > > On Tue, Sep 14, 2010 at 3:09 PM, Christopher Morrow > wrote: >> today is graveyard day... >> >> Could the WG mailing-list folks discuss this for adoption please, >> given no more discussion in the next 14 days we'll move ahead with >> adopting it, I think. >> >> -Chris >> (wg-co-chair tie on) >> >> On Sat, Jul 31, 2010 at 10:28 AM, Warren Kumari wrot= e: >>> Hi there all, >>> >>> I am asking =A0 that >>> A Publication Protocol for the Resource Public Key Infrastructure >>> (RPKI) >>> draft-weiler-sidr-publication-00.txt ( http://tools.ietf.org/html/draft= -weiler-sidr-publication-00 ) >>> >>> become a working group item. >>> >>> W >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>> >> > From kotikalapudi.sriram@nist.gov Mon Oct 11 19:08:45 2010 Return-Path: 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 9A63D3A67B8 for ; Mon, 11 Oct 2010 19:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.435 X-Spam-Level: X-Spam-Status: No, score=-6.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 ISZmKaNPHj8I for ; Mon, 11 Oct 2010 19:08:44 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 621733A6863 for ; Mon, 11 Oct 2010 19:08:44 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o9C29iU6006985; Mon, 11 Oct 2010 22:09:44 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 11 Oct 2010 22:09:43 -0400 From: "Sriram, Kotikalapudi" To: Sandra Murphy , "sidr@ietf.org" Date: Mon, 11 Oct 2010 22:06:26 -0400 Thread-Topic: [sidr] WG adoption of draft-reynolds-rpki-ltamgmt-01.txt Thread-Index: Actej9/8LRXXKJ9pQzunrwm/8VaBtQLIjOkD Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Subject: Re: [sidr] WG adoption of draft-reynolds-rpki-ltamgmt-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: , X-List-Received-Date: Tue, 12 Oct 2010 02:08:45 -0000 I support adoption of this draft as a WG item. Sriram ________________________________________ From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] On Behalf Of Sandra Murphy [Sandra.Murphy@sparta.com] Sent: Monday, September 27, 2010 6:03 PM To: sidr@ietf.org Subject: [sidr] WG adoption of draft-reynolds-rpki-ltamgmt-01.txt The wg chairs have received a request that the working group adopt the draft "Local Trust Anchor Management for the Resource Public Key Infrastructure" as a wg work item. This material of this draft was presented at IETF 75 (http://www.ietf.org/proceedings/75/slides/sidr-3/sidr-3_files/v3_document.htm) IETF 76 (http://www.ietf.org/proceedings/76/slides/sidr-11.pdf) and IETF 77 (http://www.ietf.org/proceedings/77/slides/sidr-6/sidr-6_files/v3_document.htm) A draft was requested by the audience at IETF 75. The -00 version was submitted in Mar 2010 and wg adoption was requested. Response to that request did not indicate wg consensus - the responses were positive but there were only three replies. A new version of the draft is available at http://www.ietf.org/id/draft-reynolds-rpki-ltamgmt-01.txt http://tools.ietf.org/html/draft-reynolds-rpki-ltamgmt-01 The authors request that the wg consider this new version again for wg adoption. Recall that active support for adoption is necessary for the wg chairs to judge acceptance as a working group work item, so silence works against adoption. The wg chairs also want to know who would be willing to work on the draft. The wg chairs also want to know if you oppose adoption. Please respond to the list, giving your recommendation for or against adoption of the draft as a wg work item as well as your intention to work on the draft if adopted. The call for adoption will end in two weeks on 11 Oct 2010. --Sandy, wg chair bowler on _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From Wesley.E.George@sprint.com Tue Oct 12 07:58:38 2010 Return-Path: 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 CF3223A68E4 for ; Tue, 12 Oct 2010 07:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.126 X-Spam-Level: X-Spam-Status: No, score=-5.126 tagged_above=-999 required=5 tests=[AWL=1.473, 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 2UslH57CUq+4 for ; Tue, 12 Oct 2010 07:58:38 -0700 (PDT) Received: from VA3EHSOBE009.bigfish.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by core3.amsl.com (Postfix) with ESMTP id BFD043A69A7 for ; Tue, 12 Oct 2010 07:58:37 -0700 (PDT) Received: from mail17-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.8; Tue, 12 Oct 2010 14:59:51 +0000 Received: from mail17-va3 (localhost.localdomain [127.0.0.1]) by mail17-va3-R.bigfish.com (Postfix) with ESMTP id A7F571AE0097; Tue, 12 Oct 2010 14:59:51 +0000 (UTC) X-SpamScore: -53 X-BigFish: VS-53(zzbb2dK542N1432N98dN4015L9371Pzz1202hzz8275bh8275dh1033ILz2fh87h2a8h61h) X-Spam-TCS-SCL: 0:0 X-FB-DOMAIN-IP-MATCH: fail Received: from mail17-va3 (localhost.localdomain [127.0.0.1]) by mail17-va3 (MessageSwitch) id 1286895591521779_26855; Tue, 12 Oct 2010 14:59:51 +0000 (UTC) Received: from VA3EHSMHS025.bigfish.com (unknown [10.7.14.240]) by mail17-va3.bigfish.com (Postfix) with ESMTP id 7B2C81190056; Tue, 12 Oct 2010 14:59:51 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by VA3EHSMHS025.bigfish.com (10.7.99.35) with Microsoft SMTP Server (TLS) id 14.0.482.44; Tue, 12 Oct 2010 14:59:50 +0000 Received: from PDAWEH03.ad.sprint.com (PDAWEH03.corp.sprint.com [144.226.110.91]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id o9CExmhm027916 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Oct 2010 09:59:48 -0500 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PDAWEH03.ad.sprint.com ([fe80::ad53:3472:c852:cd45%11]) with mapi id 14.01.0218.012; Tue, 12 Oct 2010 09:59:48 -0500 From: "George, Wes E IV [NTK]" To: Christopher Morrow , "sidr@ietf.org" , Sandra Murphy Thread-Topic: [sidr] Call for WG Adoption - draft-pmohapat-sidr-origin-validation-signaling-00 Thread-Index: ActmixjkrlChObN5Q+m/qE5a/ErzfgDkvXcg Date: Tue, 12 Oct 2010 14:59:47 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E6699@PLSWM12A.ad.sprint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.153.203.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Reverse-DNS: smtpls1.sprint.com Subject: Re: [sidr] Call for WG Adoption - draft-pmohapat-sidr-origin-validation-signaling-00 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: , X-List-Received-Date: Tue, 12 Oct 2010 14:58:38 -0000 support Thanks, Wes George > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Christopher Morrow > Sent: Thursday, October 07, 2010 9:49 PM > To: sidr@ietf.org; Sandra Murphy; Chris Morrow > Subject: Re: [sidr] Call for WG Adoption - draft-pmohapat-sidr-origin- > validation-signaling-00 > > On Thu, Oct 7, 2010 at 9:49 PM, Christopher Morrow > wrote: > > Howdy WG-folk, > > Pradosh has asked that we consider: > > signaling-00> > > > > for adoption in SIDR, could we hear back before 10/22/2010 pls? > > > > -Chris > > (wg-chair-belt-buckle =3D=3D on) > > s/chair/co-chair/ > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr ________________________________ This e-mail may contain Sprint Nextel proprietary information intended for = the sole use of the recipient(s). Any use by others is prohibited. If you a= re not the intended recipient, please contact the sender and delete all cop= ies of the message. From turners@ieca.com Tue Oct 12 11:04:54 2010 Return-Path: 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 D3DE93A6910 for ; Tue, 12 Oct 2010 11:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOQzZukbZ+ZS for ; Tue, 12 Oct 2010 11:04:53 -0700 (PDT) Received: from smtp111.biz.mail.re2.yahoo.com (smtp111.biz.mail.re2.yahoo.com [66.196.116.96]) by core3.amsl.com (Postfix) with SMTP id C20133A68DA for ; Tue, 12 Oct 2010 11:04:53 -0700 (PDT) Received: (qmail 25611 invoked from network); 12 Oct 2010 18:06:05 -0000 Received: from thunderfish.local (turners@129.174.97.34 with plain) by smtp111.biz.mail.re2.yahoo.com with SMTP; 12 Oct 2010 11:06:05 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: ZqYU_FgVM1njWI.TlLa6aBcp29forE_0EIDE8dD_Ovs_OeO AS3ywRVhs1zNVWILiV6L84dUHPh7w_hhgZWQ6irnTT3YM8b33ZVNAlq91199 WUZ6imd6xCAkRZ7QsKt_FsXbQW2V2WfA8iwOooqDObpD2l4EEBYjLHpQTp_L BMWAt_WhNNkEgyL03ILy7QHFGI4p7mYOPVVapFOkP8s_dFUXK_AslswD11vF D9jEuvlW5qaSLkn9hoGLV1J5uJg.orV4lAMFFM9tyXJvDoKyy.Jwg4BJ_r3b DG6ZsV4HBUUE_qPvkC.rFlb4R0e_WhgbYNoJ8dN7rk3rxO0e2EV9ZCkpogpc P_oyCLGbFjY62y3qTU_SkzMxLgoZEG1umCJ4AbZ9hgRQqUFN3k_RMSm.npWu qXZPCaaOb4PtzvA9vRGdH5O7sGFfAhyrkL9ACtVTyWK1rO3fx4dFkB8TV X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CB4A38C.9060104@ieca.com> Date: Tue, 12 Oct 2010 14:06:04 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: sidr@ietf.org References: <20101008080002.50A8D3A6827@core3.amsl.com> In-Reply-To: <20101008080002.50A8D3A6827@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] I-D Action:draft-ietf-sidr-rpki-algs-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: , X-List-Received-Date: Tue, 12 Oct 2010 18:04:54 -0000 I think this version looks great with one exception. I believe the last paragraph in Section 5 (repeated below for convenience) should be deleted: In anticipation of a potential need to transition to stronger cryptographic algorithms in the future, CAs and RPs SHOULD be able to generate and verify RSASSA-PKCS1-v1_5 signatures using the SHA-512 hash algorithm and RSA key sizes of 3072 and 4096 bits. I think we should require that implementations support algorithm agility, but I'd like to not presuppose the algorithms and key sizes for something that's going to happen 5-8 years down the road. Who knows maybe SHA3 will be so whiz bang maybe we'll want to move to it. If we added the following as a security consideration I believe the intent would be satisfied: Implementations MUST support algorithm agility. spt Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. > > > Title : A Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure > Author(s) : G. Huston > Filename : draft-ietf-sidr-rpki-algs-03.txt > Pages : 6 > Date : 2010-10-08 > > This document specifies the algorithms, algorithms' parameters, > asymmetric key formats, asymmetric key size and signature format for > the Resource Public Key Infrastructure subscribers that generate > digital signatures on certificates, Certificate Revocation Lists, and > signed objects as well as for the Relying Parties (RPs) that verify > these digital signatures. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-algs-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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From gih@apnic.net Tue Oct 12 14:28:29 2010 Return-Path: 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 AA3833A6A93 for ; Tue, 12 Oct 2010 14:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.131 X-Spam-Level: X-Spam-Status: No, score=-92.131 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_AU=0.377, HELO_EQ_CPE=0.5, HOST_EQ_AU=0.327, HOST_EQ_CPE=0.979, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ndp0FJZXfnQy for ; Tue, 12 Oct 2010 14:28:28 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id B0C873A6A8F for ; Tue, 12 Oct 2010 14:28:26 -0700 (PDT) Received: from cpe-124-179-79-69.lns5.cht.bigpond.net.au (CPE-124-179-79-69.lns5.cht.bigpond.net.au [124.179.79.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 79F61D5988; Wed, 13 Oct 2010 07:29:29 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: <4CB4A38C.9060104@ieca.com> Date: Wed, 13 Oct 2010 08:29:26 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101008080002.50A8D3A6827@core3.amsl.com> <4CB4A38C.9060104@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1081) Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action:draft-ietf-sidr-rpki-algs-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: , X-List-Received-Date: Tue, 12 Oct 2010 21:28:29 -0000 Hi Sean, That last paragraph was inserted in response to this posting from David = Cooper http://www.ietf.org/mail-archive/web/sidr/current/msg01067.html At the time David's proposed text attracted no further comment, and I = folded it into the subsequent rev of the draft. I understand that you are proposing that we now drop this text from the = next rev of the draft. I'm happy to do so, unless of course others pipe up to your proposal = with a contrary opinion. Geoff On 13/10/2010, at 5:06 AM, Sean Turner wrote: > I think this version looks great with one exception. I believe the = last paragraph in Section 5 (repeated below for convenience) should be = deleted: >=20 > In anticipation of a potential need to transition to stronger > cryptographic algorithms in the future, CAs and RPs SHOULD be able to > generate and verify RSASSA-PKCS1-v1_5 signatures using the SHA-512 > hash algorithm and RSA key sizes of 3072 and 4096 bits. >=20 > I think we should require that implementations support algorithm = agility, but I'd like to not presuppose the algorithms and key sizes for = something that's going to happen 5-8 years down the road. Who knows = maybe SHA3 will be so whiz bang maybe we'll want to move to it. If we = added the following as a security consideration I believe the intent = would be satisfied: >=20 > Implementations MUST support algorithm agility. >=20 > spt >=20 > Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Secure Inter-Domain Routing Working = Group of the IETF. >> Title : A Profile for Algorithms and Key Sizes for use = in the Resource Public Key Infrastructure >> Author(s) : G. Huston >> Filename : draft-ietf-sidr-rpki-algs-03.txt >> Pages : 6 >> Date : 2010-10-08 >> This document specifies the algorithms, algorithms' parameters, >> asymmetric key formats, asymmetric key size and signature format for >> the Resource Public Key Infrastructure subscribers that generate >> digital signatures on certificates, Certificate Revocation Lists, and >> signed objects as well as for the Relying Parties (RPs) that verify >> these digital signatures. >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-algs-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. >> = ------------------------------------------------------------------------ >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr -- Geoff Huston Chief Scientist, APNIC +61 7 3858 3100 gih@apnic.net From kent@bbn.com Tue Oct 12 14:58:44 2010 Return-Path: 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 A22523A6A9D for ; Tue, 12 Oct 2010 14:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.405 X-Spam-Level: X-Spam-Status: No, score=-102.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N87J484cvw0X for ; Tue, 12 Oct 2010 14:58:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id D2D7F3A6864 for ; Tue, 12 Oct 2010 14:58:43 -0700 (PDT) Received: from dhcp89-089-072.bbn.com ([128.89.89.72]:49238) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P5mt3-000M9F-5y; Tue, 12 Oct 2010 17:59:57 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 12 Oct 2010 17:47:58 -0400 To: Geoff Huston From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] responses to CP comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 21:58:44 -0000 At 2:31 AM +1100 10/9/10, Geoff Huston wrote: >On 09/10/2010, at 2:15 AM, Stephen Kent wrote: >... > > >> Sean asked us to add the trademark text, because it is common in >>CPs. I agree that it is inappropriate to impose a burden of this >>sort on the orgs that we are asking to act as CAs here. Not >>mentioning this issue does not provide "cover" for these orgs. >>Saying that a CA that employs the recommended name gen technique, >>or an analogous mechanism, gets a pass, may provide cover, so I >>think it is worthwhile. But, if most WG members are more >>comfortable with deleting this, let us know, and we'll remove it. >> > >I, for one, am more comfortable with deleting this. > >thanks > > Geoff OK, by popular demand (since Randy and Geoff are unarguably popular) we'll remove the paragraph that talks about trademarks in names. Steve p.s. I reserve the right to say "I told you so" later :-). From david.cooper@nist.gov Tue Oct 12 15:14:18 2010 Return-Path: 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 30ED53A6AAD for ; Tue, 12 Oct 2010 15:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.278 X-Spam-Level: X-Spam-Status: No, score=-6.278 tagged_above=-999 required=5 tests=[AWL=0.321, 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 19Rz2nhGOl3F for ; Tue, 12 Oct 2010 15:14:16 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 916853A6A87 for ; Tue, 12 Oct 2010 15:14:16 -0700 (PDT) Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o9CMFLsx024342; Tue, 12 Oct 2010 18:15:21 -0400 Message-ID: <4CB4DDF9.1020808@nist.gov> Date: Tue, 12 Oct 2010 18:15:21 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100921 Mandriva/3.0.8-0.1mdv2010.1 (2010.1) Thunderbird/3.0.8 MIME-Version: 1.0 To: Sean Turner References: <20101008080002.50A8D3A6827@core3.amsl.com> <4CB4A38C.9060104@ieca.com> In-Reply-To: <4CB4A38C.9060104@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action:draft-ietf-sidr-rpki-algs-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: , X-List-Received-Date: Tue, 12 Oct 2010 22:14:18 -0000 Sean, While a generic statement that implementations must support algorithm agility is a good one, the RPKI can't transition to a new algorithm until everyone has implemented support for the specific new algorithm and experience has shown that getting everyone to implement that support may take many years. In the Federal PKI, we began to discuss the need to move from SHA-1 to SHA-256 about seven years ago, yet some agencies are still saying that they cannot make the transition since they have applications that don't support SHA-256. So, I think it is reasonable to begin preparing for a transition at least 5-8 years before the transition needs to happen. In the case of the RPKI, it may be that 2048-bit RSA with SHA-256 will be acceptable for so long that by the time there is a need to transition to something different the consensus will be that the transition should be to something entirely different (e.g., ECDSA with SHA-3). However, the current text is intended to suggest that CAs and RPs be prepared to use stronger cryptography in a way that minimizes the extra effort for those implementations. It is much easier for an application that can sign/verify 2048-bit RSA to also support 3072-bit RSA than to also support ECDSA. This draft doesn't presuppose that the RPKI will move to 3072-bit RSA, it simply helps to ease the transition path to a likely choice for a transition to stronger cryptography by mainly encouraging CAs and RPs not to hard code their applications to only support one specific RSA key length. If in the future the decision is made to transition to something different (ECDSA, SHA-3, RSASSA-PSS) then this text hasn't really caused any harm, but it will have to be accepted that such a transition will require significantly more time that would be required for a transition to algorithms/key lengths more closely related to those that are currently required. Dave On 10/12/2010 02:06 PM, Sean Turner wrote: > I think this version looks great with one exception. I believe the > last paragraph in Section 5 (repeated below for convenience) should be > deleted: > > In anticipation of a potential need to transition to stronger > cryptographic algorithms in the future, CAs and RPs SHOULD be able to > generate and verify RSASSA-PKCS1-v1_5 signatures using the SHA-512 > hash algorithm and RSA key sizes of 3072 and 4096 bits. > > I think we should require that implementations support algorithm > agility, but I'd like to not presuppose the algorithms and key sizes > for something that's going to happen 5-8 years down the road. Who > knows maybe SHA3 will be so whiz bang maybe we'll want to move to it. > If we added the following as a security consideration I believe the > intent would be satisfied: > > Implementations MUST support algorithm agility. > > spt > > Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. >> >> >> Title : A Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure >> Author(s) : G. Huston >> Filename : draft-ietf-sidr-rpki-algs-03.txt >> Pages : 6 >> Date : 2010-10-08 >> >> This document specifies the algorithms, algorithms' parameters, >> asymmetric key formats, asymmetric key size and signature format for >> the Resource Public Key Infrastructure subscribers that generate >> digital signatures on certificates, Certificate Revocation Lists, and >> signed objects as well as for the Relying Parties (RPs) that verify >> these digital signatures. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-algs-03.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> From kent@bbn.com Wed Oct 13 07:57:52 2010 Return-Path: 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 B8F213A6956 for ; Wed, 13 Oct 2010 07:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.481 X-Spam-Level: X-Spam-Status: No, score=-101.481 tagged_above=-999 required=5 tests=[AWL=-0.741, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExTA7L+9v5su for ; Wed, 13 Oct 2010 07:57:51 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id B49303A68FD for ; Wed, 13 Oct 2010 07:57:51 -0700 (PDT) Received: from dhcp89-089-072.bbn.com ([128.89.89.72]:49253) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P62nM-0008Pi-6X for sidr@ietf.org; Wed, 13 Oct 2010 10:59:08 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 13 Oct 2010 10:59:04 -0400 To: sidr@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [sidr] single-use and multi-use EE certs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 14:57:52 -0000 Folks, The repository structure doc devotes a moderate amount of text to accommodate what are termed "multi-use" EE certs. I'd like to simplify these docs if we can, by dropping special repository treatment for multi-use certs, if there are no strong objections. Recall that almost almost all EE certs used in the RPKI are contained in CMS signed objects (that conform to the newly adopted RPKI signed object spec). The simplest model for EE certs in this context is to maintain a 1-1 correspondence between the EE cert and the object that is verified using the cert. That way one can revoke the EE cert and kill the associated object, with no collateral damage :-). Also, because of the limited scope of the cert, one can dispose of the private key associated with the cert, as soon as the object in question has been signed. A multi-use EE cert is a cert used to verify more than one RPKI signed object. In the RPKI context this means that, if one revokes a multi-use cert, all of the objects that are verified using that cert are killed when the cert is revoked. Thus one needs to choose carefully which set of objects should be verified under a multi-use cert. (Note that this is an EE cert; all CA certs are intrinsically multi-use, and are treated differently in the RPKI repository system.) If the objects to be verified under a multi-use cert are created and signed over time, the private key cannot be destroyed until the last of these objects has been signed. I can imagine two circumstances that may motivate employing a multi-use EE cert vs. a set of single-use EE certs: 1. there may be a set of objects that "fate share" and thus if any one needs to be revoked, all will be revoked. An example might be a set of ROAs that are perceived to be linked in some fate sharing fashion. 2. a series of object instances may be signed over time, and there a perception that revocation of any instance of the object is unlikely (prior to object expiration). The obvious example here is a sequence of manifests, where each manifest is replaced on a daily basis, as a consequence of daily CRL issuance. By employing a multi-use cert in either of these cases, one avoids the need to generate multiple, single-use certs (and associated key pairs), a possible performance concern. However, generating a cert is not an expensive process. Key pair generation is fairly quick these days. Filling in the data structure for the cert is very quick, as is DER encoding. Signing the message is also fast. So, I don't think the overhead of cert generation ought to be a deciding factor here, unless we are talking about 100 or more objects at a time. (For manifest instances, this clearly is not a consideration, since each manifest is generated and signed at a different time.) The first case above does not seem to merit the special treatment that the repository structure document calls out for multi-use EE certs. I say this because ROAs live at a publication point controlled by the CA (instance) that issued the EE cert in each ROA. Thus one would not store ROAs differently whether a single or multi-use EE cert were used to them. The second case above also does not seem to merit the special treatment that the repository structure document calls out for multi-use EE certs. A manifest lives at a publication point for a set of signed products associated with a CA instance, and the manifest spec specifically prohibits the EE cert associated with it from appearing as a discrete object in the repository. So, again, the location for a manifest in the repository system would not change based on whether a single or multi-use cert were employed with it. So, it is not clear to me that we need to call out special treatment for single vs. multi-use EE certs in the repository spec, based on the kinds of signed objects that we have defined so far. If we agree to eliminate this special treatment, the spec becomes simpler. I am not opposed to describing single vs. multi-use EEC certs in the cert profile. In that doc there is relatively little text devoted to these two types of certs, and I don't see a problem with what is said there. Steve From tim@ripe.net Wed Oct 13 08:58:17 2010 Return-Path: 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 0C80E3A6A9F for ; Wed, 13 Oct 2010 08:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[AWL=-0.821, BAYES_00=-2.599, MANGLED_EMAIL=2.3] 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 ovMWvZXyOr5J for ; Wed, 13 Oct 2010 08:58:15 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 4539E3A697B for ; Wed, 13 Oct 2010 08:58:15 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1P63jh-0000J7-HK; Wed, 13 Oct 2010 17:59:30 +0200 Received: from timbru.vpn.ripe.net ([193.0.21.62] helo=guest52.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1P63jh-0001nc-Ef; Wed, 13 Oct 2010 17:59:25 +0200 Message-ID: <4CB5D75D.7020406@ripe.net> Date: Wed, 13 Oct 2010 17:59:25 +0200 From: Tim Bruijnzeels User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Stephen Kent References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719c3087a817b88caddba7bafd495903831 X-RIPE-Spam-Level: -- X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719c3087a817b88caddba7bafd495903831 Cc: sidr@ietf.org Subject: Re: [sidr] single-use and multi-use EE certs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 15:58:17 -0000 Hi Steve, all, On 10/13/10 4:59 PM, Stephen Kent wrote: > Folks, > > The repository structure doc devotes a moderate amount of text to > accommodate what are termed "multi-use" EE certs. I'd like to simplify > these docs if we can, by dropping special repository treatment for > multi-use certs, if there are no strong objections. > Actually... This ship may have sailed a long time ago. I was not involved in the early stages of this. So I am not aware of the arguments that may have been raised in the past to come up with multi-use EEs in the first place.. but, bottom-line: I think it would be simplest if the drop multi-use EEs were dropped altogether. As you mention the overhead for single use is not that big. > > > I can imagine two circumstances that may motivate employing a multi-use > EE cert vs. a set of single-use EE certs: > > 1. there may be a set of objects that "fate share" and thus if any > one needs to be revoked, all will be revoked. An example might be a set > of ROAs that are perceived to be linked in some fate sharing fashion. > I think it's better to implement the knowledge about fate sharing elsewhere, and then just revoke em all as needed. Ideas about which objects should be fate sharing may change over time and with multi-use changes can not be made after object creation: one cannot de-fate-share an existing object. > 2. a series of object instances may be signed over time, and there a > perception that revocation of any instance of the object is unlikely > (prior to object expiration). The obvious example here is a sequence of > manifests, where each manifest is replaced on a daily basis, as a > consequence of daily CRL issuance. > Okay, but I would actually still prefer single use here: it allows me to throw away the key. In any case I think simplification of the standards (and CA software, and validators) outweighs the overhead of using single use EEs here. But as I said in the disclaimer, I may be overlooking other good reasons for the multi-use here... Regards Tim From turners@ieca.com Wed Oct 13 10:04:16 2010 Return-Path: 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 B8A2A3A6876 for ; Wed, 13 Oct 2010 10:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.264 X-Spam-Level: X-Spam-Status: No, score=-102.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gC-b6d1yeLb for ; Wed, 13 Oct 2010 10:04:15 -0700 (PDT) Received: from smtp111.biz.mail.sp1.yahoo.com (smtp111.biz.mail.sp1.yahoo.com [69.147.92.224]) by core3.amsl.com (Postfix) with SMTP id 59BDE3A67B7 for ; Wed, 13 Oct 2010 10:04:15 -0700 (PDT) Received: (qmail 54060 invoked from network); 13 Oct 2010 17:05:32 -0000 Received: from st-9f65cc9fecf4.nat-wireless.gmu.edu (turners@129.174.97.34 with plain) by smtp111.biz.mail.sp1.yahoo.com with SMTP; 13 Oct 2010 10:05:32 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: CziksbwVM1kn3PW1VUwheYRNow3d2SXcCcg_gssoBPSRwzM 4xKtgq00Y1yxcHCQSi5YD9Wb.1nhD1yx3MgEAGHzpTB1ZKnewrfHb3UlYwfa qDGvjt1hEhVwdyt2qCMJgl42J2TxKDxEWD2reyEblyAHKrgxK1IosAlc2hRx lb4x6Frav9OnDnIhMZCpmysZaHjtShAIDLp4LJyeHbUVkJ9WH7yr0s0fCa4N Ci6Ww42HDN6p6zMX4FEg3xtsCmSiT_McO9hD.ComDTKQr0o_bn9LP8DT6de2 P3w9T4Puf1V4dVGaACH7YLXqugp8o0SWvfR59.XM3qXBfpW0_i6wwZQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CB5E6DA.5070000@ieca.com> Date: Wed, 13 Oct 2010 13:05:30 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "David A. Cooper" References: <20101008080002.50A8D3A6827@core3.amsl.com> <4CB4A38C.9060104@ieca.com> <4CB4DDF9.1020808@nist.gov> In-Reply-To: <4CB4DDF9.1020808@nist.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action:draft-ietf-sidr-rpki-algs-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: , X-List-Received-Date: Wed, 13 Oct 2010 17:04:16 -0000 David A. Cooper wrote: > Sean, > > While a generic statement that implementations must support algorithm > agility is a good one, the RPKI can't transition to a new algorithm > until everyone has implemented support for the specific new algorithm > and experience has shown that getting everyone to implement that support > may take many years. In the Federal PKI, we began to discuss the need > to move from SHA-1 to SHA-256 about seven years ago, yet some agencies > are still saying that they cannot make the transition since they have > applications that don't support SHA-256. So, I think it is reasonable > to begin preparing for a transition at least 5-8 years before the > transition needs to happen. I 100% feel you pain and I completely agree that we should prepare for a transition *now* by requiring algorithm agility. > In the case of the RPKI, it may be that 2048-bit RSA with SHA-256 will > be acceptable for so long that by the time there is a need to transition > to something different the consensus will be that the transition should > be to something entirely different (e.g., ECDSA with SHA-3). However, > the current text is intended to suggest that CAs and RPs be prepared to > use stronger cryptography in a way that minimizes the extra effort for > those implementations. It is much easier for an application that can > sign/verify 2048-bit RSA to also support 3072-bit RSA than to also > support ECDSA. Definitely not arguing that moving to a large key size for RSA is harder than moving to another signature algorithm. > This draft doesn't presuppose that the RPKI will move to 3072-bit RSA, > it simply helps to ease the transition path to a likely choice for a > transition to stronger cryptography by mainly encouraging CAs and RPs > not to hard code their applications to only support one specific RSA key > length. If in the future the decision is made to transition to > something different (ECDSA, SHA-3, RSASSA-PSS) then this text hasn't > really caused any harm, but it will have to be accepted that such a > transition will require significantly more time that would be required > for a transition to algorithms/key lengths more closely related to those > that are currently required. I used the word "presuppose" because it's a SHOULD requirement to support 3072-bit and 4096-bit RSA and SHA-512. That means implementations need to support these key sizes and algorithms unless they've got a good reason not too. I think we have the same goal: require algorithm agility. I think we can do that with a simple one line sentence in the security considerations: Implementations MUST support algorithm agility. or Implementations MUST NOT be hard wired to support one hash algorithm or modulus size. If we want to say something encouraging about algorithm agility then maybe something like: For example, if an implementations supports SHA-512 (code available in [draft-eastlake-sha2b]), then that implementation actually supports both SHA-384 and SHA-512 because SHA-384 and SHA-512 perform identical processing on message blocks and differ only in how initial hash value is initialized and how they produce their final output. Likewise, not hard wiring RSA to a 2048-bit key size allows an implementation to support 3072-bit and 4096-bit RSA because the algorithm and key format are identical to 2048-bit RSA modulo the size of the fields. (or something like that) spt > Dave > > On 10/12/2010 02:06 PM, Sean Turner wrote: >> I think this version looks great with one exception. I believe the >> last paragraph in Section 5 (repeated below for convenience) should be >> deleted: >> >> In anticipation of a potential need to transition to stronger >> cryptographic algorithms in the future, CAs and RPs SHOULD be able to >> generate and verify RSASSA-PKCS1-v1_5 signatures using the SHA-512 >> hash algorithm and RSA key sizes of 3072 and 4096 bits. >> >> I think we should require that implementations support algorithm >> agility, but I'd like to not presuppose the algorithms and key sizes >> for something that's going to happen 5-8 years down the road. Who >> knows maybe SHA3 will be so whiz bang maybe we'll want to move to it. >> If we added the following as a security consideration I believe the >> intent would be satisfied: >> >> Implementations MUST support algorithm agility. >> >> spt >> >> Internet-Drafts@ietf.org wrote: >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Secure Inter-Domain Routing Working >>> Group of the IETF. >>> >>> >>> Title : A Profile for Algorithms and Key Sizes for use >>> in the Resource Public Key Infrastructure >>> Author(s) : G. Huston >>> Filename : draft-ietf-sidr-rpki-algs-03.txt >>> Pages : 6 >>> Date : 2010-10-08 >>> >>> This document specifies the algorithms, algorithms' parameters, >>> asymmetric key formats, asymmetric key size and signature format for >>> the Resource Public Key Infrastructure subscribers that generate >>> digital signatures on certificates, Certificate Revocation Lists, and >>> signed objects as well as for the Relying Parties (RPs) that verify >>> these digital signatures. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-algs-03.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> > From kent@bbn.com Wed Oct 13 10:19:39 2010 Return-Path: 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 D97593A684F for ; Wed, 13 Oct 2010 10:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.389 X-Spam-Level: X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g12YCC9ob+C0 for ; Wed, 13 Oct 2010 10:19:38 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 87AB83A697A for ; Wed, 13 Oct 2010 10:19:38 -0700 (PDT) Received: from dhcp89-089-072.bbn.com ([128.89.89.72]:49267) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P650Y-000BYd-37; Wed, 13 Oct 2010 13:20:54 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4CB4DDF9.1020808@nist.gov> References: <20101008080002.50A8D3A6827@core3.amsl.com> <4CB4A38C.9060104@ieca.com> <4CB4DDF9.1020808@nist.gov> Date: Wed, 13 Oct 2010 13:20:51 -0400 To: "David A. Cooper" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action:draft-ietf-sidr-rpki-algs-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: , X-List-Received-Date: Wed, 13 Oct 2010 17:19:39 -0000 At 6:15 PM -0400 10/12/10, David A. Cooper wrote: >Sean, > >While a generic statement that implementations must support >algorithm agility is a good one, the RPKI can't transition to a new >algorithm until everyone has implemented support for the specific >new algorithm and experience has shown that getting everyone to >implement that support may take many years. In the Federal PKI, we >began to discuss the need to move from SHA-1 to SHA-256 about seven >years ago, yet some agencies are still saying that they cannot make >the transition since they have applications that don't support >SHA-256. So, I think it is reasonable to begin preparing for a >transition at least 5-8 years before the transition needs to happen. If we have a clear idea of what that transition will be, I agree. But, we're not there yet. >In the case of the RPKI, it may be that 2048-bit RSA with SHA-256 >will be acceptable for so long that by the time there is a need to >transition to something different the consensus will be that the >transition should be to something entirely different (e.g., ECDSA >with SHA-3). However, the current text is intended to suggest that >CAs and RPs be prepared to use stronger cryptography in a way that >minimizes the extra effort for those implementations. It is much >easier for an application that can sign/verify 2048-bit RSA to also >support 3072-bit RSA than to also support ECDSA. It may or may not be easy. If one uses hardware and the hardware tops out at 2048-bit RSA, then it's a big problem. If the same hardware already supports ECDSA, then a transition to that suite would be easier than a transition to 3/4K RSA. If we suggest, at this very early date, that the likely next alg suite is 3K or 4K RSA, we may cause folks to make poor choices for crypto implementations. That's why I think it is preferable to say nothing about specific algs at this time. >This draft doesn't presuppose that the RPKI will move to 3072-bit >RSA, it simply helps to ease the transition path to a likely choice >for a transition to stronger cryptography by mainly encouraging CAs >and RPs not to hard code their applications to only support one >specific RSA key length. If in the future the decision is made to >transition to something different (ECDSA, SHA-3, RSASSA-PSS) then >this text hasn't really caused any harm, but it will have to be >accepted that such a transition will require significantly more time >that would be required for a transition to algorithms/key lengths >more closely related to those that are currently required. You use the phrase "likely choice" above, but I don't think we have enough info to judge 3/4K RSA as likely. And, because your text used "SHOULD" it goes a long way toward "presupposing" :-). I believe that this text has the potential to cause harm. You have argued that we should include this text because we want people to plan ahead; if the guidance is wrong, there is a potential to cause people to make wrong choices, and that could, in turn, cause folks to resist a switch to a different alg suite that might be selected later. That is causing harm. I also do not accept your assertion that switching to a larger RSA key size is easier than switching to different alg. It depends on the HW/SW products being used, and what these products offer as APIs, etc. Steve p.s. I also note that the CSI WG has agreed to use RPKI certs. Some of them have already expressed an interest in a transition to ECDSA for the SeND protocol (draft-cheneau-csi-ecc-sig-agility-02). This shows that there may be good reasons to consider a transition to ECDSA vs. 3/4K RSA. From root@core3.amsl.com Wed Oct 13 12:45:01 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B9A383A69C2; Wed, 13 Oct 2010 12:45: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: <20101013194501.B9A383A69C2@core3.amsl.com> Date: Wed, 13 Oct 2010 12:45:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-res-certs-19.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: , X-List-Received-Date: Wed, 13 Oct 2010 19:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Profile for X.509 PKIX Resource Certificates Author(s) : G. Huston, et al. Filename : draft-ietf-sidr-res-certs-19.txt Pages : 29 Date : 2010-10-13 This document defines a standard profile for X.509 certificates for the purposes of supporting validation of assertions of "right-of-use" of Resources (INRs). The certificates issued under this profile are used to convey the Issuer's authorisation of the Subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). The document also specifies profiles for the format of certificate requests. The document also specifies the Relying Party RPKI certificate path validation procedure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-res-certs-19.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-19.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-13123701.I-D@ietf.org> --NextPart-- From kotikalapudi.sriram@nist.gov Wed Oct 13 12:51:18 2010 Return-Path: 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 5E46B3A691F for ; Wed, 13 Oct 2010 12:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 FSr+JtI8UzBW for ; Wed, 13 Oct 2010 12:51:17 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id EE22D3A6876 for ; Wed, 13 Oct 2010 12:51:16 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o9DJqG6M009767; Wed, 13 Oct 2010 15:52:17 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 13 Oct 2010 15:52:16 -0400 From: "Sriram, Kotikalapudi" To: Geoff Huston , "sidr@ietf.org wg" Date: Wed, 13 Oct 2010 15:52:02 -0400 Thread-Topic: [sidr] draft-ietf-sidr-roa-validation-07 submitted Thread-Index: ActoaKwhOY8WRmsORXexcooKw66iqQA3+nLQAHFU8CA= Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Subject: Re: [sidr] draft-ietf-sidr-roa-validation-07 submitted X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 19:51:18 -0000 Hi Geoff: I just wanted to provide you some more comments for clarity. For updates with AS_SET, the algorithm in your draft only checks the ASN in the AGGREGATOR field to see if it matches with the ASN in the ROA. This approach allows tools for a would be attacker to hijack a prefix in one of these two ways: 1. Artificially inserts an AS_SET (possibly an empty AS_SET or with just his ASN in the AS_SET), places a matching ASN from the covering ROA for the prefix being hijacked into the AGGREGATOR field, and places his own ASN as the first AS after the AS_SET to attract traffic toward him. 2. Takes any legitimate update he sees with an AS_SET in it; leaves the AS_SET and AGGREGATOR field unmodified; places his own ASN immediately next to the AS_SET and propagates the update. (He doesn't need to insert the true origin before his own ASN!). There is a rather simple modification to your algorithm which mitigates these types attacks. Looking at the update/RIB data analysis in my presentation, it is clear for all practical purposes, that the ASN in the AGGREGATOR field is the same as the "first AS after the AS_SET" with very high probability (when they do not match, it is because the update is evidently flaky involving private ASNs, etc.). So the obvious remedy seems to be as follows: Check if the ASN in the AGGREGATOR field matches the the "first AS after the AS_SET". If true, then call that ASN the origin. Else, consider the origin indeterminable. If you take look at the data analysis in my slides (slides 2-4), the above approach seems quite well supported for determining the origin and at the same time mitigating the type of attacks noted above. Please let me know if this seems reasonable. Thanks. Regards, Sriram > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Sriram, > Kotikalapudi > Sent: Monday, October 11, 2010 10:14 AM > To: Geoff Huston; sidr@ietf.org wg > Subject: Re: [sidr] draft-ietf-sidr-roa-validation-07 submitted > > Geoff: > > I have a concern about the way the origin is determined > when AS_SET is present in an update. > Quoting from draft-ietf-sidr-roa-validation-07: > "If the final path segment of the AS_PATH is of type AS_SET, indicating > that the route is an aggregate, then the origin AS is taken as the AS > component of the AGGREGATOR attribute [RFC4271], if present. > Otherwise the route's origin AS cannot be determined." > > At the Maastricht SIDR WG meeting, I gave a presentation in which > I highlighted a new attack vector that is possible due to the > above quoted way of determining the origin AS. > Please see slide 7 of said presentation: > http://www.ietf.org/proceedings/78/slides/sidr-4.pdf > http://www.antd.nist.gov/~ksriram/AS_SET_Aggregator_Stats.pdf > (The second link has slightly revised slides with corrections.) > > In the presentation, I also pointed out a simple method for > avoiding the new type of attack (also on slide 7). > This method (or remedy) draws support from the > data that I presented in the preceding slides (slide 2-4). > > After my presentation, there was significant interest in this topic > and some good discussions followed on the list; links to some of which are: > http://www.ietf.org/mail-archive/web/sidr/current/msg01780.html > http://www.ietf.org/mail-archive/web/sidr/current/msg01794.html > http://www.ietf.org/mail-archive/web/sidr/current/msg01791.html > > Of course, a different take on all this is to deprecate the AS_SET. > http://www.ietf.org/mail-archive/web/sidr/current/msg01772.html > Warren Kumari has submitted a draft to IDR to try to accomplish that. > Until that is accomplished, if we think we have to be compliant with > RFC 4271, then I think my suggested solution makes sense. > > You may also factor in some comments/augmentation that Jeff Hass > and Pradosh have made to my proposal: > http://www.ietf.org/mail-archive/web/sidr/current/msg01791.html > http://www.ietf.org/mail-archive/web/sidr/current/msg01794.html > > Regards, > Sriram > ________________________________________ > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] On Behalf Of Geoff Huston > [gih@apnic.net] > Sent: Sunday, October 10, 2010 6:48 AM > To: sidr@ietf.org wg > Subject: [sidr] draft-ietf-sidr-roa-validation-07 submitted > > Hi, > > The draft's authors have reviewed the WG discussion and have decided to use, with > acknowledgement in the draft, and an expression of thanks here, the terminology in a > related WG draft, draft-ietf-sidr-pfx-validate. The revised terminology does not refer to a > route as being "valid", "invalid" or "unknown", but refers to an attribute of the route, > namely its "validity state", and this attribute has the values of "valid", "invalid" or > "unknown", and notes that "not found" is synonymous to "unknown" in this context. The > authors trust that this distinction addresses the issues WG members had over the > terminology in the previous version of this draft, that used such state attributions directly on > the route itself, rather than on a nominated attribute of the route. > > The announcement of the submission of this revised draft is below. > > regards, > > Geoff From gih@apnic.net Wed Oct 13 16:02:08 2010 Return-Path: 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 3A9F33A69C1 for ; Wed, 13 Oct 2010 16:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.988 X-Spam-Level: X-Spam-Status: No, score=-100.988 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, J_CHICKENPOX_71=0.6, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgRZ1CZeyzxU for ; Wed, 13 Oct 2010 16:02:06 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id C39B03A699A for ; Wed, 13 Oct 2010 16:02:04 -0700 (PDT) Received: from dhcp75.potaroo.net (eth143.act.adsl.internode.on.net [203.16.208.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id BBDF3D58FC; Thu, 14 Oct 2010 09:03:12 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Thu, 14 Oct 2010 10:03:08 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: , To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1081) Cc: "sidr@ietf.org wg" Subject: Re: [sidr] draft-ietf-sidr-roa-validation-07 submitted X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 23:02:08 -0000 On 14/10/2010, at 6:52 AM, Sriram, Kotikalapudi wrote: > Hi Geoff: >=20 > I just wanted to provide you some more comments for clarity. Unfortunately, I'm not sure that this note had your intended effect. > For updates with AS_SET, the algorithm in your draft=20 > only checks the ASN in the AGGREGATOR field=20 > to see if it matches with the ASN in the ROA.=20 > This approach allows tools for a would be attacker to=20 > hijack a prefix in one of these two ways: > 1. Artificially inserts an AS_SET (possibly an empty AS_SET or > with just his ASN in the AS_SET), places a matching ASN from the = covering=20 > ROA for the prefix being hijacked into the AGGREGATOR field,=20 > and places his own ASN as the first AS after the AS_SET to attract = traffic toward him.=20 But surely this can work for ANY prefix - i.e. replace the received AS = path with a bogus AS path and leave only the (valid) Origin AS. If one = is going to lie about the Path than politely asking the liar to only lie = in ways that this particular framework can detect is surely a little = far-fetched isn't it? > 2. Takes any legitimate update he sees with an AS_SET in it;=20 > leaves the AS_SET and AGGREGATOR field unmodified; places his > own ASN immediately next to the AS_SET and propagates the update. > (He doesn't need to insert the true origin before his own ASN!). But surely if the check is on the AGGREGATOR field then this would not = alter anything. I'm not sure what your point is here in this second = case. >=20 > There is a rather simple modification to your algorithm > which mitigates these types attacks. I honestly don't think so. > Looking at the update/RIB data analysis in my presentation, > it is clear for all practical purposes, that the ASN in the AGGREGATOR = field > is the same as the "first AS after the AS_SET" with very high = probability > (when they do not match, it is because the update is evidently flaky=20= > involving private ASNs, etc.). > So the obvious remedy seems to be as follows: > Check if the ASN in the AGGREGATOR field matches the=20 > the "first AS after the AS_SET". > If true, then call that ASN the origin.=20 > Else, consider the origin indeterminable. >=20 > If you take look at the data analysis in my slides (slides 2-4),=20 > the above approach seems quite well supported for determining=20 > the origin and at the same time mitigating the type of attacks noted = above. >=20 > Please let me know if this seems reasonable. Thanks. >=20 Its as reasonable as any other mechanism for origin validation that = leaves the AS PATH untouched. i.e. its a wafer thin veneer of potential = plausibility masking a rather large and gaping hole of vulnerability. = :-) Presumably if one were to introduce some form of path validation to = replace that gaping hole with something a little more substantial one = would also add a mechanism that would validate the aggregator as well. = In which case, if the aggregator and path are validated then why would = the origin AS definition require this double-barrelled approach of = having both match? So I'm at a loss to understand why adding a further constraint (that the = AGGREGATOR matches the "first AS after the AS_SET") helps in any way. = Why do you think that this additional constraint in the definition of an = origin AS is a net improvement? I'm also unsure as to your approach ere - surely the appropriate = analysis here is to ensure that the definition encompasses valid (as per = the BGP spec) actions by BGP speakers. i.e. if a BGP speaker acts in = accordance with RFC4271, and generates ROAs as appropriate, then = shouldn;t we be worried here is there are cases where acting within the = spec produces outcomes that are judged to be not valid. So rather than "mitigating attack" lets look at this from the other = perspective - does this definition fail to encompass legitimate actions = on the part of BGP speakers? Back to basics - in the current BGP definition (you know, the one that = still allows silly stuff to happen with proxy aggregation and AS Sets), = isn't the Aggregator path attribute meant to denote the AS identity of = the BGP speaker who performed the more recent proxy aggregation that = formed this particular aggregate prefix? And its thats the case then = surely that AS is the origin of the aggregated route? Yes? As far as I can tell your case would be stronger if you proposed "use = Aggregator, if present, otherwise use the AS that follows (where = "follows" is defined as "to the left of" in a Right to Left sequence = ordering of the path from origin to local) the AS Set. If there are = multiple instances of AS Set in the path and no aggregator, then abandon = all hope and surrender to the gods with an unknown origin AS" as this = would align wioth the text of the BGP spec that makes AGGREGATOR = optional. But requiring a match is going one step further than the BGP = spec, surely. So I'd like to propose the following text in section 3,. which adds a = sentence immediately before the final sentence in the paragraph: =20 If the final path segment of the AS_PATH is of type AS_SET, indicating that the route is an aggregate, then the origin AS is taken as the AS component of the AGGREGATOR attribute [RFC4271], if present. If the AGGREGATOR attribute is missing, then the origin AS is the first AS element of the last path segment of type AS_SEQUENCE (i.e. the AS in the rightmost position immediately preceding the final AS_SET path segment in the protocol message. Otherwise the route's origin AS=20 cannot be determined." It does not attempt to impose a greater constraint on the definition = than that of the BGP standard itself, which notes that AGGREGATOR is an = optional transitive attribute containing the last AS number that formed = the aggregate route. So either its there and therefore its the most = recent aggregator or its not there in which case look at AS the = immediately precedes the AS Set. (Frankly, deprecating AS-Sets is a far better answer to this particular = definitional problem you have noted, and having some form of mechanism = that validates path is about the only way I know how to detect folk who = lie about the path. You can't substitute an origin validation technique = for path validation. Square pegs, round holes, etc.) regards, Geoff > Regards, > Sriram >=20 >> -----Original Message----- >> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf = Of Sriram, >> Kotikalapudi >> Sent: Monday, October 11, 2010 10:14 AM >> To: Geoff Huston; sidr@ietf.org wg >> Subject: Re: [sidr] draft-ietf-sidr-roa-validation-07 submitted >>=20 >> Geoff: >>=20 >> I have a concern about the way the origin is determined >> when AS_SET is present in an update. >> Quoting from draft-ietf-sidr-roa-validation-07: >> "If the final path segment of the AS_PATH is of type AS_SET, = indicating >> that the route is an aggregate, then the origin AS is taken as the AS >> component of the AGGREGATOR attribute [RFC4271], if present. >> Otherwise the route's origin AS cannot be determined." >>=20 >> At the Maastricht SIDR WG meeting, I gave a presentation in which >> I highlighted a new attack vector that is possible due to the >> above quoted way of determining the origin AS. >> Please see slide 7 of said presentation: >> http://www.ietf.org/proceedings/78/slides/sidr-4.pdf >> http://www.antd.nist.gov/~ksriram/AS_SET_Aggregator_Stats.pdf >> (The second link has slightly revised slides with corrections.) >>=20 >> In the presentation, I also pointed out a simple method for >> avoiding the new type of attack (also on slide 7). >> This method (or remedy) draws support from the >> data that I presented in the preceding slides (slide 2-4). >>=20 >> After my presentation, there was significant interest in this topic >> and some good discussions followed on the list; links to some of = which are: >> http://www.ietf.org/mail-archive/web/sidr/current/msg01780.html >> http://www.ietf.org/mail-archive/web/sidr/current/msg01794.html >> http://www.ietf.org/mail-archive/web/sidr/current/msg01791.html >>=20 >> Of course, a different take on all this is to deprecate the AS_SET. >> http://www.ietf.org/mail-archive/web/sidr/current/msg01772.html >> Warren Kumari has submitted a draft to IDR to try to accomplish that. >> Until that is accomplished, if we think we have to be compliant with >> RFC 4271, then I think my suggested solution makes sense. >>=20 >> You may also factor in some comments/augmentation that Jeff Hass >> and Pradosh have made to my proposal: >> http://www.ietf.org/mail-archive/web/sidr/current/msg01791.html >> http://www.ietf.org/mail-archive/web/sidr/current/msg01794.html >>=20 >> Regards, >> Sriram >> ________________________________________ >> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] On Behalf Of = Geoff Huston >> [gih@apnic.net] >> Sent: Sunday, October 10, 2010 6:48 AM >> To: sidr@ietf.org wg >> Subject: [sidr] draft-ietf-sidr-roa-validation-07 submitted >>=20 >> Hi, >>=20 >> The draft's authors have reviewed the WG discussion and have decided = to use, with >> acknowledgement in the draft, and an expression of thanks here, the = terminology in a >> related WG draft, draft-ietf-sidr-pfx-validate. The revised = terminology does not refer to a >> route as being "valid", "invalid" or "unknown", but refers to an = attribute of the route, >> namely its "validity state", and this attribute has the values of = "valid", "invalid" or >> "unknown", and notes that "not found" is synonymous to "unknown" in = this context. The >> authors trust that this distinction addresses the issues WG members = had over the >> terminology in the previous version of this draft, that used such = state attributions directly on >> the route itself, rather than on a nominated attribute of the route. >>=20 >> The announcement of the submission of this revised draft is below. >>=20 >> regards, >>=20 >> Geoff -- Geoff Huston Chief Scientist, APNIC +61 7 3858 3100 gih@apnic.net From aservin@lacnic.net Wed Oct 13 16:15:32 2010 Return-Path: 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 E0B843A6A84 for ; Wed, 13 Oct 2010 16:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.629 X-Spam-Level: ** X-Spam-Status: No, score=2.629 tagged_above=-999 required=5 tests=[AWL=-1.193, BAYES_05=-1.11, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_DIALUP=0.862, MANGLED_EMAIL=2.3, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] 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 tbLQLw3h-P16 for ; Wed, 13 Oct 2010 16:11:36 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by core3.amsl.com (Postfix) with ESMTP id 8B0B63A6A7D for ; Wed, 13 Oct 2010 16:11:35 -0700 (PDT) Received: from [192.168.1.103] (r186-48-216-92.dialup.adsl.anteldata.net.uy [186.48.216.92]) by mail.lacnic.net.uy (Postfix) with ESMTP id CB0CD3084FF; Wed, 13 Oct 2010 21:12:39 -0200 (UYST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: <4CB5D75D.7020406@ripe.net> Date: Wed, 13 Oct 2010 21:12:39 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: <326295E3-0FD4-481A-8713-39493800D632@lacnic.net> References: <4CB5D75D.7020406@ripe.net> To: sidr@ietf.org X-Mailer: Apple Mail (2.1081) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [sidr] single-use and multi-use EE certs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 23:15:32 -0000 On 13 Oct 2010, at 13:59, Tim Bruijnzeels wrote: > Hi Steve, all, >=20 > On 10/13/10 4:59 PM, Stephen Kent wrote: >> Folks, >>=20 >> The repository structure doc devotes a moderate amount of text to >> accommodate what are termed "multi-use" EE certs. I'd like to = simplify >> these docs if we can, by dropping special repository treatment for >> multi-use certs, if there are no strong objections. >>=20 >=20 > Actually... >=20 > > This ship may have sailed a long time ago. I was not involved in the > early stages of this. So I am not aware of the arguments that may have > been raised in the past to come up with multi-use EEs in the first = place.. > >=20 > but, bottom-line: I think it would be simplest if the drop multi-use = EEs > were dropped altogether. As a new comer to RPKI I do not have strong arguments about this = but I was thinking the same than Tim while I was reading Steve post. Also I share the same concerns than Tim of overlooking something = obvious that was discussed a while ago. >=20 > As you mention the overhead for single use is not that big. >=20 >> >>=20 >> I can imagine two circumstances that may motivate employing a = multi-use >> EE cert vs. a set of single-use EE certs: >>=20 >> 1. there may be a set of objects that "fate share" and thus if any >> one needs to be revoked, all will be revoked. An example might be a = set >> of ROAs that are perceived to be linked in some fate sharing fashion. >>=20 >=20 > I think it's better to implement the knowledge about fate sharing > elsewhere, and then just revoke em all as needed. Ideas about which > objects should be fate sharing may change over time and with multi-use > changes can not be made after object creation: one cannot = de-fate-share > an existing object. >=20 >> 2. a series of object instances may be signed over time, and there = a >> perception that revocation of any instance of the object is unlikely >> (prior to object expiration). The obvious example here is a sequence = of >> manifests, where each manifest is replaced on a daily basis, as a >> consequence of daily CRL issuance. >>=20 >=20 > Okay, but I would actually still prefer single use here: it allows me = to > throw away the key. In any case I think simplification of the = standards > (and CA software, and validators) outweighs the overhead of using = single > use EEs here. >=20 >=20 > But as I said in the disclaimer, I may be overlooking other good = reasons > for the multi-use here... >=20 >=20 > Regards >=20 > Tim >=20 Best wishes, -als= From aservin@lacnic.net Wed Oct 13 16:21:23 2010 Return-Path: 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 2A1383A69DF for ; Wed, 13 Oct 2010 16:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.629 X-Spam-Level: ** X-Spam-Status: No, score=2.629 tagged_above=-999 required=5 tests=[AWL=-1.193, BAYES_05=-1.11, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_DIALUP=0.862, MANGLED_EMAIL=2.3, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] 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 nZ9lxmZujOQ8 for ; Wed, 13 Oct 2010 16:21:23 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by core3.amsl.com (Postfix) with ESMTP id 8B0B63A6A7D for ; Wed, 13 Oct 2010 16:11:35 -0700 (PDT) Received: from [192.168.1.103] (r186-48-216-92.dialup.adsl.anteldata.net.uy [186.48.216.92]) by mail.lacnic.net.uy (Postfix) with ESMTP id CB0CD3084FF; Wed, 13 Oct 2010 21:12:39 -0200 (UYST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: <4CB5D75D.7020406@ripe.net> Date: Wed, 13 Oct 2010 21:12:39 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: <326295E3-0FD4-481A-8713-39493800D632@lacnic.net> References: <4CB5D75D.7020406@ripe.net> To: sidr@ietf.org X-Mailer: Apple Mail (2.1081) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [sidr] single-use and multi-use EE certs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 23:21:23 -0000 On 13 Oct 2010, at 13:59, Tim Bruijnzeels wrote: > Hi Steve, all, >=20 > On 10/13/10 4:59 PM, Stephen Kent wrote: >> Folks, >>=20 >> The repository structure doc devotes a moderate amount of text to >> accommodate what are termed "multi-use" EE certs. I'd like to = simplify >> these docs if we can, by dropping special repository treatment for >> multi-use certs, if there are no strong objections. >>=20 >=20 > Actually... >=20 > > This ship may have sailed a long time ago. I was not involved in the > early stages of this. So I am not aware of the arguments that may have > been raised in the past to come up with multi-use EEs in the first = place.. > >=20 > but, bottom-line: I think it would be simplest if the drop multi-use = EEs > were dropped altogether. As a new comer to RPKI I do not have strong arguments about this = but I was thinking the same than Tim while I was reading Steve post. Also I share the same concerns than Tim of overlooking something = obvious that was discussed a while ago. >=20 > As you mention the overhead for single use is not that big. >=20 >> >>=20 >> I can imagine two circumstances that may motivate employing a = multi-use >> EE cert vs. a set of single-use EE certs: >>=20 >> 1. there may be a set of objects that "fate share" and thus if any >> one needs to be revoked, all will be revoked. An example might be a = set >> of ROAs that are perceived to be linked in some fate sharing fashion. >>=20 >=20 > I think it's better to implement the knowledge about fate sharing > elsewhere, and then just revoke em all as needed. Ideas about which > objects should be fate sharing may change over time and with multi-use > changes can not be made after object creation: one cannot = de-fate-share > an existing object. >=20 >> 2. a series of object instances may be signed over time, and there = a >> perception that revocation of any instance of the object is unlikely >> (prior to object expiration). The obvious example here is a sequence = of >> manifests, where each manifest is replaced on a daily basis, as a >> consequence of daily CRL issuance. >>=20 >=20 > Okay, but I would actually still prefer single use here: it allows me = to > throw away the key. In any case I think simplification of the = standards > (and CA software, and validators) outweighs the overhead of using = single > use EEs here. >=20 >=20 > But as I said in the disclaimer, I may be overlooking other good = reasons > for the multi-use here... >=20 >=20 > Regards >=20 > Tim >=20 Best wishes, -als= From achi@bbn.com Thu Oct 14 09:58:49 2010 Return-Path: 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 1889C3A6A1E for ; Thu, 14 Oct 2010 09:58:49 -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 tIBVRKVVV+C2 for ; Thu, 14 Oct 2010 09:58:46 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 49BF93A6ACB for ; Thu, 14 Oct 2010 09:58:44 -0700 (PDT) Received: from dhcp89-089-053.bbn.com ([128.89.89.53]:1618 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P6R9v-0008N6-J9 for sidr@ietf.org; Thu, 14 Oct 2010 13:00:03 -0400 Message-ID: <4CB73710.6090302@bbn.com> Date: Thu, 14 Oct 2010 13:00:00 -0400 From: Andrew Chi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sidr] draft-ietf-sidr-res-certs-19: SIA points to manifest? 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: , X-List-Received-Date: Thu, 14 Oct 2010 16:58:49 -0000 I noticed a change in the newest revision of the certificate profile (draft-ietf-sidr-res-certs-19) that could affect relying party software implementations. This might be a good change, but I just wanted to check. In section 4.9.8.1, the SIA for CA certs no longer points to a directory, but instead points to a manifest. (Well, except for some confusion because the first paragraph still says it points to a directory.) This extension MUST have an instance of an AccessDescription with an accessMethod of id-ad-rpkiManifest, id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } id-ad-rpkiManifest OBJECT IDENTIFIER ::= { id-ad 10 } with an RSYNC URI [RFC5781] form of accessLocation. The URI points to the CA's manifest of published objects [ID.sidr-rpki-manifests] as an object URL. Other accessDescription elements MAY exist for the id-ad-rpkiManifest accessMethod, where the accessLocation value indicates alternate access mechanisms for the same manifest object. If indeed the SIA now points to a manifest, RP implementations need to conform. This isn't necessarily bad--it may be a good idea during key rollover when two "instances" of a CA publish files in the same directory. Was this what we had intended all along (I may have missed the discussion), or is this new? -Andrew From achi@bbn.com Thu Oct 14 10:43:01 2010 Return-Path: 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 E1EEC3A69B5 for ; Thu, 14 Oct 2010 10:43:00 -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 xge2JNxzWO9p for ; Thu, 14 Oct 2010 10:42:59 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id F07973A698B for ; Thu, 14 Oct 2010 10:42:58 -0700 (PDT) Received: from dhcp89-089-053.bbn.com ([128.89.89.53]:1949 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P6Rqj-0007YT-Qs; Thu, 14 Oct 2010 13:44:17 -0400 Message-ID: <4CB7416F.3070606@bbn.com> Date: Thu, 14 Oct 2010 13:44:15 -0400 From: Andrew Chi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Andrew Chi References: <4CB73710.6090302@bbn.com> In-Reply-To: <4CB73710.6090302@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-sidr-res-certs-19: SIA points to manifest? 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: , X-List-Received-Date: Thu, 14 Oct 2010 17:43:01 -0000 Never mind. Both are the directory and manifest are required (as they were before), I misread. Thanks. -Andrew On 10/14/2010 1:00 PM, Andrew Chi wrote: > I noticed a change in the newest revision of the certificate profile > (draft-ietf-sidr-res-certs-19) that could affect relying party software > implementations. This might be a good change, but I just wanted to check. > > In section 4.9.8.1, the SIA for CA certs no longer points to a > directory, but instead points to a manifest. (Well, except for some > confusion because the first paragraph still says it points to a directory.) > > This extension MUST have an instance of an AccessDescription with an > accessMethod of id-ad-rpkiManifest, > > id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } > > id-ad-rpkiManifest OBJECT IDENTIFIER ::= { id-ad 10 } > > with an RSYNC URI [RFC5781] form of accessLocation. The URI points > to the CA's manifest of published objects [ID.sidr-rpki-manifests] as > an object URL. Other accessDescription elements MAY exist for the > id-ad-rpkiManifest accessMethod, where the accessLocation value > indicates alternate access mechanisms for the same manifest object. > > If indeed the SIA now points to a manifest, RP implementations need to > conform. This isn't necessarily bad--it may be a good idea during key > rollover when two "instances" of a CA publish files in the same directory. > > Was this what we had intended all along (I may have missed the > discussion), or is this new? > > -Andrew > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From root@core3.amsl.com Thu Oct 14 19:00:02 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4342F3A6956; Thu, 14 Oct 2010 19:00: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: <20101015020002.4342F3A6956@core3.amsl.com> Date: Thu, 14 Oct 2010 19:00:02 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-rpki-manifests-08.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: , X-List-Received-Date: Fri, 15 Oct 2010 02:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Manifests for the Resource Public Key Infrastructure Author(s) : R. Austein, et al. Filename : draft-ietf-sidr-rpki-manifests-08.txt Pages : 20 Date : 2010-10-14 This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). 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, Certificate Revocation List (CRL), or other type 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 enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if a RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-manifests-08.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-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-14185154.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu Oct 14 22:30:34 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2FEF73A6A7B; Thu, 14 Oct 2010 22:30:02 -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: <20101015053009.2FEF73A6A7B@core3.amsl.com> Date: Thu, 14 Oct 2010 22:30:02 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-roa-validation-08.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: , X-List-Received-Date: Fri, 15 Oct 2010 05:30:34 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Validation of Route Origination using the Resource Certificate PKI and ROAs Author(s) : G. Huston, G. Michaelson Filename : draft-ietf-sidr-roa-validation-08.txt Pages : 10 Date : 2010-10-14 This document defines the semantics of a Route Origin Authorization (ROA) in terms of the context of an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-validation-08.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-validation-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-14221851.I-D@ietf.org> --NextPart-- From gih@apnic.net Thu Oct 14 22:42:19 2010 Return-Path: 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 6B5383A6BFC for ; Thu, 14 Oct 2010 22:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.289 X-Spam-Level: X-Spam-Status: No, score=-101.289 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqOvXJrF76zp for ; Thu, 14 Oct 2010 22:42:17 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 52BCE3A6C07 for ; Thu, 14 Oct 2010 22:38:05 -0700 (PDT) Received: from dhcp75.potaroo.net (eth143.act.adsl.internode.on.net [203.16.208.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id F212AD5987; Fri, 15 Oct 2010 15:38:47 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Fri, 15 Oct 2010 16:38:47 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <10CCBFA0-B4C5-412B-B352-2779230944BD@apnic.net> References: To: Sandra Murphy , Christopher Morrow X-Mailer: Apple Mail (2.1081) Cc: "sidr@ietf.org wg" Subject: [sidr] WG LC request for draft-ietf-sidr-roa-validation-08.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: , X-List-Received-Date: Fri, 15 Oct 2010 05:42:19 -0000 Let me try that once again! The authors have revised the text relating to the definition of the = origin AS to be conformant to the current BGP specification, namely that = if the AGGREGATOR path attribute is present it "contains the last AS = number that formed the aggregate route" [RFC4271]. If this path = attribute is not present the draft defines the origin AS as the AS = preceding the AS_SET, which is a definition that has been drawn from the = earlier WG mail thread on this topic The intention here is not to impose criteria that differ from RFC4271, = and define the origin AS in an manner that if an AS undertakes proxy = aggregation in conformance with RFC4271 then this definition of origin = AS will correctly identify the aggregator AS as the origin AS. This is = slightly different from the various suggestions seen so far on the WG = mailing list, but it is believed that this refines those suggestions in = the light of a careful reading of the relevant sections of RFC 4271. The authors do not plan any further revisions of this document, and, = accordingly, would like once more to request a WG Last Call of the -08 = rev of the document. thanks, Geoff On 10/10/2010, at 9:50 PM, Geoff Huston wrote: > Hi, >=20 > The draft's authors believe that the document = draft-ietf-sidr-roa-validation-07 is ready for WG Last Call, and in this = note we are requesting the WG Chairs to conduct such a WG Last Call. >=20 > thanks, >=20 > Geoff >=20 >=20 > On 08/06/2010, at 11:01 PM, Sandra Murphy wrote: >=20 >> The WG LC has ended. >>=20 >> There were no responses to this LC. None. Zip. Zero. >>=20 >> This draft has gone through many changes through the years as it has = been discussed in IETF meetings. >>=20 >> So the silence must be regarded as proof that the wg had no further = comments to make. >>=20 >> I do note that the discussion of terminology (valid/unknown/invalid) = in the draft-pmohapat-sidr-pfx-validate-07 draft apply equally to this = draft and that an author of this draft had alternative terms to suggest = in that discussion. >>=20 >> I believe that that energetic discussion is indication that the wg = would prefer different terminology be used in this draft as well. >>=20 >> I invite the authors to continue that discussion to come to consensus = of what terms best capture the desired semantics. >>=20 >> Any final last call on this draft would be very short indeed. >>=20 >> --Sandy, speaking as wg chair >>=20 >> On Tue, 18 May 2010, Sandra Murphy wrote: >>=20 >>> The presentation "ROA Validation Update" = (http://www.ietf.org/proceedings/77/slides/sidr-8.pdf) at IETF 77 = requested a WG LC for draft "Validation of Route Origination using the = Resource Certificate PKI and ROAs". >>>=20 >>> The document (and the draft version history) is at available at >>> http://tools.ietf.org/html/draft-ietf-sidr-roa-validation-06. >>>=20 >>> The Last Call will end on Wednesday 2 June 2010. >>>=20 >>> As usual, please address all comments to the WG mailing list, and = please be clear in your comments to this last call if you are supporting = the document's submission to the IESG or if you are opposed. If you are = opposed, please indicate why. >>>=20 >>> --Sandy >>>=20 >>>=20 >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > -- >=20 > Geoff Huston > Chief Scientist, APNIC >=20 > +61 7 3858 3100 > gih@apnic.net >=20 >=20 >=20 >=20 -- Geoff Huston Chief Scientist, APNIC +61 7 3858 3100 gih@apnic.net From root@core3.amsl.com Thu Oct 14 23:15:26 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 04F463A68B9; Thu, 14 Oct 2010 23:15: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: <20101015061516.04F463A68B9@core3.amsl.com> Date: Thu, 14 Oct 2010 23:15:07 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-rescerts-provisioning-07.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: , X-List-Received-Date: Fri, 15 Oct 2010 06:15:26 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Protocol for Provisioning Resource Certificates Author(s) : G. Huston, et al. Filename : draft-ietf-sidr-rescerts-provisioning-07.txt Pages : 30 Date : 2010-10-14 This document defines a framework for certificate management interactions between a resource issuer ("Issuer") and a resource recipient ("Subject") through the specification of a protocol for interaction between the two parties. The protocol supports the transmission of requests from the Subject, and corresponding responses from the Issuer encompassing the actions of certificate issuance, certificate revocation and certificate status information reports. This protocol is intended to be limited to the application of resource certificate management and is not intended to be used as part of a more general certificate management framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rescerts-provisioning-07.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-rescerts-provisioning-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-14231028.I-D@ietf.org> --NextPart-- From kseo@bbn.com Fri Oct 15 09:27:14 2010 Return-Path: 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 30A5C3A6CB1 for ; Fri, 15 Oct 2010 09:27:14 -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.418, 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 CPhnluuPmA8J for ; Fri, 15 Oct 2010 09:27:13 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 2892F3A6A94 for ; Fri, 15 Oct 2010 09:27:13 -0700 (PDT) Received: from [128.89.255.144] (port=49380 helo=[128.89.89.78]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P6n90-000Mf9-18; Fri, 15 Oct 2010 12:28:34 -0400 Mime-Version: 1.0 Message-Id: Date: Fri, 15 Oct 2010 12:28:32 -0400 To: sidr@ietf.org From: Karen Seo Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: skent@bbn.com Subject: [sidr] Certificate policy -- new draft (version 14) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 16:27:14 -0000 Folks, We just submitted a new version of the RPKI Certificate Policy. In addition to a few typo/format corrections, we have included all the changes for which there was consensus among those who provided review feedback. We believe the document has thus completed WG Last Call and respectfully request that it proceed to the next stage of review. Thank you, Karen From root@core3.amsl.com Fri Oct 15 09:30:23 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 43A333A6CAA; Fri, 15 Oct 2010 09:30:21 -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: <20101015163023.43A333A6CAA@core3.amsl.com> Date: Fri, 15 Oct 2010 09:30:22 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-cp-14.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: , X-List-Received-Date: Fri, 15 Oct 2010 16:30:23 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Certificate Policy (CP) for the Resource PKI (RPKI Author(s) : S. Kent, et al. Filename : draft-ietf-sidr-cp-14.txt Pages : 42 Date : 2010-10-15 This document describes the certificate policy for a Public Key Infrastructure (PKI) used to support attestations about Internet resource holdings. Each organization that distributes IP addresses or Autonomous System (AS) numbers to an organization will, in parallel, issue a certificate reflecting this distribution. These certificates will enable verification that the resources indicated in the certificate have been distributed to the holder of the associated private key and that this organization is the current, unique holder of these resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-cp-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-cp-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-15092741.I-D@ietf.org> --NextPart-- From christopher.morrow@gmail.com Sat Oct 16 13:55:02 2010 Return-Path: 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 762523A6B21; Sat, 16 Oct 2010 13:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.423 X-Spam-Level: X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXJ9OWMujAVg; Sat, 16 Oct 2010 13:55:01 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id C7F4C3A6B11; Sat, 16 Oct 2010 13:54:57 -0700 (PDT) Received: by ewy6 with SMTP id 6so1394621ewy.31 for ; Sat, 16 Oct 2010 13:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=BCN/lrXbxXgWB1Kam6fygdCHn4L7gLzMHyAdT/dbVOk=; b=lvB5CMt3BzwWvytkvmBFCXOkiP770jAe0XRSMYLgxYfU5VS95NRWcngTLta9V/QpZJ WiK6gUMkcNoit1X6BgmeiLmQLAc3Kd7yJ6YKxpNx6Ge10OH1AAzfyuyp16kOKzY+j6oF iJ148l+zTQxrUPLKeMOdwRhh4TUxnyY2QMbNA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=W7nzv672Ay3+jYZpbo/skbxxplEmw+ob7FRdyAHy9RQ1eyxTSmS3NqWwgyyFU7Z8an jZwRY2kvcY1zn1TxTkRJ0mHfQYeWbPCTK+NMRcIWyL3I/9FrID1UMCGXzWyQ9hwGpzDC G6UF7f+iG3VubgEQc6Icv4uBI60EnC10TH0WQ= MIME-Version: 1.0 Received: by 10.213.11.18 with SMTP id r18mr2889135ebr.44.1287262581686; Sat, 16 Oct 2010 13:56:21 -0700 (PDT) Received: by 10.213.3.65 with HTTP; Sat, 16 Oct 2010 13:56:21 -0700 (PDT) Date: Sat, 16 Oct 2010 16:56:21 -0400 Message-ID: From: Christopher Morrow To: sidr@ietf.org, sidr-chairs@ietf.org, Geoff Huston , George Michaelson Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] WG LC for: draft-ietf-sidr-roa-validation-08.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: , X-List-Received-Date: Sat, 16 Oct 2010 20:55:02 -0000 SIDR Folk, Please take 14 days (finishing 10/30/2010) to consider the subject draft for WG LC. There was no chatter during it's last round of WG LC, some final edits were done by the authors and ... it's time to decide. -chris (wg-co-chair-cycling-socks on) From christopher.morrow@gmail.com Sat Oct 16 13:56:25 2010 Return-Path: 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 A2A463A6B11 for ; Sat, 16 Oct 2010 13:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.427 X-Spam-Level: X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIWjLQ006CDk for ; Sat, 16 Oct 2010 13:56:24 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 11E8A3A6ADA for ; Sat, 16 Oct 2010 13:56:23 -0700 (PDT) Received: by ewy6 with SMTP id 6so1394999ewy.31 for ; Sat, 16 Oct 2010 13:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UySyQL8+5a+TqgLW8CFHze2tKUVc9SmeYMXXplVZCbI=; b=LQFu1UYmSUKvBP71T+eOLV4ZFzDr9TddnAewC7FxrphCaDVsKqctwD8m7Jc7X55qJO U8kRpolCRyigitCRUDGU2sI3vR5rnsEsCuV6FpqXZ1E2hvwyTdY5RB2kYqOfb5vaYBJg Yb2KR7rxJ/jYra8AJMLCg5q7JNSWwtQ46Qi1o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jVYm3+0qB1yQcLhelaW5uNXSeyYO52vs42hpLBinjYz7fl27ceMYSpfXWYF1BgrWUA Omo1YvndmFoBkr+ZFeU4hFUylL2TcAg2irMa+lgPMo5lfWq8CozoOELt0zGkXgZZJf0o cYIXYb3BwGry0Y2ACPB7gMdEahJhL0cTsx2+E= MIME-Version: 1.0 Received: by 10.213.32.79 with SMTP id b15mr2150458ebd.39.1287262666879; Sat, 16 Oct 2010 13:57:46 -0700 (PDT) Received: by 10.213.3.65 with HTTP; Sat, 16 Oct 2010 13:57:46 -0700 (PDT) In-Reply-To: <10CCBFA0-B4C5-412B-B352-2779230944BD@apnic.net> References: <10CCBFA0-B4C5-412B-B352-2779230944BD@apnic.net> Date: Sat, 16 Oct 2010 16:57:46 -0400 Message-ID: From: Christopher Morrow To: Geoff Huston Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Sandra Murphy , "sidr@ietf.org wg" Subject: Re: [sidr] WG LC request for draft-ietf-sidr-roa-validation-08.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: , X-List-Received-Date: Sat, 16 Oct 2010 20:56:25 -0000 This was sent along (the requested LC message) to the list today... see you in 2 weeks (at decision time) -chris (wg-co-chair-cycling-shoes =3D=3D on) On Fri, Oct 15, 2010 at 1:38 AM, Geoff Huston wrote: > Let me try that once again! > > The authors have revised the text relating to the definition of the origi= n AS to be conformant to the current BGP specification, namely that if the = AGGREGATOR path attribute is present it "contains the last AS number that f= ormed the aggregate route" [RFC4271]. If this path attribute is not present= the draft defines the origin AS as the AS preceding the AS_SET, which is a= definition that has been drawn from the earlier WG mail thread on this top= ic > > The intention here is not to impose criteria that differ from RFC4271, an= d define the origin AS in an manner that if an AS undertakes proxy aggregat= ion in conformance with RFC4271 then this definition of origin AS will corr= ectly identify the aggregator AS as the origin AS. This is slightly differe= nt from the various suggestions seen so far on the WG mailing list, but it = is believed that this refines those suggestions in the light of a careful r= eading of the relevant sections of RFC 4271. > > The authors do not plan any further revisions of this document, and, acco= rdingly, would like once more to request a WG Last Call of the -08 rev of t= he document. > > > thanks, > > =A0 Geoff > > > > > > On 10/10/2010, at 9:50 PM, Geoff Huston wrote: > >> Hi, >> >> The draft's authors believe that the document draft-ietf-sidr-roa-valida= tion-07 is ready for WG Last Call, and in this note we are requesting the W= G Chairs to conduct such a WG Last Call. >> >> thanks, >> >> =A0 Geoff >> >> >> On 08/06/2010, at 11:01 PM, Sandra Murphy wrote: >> >>> The WG LC has ended. >>> >>> There were no responses to this LC. =A0None. =A0Zip. Zero. >>> >>> This draft has gone through many changes through the years as it has be= en discussed in IETF meetings. >>> >>> So the silence must be regarded as proof that the wg had no further com= ments to make. >>> >>> I do note that the discussion of terminology (valid/unknown/invalid) in= the draft-pmohapat-sidr-pfx-validate-07 draft apply equally to this draft = and that an author of this draft had alternative terms to suggest in that d= iscussion. >>> >>> I believe that that energetic discussion is indication that the wg woul= d prefer different terminology be used in this draft as well. >>> >>> I invite the authors to continue that discussion to come to consensus o= f what terms best capture the desired semantics. >>> >>> Any final last call on this draft would be very short indeed. >>> >>> --Sandy, speaking as wg chair >>> >>> On Tue, 18 May 2010, Sandra Murphy wrote: >>> >>>> The presentation "ROA Validation Update" (http://www.ietf.org/proceedi= ngs/77/slides/sidr-8.pdf) at IETF 77 requested a WG LC for draft "Validatio= n of Route Origination using the Resource Certificate PKI and ROAs". >>>> >>>> The document (and the draft version history) is at available at >>>> http://tools.ietf.org/html/draft-ietf-sidr-roa-validation-06. >>>> >>>> The Last Call will end on Wednesday 2 June 2010. >>>> >>>> As usual, please address all comments to the WG mailing list, and plea= se be clear in your comments to this last call if you are supporting the do= cument's submission to the IESG or if you are opposed. =A0If you are oppose= d, please indicate why. >>>> >>>> --Sandy >>>> >>>> >>>> _______________________________________________ >>>> sidr mailing list >>>> sidr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sidr >>>> >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >> >> -- >> >> Geoff Huston >> Chief Scientist, APNIC >> >> +61 7 3858 3100 >> gih@apnic.net >> >> >> >> > > -- > > Geoff Huston > Chief Scientist, APNIC > > +61 7 3858 3100 > gih@apnic.net > > > > > From kotikalapudi.sriram@nist.gov Sun Oct 17 12:02:50 2010 Return-Path: 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 57BB23A6BC8 for ; Sun, 17 Oct 2010 12:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.853 X-Spam-Level: X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[AWL=-1.454, BAYES_50=0.001, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOYCRv6VG3NS for ; Sun, 17 Oct 2010 12:02:48 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 02AF53A6A84 for ; Sun, 17 Oct 2010 12:02:47 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (WSXGHUB2.xchange.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o9HJ42a7015221; Sun, 17 Oct 2010 15:04:02 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Sun, 17 Oct 2010 15:03:49 -0400 From: "Sriram, Kotikalapudi" To: Geoff Huston Date: Sun, 17 Oct 2010 15:03:49 -0400 Thread-Topic: [sidr] draft-ietf-sidr-roa-validation-07 submitted Thread-Index: ActrKtc8AVHavpvsTXaR3eslmUH+cwDAlE2R Message-ID: References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Cc: "sidr@ietf.org wg" Subject: Re: [sidr] draft-ietf-sidr-roa-validation-07 submitted X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Oct 2010 19:02:50 -0000 Geoff: I feel this still needs more careful consideration and more work (in the part of the algorithm that deals with AS_SETs). My responses to your comments inline. Sriram >________________________________________ >From: Geoff Huston [gih@apnic.net] >Sent: Wednesday, October 13, 2010 7:03 PM >To: Sriram, Kotikalapudi >Cc: sidr@ietf.org wg >Subject: Re: [sidr] draft-ietf-sidr-roa-validation-07 submitted > >On 14/10/2010, at 6:52 AM, Sriram, Kotikalapudi wrote: > >> Hi Geoff: >> >> I just wanted to provide you some more comments for clarity. > > >Unfortunately, I'm not sure that this note had your intended effect. I think you misunderstood the attack vector that I described which I feel is made possible by the AS_SET-related portion of the algorithm described in your draft. It undermines ROA-based origin validation for any and all prefixes, not just those with aggregation using AS_SET. Please see examples below. > >> For updates with AS_SET, the algorithm in your draft >> only checks the ASN in the AGGREGATOR field >> to see if it matches with the ASN in the ROA. >> This approach allows tools for a would be attacker to >> hijack a prefix in one of these two ways: >> 1. Artificially inserts an AS_SET (possibly an empty AS_SET or >> with just his ASN in the AS_SET), places a matching ASN from the coverin= g >> ROA for the prefix being hijacked into the AGGREGATOR field, >> and places his own ASN as the first AS after the AS_SET to attract traff= ic toward him. > >But surely this can work for ANY prefix - i.e. replace the >received AS path with a bogus AS path and leave only the (valid) Origin AS= . >If one is going to lie about the Path than politely asking the liar to >only lie in ways that this particular framework can detect is surely a lit= tle far-fetched isn't it? I feel you may have misunderstood the attack vector (sorry if I failed to word it carefully the first time). Please consider the example: Valid ROA exists: {10.1.1.0/24, Origin =3D AS1} Hijacker owns AS2 and propagates an update as follows: AS2 [AS2], AGGEGATOR =3D AS1, 10.1.1.0/24, where [AS2] is an AS_SET that the hijacker has inserted to take advantage of your algorithm. Note that he did not even insert the true origin before his ASN! Your algorithm treats this update as one with AS_SET and AGGREGATOR present= , and it would assign status =93Valid=94 to this the update from the hijacker= . That is because you take the AGGREGATOR ASN, i.e., AS1 to be the origin and the ROA check passes. But in reality the hijack succeeds (to the extent BGP shortest path algorithm works in favor of the hijacker) and the traffic in part goes to AS2 (the hijacker). Am I right? In my view this is not path modification; it is simply origin manipulation. A straight forward heuristic that is derived from empirical evidence fixes this problem (makes the hijack infeasible). If you had a chance to look into my slides, http://www.antd.nist.gov/~ksriram/AS_SET_Aggregator_Stats.pdf what we have empirically established there is that the ASN in the AGGREGATOR attribute is practically identical to the first AS element of the last path segment of type AS_SEQUENCE (i.e. the AS = in the rightmost position immediately preceding the final AS_SET path segment in the protocol message). For simplicity, we have called this =93first AS element ...=94 the =93First AS after AS_SET.=94 Please see slides 2, 3 and 4. The above stated empirical observation is true for 97% BGP updates with AS_SET and 98.5% in RIB entries with AS_SET (based analysis of extensive Routeviews data) =96 please see slides 3 and 4= . The residual 3% in updates or 1.5% in RIB (where the AGGREGATOR ASN does not match the first AS element of the last path segment of type AS_SEQUENCE) are because the AGGREGATOR fields contains private ASN =96 that does not seem RFC 4271 compliant. So we need not care about these residual cases. Now based on the above evidence, to identify the origin AS when AS_SET is p= resent, we need NOT look at the AGGREGATOR; instead we look at the AS that =93follo= ws=94 the AS Set (where "follows" is defined as "to the left of" in a Right to Left sequence ordering of the path from origin to local). Based on the above set of observations, a simple heuristic for the algorithm is as follows: If the final path segment of the AS_PATH is of type AS_SET, indicating that the route is an aggregate, then the origin AS is taken the AS that =93follows=94 the AS Set (where "follows" is defined as "to the left of" in a Right to Left sequence ordering of the path from origin to local). (Does not matter if AGGREGATOR attribute is present or absent). (Note: We looked hard at lots of update/RIB data and found ZERO BGP updates and RIB entries which have more than one AS_SET. Thus, when an AS_SET is found in an update, there is one and only one. Also, the AS_SET always -- in 100% of updates with AS_SET and 100% of RIB entries with AS_SET -- appeared in the right most position in the AS pa= th.) With the above approach to the algorithm, the hijack vector talked about above goes away. The hijacker now has to insert the true origin AS (per ROA= ) prior to his ASN to have a chance at success =96 that is the minimum we exp= ect with ROA-based origin validation. He can no longer get away with substituting his ASN in place of the AS that =93follows=94 the AS Set (with my suggested heuristic algorithm). We are in no way requiring BGP router to do anything non-compliant with RFC= 4721. We simply have a heuristic based on a solid empirical fact that works, and preserves the fundamental premise of RPKI ROA, namely, the first AS of the right most AS_SEQUENCE must be that of the valid originator. > >>2. Takes any legitimate update he sees with an AS_SET in it; >>leaves the AS_SET and AGGREGATOR field unmodified; places his >>own ASN immediately next to the AS_SET and propagates the update. >>(He doesn't need to insert the true origin before his own ASN!). > >But surely if the check is on the AGGREGATOR field then this >would not alter anything. I'm not sure what your point is here in this sec= ond case. > I am arguing that check on the AGGREGATOR attribute alone leads to this attack vector as already explained above. > >> >>There is a rather simple modification to your algorithm >>which mitigates these types attacks. > >I honestly don't think so. > >>Looking at the update/RIB data analysis in my presentation, >>it is clear for all practical purposes, that the ASN in the AGGREGATOR fi= eld >>is the same as the "first AS after the AS_SET" with very high probability >>(when they do not match, it is because the update is evidently flaky >>involving private ASNs, etc.). >>So the obvious remedy seems to be as follows: >>Check if the ASN in the AGGREGATOR field matches the >>the "first AS after the AS_SET". >>If true, then call that ASN the origin. >>Else, consider the origin indeterminable. >> >>If you take look at the data analysis in my slides (slides 2-4), >>the above approach seems quite well supported for determining >>the origin and at the same time mitigating the type of attacks noted abov= e. >> >>Please let me know if this seems reasonable. Thanks. >> > >Its as reasonable as any other mechanism for origin validation that leaves= the AS PATH >untouched. i.e. its a wafer thin veneer of potential plausibility masking >a rather large and gaping hole of vulnerability. :-) The new attack vector I am concerned about is not about path modification; it is still origin modification that the attacker seems to get away with as explained above. > >Presumably if one were to introduce some form of path validation >to replace that gaping hole with something a little more substantial >one would also add a mechanism that would validate the aggregator as well. >In which case, if the aggregator and path are validated then why >would the origin AS definition require this double-barrelled approach of h= aving both match? > >So I'm at a loss to understand why adding a further constraint >(that the AGGREGATOR matches the "first AS after the AS_SET") >helps in any way. Why do you think that this additional constraint >in the definition of an origin AS is a net improvement? As stated above, the problem (new attack vector) goes away if the origin AS is taken the AS that =93follows=94 the AS Set (where "follows" is defined as "to the left of" in a Right to Left sequence ordering of the path from origin to local). Basically, it is not advisable to go by the AGGREGATOR attribute to define the origin AS. > >I'm also unsure as to your approach ere - surely the appropriate >analysis here is to ensure that the definition encompasses valid >(as per the BGP spec) actions by BGP speakers. i.e. if a BGP speaker >acts in accordance with RFC4271, and generates ROAs as appropriate, >then shouldn;t we be worried here is there are cases where acting >within the spec produces outcomes that are judged to be not valid. > >So rather than "mitigating attack" lets look at this from the other >perspective - does this definition fail to encompass legitimate >actions on the part of BGP speakers? > >Back to basics - in the current BGP definition (you know, the one >that still allows silly stuff to happen with proxy aggregation and AS Sets= ), >isn't the Aggregator path attribute meant to denote the AS identity of >the BGP speaker who performed the more recent proxy aggregation >that formed this particular aggregate prefix? And its thats the case >then surely that AS is the origin of the aggregated route? Yes? I feel this is where the mistake is that makes possible the new attack vect= or. Empirically, the AS that =93follows=94 the AS Set matches with the ASN in the Aggregator path attribute. That is catch. Therefore, always take the first AS of the rightmost AS_SEQUENCE to be the origin =96 for all updates, regardless of presence of AS_SET or n= ot. This eliminates the attack vector. > >As far as I can tell your case would be stronger if you proposed "use Aggr= egator, >if present, otherwise use the AS that follows (where "follows" is defined = as >"to the left of" in a Right to Left sequence ordering of the path from >origin to local) the AS Set. If there are multiple instances of AS Set in >the path and no aggregator, then abandon all hope and surrender to >the gods with an unknown origin AS" as this would align wioth >the text of the BGP spec that makes AGGREGATOR optional. >But requiring a match is going one step further than the BGP spec, surely. We are not requiring anything like that from BGP speaker. Our observation is purely empirical that leads to a more robust approach in the algorithm for validating updates with AS_SETs without compromising the normal updates. > > >So I'd like to propose the following text in section 3,. which adds a >sentence immediately before the final sentence in the paragraph: > >If the final path segment of the AS_PATH is of type AS_SET, indicating >that the route is an aggregate, then the origin AS is taken as the AS > component of the AGGREGATOR attribute [RFC4271], if present. If the >AGGREGATOR attribute is missing, then the origin AS is the first AS >element of the last path segment of type AS_SEQUENCE (i.e. the AS in >the rightmost position immediately preceding the final AS_SET path >segment in the protocol message. Otherwise the route's origin AS >cannot be determined." This still does not resolve the issue we are discussing. Sriram ------------ >It does not attempt to impose a greater constraint on the definition than = that of the BGP standard itself, which notes that AGGREGATOR is an optional= transitive attribute containing the last AS number that formed the aggrega= te route. So either its there and therefore its the most recent aggregator = or its not there in which case look at AS the immediately precedes the AS S= et. > >(Frankly, deprecating AS-Sets is a far better answer to this particular de= finitional problem you have noted, and having some form of mechanism that v= alidates path is about the only way I know how to detect folk who lie about= the path. You can't substitute an origin validation technique for path val= idation. Square pegs, round holes, etc.) > >regards, > Geoff > >Regards, >Sriram >> >>-----Original Message----- >>From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of S= riram, >>Kotikalapudi >>Sent: Monday, October 11, 2010 10:14 AM >>To: Geoff Huston; sidr@ietf.org wg >>Subject: Re: [sidr] draft-ietf-sidr-roa-validation-07 submitted >>> >>Geoff: >>> >>I have a concern about the way the origin is determined >>when AS_SET is present in an update. >>Quoting from draft-ietf-sidr-roa-validation-07: >>"If the final path segment of the AS_PATH is of type AS_SET, indicating >>that the route is an aggregate, then the origin AS is taken as the AS >>component of the AGGREGATOR attribute [RFC4271], if present. >>Otherwise the route's origin AS cannot be determined." >>> >>At the Maastricht SIDR WG meeting, I gave a presentation in which >>I highlighted a new attack vector that is possible due to the >>above quoted way of determining the origin AS. >>Please see slide 7 of said presentation: >>http://www.ietf.org/proceedings/78/slides/sidr-4.pdf >>http://www.antd.nist.gov/~ksriram/AS_SET_Aggregator_Stats.pdf >>(The second link has slightly revised slides with corrections.) >>> >>In the presentation, I also pointed out a simple method for >>avoiding the new type of attack (also on slide 7). >>This method (or remedy) draws support from the >>data that I presented in the preceding slides (slide 2-4). >>> >>After my presentation, there was significant interest in this topic >>and some good discussions followed on the list; links to some of which ar= e: >>http://www.ietf.org/mail-archive/web/sidr/current/msg01780.html >>http://www.ietf.org/mail-archive/web/sidr/current/msg01794.html >>http://www.ietf.org/mail-archive/web/sidr/current/msg01791.html >>> >>Of course, a different take on all this is to deprecate the AS_SET. >>http://www.ietf.org/mail-archive/web/sidr/current/msg01772.html >>Warren Kumari has submitted a draft to IDR to try to accomplish that. >>Until that is accomplished, if we think we have to be compliant with >>RFC 4271, then I think my suggested solution makes sense. >>> >>You may also factor in some comments/augmentation that Jeff Hass >>and Pradosh have made to my proposal: >>http://www.ietf.org/mail-archive/web/sidr/current/msg01791.html >>http://www.ietf.org/mail-archive/web/sidr/current/msg01794.html >>> >>Regards, >>Sriram >>________________________________________ From gih@apnic.net Sun Oct 17 14:00:46 2010 Return-Path: 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 985B53A6C01 for ; Sun, 17 Oct 2010 14:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.303 X-Spam-Level: X-Spam-Status: No, score=-101.303 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ealuFMaugJbt for ; Sun, 17 Oct 2010 14:00:45 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 272E23A6BEB for ; Sun, 17 Oct 2010 14:00:44 -0700 (PDT) Received: from dhcp75.potaroo.net (eth143.act.adsl.internode.on.net [203.16.208.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id B2486D57BB; Mon, 18 Oct 2010 07:01:58 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Mon, 18 Oct 2010 08:01:53 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <6CCA3A40-C081-4193-BAC4-EFC3C4F362A0@apnic.net> References: , , To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1081) Cc: "sidr@ietf.org wg" Subject: Re: [sidr] draft-ietf-sidr-roa-validation-07 submitted X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Oct 2010 21:00:46 -0000 At the risk of repeating myself, let me offer three thoughts as simply = as I can, and one not so simply: Origination validation does not stop folk lying in the AS_PATH, and, by = implication lying in the AGGREGATOR path attribute as well. I do not = understand what can be gained by believing otherwise. You can't = substitute an origin validation technique for path validation. Square = pegs, round holes, etc. If folk act within the constraints of the specification of BGP as = defined by the current BGP spec, then any additional constraints applied = in this draft should not invalidate an otherwise conforming BGP update = message. The text I've proposed in -08 of the draft attempts to meet the above = two objectives, without heading off into extraneous or diversionary = areas. After reading Appendix F.6. of RFC4271 again I'm even less convinced = that "the AS immediately preceding the final AS_SET in the AS_PATH" = means anything at all in the context of which AS performed the AS_PATH = aggregation. The "AS before the last AS_SET" assumes that the = aggregation algorithm is "bung all the AS's in the AS_PATHS of the = routes being aggregated into a bucket, pull out duplicates and put it = into a AS_SET". But that's not what is described in Appendix F.6. The = algorithm provided in that section of the draft allows for the = construction of multiple AS_SET path elements in the AS_PATH and also = allows for the aggregated path constructed by this algorithm to start = with an AS_SEQUENCE, not an AS_SET. In this case the task of identifying = the AS that performed the aggregation is actually quite fuzzy if no = AGGREGATOR is present. I suspect that if one were to quibble with the = "AS before the last AS_SET" as being what you do when no AGGREGATOR is = present, then this section of RFC4271 leads me to say that the best you = can say when no AGGREGATOR is present is that the origin AS is one of = the AS's in the initial AS_SEQUENCE path element, but it is, strictly = speaking, indeterminate as to which one it is. This leads to the = alternative interpretation that the text in the -07 version was actually = a "better" approach, namely that if no AGGREGATOR is present then its = not possible to tell definitively which AS actually undertook the proxy = aggregation action, and hence which AS should be deemed to be the origin = AS. i.e. taking a conforming route that has not been altered in any = malicious way and erring to a validation state determination of = "unknown" is perhaps better in such circumstances than taking the same = conforming route and erring to a validation state conclusion of = "invalid". In such a context of a strict interpretation of the BGP spec = as it relates to proxy aggregation, the AGGREGATOR AS, if present, = should be listed somewhere in the initial (left-most) path element, and = this path element must be an AS_SEQUENCE path element, and the = AGGREGATOR performed the most recent proxy aggregation to form this = route. If the AGGREGATOR attribute is missing, then the path aggregation = algorithm as presented in the BGP spec leads me to conclude that it is = not possible to definitively identify the AS that performed the proxy = aggregation in all circumstances.=20 At the risk of repeating myself again, the sooner the IDR WG deprecates = AS_SETs in the BGP spec, the better! From gih@apnic.net Sun Oct 17 17:46:48 2010 Return-Path: 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 BC6183A6BB6 for ; Sun, 17 Oct 2010 17:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.895 X-Spam-Level: X-Spam-Status: No, score=-101.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfealcHPN172 for ; Sun, 17 Oct 2010 17:46:47 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id C1C033A6AD4 for ; Sun, 17 Oct 2010 17:46:46 -0700 (PDT) Received: from xplode.canberra.aarnet.edu.au (xplode.canberra.aarnet.edu.au [202.158.221.24]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id F16B8D5894; Mon, 18 Oct 2010 10:48:01 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Mon, 18 Oct 2010 11:47:59 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Karen Seo X-Mailer: Apple Mail (2.1081) Cc: skent@bbn.com, sidr@ietf.org Subject: Re: [sidr] Certificate policy -- new draft (version 14) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 00:46:48 -0000 On 16/10/2010, at 3:28 AM, Karen Seo wrote: > Folks, >=20 > We just submitted a new version of the RPKI Certificate Policy. In = addition to a few typo/format corrections, we have included all the = changes for which there was consensus among those who provided review = feedback. We believe the document has thus completed WG Last Call and = respectfully request that it proceed to the next stage of review. Respectfully, I have to disagree that this document is ready. Its a long = document and for me each re-reading reveals more nits, unfortunately. I am sorry I did not raise this before, but I'd like to understand how = this constraint in the second paragraph of the Introduction, namely This PKI is designed exclusively for use in support of validation of claims related to INR holdings. Use of the certificates and certificate revocation lists (CRLs) managed under this PKI for any other purpose is a violation of this CP, and relying parties (RPs) SHOULD reject certificates presented for such uses. relates to the processing of manifests in the RPKI repository = infrastructure, where a certificate used in the context of the RPKI is = NOT used for support of validation of claims related to INR holdings. = The constraint above appears to preclude the use of manifests in the = RPKI, and I believe that this is an inappropriate constraint. Section 1.4.1 is also perhaps misleading, where is allows for these = certificates to be used to support operation of this infrastructure, but = cites an example of access control, whereas the example of manifest is = the case in point where there is a defined use.=20 I suggest that the wording in the introduction be altered to allow for = use in support of the operation of this infrastructure so that sections = 1.4.1 and the Introduction agree. Also, please correct the back ref in section 1.4.2 i.e. s/1.5.1/1.4.1/ Section 4.7.1 referes to section 5.6 relating to key validity intervals. = But in changing section 5.6, the reference in 4.7.1 is no longer = appropriate. This forward reference should be omitted, as the advice is = no longer provided. This version added the text in section 4.8.1: =20 When previously distributed INRs are removed from a certificate, then the old certificate MUST be revoked and a new certificate MUST be issued, reflecting the changed INR holdings. (The SIA extension MAY also be changed during this action, if required.) I'm not sure of the circumstances where the issuer knows what SIA to use = IF it is going to change. The SIA is normally supplied by the subject, = so in the case of certificate modification by the issuer in response to = a "shrink" in response where is the subject's certificate request that = contains a new SIA? regards, Geoff From christopher.morrow@gmail.com Sun Oct 17 20:02:07 2010 Return-Path: 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 485C63A6C7A for ; Sun, 17 Oct 2010 20:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.223 X-Spam-Level: X-Spam-Status: No, score=-102.223 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjpuxOORYXyx for ; Sun, 17 Oct 2010 20:02:06 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 28B483A6973 for ; Sun, 17 Oct 2010 20:02:06 -0700 (PDT) Received: by ewy6 with SMTP id 6so322509ewy.31 for ; Sun, 17 Oct 2010 20:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=W0eqUjQ+Ov9dtaAEfk9T5ltBJVf94ysvpYO49mb68Hk=; b=EpLQ8OTbFu5rlUIQEqhnLDwiBSZRuLfWUcWhvrPkRXrF1rOwFbwwE0TukVOjB6J+D/ n0LjHFD8EtfJfH6q0QL+h/M1q9ummpzwgE4f9mgSZt3RpPrXwH2leOq7LR8qXVgZfLzg bpXnXBPeZ5CqiktMGBu5LNXsbOPOESm0OTepo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=o/tCMHPxUqT2Me6PraKgMamDIRZxWy/sVUb1E0bXgj83dqipGS3c+QZRVockCLya0t m3qe2SJHwYtsvi5bcCiUbalm/7caTzUnHpyVDKIdCnSfRW289QLYpu3ARvXWG5SVU1e8 YNJS09GRLl169t7l9/k8xZFrDuxXP4z9ieRXc= MIME-Version: 1.0 Received: by 10.213.13.142 with SMTP id c14mr2890840eba.84.1287371012723; Sun, 17 Oct 2010 20:03:32 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.213.3.65 with HTTP; Sun, 17 Oct 2010 20:03:32 -0700 (PDT) In-Reply-To: <6CCA3A40-C081-4193-BAC4-EFC3C4F362A0@apnic.net> References: <6CCA3A40-C081-4193-BAC4-EFC3C4F362A0@apnic.net> Date: Sun, 17 Oct 2010 23:03:32 -0400 X-Google-Sender-Auth: A3jxl9rOiynVE8zl13WVfMyE388 Message-ID: From: Christopher Morrow To: Geoff Huston Content-Type: text/plain; charset=ISO-8859-1 Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org wg" Subject: Re: [sidr] draft-ietf-sidr-roa-validation-07 submitted X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 03:02:07 -0000 On Sun, Oct 17, 2010 at 5:01 PM, Geoff Huston wrote: > At the risk of repeating myself again, the sooner the IDR WG deprecates AS_SETs in the BGP spec, the better! So... without my co-chair items of clothes on (for sidr at least, and grow) ... there isn't a reliable and simple method I can see to dance around the AS-SET problem, aside from 'AS-SETs don't count and can't be in the validation decision'. So, I support SIDR folks taking a virtual walk to IDR and saying same. From kotikalapudi.sriram@nist.gov Mon Oct 18 05:19:45 2010 Return-Path: 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 A19323A6DC7 for ; Mon, 18 Oct 2010 05:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.376 X-Spam-Level: X-Spam-Status: No, score=-6.376 tagged_above=-999 required=5 tests=[AWL=0.223, 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 GrY5fzLmbnWt for ; Mon, 18 Oct 2010 05:19:14 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 472193A6DB0 for ; Mon, 18 Oct 2010 05:18:58 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (WSXGHUB2.xchange.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o9ICKB50013355; Mon, 18 Oct 2010 08:20:11 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 18 Oct 2010 08:19:58 -0400 From: "Sriram, Kotikalapudi" To: Geoff Huston Date: Mon, 18 Oct 2010 08:19:58 -0400 Thread-Topic: [sidr] draft-ietf-sidr-roa-validation-07 submitted Thread-Index: ActuPpo00A55SMxiRXm3jZV5ZIViVwAeyIt0 Message-ID: References: , , , <6CCA3A40-C081-4193-BAC4-EFC3C4F362A0@apnic.net> In-Reply-To: <6CCA3A40-C081-4193-BAC4-EFC3C4F362A0@apnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Cc: Christopher Morrow , "sidr@ietf.org wg" Subject: Re: [sidr] draft-ietf-sidr-roa-validation-07 submitted X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 12:19:45 -0000 Geoff: You seem to agree about the feasibility of the new attack vector. While I was calling it origin manipulation, you see it as AS path modificat= ion. Let us go with AS path modification (yes, I agree you are right because an artificial AS_SET is inserted by the attacker into the AS path!)= . However, your comment about square pegs, rounds holes does not seem relevan= t here. Until now, for a normal prefix update (i.e., one without proxy aggregation,= without AS_SET), we have always felt certain that RPKI ROA-based validation provided full assurance that the origin would to be valid if it matched wit= h=20 the AS in the covering ROA, even if the rest of the AS_PATH was altered in = some way. Now (with the algorithm in the draft in its current form) we seem to have l= ost that assurance. For a normal prefix update (i.e., one without proxy aggregation, without AS= _SET), now there can be false origination and this false update would be evaluated as =93valid=94 by the algorithm, only because the hijacker manipu= lated=20 the AS path cleverly enough to take advantage of what I think of as a loophole in the algorithm. Since we decided that the origin AS occurs in a particular position in the = AS_PATH for normal prefix updates, the algorithm cannot take its eyes off of that s= pot for any other type of prefix updates (e.g., with AS_SET) when validating or= igin. Although I like my empirical/heuristics-based proposal for a modification o= f=20 the algorithm; I would let others speak up if anyone likes it and sees some= merit. (Jeff Hass and Pradosh and few others did express support=20 soon after Maastricht SIDR; no surprise if they would think differently now= =96=20 the AS_SET issue seems inherently complicated.) In any case, you have cited complications also due to Appendix F.6 in RFC 4= 271 (another matter that Appendix F.6 seems so surreal). I fully agree with you and Chris Morrow that deprecating AS_SETs seems=20 the best (and may be the only) way out. I also feel that at present the document should defer statement on validati= on=20 of updates with AS_SET to a future time, pending outcome of the IDR action. Regards, Sriram ________________________________________ From: Geoff Huston [gih@apnic.net] Sent: Sunday, October 17, 2010 5:01 PM To: Sriram, Kotikalapudi Cc: sidr@ietf.org wg Subject: Re: [sidr] draft-ietf-sidr-roa-validation-07 submitted At the risk of repeating myself, let me offer three thoughts as simply as I= can, and one not so simply: Origination validation does not stop folk lying in the AS_PATH, and, by imp= lication lying in the AGGREGATOR path attribute as well. I do not understan= d what can be gained by believing otherwise. You can't substitute an origin= validation technique for path validation. Square pegs, round holes, etc. If folk act within the constraints of the specification of BGP as defined b= y the current BGP spec, then any additional constraints applied in this dra= ft should not invalidate an otherwise conforming BGP update message. The text I've proposed in -08 of the draft attempts to meet the above two o= bjectives, without heading off into extraneous or diversionary areas. After reading Appendix F.6. of RFC4271 again I'm even less convinced that "= the AS immediately preceding the final AS_SET in the AS_PATH" means anythin= g at all in the context of which AS performed the AS_PATH aggregation. The = "AS before the last AS_SET" assumes that the aggregation algorithm is "bung= all the AS's in the AS_PATHS of the routes being aggregated into a bucket,= pull out duplicates and put it into a AS_SET". But that's not what is desc= ribed in Appendix F.6. The algorithm provided in that section of the draft = allows for the construction of multiple AS_SET path elements in the AS_PATH= and also allows for the aggregated path constructed by this algorithm to s= tart with an AS_SEQUENCE, not an AS_SET. In this case the task of identifyi= ng the AS that performed the aggregation is actually quite fuzzy if no AGGR= EGATOR is present. I suspect that if one were to quibble with the "AS befor= e the last AS_SET" as being what you do when no AGGREGATOR is present, then= this section of RFC4271 leads me to say that the best you can say when no = AGGREGATOR is present is that the origin AS is one of the AS's in the initi= al AS_SEQUENCE path element, but it is, strictly speaking, indeterminate as= to which one it is. This leads to the alternative interpretation that the = text in the -07 version was actually a "better" approach, namely that if no= AGGREGATOR is present then its not possible to tell definitively which AS = actually undertook the proxy aggregation action, and hence which AS should = be deemed to be the origin AS. i.e. taking a conforming route that has not = been altered in any malicious way and erring to a validation state determin= ation of "unknown" is perhaps better in such circumstances than taking the= same conforming route and erring to a validation state conclusion of "inva= lid". In such a context of a strict interpretation of the BGP spec as it re= lates to proxy aggregation, the AGGREGATOR AS, if present, should be listed= somewhere in the initial (left-most) path element, and this path element m= ust be an AS_SEQUENCE path element, and the AGGREGATOR performed the most r= ecent proxy aggregation to form this route. If the AGGREGATOR attribute is = missing, then the path aggregation algorithm as presented in the BGP spec l= eads me to conclude that it is not possible to definitively identify the AS= that performed the proxy aggregation in all circumstances. At the risk of repeating myself again, the sooner the IDR WG deprecates AS_= SETs in the BGP spec, the better! From rogaglia@cisco.com Mon Oct 18 08:14:47 2010 Return-Path: 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 E54273A6E0C for ; Mon, 18 Oct 2010 08:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.994 X-Spam-Level: X-Spam-Status: No, score=-9.994 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 UpPvij9jHDu3 for ; Mon, 18 Oct 2010 08:14:45 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 00D8F3A6E0D for ; Mon, 18 Oct 2010 08:14:44 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYEAI8BvEyQ/khLgWdsb2JhbAChLBUBARYiIqJxnDSFSQSKSg X-IronPort-AV: E=Sophos;i="4.57,345,1283731200"; d="scan'208,217";a="66925726" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 18 Oct 2010 15:16:12 +0000 Received: from dhcp-144-254-20-83.cisco.com (dhcp-144-254-20-83.cisco.com [144.254.20.83]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o9IFGClx012267 for ; Mon, 18 Oct 2010 15:16:12 GMT From: Roque Gagliano Content-Type: multipart/alternative; boundary=Apple-Mail-120--129823641 Date: Mon, 18 Oct 2010 17:17:01 +0200 References: <20101018003130.AEDE63A6C43@core3.amsl.com> To: "sidr@ietf.org wg" Message-Id: <8238C560-1C86-4579-A722-4EBA9CFA07FD@cisco.com> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [sidr] Fwd: New Version Notification for draft-rgaglian-sidr-algorithm-agility-00 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: , X-List-Received-Date: Mon, 18 Oct 2010 15:14:48 -0000 --Apple-Mail-120--129823641 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi SIDR WG, I just submitted the first version of the algorithm agility document. I submit it as an individual contribution, but it is my understanding = that the group has already decided to take this as a working item. I = kindly request the WG chairs to indicate if there is still a need to = request WG adoption or I can go ahead and submit it as a WG item. Going to the content, the document documents what has been presented in = Maastricht and discussed in the mailing list. There are some sections = that still need to be completed, particularly on how to sync. the = different CAs during the transition for both the CAs and the RPs. I do have two requests for the provisioning protocol draft, that is a = consequence of the decision to adopt the "lazier faire" mode taken in = Maastricht: - As any subordinate CA can start the transition at any given time = without waiting to its parent CA to be able to issue certificates using = the new algorithm suite, we need a way in the provisioning protocol for = the subordinate CA to indicate which signing algorithm the parent CA = should use to process a particular request. This could be implemented = this way: - in the "issue" message, add an optional attribute: = "signing_algorithm=3DOID" [Certificate request] Behavior from issuing CA: if the cert_signing_algorithm is specified = and supported, use that OID. If the cert_signing_algorithm not specify, = use "current" algorithm. If the cert_signing_algorithm not supported, = reply with a "Request-Not-Performed" message with error code: 1401 request - request - signing algorithm not supported. - In order for the transition process to happen without any "off-line" = communication between CAs on when are they going to be able to handle = requests using the "new" algorithm sets, it may be a good idea to = include in the provisioning protocol the possibility to ask the server = about its capabilities. Another option is just to try to issue a = certificate with the new suite and see if you receive an error "core = 1401". I look forward for your comments, Roque Begin forwarded message: > From: IETF I-D Submission Tool > Date: October 18, 2010 2:31:30 AM GMT+02:00 > To: rogaglia@cisco.com > Cc: kent@bbn.com, turners@ieca.com > Subject: New Version Notification for = draft-rgaglian-sidr-algorithm-agility-00=20 >=20 >=20 > A new version of I-D, draft-rgaglian-sidr-algorithm-agility-00.txt has = been successfully submitted by Roque Gagliano and posted to the IETF = repository. >=20 > Filename: draft-rgaglian-sidr-algorithm-agility > Revision: 00 > Title: Algorithm Agility Procedure for RPKI. > Creation_date: 2010-10-18 > WG ID: Independent Submission > Number_of_pages: 22 >=20 > Abstract: > This document specifies the process that Certificate Authorities > (CAs) and Relying Parties (RP) participating in the Resource Public > Key Infrastructure (RPKI) will need to follow to transition to a new > (and probably cryptographically stronger) algorithm set. The process > is expected to be completed in a time scale of months or years. > Consequently, no emergency transition is specified. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 --Apple-Mail-120--129823641 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

- As any subordinate CA can start = the transition at any given time without waiting to its parent CA to be = able to issue certificates using the new algorithm suite, we need a way = in the provisioning protocol for the subordinate CA to indicate which = signing algorithm the parent CA should use to process a particular = request. This could be implemented this way:
- = in the = "issue" message, add an optional attribute: "
<request
              class_name=3D"class name"
              req_resource_set_as=3D"as resource set"
              req_resource_set_ipv4=3D"ipv4 resource set"
              req_resource_set_ipv6=3D"ipv6 resource set"
	  =
    cert_signing_algorithm=3D"OID">
             =
[Certificate request]
              </request>
Behavior from issuing CA: if the cert_signing_algorithm is = specified and supported, use that OID. If the cert_signing_algorithm not = specify, use "current" algorithm. If the cert_signing_algorithm not = supported, reply with a "Request-Not-Performed" message with error = code:
= 1401 request - request - signing algorithm not = supported.

- In order for the transition = process to happen without any "off-line" communication between CAs on = when are they going to be able to handle requests using the "new" = algorithm sets, it may be a good idea to include in the provisioning = protocol the possibility to ask the server about its capabilities. = Another option is just to try to issue a certificate with the new suite = and see if you receive an error "core 1401".

I = look forward for your = comments,

Roque


Begin forwarded message:

From: IETF I-D Submission = Tool <idsubmission@ietf.org>
Date: October 18, 2010 2:31:30 AM = GMT+02:00
= Subject: New Version = Notification for draft-rgaglian-sidr-algorithm-agility-00 =


A new version of I-D, = draft-rgaglian-sidr-algorithm-agility-00.txt has been successfully = submitted by Roque Gagliano and posted to the IETF = repository.

Filename: = draft-rgaglian-sidr-algorithm-agility
Revision: = 00
Title: = = Algorithm Agility Procedure for RPKI.
Creation_date: = 2010-10-18
WG ID: Independent = Submission
Number_of_pages: 22

Abstract:
This document = specifies the process that Certificate Authorities
(CAs) and Relying = Parties (RP) participating in the Resource Public
Key Infrastructure = (RPKI) will need to follow to transition to a new
(and probably = cryptographically stronger) algorithm set.  The process
is = expected to be completed in a time scale of months or = years.
Consequently, no emergency transition is = specified.



The IETF = Secretariat.



= --Apple-Mail-120--129823641-- From kotikalapudi.sriram@nist.gov Mon Oct 18 09:02:40 2010 Return-Path: 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 155B23A6DF3 for ; Mon, 18 Oct 2010 09:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.376 X-Spam-Level: X-Spam-Status: No, score=-6.376 tagged_above=-999 required=5 tests=[AWL=0.223, 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 EPLzlMJHCwjj for ; Mon, 18 Oct 2010 09:02:38 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 4C5C23A6A09 for ; Mon, 18 Oct 2010 09:02:33 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o9IG3cPU015825; Mon, 18 Oct 2010 12:03:38 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 18 Oct 2010 12:03:38 -0400 From: "Sriram, Kotikalapudi" To: Geoff Huston Date: Mon, 18 Oct 2010 12:03:29 -0400 Thread-Topic: [sidr] draft-ietf-sidr-roa-validation-07 submitted Thread-Index: ActuPpo00A55SMxiRXm3jZV5ZIViVwAeyIt0AAiD+KA= Message-ID: References: , , , <6CCA3A40-C081-4193-BAC4-EFC3C4F362A0@apnic.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Cc: Christopher Morrow , "sidr@ietf.org wg" Subject: Re: [sidr] draft-ietf-sidr-roa-validation-07 submitted X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 16:02:40 -0000 I realized my wording of sentences was a bit misleading in a few places. These corrections shown below (with [CORRECTION: ... ]). Sorry for the repeat. Sriram ----- Message showing the Corrections ----- Geoff: You seem to agree about the feasibility of the new attack vector. While I was calling it origin manipulation, you see it as AS path modification. Let us go with AS path modification (yes, I agree you are right because an artificial AS_SET is inserted by the attacker into the AS path!). However, your comment about square pegs, rounds holes does not seem relevant here. Until now, for a normal prefix update (i.e., one without proxy aggregation, without AS_SET), we have always felt certain that RPKI ROA-based validation provided full assurance that the origin would to be valid [CORRECTION: valid (invalid)] if it matched [CORRECTION: matched (didn't match)] the AS in the covering ROA, even if the rest of the AS_PATH was altered in some way. Now (with the algorithm in the draft in its current form) we seem to have lost that assurance. For a normal prefix update (i.e., one without proxy aggregation, without AS_SET), now there can be false origination and this false update would be evaluated as "valid" by the algorithm, only because the hijacker manipulated the AS path cleverly enough to take advantage of what I think of as a loophole in the algorithm. Since we decided that the origin AS occurs in a particular position in the AS_PATH for normal prefix updates, the algorithm [CORRECTION: any proposed algorithm] cannot [CORRECTION: must not] take its eyes off of that spot for any other type of prefix updates (e.g., with AS_SET) when validating origin. Although I like my empirical/heuristics-based proposal for a modification of the algorithm; I would let others speak up if anyone likes it and sees some merit. (Jeff Hass and Pradosh and few others did express support soon after Maastricht SIDR; no surprise if they would think differently now - the AS_SET issue seems inherently complicated.) In any case, you have cited complications also due to Appendix F.6 in RFC 4271 (another matter that Appendix F.6 seems so surreal). I fully agree with you and Chris Morrow that deprecating AS_SETs seems the best (and may be the only) way out. I also feel that at present the document should defer statement on validation of updates with AS_SET to a future time, pending outcome of the IDR action. Regards, Sriram ________________________________________ > From: Geoff Huston [gih@apnic.net] > Sent: Sunday, October 17, 2010 5:01 PM > To: Sriram, Kotikalapudi > Cc: sidr@ietf.org wg > Subject: Re: [sidr] draft-ietf-sidr-roa-validation-07 submitted > > At the risk of repeating myself, let me offer three thoughts as simply as I can, and one not > so simply: > > Origination validation does not stop folk lying in the AS_PATH, and, by implication lying > in the AGGREGATOR path attribute as well. I do not understand what can be gained by > believing otherwise. You can't substitute an origin validation technique for path validation. > Square pegs, round holes, etc. > > If folk act within the constraints of the specification of BGP as defined by the current BGP > spec, then any additional constraints applied in this draft should not invalidate an otherwise > conforming BGP update message. > > The text I've proposed in -08 of the draft attempts to meet the above two objectives, without > heading off into extraneous or diversionary areas. > > After reading Appendix F.6. of RFC4271 again I'm even less convinced that "the AS > immediately preceding the final AS_SET in the AS_PATH" means anything at all in the > context of which AS performed the AS_PATH aggregation. The "AS before the last > AS_SET" assumes that the aggregation algorithm is "bung all the AS's in the AS_PATHS > of the routes being aggregated into a bucket, pull out duplicates and put it into a AS_SET". > But that's not what is described in Appendix F.6. The algorithm provided in that section of > the draft allows for the construction of multiple AS_SET path elements in the AS_PATH > and also allows for the aggregated path constructed by this algorithm to start with an > AS_SEQUENCE, not an AS_SET. In this case the task of identifying the AS that performed > the aggregation is actually quite fuzzy if no AGGREGATOR is present. I suspect that if one > were to quibble with the "AS before the last AS_SET" as being what you do when no > AGGREGATOR is present, then this section of RFC4271 leads me to say that the best you > can say when no AGGREGATOR is present is that the origin AS is one of the AS's in the > initial AS_SEQUENCE path element, but it is, strictly speaking, indeterminate as to which > one it is. This leads to the alternative interpretation that the text in the -07 version was > actually a "better" approach, namely that if no AGGREGATOR is present then its not > possible to tell definitively which AS actually undertook the proxy aggregation action, and > hence which AS should be deemed to be the origin AS. i.e. taking a conforming route that > has not been altered in any malicious way and erring to a validation state determination of > "unknown" is perhaps better in such circumstances than taking the same conforming route > and erring to a validation state conclusion of "invalid". In such a context of a strict > interpretation of the BGP spec as it relates to proxy aggregation, the AGGREGATOR AS, if > present, should be listed somewhere in the initial (left-most) path element, and this path > element must be an AS_SEQUENCE path element, and the AGGREGATOR performed the > most recent proxy aggregation to form this route. If the AGGREGATOR attribute is > missing, then the path aggregation algorithm as presented in the BGP spec leads me to > conclude that it is not possible to definitively identify the AS that performed the proxy > aggregation in all circumstances. > > At the risk of repeating myself again, the sooner the IDR WG deprecates AS_SETs in the > BGP spec, the better! From weiler@watson.org Mon Oct 18 12:22:23 2010 Return-Path: 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 A60F23A6E51 for ; Mon, 18 Oct 2010 12:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=0.535, 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 5OKbCzulB7fq for ; Mon, 18 Oct 2010 12:22:22 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id BD7CB3A6E3D for ; Mon, 18 Oct 2010 12:22:22 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id o9IJNoQN082105; Mon, 18 Oct 2010 15:23:50 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id o9IJNosu082102; Mon, 18 Oct 2010 15:23:50 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 18 Oct 2010 15:23:50 -0400 (EDT) From: Samuel Weiler To: Christopher Morrow In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 18 Oct 2010 15:23:50 -0400 (EDT) Cc: sidr@ietf.org Subject: Re: [sidr] WG Adoption: draft-weiler-sidr-publication-00 (changed subject sorry for the spamz) 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: , X-List-Received-Date: Mon, 18 Oct 2010 19:22:23 -0000 On Mon, 11 Oct 2010, Christopher Morrow wrote: > Hey, it was 14 days... (or more) no one dissented WG-item it is! > > Sam, could you please spin a re-titled -00 into the process machine? Done. The -00 will match draft-weiler, and changes will appear in -01. -- Sam From root@core3.amsl.com Mon Oct 18 14:30:19 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B841A3A6AB6; Mon, 18 Oct 2010 14:30:19 -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: <20101018213019.B841A3A6AB6@core3.amsl.com> Date: Mon, 18 Oct 2010 14:30:19 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-publication-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: , X-List-Received-Date: Mon, 18 Oct 2010 21:30:19 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Publication Protocol for the Resource Public Key Infrastructure (RPKI) Author(s) : S. Weiler, A. Sonalker Filename : draft-ietf-sidr-publication-00.txt Pages : 12 Date : 2010-10-18 This document defines a protocol for publishing Resource Public Key Infrastructure (RPKI) objects. Even though the RPKI will have many participants issuing certificates and creating other objects, it is operationally useful to consolidate the publication of those objects. This document provides the protocol for that. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-publication-00.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-publication-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-18142421.I-D@ietf.org> --NextPart-- From kent@bbn.com Tue Oct 19 12:26:08 2010 Return-Path: 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 5C2C43A6921 for ; Tue, 19 Oct 2010 12:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.406 X-Spam-Level: X-Spam-Status: No, score=-102.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCFdamfOuN+f for ; Tue, 19 Oct 2010 12:26:07 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 0420F3A68EE for ; Tue, 19 Oct 2010 12:26:06 -0700 (PDT) Received: from dhcp89-089-159.bbn.com ([128.89.89.159]:49169) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P8HqT-000JHA-SZ; Tue, 19 Oct 2010 15:27:37 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 19 Oct 2010 15:27:35 -0400 To: Geoff Huston From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] Certificate policy -- new draft (version 14) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 19:26:08 -0000 Geoff, Thans for the cafreful reading. Here are our proposed changes to address the issues you raised. >I am sorry I did not raise this before, but I'd like to understand >how this constraint in the second paragraph of the Introduction, >namely > > This PKI > is designed exclusively for use in support of validation of claims > related to INR holdings. Use of the certificates and certificate > revocation lists (CRLs) managed under this PKI for any other purpose > is a violation of this CP, and relying parties (RPs) SHOULD reject > certificates presented for such uses. > >relates to the processing of manifests in the RPKI repository >infrastructure, where a certificate used in the context of the RPKI >is NOT used for support of validation of claims related to INR >holdings. The constraint above appears to preclude the use of >manifests in the RPKI, and I believe that this is an inappropriate >constraint. I don't read the text in question as precluding the processing EE certs used in manifests. Manifests exist to enable RPs to detect a class of attacks against the repository system. The repository system exists to enable RPs to acquire the CA and EE certs used validate "claims related to INR holdings." Thus, transitively, the certs used with manifests are within scope, as is the processing of these certs. But, to help avoid confusion, how about the following revised text: The most important and distinguishing aspect of the PKI for which this policy was created is that it does not purport to identify an INR holder via the subject name contained in the certificate issued to that entity. Rather, each certificate issued under this policy is intended to enable an entity to assert, in a verifiable fashion, that it is the current holder of an INR based on the current records of the entity responsible for the resources in question. Verification of the assertion is based on two criteria: the ability of the entity to digitally sign data that is verifiable using the public key contained in the corresponding certificate, and validation of that certificate in the context of this PKI. This PKI is designed exclusively for use in support of validation of claims related to current INR holdings. This includes any certificates issued in support of operation of this infrastructure, e.g., for integrity or access control of the repository system described in 2.4. Such transitive uses of certificates also are permitted under this policy. Use of the certificates and certificate revocation lists (CRLs) managed under this PKI for any other purpose is a violation of this CP, and relying parties (RPs) SHOULD reject certificates presented for such uses. >Section 1.4.1 is also perhaps misleading, where is allows for these >certificates to be used to support operation of this infrastructure, >but cites an example of access control, whereas the example of >manifest is the case in point where there is a defined use. > >I suggest that the wording in the introduction be altered to allow >for use in support of the operation of this infrastructure so that >sections 1.4.1 and the Introduction agree. I hope you find the text above to be appropriate for section 1. How about the following text for 1.4: The certificates issued under this hierarchy are for authorization in support of validation of claims of current holdings of INRs. Additional uses of the certificates, consistent with the basic goal cited above, also are permitted under this policy. For example, certificates may be issued in support of integrity and access control for the repository system described in 2.4. Such transitive uses are permitted under this policy. >Section 4.7.1 referes to section 5.6 relating to key validity >intervals. But in changing section 5.6, the reference in 4.7.1 is no >longer appropriate. This forward reference should be omitted, as the >advice is no longer provided. Agreed. We will delete the last paragraph in 4.7.1. >This version added the text in section 4.8.1: > When previously distributed INRs are removed from a certificate, > then the old certificate MUST be revoked and a new certificate MUST > be issued, reflecting the changed INR holdings. (The SIA extension > MAY also be changed during this action, if required.) > >I'm not sure of the circumstances where the issuer knows what SIA to >use IF it is going to change. The SIA is normally supplied by the >subject, so in the case of certificate modification by the issuer in >response to a "shrink" in response where is the subject's >certificate request that contains a new SIA? We made this change in response to a comment by another reviewer. If the SIA is to change, the new one must be provided by the Subject that is loosing some INRs, as you suggest. Thus, I would expect the CA that revokes the cert (due to INR shrinkage) to use the SIA that appeared in the cert being revoked, unless it is informed otherwise. We can make that clearer with the following, revised paragraph: When previously distributed INRs are removed from a certificate, then the old certificate MUST be revoked and a new certificate MUST be issued, reflecting the changed INR holdings. (The SIA extension in the new certificate will be unchanged, unless the affected INR holder supplies a new SIA value.) Steve From gih@apnic.net Tue Oct 19 12:44:35 2010 Return-Path: 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 575703A6931 for ; Tue, 19 Oct 2010 12:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.131 X-Spam-Level: X-Spam-Status: No, score=-92.131 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_AU=0.377, HELO_EQ_CPE=0.5, HOST_EQ_AU=0.327, HOST_EQ_CPE=0.979, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3DgXGX8UJxY for ; Tue, 19 Oct 2010 12:44:33 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id EA6103A68C2 for ; Tue, 19 Oct 2010 12:44:31 -0700 (PDT) Received: from cpe-124-184-225-242.lns11.cht.bigpond.net.au (CPE-124-184-225-242.lns11.cht.bigpond.net.au [124.184.225.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id D876BD57BB; Wed, 20 Oct 2010 05:45:50 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Wed, 20 Oct 2010 06:45:48 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <326EB4E9-0457-4D9B-B39E-691E445419E7@apnic.net> References: To: Stephen Kent X-Mailer: Apple Mail (2.1081) Cc: sidr@ietf.org Subject: Re: [sidr] Certificate policy -- new draft (version 14) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 19:44:35 -0000 On 20/10/2010, at 6:27 AM, Stephen Kent wrote: > Geoff, >=20 >=20 > Thans for the cafreful reading. Here are our proposed changes to = address the issues you raised. >=20 >> I am sorry I did not raise this before, but I'd like to understand = how this constraint in the second paragraph of the Introduction, namely >>=20 >> This PKI >> is designed exclusively for use in support of validation of claims >> related to INR holdings. Use of the certificates and certificate >> revocation lists (CRLs) managed under this PKI for any other = purpose >> is a violation of this CP, and relying parties (RPs) SHOULD reject >> certificates presented for such uses. >>=20 >> relates to the processing of manifests in the RPKI repository = infrastructure, where a certificate used in the context of the RPKI is = NOT used for support of validation of claims related to INR holdings. = The constraint above appears to preclude the use of manifests in the = RPKI, and I believe that this is an inappropriate constraint. >=20 > I don't read the text in question as precluding the processing EE = certs used in manifests. Manifests exist to enable RPs to detect a class = of attacks against the repository system. The repository system exists = to enable RPs to acquire the CA and EE certs used validate "claims = related to INR holdings." Thus, transitively, the certs used with = manifests are within scope, as is the processing of these certs. But, to = help avoid confusion, how about the following revised text: >=20 >=20 > The most important and distinguishing aspect of the PKI for which > this policy was created is that it does not purport to identify an > INR holder via the subject name contained in the certificate issued > to that entity. Rather, each certificate issued under this policy is > intended to enable an entity to assert, in a verifiable fashion, > that it is the current holder of an INR based on the current records > of the entity responsible for the resources in question. > Verification of the assertion is based on two criteria: the ability > of the entity to digitally sign data that is verifiable using the > public key contained in the corresponding certificate, and > validation of that certificate in the context of this PKI. >=20 > This PKI is designed exclusively for use in support of validation of = claims > related to current INR holdings. This includes any certificates = issued in > support of operation of this infrastructure, e.g., for integrity or = access > control of the repository system described in 2.4. Such transitive = uses of > certificates also are permitted under this policy. Use of the = certificates and > certificate revocation lists (CRLs) managed under this PKI for any = other > purpose is a violation of this CP, and relying parties (RPs) SHOULD = reject > certificates presented for such uses. >=20 >=20 Yes,this proposed wording works for me. >=20 >> Section 1.4.1 is also perhaps misleading, where is allows for these = certificates to be used to support operation of this infrastructure, but = cites an example of access control, whereas the example of manifest is = the case in point where there is a defined use. >>=20 >> I suggest that the wording in the introduction be altered to allow = for use in support of the operation of this infrastructure so that = sections 1.4.1 and the Introduction agree. >=20 > I hope you find the text above to be appropriate for section 1. How = about the following text for 1.4: >=20 > The certificates issued under this hierarchy are for authorization > in support of validation of claims of current holdings of INRs. >=20 > Additional uses of the certificates, consistent with the basic goal > cited above, also are permitted under this policy. For example, = certificates > may be issued in support of integrity and access control for the = repository > system described in 2.4. Such transitive uses are permitted under = this policy. >=20 >=20 again, thanks, I agree with this proposed edit. >> Section 4.7.1 referes to section 5.6 relating to key validity = intervals. But in changing section 5.6, the reference in 4.7.1 is no = longer appropriate. This forward reference should be omitted, as the = advice is no longer provided. >=20 > Agreed. We will delete the last paragraph in 4.7.1. >=20 >> This version added the text in section 4.8.1: When previously = distributed INRs are removed from a certificate, >> then the old certificate MUST be revoked and a new certificate MUST >> be issued, reflecting the changed INR holdings. (The SIA extension >> MAY also be changed during this action, if required.) >>=20 >> I'm not sure of the circumstances where the issuer knows what SIA to = use IF it is going to change. The SIA is normally supplied by the = subject, so in the case of certificate modification by the issuer in = response to a "shrink" in response where is the subject's certificate = request that contains a new SIA? >=20 > We made this change in response to a comment by another reviewer. If = the SIA is to change, the new one must be provided by the Subject that = is loosing some INRs, as you suggest. Thus, I would expect the CA that = revokes the cert (due to INR shrinkage) to use the SIA that appeared in = the cert being revoked, unless it is informed otherwise. We can make = that clearer with the following, revised paragraph: >=20 > When previously distributed INRs are removed from a certificate, > then the old certificate MUST be revoked and a new certificate MUST > be issued, reflecting the changed INR holdings. (The SIA extension > in the new certificate will be unchanged, unless the affected INR = holder > supplies a new SIA value.) I can live with this. I'm still unsure how this "new" SIA value is to be = supplied to the Issuer, given that it is not in the "current" request = from the subject (i.e. the most recent request that caused the = about-to-be-revoked-and reissued-with-a-smaller-INR-set certificate to = be issued), but that is perhaps out of scope for the CP, hence my = conclusion that I can live with this. regards, Geoff From root@core3.amsl.com Wed Oct 20 09:30:02 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6A1723A6879; Wed, 20 Oct 2010 09:30: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: <20101020163002.6A1723A6879@core3.amsl.com> Date: Wed, 20 Oct 2010 09:30:02 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-cp-15.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 16:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Certificate Policy (CP) for the Resource PKI (RPKI Author(s) : S. Kent, et al. Filename : draft-ietf-sidr-cp-15.txt Pages : 42 Date : 2010-10-20 This document describes the certificate policy for a Public Key Infrastructure (PKI) used to support attestations about Internet resource holdings. Each organization that distributes IP addresses or Autonomous System (AS) numbers to an organization will, in parallel, issue a certificate reflecting this distribution. These certificates will enable verification that the resources indicated in the certificate have been distributed to the holder of the associated private key and that this organization is the current, unique holder of these resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-cp-15.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-cp-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-20091926.I-D@ietf.org> --NextPart-- From Sandra.Murphy@cobham.com Thu Oct 21 05:55:11 2010 Return-Path: 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 6BBDA3A698B for ; Thu, 21 Oct 2010 05:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-NOmrJL-6Pz for ; Thu, 21 Oct 2010 05:55:10 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id B0C793A68FB for ; Thu, 21 Oct 2010 05:55:09 -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 o9LCueHU023679 for ; Thu, 21 Oct 2010 07:56:40 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o9LCueUT007408 for ; Thu, 21 Oct 2010 07:56:40 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.93]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Oct 2010 08:56:40 -0400 Date: Thu, 21 Oct 2010 08:56:40 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 21 Oct 2010 12:56:40.0686 (UTC) FILETIME=[67A320E0:01CB711F] Subject: [sidr] agenda request 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: , X-List-Received-Date: Thu, 21 Oct 2010 12:55:11 -0000 The draft agenda for the upcoming wg meeting is due next Wed, 2400 UTC. Anyone who wishes to present at this meeting please send a message to the list or chairs by next Wed. --Sandy From mingui@huawei.com Thu Oct 21 19:37:36 2010 Return-Path: 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 A386B3A682F for ; Thu, 21 Oct 2010 19:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.979 X-Spam-Level: **** X-Spam-Status: No, score=4.979 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_05=-1.11, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_62=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] 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 AQt0yStBMiWp for ; Thu, 21 Oct 2010 19:37:27 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id C31A33A67FA for ; Thu, 21 Oct 2010 19:37:23 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAO00ENC7CI4Q@szxga03-in.huawei.com> for sidr@ietf.org; Fri, 22 Oct 2010 10:38:42 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAO0087E7CIDU@szxga03-in.huawei.com> for sidr@ietf.org; Fri, 22 Oct 2010 10:38:42 +0800 (CST) Received: from z00171239 ([10.110.98.39]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAO00JYV7CHQ8@szxml06-in.huawei.com> for sidr@ietf.org; Fri, 22 Oct 2010 10:38:42 +0800 (CST) Date: Fri, 22 Oct 2010 10:38:41 +0800 From: =?gb2312?B?1cXD8bnz?= To: sidr@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_bntIy21zMeqFHfoLVr/moQ)" Thread-index: Actxkj0OItxM5BTzSe+7VHda1W0v7w== Subject: [sidr] To present a draft about BGP security 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: , X-List-Received-Date: Fri, 22 Oct 2010 02:37:36 -0000 This is a multi-part message in MIME format. --Boundary_(ID_bntIy21zMeqFHfoLVr/moQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi all, I am going to present my work about BGP security on the Beijing meeting. Thanks for Sandra who will arranged this. The draft is attached for your information and its abstract is pasted as follows. Looking forward to your comments. Abstract - This draft proposes a mitigation scheme to protect the data delivery in BGP during the false routing announcements. A new BGP path attribute is defined to Decouple (DBGP) the propagation of a path and the adoption of a path for data forwarding. DBGP does not use suspicious paths to forward data traffic, but still propagates them in the routing system to facilitate attack detection. It works well with attack detection and prevention systems. DBGP can extensively protect data delivery from routing announcements of false sub- prefixes, false origins, false nodes and false links. -- Mingui --Boundary_(ID_bntIy21zMeqFHfoLVr/moQ) Content-type: text/plain; name=draft-zhang-idr-decoupling-01.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-zhang-idr-decoupling-01.txt INTERNET-DRAFT Mingui Zhang Intended Status: Proposed Standard Huawei Expires: April 24, 2011 Bin Liu Tsinghua University Dacheng Zhang Huawei Beichuan Zhang The University of Arizona October 21, 2010 Secure Extension of BGP by Decoupling Path Propagation and Adoption draft-zhang-idr-decoupling-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Zhang Expires April 24, 2011 [Page 1] INTERNET-DRAFT DBGP October 21, 2010 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Zhang Expires April 24, 2011 [Page 2] INTERNET-DRAFT DBGP October 21, 2010 Abstract This draft proposes a mitigation scheme to protect the data delivery in BGP during the false routing announcements. A new BGP path attribute is defined to Decouple (DBGP) the propagation of a path and the adoption of a path for data forwarding. DBGP does not use suspicious paths to forward data traffic, but still propagates them in the routing system to facilitate attack detection. It works well with attack detection and prevention systems. DBGP can extensively protect data delivery from routing announcements of false sub- prefixes, false origins, false nodes and false links. 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]. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3 False Routing Announcements . . . . . . . . . . . . . . . . . . 4 3.1 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Countermeasures . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1 Prevention . . . . . . . . . . . . . . . . . . . . . . 5 3.2.2 Detection . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.3. Traditional Mitigation . . . . . . . . . . . . . . . . 6 3.3 Paradox of Blocking Suspicious Routing Updates and Attack Detection . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. DBGP's Mitigation: Decoupling Path Propagation and Adoption . . 7 4.1 Quarantine Time . . . . . . . . . . . . . . . . . . . . . . 7 5 Protocol Descriptions . . . . . . . . . . . . . . . . . . . . . . 8 5.1 DAS_PATH Attribute Definition . . . . . . . . . . . . . . . 9 5.2 Identification of Suspicious Paths . . . . . . . . . . . . 10 5.3 Propagating Updates . . . . . . . . . . . . . . . . . . . 11 5.4 Choosing Alternative Paths . . . . . . . . . . . . . . . . 12 5.5 Releasing Quarantined Paths . . . . . . . . . . . . . . . 12 6 Security Considerations . . . . . . . . . . . . . . . . . . . 12 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1 Normative References . . . . . . . . . . . . . . . . . . 13 8.2 Informative References . . . . . . . . . . . . . . . . . 14 Appendix A: Empirical Evaluation . . . . . . . . . . . . . . . . 14 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Zhang Expires April 24, 2011 [Page 3] INTERNET-DRAFT DBGP October 21, 2010 1 Introduction The false routing announcement in the global routing system is a serious security problem that can lead to widespread service disruptions. Existing work such as Pretty Good BGP (PGBGP)[PGBGP] blocks suspicious routing updates to protect data delivery. However, such an approach has the side effect of blocking the view of any detection system at the control plane or data plane. As a result, an attack will not be detected and operators will not be alerted to take actions stopping the attack. This draft proposes an extension of BGP, to solve this paradox by decoupling path propagation and adoption in BGP (dubbed as DBGP). 2 Terminology DBGP: Decoupling path propagation and adoption in BGP 3 False Routing Announcements 3.1 Problem False routing announcements can be caused by either inadvertent mis- configurations or malicious attacks. For the ease of exposition, we use "attacker" to refer to the network (or Autonomous System, AS) that makes the false routing announcements regardless of the intention. Based on which part of the routing path is false, such announcements can be classified into five types, each of which has different severity: o Prefix origin: The attacker originates someone else's prefix. Depending on where a network is in the Internet topology, some will choose paths leading to the true origin and some will choose paths leading to the false origin. o Intermediate node: The attacker does not forge the prefix or its origin, but inserts itself into the path as an intermediate AS. Similar to the case of false origin, some networks will choose the correct paths and some the false paths. But usually fewer networks will choose the false path since it is longer than that of false origin attack. o Intermediate link: The attacker forges a new link to bypass some of the ASes to get a shorter path. The shortened path is expected to attract more networks' traffic. o Sub-prefix: The attacker originates a sub-prefix of someone else's prefix. Due to the longest match in routing lookup, a false sub-prefix will win over the original prefix. Thus, all Zhang Expires April 24, 2011 [Page 4] INTERNET-DRAFT DBGP October 21, 2010 traffic destined to the sub-prefix range will be forwarded to the attacker. o Super-prefix: Theoretically the attacker can also announce a false super-prefix, but that will not attract any traffic unless part of the prefix range is unused by the real owner, in which case it is equivalent to announcing a false origin of the unused prefix range. 3.2 Countermeasures The current strategies proposed for the problem of false announcements fall in three categories: prevention, detection and mitigation. 3.2.1 Prevention Prevention schemes (e.g., [SBGP], [SoBGP], and [SPV]) use cryptographic mechanisms to protect the routing updates and let routers reject any forged announcement. Unfortunately no prevention scheme has seen much deployment on the Internet due to the lack of incentives for those first movers. Since crypto-based schemes add significant computational load to routers and require upgrade on software or hardware, individual ISPs need to see immediate benefits to justify the deployment. On the current Internet, however, the first mover's routing announcements will be accepted by other networks without authentication, and adding authentication does not bring any immediate benefit. 3.2.2 Detection The representative detection systems proposed in recent years include [Cyclops], [PHAS], [MyASN], [IAR], [iSPY], [NWatch], [OList], and [LWeight]. Such systems are designed to detect false routing by examining routing updates, probing data paths, cross-checking with registry databases, or a combination of these techniques. Once a false routing case is detected, the owner of the prefix will be notified, and it is expected that the owner will take actions to resolve the problem, which, in today's Internet, usually involves contacting the offending network or its upstream provider to stop the false routing announcements. This process of detection, notification and resolution takes time, ranging from an hour to a day in some past incidents and varying from network to network [NWatch][RIPE]. In the meantime, the damage to data traffic has already been made and malicious attackers may have already achieved their objectives. Zhang Expires April 24, 2011 [Page 5] INTERNET-DRAFT DBGP October 21, 2010 3.2.3. Traditional Mitigation A mitigation schemes attempts to protect the data traffic while an attack is going on. The common approach is to somehow identify abnormal routing updates and block them. As proposed in [PGBGP] and [PGBGP++], a router can examine the content of incoming updates. If an AS path contains unexpected prefix origin or links, it will be suppressed from propagating for a period of time to wait for the network operator's validation. The length of the time is configurable by the network operators. Instead, an alternative path (via trusted prefix origin and links) will be employed for data delivery in the suppression period. After this period,if the path is not proved to be illegal, the router will adopt and announce the new path. PGBGP gives operators certain reaction time to resolve potential false announcements while protecting data delivery in the meantime. When a real attack is detected and resolved, the corresponding false announcement will be withdrawn from the routing system, whereas legitimate announcement will stay in the routing system and eventually be accepted. But blocking false routing announcements can get in the way of detection systems. For instance, on September 22, 2008, a Russian ISP AS8997 hijacked a large number of prefixes as it leaked an entire table [ASN8997]. However, since the upstream ISP of AS8997 blocked the routing updates, detection systems such as MyASN and IAR did not pick up this incident. The attack mainly affected ISPs and users within Russia but largely went unnoticed by prefix owners. Each existing solution has its drawbacks, and none is sufficiently effective by itself. The future of the Internet probably will have several different solutions at the same time, complementary to each other, forming a multi-line defense to protect routing and data delivery before, during, and after attacks. 3.3 Paradox of Blocking Suspicious Routing Updates and Attack Detection It has been realized that a mitigation mechanism and a detection system that complement each other well can be integrated into an effective routing defense solution. For instance, the mitigation mechanism can help the detection system to confine the damage caused by an attack, as the affected data traffic may be vulnerable for hours before the attack can be actually detected by the detection mechanism and be eventually stopped. Also, the mitigation mechanism can also obtain benefit from the detection system because a mitigation mechanism normally cannot identity false routing information accurately with its limited knowledge, resource and time. The output from the detection system can be used to correct the many false positives generated by the mitigation mechanism and also inform Zhang Expires April 24, 2011 [Page 6] INTERNET-DRAFT DBGP October 21, 2010 the prefix owner to resolve the attack. However, there is a dilemma: the mitigation mechanism tries to render the attack ineffective while the detection system needs the attack to be effective in order to detect it. 4. DBGP's Mitigation: Decoupling Path Propagation and Adoption In order to solve the dilemma mentioned in Section 3.3, this document proposes a solution which decouples path propagation and path adoption. In current BGP, the path a router adopts for data forwarding is the same path being propagated to neighbors. As a consequence, upon receiving a suspicious path, a router has to either accept it (no mitigation but good detection) or reject it (good mitigation but no detection). The basic idea of this solution is to extend BGP so that a router can use trusted paths for data forwarding and can also inform its neighbor routers about the suspicious path. In this way, the data traffic is protected while the false routing announcements are being propagated and will likely be monitored by the detection system. In order to achieve this, a new BGP attribute, DAS_PATH, is defined in Section 5 to transport suspicious path information. Additionally, based on historical operating experiences, a false routing announcement can be detected and corrected in a certain period (e.g., one day) after it is launched, and so an announcement will be trusted if it is not withdrawn in a pre-defined period. 4.1 Quarantine Time In mitigation schemes, when a new path is identified as a suspicious one, it will be quarantined (or blocked) from being used for a period of time, which is call the quarantine time and noted as T_q. A router MAY determine the quarantine time itself. Assume there are two routers, R1 and R2. R1 is the downstream of R2, and the quarantine time of R1 and R2 is T1 and T2 respectively. The suspicious path is PATH at R1. There are two possibilities. o T1 is shorter than T2. When T1 expires, PATH becomes trusted by R1 and R1 begins to use it for data delivery. R1 will announce R1-PATH as a legitimate AS path to R2. However, at this time, the path R1-PATH is still being quarantined by R2. o T1 is longer than T2. When T2 expires, R1-PATH becomes trusted by R2. However, R2 can not use this path for data delivery as R1 has not announced R1-PATH as an AS path. It will be cached in the Adj-RIBs-In until the downstream router R1 has announced Zhang Expires April 24, 2011 [Page 7] INTERNET-DRAFT DBGP October 21, 2010 it as an AS path when T1 expires. 5 Protocol Descriptions Take Figure 5.1 for example. A, B, C, and O are DBGP routers residing in different ASes, , X is the attacker and p is the prefix of interest. Before the attack, the preferred path for traffic is ABCO. Here, we use the notation "R1R2...Rn-p" to denote the AS path which is destined to prefix "p" via routers R1, R2, ..., Rn. When X makes a false announcement of X-p to B, B will regard this new path as suspicious because it would divert traffic to an AS(X) that previously was not on the data path (BCO). B will store the suspicious path in its Adj-RIBs-In (The routing tables of an AS router is comprised of three sub-tables: Adj-RIBs-In, Loc-RIB and Adj-RIBs-Out [BGP4]), but keep using the existing path in its Loc-RIB for data forwarding. At the same time, B re-announces its path (BCO) in an update message to A, and encapsulates the new, suspicious path (BX) as an optional transitive attribute which is defined in Section 5.1. After receiving the update message, router A learns this suspicious path, stores it, and propagates it further to its neighbors using the optional attribute the same way. Therefore, the suspicious path is propagated to the Internet while not adopted for data forwarding. This approach enable the detection systems to intercept the suspicious path and notify the prefix owner to take actions. Once the attack is stopped, the false announcements will be withdrawn from the routing system, i.e., deleted or replaced in the Adj-RIBs-In of the involved routers. However, a router realizes that the quarantine time has been expired and the suspicious path is still in the Adj-RIBs-In, the router regards the path as a legitimate one. Hence the DBGP router will install the path in its Loc-RIB for data forwarding and re-announce the path using the regular ASPATH attribute in the update message. For example, if BX-p has been validated as legitimate, B will announce it to A as its AS_PATH. The rest of this section will discuss the design details in new BGP attribute definition, identifying suspicious paths, choosing alternative paths for data forwarding, propagating the paths, and releasing quarantined paths. [X]->p ^ | [A]->[B]->[C]->[O]-p Figure 5.1: Attack Example 1 The rest of this section will discuss the design details in the definition of the new DAS_PATH Attribute, identifying suspicious Zhang Expires April 24, 2011 [Page 8] INTERNET-DRAFT DBGP October 21, 2010 paths, choosing alternative paths for data forwarding, propagating the paths, and releasing quarantined paths. 5.1 DAS_PATH Attribute Definition +----------------------------------+ | Attribute Type (2 octets) | +----------------------------------+ | Attribute Length (1 or 2 octets) | +------------------------------------------------------------------+ | Attribute Value (variable length) | +------------------------------------------------------------------+ Figure 5.2: The DAS_PATH Attribute DAS_PATH (Decoupled AS_PATH) is defined as a new optional transitive Path Attribute (Figure 5.2) to be included in BGP's UPDATE message. The first bit of the Attribute Type is set (1), therefore the attribute is optional. The second bit of Attribute Type is set (1), therefore the attribute is transitive and SHOULD be passed on to other BGP peers. The third and fourth bits are Partial bit and Extended Length bit respectively, which has already been defined in [BGP4]. The Attribute Type code is assigned by the IANA (Internet Assigned Numbers Authority). The definition of Attribute Length is the same as that in [BGP4]. The Attribute Value is composed of a sequence of DAS path segments. Each DAS path segment is encoded as a triple . The path segment type is a 1-octet field with the following two allowable values: Value Segment Type 1 DAS_SET unordered set of ASs a route in the UPDATE message has traversed 2 DAS_SEQUENCE ordered set of ASs a route in the UPDATE message has traversed The path segment length is a 1-octet long field containing the number of ASs in the path segment value field. The path segment value field contains one or more AS numbers, each encoded as a 2-octets long field. When a DAS_PATH is propagated across the network, the operations on DAS_PATH follows the well-known AS_PATH attribute only that DAS_PATH Zhang Expires April 24, 2011 [Page 9] INTERNET-DRAFT DBGP October 21, 2010 is non-mandatory. If a router which does not deploy DBGP receives the update messages containing DAS_PATH attribute, i.e., does not understand this attribute, it will just pass it on to the next router. If its downstream router is a DBGP router, it will be able to pick up the information from this attribute and continue DBGP operations. Therefore DBGP can be incrementally deployed over the Internet. 5.2 Identification of Suspicious Paths For a given prefix p, a path is trusted if it has been staying in the Adj-RIBs-In continuously for the required quarantine time, T_q. All the nodes, links, and origins that appear in trusted paths are trusted components, and the set of them is denoted by trusted(p). This set of trusted components is derived from current contents of all Adj-RIBs-In without using a database to store historical information like PGBGP does. Nodes, links, and origins that do not belong to trusted(p) are said to be suspicious components for this particular prefix p. A new path is suspicious if it contains any suspicious component for its prefix. However, not all suspicious paths need to be explicitly quarantined. DBGP quarantines paths that satisfy the following condition: o A new path is quarantined if and only if it is suspicious, more preferred than other alternative paths, and contains an AS that is not in the current data forwarding path. If the new path is not better than alternative paths, it will not be able to divert any traffic. One may suggest that the attacker can first announce a less preferred path so that DBGP routers will take it as a backup path without suspicion, and then make the primary path fail to trick the router to use the false backup path. But in this case, if the attacker has the control of the primary path, it can already get the traffic without doing this. If the attacker does not have control of the primary path, it will not know when the primary path may fail and which backup path the router will choose, thus the attack will not be effective. If the new path does not introduce any new AS on the data path, it is not quarantined since it does not divert any traffic. In Figure 5.3, when X launches an attack by announcing X-p, this path is not quarantined by B since B already sends its traffic to X. B will accept this path and announces it to A. Assuming ABX-p is more preferred than ACO-p, A will quarantine ABX-p since this new path would divert A's traffic to a new place, AS X, and X is a suspicious origin to A. To reduce the potential false positives in quarantining paths, we Zhang Expires April 24, 2011 [Page 10] INTERNET-DRAFT DBGP October 21, 2010 introduce an optimization rule. If the current best path is replaced by a suspicious path (i.e., the same neighbor that sent the best path previously sends another path to replace it), then the current best path is cached for a short time period. This rule is used to accommodate some unstable prefixes, which may get announced and withdrawn or oscillate between two paths frequently. With this rule, quick re-announcement of a path will not be treated as suspicious. Previous measurement work has shown that (1) most prefixes are stable, and only a small number of prefixes are very unstable; (2) the most popular prefixes are stable; and (3) the most preferred paths are being used by routers for most of the time [BGPpop][Stable][BGPHA]. Therefore, DBGP's criterion for suspicious paths will not generate excessive false positives in reality. The majority of the rest prefixes is only suspicious infrequently. +---------------+ | | | v [A]->[B]->[X]->[C]->[O]-p | p Figure 5.3: Attack Example 2 5.3 Propagating Updates DBGP uses the new BGP attribute, DAS_PATH, to carry the suspicious path in updates. In certain cases DBGP update may need to carry multiple DAS_PATHs. For example, in Figure 5.4, assume C does not deploy DBGP and accepts the false announcement of X-p. When B receives BCX-p, B quarantines this new path and switches to its backup BDO-p. The update from B to A will have BDO as the AS_PATH, and BCX as the DAS_PATH attribute. However, since BDO is suspicious to A as well, A will quarantine BDO and switch to AEFO. Thus the update from A will contain two DAS_PATHs: ABCX and ABDO. Whether an update contains multiple DAS_PATHs depends on the topology and routing policy. In the worst case, the number of DAS_PATH in an update is the same as the AS hop count of the AS_PATH. Given AS e 10 hops, we do not expect this will make DBGP message too large and it is confirmed in our simulations. Zhang Expires April 24, 2011 [Page 11] INTERNET-DRAFT DBGP October 21, 2010 [X]->p ^ | [A]->[B]->[C]->[O]-p | | ^ | | /| | +-->[D]-+ | | | +------->[E]->[F] Figure 5.4: Attack Example 3 5.4 Choosing Alternative Paths When a new path is the most preferred but suspicious, DBGP routers will use an alternative path for data delivery. The question is which alternative path to be chosen. First, if the existing path that is being used for data forwarding is still the best, then the router can stick to that path without any changes. Second, if the existing path in use will have been replaced by the suspicious path, then the router needs to pick an alternative. For example, in Figure 5.4, suppose C does not deploy DBGP and blindly accepts the false announcement X-p. B's existing path BCO-p will be replaced by a suspicious path BCX-p, therefore B needs to temporarily switch to a backup path BDO-p from its Adj-RIBs-In. Third, if there is no alternative path or all alternative paths are labeled as suspicious, then the router err on data delivery by adopting a suspicious path to forward packets. 5.5 Releasing Quarantined Paths If the quarantined paths are false announcements, it is likely that within T_q, the attack will be stopped and these paths being withdrawn from the routing system. In this case, there is no explicit release of the quarantined path. Just the upstream router will send an update with empty DAS_PATH attribute. If T_q has passed and the quarantined path is still in the Adj-RIBs-In, then it is more likely that this is a legitimate path. The router will treat the path as a regular path and make it go through the path selection process. If the path turns out to be the most preferred one, it will be used for data forwarding and trigger routing updates to neighbor routers. 6 Security Considerations The entire document is about security consideration. 7 IANA Considerations Zhang Expires April 24, 2011 [Page 12] INTERNET-DRAFT DBGP October 21, 2010 The attribute type code of DAS_PATH should be assigned by the IANA, which identifies the attribute uniquely from all others. 8 References 8.1 Normative References [PGBGP] J. Karlin, S. Forrest, and J. Rexford, "Pretty Good BGP: Improving BGP by Cautiously Adopting Routes," in Proceedings of IEEE ICNP, 2006. [SBGP] S. Kent, C. Lynn, and K. Seo, "Secure Border Gateway Protocol (SBGP)," IEEE Journal on Selected Areas in Communications, vol. 18, no. 4, pp. 582-592, 2000. [Cyclops] Y.-J. Chi, R. Olivera, and L. Zhang, "Cyclops: the as- level connectivity observatory," SIGCOMM Comput. Commun. Rev., vol. 38, no. 5, pp. 5-16, 2008. [PHAS] M. Lad, D. Massey, D. Pei, B. Zhang, and L. Zhang, "PHAS: A Prefix Hijack Alert System," in 15th USENIX Security Symposium, 2006, pp.153-166. [MyASN] "RIPE myASN System," http://www.ris.ripe.net/myasn.html. [IAR] [Online]. Available: http://iar.cs.unm.edu/ [iSPY] Z. Zhang, Y. Zhang, Y. C. Hu, Z. M. Mao, and R. Bush, "iSPY: Detecting IP Prefix Hijacking on My Own," in Proceedings of ACM SIGCOMM, 2008. [NWatch] G. Siganos and M. Faloutsos, "Neighborhood Watch for Internet Routing: Can We Improve the Robustness of Internet Routing Today?" in Proceedings of IEEE INFOCOM, 2007. [Olist] X. Zhao, D. Pei, L. Wang, D. Massey, A. Mankin, S. Wu, and L. Zhang,"Dection of Invalid Routing Announcement in the Internet," in Proceedings of the IEEE DSN, June 2002. [LWeight] C. Zheng, L. Ji, D. Pei, J. Wang, and P. Francis, "A Light-weight Distributed Scheme for Detecting IP Prefix Hijacks in Real-time," in Proceedings of ACM SIGCOMM, 2007. [SoBGP] J. Ng, "Extensions to BGP to Support Secure Origin BGP," April 2004, ftp://ftp-eng.cisco.com/sobgp/drafts/draft- ng-sobgp-bgp-extensions-02.txt. [SPV] Y.-C. Hu, A. Perrig, and M. Sirbu, "SPV: Secure Path Vector Routing for Securing BGP," in Proceedings of ACM SIGCOMM, 2004. [RIPE] [Online]. Available: http://www.ripe.net/news/study- youtubehijacking.html [ASN8997] "Prefix hijack by ASN 8997." [Online]. Available: http://www.merit.edu/mail.archives/nanog/2008- 09/msg00704.html [BGPpop] J. Rexford, J. Wang, Z. Xiao, and Y. Zhang, "BGP Routing Stability of Popular Destinations," in Proceedings of ACM Zhang Expires April 24, 2011 [Page 13] INTERNET-DRAFT DBGP October 21, 2010 IMC 2002, pp. 197-202. [Stable] K. Butler, P. McDaniel, and W. Aiello, "Optimizing BGP Security by Exploiting Path Stability," in Proceedings of ACM CCS, Alexandria, VA, United States, 2006, pp. 298- 310. [BGPHA] R. V. Oliveira, R. Izhak-Ratzin, B. Zhang, and L. Zhang, "Measurement of Highly Active Prefixes in BGP," in Proceedings of IEEE Globecom,2005. [BGP4] J. W. Stewart, BGP4: Inter-Domain Routing in the Internet. Boston,MA, USA: Addison-Wesley Longman Publishing Co., Inc., 1998. 8.2 Informative References Appendix A: Empirical Evaluation The following aspects of DBGP are tested on the SSFNet-2.0 simulation platform which has implemented BGP4. o The ability to counter different types of attacks o The ability to rectify the false positives o The memory and message overhead The evaluation proves that DBGP can be used to mitigate all types of attacks. Compared with previous mitigation approaches [PGBGP], it reduces the delay of legitimate announcements significantly, only incurs a small amount of messages and memory overhead. Author's Addresses Mingui Zhang Huawei Technologies Co.,Ltd HuaWei Building, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing, 100085 P.R. China Email: mingui@huawei.com Bin Liu Tsinghua University East Main Building RM9-416 Tsinghua University, Hai-Dian District, Beijing, 100084 P.R. China Email: lmyujie@gmail.com Dacheng Zhang Huawei Technologies Co.,Ltd HuaWei Building, No.3 Xinxi Rd., Shang-Di Zhang Expires April 24, 2011 [Page 14] INTERNET-DRAFT DBGP October 21, 2010 Information Industry Base, Hai-Dian District, Beijing, 100085 P.R. China Email: zhangdacheng@huawei.com Beichuan Zhang University of Arizona Computer Science Department, The University of Arizona Tucson, AZ 85721 U.S.A. Email: bzhang@arizona.edu Zhang Expires April 24, 2011 [Page 15] --Boundary_(ID_bntIy21zMeqFHfoLVr/moQ)-- From Sandra.Murphy@cobham.com Fri Oct 22 10:46:35 2010 Return-Path: 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 02F8C3A693C for ; Fri, 22 Oct 2010 10:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgWFCEaABjBk for ; Fri, 22 Oct 2010 10:46:33 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id A80263A6899 for ; Fri, 22 Oct 2010 10:46:28 -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 o9MHm6am013781 for ; Fri, 22 Oct 2010 12:48:06 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o9MHm6E2032413 for ; Fri, 22 Oct 2010 12:48:06 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([74.202.225.34]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Oct 2010 13:48:06 -0400 Date: Fri, 22 Oct 2010 13:47:40 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org In-Reply-To: Message-ID: References: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 22 Oct 2010 17:48:06.0628 (UTC) FILETIME=[487BE240:01CB7211] Subject: Re: [sidr] WG adoption of draft-reynolds-rpki-ltamgmt-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: , X-List-Received-Date: Fri, 22 Oct 2010 17:46:35 -0000 The chairs see three positive responses to this call for adoption and no negative responses. The chairs are satisfied that there is wg consensus to adopt this work. The authors are requested to submit the -00 draft when the submission process permits. --Sandy, co chair wimple on On Mon, 27 Sep 2010, Sandra Murphy wrote: > The wg chairs have received a request that the working group adopt the draft > "Local Trust Anchor Management for the Resource Public Key Infrastructure" > as a wg work item. > > This material of this draft was presented at > > IETF 75 > (http://www.ietf.org/proceedings/75/slides/sidr-3/sidr-3_files/v3_document.htm) > IETF 76 (http://www.ietf.org/proceedings/76/slides/sidr-11.pdf) > and IETF 77 > (http://www.ietf.org/proceedings/77/slides/sidr-6/sidr-6_files/v3_document.htm) > > A draft was requested by the audience at IETF 75. The -00 version was > submitted in Mar 2010 and wg adoption was requested. Response to that > request did not indicate wg consensus - the responses were positive but there > were only three replies. > > A new version of the draft is available at > http://www.ietf.org/id/draft-reynolds-rpki-ltamgmt-01.txt > http://tools.ietf.org/html/draft-reynolds-rpki-ltamgmt-01 > > The authors request that the wg consider this new version again for wg > adoption. > > Recall that active support for adoption is necessary for the wg chairs to > judge acceptance as a working group work item, so silence works against > adoption. The wg chairs also want to know who would be willing to work on the > draft. The wg chairs also want to know if you oppose adoption. > > Please respond to the list, giving your recommendation for or against > adoption of the draft as a wg work item as well as your intention to work on > the draft if adopted. The call for adoption will end in two weeks on 11 Oct > 2010. > > --Sandy, wg chair bowler on > > > > From christopher.morrow@gmail.com Fri Oct 22 12:41:18 2010 Return-Path: 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 8EDA83A6916 for ; Fri, 22 Oct 2010 12:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.232 X-Spam-Level: X-Spam-Status: No, score=-102.232 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vv2hk56j44ib for ; Fri, 22 Oct 2010 12:41:17 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 5BBBD28C147 for ; Fri, 22 Oct 2010 12:38:38 -0700 (PDT) Received: by eyd10 with SMTP id 10so685287eyd.31 for ; Fri, 22 Oct 2010 12:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=a3lHnsvX74ehU0Hcz2demCbi/CSOY4AypfR789gsCPk=; b=jRqXnKSRgtV0aQFgeTd/Icb2Ru7urFgUDXp4fYEGorb0EBwxqROCKCHY28oiL+orX8 GOPYB7r3kDs29LAPlCk7Bn/5gYlBU1NMXGXoreDJ5SVmdqv5Ea2NUIzB02bdIfYMQpr+ Z2vrh0doAgvqDydzGFV1OOSglGN4wHjRjqCB4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=bsiIs4XNEbU5y5CyRBDkCi3JA1i4pUN1pVcdPhqhKtI5p5txPIwP713PWT7dby2V8v adNgeA4inCYHnEh25Y2oQ3UDL9CPL9G70eqJM9MmTCUhgAkGQfqfCZmjcONvOna4dSy0 qyUMt+Ynh2bdmjjUKym5e6Of/Vow0JKoZqIfo= MIME-Version: 1.0 Received: by 10.213.35.6 with SMTP id n6mr3712882ebd.0.1287776414620; Fri, 22 Oct 2010 12:40:14 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.213.10.10 with HTTP; Fri, 22 Oct 2010 12:40:14 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Oct 2010 15:40:14 -0400 X-Google-Sender-Auth: nJVJPMRsLBDajB09T2JkWx4Imyk Message-ID: From: Christopher Morrow To: sidr@ietf.org, Sandra Murphy , Chris Morrow , pmohapat@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [sidr] Call for WG Adoption - draft-pmohapat-sidr-origin-validation-signaling-00 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: , X-List-Received-Date: Fri, 22 Oct 2010 19:41:18 -0000 Howdy, with 4 + votes and 0 - votes, consider this adopted as a WG Item, could the author(s) please kick out a -00 doc with the proper titling? -Chris co-chair-finger-puppet == on On Thu, Oct 7, 2010 at 9:49 PM, Christopher Morrow wrote: > Howdy WG-folk, > Pradosh has asked that we consider: > > > for adoption in SIDR, could we hear back before 10/22/2010 pls? > > -Chris > (wg-chair-belt-buckle == on) > From kseo@bbn.com Fri Oct 22 13:20:23 2010 Return-Path: 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 8E4ED3A6818 for ; Fri, 22 Oct 2010 13:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=0.358, 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 hOW50bx0-gNb for ; Fri, 22 Oct 2010 13:20:22 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 1D7233A68C5 for ; Fri, 22 Oct 2010 13:20:22 -0700 (PDT) Received: from dhcp89-089-198.bbn.com ([128.89.89.198]:49204) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P9O7k-000621-84; Fri, 22 Oct 2010 16:22:00 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <13311E83-BBFC-4F4E-9195-D0908FAAD27D@virtualized.org> Date: Fri, 22 Oct 2010 16:21:55 -0400 To: Randy Bush From: Karen Seo Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@core3.amsl.com Subject: Re: [sidr] testbed sprint sat before ietf 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: , X-List-Received-Date: Fri, 22 Oct 2010 20:20:23 -0000 Randy et al, Could someone help us get subscribed to the testbed mailing list? Two of my colleagues tried to subscribe via majordomo several days to a week ago. One received no reply; the other received a message saying his request was on hold waiting for approval. I'd like to subscribe too. The 3 email addresses to be added are: achi@bbn.com mreynolds@bbn.com kseo@bbn.com Thank you, Karen > >> saturday november 6, we will be doing an rpki testbed workshop and >>> hackathon in the ietf terminal room. bring unix/macosx/linux laptop, >>> or access to a system on which you can do the install and configure. >> For public information, what code will you be using for this? > >the open source full implementation (rpki, up/down, publication, relying >party, gui, mocha ice cream), implementation at http://www.rpki.net/. >and this goes all the way to some test routers to do origin validation. > >we hope to have easy-install packages in time, as opposed to the current >python install. > >you may join the ongoing active testbed now, or participate remotely on >the 6th. there is a mailing list. we just converted to non-tls per >sidr discussion in maastricht. > >randy >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From root@core3.amsl.com Sun Oct 24 16:45:06 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8F4413A67E4; Sun, 24 Oct 2010 16:45:02 -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: <20101024234505.8F4413A67E4@core3.amsl.com> Date: Sun, 24 Oct 2010 16:45:02 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-keyroll-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: , X-List-Received-Date: Sun, 24 Oct 2010 23:45:07 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : CA Key Rollover in the RPKI Author(s) : G. Huston, et al. Filename : draft-ietf-sidr-keyroll-03.txt Pages : 10 Date : 2010-10-24 This document describes an algorithm to allow an entity who undertakes the role of a Certification Authority in the Resource Public Key Infrastructure to perform a rollover of its key pair. This document also notes the requirements placed on Relying Parties who maintain a local cache of the objects that have been published in the distributed Resource Public Key Infrastructure repository publication structure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-keyroll-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-keyroll-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-24164118.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 25 16:15:05 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 955D03A6C03; Mon, 25 Oct 2010 16:15:03 -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: <20101025231503.955D03A6C03@core3.amsl.com> Date: Mon, 25 Oct 2010 16:15:03 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-ta-05.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: , X-List-Received-Date: Mon, 25 Oct 2010 23:15:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Resource Certificate PKI (RPKI) Trust Anchor Locator Author(s) : G. Huston, et al. Filename : draft-ietf-sidr-ta-05.txt Pages : 8 Date : 2010-10-25 This document defines a Trust Anchor Locator for the Resource Certificate Public Key Infrastructure (RPKI). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-ta-05.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-ta-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-25161004.I-D@ietf.org> --NextPart-- From Sandra.Murphy@cobham.com Wed Oct 27 13:35:51 2010 Return-Path: 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 0C7443A69EE for ; Wed, 27 Oct 2010 13:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhqM5HyflAiD for ; Wed, 27 Oct 2010 13:35:50 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id F0E8C3A68ED for ; Wed, 27 Oct 2010 13:35:49 -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 o9RKbdcB018119 for ; Wed, 27 Oct 2010 15:37:39 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o9RKbeNV004170 for ; Wed, 27 Oct 2010 15:37:40 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.119]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Oct 2010 16:37:39 -0400 Date: Wed, 27 Oct 2010 16:37:37 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org In-Reply-To: Message-ID: References: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 27 Oct 2010 20:37:39.0763 (UTC) FILETIME=[CC35D830:01CB7616] Subject: Re: [sidr] agenda request 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: , X-List-Received-Date: Wed, 27 Oct 2010 20:35:51 -0000 I have received only a few requests for agenda slots. I'll be turning in a first draft agenda this evening. Any additional requests to be added to the agenda are still permitted - final agendas are due 01 Nov 2010. --Sandy On Thu, 21 Oct 2010, Sandra Murphy wrote: > The draft agenda for the upcoming wg meeting is due next Wed, 2400 UTC. > > Anyone who wishes to present at this meeting please send a message to the > list or chairs by next Wed. > > --Sandy > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From Sandra.Murphy@cobham.com Thu Oct 28 08:52:11 2010 Return-Path: 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 F19993A67FD for ; Thu, 28 Oct 2010 08:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tODAU4YUPPxO for ; Thu, 28 Oct 2010 08:52:09 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id A26B83A67E7 for ; Thu, 28 Oct 2010 08:52:09 -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 o9SFs13W029823 for ; Thu, 28 Oct 2010 10:54:01 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o9SFs1XY000891 for ; Thu, 28 Oct 2010 10:54:01 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.119]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Oct 2010 11:54:01 -0400 Date: Thu, 28 Oct 2010 11:53:58 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 28 Oct 2010 15:54:01.0192 (UTC) FILETIME=[56C3BE80:01CB76B8] Subject: [sidr] about reserved address space, anycast addresses and such 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: , X-List-Received-Date: Thu, 28 Oct 2010 15:52:11 -0000 This message is about a technical question, not a wg process question. I send this message as a typical wg member, with no special wg chairness involved, no special items of wg ceremonial vestments donned, etc. I came across a couple of special address space cases recently. There are some special addresses that are reserved by/to IANA. We've discussed a few of the more well known, e.g. the private address space (10/8, etc) and local addresses (127/8, etc). For the most part, these addressees are not intended to be globally routed, so ROAs for these spaces are not meaningful. In full deployment, the prefix holder (IANA) might omit producing a ROA for such address space. In incremental deployment, that would allow anyone to originate a route to the prefix. For address space that is not supposed to be announced, we've discussed things like producing a ROA to AS 0 (and BOAs) to cause mis-originations to be evaluated as "invalid" rather than "unkown". That works for these not-globally-routed cases as well, with IANA signing the ROA. But not all reserved address space is private. In particular, there is a IANA reserved space for 6to4 routers, the 192.88.99.0/24 prefix. It is intended to be carried in BGP updates between ASs, if I read RFC3068 correctly. This space is also a special case in that is supposed to be an anycasted address. Anycasted addresses that have specific individual prefix holders present little problem to the RPKI. The prefix holder creates a ROA for each AS that could originate the prefix. But in the 6to4 address case (if I read correctly), any AS is allowed to use that address space. Would IANA sign ROAs for that space? What ASs would be in the ROA for that address space? Every AS? How would that prevent hijacking? The security considerations section in RFC3068 is nifty keen, especially the last sentence: The generic security risks of 6to4 tunneling and the appropriate protections are discussed in [RFC3056]. The anycast technique introduces an additional risk, that a rogue router or a rogue AS would introduce a bogus route to the 6to4 anycast prefix, and thus divert the traffic. IPv4 network managers have to guarantee the integrity of their routing to the 6to4 anycast prefix in much the same way that they guarantee the integrity of the generic v4 routing. [There is another range of addresses that has no defined semantics as yet and so might prove problematic to RPKI protections - the special use range of RFC5736/5735 192.0.0.0/24 - This block is reserved for IETF protocol assignments. We won't know until someone attempts to register something in this range (currently the registry is empty) whether it will fit nicely with the RPKI model. Cross that bridge when we come to it.] --Sandy, garden variety wg member From kotikalapudi.sriram@nist.gov Thu Oct 28 09:02:21 2010 Return-Path: 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 0CDEB3A67E7 for ; Thu, 28 Oct 2010 09:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.388 X-Spam-Level: X-Spam-Status: No, score=-6.388 tagged_above=-999 required=5 tests=[AWL=0.211, 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 rjipinh1THPD for ; Thu, 28 Oct 2010 09:02:20 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 0DF4D3A683C for ; Thu, 28 Oct 2010 09:02:19 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o9SG3kwp032458; Thu, 28 Oct 2010 12:03:46 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 28 Oct 2010 12:03:46 -0400 From: "Sriram, Kotikalapudi" To: Christopher Morrow , Geoff Huston Date: Thu, 28 Oct 2010 12:03:34 -0400 Thread-Topic: [sidr] WG LC request for draft-ietf-sidr-roa-validation-08.txt Thread-Index: ActtdNA6+XKs/kVUQcKAnfFC3wilDwJRHZAg Message-ID: References: <10CCBFA0-B4C5-412B-B352-2779230944BD@apnic.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Cc: Sandra Murphy , "sidr@ietf.org wg" Subject: Re: [sidr] WG LC request for draft-ietf-sidr-roa-validation-08.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: , X-List-Received-Date: Thu, 28 Oct 2010 16:02:21 -0000 http://www.ietf.org/mail-archive/web/sidr/current/msg02020.html http://www.ietf.org/mail-archive/web/sidr/current/msg02017.html > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of C= hristopher > Morrow > Sent: Saturday, October 16, 2010 4:58 PM > To: Geoff Huston > Cc: Sandra Murphy; sidr@ietf.org wg > Subject: Re: [sidr] WG LC request for draft-ietf-sidr-roa-validation-08.t= xt >=20 > This was sent along (the requested LC message) to the list today... > see you in 2 weeks (at decision time) >=20 > -chris > (wg-co-chair-cycling-shoes =3D=3D on) >=20 > On Fri, Oct 15, 2010 at 1:38 AM, Geoff Huston wrote: > > Let me try that once again! > > > > The authors have revised the text relating to the definition of the ori= gin AS to be > conformant to the current BGP specification, namely that if the AGGREGATO= R path > attribute is present it "contains the last AS number that formed the aggr= egate route" > [RFC4271]. If this path attribute is not present the draft defines the or= igin AS as the AS > preceding the AS_SET, which is a definition that has been drawn from the = earlier WG mail > thread on this topic > > > > The intention here is not to impose criteria that differ from RFC4271, = and define the > origin AS in an manner that if an AS undertakes proxy aggregation in conf= ormance with > RFC4271 then this definition of origin AS will correctly identify the agg= regator AS as the > origin AS. This is slightly different from the various suggestions seen s= o far on the WG > mailing list, but it is believed that this refines those suggestions in t= he light of a careful > reading of the relevant sections of RFC 4271. > > > > The authors do not plan any further revisions of this document, and, ac= cordingly, would > like once more to request a WG Last Call of the -08 rev of the document. > > > > > > thanks, > > > > =A0 Geoff From kotikalapudi.sriram@nist.gov Thu Oct 28 09:32:55 2010 Return-Path: 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 3B4163A6834 for ; Thu, 28 Oct 2010 09:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.398 X-Spam-Level: X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 NaqbKKvqnzMI for ; Thu, 28 Oct 2010 09:32:53 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 919AF3A681B for ; Thu, 28 Oct 2010 09:32:53 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o9SGYR4K022656; Thu, 28 Oct 2010 12:34:27 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 28 Oct 2010 12:34:27 -0400 From: "Sriram, Kotikalapudi" To: Christopher Morrow , Geoff Huston Date: Thu, 28 Oct 2010 12:34:22 -0400 Thread-Topic: [sidr] WG LC request for draft-ietf-sidr-roa-validation-08.txt Thread-Index: ActtdNA6+XKs/kVUQcKAnfFC3wilDwJRRBUg Message-ID: References: <10CCBFA0-B4C5-412B-B352-2779230944BD@apnic.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Cc: Sandra Murphy , "sidr@ietf.org wg" Subject: Re: [sidr] WG LC request for draft-ietf-sidr-roa-validation-08.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: , X-List-Received-Date: Thu, 28 Oct 2010 16:32:55 -0000 Geoff: Sorry about the previous email with an incomplete message. I hit some key accidentally and off it went :( As you know, the following email messages between you, Chris and=20 myself are relevant to your 08-rev as well. http://www.ietf.org/mail-archive/web/sidr/current/msg02020.html http://www.ietf.org/mail-archive/web/sidr/current/msg02017.html http://www.ietf.org/mail-archive/web/sidr/current/msg02015.html Consistent with the above messages, I would like to suggest removing the algorithmic aspects=20 of how to handle updates with AS_SET. Instead wording along the lines (you may fine tune the wording) should be included: It is recognized that in a very small percentage of updates, proxy aggregation with inclusion AS_SET attribute is found. There is a proposal under consideration in the IDR WG to deprecate AS_SETs. Description of the part of the algorithm that deals with origin validation of updates with AS_SET is deferred=20 pending outcome of the IDR WG action on this issue. Sriram > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of C= hristopher > Morrow > Sent: Saturday, October 16, 2010 4:58 PM > To: Geoff Huston > Cc: Sandra Murphy; sidr@ietf.org wg > Subject: Re: [sidr] WG LC request for draft-ietf-sidr-roa-validation-08.t= xt >=20 > This was sent along (the requested LC message) to the list today... > see you in 2 weeks (at decision time) >=20 > -chris > (wg-co-chair-cycling-shoes =3D=3D on) >=20 > On Fri, Oct 15, 2010 at 1:38 AM, Geoff Huston wrote: > > Let me try that once again! > > > > The authors have revised the text relating to the definition of the ori= gin AS to be > conformant to the current BGP specification, namely that if the AGGREGATO= R path > attribute is present it "contains the last AS number that formed the aggr= egate route" > [RFC4271]. If this path attribute is not present the draft defines the or= igin AS as the AS > preceding the AS_SET, which is a definition that has been drawn from the = earlier WG mail > thread on this topic > > > > The intention here is not to impose criteria that differ from RFC4271, = and define the > origin AS in an manner that if an AS undertakes proxy aggregation in conf= ormance with > RFC4271 then this definition of origin AS will correctly identify the agg= regator AS as the > origin AS. This is slightly different from the various suggestions seen s= o far on the WG > mailing list, but it is believed that this refines those suggestions in t= he light of a careful > reading of the relevant sections of RFC 4271. > > > > The authors do not plan any further revisions of this document, and, ac= cordingly, would > like once more to request a WG Last Call of the -08 rev of the document. > > > > > > thanks, > > > > =A0 Geoff From gih@apnic.net Thu Oct 28 12:51:45 2010 Return-Path: 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 D291D3A68DA for ; Thu, 28 Oct 2010 12:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.316 X-Spam-Level: X-Spam-Status: No, score=-101.316 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QM7jwCJzw+W6 for ; Thu, 28 Oct 2010 12:51:45 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 7E0E23A6774 for ; Thu, 28 Oct 2010 12:51:43 -0700 (PDT) Received: from dhcp75.potaroo.net (eth143.act.adsl.internode.on.net [203.16.208.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 4A723D58BC; Fri, 29 Oct 2010 05:53:34 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Fri, 29 Oct 2010 06:52:17 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <10CCBFA0-B4C5-412B-B352-2779230944BD@apnic.net> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1081) Cc: Christopher Morrow , Sandra Murphy , "sidr@ietf.org wg" Subject: Re: [sidr] WG LC request for draft-ietf-sidr-roa-validation-08.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: , X-List-Received-Date: Thu, 28 Oct 2010 19:51:46 -0000 Hi Srinam, I don't believe that wording is appropriate for an RFC. The wording that = is consistent with the current BGP spec is actually in the -07 version. regards, Geoff On 29/10/2010, at 3:34 AM, Sriram, Kotikalapudi wrote: > Geoff: >=20 > Sorry about the previous email with an incomplete message. > I hit some key accidentally and off it went :( >=20 > As you know, the following email messages between you, Chris and=20 > myself are relevant to your 08-rev as well. >=20 > http://www.ietf.org/mail-archive/web/sidr/current/msg02020.html > http://www.ietf.org/mail-archive/web/sidr/current/msg02017.html > http://www.ietf.org/mail-archive/web/sidr/current/msg02015.html >=20 > Consistent with the above messages, > I would like to suggest removing the algorithmic aspects=20 > of how to handle updates with AS_SET. > Instead wording along the lines (you may fine tune the wording) > should be included: > It is recognized that in a very small percentage of updates, > proxy aggregation with inclusion AS_SET attribute is found. > There is a proposal under consideration in the IDR WG > to deprecate AS_SETs. Description of the part of the algorithm > that deals with origin validation of updates with AS_SET is deferred=20= > pending outcome of the IDR WG action on this issue. >=20 > Sriram >=20 >> -----Original Message----- >> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf = Of Christopher >> Morrow >> Sent: Saturday, October 16, 2010 4:58 PM >> To: Geoff Huston >> Cc: Sandra Murphy; sidr@ietf.org wg >> Subject: Re: [sidr] WG LC request for = draft-ietf-sidr-roa-validation-08.txt >>=20 >> This was sent along (the requested LC message) to the list today... >> see you in 2 weeks (at decision time) >>=20 >> -chris >> (wg-co-chair-cycling-shoes =3D=3D on) >>=20 >> On Fri, Oct 15, 2010 at 1:38 AM, Geoff Huston wrote: >>> Let me try that once again! >>>=20 >>> The authors have revised the text relating to the definition of the = origin AS to be >> conformant to the current BGP specification, namely that if the = AGGREGATOR path >> attribute is present it "contains the last AS number that formed the = aggregate route" >> [RFC4271]. If this path attribute is not present the draft defines = the origin AS as the AS >> preceding the AS_SET, which is a definition that has been drawn from = the earlier WG mail >> thread on this topic >>>=20 >>> The intention here is not to impose criteria that differ from = RFC4271, and define the >> origin AS in an manner that if an AS undertakes proxy aggregation in = conformance with >> RFC4271 then this definition of origin AS will correctly identify the = aggregator AS as the >> origin AS. This is slightly different from the various suggestions = seen so far on the WG >> mailing list, but it is believed that this refines those suggestions = in the light of a careful >> reading of the relevant sections of RFC 4271. >>>=20 >>> The authors do not plan any further revisions of this document, and, = accordingly, would >> like once more to request a WG Last Call of the -08 rev of the = document. >>>=20 >>>=20 >>> thanks, >>>=20 >>> Geoff -- Geoff Huston Chief Scientist, APNIC +61 7 3858 3100 gih@apnic.net From terry.manderson@icann.org Thu Oct 28 16:48:31 2010 Return-Path: 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 2B2B33A67B3 for ; Thu, 28 Oct 2010 16:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.305 X-Spam-Level: X-Spam-Status: No, score=-106.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ITXDbkzqlja for ; Thu, 28 Oct 2010 16:48:30 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 06C673A6971 for ; Thu, 28 Oct 2010 16:48:30 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 28 Oct 2010 16:50:23 -0700 From: Terry Manderson To: Sandra Murphy , "sidr@ietf.org" Date: Thu, 28 Oct 2010 16:50:23 -0700 Thread-Topic: [sidr] about reserved address space, anycast addresses and such Thread-Index: Act2uGVd711QeRnOQyOqd+7mkmtHgQAQn1/z Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] about reserved address space, anycast addresses and such 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: , X-List-Received-Date: Thu, 28 Oct 2010 23:48:31 -0000 Hi Sandy, On 29/10/10 1:53 AM, "Sandra Murphy" wrote: >=20 > I came across a couple of special address space cases recently. >=20 > There are some special addresses that are reserved by/to IANA. We've > discussed a few of the more well known, e.g. the private address space > (10/8, etc) and local addresses (127/8, etc). >=20 > For the most part, these addressees are not intended to be globally > routed, so ROAs for these spaces are not meaningful. A ROA can only exist publically if the resource has been allocated to the entity, setting aside discussion of the local TA for a moment. So really th= e only place a reserved or special ROA (AS0 or otherwise) would be publically created is the IANA. > In full deployment, > the prefix holder (IANA) might omit producing a ROA for such address > space. In incremental deployment, that would allow anyone to originate a > route to the prefix. For address space that is not supposed to be > announced, we've discussed things like producing a ROA to AS 0 (and BOAs) > to cause mis-originations to be evaluated as "invalid" rather than > "unkown". That works for these not-globally-routed cases as well, with > IANA signing the ROA. I agree with that summary. >=20 > But not all reserved address space is private. In particular, there is a > IANA reserved space for 6to4 routers, the 192.88.99.0/24 prefix. It is > intended to be carried in BGP updates between ASs, if I read RFC3068 > correctly. >=20 > This space is also a special case in that is supposed to be an anycasted > address. Anycasted addresses that have specific individual prefix holder= s > present little problem to the RPKI. The prefix holder creates a ROA for > each AS that could originate the prefix. But in the 6to4 address case (i= f > I read correctly), any AS is allowed to use that address space. Would > IANA sign ROAs for that space? What ASs would be in the ROA for that > address space? Every AS? How would that prevent hijacking? Personally, and speaking only for myself, I would rather not see a ROA of any type created for such prefixes as the 6to4 allocation. I would much rather have it flagged as "unknown" over "Valid from 'ANY AS'". The relying party then has a visible and conscious decision to make. >=20 > The security considerations section in RFC3068 is nifty keen, especially > the last sentence: >=20 > The generic security risks of 6to4 tunneling and the appropriate > protections are discussed in [RFC3056]. The anycast technique > introduces an additional risk, that a rogue router or a rogue AS > would introduce a bogus route to the 6to4 anycast prefix, and thus > divert the traffic. IPv4 network managers have to guarantee the > integrity of their routing to the 6to4 anycast prefix in much the > same way that they guarantee the integrity of the generic v4 routing. >=20 Right, its really passing the decision and responsibility to the relying party (IPv4 network managers). So at some point in the near future it would be worth cataloging the expected IANA issued RPKI objects for the internet number resources IANA retains (as opposed to the numbers the IANA allocated to the RIRs through certification). Some would be candidates for a ROA with AS0, others might b= e best handled by leaving them in the unknown state. Cheers Terry From kotikalapudi.sriram@nist.gov Fri Oct 29 07:46:20 2010 Return-Path: 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 D28653A6A46 for ; Fri, 29 Oct 2010 07:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.407 X-Spam-Level: X-Spam-Status: No, score=-6.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 ZWXvO6C5Zr65 for ; Fri, 29 Oct 2010 07:46:19 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 6969D3A6899 for ; Fri, 29 Oct 2010 07:46:14 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o9TElo9S002245; Fri, 29 Oct 2010 10:47:50 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 29 Oct 2010 10:47:49 -0400 From: "Sriram, Kotikalapudi" To: Geoff Huston Date: Fri, 29 Oct 2010 10:47:37 -0400 Thread-Topic: [sidr] WG LC request for draft-ietf-sidr-roa-validation-08.txt Thread-Index: Act22eAuU/2BKnNMSCKlaSkFvhG/PAAmt97g Message-ID: References: <10CCBFA0-B4C5-412B-B352-2779230944BD@apnic.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Cc: Christopher Morrow , Sandra Murphy , "sidr@ietf.org wg" Subject: Re: [sidr] WG LC request for draft-ietf-sidr-roa-validation-08.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: , X-List-Received-Date: Fri, 29 Oct 2010 14:46:21 -0000 Geoff: The following wording is in both -07 and -08 versions: "If the final path segment of the AS_PATH is of type AS_SET, indicating that the route is an aggregate, then the origin AS is taken as the AS component of the AGGREGATOR attribute [RFC4271], if present." In light of all our discussions, why not replace the above wording with: "If the final path segment of the AS_PATH is of type AS_SET, indicating that the route is an aggregate, then the route's origin AS cannot be determined." That would clearly avoid the new attack vector on normal prefixes that I have explained before. There is no point in allowing an additional new type of attack possibility on 300K or more normal prefixes (i.e., those originated without AS_SET and proxy aggregation) in order to somehow cater to miniscule prefix-updates with AS_SET. Sriram > -----Original Message----- > From: Geoff Huston [mailto:gih@apnic.net] > Sent: Thursday, October 28, 2010 3:52 PM > To: Sriram, Kotikalapudi > Cc: Christopher Morrow; Sandra Murphy; sidr@ietf.org wg > Subject: Re: [sidr] WG LC request for draft-ietf-sidr-roa-validation-08.txt > > Hi Srinam, > > I don't believe that wording is appropriate for an RFC. The wording that is consistent with > the current BGP spec is actually in the -07 version. > > regards, > > Geoff > > On 29/10/2010, at 3:34 AM, Sriram, Kotikalapudi wrote: > > > Geoff: > > > > Sorry about the previous email with an incomplete message. > > I hit some key accidentally and off it went :( > > > > As you know, the following email messages between you, Chris and > > myself are relevant to your 08-rev as well. > > > > http://www.ietf.org/mail-archive/web/sidr/current/msg02020.html > > http://www.ietf.org/mail-archive/web/sidr/current/msg02017.html > > http://www.ietf.org/mail-archive/web/sidr/current/msg02015.html > > > > Consistent with the above messages, > > I would like to suggest removing the algorithmic aspects > > of how to handle updates with AS_SET. > > Instead wording along the lines (you may fine tune the wording) > > should be included: > > It is recognized that in a very small percentage of updates, > > proxy aggregation with inclusion AS_SET attribute is found. > > There is a proposal under consideration in the IDR WG > > to deprecate AS_SETs. Description of the part of the algorithm > > that deals with origin validation of updates with AS_SET is deferred > > pending outcome of the IDR WG action on this issue. > > > > Sriram > >