draft-ietf-v6ops-teredo-security-concerns-01.txt   draft-ietf-v6ops-teredo-security-concerns-02.txt 
IPv6 Operations Working Group J. Hoagland IPv6 Operations Working Group J. Hoagland
Internet-Draft Symantec Internet-Draft Symantec
Expires: May 19, 2008 S. Krishnan Expires: August 28, 2008 S. Krishnan
Ericsson Ericsson
November 16, 2007 February 25, 2008
Teredo Security Concerns Teredo Security Concerns
draft-ietf-v6ops-teredo-security-concerns-01 draft-ietf-v6ops-teredo-security-concerns-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes 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. 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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 May 19, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
Additional security concerns with Teredo are documented, beyond what Additional security concerns with Teredo are documented, beyond what
is in RFC 4380. This is based on an independent analysis of Teredo's is in RFC 4380. This is based on an independent analysis of Teredo's
security implications. The primary intent of this document is to security implications. The primary intent of this document is to
raise the awareness regarding the security issues in Teredo as raise the awareness regarding the security issues in Teredo as
deployed today. deployed today.
Table of Contents Table of Contents
skipping to change at page 3, line 16 skipping to change at page 3, line 16
An independent analysis of Teredo's security implications was An independent analysis of Teredo's security implications was
conducted by Symantec[TEREDOSEC], based on the Teredo specification conducted by Symantec[TEREDOSEC], based on the Teredo specification
([RFC4380]). This analysis uncovered some security concerns ([RFC4380]). This analysis uncovered some security concerns
associated with Teredo which are not documented in the Teredo associated with Teredo which are not documented in the Teredo
specification. This document discloses these additional concerns and specification. This document discloses these additional concerns and
includes any recommendations where relevant. This Internet Draft is includes any recommendations where relevant. This Internet Draft is
also influenced to an extent by an examination of the Teredo also influenced to an extent by an examination of the Teredo
implementation on Microsoft Windows Vista [WVNASA]. implementation on Microsoft Windows Vista [WVNASA].
The primary intent of this document is to provide information so that The primary intent of this document is to provide information that
can be used in any updated Teredo specification. Secondarily, this can be used in any updated Teredo specification. Secondarily, this
document can help improve security in Teredo as deployed (including document can help improve security in Teredo as deployed (including
those that implement Teredo, security providers, and network security those that implement Teredo, security providers, and network security
administrators) become aware of any valid security concerns. administrators) become aware of any valid security concerns.
2. Teredo Bypasses Security 2. Teredo Bypasses Security
2.1. Teredo Bypasses Network Security 2.1. Teredo Bypasses Network Security
2.1.1. Problem 2.1.1. Problem
skipping to change at page 4, line 7 skipping to change at page 4, line 7
tested and released, and the customer begins using the update. Late tested and released, and the customer begins using the update. Late
changes in the protocol specification or in the way it is implemented changes in the protocol specification or in the way it is implemented
can cause additional delays. This becomes a significant security can cause additional delays. This becomes a significant security
concern when a delay in applied coverage is occurring frequently. concern when a delay in applied coverage is occurring frequently.
Specifically for Teredo, a Teredo-unaware network security device Specifically for Teredo, a Teredo-unaware network security device
would inspect or regulate the IPv4 and the IPv4-based UDP layer as would inspect or regulate the IPv4 and the IPv4-based UDP layer as
normal for IPv4, but it would not recognize that there is an normal for IPv4, but it would not recognize that there is an
additional IP layer contained inside the UDP payload that it needs to additional IP layer contained inside the UDP payload that it needs to
apply the same controls as it would to a native packet. (Of course, apply the same controls as it would to a native packet. (Of course,
if device discards the packet due to something in the IPv4 or UDP if the device discards the packet due to something in the IPv4 or UDP
header, such as referring to an unknown protocol, the Teredo packet header, such as referring to an unknown protocol, the Teredo packet
is no longer a concern.) Teredo also only recently reached RFC is no longer a concern.) Teredo also only recently reached RFC
status (February 2006), is widely applicable, requires no support status (February 2006), is widely applicable, requires no support
from the local or organizational network, and looks ready to be from the local or organizational network, and looks ready to be
widely used. Furthermore the tunnel created by the Teredo client is widely used. Furthermore the tunnel created by the Teredo client is
open-ended and allows bidirectional traffic. open-ended and allows bidirectional traffic.
Network security controls being not applied must be a concern to Network security controls being not applied must be a concern to
those that set them up, since those controls are supposed to those that set them up, since those controls are supposed to
adequately regulate all traffic. If network controls are being adequately regulate all traffic. If network controls are being
skipping to change at page 5, line 24 skipping to change at page 5, line 24
We specifically note that we could find no pre-existing mechanism for We specifically note that we could find no pre-existing mechanism for
Teredo to use that could automate its functionality being disabled Teredo to use that could automate its functionality being disabled
unless all network-based security controls were aware of it. A unless all network-based security controls were aware of it. A
separate type of consent request packet would be needed. (Such a separate type of consent request packet would be needed. (Such a
consent request service could have application beyond Teredo.) consent request service could have application beyond Teredo.)
2.2. IPv6 Ingress and Egress Filtering Bypass 2.2. IPv6 Ingress and Egress Filtering Bypass
2.2.1. Problem 2.2.1. Problem
IPv6 addresses inside Teredo tunnels are not subject ingress and IPv6 addresses inside Teredo tunnels are not subject to ingress and
egress filtering, unless extraordinary measures are taken. egress filtering, unless extraordinary measures are taken.
2.2.2. Discussion 2.2.2. Discussion
Ingress filtering (sanity-checking incoming destination addresses) Ingress filtering (sanity-checking incoming destination addresses)
and egress filtering (sanity-checking outgoing source addresses) are and egress filtering (sanity-checking outgoing source addresses) are
done to mitigate attacks and to make it easier to identify the source done to mitigate attacks and to make it easier to identify the source
of a packet and are considered to be a good practice. This is most of a packet and are considered to be a good practice. This is most
naturally (and in the general case, by requirement) done at network naturally (and in the general case, by requirement) done at network
boundaries. Teredo-tunneled IPv6 traffic bypassing this network boundaries. Teredo-tunneled IPv6 traffic bypassing this network
skipping to change at page 6, line 30 skipping to change at page 6, line 30
If the encapsulated IPv6 packet specifies source routing beyond the If the encapsulated IPv6 packet specifies source routing beyond the
recipient Teredo client, the host may forward the IPv6 packet to the recipient Teredo client, the host may forward the IPv6 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.
2.3.2. Discussion 2.3.2. Discussion
A detailed discussion of issues related to source routing can be A detailed discussion of issues related to source routing can be
found in [RH0] found in [RFC5095]
2.3.3. Recommendations 2.3.3. Recommendations
Teredo clients should by default discard tunneled IPv6 packets that Teredo clients should by default discard tunneled IPv6 packets that
specify additional routing, though they may also allow the user to specify additional routing, though they may also allow the user to
configure what source routing types are allowed. All pre-existing configure what source routing types are allowed. All pre-existing
source routing controls should be upgraded to apply these controls to source routing controls should be upgraded to apply these controls to
Teredo tunneled IPv6 packets as well. Teredo tunneled IPv6 packets as well.
3. Challenges in Inspecting and Filtering Content of Teredo Data 3. Challenges in Inspecting and Filtering Content of Teredo Data
skipping to change at page 7, line 27 skipping to change at page 7, line 27
be assured that a host trying to establish a new Teredo address will be assured that a host trying to establish a new Teredo address will
be prevented from using Teredo tunneling. However, existing Teredo be prevented from using Teredo tunneling. However, existing Teredo
clients will not be affected, at least not immediately. In addition, clients will not be affected, at least not immediately. In addition,
if the blocking is applied on the outside of client's NAT, the NAT if the blocking is applied on the outside of client's NAT, the NAT
will retain the port mapping for the client and the client may or may will retain the port mapping for the client and the client may or may
not continue to use its Teredo address. It is not known if blocking not continue to use its Teredo address. It is not known if blocking
all outbound port 3544 will interfere with non-Teredo traffic. all outbound port 3544 will interfere with non-Teredo traffic.
The other approach is to find all packets to block in the same way as The other approach is to find all packets to block in the same way as
would be done for inspecting all packets (Section 3.2). However, would be done for inspecting all packets (Section 3.2). However,
this faces the difficulties in terms of efficient as was present this faces the difficulties in terms of efficiency of filtering as
there. was present there.
3.1.3. Recommendations 3.1.3. Recommendations
Teredo is NOT RECOMMENDED as a solution for managed networks. Teredo is NOT RECOMMENDED as a solution for managed networks.
Administrators of such networks may wish to filter all Teredo traffic Administrators of such networks may wish to filter all Teredo traffic
at the boundaries of their networks. It is sufficient to filter out at the boundaries of their networks. It is sufficient to filter out
the Teredo connection requests to stop further Teredo traffic. The the Teredo connection requests to stop further Teredo traffic. The
easiest mechanism for this would be to filter out incoming traffic easiest mechanism for this would be to filter out incoming traffic
with source port 3544 and outgoing traffic with destination port with source port 3544 and outgoing traffic with destination port
3544. 3544.
skipping to change at page 8, line 9 skipping to change at page 8, line 9
3.2.2. Discussion 3.2.2. Discussion
The only well known port that Teredo traffic uses is UDP 3544 and RFC The only well known port that Teredo traffic uses is UDP 3544 and RFC
4380 only requires that to be used for the Teredo server service 4380 only requires that to be used for the Teredo server service
port. The client and relay components can use any port they wish. port. The client and relay components can use any port they wish.
The implication of this is that network-based devices that wish to The implication of this is that network-based devices that wish to
passively inspect (and perhaps selectively apply policy to) all passively inspect (and perhaps selectively apply policy to) all
encapsulated Teredo-based traffic must inspect all UDP packets (or at encapsulated Teredo-based traffic must inspect all UDP packets (or at
least all UDP packets not part of session that is known not to be least all UDP packets not part of a session that is known not to be
Teredo). This is inefficient (more so that say 6to4), especially Teredo). This is inefficient (more so that say 6to4), especially
considering that a heuristic must then be applied to determine if a considering that a heuristic must then be applied to determine if a
packet is indeed Teredo. This may be too slow to make use of in packet is indeed Teredo. This may be too slow to make use of in
practice, especially if it means that all UDP packets must be taken practice, especially if it means that all UDP packets must be taken
off of the device's "fast path". off of the device's "fast path".
One heuristic that can be used on UDP packets to determine if they One heuristic that can be used on UDP packets to determine if they
are Teredo-related or not is as follows: are Teredo-related or not is as follows:
1. The packet is not Teredo if it is not UDP over IPv4. 1. The packet is not Teredo if it is not UDP over IPv4.
skipping to change at page 8, line 46 skipping to change at page 8, line 46
origin encapsulation), T= T+8. origin encapsulation), T= T+8.
8. If E-T < 40, the packet is not Teredo. 8. If E-T < 40, the packet is not Teredo.
9. If the octets starting with T is 0x0000 or 0x0001, loop back to 9. If the octets starting with T is 0x0000 or 0x0001, loop back to
step 5. step 5.
10. If the most significant nibble of the octet at T is not 6, the 10. If the most significant nibble of the octet at T is not 6, the
packet is not Teredo. packet is not Teredo.
11. Assuming T is the start of an IPv6 header, set L to value of the 11. Assuming T is the start of an IPv6 header, set L to the value of
payload length field, S to the start of the source address, and the payload length field, S to the start of the source address,
D to the start of the destination address. and D to the start of the destination address.
12. If E-T != L+40, the packet is not Teredo. 12. If E-T != L+40, the packet is not Teredo.
13. If neither S nor D start with 0x20010000 (the Teredo prefix), 13. If neither S nor D start with 0x20010000 (the Teredo prefix),
the packet is not Teredo. the packet is not Teredo.
14. The packet is assumed to be Teredo, with the IPv6 header 14. The packet is assumed to be Teredo, with the IPv6 header
starting at T. starting at T.
This is similar to the packet reception checks in [RFC4380]. The This is similar to the packet reception checks in [RFC4380]. The
skipping to change at page 11, line 16 skipping to change at page 11, line 16
4.2. Unusually High Exposure of a NAT Hole 4.2. Unusually High Exposure of a NAT Hole
4.2.1. Problem 4.2.1. Problem
Attackers are more likely to know about a Teredo client's NAT hole Attackers are more likely to know about a Teredo client's NAT hole
than a typical hole in the NAT. If they know about the hole, they than a typical hole in the NAT. If they know about the hole, they
could try to use it. could try to use it.
4.2.2. Discussion 4.2.2. Discussion
There are at least three reasons whey an attacker is more likely to There are at least three reasons why an attacker is more likely to
learn of the Teredo client's exposed port than a typical NAT exposed learn of the Teredo client's exposed port than a typical NAT exposed
port: port:
1. The NAT mapping is typically held open longer and kept more 1. The NAT mapping is typically held open longer and kept more
stable than would otherwise be the case. This increases the stable than would otherwise be the case. This increases the
chance of it being discovered. chance of it being discovered.
2. The external IP address and port is contained in the client's 2. The external IP address and port is contained in the client's
Teredo address. While the Teredo protocol itself only Teredo address. While the Teredo protocol itself only
distributes this address on packets, peers and even network distributes this address on packets, peers and even network
skipping to change at page 14, line 17 skipping to change at page 14, line 17
5.2.3. Recommendations 5.2.3. Recommendations
If installation programs randomized the server setting, that would If installation programs randomized the server setting, that would
reduce the extent to which they can be profiled. Similarly, reduce the extent to which they can be profiled. Similarly,
administrators can chose to change the default setting to reduce the administrators can chose to change the default setting to reduce the
degree to which they can be profiled ahead of time. degree to which they can be profiled ahead of time.
Randomizing the Teredo client port in use would mitigate any Randomizing the Teredo client port in use would mitigate any
profiling that can be done based on the external port, especially if profiling that can be done based on the external port, especially if
multiple different Teredo clients did this. multiple different Teredo clients did this. Further discussion on
randomizing ports can be found at [PORTRAND].
A companion document [TEREDOUP] provides a possible solution for A companion document [TEREDOUP] provides a possible solution for
avoiding the disclosure of the network's security posture avoiding the disclosure of the network's security posture
6. Additional Security Concerns 6. Additional Security Concerns
6.1. Attacks Facilitated By Changing Teredo Server Setting 6.1. Attacks Facilitated By Changing Teredo Server Setting
6.1.1. Problem 6.1.1. Problem
skipping to change at page 15, line 25 skipping to change at page 15, line 25
host's Teredo server setting to reference the above server host's Teredo server setting to reference the above server
(either by IPv4 address or by hostname). (either by IPv4 address or by hostname).
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 both IPv6 and IPv4 addresses and 4. The bank's hostname resolves to both IPv6 and IPv4 addresses and
the IPv6 address is selected for the socket connection. the IPv6 address is selected for the socket connection.
(Alternately, it just resolves to IPv6.) (Alternately, it just resolves to IPv6.)
5. The host is behind an IPv4 NAT so no native IPv6 or ISTAP 5. The host is behind an IPv4 NAT so no native IPv6 or ISATAP
connection is possible, so the Teredo interface is used. connection is possible, so the Teredo interface is used.
6. The Teredo client uses the server for help in connecting to the 6. The Teredo client uses the server for help in connecting to the
the bank's IPv6 address. It asks the server to pass along an the bank's IPv6 address. It asks the server to pass along an
IPv6 ping so it can determine what Teredo relay to use in sending IPv6 ping so it can determine what Teredo relay to use in sending
packets to the bank's IPv6 address and so it knows what relay to packets to the bank's IPv6 address and so it knows what relay to
trust packets from for the peer. trust packets from for the peer.
7. The malicious server recognizes the IPv6 address as belonging to 7. The malicious server recognizes the IPv6 address as belonging to
a bank that it wants to phish against, so it sends an a bank that it wants to phish against, so it sends an
skipping to change at page 16, line 28 skipping to change at page 16, line 28
On the host, it should require an appropriate level of privilege in On the host, it should require an appropriate level of privilege in
order to change the Teredo server setting and we recommend that the order to change the Teredo server setting and we recommend that the
user be prompted when the Teredo server setting has been changed. user be prompted when the Teredo server setting has been changed.
Making it easy to see the current Teredo server setting (e.g., not Making it easy to see the current Teredo server setting (e.g., not
requiring privilege for this) should help detection of changes. requiring privilege for this) should help detection of changes.
6.2. RFC 4380 Implies That Teredo Improves Security 6.2. RFC 4380 Implies That Teredo Improves Security
6.2.1. Problem 6.2.1. Problem
The Security Considerations section of RFC 4380 states that it can The Security Considerations section of RFC 4380 states that it can be
argued that Teredo improves security. The above sections argue to argued that Teredo improves security. The above sections argue to
the contrary. This misleading or inaccurate claim can be taken out the contrary. This misleading or inaccurate claim can be taken out
of context and used to downplay Teredo security implications. of context and used to downplay Teredo security implications.
6.2.2. Discussion 6.2.2. Discussion
The "Security Considerations" section of [RFC4380] begins with: The "Security Considerations" section of [RFC4380] begins with:
"The main objective of Teredo is to provide nodes located behind a "The main objective of Teredo is to provide nodes located behind a
NAT with a globally routable IPv6 address. The Teredo nodes can NAT with a globally routable IPv6 address. The Teredo nodes can
skipping to change at page 17, line 8 skipping to change at page 17, line 8
a NAT and the security properties that it provides are a benefit in a NAT and the security properties that it provides are a benefit in
certain cases, specifically when the alternate session directly certain cases, specifically when the alternate session directly
involves NAT translation, IPsec is desired to be used, and involves NAT translation, IPsec is desired to be used, and
circumstances allow IPsec to be used. In this case the nice security circumstances allow IPsec to be used. In this case the nice security
properties IPsec can provide have been allowed by Teredo. However, properties IPsec can provide have been allowed by Teredo. However,
IPsec does not solve all security problems. IPsec does not solve all security problems.
It is hoped that by this point the reader will agree that Teredo It is hoped that by this point the reader will agree that Teredo
introduces security risk and does not improve security overall. introduces security risk and does not improve security overall.
Hence we feel the sentence that "the service has a positive effect on Hence we feel the sentence that "the service has a positive effect on
network security" goes to far in stating its point, even considering network security" goes too far in stating its point, even considering
the following sentence which may somewhat reduce the pointedness of the following sentence which may somewhat reduce the pointedness of
the claim. Someone may not recognize the full security impact of the claim. Someone may not recognize the full security impact of
Teredo after reading the sentence. Teredo after reading the sentence.
6.2.3. Recommendations 6.2.3. Recommendations
We recommend that no claims regarding a positive security impact from We recommend that no claims regarding a positive security impact from
Teredo be made, unless the scope of such a claim is immediately Teredo be made, unless the scope of such a claim is immediately
clear. We also recommend that the security concerns identified in clear. We also recommend that the security concerns identified in
this document be included in an updated Teredo standard document, this document be included in an updated Teredo standard document,
except to the extent that the Teredo protocol has been improved to except to the extent that the Teredo protocol has been improved to
mitigate them. mitigate them.
7. Acknowledgments 7. Acknowledgments
The authors would like to thank Remi Denis-Courmont, Dave Thaler, The authors would like to thank Remi Denis-Courmont, Dave Thaler,
Fred Templin, Jori Palet Martinez, James Woodyatt and Christian Fred Templin, Jordi Palet Martinez, James Woodyatt and Christian
Huitema for reviewing earlier versions of the document and providing Huitema for reviewing earlier versions of the document and providing
comments to make this document better. comments to make this document better. The authors would also like
to thank Alfred Hines for a carefully review of the document.
8. Security Considerations 8. Security Considerations
This document identified security concerns with Teredo that were not This document identified security concerns with Teredo that were not
included in RFC 4380. included in RFC 4380.
9. IANA Considerations 9. IANA Considerations
There are no IANA considerations from this document. There are no IANA considerations from this document.
skipping to change at page 18, line 20 skipping to change at page 18, line 21
[RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, [RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler,
"Intra-Site Automatic Tunnel Addressing Protocol "Intra-Site Automatic Tunnel Addressing Protocol
(ISATAP)", RFC 4214, October 2005. (ISATAP)", RFC 4214, October 2005.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, Network Address Translations (NATs)", RFC 4380,
February 2006. February 2006.
10.2. Informative References 10.2. Informative References
[RH0] Abley, J., "Deprecation of Type 0 Routing Headers in [PORTRAND]
IPv6", draft-ietf-ipv6-deprecate-rh0-01 (work in Larsen, M. and F. Gont, "Port Randomization",
progress), June 2007. draft-ietf-tsvwg-port-randomization-00 (work in progress),
December 2007.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095,
December 2007.
[TEREDOSEC] [TEREDOSEC]
Hoagland, J., "The Teredo Protocol: Tunneling Past Network Hoagland, J., "The Teredo Protocol: Tunneling Past Network
Security and Other Security Implications", November 2006, Security and Other Security Implications", November 2006,
<http://www.symantec.com/avcenter/reference/ <http://www.symantec.com/avcenter/reference/
Teredo_Security.pdf>. Teredo_Security.pdf>.
[TEREDOUP] [TEREDOUP]
Krishnan, S. and J. Hoagland, "Teredo Security Updates", Krishnan, S. and J. Hoagland, "Teredo Security Updates",
draft-krishnan-v6ops-teredo-update-00 (work in progress), draft-krishnan-v6ops-teredo-update-00 (work in progress),
skipping to change at page 20, line 7 skipping to change at page 20, line 7
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
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 21 change blocks. 
26 lines changed or deleted 33 lines changed or added

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