draft-ietf-v6ops-tunnel-security-concerns-01.txt   draft-ietf-v6ops-tunnel-security-concerns-02.txt 
IPv6 Operations Working Group J. Hoagland IPv6 Operations Working Group J. Hoagland
Internet-Draft Symantec Internet-Draft Symantec
Intended status: Informational S. Krishnan Intended status: Informational S. Krishnan
Expires: April 17, 2009 Ericsson Expires: September 9, 2010 Ericsson
D. Thaler D. Thaler
Microsoft Microsoft
October 14, 2008 March 8, 2010
Security Concerns With IP Tunneling Security Concerns With IP Tunneling
draft-ietf-v6ops-tunnel-security-concerns-01 draft-ietf-v6ops-tunnel-security-concerns-02
Abstract
A number of security concerns with IP tunnels are documented in this
memo. The intended audience of this document includes network
administrators and future protocol developers. The primary intent of
this document is to raise the awareness regarding the security issues
with IP tunnels as deployed today.
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://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 April 17, 2009. This Internet-Draft will expire on September 9, 2010.
Abstract Copyright Notice
A number of security concerns with IP tunnels are documented in this Copyright (c) 2010 IETF Trust and the persons identified as the
document. The intended audience of this document includes network document authors. All rights reserved.
administrators and future protocol developers. The primary intent of
this document is to raise the awareness regarding the security issues This document is subject to BCP 78 and the IETF Trust's Legal
with IP tunnels as deployed today. Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Tunnels May Bypass Security . . . . . . . . . . . . . . . . . 3 2. Tunnels May Bypass Security . . . . . . . . . . . . . . . . . 3
2.1. Network Security Bypass . . . . . . . . . . . . . . . . . 3 2.1. Network Security Bypass . . . . . . . . . . . . . . . . . 3
2.2. IP Ingress and Egress Filtering Bypass . . . . . . . . . . 5 2.2. IP Ingress and Egress Filtering Bypass . . . . . . . . . . 5
2.3. Source Routing After the Tunnel Client . . . . . . . . . . 6 2.3. Source Routing After the Tunnel Client . . . . . . . . . . 6
3. Challenges in Inspecting and Filtering Content of Tunneled 3. Challenges in Inspecting and Filtering Content of Tunneled
Data Packets . . . . . . . . . . . . . . . . . . . . . . . . . 7 Data Packets . . . . . . . . . . . . . . . . . . . . . . . . . 7
skipping to change at page 2, line 27 skipping to change at page 3, line 27
packets . . . . . . . . . . . . . . . . . . . . . . . . . 8 packets . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Increased Exposure Due to Tunneling . . . . . . . . . . . . . 9 4. Increased Exposure Due to Tunneling . . . . . . . . . . . . . 9
4.1. NAT Holes Increase Attack Surface . . . . . . . . . . . . 9 4.1. NAT Holes Increase Attack Surface . . . . . . . . . . . . 9
4.2. Exposure of a NAT Hole . . . . . . . . . . . . . . . . . . 11 4.2. Exposure of a NAT Hole . . . . . . . . . . . . . . . . . . 11
4.3. Public Tunnels Widen Holes in Restricted NATs . . . . . . 12 4.3. Public Tunnels Widen Holes in Restricted NATs . . . . . . 12
5. Tunnel Address Concerns . . . . . . . . . . . . . . . . . . . 12 5. Tunnel Address Concerns . . . . . . . . . . . . . . . . . . . 12
5.1. Feasibility of Guessing Tunnel Addresses . . . . . . . . . 12 5.1. Feasibility of Guessing Tunnel Addresses . . . . . . . . . 12
5.2. Profiling Targets Based on Tunnel Address . . . . . . . . 13 5.2. Profiling Targets Based on Tunnel Address . . . . . . . . 13
6. Additional Security Concerns . . . . . . . . . . . . . . . . . 15 6. Additional Security Concerns . . . . . . . . . . . . . . . . . 15
6.1. Attacks Facilitated By Changing Tunnel Server Setting . . 15 6.1. Attacks Facilitated By Changing Tunnel Server Setting . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 7. Mechanisms to secure the use of tunnels . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. Informative References . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Informative References . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
With NAT devices becoming increasingly more prevalent, there have With NAT devices becoming increasingly more prevalent, there have
recently been many tunneling protocols developed that go through NAT recently been many tunneling protocols developed that go through NAT
devices or firewalls by tunneling over UDP or TCP. For example, devices or firewalls by tunneling over UDP or TCP. For example,
Teredo [RFC4380], L2TPv2 [RFC2661], and L2TPv3 [RFC3931] all tunnel Teredo [RFC4380], L2TPv2 [RFC2661], and L2TPv3 [RFC3931] all tunnel
IP packets over UDP. Similarly, many SSL VPN solutions that tunnel IP packets over UDP. Similarly, many SSL VPN solutions that tunnel
IP packets over HTTP (and hence over TCP) are deployed today. IP packets over HTTP (and hence over TCP) are deployed today.
skipping to change at page 6, line 26 skipping to change at page 7, line 26
Implementations of protocols that embed an IPv4 address in a Implementations of protocols that embed an IPv4 address in a
tunneled IPv6 address directly between peers often do filtering tunneled IPv6 address directly between peers often do filtering
based on checking the correspondence. based on checking the correspondence.
Implementations of protocols that accept tunneled packets directly Implementations of protocols that accept tunneled packets directly
from a server or relay do filtering the same way as it would be from a server or relay do filtering the same way as it would be
done on a native link with traffic from a router. done on a native link with traffic from a router.
Some protocols such as 6to4 [RFC3056], Teredo, ISATAP [RFC5214], Some protocols such as 6to4 [RFC3056], Teredo, ISATAP [RFC5214],
and 6over4 [RFC2529] allow both other hosts and a router over a and 6over4 [RFC2529] allow both other hosts and a router over a
common tunnel To perform host-based filtering with such protocols common tunnel. To perform host-based filtering with such
a host would need to know the outer IP address of each router from protocols a host would need to know the outer IP address of each
which it could receive traffic, so that packets from hosts beyond router from which it could receive traffic, so that packets from
the router will be accepted even though the source address would hosts beyond the router will be accepted even though the source
not embed the router's IP address. Router addresses might be address would not embed the router's IP address. Router addresses
learned via Secure Neighbor Discovery (SEND) [RFC3971] or some might be learned via Secure Neighbor Discovery (SEND) [RFC3971] or
other mechanism (e.g., [RFC5214] section 8.3.2). some other mechanism (e.g., [RFC5214] section 8.3.2).
2.3. Source Routing After the Tunnel Client 2.3. Source Routing After the Tunnel Client
2.3.1. Problem 2.3.1. Problem
If the encapsulated IP packet specifies source routing beyond the If the encapsulated IP packet specifies source routing beyond the
recipient tunnel client, the host may forward the IP packet to the recipient tunnel client, the host may forward the IP packet to the
specified next hop. This may be unexpected and contrary to specified next hop. This may be unexpected and contrary to
administrator wishes and may have bypassed network-based source administrator wishes and may have bypassed network-based source
routing controls. routing controls.
skipping to change at page 10, line 43 skipping to change at page 11, line 43
Thus, even if firewall filtering is in place (as is prudent) and Thus, even if firewall filtering is in place (as is prudent) and
filters all incoming packets, the exposed area is larger than if a filters all incoming packets, the exposed area is larger than if a
native IP Internet connection were in place, due to the processing native IP Internet connection were in place, due to the processing
that takes place before the inner IP is reached (specifically, the that takes place before the inner IP is reached (specifically, the
UDP/TCP processing, the tunnel client processing, and additional IP UDP/TCP processing, the tunnel client processing, and additional IP
processing, especially if one is IPv4 and the other is IPv6). processing, especially if one is IPv4 and the other is IPv6).
One possibility is that a layer 3 targeted worm makes use of a One possibility is that a layer 3 targeted worm makes use of a
vulnerability in the exposed processing. While the main benefit to vulnerability in the exposed processing. While the main benefit to
worms from tunneling is targeting at layer 3 reaching the end host, worms from tunneling is targeting at layer 3 reaching the end host,
even a throughly firewalled host could be subject to a worm that even a thoroughly firewalled host could be subject to a worm that
spreads with a single UDP packet if the right remote code spreads with a single UDP packet if the right remote code
vulnerability is present. vulnerability is present.
4.1.3. Recommendations 4.1.3. Recommendations
This problem seems inherent in tunneling being active on a host, so This problem seems inherent in tunneling being active on a host, so
the solution seems to be to minimize tunneling use. the solution seems to be to minimize tunneling use.
For example, it can be active only when it is really needed and only For example, it can be active only when it is really needed and only
for as long as needed. So, the tunnel interface can be initially not for as long as needed. So, the tunnel interface can be initially not
skipping to change at page 13, line 32 skipping to change at page 14, line 32
tunneling protocol or well-known tunnel server has the opportunity to tunneling protocol or well-known tunnel server has the opportunity to
infer certain relevant pieces of information that can be used to infer certain relevant pieces of information that can be used to
profile the host before sending any packets. This can reduce the profile the host before sending any packets. This can reduce the
attacker's footprint and increase the attacker's efficiency. attacker's footprint and increase the attacker's efficiency.
5.2.2. Discussion 5.2.2. Discussion
The tunnel address reveals some information about the nature of the The tunnel address reveals some information about the nature of the
client. client.
o That a host has a tunnel address associated with a given proocol o That a host has a tunnel address associated with a given protocol
means that the client is running on some platform for which there means that the client is running on some platform for which there
exists a tunnel client implementation of that protocol. In exists a tunnel client implementation of that protocol. In
addition, if some platforms have that protocol installed by addition, if some platforms have that protocol installed by
default and where the host's default rules for using it make it default and where the host's default rules for using it make it
susceptible to being in use, then it is more likely to be running susceptible to being in use, then it is more likely to be running
on such a platform than on one where it is not used by default. on such a platform than on one where it is not used by default.
For example, as of this writing, seeing a Teredo address suggests For example, as of this writing, seeing a Teredo address suggests
that the host it is on is running Windows Vista. that the host it is on is running Windows Vista.
o Similarly, the use of an address associated with a particular o Similarly, the use of an address associated with a particular
skipping to change at page 15, line 15 skipping to change at page 16, line 15
bit for Teredo should be deprecated. bit for Teredo should be deprecated.
6. Additional Security Concerns 6. Additional Security Concerns
6.1. Attacks Facilitated By Changing Tunnel Server Setting 6.1. Attacks Facilitated By Changing Tunnel Server Setting
6.1.1. Problem 6.1.1. Problem
If an attacker could either change a tunnel client's server setting If an attacker could either change a tunnel client's server setting
or change the IP addresses to which a configured host name resolves or change the IP addresses to which a configured host name resolves
(e.g., by intercepting DNS queries), this would allow them to become (e.g., by intercepting DNS queries), it would let them become a man
a man-in-the-middle at least monitor peer communication and at worst in the middle. This will allow them to at least monitor peer
pretend to represent the remote peer. communication and at worst pretend to represent the remote peer.
6.1.2. Discussion 6.1.2. Discussion
A client's server has good visibility into the client's communication A client's server has good visibility into the client's communication
with IP peers. If the server were switched to one that records this with IP peers. If the server were switched to one that records this
information and makes it available to third parties (e.g., information and makes it available to third parties (e.g.,
advertisers, competitors, spouses, etc.) then sensitive information advertisers, competitors, spouses, etc.) then sensitive information
is being disclosed, especially if the client's host prefers the is being disclosed, especially if the client's host prefers the
tunnel over native IP. Assuming the server provides good service, tunnel over native IP. Assuming the server provides good service,
the user would not have reason to suspect the change. the user would not have reason to suspect the change.
skipping to change at page 15, line 46 skipping to change at page 16, line 46
Teredo client's server setting and have the user be unaware their Teredo client's server setting and have the user be unaware their
trust has been misplaced for an indefinite period of time. However, trust has been misplaced for an indefinite period of time. However,
malware or a malicious user can do much worse than this, so this is malware or a malicious user can do much worse than this, so this is
not a significant concern. Hence it is only important that an not a significant concern. Hence it is only important that an
attacker on the network cannot change the client's server setting. attacker on the network cannot change the client's server setting.
1. A phisher sets up a malicious tunnel server (or tampers with a 1. A phisher sets up a malicious tunnel server (or tampers with a
legitimate one). This server, for the most part, provides legitimate one). This server, for the most part, provides
correct service. correct service.
2. An attacker by some means and switches the host's tunnel server 2. An attacker, by some means, switches the host's tunnel server
setting, or spoofs a DNS reply, to point to the above server. If setting, or spoofs a DNS reply, to point to the above server. If
neither DNS nor the tunnel setup is secured (i.e., if the client neither DNS nor the tunnel setup is secured (i.e., if the client
does not authenticate the information), then the attacker's does not authenticate the information), then the attacker's
tunnel server is seen as legitimate. tunnel server is seen as legitimate.
3. A user on the victim host types their bank's URL into his/her 3. A user on the victim host types their bank's URL into his/her
browser. browser.
4. The bank's hostname resolves to one or more IP addresses and the 4. The bank's hostname resolves to one or more IP addresses and the
tunnel is selected for socket connection for whatever reason tunnel is selected for socket connection for whatever reason
(e.g., the tunnel provides IPv6 connectivity and the bank has an (e.g., the tunnel provides IPv6 connectivity and the bank has an
IPv6 address). IPv6 address).
5. The tunnel client uses the server for help in connecting to the 5. The tunnel client uses the server for help in connecting to the
the bank's IP address. Some tunneling protocols use a separate bank's IP address. Some tunneling protocols use a separate
channel for signaling vs data, but this still allows the server channel for signaling vs data, but this still allows the server
to place itself in the data path by an appropriate signal to the to place itself in the data path by an appropriate signal to the
client. For example, in Teredo, the client sends a ping request client. For example, in Teredo, the client sends a ping request
through a server which is expected to come back through a data through a server which is expected to come back through a data
relay, and a malicious server can simply send it back itself to relay, and a malicious server can simply send it back itself to
indicate that is a data relay for the communication. indicate that is a data relay for the communication.
6. The rest works pretty much like any normal phishing transaction, 6. The rest works pretty much like any normal phishing transaction,
except that the attacker acts as a tunnel server (or data relay, except that the attacker acts as a tunnel server (or data relay,
for protocols such as Teredo) and a host with the bank's IP for protocols such as Teredo) and a host with the bank's IP
address. address.
This pharming type attack is not unique to tunneling. Switching DNS This pharming type attack is not unique to tunneling. Switching DNS
server settings to a malicious DNS server could have similar effect. server settings to a malicious DNS server or DNS cache poisoning in a
recursive DNS resolver could have a similar effect.
6.1.3. Recommendations 6.1.3. Recommendations
In general, anti-phishing and anti-fraud provisions should help with In general, anti-phishing and anti-fraud provisions should help with
aspects of this, as well as software that specifically monitors for aspects of this, as well as software that specifically monitors for
tunnel server changes. tunnel server changes.
Perhaps the best way to mitigate tunnel-specific attacks is to have Perhaps the best way to mitigate tunnel-specific attacks is to have
the client either authenticate the tunnel server, or at least the the client either authenticate the tunnel server, or at least the
means by which the tunnel server's IP address is determined. For means by which the tunnel server's IP address is determined. For
skipping to change at page 17, line 8 skipping to change at page 18, line 9
tunnel-specific settings such as the DNS server setting, etc.). tunnel-specific settings such as the DNS server setting, etc.).
Making it easy to see the current tunnel server setting (e.g., not Making it easy to see the current tunnel server setting (e.g., not
requiring privilege for this) should help detection of changes. requiring privilege for this) should help detection of changes.
The scope of the attack can also be reduced by limiting tunneling use The scope of the attack can also be reduced by limiting tunneling use
in general but especially in preferring native IPv4 to tunneled IPv6; in general but especially in preferring native IPv4 to tunneled IPv6;
this is because it is reasonable to expect that banks and similar web this is because it is reasonable to expect that banks and similar web
sites will continue to be accessible over IPv4 for as long as a sites will continue to be accessible over IPv4 for as long as a
significant fraction of their customers are still IPv4-only. significant fraction of their customers are still IPv4-only.
7. Acknowledgments 7. Mechanisms to secure the use of tunnels
This document described several security issues with tunnels. This
does not mean that tunnels need to be avoided at any cost. On the
contrary, tunnels can be very useful if deployed, operated and used
properly. The threats against IP tunnels are documented here. If
the threats can be mitigated, network administrators can efficiently
and securely use tunnels in their network. Several measures can be
taken in order to secure the operation of IPv6 tunnels.
o Operating on-premise tunnel servers/relays so that the tunneled
traffic does not cross border routers.
o Setting up internal routing to steer traffic to these servers/
relays
o Setting up of firewalls to allow known and controllable tunneling
mechanisms and disallow unknown tunnels.
8. Acknowledgments
The authors would like to thank Remi Denis-Courmont, Fred Templin, The authors would like to thank Remi Denis-Courmont, Fred Templin,
Jordi Palet Martinez, James Woodyatt, Christian Huitema and Kurt Jordi Palet Martinez, James Woodyatt, Christian Huitema, Brian
Zeilenga for reviewing earlier versions of the document and providing Carpenter, Nathan Ward and Kurt Zeilenga for reviewing earlier
comments to make this document better. The authors would also like versions of the document and providing comments to make this document
to thank Alfred Hines for a careful review of the document. better. The authors would also like to thank Alfred Hoenes for a
careful review of the document.
8. Security Considerations 9. Security Considerations
This entire document discusses security concerns with tunnels. This entire document discusses security concerns with tunnels.
9. IANA Considerations 10. IANA Considerations
There are no actions for IANA in this document. There are no actions for IANA in this document.
10. Informative References 11. Informative References
[I-D.ietf-tsvwg-port-randomization] [I-D.ietf-tsvwg-port-randomization]
Larsen, M. and F. Gont, "Port Randomization", Larsen, M. and F. Gont, "Transport Protocol Port
draft-ietf-tsvwg-port-randomization-02 (work in progress), Randomization Recommendations",
August 2008. draft-ietf-tsvwg-port-randomization-06 (work in progress),
February 2010.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, March 1999. Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
skipping to change at page 19, line 4 skipping to change at page 20, line 24
URI: http://symantec.com/ URI: http://symantec.com/
Suresh Krishnan Suresh Krishnan
Ericsson Ericsson
8400 Decarie Blvd. 8400 Decarie Blvd.
Town of Mount Royal, QC Town of Mount Royal, QC
Canada Canada
Phone: +1 514 345 7900 x42871 Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com Email: suresh.krishnan@ericsson.com
Dave Thaler Dave Thaler
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
Phone: +1 425 703 8835 Phone: +1 425 703 8835
Email: dthaler@microsoft.com Email: dthaler@microsoft.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 23 change blocks. 
46 lines changed or deleted 94 lines changed or added

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