draft-ietf-sidr-rtr-keying-00.txt   draft-ietf-sidr-rtr-keying-01.txt 
Network Working Group S. Turner SIDR Working Group S. Turner
Internet-Draft IECA, Inc. Internet-Draft IECA, Inc.
Intended status: BCP K. Patel Intended status: BCP K. Patel
Expires: November 15, 2012 Cisco Systems Expires: August 27, 2013 Cisco Systems
R. Bush R. Bush
Internet Initiative Japan, Inc. Internet Initiative Japan, Inc.
May 14, 2012 February 23, 2013
Router Keying for BGPsec Router Keying for BGPsec
draft-ietf-sidr-rtr-keying-00 draft-ietf-sidr-rtr-keying-01
Abstract Abstract
BGPsec-speaking routers must be provisioned with private keys and the BGPsec-speaking routers must be provisioned with private keys and the
corresponding public key must be published in the global Resource corresponding public key must be published in the global RPKI
PKI. This document describes two ways of doing so, router-driven and (Resource Public Key Infrastructure). This document describes two
operator-driven. ways of provisioning public/private keys, router-driven and operator-
driven.
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 November 15, 2012. This Internet-Draft will expire on August 27, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Router-Generated Keys . . . . . . . . . . . . . . . . . . . . . 4
4. Operator-Generated Keys . . . . . . . . . . . . . . . . . . . . 4
5. Provisioning a New Router . . . . . . . . . . . . . . . . . . . 4
6. Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
BGPsec-speaking routers must be provisioned with private keys and the BGPsec-speaking routers must be provisioned with private keys and the
corresponding public key must be published in the global RPKI corresponding public key must be published in the global RPKI
(Resource Public Key Infrastructure). Note that the public key is (Resource Public Key Infrastructure). The public key is published in
published in the RPKI in the form of a certificate the RPKI in the form of a certificate [I-D.ietf-sidr-bgpsec-pki-
[I-D.ietf-sidr-bgpsec-pki-profiles]. This document describes two profiles]. This document describes two methods for generating the
methods for generating the necessary public/private key-pair: router- necessary public/private key-pair: router-driven and operator-driven.
driven and operator-driven.
In the router-driven method, the router generates its own public/
private key-pair, uses the private key to sign a certification
request [I-D.ietf-sidr-bgpsec-pki-profiles] (a PKCS#10 - includes the
public key), and sends the certification request to the RPKI CA
(Certification Authority). The CA returns a PKCS#7, which includes
the certified public key in the form of a certificate, to the router
and the CA also publishes the certificate in the RPKI.
The router-driven model mirrors the model used by most PKI The difference between the two models is where the keys are
subscribers. In many cases, the private key never leaves trusted generated. Keys are generated on the router in the router-drive
storage (e.g., HSM (Hardware Security Model)). This is by design and method but elsewhere by the operator in the operator-drive model.
supports CPs (Certification Policies), often times for human The router-driven model is most familiar to PKI subscribers because
subscribers, that require the private key only ever be controlled by its design supports CPs (Certification Policies), often times for
the subscriber to ensure that no one can impersonate the subscriber. human subscribers, that require the private key only ever be
For non-humans, this model does not always work. For example, when controlled by the subscriber to ensure that no one can impersonate
an operator wants to support hot-swappable routers the same private the subscriber. For non-humans, this model does not always work in
key needs to be installed in the soon-to-be online router that was particular when an operator wants to support hot-swappable routers
installed in the soon-to-be offline router. This motivated the the same private key needs to be installed in the soon-to-be online
operator-driven model. router that was installed in the soon-to-be offline router.
In the operator-driven model, the operator generates the private/ The remainder of this document describes how operators can use the
public key-pair and sends it to the router in a PKCS#8 [RFC5958]. two methods to provision new and existing routers.
In both cases, the key pair is for algorithms defined in Note that in both models, the key pair is for algorithms defined in
[I-D.ietf-sidr-bgpsec-algs]. The first version specifies ECDSA on [I-D.ietf-sidr-bgpsec-algs]. The first version specifies ECDSA on
the P-256 curve. the P-256 curve.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].
It is assumed that the reader understands BGPsec, see It is assumed that the reader understands BGPsec [I-D.ietf-sidr-
[I-D.lepinski-bgpsec-overview], [I-D.lepinski-bgpsec-protocol], the bgpsec-overview] [I-D.ietf-sidr-bgpsec-protocol], the RPKI [RFC6480],
RPKI, see [RFC6480], and [I-D.ietf-sidr-bgpsec-pki-profiles]. and [I-D.ietf-sidr-bgpsec-pki-profiles].
3. Router-Generated Keys 3. Provisioning a New Router
For router-generated keys, the public/private keys are made by the When commissioning a new router, operators may use either the router-
router, a PKCS#10 is made by the router, and signed by the private driven or operator-drive methods. Regardless of the method chosen,
key, and is transferred to the RPKI CA. The CA returns a PKCS#7, the the operator first needs to establish a secure communication channel
operator transfers the PKCS#7 to the router, and the router picks the with the router. Today, this is done via a proprietary management
certificate out of the PKCS#7. Even if the operator can not get the box directly connected to the router on the serial/craft port {spt:
private key off the router this still provides a linkage between a is serial/craft port the correct terminology?}. After the management
private key and a router. box has been physically connected to the router, the operator
authenticates to the management box, via a proprietary mechanism
{spt: is this really proprietary or it is leap-of-faith?}, and uses
the CLI (command line interface) to generate the router's SSH (Secure
Shell) key [RFC4253], retrieve the router's SSH public key, install
the operator's SSH key(s), configures the Ethernet port [IEEE-802.3],
BGPSEC-router number {spt: assume this is where the BGPSEC-router #
will get "installed" for the router-driven case to know what to put
in the PKCS#10}, etc. {spt: did I miss anything?}.
4. Operator-Generated Keys {spt: i added CA certificate in the above for the router to verify
that the CA actually signed the certificate. overkill?}
For operator-generated keys, the public/private keys are made by the {spt: this could go here or in the security considerations. i am
operator with their RPKI management software. The private key pair ambivalent about where it ends up, but i think we should have this
MUST be as specified in [RFC5915], which supports ECDSA keys. That data in here somewhere. i'd like to think if we're provisioning
format MUST then be inserted to a PKCS#8 [RFC5958] along with the these routers with ECDSA keys that we're going to be using algorithms
certificate. If the operator wants to ship the keys around they can at least as good!? the one that gives me heartburn is hmac-sha2-256
use the .p8 file extension and optional PEM encoding also from seems like there ought to be a 128-bit truncated version to match
[RFC5958]. with the others.}
EDITOR NOTE: One thing we should consider is whether the certificate The SSH encryption, integrity, authentication, and key exchange
needs to returned to the router like in the router-generated keys mechanisms used by the router and operator SHOULD be of comparable
method. PKCS#8 supports including the certificate so it's not a big strength to BGPSEC key, which is 128-bit strength, e.g., for
deal to add it if we do. encryption: aes128-cbc [RFC4253] and AEAD_AES_128_GCM [RFC5647], for
integrity: hmac-sha2-256 [RFC6668] and AESAD_AES_128_GCM [RFC5647],
for authentication: ecdsa-sha2-nistp256 [RFC5656], and for key
exchange: ecdh-sha2-nistp256 [RFC5656].
5. Provisioning a New Router {spt: i'm unsure whether the following is being done, but it could be
done so i think it's worth mentioning it.}
When commissioning a new router, the operator may use either of the Note that if the router supports public key certificates at this
above methods. point, which would have had to have been provided by the operator at
this point, x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used
instead for authentication. The SSH certificate, profiled in
[RFC6187], would be different than the BGPSEC certificate.
Using the Router-Generated Keys method, see Section 3, the operator {spt: do the commands to generate/deposit a key need to come over the
decides on the AS number and the BGP RouterID of the router, logs on ethernet port or if they can come over the management port?}
to the new router using the craft port, ssh, etc., and requests that
the router generate a public/private key-pair and generate and sign
(with the private key) a PKCS#10 request. The operator then off-
loads the PKCS#10 request and uploads the request to their RPKI
software management tools. The tools create and publish the RPKI
Router-Key object for the public key, and return the PKCS#7. The
operator uploads the PKCS#7 to the router which then extracts its
certificate.
The router MAY use the PKCS#7 as an indicator that the certificate Once generated, the operator establishes an SSH connection with the
request was actually processed, and SHOULD verify that the issued router and the management box is no longer needed. At this point,
certificate actually corresponds to the private key the router holds. the choice of router-driven or operator-driven is vendor specific.
Using the Operator-Generated Key method, see Section 4, the operator 3.1. Router-Generated Keys
decides on the AS number and the BGP RouterID of the new router and
uses their RPKI software management tools to generate the public/
private key-pair and publish the public key in the RPKI. The tools
also produce the PKCS#8 object which the operator then uploads into
the new router via the craft port, ssh, NetConf, etc. The router
installs the PKCS#8 and installs the public/private key-pair.
The router SHOULD verify that the issued certificate actually In the router-driven method, once an SSH connection is established
corresponds to the private key in the PKCS#8, i.e. the PKCS#8 is between the operator and the router the operator issues a command, or
self-consistent. commands, to generate the public/private key pair on the router, to
generate the PKCS#10 that includes the router number and public key,
and sign the PKCS#10 with the private key. [I-D.ietf-sidr-bgpsec-
pki-profiles] specifies the format for the PKCS #10 and the algorithm
used to generate the signature is specified in [I-D.ietf-sidr-bgpsec-
algs].
6. Other Use Cases {spt: Not sure if the distinction I made here between direct and
indirect makes any sense.}
Current router code generates private keys for uses such as ssh, but The PKCS#10 request can be directly transferred to the RPKI CA over
the Ethernet port if the router supports protocols such as FTP and
HTTP [RFC2585] using the application/pkcs10 media type [RFC5967] or
EST (Enrollment over Secure Transport) [I-D.ietf-pkix-est]. The CA
returns a successful request as a PKCS#7 [I-D.ietf-sidr-bgpsec-pki-
profiles], which includes the certificate, and uploads the
certificate to the global RPKI. The response can be returned using
the application/pkcs7-mime media type [RFC5751] if the router
supports protocols such as FTP and HTTP.
The PKCS#10 request can also be indirectly transferred to the RPKI CA
through the operator. The operator off-loads the PKCS#10 and uploads
the request to their RPKI software management tools. The tools
create and publish the certificate for the public key, and return the
PKCS#7 to the router.
{spt: the bit about checking the returned certificate is new, but i
think a good idea. but, does the CA's certificate get returned in
the PKCS#7 - I couldn't find that in the cert profile?}
The router SHOULD extract the certificate from the PCKCS#7 and verify
that the private key corresponds to the returned public key. The
router SHOULD inform the operator that it has successfully received
its certificate; this mechanism is out of scope. When the keys do
not correspond, the router SHOULD inform the operator; this mechanism
is out of scope. The router SHOULD also verify the returned
certificate back to a trust anchor, but to perform this verification
either the CA's certificate needs to be installed on the router via
the CLI or the CA's certificate needs to be returned along with the
router's certificate in the PKCS#7. The router SHOULD inform the
operator if the signature does not validate to a trust anchor; this
notification mechanism is out of scope. After performing these
checks, the router need not retain the certificate.
Note that even if the operator can not get the private key off the
router this still provides a linkage between a private key and a
router.
3.2. Operator-Generated Keys
In the operator-driven method, the operator generates the private key
and it is installed over the SSH connection established between the
operator and the router. The operator uses their RPKI management
tools to generate the keys, the PKCS#10 certification request, the
certificate, and the PKCS#7 certification response as well as publish
the certificate for the public key in the global RPKI. The private
key MUST support the algorithm specified in [I-D.ietf-sidr-bgpsec-
algs], which for ECDSA is specified in [RFC5915]. The PKCS#10 and
PKCS#7 are as specified in [I-D.ietf-sidr-bgpsec-pki-profiles].
{spt: i figured maybe we could sign the PKCS#8, but that would have
to be done with a key other than the CA's key. It would have to be
the operator's EE key.}
Along with the PKCS#7, the operator returns the private key. The
private key is encapsulated in a PKCS #8 [RFC5958], the PKCS#8 is
further encapsulated in a CMS (Cryptographic Message Syntax)
SignedData [RFC5652], and signed by the operator's EE certificate.
The router SHOULD verify the signature on the encapsulated PKCS#8 to
ensure the returned private key in fact came from the operator, but
this requires that the operator also provision via the CLI or include
in the SignedData the RPKI CA certificates and operator's EE
certificates. The router SHOULD inform the operator if the signature
does not validate to a trust anchor; this notification mechanism is
out of scope.
The router SHOULD extract the certificate for the PKCS#7 and verify
that the private key corresponds to the returned public key. The
router SHOULD inform the operator that it has successfully received
its certificate; this mechanism is out of scope. When the keys do
not correspond, the router SHOULD inform the operator; this mechanism
is out of scope. The router SHOULD also verify the returned
certificate back to a trust anchor, but to perform this verification
either the CA's certificate needs to be installed on the router via
the CLI or the CA's certificate needs to be returned along with the
router's certificate in the PKCS#7. The router SHOULD inform the
operator if the signature does not validate to a trust anchor; this
notification mechanism is out of scope. After performing these
checks, the router need not retain the certificate.
5. Other Use Cases
Current router code generates private keys for uses such as SSH, but
the private keys may not be seen or off-loaded via CLI or any other the private keys may not be seen or off-loaded via CLI or any other
means. While this is good security, it creates difficulties when a means. While this is good security, it creates difficulties when a
routing engine or whole router must be replaced in the field and all routing engine or whole router must be replaced in the field and all
software which accesses the router must be updated with the new keys. software which accesses the router must be updated with the new keys.
Also, the initial contact with a new routing engine requires trust in Also, the initial contact with a new routing engine requires trust in
the public key presented on first contact. the public key presented on first contact.
To allow operators to quickly replace routers without requiring To allow operators to quickly replace routers without requiring
update and distribution of the corresponding public keys in the RPKI, update and distribution of the corresponding public keys in the RPKI,
routers SHOULD allow the private BGPsec key to be off-loaded via the routers SHOULD allow the private BGPsec key to be off-loaded via the
CLI, NetConf (see [RFC6470]), SNMP, etc. This lets the operator CLI, NetConf (see [RFC6470]), SNMP, etc. This lets the operator
upload the old private key via the mechanism used for Operator- upload the old private key via the mechanism used for operator-
Generated Keys, see Section 4. generated keys, see Section 3.2.
7. Security Considerations 6. Security Considerations
Operator-generated keys could be intercepted in transport and the Operator-generated keys could be intercepted in transport and the
recipient router would have no way of knowing a substitution had been recipient router would have no way of knowing a substitution had been
made by a monkey in the middle. Hence transport security is strongly made or that the key had been disclosed by a monkey in the middle.
advised. Hence transport security is strongly RECOMMENDED. As noted in
Section 3, the level of security provided by the transport security
SHOULD be commensurate with the BGPsec key. Additionally, operators
SHOULD ensure the transport security implementation is up to date and
addresses all known implementation bugs.
8. IANA Considerations All generated key pairs MUST be generated from a good source of non-
deterministic random input [RFC4086] and the private key MUST be
protected in a secure fashion. Disclosure of the private key leads
to masquerade [RFC4949]. The local storage format for the private
key is a local matter.
Though the CA's certificate is installed on the router and used to
verify the returned certificate is in fact signed by the CA, the
revocation status of the CA's certificate is not checked. The
operator MUST ensure that installed CA certificate is valid.
Operators need to manage their SSH keys to ensure only those
authorized to access the router can. As employees no longer need
access to the router, their keys SHOULD be removed from the router.
7. IANA Considerations
This document has no IANA Considerations. This document has no IANA Considerations.
9. References 8. References
9.1. Normative References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
June 2005.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, January 2006.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, September 2009.
[RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key
Structure", RFC 5915, June 2010. Structure", RFC 5915, June 2010.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August
August 2010. 2010.
9.2. Informative References
[I-D.ietf-sidr-bgpsec-algs] [I-D.ietf-sidr-bgpsec-algs]
Turner, S., "BGP Algorithms, Key Formats, & Signature Turner, S., "BGP Algorithms, Key Formats, & Signature
Formats", draft-ietf-sidr-bgpsec-algs-02 (work in Formats", draft-ietf-sidr-bgpsec-algs (work in progress),
progress), March 2012. September 2012.
[I-D.ietf-sidr-bgpsec-pki-profiles] [I-D.ietf-sidr-bgpsec-pki-profiles]
Reynolds, M., Turner, S., and S. Kent, "A Profile for Reynolds, M., Turner, S., and S. Kent, "A Profile for
BGPSEC Router Certificates, Certificate Revocation Lists, BGPSEC Router Certificates, Certificate Revocation Lists,
and Certification Requests", and Certification Requests",
draft-ietf-sidr-bgpsec-pki-profiles-03 (work in progress), draft-ietf-sidr-bgpsec-pki-profiles (work in progress),
April 2012. October 2012.
[I-D.lepinski-bgpsec-overview] 8.2. Informative References
[I-D.ietf-sidr-bgpsec-overview]
Lepinski, M. and S. Turner, "An Overview of BGPSEC", Lepinski, M. and S. Turner, "An Overview of BGPSEC",
draft-lepinski-bgpsec-overview-00 (work in progress), draft-ietf-sidr-bgpsec-overview (work in progress),
March 2011. December 2012.
[I-D.lepinski-bgpsec-protocol] [I-D.ietf-sidr-bgpsec-protocol]
Lepinski, M., "BGPSEC Protocol Specification", Lepinski, M., "BGPSEC Protocol Specification",
draft-lepinski-bgpsec-protocol-00 (work in progress), draft-ietf-sidr-bgpsec-protocol (work in progress),
March 2011. October 2012.
[I-D.ietf-pkix-est]
Pritikin, M, Yee, P., and D. Harkins "Enrollment over
Secure Transport", draft-ietf-pkix-est (work in progress),
February 2013.
[IEEE-802.3]
ISO/IEC 8802-3 Information technology -
Telecommunications and information exchange between
systems - Local and metropolitan area networks -
Common specifications - Part 3: Carrier Sense
Multiple Access with Collision Detection (CSMA/CD)
Access Method and Physical Layer Specifications, 2008.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, May 1999.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, January 2006.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI
36, RFC 4949, August 2007.
[RFC5647] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the
Secure Shell Transport Layer Protocol", RFC 5647, August
2009.
[RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm
Integration in the Secure Shell Transport Layer",
RFC 5656, December 2009.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967,
August 2010.
[RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure
Shell Authentication", RFC 6187, March 2011.
[RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF)
Base Notifications", RFC 6470, February 2012. Base Notifications", RFC 6470, February 2012.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012. Secure Internet Routing", RFC 6480, February 2012.
[RFC6668] Bider, D. and M. Baushke, "SHA-2 Data Integrity
Verification for the Secure Shell (SSH) Transport Layer
Protocol", RFC 6668, July 2012.
Authors' Addresses Authors' Addresses
Sean Turner Sean Turner
IECA, Inc. IECA, Inc.
3057 Nutley Street, Suite 106 3057 Nutley Street, Suite 106
Fairfax, Virginia 22031 Fairfax, Virginia 22031
US US
Email: turners@ieca.com Email: turners@ieca.com
 End of changes. 41 change blocks. 
126 lines changed or deleted 269 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/