draft-ietf-dhc-v4-threat-analysis-00.txt   draft-ietf-dhc-v4-threat-analysis-01.txt 
Network Working Group R. Hibbs Network Working Group R. Hibbs
Internet-Draft Richard Barr Hibbs, P.E. Internet-Draft Richard Barr Hibbs, P.E.
Expires: December 12, 2003 C. Smith Expires: September 28, 2004 C. Smith
Sun Microsystems Sun Microsystems, Inc.
B. Volz B. Volz
Ericsson Cisco Systems, Inc.
M. Zohar M. Zohar
IBM IBM T. J. Watson Research Center
June 13, 2003 March 30, 2004
Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis
draft-ietf-dhc-v4-threat-analysis-00 draft-ietf-dhc-v4-threat-analysis-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 12, 2003. This Internet-Draft will expire on September 28, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
DHCPv4 (RFC 2131) is a stable, widely used protocol for configuration DHCPv4 (RFC 2131) is a stable, widely used protocol for configuration
of host systems in a TCP/IPv4 network. It did not provide for of host systems in a TCP/IPv4 network. It did not provide for
authentication of clients and servers, nor did it provide for data authentication of clients and servers, nor did it provide for data
confidentiality. This is reflected in the original "Security confidentiality. This is reflected in the original "Security
Considerations" section of RFC 2131, which identifies a few threats Considerations" section of RFC 2131, which identifies a few threats
and leaves development of any defenses against those threats to and leaves development of any defenses against those threats to
future work. Beginning in about 1995 DHCP security began to attract future work. Beginning in about 1995 DHCP security began to attract
skipping to change at page 2, line 23 skipping to change at page 2, line 23
Full Standard and to support our chartered work improving the Full Standard and to support our chartered work improving the
acceptance and deployment of RFC 3118. acceptance and deployment of RFC 3118.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Issues for Consideration . . . . . . . . . . . . . . . . . . 3 1.1 Issues for Consideration . . . . . . . . . . . . . . . . . . 3
1.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Scope of this Memo . . . . . . . . . . . . . . . . . . . . . 3 1.3 Scope of this Memo . . . . . . . . . . . . . . . . . . . . . 3
1.4 Use of Key Words . . . . . . . . . . . . . . . . . . . . . . 4 1.4 Use of Key Words . . . . . . . . . . . . . . . . . . . . . . 4
2. General threats to DHCPv4 . . . . . . . . . . . . . . . . . 5 2. General threats to DHCPv4 . . . . . . . . . . . . . . . . . 4
2.1 Denial-of-Service Attacks . . . . . . . . . . . . . . . . . 5 2.1 Denial-of-Service Attacks . . . . . . . . . . . . . . . . . 4
2.1.1 Refusal to Configure Clients . . . . . . . . . . . . . . . . 5 2.1.1 Refusal to Configure Clients . . . . . . . . . . . . . . . . 4
2.1.2 Client Masquerading . . . . . . . . . . . . . . . . . . . . 5 2.1.2 Client Masquerading . . . . . . . . . . . . . . . . . . . . 4
2.1.3 Flooding . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.3 Flooding . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Client Misconfiguration . . . . . . . . . . . . . . . . . . 5 2.2 Client Misconfiguration . . . . . . . . . . . . . . . . . . 5
2.3 Theft of Service . . . . . . . . . . . . . . . . . . . . . . 6 2.3 Theft of Service . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Packet Insertion, Deletion, or Modification . . . . . . . . 6 2.4 Packet Insertion, Deletion, or Modification . . . . . . . . 5
3. Weaknesses of RFC 3118 . . . . . . . . . . . . . . . . . . . 7 3. Weaknesses of RFC 3118 . . . . . . . . . . . . . . . . . . . 6
3.1 Key Exposure . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 Key Exposure . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Key Distribution . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Key Distribution . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Replay attacks . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 Replay attacks . . . . . . . . . . . . . . . . . . . . . . . 6
3.4 Protocol Agreement Difficulties . . . . . . . . . . . . . . 8 3.4 Protocol Agreement Difficulties . . . . . . . . . . . . . . 7
4. DHCPv4 Security Requirements . . . . . . . . . . . . . . . . 9 4. DHCPv4 Security Requirements . . . . . . . . . . . . . . . . 7
4.1 Environments . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1 Environments . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2 Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2 Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3 Musings on the Key Distribution Problem . . . . . . . . . . 10 4.3 Musings on the Key Distribution Problem . . . . . . . . . . 8
4.4 Data Confidentiality . . . . . . . . . . . . . . . . . . . . 10 4.4 Data Confidentiality . . . . . . . . . . . . . . . . . . . . 8
4.4.1 "Public" Data in DHCP Packets . . . . . . . . . . . . . . . 11 4.4.1 "Public" Data in DHCP Packets . . . . . . . . . . . . . . . 9
4.4.2 Protecting Other Data in DHCP Options . . . . . . . . . . . 11 4.4.2 Protecting Other Data in DHCP Options . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
Normative References . . . . . . . . . . . . . . . . . . . . 15 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 10
Informative References . . . . . . . . . . . . . . . . . . . 16 8.1 01 Draft . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 Normative References . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . 18 Informative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . 13
1. Introduction 1. Introduction
DHCPv4 as defined in RFC 1541 [1] and RFC 2131 [2] does not provide DHCPv4 as defined in RFC 1541 [RFC1541] and RFC 2131 [RFC2131] does
any form of communication security, confidentiality, data integrity, not provide any form of communication security, confidentiality, data
or peer entity authentication. integrity, or peer entity authentication.
A design team was formed at IETF-55 in Atlanta in November 2002 to A design team was formed at IETF-55 in Atlanta in November 2002 to
look at DHCPv4 and RFC 3118 [3] to document security requirements for look at DHCPv4 and RFC 3118 [RFC3118] to document security
DHCPv4. RFC 3118 defines the current security mechanisms for DHCPv4. requirements for DHCPv4. RFC 3118 defines the current security
mechanisms for DHCPv4.
Unfortunately, RFC 3118 has neither been implemented nor deployed to Unfortunately, RFC 3118 has neither been implemented nor deployed to
date. There is widespread feeling that its current restriction to date. There is widespread feeling that its current restriction to
manual keying of clients limits its deployment. The DHC Working manual keying of clients limits its deployment. The DHC Working
Group seeks to rectify this situation by defining security mechanisms Group seeks to rectify this situation by defining security mechanisms
for DHCPv4 that have better deployment properties. for DHCPv4 that have better deployment properties.
1.1 Issues for Consideration 1.1 Issues for Consideration
Specific issues to be considered include: Specific issues to be considered include:
skipping to change at page 3, line 45 skipping to change at page 3, line 42
1.2 Assumptions 1.2 Assumptions
This document assumes that the reader is familiar with both the base This document assumes that the reader is familiar with both the base
DHCPv4 protocol as defined in RFC 2131 and the DHCPv4 authentication DHCPv4 protocol as defined in RFC 2131 and the DHCPv4 authentication
extension as defined in RFC 3118, and does not attempt to provide a extension as defined in RFC 3118, and does not attempt to provide a
tutorial on either. tutorial on either.
1.3 Scope of this Memo 1.3 Scope of this Memo
This document confines its analysis to DHCPv4, as defined in RFC 2131 This document confines its analysis to DHCPv4, as defined in RFC 2131
and RFC 2132 [4] and DHCP Authentication, as defined in RFC 3118. and RFC 2132 [RFC2132] and DHCP Authentication, as defined in RFC
3118.
Excluded from our analysis are
o The DHCP Reconfigure Extension (FORCERENEW), RFC 3203 [10]: the
authors believe it is appropriate to put the onus to provide the
analysis on those who are interested in moving it forward.
o DHCP Failover Protocol, as defined in [11]: the server-to-server
protocol it uses differs significantly from DHCP.
o DHCP-DNS Interaction, as defined in [12]: securing communication Excluded from our analysis are:
o The DHCP Reconfigure Extension (FORCERENEW), RFC 3203 [RFC3203]:
the authors believe it is appropriate to put the onus to provide
the analysis on those who are interested in moving it forward.
o DHCP Failover Protocol, as defined in [failover]: the
server-to-server protocol it uses differs significantly from DHCP.
o DHCP-DNS Interaction, as defined in [fqdn]: securing communication
between DHCP servers and DNS servers is a DNS update security between DHCP servers and DNS servers is a DNS update security
issue and therefore out of scope for the DHC working group. issue and therefore out of scope for the DHC working group.
o DHCPv6, as defined in RFC 3315 [RFC3315]: while we believe that
o DHCPv6, as defined in [13]: while we believe that authentication authentication techniques developed for DHCPv4 would generally be
techniques developed for DHCPv4 would generally be applicable to applicable to DHCPv6, there are fundamental differences between
DHCPv6, there are fundamental differences between the two the two protocols and RFC 3118 specifies DHCPv4-style message and
protocols and RFC 3118 specifies DHCPv4-style message and options options formats, so we have chosen to concentrate on DHCPv4.
formats, so we have chosen to concentrate on DHCPv4. o DHCP Lease Query, as defined in [leasequery]: because of lack of
maturity.
o DHCP Lease Query, as defined in [14]: because of lack of maturity
1.4 Use of Key Words 1.4 Use of Key Words
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," "MAY," and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. [5] document are to be interpreted as described in RFC 2119 [RFC2119].
2. General threats to DHCPv4 2. General threats to DHCPv4
These are the classes of threats to the base DHCPv4 protocol. Not These are the classes of threats to the base DHCPv4 protocol. Not
all of these are DHCP-specific, nor can all the concerns listed be all of these are DHCP-specific, nor can all the concerns listed be
addressed by DHCP authentication. addressed by DHCP authentication.
2.1 Denial-of-Service Attacks 2.1 Denial-of-Service Attacks
2.1.1 Refusal to Configure Clients 2.1.1 Refusal to Configure Clients
skipping to change at page 10, line 48 skipping to change at page 8, line 50
4.4 Data Confidentiality 4.4 Data Confidentiality
Data Confidentiality was not provided for in the original DHCP Data Confidentiality was not provided for in the original DHCP
protocol as defined in RFC 2131 or any of the subsequent RFCs. protocol as defined in RFC 2131 or any of the subsequent RFCs.
Historically, DHCP was mainly used to assign IP addresses and return Historically, DHCP was mainly used to assign IP addresses and return
configuration options such as the local gateway and DNS information. configuration options such as the local gateway and DNS information.
Over time the DHCP protocol has evolved, deployments are extending Over time the DHCP protocol has evolved, deployments are extending
beyond physically secure intranets to public networks in hotspots, beyond physically secure intranets to public networks in hotspots,
cafs, airports, and at home over broadband. and we are seeing an cafes, airports, and at home over broadband. and we are seeing an
accompanying proliferation of new configuration options. accompanying proliferation of new configuration options.
DHCP has, in fact, become so successful that it is now used to DHCP has, in fact, become so successful that it is now used to
transport a great deal of configuration data that could be obtained transport a great deal of configuration data that could be obtained
in a variety of other ways. It is certainly possible that a client in a variety of other ways. It is certainly possible that a client
or server might wish to reveal some of these data only to a or server might wish to reveal some of these data only to a
properly-authenticated peer. properly-authenticated peer.
4.4.1 "Public" Data in DHCP Packets 4.4.1 "Public" Data in DHCP Packets
skipping to change at page 11, line 24 skipping to change at page 9, line 26
communication will be encrypted, so that less information could be communication will be encrypted, so that less information could be
gleaned from the network traffic. Taking this into consideration, gleaned from the network traffic. Taking this into consideration,
the IP packet payload might be encrypted, but not the IP header the IP packet payload might be encrypted, but not the IP header
itself since it is required for packet routing. As a result none of itself since it is required for packet routing. As a result none of
the IP header fields are confidential. IP addresses included in the the IP header fields are confidential. IP addresses included in the
header are therefore not confidential. header are therefore not confidential.
Although the IP packet payload (which would include the UDP or TCP Although the IP packet payload (which would include the UDP or TCP
header) might normally be encrypted, some protocols have made header) might normally be encrypted, some protocols have made
explicit decisions not to encrypt their exchanges, declaring their explicit decisions not to encrypt their exchanges, declaring their
data public. DNS is such a protocol [15]. Thus we may also treat data public. DNS is such a protocol [dns-threats]. Thus we may also
DNS domain and server information as public. treat DNS domain and server information as public.
Commonly-used routing protocols such as BGP (RFC 1771) [6], RIP (RFC Commonly-used routing protocols such as BGP (RFC 1771) [RFC1771], RIP
1721) [7], and router discovery (RFC 1256) [8] also normally send (RFC 1721) [RFC1721], and router discovery (RFC 1256) [RFC1256] also
advertisements in the clear and we therefore extend our treatment of normally send advertisements in the clear and we therefore extend our
public DHCP data to routing information. treatment of public DHCP data to routing information.
4.4.2 Protecting Other Data in DHCP Options 4.4.2 Protecting Other Data in DHCP Options
Some DHCP options (e.g., relay agent options, RFC 3046 [9]) or option Some DHCP options (e.g., relay agent options, RFC 3046 [RFC3046]) or
families (site or vendor options) admit no analysis because the data option families (site or vendor options) admit no analysis because
carried by them may be of unknown sensitivity. Analysis of their the data carried by them may be of unknown sensitivity. Analysis of
confidentiality requirements must be done by their users. their confidentiality requirements must be done by their users.
Should some data require confidentiality, it may be possible to Should some data require confidentiality, it may be possible to
exploit the "public" data above to allow a two-step configuration exploit the "public" data above to allow a two-step configuration
process in which sufficient client configuration is first obtained by process in which sufficient client configuration is first obtained by
the normal DHCPDISCOVER/OFFER/REQUEST/ACK exchange, and private data the normal DHCPDISCOVER/OFFER/REQUEST/ACK exchange, and private data
subsequently transmitted over a secure communications channel (such subsequently transmitted over a secure communications channel (such
as IPsec) using DHCPINFORM. as IPsec) using DHCPINFORM.
5. IANA Considerations 5. IANA Considerations
skipping to change at page 14, line 11 skipping to change at page 10, line 15
6. Security Considerations 6. Security Considerations
This entire memo presents a threat analysis of the DHCPv4 protocol. This entire memo presents a threat analysis of the DHCPv4 protocol.
7. Acknowledgements 7. Acknowledgements
This document is the result of work undertaken the by DHCP working This document is the result of work undertaken the by DHCP working
group, beginning at 55th IETF meeting in Atlanta. The authors would group, beginning at 55th IETF meeting in Atlanta. The authors would
also like to acknowledge contributions from others not directly also like to acknowledge contributions from others not directly
involved in writing this memo, including John Beatty and Vipul Gupta involved in writing this memo, including John Beatty and Vipul Gupta
of Sun Microsystems, and Ralph Droms of cisco Systems. of Sun Microsystems, and Ralph Droms of Cisco Systems.
Normative References 8. Change Log
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541, This section summaries the changes made to this Internet-Draft as it
October 1993. has evolved.
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 8.1 01 Draft
March 1997.
[3] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", No significant changes were made:
RFC 3118, June 2001. o Updated author information.
o Converted to using xml2rfc to generate the draft.
o Removed unused references.
o Added the Change Log section.
[4] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Normative References
Extensions", RFC 2132, March 1997.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
Levels", BCP 14, RFC 2119, March 1997. September 1991.
[6] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", [RFC1541] Droms, R., "Dynamic Host Configuration Protocol", RFC
RFC 1771, March 1995. 1541, October 1993.
[7] Malkin, G., "RIP Version 2 Protocol Analysis", RFC 1721, [RFC1721] Malkin, G., "RIP Version 2 Protocol Analysis", RFC 1721,
November 1994. November 1994.
[8] Deering, S., "ICMP Router Discovery Messages", RFC 1256, [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
September 1991. (BGP-4)", RFC 1771, March 1995.
[9] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
January 2001. Requirement Levels", BCP 14, RFC 2119, March 1997.
Informative References [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[10] T'Joens, Y., Hublet, C. and P. De Schrijver, "DHCP reconfigure [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
extension", RFC 3203, December 2001. Extensions", RFC 2132, March 1997.
[11] Droms, R. and K. Kinnear, "DHCP Failover Protocol", [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
draft-ietf-dhc-failover-12 (work in progress), March 2003. 3046, January 2001.
[12] Rekhter, Y. and M. Stapp, "The DHCP Client FQDN Option", [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
draft-ietf-dhc-fqdn-option-05 (work in progress), November Messages", RFC 3118, June 2001.
2002.
[13] Droms, R., "Dynamic Host Configuration Protocol for IPv6 Informative References
(DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress),
November 2002.
[14] Woundy, R. and K. Kinnear, "DHCP Lease Query", [RFC3203] T'Joens, Y., Hublet, C. and P. De Schrijver, "DHCP
draft-ietf-dhc-leasequery-04 (work in progress), November 2002. reconfigure extension", RFC 3203, December 2001.
[15] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
System", draft-ietf-dnsext-dns-threats-02 (work in progress), M. Carney, "Dynamic Host Configuration Protocol for IPv6
November 2002. (DHCPv6)", RFC 3315, July 2003.
[16] Haller, N. and R. Atkinson, "On Internet Authentication", RFC [dns-threats]
1704, October 1994. Atkins, D. and R. Austein, "Threat Analysis Of The Domain
Name System", draft-ietf-dnsext-dns-threats-06 (work in
progress), February 2004.
[17] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on [failover]
Security Considerations", draft-iab-sec-cons-03 (work in Droms, R. and K. Kinnear, "DHCP Failover Protocol",
progress), February 2003. draft-ietf-dhc-failover-12 (work in progress), December
2003.
[18] Schnizlein, J., Polk, J. and M. Linsner, "DHC Location Object [fqdn] Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option",
within GEOPRIV", draft-ietf-geopriv-dhcp-lo-option-00 (work in draft-ietf-dhc-fqdn-option-06 (work in progress), October
progress), January 2003. 2003.
[19] Morris, R., "A Weakness in the 4.2 BSD UNIX TCP/IP Software", [leasequery]
CSTR 117, 1985. Woundy, R., "DHCP Lease Query",
draft-ietf-dhc-leasequery-07 (work in progress), March
2004.
Authors' Addresses Authors' Addresses
Richard Barr Hibbs Richard Barr Hibbs
Richard Barr Hibbs, P.E. Richard Barr Hibbs, P.E.
952 Sanchez Street 952 Sanchez Street
San Francisco, California 94114-3362 San Francisco, California 94114-3362
USA USA
Phone: +1 415 648 3920 Phone: +1 415 648 3920
skipping to change at page 17, line 16 skipping to change at page 12, line 4
Richard Barr Hibbs Richard Barr Hibbs
Richard Barr Hibbs, P.E. Richard Barr Hibbs, P.E.
952 Sanchez Street 952 Sanchez Street
San Francisco, California 94114-3362 San Francisco, California 94114-3362
USA USA
Phone: +1 415 648 3920 Phone: +1 415 648 3920
Fax: +1 415 648 9017 Fax: +1 415 648 9017
EMail: rbhibbs@pacbell.net EMail: rbhibbs@pacbell.net
Carl Smith Carl Smith
Sun Microsystems, Inc. Sun Microsystems, Inc.
901 San Antonio Road 901 San Antonio Road
Palo Alto, California 94303-4900 Palo Alto, California 94303-4900
USA USA
EMail: cs@eng.sun.com EMail: cs@eng.sun.com
Bernie Volz Bernard Volz
Ericsson Cisco Systems, Inc.
959 Concord Street 1414 Massachusetts Ave.
Framingham, Massachusetts 01701-4682 Boxborough, MA 01719
USA USA
Phone: +1 508 875 3162 Phone: +1 978 936 0382
EMail: Bernie.Volz@ericsson.com EMail: volz@cisco.com
Mimi Zohar Mimi Zohar
IBM T. J. Watson Research Center IBM T. J. Watson Research Center
19 Skyline Drive 19 Skyline Drive
Hawthorne, New York 10532-2134 Hawthorne, New York 10532-2134
USA USA
Phone: 1 914 784 7606 Phone: +1 914 784 7606
EMail: zohar@us.ibm.com EMail: zohar@us.ibm.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
skipping to change at page 18, line 27 skipping to change at page 13, line 27
obtain a general license or permission for the use of such obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at page 19, line 12 skipping to change at page 14, line 7
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/