From sidr-bounces@ietf.org Thu Oct 05 11:33:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVVDw-0002GR-3L; Thu, 05 Oct 2006 11:33:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVVDu-0002Fm-PW for sidr@ietf.org; Thu, 05 Oct 2006 11:33:22 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVVDs-000294-GY for sidr@ietf.org; Thu, 05 Oct 2006 11:33:22 -0400 Received: from yxu1a19.hopcount.ca ([199.212.90.19]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVVDr-000Lor-OE for sidr@ietf.org; Thu, 05 Oct 2006 15:33:20 +0000 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sidr@ietf.org From: Joe Abley Date: Thu, 5 Oct 2006 11:33:07 -0400 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [Sidr] comments on draft-ietf-sidr-res-certs-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org I have read draft-ietf-sidr-res-certs-02, and have some comments. I have decidedly little experience of the guts of X.509 certificates, but some practical experience of routing systems and resource assignment. The following comments (and the absence of comments on X. 509 minutiae) should be read in that context. I have assumed that the intended audience for this draft includes organisations which assign resources to others (the IANA, RIRs, NIRs, LIRs) and those which might have a reason to validate a certificate for a particular resource (RPSL repositories, transit providers being asked to announce new customer prefixes). Both these groups' perspectives seem to be well-covered in this document. There are no examples provided in the document of how these certificates might be used, once generated. I realise that's a much wider topic of which a description of the certificates themselves is a small component; however, some examples might be useful in the event that this document is ever read in isolation. Section 3 contains fields described using phrases such as "positive integer" without including information about the field width -- in other words, there's no comment on the maximum value that might be stored. Perhaps this is implicit in the design of X.509, but since I couldn't find any mention of it in RFC 3280 either, I thought I'd make the observation here. In section 3.7 the draft alludes to possible reasons for a resource certificate's "valid to" field to extend beyond that in the superior certificate. It's not clear to me why this should be the case. I don't have strong opinions about this, but it seems possible that an example would lend some clarity. In section 3.8 the draft uses normative language to specify key sizes. Should it not instead specify *minimum* key sizes, or is it an explicit goal to specify an absolute size? (Would it be bad, for example, if I chose to use a 4096 bit key instead of the 2048 bit key I SHOULD use?) Section 3.9.1 has a typo, maybe ("cA" vs. "CA")? Section 3.9.2 is missing a space between the "of" and the "[RFC3280]" at the end of the last paragraph. In section 3.9.5, why is an rsync URI preferred over any other kind of URI? There's no normative language surrounding the stated preference. Is a preference lacking normative teeth worth mentioning? If so, might it be an idea to indicate that other URIs MAY be used instead? In section 3.9.6 and 3.9.7 the rsync URI is specified again, this time as a MUST with a note that other URIs MAY be used. While I'm still interested in why the rsync URI is a MUST, the language and the associated MAY make these sections clearer than 3.9.5. In general, the draft seems to systematically misspell words like "authorise" and "recognise", in defiance of the authors' Commonwealth origins. Also I'm fairly sure "unexpired" is not a word; "non- expired" seems better. :-) Joe _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Oct 05 11:52:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVVWA-0003IG-NJ; Thu, 05 Oct 2006 11:52:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVVW9-0003HV-Qx for sidr@ietf.org; Thu, 05 Oct 2006 11:52:13 -0400 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVVW5-0005f7-H5 for sidr@ietf.org; Thu, 05 Oct 2006 11:52:13 -0400 Received: by postman.ripe.net (Postfix, from userid 4008) id A8856240EE; Thu, 5 Oct 2006 17:51:48 +0200 (CEST) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id 81BF223F2B for ; Thu, 5 Oct 2006 17:51:48 +0200 (CEST) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by herring.ripe.net (Postfix) with ESMTP id 743522F5A3 for ; Thu, 5 Oct 2006 17:51:48 +0200 (CEST) Message-Id: <7.0.1.0.2.20061005175025.034d98c8@ripe.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 05 Oct 2006 17:51:45 +0200 To: sidr@ietf.org From: Henk Uijterwaal Subject: Re: [Sidr] comments on draft-ietf-sidr-res-certs-02 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000000 / -4.4 X-RIPE-Signature: 3f4fb6ef444478c17892f6c1355b1a9f X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org Sandy and others, I read the draft and it looks fine, though I immediately admit that I didn't look at every tiny detail. The draft is being used by the teams working on prototype implementation of this, at APNIC and RIPE NCC (and others). The engineer working on this here, said the draft is fine but there are some details to be worked out. This is being discussed on the list that the APNIC and RIPE NCC folks use to discuss their work, rather than the IETF SIDR list. A number of things brought up there, actually made it into the -02 version of the draft. (I agree that the discussion should take place on the IETF list but don't ask me how to get it there.) Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ 1160438400 + 381600 = 1160820000. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Oct 06 06:02:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVmWW-0004Gd-6U; Fri, 06 Oct 2006 06:01:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVmWV-0004GY-Nt for sidr@ietf.org; Fri, 06 Oct 2006 06:01:43 -0400 Received: from mint.apnic.net ([202.12.29.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVmWT-0000NL-N0 for sidr@ietf.org; Fri, 06 Oct 2006 06:01:43 -0400 Received: from [192.168.1.35] (gw.home.zots.net [59.167.208.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 24BD8D5F31; Fri, 6 Oct 2006 20:01:06 +1000 (EST) Message-ID: <45262960.2090802@apnic.net> Date: Fri, 06 Oct 2006 20:01:04 +1000 From: Robert Loomans Organization: APNIC User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060615 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Joe Abley Subject: Re: [Sidr] comments on draft-ietf-sidr-res-certs-02 References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 OpenPGP: id=C6B3AE7E X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1318814425==" Errors-To: sidr-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1318814425== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060106050009020300010907" This is a cryptographically signed message in MIME format. --------------ms060106050009020300010907 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Thanks, Joe, for the feedback. I am one of the APNIC staff working on this, and a co-author of the draft. > There are no examples provided in the document of how these > certificates might be used, once generated. I realise that's a much > wider topic of which a description of the certificates themselves is > a small component; however, some examples might be useful in the > event that this document is ever read in isolation. Good call. Such examples mostly live in Geoff's slidepacks at the moment... > Section 3 contains fields described using phrases such as "positive > integer" without including information about the field width -- in > other words, there's no comment on the maximum value that might be > stored. Perhaps this is implicit in the design of X.509, but since I > couldn't find any mention of it in RFC 3280 either, I thought I'd > make the observation here. Serial numbers are discussed in section 4.1.2.2 of RFC 3280: "Certificate users MUST be able to handle serialNumber values up to 20 octets. Conformant CAs MUST NOT use serialNumber values longer than 20 octets." > In section 3.7 the draft alludes to possible reasons for a resource > certificate's "valid to" field to extend beyond that in the superior > certificate. It's not clear to me why this should be the case. I > don't have strong opinions about this, but it seems possible that an > example would lend some clarity. An example of this in situations where there are contractual or membership period differences between your upstream and and downstream. As an APNIC member your APNIC-issued certificates would have validity related to their typically annual membership, but you might have relationships with your customers that are expected to last longer. You can issue certificates to your customer reflecting that longer relationship, and you don't have to re-issue when your APNIC certificates are re-issued. Another example (that just came to mind) is that within a company, you might delegate resources to different sections. Obviously you expect those relationships to last indefinitely, and you can reflect that in the validity period. > In section 3.8 the draft uses normative language to specify key > sizes. Should it not instead specify *minimum* key sizes, or is it an > explicit goal to specify an absolute size? (Would it be bad, for > example, if I chose to use a 4096 bit key instead of the 2048 bit key > I SHOULD use?) I believe there are concerns about the overhead of using unnecessarily larger keys.... > Section 3.9.1 has a typo, maybe ("cA" vs. "CA")? No... the ASN.1 definition of BasicConstraints in RFC 3280 calls the field cA: BasicConstraints ::= SEQUENCE { cA BOOLEAN DEFAULT FALSE, pathLenConstraint INTEGER (0..MAX) OPTIONAL } > In section 3.9.5, why is an rsync URI preferred over any other kind > of URI? There's no normative language surrounding the stated > preference. Is a preference lacking normative teeth worth mentioning? > If so, might it be an idea to indicate that other URIs MAY be used > instead? > > In section 3.9.6 and 3.9.7 the rsync URI is specified again, this > time as a MUST with a note that other URIs MAY be used. While I'm > still interested in why the rsync URI is a MUST, the language and the > associated MAY make these sections clearer than 3.9.5. There are two issues here: 1) We want *all* certificates, CRLs, etc to be available and accessible by only having to implement one protocol. Alternative protocols are fine, but one protocol is mandatory. This will aid in interoperability. 2) We want a protocol with properties that include fetching complete trees of objects/files, and, if you already have an old tree, just the changes. We could implement this in any transport, but RSYNC does this for free. > In general, the draft seems to systematically misspell words like > "authorise" and "recognise", in defiance of the authors' Commonwealth > origins. Ummm.... not my call :) > Also I'm fairly sure "unexpired" is not a word; "non-expired" seems > better. :-) Pedant! :-P Cheers, Rob -- Robert Loomans Email: robertl@apnic.net Programmer/Analyst, APNIC Phone: +61 7 3858 3100 http://www.apnic.net Fax: +61 7 3858 3199 --------------ms060106050009020300010907 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5jCC BW8wggRXoAMCAQICAhmqMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UE ChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5h Z2VyQGFwbmljLm5ldDAeFw0wNjA4MTYyMzQ0MjJaFw0wNzA4MTYyMzQ0MjJaMEgxCzAJBgNV BAYTAkFQMREwDwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTAL BgNVBAUTBDY1NzAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDIGKArFelrgnyK QHEZnvLP8bvR3jwpKRmaBp8+PrCJRA8ELT3L4ZtY98cYyjAIfFYdt/n9gQjagRaltoEW4bkK Z9cS91onYYCt70xnMzwJrh3ms3rDUeXK5JQqUv3AYpQLfvC5ICV+FBNuIQ26b2hzUgiyOP89 Lc9YHJ2E02ACHKlfsYyWD/vWCd8UOQYyuijkPgHvCncHaEjuSekg8JnWqi9GQtWLt7EmtsLb /D8Yn6beScKex4KK2GZtD8fGyQoCXj25DBSU9OLXE8bDc0V1z8N/RU6TA8paLS+iculoBu1G NXRE3sdyTIS+OXsgwLh6xrY5Lnowow/HkQ7Ckn7hAgMBAAGjggIaMIICFjAJBgNVHRMEAjAA MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklD IENsaWVudCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQU3b65o54yQEQn+fF94hWGnIeCdlUwgbsG A1UdIwSBszCBsIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFV MQ4wDAYDVQQKEwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQD EyVBUE5JQyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkB FhNjYW1hbmFnZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0 MB4GA1UdEgQXMBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0 cHM6Ly93d3cuYXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0 dHBzOi8vd3d3LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZo dHRwczovL3d3dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOC AQEAjhazoKEg7sVuzPifVcwRZYSJq7JApAMyGx0RrxqtmMp/lp2vzB89ducRVq+FUfXQXaJc q4FZmJ+1WyncU/p6yJK0z6/FXMf/5eqk6PTC5NJt/yNBifYBV5MYCwuukY0c2b/io4JojR3D kfmuIkmbZPcCep6rDqrwLHIMLjZmL1U1uVlSnhbX8HdHrsURsroRtfXNlWYTnk/dFLBPRmIV 1RhjVODH72qw+fTcSNWWF5jcIPHXj6LeCxSm24xqbKzMuCEUgdWpFtlSK+utIWXrhvzOKK4C xOE1kPsx7lGfGZ+RsLtB6BGx5UC1NotAB9r2UBxkmiJV79kKjOE8rwMcgjCCBW8wggRXoAMC AQICAhmqMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMx GzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmlj Lm5ldDAeFw0wNjA4MTYyMzQ0MjJaFw0wNzA4MTYyMzQ0MjJaMEgxCzAJBgNVBAYTAkFQMREw DwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTALBgNVBAUTBDY1 NzAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDIGKArFelrgnyKQHEZnvLP8bvR 3jwpKRmaBp8+PrCJRA8ELT3L4ZtY98cYyjAIfFYdt/n9gQjagRaltoEW4bkKZ9cS91onYYCt 70xnMzwJrh3ms3rDUeXK5JQqUv3AYpQLfvC5ICV+FBNuIQ26b2hzUgiyOP89Lc9YHJ2E02AC HKlfsYyWD/vWCd8UOQYyuijkPgHvCncHaEjuSekg8JnWqi9GQtWLt7EmtsLb/D8Yn6beScKe x4KK2GZtD8fGyQoCXj25DBSU9OLXE8bDc0V1z8N/RU6TA8paLS+iculoBu1GNXRE3sdyTIS+ OXsgwLh6xrY5Lnowow/HkQ7Ckn7hAgMBAAGjggIaMIICFjAJBgNVHRMEAjAAMBEGCWCGSAGG +EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklDIENsaWVudCBD ZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQU3b65o54yQEQn+fF94hWGnIeCdlUwgbsGA1UdIwSBszCB sIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFVMQ4wDAYDVQQK EwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQDEyVBUE5JQyBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkBFhNjYW1hbmFn ZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0MB4GA1UdEgQX MBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0cHM6Ly93d3cu YXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0dHBzOi8vd3d3 LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwczovL3d3 dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAjhazoKEg 7sVuzPifVcwRZYSJq7JApAMyGx0RrxqtmMp/lp2vzB89ducRVq+FUfXQXaJcq4FZmJ+1Wync U/p6yJK0z6/FXMf/5eqk6PTC5NJt/yNBifYBV5MYCwuukY0c2b/io4JojR3DkfmuIkmbZPcC ep6rDqrwLHIMLjZmL1U1uVlSnhbX8HdHrsURsroRtfXNlWYTnk/dFLBPRmIV1RhjVODH72qw +fTcSNWWF5jcIPHXj6LeCxSm24xqbKzMuCEUgdWpFtlSK+utIWXrhvzOKK4CxOE1kPsx7lGf GZ+RsLtB6BGx5UC1NotAB9r2UBxkmiJV79kKjOE8rwMcgjGCA8YwggPCAgEBMIGVMIGOMQsw CQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNl czEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAG CSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmljLm5ldAICGaowCQYFKw4DAhoFAKCCAgUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMDA2MTAwMTA0WjAj BgkqhkiG9w0BCQQxFgQUTC0F9w7lDqvVPqyNgon2OIyWju4wUgYJKoZIhvcNAQkPMUUwQzAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgaYGCSsGAQQBgjcQBDGBmDCBlTCBjjELMAkGA1UEBhMCQVUxDjAMBgNV BAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNVBAMTJUFQTklD IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0BCQEWE2NhbWFu YWdlckBhcG5pYy5uZXQCAhmqMIGoBgsqhkiG9w0BCRACCzGBmKCBlTCBjjELMAkGA1UEBhMC QVUxDjAMBgNVBAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNV BAMTJUFQTklDIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0B CQEWE2NhbWFuYWdlckBhcG5pYy5uZXQCAhmqMA0GCSqGSIb3DQEBAQUABIIBAEPlUmuZGhUy Uf6mpnpCBybEVcdW378Vim4P2o705uCMMacnksnyz0aIySwyMFFNwgS25cJEhRG7287lTAEO yukF0u3s/gjaNk+yLPogCfAyEdt1vJwZEL69NfQpPyky9SL1vC0EnaqlDHshxEd0i045th9n QAZGSHHIbMabrRdASeyM5vlaSDKXnLuDs3C8F0h5m2cTC6jan2Q09B482sxA+HTD5MTYJ6VR 1tsIIeS0VRc/nF4smdLgQwYgt98hQQF/SjvWNwpELq1fRFKuKoTSQRKE5U76SerGPER6B3HW vfefmkvlLkMs3ua+4WQBNt5AnnvsW3WsA6t6bdPo38MAAAAAAAA= --------------ms060106050009020300010907-- --===============1318814425== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr --===============1318814425==-- From sidr-bounces@ietf.org Fri Oct 06 08:05:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVoRW-0004l8-6U; Fri, 06 Oct 2006 08:04:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVoRU-0004kU-K1 for sidr@ietf.org; Fri, 06 Oct 2006 08:04:40 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVoPs-0007y9-0k for sidr@ietf.org; Fri, 06 Oct 2006 08:03:06 -0400 Received: from [64.235.108.48] (helo=[192.168.182.9]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVoPU-0007uf-Sj; Fri, 06 Oct 2006 12:02:51 +0000 In-Reply-To: <45262960.2090802@apnic.net> References: <45262960.2090802@apnic.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1FD92270-BBAD-4087-8EC5-8EB6D916557D@ca.afilias.info> Content-Transfer-Encoding: 7bit From: Joe Abley Subject: Re: [Sidr] comments on draft-ietf-sidr-res-certs-02 Date: Fri, 6 Oct 2006 08:02:17 -0400 To: Robert Loomans X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org On 6-Oct-2006, at 06:01, Robert Loomans wrote: >> In section 3.8 the draft uses normative language to specify key >> sizes. Should it not instead specify *minimum* key sizes, or is it an >> explicit goal to specify an absolute size? (Would it be bad, for >> example, if I chose to use a 4096 bit key instead of the 2048 bit key >> I SHOULD use?) > > I believe there are concerns about the overhead of using unnecessarily > larger keys.... I'd like to understand that concern a little better. It seems to me (as a crypto non-expert) that the three principle degrees of freedom available when you generate a key are the algorithm, the key length, and the the validity period. For applications in which the key is exercised very regularly, the usual (general) advice I have heard is to use a larger key, or to reduce the validity period. This kind of advice regarding specific key lengths and lifetimes seems to change over time -- the key sizes get longer and the validity periods get shorter -- presumably as a result of ongoing research and improved capabilities of the machinery which can be used to break keys. By specifying absolute values for the algorithm and the key size, this document leaves us only with the validity period, and changing that in many cases is going to involve talking to a customer to reissue a certificate. Talking to customers is expensive. For sensitive applications, it also seems possible that in the future the requirement to use a 2048-bit key length might imply the need for such keys to expire more frequently than is practical to manage. I'm quite prepared to believe there are reasons to fix the key size in the specification, but I think that decision needs some justification. Joe _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sat Oct 07 11:47:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWENQ-0004P2-Fs; Sat, 07 Oct 2006 11:46:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWENP-0004Ox-Cs for sidr@ietf.org; Sat, 07 Oct 2006 11:46:11 -0400 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWENO-0003IP-3f for sidr@ietf.org; Sat, 07 Oct 2006 11:46:11 -0400 Received: by postman.ripe.net (Postfix, from userid 4008) id 6336323F44; Sat, 7 Oct 2006 17:45:49 +0200 (CEST) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id 49F2023EF0; Sat, 7 Oct 2006 17:45:49 +0200 (CEST) Received: from [127.0.0.1] (cow.ripe.net [193.0.1.239]) by herring.ripe.net (Postfix) with ESMTP id 30B112F583; Sat, 7 Oct 2006 17:45:49 +0200 (CEST) Message-ID: <4527CBB1.9030409@ripe.net> Date: Sat, 07 Oct 2006 17:45:53 +0200 From: =?ISO-8859-1?Q?R=F3bert_Kisteleki?= Organization: RIPE NCC User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Joe Abley Subject: Re: [Sidr] comments on draft-ietf-sidr-res-certs-02 References: <45262960.2090802@apnic.net> <1FD92270-BBAD-4087-8EC5-8EB6D916557D@ca.afilias.info> In-Reply-To: <1FD92270-BBAD-4087-8EC5-8EB6D916557D@ca.afilias.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000011 / -4.4 X-RIPE-Signature: d115f38a7889da072e33977918d6e84e X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org Joe Abley wrote: > > On 6-Oct-2006, at 06:01, Robert Loomans wrote: > >>> In section 3.8 the draft uses normative language to specify key >>> sizes. Should it not instead specify *minimum* key sizes, or is it an >>> explicit goal to specify an absolute size? (Would it be bad, for >>> example, if I chose to use a 4096 bit key instead of the 2048 bit key >>> I SHOULD use?) >> >> I believe there are concerns about the overhead of using unnecessarily >> larger keys.... > > I'd like to understand that concern a little better. I had the same concern a while ago - namely that 2048 should be a minimum. At that time Stephen Kent pointed out that on the longer term he would prefer to move to EC-DSA instead of RSA with larger key sizes. Regards, Robert _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Oct 08 15:23:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWeDn-0006nA-62; Sun, 08 Oct 2006 15:21:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWeDl-0006n4-DB for sidr@ietf.org; Sun, 08 Oct 2006 15:21:57 -0400 Received: from skink.reptiles.org ([198.96.119.1] helo=mail.reptiles.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWeDk-0005zZ-6I for sidr@ietf.org; Sun, 08 Oct 2006 15:21:57 -0400 Received: from mail.reptiles.org([198.96.119.1] port=2487) (1803 bytes) by mail.reptiles.org([198.96.119.1] port=25) via TCP with esmtp (sender: ) id for ; (dest:remote)(R=bind_hosts)(T=inet_zone_bind_smtp) Sun, 8 Oct 2006 15:21:43 -0400 (EDT) (Smail-3.2.0.118 2004-May-31 #3 built 2004-Oct-14) Date: Sun, 8 Oct 2006 15:21:43 -0400 (EDT) From: Cat Okita X-X-Sender: gwen@skink.reptiles.org To: Henk Uijterwaal Subject: Re: [Sidr] comments on draft-ietf-sidr-res-certs-02 In-Reply-To: <7.0.1.0.2.20061005175025.034d98c8@ripe.net> Message-ID: <20061008152116.P37245@skink.reptiles.org> References: <7.0.1.0.2.20061005175025.034d98c8@ripe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Cat Okita List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org On Thu, 5 Oct 2006, Henk Uijterwaal wrote: > The draft is being used by the teams working on prototype implementation > of this, at APNIC and RIPE NCC (and others). The engineer working > on this here, said the draft is fine but there are some details to > be worked out. This is being discussed on the list that the APNIC and > RIPE NCC folks use to discuss their work, rather than the IETF SIDR > list. A number of things brought up there, actually made it into > the -02 version of the draft. > > (I agree that the discussion should take place on the IETF list but > don't ask me how to get it there.) Is there a way to peruse their archives, so we've got some idea of the discussions that have been taking place? cheers! ========================================================================== "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now." _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Oct 08 16:01:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWepT-0004qM-Js; Sun, 08 Oct 2006 16:00:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWepR-0004pz-OA for sidr@ietf.org; Sun, 08 Oct 2006 16:00:53 -0400 Received: from skink.reptiles.org ([198.96.119.1] helo=mail.reptiles.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWebg-0004Rp-JG for sidr@ietf.org; Sun, 08 Oct 2006 15:46:41 -0400 Received: from mail.reptiles.org([198.96.119.1] port=1202) (3084 bytes) by mail.reptiles.org([198.96.119.1] port=25) via TCP with esmtp (sender: ) id for ; (dest:remote)(R=bind_hosts)(T=inet_zone_bind_smtp) Sun, 8 Oct 2006 15:46:33 -0400 (EDT) (Smail-3.2.0.118 2004-May-31 #3 built 2004-Oct-14) Date: Sun, 8 Oct 2006 15:46:33 -0400 (EDT) From: Cat Okita X-X-Sender: gwen@skink.reptiles.org To: Joe Abley Subject: Re: [Sidr] comments on draft-ietf-sidr-res-certs-02 In-Reply-To: <1FD92270-BBAD-4087-8EC5-8EB6D916557D@ca.afilias.info> Message-ID: <20061008152247.U37245@skink.reptiles.org> References: <45262960.2090802@apnic.net> <1FD92270-BBAD-4087-8EC5-8EB6D916557D@ca.afilias.info> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Cat Okita List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org On Fri, 6 Oct 2006, Joe Abley wrote: > This kind of advice regarding specific key lengths and lifetimes seems to > change over time -- the key sizes get longer and the validity periods get > shorter -- presumably as a result of ongoing research and improved > capabilities of the machinery which can be used to break keys. > > By specifying absolute values for the algorithm and the key size, this > document leaves us only with the validity period, and changing that in many > cases is going to involve talking to a customer to reissue a certificate. > Talking to customers is expensive. I would strongly suggest that if absolutely necessary, the key size and algorithm not not be fixed, but that a basic compatibility requirement should be set. All of the PXIX working group documents that I've checked through avoid the pitfall of specifying an absolute algorithm/key size - and I strongly suspect that there are far more cryptographers there than here. 3.3. Signature Algorithm This field describes the algorithm used to compute the signature on this certificate. This profile specifies SHA-256 with RSA (sha256WithRSAEncryption), and, accordingly, the value for this field MUST be the OID value 1.2.840.113549.1.1.11 [RFC4055]. Looking in RFC4055, we find that there are already questions about SHA-256, given the recent advances in attacking SHA-1: [Page 21/22] If a greater level of security is desired, then a secure one-way hash function with a longer hash value is needed. SHA-256, SHA-384, and SHA-512 are reasonable choices [SHA2], although their security needs to be reconfirmed in light of the SHA-1 results. I'd suggest that we refer to a minimum standard (probably as set in one of the related documents such as RFC4055), and follow the same, standard means of specifying any 'upwards' improvements in algorithm/key length. cheers! ========================================================================== "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now." _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 09 10:58:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwZv-0003iJ-OL; Mon, 09 Oct 2006 10:58:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwWm-00033i-BE for sidr@ietf.org; Mon, 09 Oct 2006 10:54:48 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWwWj-000772-B6 for sidr@ietf.org; Mon, 09 Oct 2006 10:54:47 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.0.100]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1GWwWf-0001RR-4i; Mon, 09 Oct 2006 10:54:41 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20061008152247.U37245@skink.reptiles.org> References: <45262960.2090802@apnic.net> <1FD92270-BBAD-4087-8EC5-8EB6D916557D@ca.afilias.info> <20061008152247.U37245@skink.reptiles.org> Date: Mon, 9 Oct 2006 10:47:01 -0400 To: Cat Okita From: Stephen Kent Subject: Re: [Sidr] comments on draft-ietf-sidr-res-certs-02 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org At 3:46 PM -0400 10/8/06, Cat Okita wrote: >On Fri, 6 Oct 2006, Joe Abley wrote: >>This kind of advice regarding specific key lengths and lifetimes >>seems to change over time -- the key sizes get longer and the >>validity periods get shorter -- presumably as a result of ongoing >>research and improved capabilities of the machinery which can be >>used to break keys. >> >>By specifying absolute values for the algorithm and the key size, >>this document leaves us only with the validity period, and changing >>that in many cases is going to involve talking to a customer to >>reissue a certificate. Talking to customers is expensive. > >I would strongly suggest that if absolutely necessary, the key size >and algorithm not not be fixed, but that a basic compatibility >requirement >should be set. All of the PXIX working group documents that I've >checked through avoid the pitfall of specifying an absolute >algorithm/key size - and I strongly suspect that there are far more >cryptographers there than here. As co-chair of PKIX I can explain why we don't put algorithms or key sizes into those standards, but why they are relevant here. PKIX standards focus on formats and processing algorithms for certs and CRLs in all Internet contexts. Thus we don't make ANY algorithms, much less key sizes, standard. Different application need not use the same certs and thus can use different algorithms for cert signing/verification without imposing any interoperability issues. Also, some applications are uses in closed communities and thus different sets of users can employ different algorithms for their certs without interoperability concerns. What PKIX does allow is publication of standards on HOW to represent info about a given algorithm in a cert. So, for example, we say how to represent RSA, DH, DSA, and EC DSA algorithms and associated parameters. We also cite appropriate hash algorithms and the OIDs that represent the use of one of these hash algorithms with a signature algorithm. In the SIDR context, we are discussing a single application, and for use in the public Internet, it helps immensely if the same algorithm is used everywhere. However, it is fair to say that we could avoid algorithm references in a SIDR cert profile, which could be used in closed Internets as well as the public Internet, and just put the algorithm and key size info into a CP for the public Internet instance of SIDR. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 09 10:58:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwZw-0003iO-5F; Mon, 09 Oct 2006 10:58:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwWm-00033h-BD for sidr@ietf.org; Mon, 09 Oct 2006 10:54:48 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWwWj-0006wW-B6 for sidr@ietf.org; Mon, 09 Oct 2006 10:54:46 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.0.100]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1GWwWc-0001RR-4z; Mon, 09 Oct 2006 10:54:39 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4527CBB1.9030409@ripe.net> References: <45262960.2090802@apnic.net> <1FD92270-BBAD-4087-8EC5-8EB6D916557D@ca.afilias.info> <4527CBB1.9030409@ripe.net> Date: Mon, 9 Oct 2006 10:29:08 -0400 To: Joe Abley From: Stephen Kent Subject: Re: [Sidr] comments on draft-ietf-sidr-res-certs-02 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org Joe, 4096-bit RSA is computationally intensive, which is why I didn't suggest that we set minimum key sizes. There is a tendency for some folks to pick bigger keys w/o regard to the need for such. We see this often in the IPsec environment, where when AES was adopted, many folks were convinced that 256-bit AES keys were appropriate, when 128-bit keys would be just fine. In the case of a PKI, one should take into account the impact on the relying parties who will have to check signatures generated with very large keys, as well as the local impact on an individual CA that uses a very large key for signing. As Robert noted, in the long run we can transition to EC DSA when we feel to need for bigger (equivalent) key sizes. That's what folks are doing in general, as an alternative to very big RSA keys. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 09 11:03:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwf0-0005NW-LI; Mon, 09 Oct 2006 11:03:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwex-0005Ek-S9 for sidr@ietf.org; Mon, 09 Oct 2006 11:03:16 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWwew-0008UF-J9 for sidr@ietf.org; Mon, 09 Oct 2006 11:03:15 -0400 Received: from [67.99.248.2] (helo=[10.111.113.102]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GWwek-0000jM-6w; Mon, 09 Oct 2006 15:03:02 +0000 In-Reply-To: References: <45262960.2090802@apnic.net> <1FD92270-BBAD-4087-8EC5-8EB6D916557D@ca.afilias.info> <4527CBB1.9030409@ripe.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <747B0082-1C9D-45F0-A911-3968B2BF72C2@ca.afilias.info> Content-Transfer-Encoding: 7bit From: Joe Abley Subject: Re: [Sidr] comments on draft-ietf-sidr-res-certs-02 Date: Mon, 9 Oct 2006 10:02:52 -0500 To: Stephen Kent X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org Hi Stephen, Thanks for the clues. On 9-Oct-2006, at 09:29, Stephen Kent wrote: > As Robert noted, in the long run we can transition to EC DSA when > we feel to need for bigger (equivalent) key sizes. That's what > folks are doing in general, as an alternative to very big RSA keys. Re-reading the document, I think I might have mis-read the text in the first place. Section 3.8 says: This field specifies the subject's public key and the algorithm with which the key is used. The public key algorithm MUST be RSA, and, accordingly, the OID for the algorithm is 1.2.840.113549.1.1.1. A minimum key size of 1024 bits is mandated in this profile. In the context of certifying resources it is recommended that certificates that are intended to be used as root certificates, and their immediate subordinates SHOULD use a key size of 2048 bits. Subordinates of these subordinate certificates, in the context of continued level of high trust, SHOULD use a key size of 2048 bits. In the application of this profile to certification of public number resources, it would be consistent with this recommendation that the Regional Internet Registries used a key size of 2048 bits, and that their immediate subordinate certificate authorities also use a key size of 2048 bits. All other subordinate certificates MAY use a key size of 1024 bits. So, in fact, for general use it is a minimum that is recommended (1024 bits), not an absolute, and where an absolute number is quoted it's for RIRs and LIRs, and even then a SHOULD rather than a MUST. Your comments above though (and Rob's comments earlier) make me wonder about the hard requirement that the algorithm MUST be RSA, though. Seems to me that a future transition to a different algorithm would require a new document to be issued which updates this one. Perhaps that's a feature. Joe _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 09 11:04:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwfx-0006RJ-HW; Mon, 09 Oct 2006 11:04:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwWi-00032z-TA for sidr@ietf.org; Mon, 09 Oct 2006 10:54:44 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWwMG-0005Dg-7l for sidr@ietf.org; Mon, 09 Oct 2006 10:43:56 -0400 Received: from [IPv6:2001:1af8:6::20a:95ff:fecd:987a] (alumange-giga.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fecd:987a]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k99EgJYd095461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Oct 2006 16:42:19 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <20061008152247.U37245@skink.reptiles.org> References: <45262960.2090802@apnic.net> <1FD92270-BBAD-4087-8EC5-8EB6D916557D@ca.afilias.info> <20061008152247.U37245@skink.reptiles.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <780D917B-DDED-449E-B835-9A246CC50506@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [Sidr] comments on draft-ietf-sidr-res-certs-02 Date: Mon, 9 Oct 2006 16:43:35 +0200 To: Cat Okita X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org On 8-okt-2006, at 21:46, Cat Okita wrote: > I'd suggest that we refer to a minimum standard (probably as set in > one > of the related documents such as RFC4055), and follow the same, > standard > means of specifying any 'upwards' improvements in algorithm/key > length. The current work on certificates assumes that these are kept outside the actual routing system, but proposals such as S-BGP carry certificates and signatures in BGP. This will increase the amount of data that must be communicated from one BGP speaker to another, and, more importantly, the amount of data a BGP router must keep in memory manifold. As such, it would be very helpful to keep all of this as small as possible, and use better algorithms with shorter keys rather than weaker algorithms with longer keys. It would also be useful to consider how much protection is sufficient. Obviously the security should be reasonably strong, but we may be overshooting the mark if we go for the absolutely strongest crypto we have available. It might be useful approach to carry medium-strength certificates and signatures inside the routing system and have cryptographically stronger certificates and signatures available out-of-band. In any event, I would rather give operators the choice of algorithm/ key length strength rather than mandate a certain minimum. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 09 12:14:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWxlE-0007Fe-1C; Mon, 09 Oct 2006 12:13:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWxkR-0006Zn-TP for sidr@ietf.org; Mon, 09 Oct 2006 12:12:59 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWxWf-00077O-Ff for sidr@ietf.org; Mon, 09 Oct 2006 11:58:46 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.0.100]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1GWxWY-0002AT-6J; Mon, 09 Oct 2006 11:58:39 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <747B0082-1C9D-45F0-A911-3968B2BF72C2@ca.afilias.info> References: <45262960.2090802@apnic.net> <1FD92270-BBAD-4087-8EC5-8EB6D916557D@ca.afilias.info> <4527CBB1.9030409@ripe.net> <747B0082-1C9D-45F0-A911-3968B2BF72C2@ca.afilias.info> Date: Mon, 9 Oct 2006 11:58:33 -0400 To: Joe Abley From: Stephen Kent Subject: Re: [Sidr] comments on draft-ietf-sidr-res-certs-02 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org >... >So, in fact, for general use it is a minimum that is recommended >(1024 bits), not an absolute, and where an absolute number is quoted >it's for RIRs and LIRs, and even then a SHOULD rather than a MUST. We have lots of time to revise this text, but I'd suggest that we establish target sizes for RIRs, LIRs, and ISPs, and that we try to establish a max key size as well, for the reasons I cited. However, we can put this into a CP, instead of the cert profile, if we want to maintain flexibility. >Your comments above though (and Rob's comments earlier) make me >wonder about the hard requirement that the algorithm MUST be RSA, >though. Seems to me that a future transition to a different >algorithm would require a new document to be issued which updates >this one. Perhaps that's a feature. Switching to a different algorithm will be a big deal. Changing the documentation will be the easiest part of such a transition :-). _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sat Oct 14 09:40:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYjjA-00075j-IH; Sat, 14 Oct 2006 09:39:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYjj9-00075d-4z for sidr@ietf.org; Sat, 14 Oct 2006 09:38:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYjj9-0002DQ-3L for sidr@ietf.org; Sat, 14 Oct 2006 09:38:59 -0400 Received: from kahuna.telstra.net ([203.50.0.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GYjj7-00046U-7z for sidr@ietf.org; Sat, 14 Oct 2006 09:38:59 -0400 Received: from gihm3.apnic.net (kahuna.telstra.net [IPv6:2001:360::4]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k9EDXQRd067880; Sat, 14 Oct 2006 23:33:29 +1000 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20061014233123.014cc928@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Sat, 14 Oct 2006 23:32:27 +1000 To: Cat Okita , Henk Uijterwaal From: Geoff Huston Subject: Re: [Sidr] comments on draft-ietf-sidr-res-certs-02 In-Reply-To: <20061008152116.P37245@skink.reptiles.org> References: <7.0.1.0.2.20061005175025.034d98c8@ripe.net> <20061008152116.P37245@skink.reptiles.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org > >Is there a way to peruse their archives, so we've got some idea of the >discussions that have been taking place? Have a look at the headers of the sidr mail: List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , thanks, Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sat Oct 14 14:39:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYoPS-0000K7-8r; Sat, 14 Oct 2006 14:38:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYoPQ-0000Iw-RM for sidr@ietf.org; Sat, 14 Oct 2006 14:38:56 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYoPP-00018V-GT for sidr@ietf.org; Sat, 14 Oct 2006 14:38:56 -0400 Received: from yxu1a22.hopcount.ca ([199.212.90.22]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GYoP8-000OzJ-1r; Sat, 14 Oct 2006 18:38:38 +0000 In-Reply-To: <7.0.0.16.2.20061014233123.014cc928@apnic.net> References: <7.0.1.0.2.20061005175025.034d98c8@ripe.net> <20061008152116.P37245@skink.reptiles.org> <7.0.0.16.2.20061014233123.014cc928@apnic.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joe Abley Subject: Re: [Sidr] comments on draft-ietf-sidr-res-certs-02 Date: Sat, 14 Oct 2006 14:38:30 -0400 To: Geoff Huston X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org On 14-Oct-2006, at 09:32, Geoff Huston wrote: >> Is there a way to peruse their archives, so we've got some idea of >> the >> discussions that have been taking place? > > Have a look at the headers of the sidr mail: Cat was talking about the discussions between RIPE and APNIC that Henk mentioned had happened on some other list, I think, not those that have happened here. Joe _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 16 11:05:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZU1A-0000M4-4n; Mon, 16 Oct 2006 11:04:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZU18-0000KV-Ut for sidr@ietf.org; Mon, 16 Oct 2006 11:04:38 -0400 Received: from reptiles.org ([198.96.119.1] helo=mail.reptiles.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZU14-00087S-3G for sidr@ietf.org; Mon, 16 Oct 2006 11:04:38 -0400 Received: from mail.reptiles.org([198.96.119.1] port=1988) (1651 bytes) by mail.reptiles.org([198.96.119.1] port=25) via TCP with esmtp (sender: ) id for ; (dest:remote)(R=bind_hosts)(T=inet_zone_bind_smtp) Mon, 16 Oct 2006 11:04:19 -0400 (EDT) (Smail-3.2.0.118 2004-May-31 #3 built 2004-Oct-14) Date: Mon, 16 Oct 2006 11:04:13 -0400 (EDT) From: Cat Okita X-X-Sender: gwen@skink.reptiles.org To: Geoff Huston Subject: Re: [Sidr] comments on draft-ietf-sidr-res-certs-02 In-Reply-To: <7.0.0.16.2.20061014233123.014cc928@apnic.net> Message-ID: <20061016110253.Q31020@skink.reptiles.org> References: <7.0.1.0.2.20061005175025.034d98c8@ripe.net> <20061008152116.P37245@skink.reptiles.org> <7.0.0.16.2.20061014233123.014cc928@apnic.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Cat Okita List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org On Sat, 14 Oct 2006, Geoff Huston wrote: >> Is there a way to peruse their archives, so we've got some idea of the >> discussions that have been taking place? > > Have a look at the headers of the sidr mail: I think you missed the details, Geoff - I was asking about the RIPE and APNIC list discussions (which are not available), not how to find archives for this list. cheers! ========================================================================== "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now." _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 16 15:19:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZXza-0000m2-7B; Mon, 16 Oct 2006 15:19:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZXzY-0000ls-Pm for sidr@ietf.org; Mon, 16 Oct 2006 15:19:16 -0400 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZXzV-00080g-Sf for sidr@ietf.org; Mon, 16 Oct 2006 15:19:16 -0400 Received: from gihm3.apnic.net (kahuna.telstra.net [IPv6:2001:360::4]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k9GJImOB062294; Tue, 17 Oct 2006 05:18:50 +1000 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20061017051346.014815d8@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 17 Oct 2006 05:16:36 +1000 To: Cat Okita From: Geoff Huston Subject: Re: [Sidr] comments on draft-ietf-sidr-res-certs-02 In-Reply-To: <20061016110253.Q31020@skink.reptiles.org> References: <7.0.1.0.2.20061005175025.034d98c8@ripe.net> <20061008152116.P37245@skink.reptiles.org> <7.0.0.16.2.20061014233123.014cc928@apnic.net> <20061016110253.Q31020@skink.reptiles.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.8 (--) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org At 01:04 AM 17/10/2006, Cat Okita wrote: >On Sat, 14 Oct 2006, Geoff Huston wrote: >>>Is there a way to peruse their archives, so we've got some idea of the >>>discussions that have been taking place? >> >>Have a look at the headers of the sidr mail: > >I think you missed the details, Geoff - I was asking about the RIPE >and APNIC list discussions (which are not available), not how to >find archives for this list. My apologies for the misunderstanding. The design group working on certification trials do not have a public archive of their work. Public progress reports of certification trial activity can be found in the archives of recent APNIC, RIPE and ARIN meetings. kind regards, Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 16 22:06:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZeKv-00048h-6M; Mon, 16 Oct 2006 22:05:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZeKt-000488-S6 for sidr@ietf.org; Mon, 16 Oct 2006 22:05:43 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZeKs-0001QB-4x for sidr@ietf.org; Mon, 16 Oct 2006 22:05:43 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J79004OFCZFM6@szxga03-in.huawei.com> for sidr@ietf.org; Tue, 17 Oct 2006 10:16:27 +0800 (CST) Received: from M55527 ([10.111.12.134]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7900LVKCZDIJ@szxga03-in.huawei.com> for sidr@ietf.org; Tue, 17 Oct 2006 10:16:26 +0800 (CST) Date: Tue, 17 Oct 2006 10:04:57 +0800 From: Mach Chen To: sidr@ietf.org Message-id: <007c01c6f190$a538de30$860c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Subject: [Sidr] [IDR] Nexthop based Outbound Route Filter X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0834100909==" Errors-To: sidr-bounces@ietf.org This is a multi-part message in MIME format. --===============0834100909== Content-type: multipart/alternative; boundary="Boundary_(ID_kTAoD7f48IUm6f5Rupsfzw)" This is a multi-part message in MIME format. --Boundary_(ID_kTAoD7f48IUm6f5Rupsfzw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi folks, We have posted a new I-D which is about "Nexthop based ORF". Any feed-back and comments would be most welcome! Best regards, Mach -------------------------------------------------------------------------------- a.. To: i-d-announce at ietf.org b.. Subject: I-D ACTION:draft-chen-idr-bgp-nexthop-orf-00.txt c.. From: Internet-Drafts at ietf.org d.. Date: Thu, 12 Oct 2006 15:50:02 -0400 e.. Cc: f.. List-archive: g.. List-help: h.. List-id: i-d-announce.ietf.org i.. List-post: j.. List-subscribe: , k.. List-unsubscribe: , l.. Reply-to: internet-drafts at ietf.org -------------------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Nexthop Based Outbound Route Filter for BGP-4 Author(s) : R. Zhang, M. Chen Filename : draft-chen-idr-bgp-nexthop-orf-00.txt Pages : 7 Date : 2006-10-12 This document defines a new Outbound Route Filter type for BGP, termed "Nexthop Outbound Route Filter", which can be used to provide Nexthop based route filtering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-idr-bgp-nexthop-orf-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-chen-idr-bgp-nexthop-orf-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-chen-idr-bgp-nexthop-orf-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --Boundary_(ID_kTAoD7f48IUm6f5Rupsfzw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi folks,
 
We have posted a new I-D which is about "Nexthop based ORF".
 
Any feed-back and comments would be most welcome!
 
Best regards,
 
Mach
 
A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


	Title		: Nexthop Based Outbound Route Filter for BGP-4 
	Author(s)	: R. Zhang, M. Chen
	Filename	: draft-chen-idr-bgp-nexthop-orf-00.txt
	Pages		: 7
	Date		: 2006-10-12
	
   This document defines a new Outbound Route Filter type for BGP, 
   termed "Nexthop Outbound Route Filter", which can be used to provide 
   Nexthop based route filtering. 


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-idr-bgp-nexthop-orf-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request at ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-chen-idr-bgp-nexthop-orf-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv at ietf.org.
In the body type:
	"FILE /internet-drafts/draft-chen-idr-bgp-nexthop-orf-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
<ftp://ftp.ietf.org/internet-drafts/draft-chen-idr-bgp-nexthop-orf-00.txt> 
_______________________________________________
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce
--Boundary_(ID_kTAoD7f48IUm6f5Rupsfzw)-- --===============0834100909== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr --===============0834100909==-- From sidr-bounces@ietf.org Mon Oct 16 22:25:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZedP-0000eQ-Ma; Mon, 16 Oct 2006 22:24:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZedN-0000bx-Oz for sidr@ietf.org; Mon, 16 Oct 2006 22:24:49 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZedE-0004LP-Sy for sidr@ietf.org; Mon, 16 Oct 2006 22:24:49 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J79002XBDE7BH@szxga01-in.huawei.com> for sidr@ietf.org; Tue, 17 Oct 2006 10:25:19 +0800 (CST) Received: from M55527 ([10.111.12.134]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7900FD5DE5LV@szxga01-in.huawei.com> for sidr@ietf.org; Tue, 17 Oct 2006 10:25:19 +0800 (CST) Date: Tue, 17 Oct 2006 10:20:44 +0800 From: Mach Chen To: sidr@ietf.org Message-id: <00ca01c6f192$d9e8f500$860c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Subject: [Sidr] [IDR] Nexthop based Outbound Route Filter X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2111878577==" Errors-To: sidr-bounces@ietf.org This is a multi-part message in MIME format. --===============2111878577== Content-type: multipart/alternative; boundary="Boundary_(ID_Yk1DxGgfbpMJ/5dD6Ikn7w)" This is a multi-part message in MIME format. --Boundary_(ID_Yk1DxGgfbpMJ/5dD6Ikn7w) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi folks, We have posted a new I-D which is about "Nexthop based ORF". Any feed-back and comments would be most welcome! Best regards, Mach -------------------------------------------------------------------------------- a.. To: i-d-announce at ietf.org b.. Subject: I-D ACTION:draft-chen-idr-bgp-nexthop-orf-00.txt c.. From: Internet-Drafts at ietf.org d.. Date: Thu, 12 Oct 2006 15:50:02 -0400 e.. Cc: f.. List-archive: g.. List-help: h.. List-id: i-d-announce.ietf.org i.. List-post: j.. List-subscribe: , k.. List-unsubscribe: , l.. Reply-to: internet-drafts at ietf.org -------------------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Nexthop Based Outbound Route Filter for BGP-4 Author(s) : R. Zhang, M. Chen Filename : draft-chen-idr-bgp-nexthop-orf-00.txt Pages : 7 Date : 2006-10-12 This document defines a new Outbound Route Filter type for BGP, termed "Nexthop Outbound Route Filter", which can be used to provide Nexthop based route filtering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-idr-bgp-nexthop-orf-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-chen-idr-bgp-nexthop-orf-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-chen-idr-bgp-nexthop-orf-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --Boundary_(ID_Yk1DxGgfbpMJ/5dD6Ikn7w) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi folks,
 
We have posted a new I-D which is about "Nexthop based ORF".
 
Any feed-back and comments would be most welcome!
 
Best regards,
 
Mach
 
A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


	Title		: Nexthop Based Outbound Route Filter for BGP-4 
	Author(s)	: R. Zhang, M. Chen
	Filename	: draft-chen-idr-bgp-nexthop-orf-00.txt
	Pages		: 7
	Date		: 2006-10-12
	
   This document defines a new Outbound Route Filter type for BGP, 
   termed "Nexthop Outbound Route Filter", which can be used to provide 
   Nexthop based route filtering. 


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-idr-bgp-nexthop-orf-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request at ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-chen-idr-bgp-nexthop-orf-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv at ietf.org.
In the body type:
	"FILE /internet-drafts/draft-chen-idr-bgp-nexthop-orf-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
<ftp://ftp.ietf.org/internet-drafts/draft-chen-idr-bgp-nexthop-orf-00.txt> 
_______________________________________________
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce
 
--Boundary_(ID_Yk1DxGgfbpMJ/5dD6Ikn7w)-- --===============2111878577== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr --===============2111878577==-- From sidr-bounces@ietf.org Mon Oct 16 22:41:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZetg-0004k5-Ei; Mon, 16 Oct 2006 22:41:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZete-0004jx-T3 for sidr@ietf.org; Mon, 16 Oct 2006 22:41:38 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZetc-0006O2-Cb for sidr@ietf.org; Mon, 16 Oct 2006 22:41:38 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7900JJFEYZTQ@szxga02-in.huawei.com> for sidr@ietf.org; Tue, 17 Oct 2006 10:59:23 +0800 (CST) Received: from M55527 ([10.111.12.134]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7900KVNEYX7G@szxga02-in.huawei.com> for sidr@ietf.org; Tue, 17 Oct 2006 10:59:23 +0800 (CST) Date: Tue, 17 Oct 2006 10:39:55 +0800 From: Mach Chen Subject: Re: [Sidr] [IDR] Nexthop based Outbound Route Filter To: Mach Chen , sidr@ietf.org Message-id: <011301c6f195$87e598f0$860c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal References: <00ca01c6f192$d9e8f500$860c6f0a@china.huawei.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Cc: X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1988354975==" Errors-To: sidr-bounces@ietf.org This is a multi-part message in MIME format. --===============1988354975== Content-type: multipart/alternative; boundary="Boundary_(ID_skGoYRBRN8Gg/IqCsnKO9g)" This is a multi-part message in MIME format. --Boundary_(ID_skGoYRBRN8Gg/IqCsnKO9g) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT sorry, I send the message to a wrong place! ----- Original Message ----- From: Mach Chen To: sidr@ietf.org Sent: Tuesday, October 17, 2006 10:20 AM Subject: [Sidr] [IDR] Nexthop based Outbound Route Filter Hi folks, We have posted a new I-D which is about "Nexthop based ORF". Any feed-back and comments would be most welcome! Best regards, Mach ------------------------------------------------------------------------------ a.. To: i-d-announce at ietf.org b.. Subject: I-D ACTION:draft-chen-idr-bgp-nexthop-orf-00.txt c.. From: Internet-Drafts at ietf.org d.. Date: Thu, 12 Oct 2006 15:50:02 -0400 e.. Cc: f.. List-archive: g.. List-help: h.. List-id: i-d-announce.ietf.org i.. List-post: j.. List-subscribe: , k.. List-unsubscribe: , l.. Reply-to: internet-drafts at ietf.org ------------------------------------------------------------------------------ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Nexthop Based Outbound Route Filter for BGP-4 Author(s) : R. Zhang, M. Chen Filename : draft-chen-idr-bgp-nexthop-orf-00.txt Pages : 7 Date : 2006-10-12 This document defines a new Outbound Route Filter type for BGP, termed "Nexthop Outbound Route Filter", which can be used to provide Nexthop based route filtering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-idr-bgp-nexthop-orf-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-chen-idr-bgp-nexthop-orf-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-chen-idr-bgp-nexthop-orf-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------------------------------------------------------------------------------ _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr --Boundary_(ID_skGoYRBRN8Gg/IqCsnKO9g) Content-type: text/html; charset=gb2312 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjI5NjMiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5zb3JyeSwgSSBzZW5kIHRo ZSBtZXNzYWdlIHRvIGEgd3JvbmcgcGxhY2UhPC9GT05UPjwvRElWPg0KPEJMT0NLUVVPVEUgDQpz dHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6 IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+ DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDLzszlIj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS0tIDwvRElWPg0KICA8RElWIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBGT05UOiA5cHQg y87M5TsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiANCiAgPEEgdGl0bGU9bWFjaEBo dWF3ZWkuY29tIGhyZWY9Im1haWx0bzptYWNoQGh1YXdlaS5jb20iPk1hY2ggQ2hlbjwvQT4gPC9E SVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDLzszlIj48Qj5Ubzo8L0I+IDxBIHRpdGxlPXNp ZHJAaWV0Zi5vcmcgDQogIGhyZWY9Im1haWx0bzpzaWRyQGlldGYub3JnIj5zaWRyQGlldGYub3Jn PC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0IMvOzOUiPjxCPlNlbnQ6PC9CPiBU dWVzZGF5LCBPY3RvYmVyIDE3LCAyMDA2IDEwOjIwIA0KQU08L0RJVj4NCiAgPERJViBzdHlsZT0i Rk9OVDogOXB0IMvOzOUiPjxCPlN1YmplY3Q6PC9CPiBbU2lkcl0gW0lEUl0gTmV4dGhvcCBiYXNl ZCBPdXRib3VuZCANCiAgUm91dGUgRmlsdGVyPC9ESVY+DQogIDxESVY+PEJSPjwvRElWPg0KICA8 RElWPjxGT05UIHNpemU9Mj5IaSBmb2xrcyw8L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgc2l6 ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBzaXplPTI+V2UgaGF2ZSBwb3N0 ZWQgYSBuZXcgSS1EIHdoaWNoIGlzIGFib3V0ICJOZXh0aG9wIGJhc2VkIA0KICBPUkYiLjwvRk9O VD48L0RJVj4NCiAgPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElW PjxGT05UIHNpemU9Mj5BbnkgZmVlZC1iYWNrIGFuZCBjb21tZW50cyB3b3VsZCBiZSBtb3N0IA0K ICB3ZWxjb21lITwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNw OzwvRElWPg0KICA8RElWPjxGT05UIHNpemU9Mj5CZXN0IHJlZ2FyZHMsPC9GT05UPjwvRElWPg0K ICA8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgc2l6 ZT0yPk1hY2g8L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgc2l6ZT0yPjxFTT48L0VNPiZuYnNw OzwvRElWPg0KICA8RElWPg0KICA8SFI+DQogIDwvRElWPg0KICA8RElWPjxGT05UIA0KICBzaXpl PTM+PCEtLVgtU3ViamVjdC1IZWFkZXItRW5kLS0+PCEtLVgtSGVhZC1vZi1NZXNzYWdlLS0+PC9G T05UPjwvRElWPg0KICA8VUw+DQogICAgPExJPjxFTT5UbzwvRU0+OiA8QSBocmVmPSJtYWlsdG86 aS1kLWFubm91bmNlQERPTUFJTi5ISURERU4iPmktZC1hbm5vdW5jZSBhdCANCiAgICBpZXRmLm9y ZzwvQT4gDQogICAgPExJPjxFTT5TdWJqZWN0PC9FTT46IEktRCBBQ1RJT046ZHJhZnQtY2hlbi1p ZHItYmdwLW5leHRob3Atb3JmLTAwLnR4dCANCiAgICA8TEk+PEVNPkZyb208L0VNPjogPEEgDQog ICAgaHJlZj0ibWFpbHRvOkludGVybmV0LURyYWZ0c0BET01BSU4uSElEREVOIj5JbnRlcm5ldC1E cmFmdHMgYXQgaWV0Zi5vcmc8L0E+IA0KICAgIDxMST48RU0+RGF0ZTwvRU0+OiBUaHUsIDEyIE9j dCAyMDA2IDE1OjUwOjAyIC0wNDAwIA0KICAgIDxMST48RU0+Q2M8L0VNPjogDQogICAgPExJPjxF TT5MaXN0LWFyY2hpdmU8L0VNPjogJmx0OzxBIA0KICAgIGhyZWY9Imh0dHA6Ly93d3cxLmlldGYu b3JnL3BpcGVybWFpbC9pLWQtYW5ub3VuY2UiPmh0dHA6Ly93d3cxLmlldGYub3JnL3BpcGVybWFp bC9pLWQtYW5ub3VuY2U8L0E+Jmd0OyANCg0KICAgIDxMST48RU0+TGlzdC1oZWxwPC9FTT46ICZs dDs8QSANCiAgICBocmVmPSJtYWlsdG86aS1kLWFubm91bmNlLXJlcXVlc3RAaWV0Zi5vcmc/c3Vi amVjdD1oZWxwIj5tYWlsdG86aS1kLWFubm91bmNlLXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD1o ZWxwPC9BPiZndDsgDQoNCiAgICA8TEk+PEVNPkxpc3QtaWQ8L0VNPjogaS1kLWFubm91bmNlLmll dGYub3JnIA0KICAgIDxMST48RU0+TGlzdC1wb3N0PC9FTT46ICZsdDs8QSANCiAgICBocmVmPSJt YWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnIj5tYWlsdG86aS1kLWFubm91bmNlQGlldGYub3Jn PC9BPiZndDsgDQogICAgPExJPjxFTT5MaXN0LXN1YnNjcmliZTwvRU0+OiAmbHQ7PEEgDQogICAg aHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNl Ij5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2U8L0E+ Jmd0OywgDQogICAgJmx0OzxBIA0KICAgIGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2UtcmVxdWVz dEBpZXRmLm9yZz9zdWJqZWN0PXN1YnNjcmliZSI+bWFpbHRvOmktZC1hbm5vdW5jZS1yZXF1ZXN0 QGlldGYub3JnP3N1YmplY3Q9c3Vic2NyaWJlPC9BPiZndDsgDQoNCiAgICA8TEk+PEVNPkxpc3Qt dW5zdWJzY3JpYmU8L0VNPjogJmx0OzxBIA0KICAgIGhyZWY9Imh0dHBzOi8vd3d3MS5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZSI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlPC9BPiZndDssIA0KICAgICZsdDs8QSANCiAgICBo cmVmPSJtYWlsdG86aS1kLWFubm91bmNlLXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD11bnN1YnNj cmliZSI+bWFpbHRvOmktZC1hbm5vdW5jZS1yZXF1ZXN0QGlldGYub3JnP3N1YmplY3Q9dW5zdWJz Y3JpYmU8L0E+Jmd0OyANCg0KICAgIDxMST48RU0+UmVwbHktdG88L0VNPjogPEEgDQogICAgaHJl Zj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BET01BSU4uSElEREVOIj5pbnRlcm5ldC1kcmFmdHMg YXQgaWV0Zi5vcmc8L0E+IA0KICAgIDwvTEk+PC9VTD48IS0tWC1IZWFkLW9mLU1lc3NhZ2UtRW5k LS0+PCEtLVgtSGVhZC1Cb2R5LVNlcC1CZWdpbi0tPg0KICA8RElWPg0KICA8SFI+DQogIDwvRElW PjwhLS1YLUhlYWQtQm9keS1TZXAtRW5kLS0+PCEtLVgtQm9keS1vZi1NZXNzYWdlLS0+PFBSRT5B IE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5l dC1EcmFmdHMgDQpkaXJlY3Rvcmllcy4NCg0KDQoJVGl0bGUJCTogTmV4dGhvcCBCYXNlZCBPdXRi b3VuZCBSb3V0ZSBGaWx0ZXIgZm9yIEJHUC00IA0KCUF1dGhvcihzKQk6IFIuIFpoYW5nLCBNLiBD aGVuDQoJRmlsZW5hbWUJOiBkcmFmdC1jaGVuLWlkci1iZ3AtbmV4dGhvcC1vcmYtMDAudHh0DQoJ UGFnZXMJCTogNw0KCURhdGUJCTogMjAwNi0xMC0xMg0KCQ0KICAgVGhpcyBkb2N1bWVudCBkZWZp bmVzIGEgbmV3IE91dGJvdW5kIFJvdXRlIEZpbHRlciB0eXBlIGZvciBCR1AsIA0KICAgdGVybWVk ICJOZXh0aG9wIE91dGJvdW5kIFJvdXRlIEZpbHRlciIsIHdoaWNoIGNhbiBiZSB1c2VkIHRvIHBy b3ZpZGUgDQogICBOZXh0aG9wIGJhc2VkIHJvdXRlIGZpbHRlcmluZy4gDQoNCg0KQSBVUkwgZm9y IHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQo8QSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1jaGVuLWlkci1iZ3AtbmV4dGhvcC1vcmYtMDAudHh0Ij5odHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1jaGVuLWlkci1iZ3AtbmV4dGhv cC1vcmYtMDAudHh0PC9BPg0KDQpUbyByZW1vdmUgeW91cnNlbGYgZnJvbSB0aGUgSS1EIEFubm91 bmNlbWVudCBsaXN0LCBzZW5kIGEgbWVzc2FnZSB0byANCmktZC1hbm5vdW5jZS1yZXF1ZXN0IGF0 IGlldGYub3JnIHdpdGggdGhlIHdvcmQgdW5zdWJzY3JpYmUgaW4gdGhlIGJvZHkgb2YgDQp0aGUg bWVzc2FnZS4gDQpZb3UgY2FuIGFsc28gdmlzaXQgPEEgaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vSS1ELWFubm91bmNlIj5odHRwczovL3d3dzEuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9JLUQtYW5ub3VuY2U8L0E+IA0KdG8gY2hhbmdlIHlvdXIgc3Vic2Ny aXB0aW9uIHNldHRpbmdzLg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5 IGFub255bW91cyBGVFAuIExvZ2luIHdpdGggdGhlIA0KdXNlcm5hbWUgImFub255bW91cyIgYW5k IGEgcGFzc3dvcmQgb2YgeW91ciBlLW1haWwgYWRkcmVzcy4gQWZ0ZXIgDQpsb2dnaW5nIGluLCB0 eXBlICJjZCBpbnRlcm5ldC1kcmFmdHMiIGFuZCB0aGVuIA0KImdldCBkcmFmdC1jaGVuLWlkci1i Z3AtbmV4dGhvcC1vcmYtMDAudHh0Ii4NCg0KQSBsaXN0IG9mIEludGVybmV0LURyYWZ0cyBkaXJl Y3RvcmllcyBjYW4gYmUgZm91bmQgaW4NCjxBIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hh ZG93Lmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWw8L0E+IA0Kb3IgPEEgaHJl Zj0iZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQiPmZ0cDovL2Z0cC5p ZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0PC9BPg0KDQpJbnRlcm5ldC1EcmFmdHMgY2Fu IGFsc28gYmUgb2J0YWluZWQgYnkgZS1tYWlsLg0KDQpTZW5kIGEgbWVzc2FnZSB0bzoNCgltYWls c2VydiBhdCBpZXRmLm9yZy4NCkluIHRoZSBib2R5IHR5cGU6DQoJIkZJTEUgL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1jaGVuLWlkci1iZ3AtbmV4dGhvcC1vcmYtMDAudHh0Ii4NCgkNCk5PVEU6CVRo ZSBtYWlsIHNlcnZlciBhdCBpZXRmLm9yZyBjYW4gcmV0dXJuIHRoZSBkb2N1bWVudCBpbg0KCU1J TUUtZW5jb2RlZCBmb3JtIGJ5IHVzaW5nIHRoZSAibXBhY2siIHV0aWxpdHkuICBUbyB1c2UgdGhp cw0KCWZlYXR1cmUsIGluc2VydCB0aGUgY29tbWFuZCAiRU5DT0RJTkcgbWltZSIgYmVmb3JlIHRo ZSAiRklMRSINCgljb21tYW5kLiAgVG8gZGVjb2RlIHRoZSByZXNwb25zZShzKSwgeW91IHdpbGwg bmVlZCAibXVucGFjayIgb3INCglhIE1JTUUtY29tcGxpYW50IG1haWwgcmVhZGVyLiAgRGlmZmVy ZW50IE1JTUUtY29tcGxpYW50IG1haWwgcmVhZGVycw0KCWV4aGliaXQgZGlmZmVyZW50IGJlaGF2 aW9yLCBlc3BlY2lhbGx5IHdoZW4gZGVhbGluZyB3aXRoDQoJIm11bHRpcGFydCIgTUlNRSBtZXNz YWdlcyAoaS5lLiBkb2N1bWVudHMgd2hpY2ggaGF2ZSBiZWVuIHNwbGl0DQoJdXAgaW50byBtdWx0 aXBsZSBtZXNzYWdlcyksIHNvIGNoZWNrIHlvdXIgbG9jYWwgZG9jdW1lbnRhdGlvbiBvbg0KCWhv dyB0byBtYW5pcHVsYXRlIHRoZXNlIG1lc3NhZ2VzLg0KDQpCZWxvdyBpcyB0aGUgZGF0YSB3aGlj aCB3aWxsIGVuYWJsZSBhIE1JTUUgY29tcGxpYW50IG1haWwgcmVhZGVyDQppbXBsZW1lbnRhdGlv biB0byBhdXRvbWF0aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJSSB2ZXJzaW9uIG9mIHRoZQ0KSW50 ZXJuZXQtRHJhZnQuDQo8L1BSRT4NCiAgPERMPg0KICAgIDxEVD48QSANCiAgICBocmVmPSJmdHA6 Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWNoZW4taWRyLWJncC1uZXh0aG9w LW9yZi0wMC50eHQiPiZsdDtmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWNoZW4taWRyLWJncC1uZXh0aG9wLW9yZi0wMC50eHQmZ3Q7PC9BPiANCg0KICAgIDxERD48L0RE PjwvREw+PFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdA0KSS1ELUFubm91bmNlIGF0IGlldGYub3JnDQo8 QSBocmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3Vu Y2UiPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZTwv QT4NCjwvUFJFPjwhLS1YLUJvZHktb2YtTWVzc2FnZS1FbmQtLT48IS0tWC1Nc2dCb2R5LUVuZC0t PjwhLS1YLUZvbGxvdy1VcHMtLT48L0ZPTlQ+DQogIDxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4m bmJzcDs8L0RJVj4NCiAgPFA+DQogIDxIUj4NCg0KICA8UD48L1A+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+U2lkciBtYWlsaW5nIA0KICBsaXN0PEJS PlNpZHJAaWV0Zi5vcmc8QlI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2lkcjxCUj48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== --Boundary_(ID_skGoYRBRN8Gg/IqCsnKO9g)-- --===============1988354975== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr --===============1988354975==-- From sidr-bounces@ietf.org Wed Oct 18 15:51:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaHR0-0001ha-RG; Wed, 18 Oct 2006 15:50:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaHQR-000118-Jw; Wed, 18 Oct 2006 15:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaHQQ-0003mm-Ex; Wed, 18 Oct 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 68B5E26E4F; Wed, 18 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GaHQQ-0001TV-94; Wed, 18 Oct 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 18 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: sidr@ietf.org Subject: [Sidr] I-D ACTION:draft-ietf-sidr-cp-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Certificate Policy (CP) for the Internet IP Address and AS Number (PKI) Author(s) : K. Seo, et al. Filename : draft-ietf-sidr-cp-00.txt Pages : 47 Date : 2006-10-18 This document describes the certificate policy for a PKI used to support improved routing security. Each organization that allocates IP addresses or AS numbers to an organization will, in parallel, issue a certificate reflecting this allocation. These certificates will enable verification that the holder of the associated private key has been allocated the resources indicated in the certificate, and is the current, unique holder of these resources. The PKI in which the certificates issued under this policy are employed, in conjunction with ancillary digitally signed data structures, will provide critical inputs for routing security mechanisms, e.g., generation of route filters by ISPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-cp-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sidr-cp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sidr-cp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-18123116.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sidr-cp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sidr-cp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-18123116.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Wed Oct 18 15:52:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaHSX-0003f4-KW; Wed, 18 Oct 2006 15:52:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaHRP-0002PH-7O; Wed, 18 Oct 2006 15:51:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaHRP-0003uP-1U; Wed, 18 Oct 2006 15:51:03 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GaHRO-0001pP-NJ; Wed, 18 Oct 2006 15:51:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 878E82ACF1; Wed, 18 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GaHQQ-0001TY-9j; Wed, 18 Oct 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 18 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sidr@ietf.org Subject: [Sidr] I-D ACTION:draft-ietf-sidr-cps-irs-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Template for an Internet Registry's Certification Practice Statement (CPS) for the Internet IP Address and AS Number (PKI) Author(s) : S. Kent, et al. Filename : draft-ietf-sidr-cps-irs-00.txt Pages : 45 Date : 2006-10-18 This document contains a template to be used for creating a Certification Practice Statement (CPS) for an Internet Registry (e.g., NIR or RIR) that is part of the Internet IP Address and AS Number Public Key Infrastructure (PKI). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-cps-irs-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sidr-cps-irs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sidr-cps-irs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-18123412.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sidr-cps-irs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sidr-cps-irs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-18123412.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Fri Oct 20 11:57:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gawk3-0005TB-QO; Fri, 20 Oct 2006 11:57:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gawk2-0005T5-1l for sidr@ietf.org; Fri, 20 Oct 2006 11:57:02 -0400 Received: from nutshell.tislabs.com ([192.94.214.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gawk0-0007RF-N6 for sidr@ietf.org; Fri, 20 Oct 2006 11:57:02 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k9KFsc6x000981 for ; Fri, 20 Oct 2006 11:54:38 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAArGaaEb; Fri, 20 Oct 06 11:51:12 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id C3B003F62C; Fri, 20 Oct 2006 11:35:45 -0400 (EDT) To: sidr@ietf.org Message-Id: <20061020153545.C3B003F62C@pecan.tislabs.com> Date: Fri, 20 Oct 2006 11:35:45 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: sandy@tislabs.com Subject: [Sidr] deadlines for the San Diego meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org A reminder of some deadlines: draft submission deadline for submission of revised drafts (-01 and higher): October 23, Monday - Internet Draft final submission cut-off by 09:00 ET (13:00 UTC/GMT) early-bird registration deadline: October 23, Monday - Internet Draft final submission cut-off by 09:00 ET (13:00 UTC/GMT) For submitting drafts, you should also keep in mind the following announcement. --Sandy From: IETF Secretariat Date: Thu, 19 Oct 2006 23:16:36 -0400 Subject: Power Maintenance of the IETF Secretariat Data Center - Addendum Addendum to the previous annoucement that is attached below: In extreme condition, IETF Mail Exchange server will automaically failover to the secondary MX server that is running from other data center, which will assure that there will be *no* impact on email exchange (include I-D submissions) during this maintenance. Thanks you, The IETF Secretariat. ----------------------------------------------- The NeuStar Secretariat Services annual power generator maintenance for the data center will be taking place over this weekend. As a consequence of this routine maintenance, between Saturday, October 21, 2006, 5pm EDT, and Sunday, October 22, 2006, 2am EDT, the following sites and services may experience brief down times: https://datatracker.ietf.org IETF Mailing List pages and archives I-D Submission auto-response system IETF Ticketing system (RT) IETF proceedings pages The main IETF Web pages and ftp sites will be temporarily migrated to another data center during this maintenance. There is no predicted impact for the use of these sites. These sites include: www.ietf.org ftp.ietf.org www.iesg.org www.iab.org If you cannot access any of the affected services *after* the time window stated above, please send an email to ietf-action@ietf.org. Thank you, The IETF Secretariat _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Oct 20 12:06:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gawsa-0004zQ-4B; Fri, 20 Oct 2006 12:05:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GawsY-0004zD-W3 for sidr@ietf.org; Fri, 20 Oct 2006 12:05:50 -0400 Received: from nutshell.tislabs.com ([192.94.214.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GawsX-0000eQ-Lh for sidr@ietf.org; Fri, 20 Oct 2006 12:05:50 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k9KFsKUR000943 for ; Fri, 20 Oct 2006 11:54:20 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAfQairb; Fri, 20 Oct 06 11:47:52 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 60A733F62A; Fri, 20 Oct 2006 11:33:54 -0400 (EDT) To: sidr@ietf.org Message-Id: <20061020153354.60A733F62A@pecan.tislabs.com> Date: Fri, 20 Oct 2006 11:33:54 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: sandy@tislabs.com Subject: [Sidr] deadlines for the San Diego meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org A reminder of some deadlines: draft submission deadline for submission of revised drafts (-01 and higher): October 23, Monday - Internet Draft final submission cut-off by 09:00 ET (13:00 UTC/GMT) early-bird registration deadline: October 23, Monday - Internet Draft final submission cut-off by 09:00 ET (13:00 UTC/GMT) For submitting drafts, you should also keep in mind the following announcement: From: IETF Secretariat Date: Thu, 19 Oct 2006 23:16:36 -0400 Subject: Power Maintenance of the IETF Secretariat Data Center - Addendum Addendum to the previous annoucement that is attached below: In extreme condition, IETF Mail Exchange server will automaically failover to the secondary MX server that is running from other data center, which will assure that there will be *no* impact on email exchange (include I-D submissions) during this maintenance. Thanks you, The IETF Secretariat. ----------------------------------------------- The NeuStar Secretariat Services annual power generator maintenance for the data center will be taking place over this weekend. As a consequence of this routine maintenance, between Saturday, October 21, 2006, 5pm EDT, and Sunday, October 22, 2006, 2am EDT, the following sites and services may experience brief down times: https://datatracker.ietf.org IETF Mailing List pages and archives I-D Submission auto-response system IETF Ticketing system (RT) IETF proceedings pages The main IETF Web pages and ftp sites will be temporarily migrated to another data center during this maintenance. There is no predicted impact for the use of these sites. These sites include: www.ietf.org ftp.ietf.org www.iesg.org www.iab.org If you cannot access any of the affected services *after* the time window stated above, please send an email to ietf-action@ietf.org. Thank you, The IETF Secretariat _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Oct 20 15:30:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb04o-0007j2-AP; Fri, 20 Oct 2006 15:30:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb04m-0007il-Rm for sidr@ietf.org; Fri, 20 Oct 2006 15:30:40 -0400 Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gb04i-00064H-He for sidr@ietf.org; Fri, 20 Oct 2006 15:30:40 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k9KJQnDj013851 for ; Fri, 20 Oct 2006 15:26:50 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAA7Uai0A; Fri, 20 Oct 06 15:23:32 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id D17BD3F524; Fri, 20 Oct 2006 11:51:49 -0400 (EDT) To: sidr@ietf.org Message-Id: <20061020155149.D17BD3F524@pecan.tislabs.com> Date: Fri, 20 Oct 2006 11:51:49 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: sandy@tislabs.com Subject: [Sidr] request for agenda items for IETF-67 in San Diego X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org If anyone has an item or topic they wish to discuss at the San Diego meeting, please send the request to the wg chairs: sandy@tislabs.com gih@apnic.net --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 23 22:17:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcBqR-00008W-2O; Mon, 23 Oct 2006 22:16:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcBqP-00008L-Uo for sidr@ietf.org; Mon, 23 Oct 2006 22:16:45 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcBqO-0006f1-9a for sidr@ietf.org; Mon, 23 Oct 2006 22:16:45 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7M0007PC632D@szxga03-in.huawei.com> for sidr@ietf.org; Tue, 24 Oct 2006 10:27:39 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7M00C6YC6250@szxga03-in.huawei.com> for sidr@ietf.org; Tue, 24 Oct 2006 10:27:39 +0800 (CST) Received: from d42201 ([10.111.12.66]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7M0078YC994H@szxml04-in.huawei.com> for sidr@ietf.org; Tue, 24 Oct 2006 10:29:35 +0800 (CST) Date: Tue, 24 Oct 2006 10:15:59 +0800 From: daigm Subject: [Sidr]BGP UPDATE Advertisement Restriction To: "sidr@ietf.org" Message-id: <0J7M00792C9A4H@szxml04-in.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-Spam-Score: 0.5 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org Hi folks, We have posted an internet draft that is related to the sidr working group. Any feed-back and comments would be most welcome! A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dai-sidr-bgp-advertisement-00.txt Kind Regards, Dai Guangming Advanced Technology Department, Wireline Networking Business Unit Huawei Technologies Co., Ltd. Add: No.3, Xinxi Road, Shangdi Information Industry Base Haidian District, Beijing-100085 daigm@huawei.com 2006-10-24 _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 30 01:01:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeQCN-00026P-Ii; Mon, 30 Oct 2006 01:00:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeQCL-00026K-62 for sidr@ietf.org; Mon, 30 Oct 2006 01:00:38 -0500 Received: from mint.apnic.net ([202.12.29.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeQCJ-000463-Ej for sidr@ietf.org; Mon, 30 Oct 2006 01:00:37 -0500 Received: from [202.12.29.225] (puck.apnic.net [202.12.29.225]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 989F2D5F33 for ; Mon, 30 Oct 2006 16:00:15 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v624) In-Reply-To: <45262960.2090802@apnic.net> References: <45262960.2090802@apnic.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Terry Manderson Subject: Re: [Sidr] comments on draft-ietf-sidr-res-certs-02 Date: Mon, 30 Oct 2006 16:00:13 +1000 To: sidr@ietf.org X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org Apologies for awakening an old thread, I was on holidays. There is something that I am stuck on, and since I am in the same physical location as two of the authors, I have been able to beat on their door for a discussion. Apologies for not raising it directly on the SIDR list. The following is a transposition of a discussion that which fairly accurately describes my concerns relating to Joe's comment and Rob's reply. I am concerned with the current draft's reliance on RSYNC as a base line (read required) protocol for transport of the certificate information and the CRL. I'm not that concerned with the specific protocol, ie RSYNC vs HTTP/HTTPS vs something else. I am predominately concerned with an aspect of "lock-in" that will bind operators to running that mandated service/protocol even _IF_ the protocol selected is found to be wanting in areas of scale, security, and integrity. My initial feel for this document suggested two options. 1) change the wording of MUST to SHOULD in stating the protocol. or 2) Have the URI protocol defined in another draft that could be more easily changed in IETF process that modifying a RFC that would become certificate profile/policy. Cheers Terry On 06/10/2006, at 8:01 PM, Robert Loomans wrote: > > >> Joe Abley wrote: >> In section 3.9.5, why is an rsync URI preferred over any other kind >> of URI? There's no normative language surrounding the stated >> preference. Is a preference lacking normative teeth worth mentioning? >> If so, might it be an idea to indicate that other URIs MAY be used >> instead? >> >> In section 3.9.6 and 3.9.7 the rsync URI is specified again, this >> time as a MUST with a note that other URIs MAY be used. While I'm >> still interested in why the rsync URI is a MUST, the language and the >> associated MAY make these sections clearer than 3.9.5. > > There are two issues here: > > 1) We want *all* certificates, CRLs, etc to be available and accessible > by only having to implement one protocol. Alternative protocols are > fine, but one protocol is mandatory. This will aid in interoperability. > > 2) We want a protocol with properties that include fetching complete > trees of objects/files, and, if you already have an old tree, just the > changes. We could implement this in any transport, but RSYNC does this > for free. -- Terry Manderson email: terry@apnic.net Network Operations Manager, APNIC sip: info@voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100 _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 30 08:49:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeXVQ-0001pm-VI; Mon, 30 Oct 2006 08:48:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeXVP-0001pg-Nz for sidr@ietf.org; Mon, 30 Oct 2006 08:48:47 -0500 Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeXVN-0000D0-EO for sidr@ietf.org; Mon, 30 Oct 2006 08:48:47 -0500 Received: from [64.235.108.48] (helo=[192.168.182.2]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GeXVF-000Awa-DP; Mon, 30 Oct 2006 13:48:39 +0000 In-Reply-To: References: <45262960.2090802@apnic.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <55BB8600-840E-4B68-B95A-8AF89CB7B916@ca.afilias.info> Content-Transfer-Encoding: 7bit From: Joe Abley Subject: Re: [Sidr] comments on draft-ietf-sidr-res-certs-02 Date: Mon, 30 Oct 2006 08:48:28 -0500 To: Terry Manderson X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org On 30-Oct-2006, at 01:00, Terry Manderson wrote: > The following is a transposition of a discussion that which fairly > accurately describes my concerns relating to Joe's comment and > Rob's reply. > > I am concerned with the current draft's reliance on RSYNC as a base > line (read required) protocol for transport of the certificate > information and the CRL. I think I had two concerns about the the way that rsync was specified: 1. Why specify (with MUSTs and SHOULDs) a particular protocol at all? 2. Given the need for a base protocol, why choose rsync? Point 1 was answered, I think, and I agree that having a uniforum protocol which is required to be supported has advantages for implementors (who might otherwise be obliged to code support for many exotic URI schemes on platforms with limited capabilities) and avoids the situation where particular policies cannot be retrieved by some clients because they happen to lack support for a particular protocol. Point 2 still bothers me slightly, since it seems to me that the rsync protocol is not documented in a sufficiently stable form for it to be used as a base protocol for work such as this. Unless I'm mistaken, the rsync protocol/algorithm are products of a single talented individual and are documented in ad-hoc web pages. This seems to present risks (e.g. of future IPR claims, or modifications to the protocol which break interop with other rsync implementations). It seems to me that the answer to question 1 lends itself to the choice of a protocol which is widely implemented, for which interoperability has been well-demonstrated, and whose specification is stable. Given these goals, HTTP seems like a better choice than rsync. Perhaps this is a non-issue, but it seems to me that it ought to be discussed. Joe _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 30 09:44:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeYMQ-0004FS-JB; Mon, 30 Oct 2006 09:43:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeYMP-0004FN-34 for sidr@ietf.org; Mon, 30 Oct 2006 09:43:33 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeYML-0008QB-Jo for sidr@ietf.org; Mon, 30 Oct 2006 09:43:33 -0500 Received: by postman.ripe.net (Postfix, from userid 4008) id A786F2415B; Mon, 30 Oct 2006 15:42:53 +0100 (CET) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id 0C67924161; Mon, 30 Oct 2006 15:42:53 +0100 (CET) Received: from [127.0.0.1] (cow.ripe.net [193.0.1.239]) by herring.ripe.net (Postfix) with ESMTP id C65362F593; Mon, 30 Oct 2006 15:42:52 +0100 (CET) Message-ID: <45460F6B.4040004@ripe.net> Date: Mon, 30 Oct 2006 15:42:51 +0100 From: =?ISO-8859-1?Q?R=F3bert_Kisteleki?= Organization: RIPE NCC User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Joe Abley Subject: Re: [Sidr] comments on draft-ietf-sidr-res-certs-02 References: <45262960.2090802@apnic.net> <55BB8600-840E-4B68-B95A-8AF89CB7B916@ca.afilias.info> In-Reply-To: <55BB8600-840E-4B68-B95A-8AF89CB7B916@ca.afilias.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000186 / -4.4 X-RIPE-Signature: e58b15fe456c0ab0975f3da840932bf8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org >> I am concerned with the current draft's reliance on RSYNC as a base >> line (read required) protocol for transport of the certificate >> information and the CRL. > > I think I had two concerns about the the way that rsync was specified: > > 1. Why specify (with MUSTs and SHOULDs) a particular protocol at all? > > 2. Given the need for a base protocol, why choose rsync? [...] > Point 2 still bothers me slightly, since it seems to me that the rsync > protocol is not documented in a sufficiently stable form for it to be > used as a base protocol for work such as this. Unless I'm mistaken, the > rsync protocol/algorithm are products of a single talented individual > and are documented in ad-hoc web pages. This seems to present risks > (e.g. of future IPR claims, or modifications to the protocol which break > interop with other rsync implementations). These might be real concerns, I don't know. > It seems to me that the answer to question 1 lends itself to the choice > of a protocol which is widely implemented, for which interoperability > has been well-demonstrated, and whose specification is stable. Given > these goals, HTTP seems like a better choice than rsync. If you look at the expected use cases (especially parties synchronising between repositories), you end up with a number of requirements against the protocol that is going to be used in the distribution of these certificates: 1. It should be able to handle access to individual files (e.g. download issuer certificate or CRL). 2. It should be able to handle access to a large set files (download all objects from one or more repositories), out of which only relatively few are new (because you don't want to transfer data you already have) 3. The previous need to be supported throughout multiple directories, which are potentially nested 4. It should have some method for marking/deleting the objects that no longer exist on the "server". 5. It should work bidirectionally, i.e. should support sync between "A" and "B", not only update "B" from the repository "A". rsync does all that, pretty effectively. Number (1) is easy with HTTP, but starting from (2) you need to have some common listing format, a directory traversal (probably with multiple requests), etc. Yes, it could be done, but if you specify everything for all that functionality, you pretty much invent "rsync over HTTP" :-) > Perhaps this is a non-issue, but it seems to me that it ought to be > discussed. I'm not saying rsync is the only solution here, but from the usage point of view it is a very good tool. Regards, Robert > Joe > > _______________________________________________ > Sidr mailing list > Sidr@ietf.org > https://www1.ietf.org/mailman/listinfo/sidr _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 30 09:49:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeYS0-0000AU-DJ; Mon, 30 Oct 2006 09:49:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeYRz-0000AP-Ft for sidr@ietf.org; Mon, 30 Oct 2006 09:49:19 -0500 Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeYRx-0001Nc-83 for sidr@ietf.org; Mon, 30 Oct 2006 09:49:19 -0500 Received: from [64.235.108.48] (helo=[192.168.182.2]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GeYRu-000BfC-D9; Mon, 30 Oct 2006 14:49:14 +0000 In-Reply-To: <45460F6B.4040004@ripe.net> References: <45262960.2090802@apnic.net> <55BB8600-840E-4B68-B95A-8AF89CB7B916@ca.afilias.info> <45460F6B.4040004@ripe.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <96BBE1CD-9186-4E86-8F0C-424965042589@ca.afilias.info> Content-Transfer-Encoding: quoted-printable From: Joe Abley Subject: Re: [Sidr] comments on draft-ietf-sidr-res-certs-02 Date: Mon, 30 Oct 2006 09:49:07 -0500 To: =?ISO-8859-1?Q?R=F3bert_Kisteleki?= X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org On 30-Oct-2006, at 09:42, R=F3bert Kisteleki wrote: >> Perhaps this is a non-issue, but it seems to me that it ought to =20 >> be discussed. > > I'm not saying rsync is the only solution here, but from the usage =20 > point of view it is a very good tool. No argument from me on that. If Tridge sold t-shirts, I'd buy one. Joe _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 30 17:41:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gefou-0000Ay-Qx; Mon, 30 Oct 2006 17:41:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gefot-00009E-Ho for sidr@ietf.org; Mon, 30 Oct 2006 17:41:27 -0500 Received: from mint.apnic.net ([202.12.29.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gefon-0006Fg-OM for sidr@ietf.org; Mon, 30 Oct 2006 17:41:27 -0500 Received: from [192.168.1.35] (gw.home.zots.net [59.167.208.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 7FEC1D5F31 for ; Tue, 31 Oct 2006 08:41:07 +1000 (EST) Message-ID: <45467F80.8080702@apnic.net> Date: Tue, 31 Oct 2006 08:41:04 +1000 From: Robert Loomans Organization: APNIC User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060615 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: sidr@ietf.org Subject: Re: [Sidr] comments on draft-ietf-sidr-res-certs-02 References: <45262960.2090802@apnic.net> <55BB8600-840E-4B68-B95A-8AF89CB7B916@ca.afilias.info> <45460F6B.4040004@ripe.net> In-Reply-To: <45460F6B.4040004@ripe.net> X-Enigmail-Version: 0.94.0.0 OpenPGP: id=C6B3AE7E X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1099637432==" Errors-To: sidr-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1099637432== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010205000900060200080606" This is a cryptographically signed message in MIME format. --------------ms010205000900060200080606 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > Yes, it could be done, but if you specify everything for all that > functionality, you pretty much invent "rsync over HTTP" :-) "Rsync over HTTP" has already been (partially?) done: http://zsync.moria.org.uk/ The only wrinkle is that there'd have to be an index file or similar, because zsync is aimed at single files.... The advantages of zsync over rsync include that the diffs are pre-calculated once per file change as opposed to every transfer, and the actual server is simply a HTTP 1.1 compliant web server. The diffs can calculated off-line and uploaded to the server or servers. Debian has implemented a similar scheme for it's package files. On a related note, one of the requirements that Tridge had in mind when designing rsync was maximising throughput even in the presence of high end-to-end latencies and lots of small files. He did this by minimising the "chattiness" of the protocol and thus the effect of round-trip times. I think that is another property of rsync that would be useful to retain. Rob -- Robert Loomans Email: robertl@apnic.net Programmer/Analyst, APNIC Phone: +61 7 3858 3100 http://www.apnic.net Fax: +61 7 3858 3199 --------------ms010205000900060200080606 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5jCC BW8wggRXoAMCAQICAhmqMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UE ChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5h Z2VyQGFwbmljLm5ldDAeFw0wNjA4MTYyMzQ0MjJaFw0wNzA4MTYyMzQ0MjJaMEgxCzAJBgNV BAYTAkFQMREwDwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTAL BgNVBAUTBDY1NzAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDIGKArFelrgnyK QHEZnvLP8bvR3jwpKRmaBp8+PrCJRA8ELT3L4ZtY98cYyjAIfFYdt/n9gQjagRaltoEW4bkK Z9cS91onYYCt70xnMzwJrh3ms3rDUeXK5JQqUv3AYpQLfvC5ICV+FBNuIQ26b2hzUgiyOP89 Lc9YHJ2E02ACHKlfsYyWD/vWCd8UOQYyuijkPgHvCncHaEjuSekg8JnWqi9GQtWLt7EmtsLb /D8Yn6beScKex4KK2GZtD8fGyQoCXj25DBSU9OLXE8bDc0V1z8N/RU6TA8paLS+iculoBu1G NXRE3sdyTIS+OXsgwLh6xrY5Lnowow/HkQ7Ckn7hAgMBAAGjggIaMIICFjAJBgNVHRMEAjAA MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklD IENsaWVudCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQU3b65o54yQEQn+fF94hWGnIeCdlUwgbsG A1UdIwSBszCBsIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFV MQ4wDAYDVQQKEwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQD EyVBUE5JQyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkB FhNjYW1hbmFnZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0 MB4GA1UdEgQXMBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0 cHM6Ly93d3cuYXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0 dHBzOi8vd3d3LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZo dHRwczovL3d3dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOC AQEAjhazoKEg7sVuzPifVcwRZYSJq7JApAMyGx0RrxqtmMp/lp2vzB89ducRVq+FUfXQXaJc q4FZmJ+1WyncU/p6yJK0z6/FXMf/5eqk6PTC5NJt/yNBifYBV5MYCwuukY0c2b/io4JojR3D kfmuIkmbZPcCep6rDqrwLHIMLjZmL1U1uVlSnhbX8HdHrsURsroRtfXNlWYTnk/dFLBPRmIV 1RhjVODH72qw+fTcSNWWF5jcIPHXj6LeCxSm24xqbKzMuCEUgdWpFtlSK+utIWXrhvzOKK4C xOE1kPsx7lGfGZ+RsLtB6BGx5UC1NotAB9r2UBxkmiJV79kKjOE8rwMcgjCCBW8wggRXoAMC AQICAhmqMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMx GzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmlj Lm5ldDAeFw0wNjA4MTYyMzQ0MjJaFw0wNzA4MTYyMzQ0MjJaMEgxCzAJBgNVBAYTAkFQMREw DwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTALBgNVBAUTBDY1 NzAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDIGKArFelrgnyKQHEZnvLP8bvR 3jwpKRmaBp8+PrCJRA8ELT3L4ZtY98cYyjAIfFYdt/n9gQjagRaltoEW4bkKZ9cS91onYYCt 70xnMzwJrh3ms3rDUeXK5JQqUv3AYpQLfvC5ICV+FBNuIQ26b2hzUgiyOP89Lc9YHJ2E02AC HKlfsYyWD/vWCd8UOQYyuijkPgHvCncHaEjuSekg8JnWqi9GQtWLt7EmtsLb/D8Yn6beScKe x4KK2GZtD8fGyQoCXj25DBSU9OLXE8bDc0V1z8N/RU6TA8paLS+iculoBu1GNXRE3sdyTIS+ OXsgwLh6xrY5Lnowow/HkQ7Ckn7hAgMBAAGjggIaMIICFjAJBgNVHRMEAjAAMBEGCWCGSAGG +EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklDIENsaWVudCBD ZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQU3b65o54yQEQn+fF94hWGnIeCdlUwgbsGA1UdIwSBszCB sIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFVMQ4wDAYDVQQK EwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQDEyVBUE5JQyBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkBFhNjYW1hbmFn ZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0MB4GA1UdEgQX MBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0cHM6Ly93d3cu YXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0dHBzOi8vd3d3 LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwczovL3d3 dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAjhazoKEg 7sVuzPifVcwRZYSJq7JApAMyGx0RrxqtmMp/lp2vzB89ducRVq+FUfXQXaJcq4FZmJ+1Wync U/p6yJK0z6/FXMf/5eqk6PTC5NJt/yNBifYBV5MYCwuukY0c2b/io4JojR3DkfmuIkmbZPcC ep6rDqrwLHIMLjZmL1U1uVlSnhbX8HdHrsURsroRtfXNlWYTnk/dFLBPRmIV1RhjVODH72qw +fTcSNWWF5jcIPHXj6LeCxSm24xqbKzMuCEUgdWpFtlSK+utIWXrhvzOKK4CxOE1kPsx7lGf GZ+RsLtB6BGx5UC1NotAB9r2UBxkmiJV79kKjOE8rwMcgjGCA8YwggPCAgEBMIGVMIGOMQsw CQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNl czEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAG CSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmljLm5ldAICGaowCQYFKw4DAhoFAKCCAgUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMDMwMjI0MTA0WjAj BgkqhkiG9w0BCQQxFgQUv5MxdT7bJE4fGZ+18PrsjoUbVm4wUgYJKoZIhvcNAQkPMUUwQzAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgaYGCSsGAQQBgjcQBDGBmDCBlTCBjjELMAkGA1UEBhMCQVUxDjAMBgNV BAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNVBAMTJUFQTklD IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0BCQEWE2NhbWFu YWdlckBhcG5pYy5uZXQCAhmqMIGoBgsqhkiG9w0BCRACCzGBmKCBlTCBjjELMAkGA1UEBhMC QVUxDjAMBgNVBAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNV BAMTJUFQTklDIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0B CQEWE2NhbWFuYWdlckBhcG5pYy5uZXQCAhmqMA0GCSqGSIb3DQEBAQUABIIBAH3Z0kcyQc5P tRRCaF5JSShzS3Hwk2xm90O2RNLIyaZxrFVFCyvUbehCR2PmtvIXTz/+geRweHRRifOQTv9l DxF5uAuzLhrpEy3FUfEEuOnJORGTFEpg9HpuRdf5tHKw/3TLsqUDx3xmNayfReVdzKYxX3r9 3pd3pyTA+fRofltj0ldyE1HMmzAU7Cqn/5JF5eE0LRXhKuU1AX2csmFBvTvSt+9ulSR+0lN1 VNqgEP9q+Kg8v7CTu3SW8XlE5mGfCaysw7y1Hk5ariuYtfEIktMDBICSCfRcg9eshb1jKnpA uTPiJwhMOvSCZMdtyOyrVhnM/vKELJxhzm+quSDb3VYAAAAAAAA= --------------ms010205000900060200080606-- --===============1099637432== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr --===============1099637432==--