draft-ietf-sidr-keyroll-06.txt   draft-ietf-sidr-keyroll-07.txt 
SIDR G. Huston SIDR G. Huston
Internet-Draft G. Michaelson Internet-Draft G. Michaelson
Intended status: BCP APNIC Intended status: BCP APNIC
Expires: August 25, 2011 S. Kent Expires: December 5, 2011 S. Kent
BBN BBN
February 21, 2011 June 3, 2011
CA Key Rollover in the RPKI CA Key Rollover in the RPKI
draft-ietf-sidr-keyroll-06.txt draft-ietf-sidr-keyroll-07.txt
Abstract Abstract
This document describes how a Certification Authority (CA) in the This document describes how a Certification Authority (CA) in the
Resource Public Key Infrastructure (RPKI) performs a planned rollover Resource Public Key Infrastructure (RPKI) performs a planned rollover
of its key pair. This document also notes the implications of this of its key pair. This document also notes the implications of this
key rollover procedure for Relying Parties (RPs). In general, RPs are key rollover procedure for Relying Parties (RPs). In general, RPs
expected to maintain a local cache of the objects that have been are expected to maintain a local cache of the objects that have been
published in the RPKI repository, and thus the way in which a CA published in the RPKI repository, and thus the way in which a CA
performs key rollover impacts RPs. performs key rollover impacts RPs.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 6, 2011. This Internet-Draft will expire on December 5, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology and Concepts . . . . . . . . . . . . . . . . . 3 1.1. Terminology and Concepts . . . . . . . . . . . . . . . . . 3
2. CA Key Rollover Procedure . . . . . . . . . . . . . . . . . . 3 2. CA Key Rollover Procedure . . . . . . . . . . . . . . . . . . 3
3. Relying Party Requirements . . . . . . . . . . . . . . . . . . 7 3. Relying Party Requirements . . . . . . . . . . . . . . . . . . 7
4. Re-issuing Certificates and RPKI Signed Objects . . . . . . . 7 4. Re-issuing Certificates and RPKI Signed Objects . . . . . . . 7
4.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 7 4.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 8
4.2. RPKI Signed Objects . . . . . . . . . . . . . . . . . . . 8 4.2. RPKI Signed Objects . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
This document describes an algorithm to by employed by a This document describes an algorithm to be employed by a
Certification Authority (CA) in the Resource Public Key Certification Authority (CA) in the Resource Public Key
Infrastructure (RPKI) [ID.ietf-sidr-arch] to perform a rollover of Infrastructure (RPKI) [ID.ietf-sidr-arch] to perform a rollover of
its key pair. its key pair.
This document defines a conservative procedure for such entities to This document defines a conservative procedure for such entities to
follow when performing a key rollover, so that Relying Parties are in follow when performing a key rollover, so that Relying Parties are in
a position to be able to validate all authentic objects in the RPKI a position to be able to validate all authentic objects in the RPKI
using the validation procedure described in [ID.ietf-sidr-arch] at using the validation procedure described in [ID.ietf-sidr-arch] at
all times. all times.
skipping to change at page 3, line 47 skipping to change at page 3, line 47
implying that if key rollover is a regularly scheduled event then, implying that if key rollover is a regularly scheduled event then,
over time, there will be many instances of a CA. The implication in over time, there will be many instances of a CA. The implication in
the context of key rollover is that, strictly speaking, a CA does not the context of key rollover is that, strictly speaking, a CA does not
perform a key rollover per se. In order to perform the equivalent of perform a key rollover per se. In order to perform the equivalent of
a key rollover, the CA creates a "new" instance of itself, with a new a key rollover, the CA creates a "new" instance of itself, with a new
key pair, and then effectively substitutes this "new" CA instance key pair, and then effectively substitutes this "new" CA instance
into the RPKI hierarchy in place of the old CA instance. into the RPKI hierarchy in place of the old CA instance.
Note that focus of this procedure is planned key rollover, not an Note that focus of this procedure is planned key rollover, not an
"emergency" key rollover, e.g., promoted by a suspected or detected "emergency" key rollover, e.g., promoted by a suspected or detected
private key compromise. However, the procedure described here is private key compromise. However, the procedure described here is
applicable in emergency key rollover situations, with the exception applicable in emergency key rollover situations, with the exception
of the Staging Period duration. of the Staging Period duration.
There are several considerations regarding this procedure that MUST There are several considerations regarding this procedure that MUST
be followed by a CA performing a key rollover operation. The be followed by a CA performing a key rollover operation. The
critical consideration is that the RPKI has potential application in critical consideration is that the RPKI has potential application in
the area of control of routing integrity [ID.ietf-sidr-arch], and key the area of control of routing integrity [ID.ietf-sidr-arch], and key
rollover should not cause any transient hiatus in which a Relying rollover should not cause any transient hiatus in which a Relying
Party (RP) is led to incorrect conclusions regarding the authenticity Party (RP) is led to incorrect conclusions regarding the authenticity
of attestations made in the context of the RPKI. A CA cannot assume of attestations made in the context of the RPKI. A CA cannot assume
skipping to change at page 4, line 28 skipping to change at page 4, line 28
"new" CA certificate. While the "current" and "new" CA instances "new" CA certificate. While the "current" and "new" CA instances
share a single repository publication point, each CA has its own CRL share a single repository publication point, each CA has its own CRL
and its own manifest. Initially, the "new" CA publishes an empty CRL and its own manifest. Initially, the "new" CA publishes an empty CRL
and a manifest that contains a single entry for the CRL. The and a manifest that contains a single entry for the CRL. The
"current" CA also maintains its published CRL and manifest at this "current" CA also maintains its published CRL and manifest at this
Repository publication point. Repository publication point.
The CA performing key rollover waits for a period of time to afford The CA performing key rollover waits for a period of time to afford
every RP an opportunity to discover and retrieve this "new" CA every RP an opportunity to discover and retrieve this "new" CA
certificate, and store it in its local RPKI Repository cache certificate, and store it in its local RPKI Repository cache
instance. This period of time is termed the "staging period". During instance. This period of time is termed the "staging period".
this period, the CA will have a "new" CA instance, with no During this period, the CA will have a "new" CA instance, with no
subordinate products, and a "current" CA instance that has issued all subordinate products, and a "current" CA instance that has issued all
subordinate products. At the expiration of the staging period the subordinate products. At the expiration of the staging period the
"new" CA instance MUST replace all (valid) subordinate products of "new" CA instance MUST replace all (valid) subordinate products of
the "current" CA instance, overwriting the "current" subordinate the "current" CA instance, overwriting the "current" subordinate
products in the CA's repository publication point. When this process products in the CA's repository publication point. When this process
is complete the "current" CA instance is retired, and the "new" CA is complete the "current" CA instance is retired, and the "new" CA
instance becomes the "current" CA. instance becomes the "current" CA.
During the transition of the "current" and "new" CA instances it is During the transition of the "current" and "new" CA instances the
necessary for the "new" CA instance to re-issue all subordinate "new" CA instance MUST re-issue all subordinate products of the
products of the "current" CA. The procedure described here requires "current" CA. The procedure described here requires that, with the
that, with the exception of manifests and CRLs, the re-issued exception of manifests and CRLs, the re-issued subordinate products
subordinate products be published using the same repository be published using the same repository publication point object
publication point object names, effectively overwriting the old names, effectively overwriting the old objects with these re-issued
objects with these re-issued objects. The intent of this overwriting objects. The intent of this overwriting operation is to ensure that
operation is to ensure that the AIA pointers of subordinate products the AIA pointers of subordinate products at lower tiers in the RPKI
at lower tiers in the RPKI hierarchy remain correct, and that CA key hierarchy remain correct, and that CA key rollover does not require
rollover does not require any associated actions by any subordinate any associated actions by any subordinate CA.
CA.
There are three CA states described here: There are three CA states described here:
CURRENT: CURRENT:
The CURRENT CA is the active CA instance used to accept and The CURRENT CA is the active CA instance used to accept and
process certificate issuance and revocation requests The starting process certificate issuance and revocation requests. The
point for this algorithm is that the key of the CURRENT CA is to starting point for this algorithm is that the key of the CURRENT
be rolled over. CA is to be rolled over.
NEW: NEW:
The NEW CA is the CA instance that is being created. The NEW CA The NEW CA is the CA instance that is being created. The NEW CA
is not active, and thus does not accept nor process certificate is not active, and thus does not accept nor process certificate
issuance and revocation requests. The NEW CA SHOULD issue a CRL issuance and revocation requests. The NEW CA SHOULD issue a CRL
and an EE certificate in association with its manifest to provide and an EE certificate in association with its manifest to provide
a trivial, complete, consistent instance of a CA. a trivial, complete, consistent instance of a CA.
OLD: OLD:
The CA instance is in the process of being removed. An OLD CA The CA instance is in the process of being removed. An OLD CA
skipping to change at page 5, line 36 skipping to change at page 5, line 36
steps in the order given here. Unless specified otherwise each step steps in the order given here. Unless specified otherwise each step
SHOULD be performed without any intervening delay. The process MUST SHOULD be performed without any intervening delay. The process MUST
be run through to completion. be run through to completion.
1. Generate a new key pair for use by the NEW CA. Because the 1. Generate a new key pair for use by the NEW CA. Because the
goal of this algorithm is key rollover, the key pair generated goal of this algorithm is key rollover, the key pair generated
in this step MUST be different from the pair in use by the in this step MUST be different from the pair in use by the
CURRENT CA. CURRENT CA.
2. Generate a certificate request with this key pair and pass the 2. Generate a certificate request with this key pair and pass the
request to the CA that issued the CURRENT CA certificate. This request to the CA that issued the CURRENT CA certificate.
request MUST include the same SIA extension that is present in This request MUST include the same SIA extension that is
the CURRENT CA certificate. This request, when satisfied, present in the CURRENT CA certificate. This request, when
will result in the publication of the NEW CA certificate. satisfied, will result in the publication of the NEW CA
This (NEW) CA certificate will contain a Subject Name selected certificate. This (NEW) CA certificate will contain a Subject
by the issuer, which MUST be distinct from the Subject Name Name selected by the issuer, which MUST be distinct from the
used in the CURRENT CA certificate. The CPS for the issuer of Subject Name used in the CURRENT CA certificate. The
the NEW CA certificate will indicate the time frame within Certificate Practice Statement (CPS) for the issuer of the NEW
which a certificate request is expected to be processed. CA certificate will indicate the time frame within which a
certificate request is expected to be processed.
3. Publish the NEW CA's CRL and manifest. 3. Publish the NEW CA's CRL and manifest.
The steps involved here are: The steps involved here are:
- Wait for the issuer of the NEW CA to publish the NEW CA - Wait for the issuer of the NEW CA to publish the NEW CA
certificate. certificate.
- As quickly as possible following the publication of the - As quickly as possible following the publication of the
NEW CA certificate, use the key pair associated with the NEW CA certificate, use the key pair associated with the
skipping to change at page 6, line 28 skipping to change at page 6, line 30
EE certificate as the NEW CA's manifest EE certificate. EE certificate as the NEW CA's manifest EE certificate.
- Generate a manifest containing the new CA's CRL as the - Generate a manifest containing the new CA's CRL as the
only entry, and sign it with the private key associated only entry, and sign it with the private key associated
with the manifest EE certificate. Publish the manifest with the manifest EE certificate. Publish the manifest
at the NEW CA's repository publication point. at the NEW CA's repository publication point.
- Destroy the private key associated with the manifest EE - Destroy the private key associated with the manifest EE
certificate. certificate.
4. The NEW CA enters a Staging Period. This duration of the 4. The NEW CA enters a Staging Period. The duration of the
Staging Period is determined by the CA, but it SHOULD be no Staging Period is determined by the CA, but it SHOULD be no
less than 24 hours. The Staging Period is intended to afford less than 24 hours. The Staging Period is intended to afford
an opportunity for all RPs to download the NEW CA certificate, an opportunity for all RPs to download the NEW CA certificate,
prior to publication of certificates, CRLs, and RPKI signed prior to publication of certificates, CRLs, and RPKI signed
objects under the NEW CA. During the Staging Period, the NEW objects under the NEW CA. During the Staging Period, the NEW
CA SHOULD re-issue, but not publish, all of the products that CA SHOULD re-issue, but not publish, all of the products that
were issued under the CURRENT CA. This includes all CA were issued under the CURRENT CA. This includes all CA
certificates, EE certificates, and RPKI signed objects. certificates, EE certificates, and RPKI signed objects.
Section 4 describes how each re-issued product relates to the Section 4 describes how each re-issued product relates to the
product that it replaces. During the Staging Period, the product that it replaces. During the Staging Period, the
CURRENT CA SHOULD continue to accept and process certificate CURRENT CA SHOULD continue to accept and process certificate
issuance requests and MUST continue to accept and process issuance requests and MUST continue to accept and process
certificate revocation requests. If any certificates are certificate revocation requests. If any certificates are
issued by the CURRENT CA during the staging period, they MUST issued by the CURRENT CA during the Staging Period, they MUST
be re-issued under the NEW CA during the period. Any be re-issued under the NEW CA during this period. Any
certificates that are revoked under the CURRENT CA MUST NOT be certificates that are revoked under the CURRENT CA MUST NOT be
re-issued under the NEW CA. (As noted above, in the case of an re-issued under the NEW CA. As noted above, in the case of an
emergency key rollover, a CA will decide whether the 24 hour emergency key rollover, a CA will decide whether the 24 hour
minimal staging period interval is appropriate, or if a minimal Staging Period interval is appropriate, or if a
shorter Staging Period is needed.) shorter Staging Period is needed. As the Staging Period
imposes no additional burden on Relying Parties, there is no
stipulated or recommended maximum Staging Period.
5. Upon expiration of the Staging Period, the NEW CA MUST publish 5. Upon expiration of the Staging Period, the NEW CA MUST publish
the signed products that have been re-issued under the NEW CA, the signed products that have been re-issued under the NEW CA,
replacing the corresponding products issued under the CURRENT replacing the corresponding products issued under the CURRENT
CA at the NEW CA's repository publication point. This CA at the NEW CA's repository publication point. This
replacement is implied by the file naming requirements imposed replacement is implied by the file naming requirements imposed
by [ID.ietf-sidr-repos-struct] for these signed products. The by [ID.ietf-sidr-repos-struct] for these signed products. The
trivial manifest for the NEW CA (which contained only one trivial manifest for the NEW CA (which contained only one
entry, for the NEW CA's CRL) is replaced by a manifest listing entry, for the NEW CA's CRL) is replaced by a manifest listing
all of these re-issued, signed products. At this point the all of these re-issued, signed products. At this point the
skipping to change at page 8, line 17 skipping to change at page 8, line 20
this rule are that the notBefore value MAY be set to the current date this rule are that the notBefore value MAY be set to the current date
and time, and the certificate serial number MAY change. Because the and time, and the certificate serial number MAY change. Because the
re-issued CA certificate is issued by a different CA instance, it is re-issued CA certificate is issued by a different CA instance, it is
not a requirement that the certificate serial number change in the not a requirement that the certificate serial number change in the
re-issued certificate. Nonetheless, the CA MUST ensure that each re-issued certificate. Nonetheless, the CA MUST ensure that each
certificate issued under a specific CA instance (a distinct name and certificate issued under a specific CA instance (a distinct name and
key) contains a unique serial number. key) contains a unique serial number.
4.2. RPKI Signed Objects 4.2. RPKI Signed Objects
An RPKI signed object is a CMS signed-data object, containing an EE An RPKI signed object is a Cryptographic Message Syntax (CMS) signed-
certificate and a payload (content) [ID.ietf-sidr-signed-object]. data object, containing an EE certificate and a payload (content)
When a key rollover occurs, the EE certificate for the RPKI signed [ID.ietf-sidr-signed-object]. When a key rollover occurs, the EE
object MUST be re-issued, under the key of the NEW CA. A CA MAY certificate for the RPKI signed object MUST be re-issued, under the
choose to treat this EE certificate the same way that it deals with key of the NEW CA. A CA MAY choose to treat this EE certificate the
CA certificates, i.e., to copy over all fields and extensions, and same way that it deals with CA certificates, i.e., to copy over all
MAY change only the notBefore date and the serial number. If the CA fields and extensions, and MAY change only the notBefore date and the
adopts this approach, then the new EE certificate is inserted into serial number. If the CA adopts this approach, then the new EE
the CMS wrapper, but the signed context remains the same. (If the certificate is inserted into the CMS wrapper, but the signed context
signing time or binary signing time values in the CMS wrapper are remains the same. (If the signing time or binary signing time values
non-null, they MAY be updated to reflect the current time.)
Alternatively, the CA MAY elect to generate a new key pair for this
EE certificate. If it does so, the object content MUST be resigned
under the private key corresponding to the EE certificate. In this
case the EE certificate MUST contain a new public key and a new
notBefore value, and it MAY contain a new notAfter value, but all
other field and extension values, other that those relating to the
digital signature and its associated certificate validation path,
remain unchanged. If the signing time or binary signing time values
in the CMS wrapper are non-null, they MAY be updated to reflect the in the CMS wrapper are non-null, they MAY be updated to reflect the
current time. current time.) Alternatively, the CA MAY elect to generate a new key
pair for this EE certificate. If it does so, the object content MUST
be resigned under the private key corresponding to the EE
certificate. In this case the EE certificate MUST contain a new
public key and a new notBefore value, and it MAY contain a new
notAfter value, but all other field and extension values, other that
those relating to the digital signature and its associated
certificate validation path, remain unchanged. If the signing time
or binary signing time values in the CMS wrapper are non-null, they
MAY be updated to reflect the current time.
As noted in Section 2.1.6.4.3 and 2.1.6.4.4 of As noted in Section 2.1.6.4.3 and 2.1.6.4.4 of
[ID.ietf-sidr-signed-object], the presence or absence of the [ID.ietf-sidr-signed-object], the presence or absence of the
SigningTime and/or the BinarySigningTime attribute MUST NOT affect SigningTime and/or the BinarySigningTime attribute MUST NOT affect
the validity of the RPKI signed object. the validity of the RPKI signed object.
5. Security Considerations 5. Security Considerations
No key should be used forever. The longer a key is in use, the No key should be used forever. The longer a key is in use, the
greater the probability that it will have been compromised through greater the probability that it will have been compromised through
skipping to change at page 9, line 38 skipping to change at page 9, line 40
7. Acknowledgements 7. Acknowledgements
The authors would like to acknowledge the review comments of Tim The authors would like to acknowledge the review comments of Tim
Bruijnzeels and Sean Turner in preparing this document. Bruijnzeels and Sean Turner in preparing this document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[ID.ietf-sidr-arch]
Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch-12 (work in
progress), February 2011.
[ID.ietf-sidr-repos-struct] [ID.ietf-sidr-repos-struct]
Huston, G., Loomans, R., and G. Michaelson, "A Profile for Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure", Internet Resource Certificate Repository Structure", Internet
Draft draft-ietf-sidr-repos-struct-07.txt, February, 2011. Draft draft-ietf-sidr-repos-struct-07.txt, February 2010.
[ID.ietf-sidr-res-certs] [ID.ietf-sidr-res-certs]
Huston, G., Michaelson, G., and R. Loomans, "A Profile for Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", Internet X.509 PKIX Resource Certificates", Internet
Draft draft-ietf-sidr-res-certs-21.txt, December 2010. Draft draft-ietf-sidr-res-certs-18.txt, May 2010.
8.2. Informative References
[RFC3779] [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC5280] [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key
Housley, R.,and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List
Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
(CRL) Profile", RFC 5280, May 2008.
[ID.ietf-sidr-arch] 8.2. Informative References
Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch-12.txt (work
in progress), February 2011.
[ID.ietf-sidr-signed-object] [ID.ietf-sidr-signed-object]
Lepinski, M., Chi, A., and S. Kent, "Signed Object Lepinski, M., Chi, A., and S. Kent, "Signed Object
Template for the Resource Public Key Infrastructure", Template for the Resource Public Key Infrastructure",
draft-ietf-sidr-signed-object-03.txt (work in progress), draft-ietf-sidr-signed-object-03.txt (work in progress),
February 2011. February 2011.
Authors' Addresses Authors' Addresses
Geoff Huston Geoff Huston
Asia Pacific Network Information Centre Asia Pacific Network Information Centre
Email: gih@apnic.net Email: gih@apnic.net
URI: http://www.apnic.net URI: http://www.apnic.net
George Michaelson George Michaelson
 End of changes. 25 change blocks. 
81 lines changed or deleted 81 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/