draft-ietf-v6ops-6to4-security-02.txt | draft-ietf-v6ops-6to4-security-03.txt | |||
---|---|---|---|---|
v6ops Working Group P. Savola | v6ops Working Group P. Savola | |||
Internet-Draft CSC/FUNET | Internet-Draft CSC/FUNET | |||
Expires: September 7, 2004 C. Patel | Expires: December 16, 2004 C. Patel | |||
All Play, No Work | All Play, No Work | |||
Mar 9, 2004 | June 17, 2004 | |||
Security Considerations for 6to4 | Security Considerations for 6to4 | |||
draft-ietf-v6ops-6to4-security-02.txt | draft-ietf-v6ops-6to4-security-03.txt | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, I certify that any applicable | By submitting this Internet-Draft, I certify that any applicable | |||
patent or other IPR claims of which I am aware have been disclosed, | patent or other IPR claims of which I am aware have been disclosed, | |||
and any of which I become aware will be disclosed, in accordance with | and any of which I become aware will be disclosed, in accordance with | |||
RFC 3667. | RFC 3668. | |||
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 | |||
groups may also distribute working documents as Internet-Drafts. | other groups may also distribute working documents as | |||
Internet-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 http:// | The list of current Internet-Drafts can be accessed at | |||
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 September 7, 2004. | This Internet-Draft will expire on December 16, 2004. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2004). All Rights Reserved. | Copyright (C) The Internet Society (2004). All Rights Reserved. | |||
Abstract | Abstract | |||
The IPv6 interim mechanism 6to4 (RFC3056) uses automatic | The IPv6 interim mechanism 6to4 (RFC3056) uses automatic | |||
IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The | IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The | |||
architecture includes 6to4 routers and 6to4 relay routers, which | architecture includes 6to4 routers and 6to4 relay routers, which | |||
accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from | accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from | |||
any node in the IPv4 internet. This characteristic enables a number | any node in the IPv4 internet. This characteristic enables a number | |||
of security threats, mainly Denial of Service. It also makes it | of security threats, mainly Denial of Service. It also makes it | |||
easier for nodes to spoof IPv6 addresses. This document discusses | easier for nodes to spoof IPv6 addresses. This document discusses | |||
these issues in more detail and suggests enhancements to alleviate | these issues in more detail and suggests enhancements to alleviate | |||
the problems. | the problems. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Different 6to4 Forwarding Scenarios . . . . . . . . . . . . 4 | 2. Different 6to4 Forwarding Scenarios . . . . . . . . . . . . . 5 | |||
2.1 From 6to4 to 6to4 . . . . . . . . . . . . . . . . . . 4 | 2.1 From 6to4 to 6to4 . . . . . . . . . . . . . . . . . . . . 5 | |||
2.2 From Native to 6to4 . . . . . . . . . . . . . . . . . 4 | 2.2 From Native to 6to4 . . . . . . . . . . . . . . . . . . . 5 | |||
2.3 From 6to4 to Native . . . . . . . . . . . . . . . . . 5 | 2.3 From 6to4 to Native . . . . . . . . . . . . . . . . . . . 6 | |||
2.4 Other Models . . . . . . . . . . . . . . . . . . . . . 5 | 2.4 Other Models . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
2.4.1 BGP Between 6to4 Routers and Relays . . . . . . 6 | 2.4.1 BGP Between 6to4 Routers and Relays . . . . . . . . . 7 | |||
2.4.2 6to4 as an Optimization Method . . . . . . . . . 6 | 2.4.2 6to4 as an Optimization Method . . . . . . . . . . . . 7 | |||
2.4.3 6to4 as Tunnel End-Point Addressing Mechanism . 6 | 2.4.3 6to4 as Tunnel End-Point Addressing Mechanism . . . . 7 | |||
3. Functionalities of 6to4 Network Components . . . . . . . . . 8 | 3. Functionalities of 6to4 Network Components . . . . . . . . . . 9 | |||
3.1 6to4 Routers . . . . . . . . . . . . . . . . . . . . . 8 | 3.1 6to4 Routers . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.2 6to4 Relay Routers . . . . . . . . . . . . . . . . . . 9 | 3.2 6to4 Relay Routers . . . . . . . . . . . . . . . . . . . . 10 | |||
4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . 10 | 4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
4.1 Attacks on 6to4 Networks . . . . . . . . . . . . . . . 11 | 4.1 Attacks on 6to4 Networks . . . . . . . . . . . . . . . . . 12 | |||
4.1.1 Attacks with ND Messages . . . . . . . . . . . . 12 | 4.1.1 Attacks with ND Messages . . . . . . . . . . . . . . . 13 | |||
4.1.2 Spoofing Traffic to 6to4 Nodes . . . . . . . . . 13 | 4.1.2 Spoofing Traffic to 6to4 Nodes . . . . . . . . . . . . 14 | |||
4.1.3 Reflecting Traffic to 6to4 Nodes . . . . . . . . 16 | 4.1.3 Reflecting Traffic to 6to4 Nodes . . . . . . . . . . . 17 | |||
4.1.4 Local IPv4 Broadcast Attack . . . . . . . . . . 17 | 4.1.4 Local IPv4 Broadcast Attack . . . . . . . . . . . . . 18 | |||
4.2 Attacks on Native IPv6 Internet . . . . . . . . . . . 19 | 4.2 Attacks on Native IPv6 Internet . . . . . . . . . . . . . 20 | |||
4.2.1 Attacks with ND Messages . . . . . . . . . . . . 19 | 4.2.1 Attacks with ND Messages . . . . . . . . . . . . . . . 20 | |||
4.2.2 Spoofing Traffic to Native IPv6 node . . . . . . 20 | 4.2.2 Spoofing Traffic to Native IPv6 node . . . . . . . . . 21 | |||
4.2.3 Reflecting Traffic to Native IPv6 nodes . . . . 21 | 4.2.3 Reflecting Traffic to Native IPv6 nodes . . . . . . . 22 | |||
4.2.4 Local IPv4 Broadcast Attack . . . . . . . . . . 23 | 4.2.4 Local IPv4 Broadcast Attack . . . . . . . . . . . . . 24 | |||
4.2.5 Theft of Service . . . . . . . . . . . . . . . . 23 | 4.2.5 Theft of Service . . . . . . . . . . . . . . . . . . . 24 | |||
4.2.6 Relay Operators Seen as Source of Abuse . . . . 25 | 4.2.6 Relay Operators Seen as Source of Abuse . . . . . . . 26 | |||
4.3 Attacks on IPv4 Internet . . . . . . . . . . . . . . . 26 | 4.3 Attacks on IPv4 Internet . . . . . . . . . . . . . . . . . 27 | |||
4.4 Summary of the Attacks . . . . . . . . . . . . . . . . 26 | 4.4 Summary of the Attacks . . . . . . . . . . . . . . . . . . 27 | |||
5. Implementing Proper Security Checks in 6to4 . . . . . . . . 28 | 5. Implementing Proper Security Checks in 6to4 . . . . . . . . . 29 | |||
5.1 Encapsulating IPv6 into IPv4 . . . . . . . . . . . . . 29 | 5.1 Encapsulating IPv6 into IPv4 . . . . . . . . . . . . . . . 30 | |||
5.2 Decapsulating IPv4 into IPv6 . . . . . . . . . . . . . 29 | 5.2 Decapsulating IPv4 into IPv6 . . . . . . . . . . . . . . . 30 | |||
5.3 IPv4 and IPv6 Sanity Checks . . . . . . . . . . . . . 30 | 5.3 IPv4 and IPv6 Sanity Checks . . . . . . . . . . . . . . . 31 | |||
5.3.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . 30 | 5.3.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
5.3.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . 31 | 5.3.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
5.3.3 Optional Ingress Filtering . . . . . . . . . . . 31 | 5.3.3 Optional Ingress Filtering . . . . . . . . . . . . . . 32 | |||
5.3.4 Notes About the Checks . . . . . . . . . . . . . 31 | 5.3.4 Notes About the Checks . . . . . . . . . . . . . . . . 32 | |||
6. Issues in 6to4 Implementation and Use . . . . . . . . . . . 32 | 6. Issues in 6to4 Implementation and Use . . . . . . . . . . . . 33 | |||
6.1 Implementation Considerations with Automatic Tunnels . 32 | 6.1 Implementation Considerations with Automatic Tunnels . . . 33 | |||
6.2 A Different Model for 6to4 Deployment . . . . . . . . 33 | 6.2 A Different Model for 6to4 Deployment . . . . . . . . . . 34 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . 34 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35 | |||
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 34 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 | |||
Normative References . . . . . . . . . . . . . . . . . . . . 35 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 | |||
Informative References . . . . . . . . . . . . . . . . . . . 35 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 36 | 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 36 | |||
A. Some Trivial Attack Scenarios Outlined . . . . . . . . . . . 37 | 10.2 Informative References . . . . . . . . . . . . . . . . . . . 36 | |||
B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 38 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37 | |||
Intellectual Property and Copyright Statements . . . . . . . 39 | A. Some Trivial Attack Scenarios Outlined . . . . . . . . . . . . 38 | |||
B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 39 | ||||
Intellectual Property and Copyright Statements . . . . . . . . 40 | ||||
1. Introduction | 1. Introduction | |||
The IPv6 interim mechanism "6to4" [1] specifies automatic | The IPv6 interim mechanism "6to4" [1] specifies automatic | |||
IPv6-over-IPv4 tunneling to interconnect isolated IPv6 clouds by | IPv6-over-IPv4 tunneling to interconnect isolated IPv6 clouds by | |||
embedding the tunnel IPv4 address in the IPv6 6to4 prefix. | embedding the tunnel IPv4 address in the IPv6 6to4 prefix. | |||
Two characteristics of the 6to4 mechanism introduce most of the | Two characteristics of the 6to4 mechanism introduce most of the | |||
security considerations: | security considerations: | |||
skipping to change at page 8, line 18 | skipping to change at page 9, line 18 | |||
destination, it will not go through the main office as the 6to4 | destination, it will not go through the main office as the 6to4 | |||
2002::/16 route overrides the default route. | 2002::/16 route overrides the default route. | |||
This approach may make addressing and routing slightly easier in some | This approach may make addressing and routing slightly easier in some | |||
circumstances. | circumstances. | |||
3. Functionalities of 6to4 Network Components | 3. Functionalities of 6to4 Network Components | |||
This section summarizes the main functionalities of the 6to4 network | This section summarizes the main functionalities of the 6to4 network | |||
components (6to4 routers, and 6to4 relays), and the security checks | components (6to4 routers, and 6to4 relays), and the security checks | |||
that must be done by them. The pseudo-code for the security checks is | that must be done by them. The pseudo-code for the security checks | |||
provided in Section 5. | is provided in Section 5. | |||
This section summarizes the main functions of the various components | This section summarizes the main functions of the various components | |||
that are part of a 6to4 network - 6to4 relay routers, and 6to4 | that are part of a 6to4 network - 6to4 relay routers, and 6to4 | |||
routers. Refer to Section 1.1 of RFC 3056 [1] for 6to4 related | routers. Refer to Section 1.1 of RFC 3056 [1] for 6to4 related | |||
definitions. | definitions. | |||
3.1 6to4 Routers | 3.1 6to4 Routers | |||
The 6to4 routers acts as the border router of a 6to4 domain. It does | The 6to4 routers acts as the border router of a 6to4 domain. It does | |||
not have a native, global IPv6 address except in certain special | not have a native, global IPv6 address except in certain special | |||
skipping to change at page 9, line 5 | skipping to change at page 10, line 5 | |||
o Tunnel packets sent to non-6to4 addresses, to the configured/ | o Tunnel packets sent to non-6to4 addresses, to the configured/ | |||
closest-by-anycast 6to4 relay router. | closest-by-anycast 6to4 relay router. | |||
o Decapsulate directly received IPv4 packets from foreign 6to4 | o Decapsulate directly received IPv4 packets from foreign 6to4 | |||
addresses. | addresses. | |||
o Decapsulate IPv4 packets received via the relay closest to the | o Decapsulate IPv4 packets received via the relay closest to the | |||
native IPv6 sources. Note, it is not easily distinguishable that | native IPv6 sources. Note, it is not easily distinguishable that | |||
the packet was really received from a 6to4 relay router, not from | the packet was really received from a 6to4 relay router, not from | |||
a spoofing third party.) | a spoofing third party. | |||
The 6to4 router should also perform security checks on traffic that | The 6to4 router should also perform security checks on traffic that | |||
it will receive from other 6to4 relays, or 6to4 routers, or from | it will receive from other 6to4 relays, or 6to4 routers, or from | |||
within the 6to4 site. These checks include: | within the 6to4 site. These checks include: | |||
o Disallow traffic that has private, broadcast or reserved IPv4 | o Disallow traffic that has private, broadcast or reserved IPv4 | |||
addresses in tunnels, or the matching 6to4 prefixes. | addresses in tunnels, or the matching 6to4 prefixes. | |||
o Disallow traffic from 6to4 routers where the IPv4 tunnel source | o Disallow traffic from 6to4 routers where the IPv4 tunnel source | |||
address does not match the 6to4 prefix. (Note that the | address does not match the 6to4 prefix. (Note that the | |||
skipping to change at page 10, line 36 | skipping to change at page 11, line 36 | |||
global address; in particular, e.g. link-local addresses, mapped | global address; in particular, e.g. link-local addresses, mapped | |||
addresses and such should not be used. | addresses and such should not be used. | |||
o Discard traffic received from 6to4 routers with the destination as | o Discard traffic received from 6to4 routers with the destination as | |||
a 6to4 prefix. | a 6to4 prefix. | |||
4. Threat Analysis | 4. Threat Analysis | |||
This section discusses attacks against the 6to4 network or attacks | This section discusses attacks against the 6to4 network or attacks | |||
that are caused by the 6to4 network. The threats are discussed in | that are caused by the 6to4 network. The threats are discussed in | |||
light of the 6to4 deployment models defined in the Section 2. | light of the 6to4 deployment models defined in Section 2. | |||
There are three general types of threats: | There are three general types of threats: | |||
1. Denial-of-Service (DoS) attacks, in which a malicious node | 1. Denial-of-Service (DoS) attacks, in which a malicious node | |||
prevents communication between the node under attack and other | prevents communication between the node under attack and other | |||
nodes. | nodes. | |||
2. Reflection Denial-of-Service (DoS) attacks, in which a malicious | 2. Reflection Denial-of-Service (DoS) attacks, in which a malicious | |||
node reflects the traffic off unsuspecting nodes to a particular | node reflects the traffic off unsuspecting nodes to a particular | |||
node (node under attack) with the intent of preventing | node (node under attack) with the intent of preventing | |||
skipping to change at page 14, line 24 | skipping to change at page 15, line 24 | |||
This attack is similar to ones shown in [10]. | This attack is similar to ones shown in [10]. | |||
EXTENSIONS | EXTENSIONS | |||
Replies to the traffic will be directed to the src_v6 address, | Replies to the traffic will be directed to the src_v6 address, | |||
resulting in 6to4 nodes in participating in a reflection DoS. This | resulting in 6to4 nodes in participating in a reflection DoS. This | |||
attack is described in more detail in Section 4.2.3. That is, the | attack is described in more detail in Section 4.2.3. That is, the | |||
replies (e.g., TCP SYN ACK, TCP RST, ICMPv6 Echo Reply, input sent to | replies (e.g., TCP SYN ACK, TCP RST, ICMPv6 Echo Reply, input sent to | |||
UDP echo service, ICMPv6 Destination Unreachable, etc.) are sent to | UDP echo service, ICMPv6 Destination Unreachable, etc.) are sent to | |||
the victim (src_v6), above. All the traces from the original attacker | the victim (src_v6), above. All the traces from the original | |||
(src_v4) have been discarded. These return packets will go through a | attacker (src_v4) have been discarded. These return packets will go | |||
relay. | through a relay. | |||
Certain 6to4 networks may have a trivial ACL (Access Control List) | Certain 6to4 networks may have a trivial ACL (Access Control List) | |||
based firewall that allows traffic to pass through if it comes from | based firewall that allows traffic to pass through if it comes from | |||
particular source(s). Such a firewalling mechanism can be bypassed by | particular source(s). Such a firewalling mechanism can be bypassed | |||
address spoofing. This attack can therefore be used for trivial ACL | by address spoofing. This attack can therefore be used for trivial | |||
avoidance as well. These attacks might be hampered by the fact that | ACL avoidance as well. These attacks might be hampered by the fact | |||
the replies from the 6to4 node to the spoofed address will be lost. | that the replies from the 6to4 node to the spoofed address will be | |||
lost. | ||||
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS | THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS | |||
The Denial-of-Service attack based on traffic spoofing is not new; | The Denial-of-Service attack based on traffic spoofing is not new; | |||
the only twists come from the fact that traces of an attack are more | the only twists come from the fact that traces of an attack are more | |||
easily lost, and that spoofing the IPv6 address is possible even to | easily lost, and that spoofing the IPv6 address is possible even to | |||
those who are unable to do so in their current networks. The 6to4 | those who are unable to do so in their current networks. The 6to4 | |||
router typically does not log IPv4 addresses (as they would be | router typically does not log IPv4 addresses (as they would be | |||
treated as L2 addresses) and thus the source of the attack (if | treated as L2 addresses) and thus the source of the attack (if | |||
launched from an IPv4 node) is lost. Since traces to the src_v4 | launched from an IPv4 node) is lost. Since traces to the src_v4 | |||
skipping to change at page 15, line 19 | skipping to change at page 16, line 21 | |||
there is no amplification factor. | there is no amplification factor. | |||
o Attack packets, if initiated from an IPv6 node, will pass through | o Attack packets, if initiated from an IPv6 node, will pass through | |||
choke point(s), namely a 6to4 relay; in addition to physical | choke point(s), namely a 6to4 relay; in addition to physical | |||
limitations, these could implement some form of 6to4-site-specific | limitations, these could implement some form of 6to4-site-specific | |||
traffic limiting. | traffic limiting. | |||
On the other hand, a variety of factors can make the attack serious: | On the other hand, a variety of factors can make the attack serious: | |||
o The attacker may have the ability to choose the relay, and he | o The attacker may have the ability to choose the relay, and he | |||
might employ the ones best suited for the attacks. Also, some | might employ the ones best suited for the attacks. Also, many | |||
relays use 192.88.99.1 [3] as the source address making tracing | relays use 192.88.99.1 [3] as the source address making tracing | |||
even more difficult. | even more difficult (also see Section 4.2.6). | |||
o The relay's IPv4 address may be used as a source address for these | o The relay's IPv4 address may be used as a source address for these | |||
attacks, potentially causing a lot of complaints or other actions | attacks, potentially causing a lot of complaints or other actions | |||
as the relay might seem to be the source of the attack (see | as the relay might seem to be the source of the attack (see | |||
Section 4.2.6 for more). | Section 4.2.6 for more). | |||
Some of the mitigation methods for such attacks are: | Some of the mitigation methods for such attacks are: | |||
1. Ingress filtering in the native IPv6 networks to prevent packets | 1. Ingress filtering in the native IPv6 networks to prevent packets | |||
with spoofed IPv6 source being transmitted. It would, thus, make | with spoofed IPv6 source being transmitted. It would, thus, make | |||
it easy to identify the source of the attack. | it easy to identify the source of the attack. | |||
2. Security checks in the 6to4 relay. The 6to4 relay must drop | 2. Security checks in the 6to4 relay. The 6to4 relay must drop | |||
traffic (from the IPv6 internet) that has 6to4 addresses as | traffic (from the IPv6 internet) that has 6to4 addresses as | |||
source address, see Section 5 for more. | source address, see Section 5 for more. | |||
However, these mitigation methods do not address the case of IPv4 | However, these mitigation methods do not address the case of IPv4 | |||
node sending encapsulated IPv6 packets. | node sending encapsulated IPv6 packets. | |||
There exists no simple way to prevent such attacks, and longer term | There exists no simple way to prevent such attacks, and longer term | |||
solutions like ingress filtering [11] or itrace [12] have to be | solutions like ingress filtering [11] or itrace [12] would have to be | |||
deployed in both IPv6 and IPv4 networks to help identify the source | deployed in both IPv6 and IPv4 networks to help identify the source | |||
of the attacks. | of the attacks. (Note that itrace work has been discontinued, as of | |||
this writing.) | ||||
COMPARISON TO SITUATION WITHOUT 6to4 | COMPARISON TO SITUATION WITHOUT 6to4 | |||
Traffic spoofing is not a new phenomenon in IPv4 or IPv6. 6to4 just | Traffic spoofing is not a new phenomenon in IPv4 or IPv6. 6to4 just | |||
makes it easier: anyone can, regardless of ingress filtering, spoof a | makes it easier: anyone can, regardless of ingress filtering, spoof a | |||
native IPv6 address to a 6to4 node, even if "maximal security" would | native IPv6 address to a 6to4 node, even if "maximal security" would | |||
be implemented and deployed. Losing trails is also easier. | be implemented and deployed. Losing trails is also easier. | |||
Therefore, depending on how much one assumes ingress filtering is | Therefore, depending on how much one assumes ingress filtering is | |||
deployed for IPv4 and IPv6, this could be considered to be a very | deployed for IPv4 and IPv6, this could be considered to be a very | |||
serious issue, or close to irrelevant compared to the IP spoofing | serious issue, or close to irrelevant compared to the IP spoofing | |||
capabilities without 6to4. | capabilities without 6to4. | |||
4.1.3 Reflecting Traffic to 6to4 Nodes | 4.1.3 Reflecting Traffic to 6to4 Nodes | |||
ATTACK DESCRIPTION | ATTACK DESCRIPTION | |||
Spoofed traffic (as described in the Section 4.2.2) may be sent to | Spoofed traffic (as described in Section 4.2.2) may be sent to native | |||
native IPv6 nodes with the aim of performing a reflection attack | IPv6 nodes with the aim of performing a reflection attack against | |||
against 6to4 nodes. | 6to4 nodes. | |||
The spoofed traffic is sent to a native IPv6 node, either from an | The spoofed traffic is sent to a native IPv6 node, either from an | |||
IPv4 node (through a 6to4 relay), or from a native IPv6 node (unless | IPv4 node (through a 6to4 relay), or from a native IPv6 node (unless | |||
ingress filtering has been deployed). With the former, the sent | ingress filtering has been deployed). With the former, the sent | |||
packets would look like: | packets would look like: | |||
src_v6 = 2002:1234:1234::1 (forged address of the target 6to4 node) | src_v6 = 2002:1234:1234::1 (forged address of the target 6to4 node) | |||
dst_v6 = 2002:0900:0002::1 (valid address) | dst_v6 = 2002:0900:0002::1 (valid address) | |||
src_v4 = 8.0.0.1 (valid or invalid address) | src_v4 = 8.0.0.1 (valid or invalid address) | |||
dst_v4 = 9.0.0.2 (valid address, matches dst_v6) | dst_v4 = 9.0.0.2 (valid address, matches dst_v6) | |||
skipping to change at page 18, line 25 | skipping to change at page 19, line 27 | |||
broadcast address. After receiving the packet with a destionation | broadcast address. After receiving the packet with a destionation | |||
address like "2002:0900:00ff::bbbb" from a local 6to4 node, if the | address like "2002:0900:00ff::bbbb" from a local 6to4 node, if the | |||
router doesn't check the destination address for subnet broadcast, it | router doesn't check the destination address for subnet broadcast, it | |||
would send the encapsulated protocol-41 packet to 9.0.0.255. This | would send the encapsulated protocol-41 packet to 9.0.0.255. This | |||
would be received by all nodes in the subnet, and the responses would | would be received by all nodes in the subnet, and the responses would | |||
be directed to the 6to4 router. | be directed to the 6to4 router. | |||
Malicious sites may also embed forged 6to4 addresses in the DNS, use | Malicious sites may also embed forged 6to4 addresses in the DNS, use | |||
of which by a 6to4 node will result in a local broadcast by the 6to4 | of which by a 6to4 node will result in a local broadcast by the 6to4 | |||
router. One way to perform this attack would be to send an HTML mail | router. One way to perform this attack would be to send an HTML mail | |||
containing a link to an invalid URL (for example, http:// | containing a link to an invalid URL (for example, | |||
[2002:0900:00ff::bbbb]/index.html) to all users in a 6to4 technology | http://[2002:0900:00ff::bbbb]/index.html) to all users in a 6to4 | |||
based network. Opening of the mail simultaneously would result in a | technology based network. Opening of the mail simultaneously would | |||
broadcast storm. | result in a broadcast storm. | |||
The second kind of attack is more complex: the attack can be | The second kind of attack is more complex: the attack can be | |||
initiated by IPv4 nodes not belonging to the local network as long as | initiated by IPv4 nodes not belonging to the local network as long as | |||
they can send traffic with invalid (for example 2002:0900:00ff::bbbb) | they can send traffic with invalid (for example 2002:0900:00ff::bbbb) | |||
source address. The 6to4 router has to respond to the traffic by | source address. The 6to4 router has to respond to the traffic by | |||
sending ICMPv6 packets back to the source, for example Hop Limit | sending ICMPv6 packets back to the source, for example Hop Limit | |||
Exceeded or Destination Unreachable. The packet would be as follows: | Exceeded or Destination Unreachable. The packet would be as follows: | |||
src_v6 = 2002:0800:00ff::bbbb (broadcast address of the router) | src_v6 = 2002:0800:00ff::bbbb (broadcast address of the router) | |||
dst_v6 = 2002:0800:0001::0001 (valid non-existent address) | dst_v6 = 2002:0800:0001::0001 (valid non-existent address) | |||
skipping to change at page 20, line 17 | skipping to change at page 21, line 17 | |||
ATTACK DESCRIPTION | ATTACK DESCRIPTION | |||
The attacker - a malicious IPv4 or 6to4 node - can send packets with | The attacker - a malicious IPv4 or 6to4 node - can send packets with | |||
spoofed (or not spoofed) 6to4 source address to a native IPv6 node to | spoofed (or not spoofed) 6to4 source address to a native IPv6 node to | |||
accomplish a DoS attack. | accomplish a DoS attack. | |||
The threat is similar as the one involving 6to4 routers as described | The threat is similar as the one involving 6to4 routers as described | |||
in Section 4.1.2. | in Section 4.1.2. | |||
The difference here is that the attack is initiated by IPv4 nodes, or | The difference here is that the attack is initiated by IPv4 nodes, or | |||
6to4 nodes. The source IPv6 address may or may not be spoofed. Note, | 6to4 nodes. The source IPv6 address may or may not be spoofed. | |||
as mentioned above, the relay is assumed to correlate source IPv4 | Note, as mentioned above, the relay is assumed to correlate source | |||
address with the address embedded in the source IPv6 address during | IPv4 address with the address embedded in the source IPv6 address | |||
decapsulation. A side effect is that all the spoofed traffic will | during decapsulation. A side effect is that all the spoofed traffic | |||
have a 6to4 source address. | will have a 6to4 source address. | |||
EXTENSIONS | EXTENSIONS | |||
Spoofed traffic may also be sent to native IPv6 nodes by either other | Spoofed traffic may also be sent to native IPv6 nodes by either other | |||
native IPv6 nodes, or 6to4 nodes, or malicious IPv4 nodes to conduct | native IPv6 nodes, or 6to4 nodes, or malicious IPv4 nodes to conduct | |||
Reflection DoS on either native IPv6 nodes or 6to4 nodes. | Reflection DoS on either native IPv6 nodes or 6to4 nodes. | |||
Certain native IPv6 networks may have a trivial ACL (Access Control | Certain native IPv6 networks may have a trivial ACL (Access Control | |||
List) based firewall that allows traffic to pass through if it comes | List) based firewall that allows traffic to pass through if it comes | |||
from particular source(s). Such a firewalling mechanism can be | from particular source(s). Such a firewalling mechanism can be | |||
bypassed by address spoofing. This attack can therefore be used for | bypassed by address spoofing. This attack can therefore be used for | |||
trivial ACL avoidance as well. These attacks might be hampered by the | trivial ACL avoidance as well. These attacks might be hampered by | |||
fact that the replies from the 6to4 node to the spoofed address will | the fact that the replies from the 6to4 node to the spoofed address | |||
be lost. | will be lost. | |||
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS | THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS | |||
The Denial-of-Service attack based on traffic spoofing is not new; | The Denial-of-Service attack based on traffic spoofing is not new; | |||
the only twist comes from the fact that traces of an attack are more | the only twist comes from the fact that traces of an attack are more | |||
easily lost. The 6to4 relay typically does not log IPv4 addresses | easily lost. The 6to4 relay typically does not log IPv4 addresses | |||
(as they would be treated as L2 addresses) and thus the source of the | (as they would be treated as L2 addresses) and thus the source of the | |||
attack (if launched from an IPv4 node) is lost. Since traces to the | attack (if launched from an IPv4 node) is lost. Since traces to the | |||
src_v4 address can easily be lost, these attacks can also be be | src_v4 address can easily be lost, these attacks can also be be | |||
launched from IPv4 nodes whose connection is ingress-filtered. | launched from IPv4 nodes whose connection is ingress-filtered. | |||
skipping to change at page 26, line 35 | skipping to change at page 27, line 35 | |||
Attacks initiated by IPv4 nodes that send spoofed traffic that will | Attacks initiated by IPv4 nodes that send spoofed traffic that will | |||
not utilize the 6to4 infrastructure are considered out of scope of | not utilize the 6to4 infrastructure are considered out of scope of | |||
this document. 6to4 infrastructure may be utilized in reflection | this document. 6to4 infrastructure may be utilized in reflection | |||
attacks that are initiated by IPv4 nodes. | attacks that are initiated by IPv4 nodes. | |||
It is difficult for these attacks to be effective as the traffic sent | It is difficult for these attacks to be effective as the traffic sent | |||
out will be IPv6-in-IPv4. Such traffic will be rejected by most IPv4 | out will be IPv6-in-IPv4. Such traffic will be rejected by most IPv4 | |||
nodes unless they have implemented some sort of IPv6-in-IPv4 | nodes unless they have implemented some sort of IPv6-in-IPv4 | |||
tunneling. | tunneling. | |||
XXX: do these need to be spelled out, as in previous sections? | ||||
4.4 Summary of the Attacks | 4.4 Summary of the Attacks | |||
Columns: | Columns: | |||
o Section number. The section that describes the attack. | o Section number. The section that describes the attack. | |||
o Attack name. | o Attack name. | |||
o Initiator. The node that initiates the attack. | o Initiator. The node that initiates the attack. | |||
* I_4 - IPv4 node | * I_4 - IPv4 node | |||
* I_6 - native IPv6 node | * I_6 - native IPv6 node | |||
* 6to4 - 6to4 node | * 6to4 - 6to4 node | |||
* * - All of the above | ||||
* * - All of the above | ||||
o Victim. The victim node | o Victim. The victim node | |||
* I_4 - IPv4 node | * I_4 - IPv4 node | |||
* I_6 - native IPv6 node | * I_6 - native IPv6 node | |||
* 6to4 - 6to4 node | * 6to4 - 6to4 node | |||
* Relay - 6to4 relay | * Relay - 6to4 relay | |||
skipping to change at page 29, line 24 | skipping to change at page 30, line 24 | |||
The checks described in this section are to be performed when | The checks described in this section are to be performed when | |||
encapsulating IPv6 into IPv4. | encapsulating IPv6 into IPv4. | |||
The encapsulation rules are mainly designed to keep one from | The encapsulation rules are mainly designed to keep one from | |||
"shooting yourself on the foot" -- for example, the source address | "shooting yourself on the foot" -- for example, the source address | |||
check verifies that the packet will be acceptable to the | check verifies that the packet will be acceptable to the | |||
decapsulator, or the sanity checks ensure that addresses derived from | decapsulator, or the sanity checks ensure that addresses derived from | |||
private addresses are not used (which would be equally unacceptable). | private addresses are not used (which would be equally unacceptable). | |||
src_v6 and dst_v6 MUST pass ipv6-sanity checks (see below), else drop | src_v6 and dst_v6 MUST pass ipv6-sanity checks (see below) else drop | |||
if prefix (src_v6) == 2002::/16 | if prefix (src_v6) == 2002::/16 | |||
ipv4 address embedded in src_v6 MUST match src_v4 | ipv4 address embedded in src_v6 MUST match src_v4 | |||
else if prefix (dst_v6) == 2002::/16 | else if prefix (dst_v6) == 2002::/16 | |||
dst_v4 SHOULD NOT be assigned to the router | dst_v4 SHOULD NOT be assigned to the router | |||
else | else | |||
drop | drop | |||
/* we somehow got a native-native ipv6 packet */ | /* we somehow got a native-native ipv6 packet */ | |||
fi | fi | |||
accept | accept | |||
skipping to change at page 32, line 26 | skipping to change at page 33, line 26 | |||
implementations are faced with, and the kind of generic problems the | implementations are faced with, and the kind of generic problems the | |||
6to4 users could come up with. | 6to4 users could come up with. | |||
6.1 Implementation Considerations with Automatic Tunnels | 6.1 Implementation Considerations with Automatic Tunnels | |||
There is a problem with multiple transition mechanisms if strict | There is a problem with multiple transition mechanisms if strict | |||
security checks are implemented. This may vary a bit from | security checks are implemented. This may vary a bit from | |||
implementation to implementation. | implementation to implementation. | |||
Consider three mechanisms using automatic tunneling: 6to4, ISATAP | Consider three mechanisms using automatic tunneling: 6to4, ISATAP | |||
[14] and Automatic Tunneling using Compatible Addresses [4]. All of | [14] and Automatic Tunneling using Compatible Addresses [4] | |||
these use IP-IP (protocol 41) [15] IPv4 encapsulation with, more or | (currently removed [9] but typically still supported). All of these | |||
less, a pseudo-interface. | use IP-IP (protocol 41) [15] IPv4 encapsulation with, more or less, a | |||
pseudo-interface. | ||||
When a router, which has any two of these enabled, receives an IPv4 | When a router, which has any two of these enabled, receives an IPv4 | |||
encapsulated IPv6 packet: | encapsulated IPv6 packet: | |||
src_v6 = 2001:db8::1 | src_v6 = 2001:db8::1 | |||
dst_v6 = 2002:1010:1010::2 | dst_v6 = 2002:1010:1010::2 | |||
src_v4 = 10.0.0.1 | src_v4 = 10.0.0.1 | |||
dst_v4 = 20.20.20.20 | dst_v4 = 20.20.20.20 | |||
What can it do? How should it decide which transition mechanism this | What can it do? How should it decide which transition mechanism this | |||
skipping to change at page 33, line 25 | skipping to change at page 34, line 27 | |||
sources via 6to4 relays. 6to4 routers have no way of matching IPv4 | sources via 6to4 relays. 6to4 routers have no way of matching IPv4 | |||
source address of the relay with non-6to4 IPv6 address of the source. | source address of the relay with non-6to4 IPv6 address of the source. | |||
Consequently, anyone can spoof any non-6to4 IPv6 address he wants by | Consequently, anyone can spoof any non-6to4 IPv6 address he wants by | |||
sending traffic, encapsulated, directly to 6to4 routers. | sending traffic, encapsulated, directly to 6to4 routers. | |||
It could be possible to turn the deployment assumptions of 6to4 | It could be possible to turn the deployment assumptions of 6to4 | |||
around a bit to eliminate some threats caused by untrusted 6to4 | around a bit to eliminate some threats caused by untrusted 6to4 | |||
relays. That is: | relays. That is: | |||
o Every dual-stack site (or even ISP) would be required to have | o Every dual-stack site (or even ISP) would be required to have | |||
their own 6to4 relay. (This assumes that IPv6-only is so long away | their own 6to4 relay. (This assumes that IPv6-only is so long | |||
that 6to4 would be hopefully retired at that point.) That is, | away that 6to4 would be hopefully retired at that point.) That | |||
there would not be third-party relays, and the 2002::/16 route | is, there would not be third-party relays, and 2002::/16 and | |||
would not need to be advertised globally, and | 192.88.99.0/24 routes would not need to be advertised globally, | |||
and | ||||
o The security implications of 6to4 use could be pushed back to the | o The security implications of 6to4 use could be pushed back to the | |||
level of trust inside the site or ISP (or their acceptable use | level of trust inside the site or ISP (or their acceptable use | |||
policies) -- this is something that the sites and ISP's should be | policies) -- this is something that the sites and ISP's should be | |||
familiar with already. | familiar with already. | |||
However, this has a number of problems: | However, this has a number of problems: | |||
This model would shift the majority of burden of supporting 6to4 to | This model would shift the majority of burden of supporting 6to4 to | |||
IPv6 sites which don't employ or use 6to4 at all, i.e., "those who | IPv6 sites which don't employ or use 6to4 at all, i.e., "those who | |||
skipping to change at page 34, line 37 | skipping to change at page 35, line 37 | |||
The first is the toughest problem, still under research. The second | The first is the toughest problem, still under research. The second | |||
can be fixed by ensuring the correctness of implementations; this is | can be fixed by ensuring the correctness of implementations; this is | |||
important. The third is also a very difficult problem, and | important. The third is also a very difficult problem, and | |||
impossible to solve completely -- therefore it is important to be | impossible to solve completely -- therefore it is important to be | |||
able to analyze whether this results in a significant increase of | able to analyze whether this results in a significant increase of | |||
threats. The fourth problem seems to have feasible solutions. | threats. The fourth problem seems to have feasible solutions. | |||
These are analyzed in detail in Threat Analysis, in Section 4. | These are analyzed in detail in Threat Analysis, in Section 4. | |||
8. Acknowledgments | 8. IANA Considerations | |||
This memo makes no requet to IANA. (RFC-editor note: please remove | ||||
this section on publication.) | ||||
9. Acknowledgments | ||||
Some issues were first brought up by Itojun Hagino in [16], and Alain | Some issues were first brought up by Itojun Hagino in [16], and Alain | |||
Durand introduced one specific problem at IETF51 in August 2001 | Durand introduced one specific problem at IETF51 in August 2001 | |||
(though there was some discussion on the list prior to that); these | (though there was some discussion on the list prior to that); these | |||
gave the author the push to start looking into the details of | gave the author the push to start looking into the details of | |||
securing 6to4. | securing 6to4. | |||
Alexey Kuznetsov brought up the implementation problem with IPv6 | Alexey Kuznetsov brought up the implementation problem with IPv6 | |||
martian checks. Christian Huitema formulated the rules that rely on | martian checks. Christian Huitema formulated the rules that rely on | |||
6to4 relays using only anycast. Keith Moore brought up the point | 6to4 relays using only anycast. Keith Moore brought up the point | |||
skipping to change at page 35, line 11 | skipping to change at page 36, line 16 | |||
reminded of relay spoofing problems. Brian Carpenter reminded of the | reminded of relay spoofing problems. Brian Carpenter reminded of the | |||
BGP-based 6to4 router model. Christian Huitema gave a push to a more | BGP-based 6to4 router model. Christian Huitema gave a push to a more | |||
complete threat analysis. Itojun Hagino spelled out the operators' | complete threat analysis. Itojun Hagino spelled out the operators' | |||
fears about 6to4 relay abuse. Rob Austein brought up the idea of a | fears about 6to4 relay abuse. Rob Austein brought up the idea of a | |||
different 6to4 deployment model. | different 6to4 deployment model. | |||
In the latter phase, especially discussions with Christian Huitema, | In the latter phase, especially discussions with Christian Huitema, | |||
Brian Carpenter and Alain Durand were helpful when improving the | Brian Carpenter and Alain Durand were helpful when improving the | |||
document. | document. | |||
David Malone and Iljitsch van Beijnum gave feedback on the document. | David Malone, Iljitsch van Beijnum, and Tim Chown gave feedback on | |||
the document. | ||||
Normative References | 10. References | |||
10.1 Normative References | ||||
[1] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 | [1] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 | |||
Clouds", RFC 3056, February 2001. | Clouds", RFC 3056, February 2001. | |||
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement | [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement | |||
Levels", BCP 14, RFC 2119, March 1997. | Levels", BCP 14, RFC 2119, March 1997. | |||
[3] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC | [3] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC | |||
3068, June 2001. | 3068, June 2001. | |||
Informative References | 10.2 Informative References | |||
[4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 | [4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 | |||
Hosts and Routers", RFC 2893, August 2000. | Hosts and Routers", RFC 2893, August 2000. | |||
[5] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", | [5] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", | |||
RFC 1771, March 1995. | RFC 1771, March 1995. | |||
[6] Draves, R., "Default Address Selection for Internet Protocol | [6] Draves, R., "Default Address Selection for Internet Protocol | |||
version 6 (IPv6)", RFC 3484, February 2003. | version 6 (IPv6)", RFC 3484, February 2003. | |||
[7] Nikander, P., "IPv6 Neighbor Discovery trust models and | [7] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor | |||
threats", draft-ietf-send-psreq-04 (work in progress), October | Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. | |||
2003. | ||||
[8] Arkko, J., "SEcure Neighbor Discovery (SEND)", | [8] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, | |||
draft-ietf-send-ndopt-04 (work in progress), February 2004. | "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05 | |||
(work in progress), April 2004. | ||||
[9] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for | [9] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for | |||
IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-02 (work in | IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-03 (work in | |||
progress), February 2004. | progress), June 2004. | |||
[10] Savola, P., "Security of IPv6 Routing Header and Home Address | [10] Savola, P., "Security of IPv6 Routing Header and Home Address | |||
Options", draft-savola-ipv6-rh-ha-security-02 (work in | Options", draft-savola-ipv6-rh-ha-security-02 (work in | |||
progress), March 2002. | progress), March 2002. | |||
[11] Ferguson, P. and D. Senie, "Network Ingress Filtering: | [11] Ferguson, P. and D. Senie, "Network Ingress Filtering: | |||
Defeating Denial of Service Attacks which employ IP Source | Defeating Denial of Service Attacks which employ IP Source | |||
Address Spoofing", BCP 38, RFC 2827, May 2000. | Address Spoofing", BCP 38, RFC 2827, May 2000. | |||
[12] Bellovin, S., Leech, M. and T. Taylor, "ICMP Traceback | [12] Bellovin, S., Leech, M. and T. Taylor, "ICMP Traceback | |||
Messages", draft-ietf-itrace-04 (work in progress), February | Messages", draft-ietf-itrace-04 (work in progress), February | |||
2003. | 2003. | |||
[13] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, | [13] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, | |||
June 1995. | June 1995. | |||
[14] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site | [14] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site | |||
Automatic Tunnel Addressing Protocol (ISATAP)", | Automatic Tunnel Addressing Protocol (ISATAP)", | |||
draft-ietf-ngtrans-isatap-20 (work in progress), February 2004. | draft-ietf-ngtrans-isatap-22 (work in progress), May 2004. | |||
[15] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. | [15] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. | |||
[16] Hagino, J., "Possible abuse against IPv6 transition | [16] Hagino, J., "Possible abuse against IPv6 transition | |||
technologies", draft-itojun-ipv6-transition-abuse-01.txt | technologies", draft-itojun-ipv6-transition-abuse-01.txt | |||
(expired, work-in-progress) , July 2000. | (expired, work-in-progress) , July 2000. | |||
[17] Barros, C., "Proposal for ICMP Traceback Messages", http:// | ||||
www.research.att.com/lists/ietf-itrace/2000/09/msg00044.html . | ||||
[18] Merit Network Inc., "Routing Assets Database (http:// | ||||
www.radb.net)". | ||||
Authors' Addresses | Authors' Addresses | |||
Pekka Savola | Pekka Savola | |||
CSC/FUNET | CSC/FUNET | |||
Espoo | Espoo | |||
Finland | Finland | |||
EMail: psavola@funet.fi | EMail: psavola@funet.fi | |||
Chirayu Patel | Chirayu Patel | |||
skipping to change at page 38, line 12 | skipping to change at page 39, line 12 | |||
Some implementations might have been careful enough to have designed | Some implementations might have been careful enough to have designed | |||
the stack to as to avoid the incoming (or reply) packets going to | the stack to as to avoid the incoming (or reply) packets going to | |||
IPv4 packet processing through special addresses (e.g., IPv4-mapped | IPv4 packet processing through special addresses (e.g., IPv4-mapped | |||
addresses), but who can say for all ... | addresses), but who can say for all ... | |||
Appendix B. Change Log | Appendix B. Change Log | |||
[[ RFC-EDITOR note: to be removed before publication ]] | [[ RFC-EDITOR note: to be removed before publication ]] | |||
Changes from -02 to -03 | ||||
1. Only rather minor editorial changes. | ||||
Changes from -01 to -02 | Changes from -01 to -02 | |||
1. Incorporate Iljitsch's feedback | 1. Incorporate Iljitsch's feedback | |||
2. Clean up section 6.2 | 2. Clean up section 6.2 | |||
3. Fix encapsulation code (had been munged in -01) | 3. Fix encapsulation code (had been munged in -01) | |||
Changes from -00 to -01 | Changes from -00 to -01 | |||
skipping to change at page 39, line 13 | skipping to change at page 40, line 13 | |||
3. Added Chirayu Patel as a co-author. | 3. Added Chirayu Patel as a co-author. | |||
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 Rights or other rights that might be claimed to | Intellectual Property Rights 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; nor does it represent that it has | might or might not be available; nor does it represent that it has | |||
made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
on the IETF's procedures with respect to rights in IETF Documents can | on the procedures with respect to rights in RFC documents can be | |||
be found in BCP 78 and BCP 79. | found in BCP 78 and BCP 79. | |||
Copies of IPR disclosures made to the IETF Secretariat and any | Copies of IPR disclosures made to the IETF Secretariat and any | |||
assurances of licenses to be made available, or the result of an | 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 | attempt made to obtain a general license or permission for the use of | |||
such proprietary rights by implementers or users of this | such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository at | |||
http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
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 | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |