draft-ietf-rtgwg-rfc3682bis-10.txt | rfc5082.txt | |||
---|---|---|---|---|
Routing WG V. Gill | Network Working Group V. Gill | |||
Internet-Draft J. Heasley | Request for Comments: 5082 J. Heasley | |||
Obsoletes: 3682 (if approved) D. Meyer | Obsoletes: 3682 D. Meyer | |||
Intended status: Standards Track P. Savola, Ed. | Category: Standards Track P. Savola, Ed. | |||
Expires: December 27, 2007 C. Pignataro | C. Pignataro | |||
June 25, 2007 | October 2007 | |||
The Generalized TTL Security Mechanism (GTSM) | The Generalized TTL Security Mechanism (GTSM) | |||
draft-ietf-rtgwg-rfc3682bis-10.txt | ||||
Status of this Memo | ||||
By submitting this Internet-Draft, each author represents that any | ||||
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 | ||||
aware will be disclosed, in accordance with Section 6 of BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF), its areas, and its working groups. Note that | ||||
other groups may also distribute working documents as Internet- | ||||
Drafts. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | Status of This Memo | |||
and may be updated, replaced, or obsoleted by other documents at any | ||||
time. It is inappropriate to use Internet-Drafts as reference | ||||
material or to cite them other than as "work in progress." | ||||
The list of current Internet-Drafts can be accessed at | ||||
http://www.ietf.org/ietf/1id-abstracts.txt. | ||||
The list of Internet-Draft Shadow Directories can be accessed at | ||||
http://www.ietf.org/shadow.html. | ||||
This Internet-Draft will expire on December 27, 2007. | ||||
Copyright Notice | ||||
Copyright (C) The IETF Trust (2007). | This document specifies an Internet standards track protocol for the | |||
Internet community, and requests discussion and suggestions for | ||||
improvements. Please refer to the current edition of the "Internet | ||||
Official Protocol Standards" (STD 1) for the standardization state | ||||
and status of this protocol. Distribution of this memo is unlimited. | ||||
Abstract | Abstract | |||
The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) | The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) | |||
to verify whether the packet was originated by an adjacent node on a | to verify whether the packet was originated by an adjacent node on a | |||
connected link has been used in many recent protocols. This document | connected link has been used in many recent protocols. This document | |||
generalizes this technique. This document obsoletes Experimental RFC | generalizes this technique. This document obsoletes Experimental RFC | |||
3682. | 3682. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Assumptions Underlying GTSM . . . . . . . . . . . . . . . . . 3 | 2. Assumptions Underlying GTSM . . . . . . . . . . . . . . . . . 3 | |||
2.1. GTSM Negotiation . . . . . . . . . . . . . . . . . . . . . 4 | 2.1. GTSM Negotiation . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.2. Assumptions on Attack Sophistication . . . . . . . . . . . 4 | 2.2. Assumptions on Attack Sophistication . . . . . . . . . . . 4 | |||
3. GTSM Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3. GTSM Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 | 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | |||
5.1. TTL (Hop Limit) Spoofing . . . . . . . . . . . . . . . . . 7 | 5.1. TTL (Hop Limit) Spoofing . . . . . . . . . . . . . . . . . 7 | |||
5.2. Tunneled Packets . . . . . . . . . . . . . . . . . . . . . 7 | 5.2. Tunneled Packets . . . . . . . . . . . . . . . . . . . . . 7 | |||
5.2.1. IP Tunneled over IP . . . . . . . . . . . . . . . . . 8 | 5.2.1. IP Tunneled over IP . . . . . . . . . . . . . . . . . 8 | |||
5.2.2. IP Tunneled over MPLS . . . . . . . . . . . . . . . . 9 | 5.2.2. IP Tunneled over MPLS . . . . . . . . . . . . . . . . 9 | |||
5.3. Onlink Attackers . . . . . . . . . . . . . . . . . . . . . 11 | 5.3. Onlink Attackers . . . . . . . . . . . . . . . . . . . . . 11 | |||
5.4. Fragmentation Considerations . . . . . . . . . . . . . . . 11 | 5.4. Fragmentation Considerations . . . . . . . . . . . . . . . 11 | |||
5.5. Multi-Hop Protocol Sessions . . . . . . . . . . . . . . . 12 | 5.5. Multi-Hop Protocol Sessions . . . . . . . . . . . . . . . 12 | |||
6. Applicability Statement . . . . . . . . . . . . . . . . . . . 12 | 6. Applicability Statement . . . . . . . . . . . . . . . . . . . 12 | |||
6.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 13 | 6.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 12 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 | 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 | Appendix A. Multi-Hop GTSM . . . . . . . . . . . . . . . . . . . 15 | |||
Appendix A. Multi-hop GTSM . . . . . . . . . . . . . . . . . . . 15 | ||||
Appendix B. Changes Since RFC3682 . . . . . . . . . . . . . . . 15 | Appendix B. Changes Since RFC3682 . . . . . . . . . . . . . . . 15 | |||
Appendix C. Draft Changelog . . . . . . . . . . . . . . . . . . 15 | ||||
Appendix C.1. Changes between -09 and -10 . . . . . . . . . . . . 15 | ||||
Appendix C.2. Changes between -08 and -09 . . . . . . . . . . . . 16 | ||||
Appendix C.3. Changes between -07 and -08 . . . . . . . . . . . . 16 | ||||
Appendix C.4. Changes between -06 and -07 . . . . . . . . . . . . 16 | ||||
Appendix C.5. Changes between -05 and -06 . . . . . . . . . . . . 17 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 | ||||
Intellectual Property and Copyright Statements . . . . . . . . . . 18 | ||||
1. Introduction | 1. Introduction | |||
The Generalized TTL Security Mechanism (GTSM) is designed to protect | The Generalized TTL Security Mechanism (GTSM) is designed to protect | |||
a router's IP based control plane from CPU-utilization based attacks. | a router's IP-based control plane from CPU-utilization based attacks. | |||
In particular, while cryptographic techniques can protect the router- | In particular, while cryptographic techniques can protect the router- | |||
based infrastructure (e.g., BGP [RFC4271], [RFC4272]) from a wide | based infrastructure (e.g., BGP [RFC4271], [RFC4272]) from a wide | |||
variety of attacks, many attacks based on CPU overload can be | variety of attacks, many attacks based on CPU overload can be | |||
prevented by the simple mechanism described in this document. Note | prevented by the simple mechanism described in this document. Note | |||
that the same technique protects against other scarce-resource | that the same technique protects against other scarce-resource | |||
attacks involving a router's CPU, such as attacks against processor- | attacks involving a router's CPU, such as attacks against processor- | |||
line card bandwidth. | line card bandwidth. | |||
GTSM is based on the fact that the vast majority of protocol peerings | GTSM is based on the fact that the vast majority of protocol peerings | |||
are established between routers that are adjacent. Thus most | are established between routers that are adjacent. Thus, most | |||
protocol peerings are either directly between connected interfaces or | protocol peerings are either directly between connected interfaces | |||
at the worst case, are between loopback and loopback, with static | or, in the worst case, are between loopback and loopback, with static | |||
routes to loopbacks. Since TTL spoofing is considered nearly | routes to loopbacks. Since TTL spoofing is considered nearly | |||
impossible, a mechanism based on an expected TTL value can provide a | impossible, a mechanism based on an expected TTL value can provide a | |||
simple and reasonably robust defense from infrastructure attacks | simple and reasonably robust defense from infrastructure attacks | |||
based on forged protocol packets from outside the network. Note, | based on forged protocol packets from outside the network. Note, | |||
however, that GTSM is not a substitute for authentication mechanisms. | however, that GTSM is not a substitute for authentication mechanisms. | |||
In particular, it does not secure against insider on-the-wire | In particular, it does not secure against insider on-the-wire | |||
attacks, such as packet spoofing or replay. | attacks, such as packet spoofing or replay. | |||
Finally, the GTSM mechanism is equally applicable to both TTL (IPv4) | Finally, the GTSM mechanism is equally applicable to both TTL (IPv4) | |||
and Hop Limit (IPv6), and from the perspective of GTSM, TTL and Hop | and Hop Limit (IPv6), and from the perspective of GTSM, TTL and Hop | |||
skipping to change at page 4, line 15 | skipping to change at page 3, line 37 | |||
3. Use of GTSM is OPTIONAL, and can be configured on a per-peer | 3. Use of GTSM is OPTIONAL, and can be configured on a per-peer | |||
(group) basis. | (group) basis. | |||
4. The peer routers both implement GTSM. | 4. The peer routers both implement GTSM. | |||
5. The router supports a method to use separate resource pools | 5. The router supports a method to use separate resource pools | |||
(e.g., queues, processing quotas) for differently classified | (e.g., queues, processing quotas) for differently classified | |||
traffic. | traffic. | |||
Note that this document does not prescribe further restrictions that | Note that this document does not prescribe further restrictions that | |||
a router may apply to the packets not matching the GTSM filtering | a router may apply to packets not matching the GTSM filtering rules, | |||
rules, such as dropping packets that do not match any configured | such as dropping packets that do not match any configured protocol | |||
protocol session and rate-limiting the rest. This document also does | session and rate-limiting the rest. This document also does not | |||
not suggest the actual means of resource separation, as those are | suggest the actual means of resource separation, as those are | |||
hardware and implementation-specific. | hardware and implementation-specific. | |||
The possibility of denial-of-service (DoS) attack prevention, | However, the possibility of denial-of-service (DoS) attack prevention | |||
however, is based on the assumption that classification of packets | is based on the assumption that classification of packets and | |||
and separation of their paths are done before they go through a | separation of their paths are done before the packets go through a | |||
scarce resource in the system. In practice, this means that, the | scarce resource in the system. In practice, the closer GTSM | |||
closer GTSM processing is done to the line-rate hardware, the more | processing is done to the line-rate hardware, the more resistant the | |||
resistant the system is to the DoS attacks. | system is to DoS attacks. | |||
2.1. GTSM Negotiation | 2.1. GTSM Negotiation | |||
This document assumes that, when used with existing protocols, GTSM | This document assumes that, when used with existing protocols, GTSM | |||
will be manually configured between protocol peers. That is, no | will be manually configured between protocol peers. That is, no | |||
automatic GTSM capability negotiation, such as is provided by RFC | automatic GTSM capability negotiation, such as is provided by RFC | |||
3392 [RFC3392] is assumed or defined. | 3392 [RFC3392], is assumed or defined. | |||
If a new protocol is designed with built-in GTSM support, then it is | If a new protocol is designed with built-in GTSM support, then it is | |||
recommended that procedures are always used for sending and | recommended that procedures are always used for sending and | |||
validating received protocol packets (GTSM is always on, see for | validating received protocol packets (GTSM is always on, see for | |||
example [RFC2461]). If, however, dynamic negotiation of GTSM support | example [RFC2461]). If, however, dynamic negotiation of GTSM support | |||
is necessary, protocol messages used for such negotiation MUST be | is necessary, protocol messages used for such negotiation MUST be | |||
authenticated using other security mechanisms to prevent DoS attacks. | authenticated using other security mechanisms to prevent DoS attacks. | |||
Also note that this specification does not offer a generic GTSM | Also note that this specification does not offer a generic GTSM | |||
capability negotiation mechanism, so messages of the protocol | capability negotiation mechanism, so messages of the protocol | |||
augmented with the GTSM behavior will need to be used if dynamic | augmented with the GTSM behavior will need to be used if dynamic | |||
negotiation is deemed necessary. | negotiation is deemed necessary. | |||
2.2. Assumptions on Attack Sophistication | 2.2. Assumptions on Attack Sophistication | |||
Throughout this document, we assume that potential attackers have | Throughout this document, we assume that potential attackers have | |||
evolved in both sophistication and access to the point that they can | evolved in both sophistication and access to the point that they can | |||
send control traffic to a protocol session, and that this traffic | send control traffic to a protocol session, and that this traffic | |||
appears to be valid control traffic (i.e., has the source/destination | appears to be valid control traffic (i.e., it has the source/ | |||
of configured peer routers). | destination of configured peer routers). | |||
We also assume that each router in the path between the attacker and | We also assume that each router in the path between the attacker and | |||
the victim protocol speaker decrements TTL properly (clearly, if | the victim protocol speaker decrements TTL properly (clearly, if | |||
either the path or the adjacent peer is compromised, then there are | either the path or the adjacent peer is compromised, then there are | |||
worse problems to worry about). | worse problems to worry about). | |||
For maximal protection, ingress filtering should be applied before | For maximal protection, ingress filtering should be applied before | |||
the packet goes through the scarce resource. Otherwise an attacker | the packet goes through the scarce resource. Otherwise an attacker | |||
directly connected to one interface could disturb a GTSM-protected | directly connected to one interface could disturb a GTSM-protected | |||
session on the same or another interface. Interfaces which aren't | session on the same or another interface. Interfaces that aren't | |||
configured with this filtering (e.g., backbone links) are assumed to | configured with this filtering (e.g., backbone links) are assumed to | |||
not have such attackers (i.e., are trusted). | not have such attackers (i.e., are trusted). | |||
As a specific instance of such interfaces, we assume that tunnels are | As a specific instance of such interfaces, we assume that tunnels are | |||
not a back-door for allowing TTL-spoofing on protocol packets for a | not a back-door for allowing TTL-spoofing on protocol packets to a | |||
GTSM-protected peering session with a directly connected neighbor. | GTSM-protected peering session with a directly connected neighbor. | |||
We assume that: 1) there are no tunneled packets terminating on the | We assume that: 1) there are no tunneled packets terminating on the | |||
router, 2) tunnels terminating on the router are assumed to be secure | router, 2) tunnels terminating on the router are assumed to be secure | |||
and endpoints are trusted, 3) tunnel decapsulation includes source | and endpoints are trusted, 3) tunnel decapsulation includes source | |||
address spoofing prevention [RFC3704], or 4) the GTSM-enabled session | address spoofing prevention [RFC3704], or 4) the GTSM-enabled session | |||
does not allow protocol packets coming from a tunnel. | does not allow protocol packets coming from a tunnel. | |||
Since the vast majority of peerings are between adjacent routers, we | Since the vast majority of peerings are between adjacent routers, we | |||
can set the TTL on the protocol packets to 255 (the maximum possible | can set the TTL on the protocol packets to 255 (the maximum possible | |||
for IP) and then reject any protocol packets that come in from | for IP) and then reject any protocol packets that come in from | |||
configured peers which do NOT have an inbound TTL of 255. | configured peers that do NOT have an inbound TTL of 255. | |||
GTSM can be disabled for applications such as route-servers and other | GTSM can be disabled for applications such as route-servers and other | |||
multi-hop peerings. In the event that an attack comes in from a | multi-hop peerings. In the event that an attack comes in from a | |||
compromised multi-hop peering, that peering can be shut down. | compromised multi-hop peering, that peering can be shut down. | |||
3. GTSM Procedure | 3. GTSM Procedure | |||
If GTSM is not built into the protocol and is used as an additional | If GTSM is not built into the protocol and is used as an additional | |||
feature (e.g., for BGP, LDP, or MSDP), it SHOULD NOT be enabled by | feature (e.g., for BGP, LDP, or MSDP), it SHOULD NOT be enabled by | |||
default in order to be backward-compatible with the unmodified | default in order to remain backward-compatible with the unmodified | |||
protocol. However, if the protocol defines a built-in dynamic | protocol. However, if the protocol defines a built-in dynamic | |||
capability negotiation for GTSM, a protocol peer MAY suggest the use | capability negotiation for GTSM, a protocol peer MAY suggest the use | |||
of GTSM provided that GTSM would only be enabled if both peers agree | of GTSM provided that GTSM would only be enabled if both peers agree | |||
to use it. | to use it. | |||
If GTSM is enabled for a protocol session, the following steps are | If GTSM is enabled for a protocol session, the following steps are | |||
added to the IP packet sending and reception procedures: | added to the IP packet sending and reception procedures: | |||
Sending protocol packets: | Sending protocol packets: | |||
skipping to change at page 6, line 32 | skipping to change at page 6, line 8 | |||
any registered GTSM-enabled session, and hence GTSM cannot | any registered GTSM-enabled session, and hence GTSM cannot | |||
make any judgment on the level of risk associated with them. | make any judgment on the level of risk associated with them. | |||
+ Trusted: these are packets that have been identified as | + Trusted: these are packets that have been identified as | |||
belonging to one of the GTSM-enabled sessions, and their TTL | belonging to one of the GTSM-enabled sessions, and their TTL | |||
values are within the expected range. | values are within the expected range. | |||
+ Dangerous: these are packets that have been identified as | + Dangerous: these are packets that have been identified as | |||
belonging to one of the GTSM-enabled sessions, but their TTL | belonging to one of the GTSM-enabled sessions, but their TTL | |||
values are NOT within the expected range, and hence GTSM | values are NOT within the expected range, and hence GTSM | |||
believes there is a risk that the packets have been spoofed. | believes there is a risk that these packets have been | |||
spoofed. | ||||
The exact policies applied to packets of different | The exact policies applied to packets of different | |||
classifications are not postulated in this document and are | classifications are not postulated in this document and are | |||
expected to be configurable. Configurability is likely | expected to be configurable. Configurability is likely | |||
necessary in particular with the treatment of related messages | necessary in particular with the treatment of related messages | |||
(ICMP errors). It should be noted that fragmentation may | (ICMP errors). It should be noted that fragmentation may | |||
restrict the amount of information available to the | restrict the amount of information available for | |||
classification. | classification. | |||
However, by default, the implementations: | However, by default, the implementations: | |||
+ SHOULD ensure that packets classified as Dangerous do not | + SHOULD ensure that packets classified as Dangerous do not | |||
compete for resources with packets classified as Trusted or | compete for resources with packets classified as Trusted or | |||
Unknown. | Unknown. | |||
+ MUST NOT drop (as part of GTSM processing) packets | + MUST NOT drop (as part of GTSM processing) packets | |||
classified as Trusted or Unknown. | classified as Trusted or Unknown. | |||
+ MAY drop packets classified as Dangerous. | + MAY drop packets classified as Dangerous. | |||
4. Acknowledgments | 4. Acknowledgments | |||
The use of the TTL field to protect BGP originated with many | The use of the TTL field to protect BGP originated with many | |||
different people, including Paul Traina and Jon Stewart. Ryan | different people, including Paul Traina and Jon Stewart. Ryan | |||
McDowell also suggested a similar idea. Steve Bellovin, Jay | McDowell also suggested a similar idea. Steve Bellovin, Jay | |||
Borkenhagen, Randy Bush, Alfred Hoenes, Vern Paxon, Robert Raszuk and | Borkenhagen, Randy Bush, Alfred Hoenes, Vern Paxon, Robert Raszuk, | |||
Alex Zinin also provided useful feedback on earlier versions of this | and Alex Zinin also provided useful feedback on earlier versions of | |||
document. David Ward provided insight on the generalization of the | this document. David Ward provided insight on the generalization of | |||
original BGP-specific idea. Alex Zinin, Alia Atlas, and John Scudder | the original BGP-specific idea. Alex Zinin, Alia Atlas, and John | |||
provided significant amount of feedback for the newer versions of the | Scudder provided a significant amount of feedback for the newer | |||
document. During and after the IETF Last Call, Francis Dupont, Sam | versions of the document. During and after the IETF Last Call, | |||
Hartman, Lars Eggert, and Ross Callon. | useful comments were provided by Francis Dupont, Sam Hartman, Lars | |||
Eggert, and Ross Callon. | ||||
5. Security Considerations | 5. Security Considerations | |||
GTSM is a simple procedure that protects single hop protocol | GTSM is a simple procedure that protects single-hop protocol | |||
sessions, except in those cases in which the peer has been | sessions, except in those cases in which the peer has been | |||
compromised. In particular, it does not protect against the wide | compromised. In particular, it does not protect against the wide | |||
range of on-the-wire attacks; protection from these attacks requires | range of on-the-wire attacks; protection from these attacks requires | |||
more rigorous security mechanisms. | more rigorous security mechanisms. | |||
5.1. TTL (Hop Limit) Spoofing | 5.1. TTL (Hop Limit) Spoofing | |||
The approach described here is based on the observation that a TTL | The approach described here is based on the observation that a TTL | |||
(or Hop Limit) value of 255 is non-trivial to spoof, since as the | (or Hop Limit) value of 255 is non-trivial to spoof, since as the | |||
packet passes through routers towards the destination, the TTL is | packet passes through routers towards the destination, the TTL is | |||
skipping to change at page 8, line 11 | skipping to change at page 7, line 37 | |||
authentication at the tunnel endpoints, as well as how the tunneled | authentication at the tunnel endpoints, as well as how the tunneled | |||
packets are protected in flight. Such mechanisms are, however, | packets are protected in flight. Such mechanisms are, however, | |||
beyond the scope of this memo. | beyond the scope of this memo. | |||
An exception to the observation that a packet with TTL of 255 is | An exception to the observation that a packet with TTL of 255 is | |||
difficult to spoof may occur when a protocol packet is tunneled and | difficult to spoof may occur when a protocol packet is tunneled and | |||
the tunnel is not integrity-protected (i.e., the lower layer is | the tunnel is not integrity-protected (i.e., the lower layer is | |||
compromised). | compromised). | |||
When the protocol packet is tunneled directly to the protocol peer | When the protocol packet is tunneled directly to the protocol peer | |||
(the protocol peer is the decapsulator), the GTSM provides some | (i.e., the protocol peer is the decapsulator), the GTSM provides some | |||
limited added protection as the security depends entirely on the | limited added protection as the security depends entirely on the | |||
integrity of the tunnel. | integrity of the tunnel. | |||
For protocol adjacencies over a tunnel, if the tunnel itself is | For protocol adjacencies over a tunnel, if the tunnel itself is | |||
deemed secure (e.g., the underlying infrastructure is deemed secure, | deemed secure (i.e., the underlying infrastructure is deemed secure, | |||
and the tunnel offers degrees of protection against spoofing such as | and the tunnel offers degrees of protection against spoofing such as | |||
keys or cryptographic security), the GTSM can serve as a check that | keys or cryptographic security), the GTSM can serve as a check that | |||
the protocol packet did not originate beyond the head-end of the | the protocol packet did not originate beyond the head-end of the | |||
tunnel. In addition, if the protocol peer can receive packets for | tunnel. In addition, if the protocol peer can receive packets for | |||
the GTSM-protected protocol session from outside the tunnel, the GTSM | the GTSM-protected protocol session from outside the tunnel, the GTSM | |||
can help thwart attacks from beyond the adjacent router. | can help thwart attacks from beyond the adjacent router. | |||
When the tunnel tail-end decapsulates the protocol packet and then | When the tunnel tail-end decapsulates the protocol packet and then | |||
IP-forwards the packet to a directly connected protocol peer, TTL is | IP-forwards the packet to a directly connected protocol peer, the TTL | |||
decremented as described below. This means that the tunnel | is decremented as described below. This means that the tunnel | |||
decapsulator is the penultimate node from the GTSM-protected protocol | decapsulator is the penultimate node from the GTSM-protected protocol | |||
peer's perspective. As a result, the GTSM check protects from | peer's perspective. As a result, the GTSM check protects from | |||
attackers encapsulating packets to your peers. However, specific | attackers encapsulating packets to your peers. However, specific | |||
cases arise when the connection from the tunnel decapsulator node to | cases arise when the connection from the tunnel decapsulator node to | |||
the protocol peer is not an IP forwarding hop, where TTL-decrementing | the protocol peer is not an IP forwarding hop, where TTL-decrementing | |||
does not happen (e.g., layer-2 tunneling, bridging, etc). In the | does not happen (e.g., layer-2 tunneling, bridging, etc). In the | |||
IPsec architecture [RFC4301], another example is the use of Bump-in- | IPsec architecture [RFC4301], another example is the use of Bump-in- | |||
the-Wire (BITW) [BITW]. | the-Wire (BITW) [BITW]. | |||
5.2.1. IP Tunneled over IP | 5.2.1. IP Tunneled over IP | |||
Protocol packets may be tunneled over IP directly to a protocol peer, | Protocol packets may be tunneled over IP directly to a protocol peer, | |||
or to a decapsulator (tunnel endpoint) that then forwards the packet | or to a decapsulator (tunnel endpoint) that then forwards the packet | |||
to a directly connected protocol peer. Examples of tunneling IP over | to a directly connected protocol peer. Examples of tunneling IP over | |||
IP include IP-in-IP [RFC2003], GRE [RFC2784], or various forms of | IP include IP-in-IP [RFC2003], GRE [RFC2784], and various forms of | |||
IPv6-in-IPv4 (e.g., [RFC4213]). These cases are depicted below. | IPv6-in-IPv4 (e.g., [RFC4213]). These cases are depicted below. | |||
Peer router ---------- Tunnel endpoint router and peer | Peer router ---------- Tunnel endpoint router and peer | |||
TTL=255 [tunnel] [TTL=255 at ingress] | TTL=255 [tunnel] [TTL=255 at ingress] | |||
[TTL=255 at processing] | [TTL=255 at processing] | |||
Peer router -------- Tunnel endpoint router ----- On-link peer | Peer router -------- Tunnel endpoint router ----- On-link peer | |||
TTL=255 [tunnel] [TTL=255 at ingress] [TTL=254 at ingress] | TTL=255 [tunnel] [TTL=255 at ingress] [TTL=254 at ingress] | |||
[TTL=254 at egress] | [TTL=254 at egress] | |||
skipping to change at page 9, line 18 | skipping to change at page 8, line 44 | |||
header is decremented by one if the tunneling is being | header is decremented by one if the tunneling is being | |||
done as part of forwarding the datagram; otherwise, the | done as part of forwarding the datagram; otherwise, the | |||
inner header TTL is not changed during encapsulation. | inner header TTL is not changed during encapsulation. | |||
In the first case, the encapsulated packet is tunneled directly to | In the first case, the encapsulated packet is tunneled directly to | |||
the protocol peer (also a tunnel endpoint), and therefore the | the protocol peer (also a tunnel endpoint), and therefore the | |||
encapsulated packet's TTL can be received by the protocol peer with | encapsulated packet's TTL can be received by the protocol peer with | |||
an arbitrary value, including 255. | an arbitrary value, including 255. | |||
In the second case, the encapsulated packet is tunneled to a | In the second case, the encapsulated packet is tunneled to a | |||
decapsulator (tunnel endpoint) which then forwards it to a directly | decapsulator (tunnel endpoint), which then forwards it to a directly | |||
connected protocol peer. For IP-in-IP tunnels, RFC 2003 specifies | connected protocol peer. For IP-in-IP tunnels, RFC 2003 specifies | |||
the following decapsulator behavior: | the following decapsulator behavior: | |||
The TTL in the inner IP header is not changed when decapsulating. | The TTL in the inner IP header is not changed when decapsulating. | |||
If, after decapsulation, the inner datagram has TTL = 0, the | If, after decapsulation, the inner datagram has TTL = 0, the | |||
decapsulator MUST discard the datagram. If, after decapsulation, | decapsulator MUST discard the datagram. If, after decapsulation, | |||
the decapsulator forwards the datagram to one of its network | the decapsulator forwards the datagram to one of its network | |||
interfaces, it will decrement the TTL as a result of doing normal | interfaces, it will decrement the TTL as a result of doing normal | |||
IP forwarding. See also Section 4.4. | IP forwarding. See also Section 4.4. | |||
skipping to change at page 10, line 28 | skipping to change at page 10, line 10 | |||
the iTTL: For Uniform Model LSPs, the iTTL is the value of the TTL | the iTTL: For Uniform Model LSPs, the iTTL is the value of the TTL | |||
field from the popped MPLS header (encapsulating header), whereas for | field from the popped MPLS header (encapsulating header), whereas for | |||
Pipe Model LSPs, the iTTL is the value of the TTL field from the | Pipe Model LSPs, the iTTL is the value of the TTL field from the | |||
exposed header (encapsulated header). | exposed header (encapsulated header). | |||
For Uniform Model LSPs, RFC 3443 states that at ingress: | For Uniform Model LSPs, RFC 3443 states that at ingress: | |||
For each pushed Uniform Model label, the TTL is copied from the | For each pushed Uniform Model label, the TTL is copied from the | |||
label/IP-packet immediately underneath it. | label/IP-packet immediately underneath it. | |||
From this point, the inner TTL (TTL of the tunneled IP datagram) | From this point, the inner TTL (i.e., the TTL of the tunneled IP | |||
represents non-meaningful information, and at the egress node or | datagram) represents non-meaningful information, and at the egress | |||
during PHP, the ingress TTL (iTTL) is equal to the TTL of the popped | node or during PHP, the ingress TTL (iTTL) is equal to the TTL of the | |||
MPLS header (see Section 3.1 of RFC 3443). In consequence, for | popped MPLS header (see Section 3.1 of RFC 3443). In consequence, | |||
Uniform Model LSPs of more than one hop, the TTL at ingress (iTTL) | for Uniform Model LSPs of more than one hop, the TTL at ingress | |||
will be less than 255 (x <= 254), and as a result the check described | (iTTL) will be less than 255 (x <= 254), and as a result the check | |||
in Section 3 of this document will fail. | described in Section 3 of this document will fail. | |||
The TTL treatment is identical between Short Pipe Model LSPs without | The TTL treatment is identical between Short Pipe Model LSPs without | |||
PHP and Pipe Model LSPs (without PHP only). For these cases, RFC | PHP and Pipe Model LSPs (without PHP only). For these cases, RFC | |||
3443 states that: | 3443 states that: | |||
For each pushed Pipe Model or Short Pipe Model label, the TTL | For each pushed Pipe Model or Short Pipe Model label, the TTL | |||
field is set to a value configured by the network operator. In | field is set to a value configured by the network operator. In | |||
most implementations, this value is set to 255 by default. | most implementations, this value is set to 255 by default. | |||
In these models, the forwarding treatment at egress is based on the | In these models, the forwarding treatment at egress is based on the | |||
skipping to change at page 11, line 12 | skipping to change at page 10, line 42 | |||
also the protocol peer, it is possible to deliver the protocol packet | also the protocol peer, it is possible to deliver the protocol packet | |||
with a TTL of 255 (x = 255). | with a TTL of 255 (x = 255). | |||
Finally, for Short Pipe Model LSPs with PHP, the TTL of the tunneled | Finally, for Short Pipe Model LSPs with PHP, the TTL of the tunneled | |||
packet is unchanged after the PHP operation. Therefore, the same | packet is unchanged after the PHP operation. Therefore, the same | |||
conclusions drawn regarding the Short Pipe Model LSPs without PHP and | conclusions drawn regarding the Short Pipe Model LSPs without PHP and | |||
Pipe Model LSPs (without PHP only) apply to this case. For Short | Pipe Model LSPs (without PHP only) apply to this case. For Short | |||
Pipe Model LSPs, the TTL at egress has the same value with or without | Pipe Model LSPs, the TTL at egress has the same value with or without | |||
PHP. | PHP. | |||
In conclusion, GTSM-checks are possible for IP tunneled over Pipe | In conclusion, GTSM checks are possible for IP tunneled over Pipe | |||
model LSPs, but not for IP tunneled over Uniform model LSPs. | model LSPs, but not for IP tunneled over Uniform model LSPs. | |||
Additionally, for all tunneling modes, if the LSP termination router | Additionally, for all tunneling modes, if the LSP termination router | |||
needs to forward the protocol packet to a directly connected protocol | needs to forward the protocol packet to a directly connected protocol | |||
peer, it is not possible to deliver the protocol packet to the | peer, it is not possible to deliver the protocol packet to the | |||
protocol peer with a TTL of 255. If the packet is further forwarded, | protocol peer with a TTL of 255. If the packet is further forwarded, | |||
the outgoing TTL (oTTL) is calculated by decrementing iTTL by one. | the outgoing TTL (oTTL) is calculated by decrementing iTTL by one. | |||
5.3. Onlink Attackers | 5.3. Onlink Attackers | |||
As described in Section 2, an attacker directly connected to one | As described in Section 2, an attacker directly connected to one | |||
interface can disturb a GTSM-protected session on the same or another | interface can disturb a GTSM-protected session on the same or another | |||
interface (by spoofing a GTSM peer's address) unless ingress | interface (by spoofing a GTSM peer's address) unless ingress | |||
filtering has been applied on the connecting interface. As a result, | filtering has been applied on the connecting interface. As a result, | |||
interfaces which do not include such protection need to be trusted | interfaces that do not include such protection need to be trusted not | |||
not to originate attacks on the router. | to originate attacks on the router. | |||
5.4. Fragmentation Considerations | 5.4. Fragmentation Considerations | |||
As already mentioned, fragmentation may restrict the amount of | As mentioned, fragmentation may restrict the amount of information | |||
information available for classification. Since non-initial IP | available for classification. Since non-initial IP fragments do not | |||
fragments do not contain Layer 4 information, it is highly likely | contain Layer 4 information, it is highly likely that they cannot be | |||
that they cannot be associated with a registered GTSM-enabled | associated with a registered GTSM-enabled session. Following the | |||
session. Following the receiving protocol procedures described in | receiving protocol procedures described in Section 3, non-initial IP | |||
Section 3, non-initial IP fragments would likely be classified with | fragments would likely be classified with Unknown trustworthiness. | |||
Unknown trustworthiness. And since the IP packet would need to be | And since the IP packet would need to be reassembled in order to be | |||
reassembled in order to be processed, the end result is that the | processed, the end result is that the initial-fragment of a GTSM- | |||
initial-fragment of a GTSM-enabled session effectively receives the | enabled session effectively receives the treatment of an Unknown- | |||
treatment of an Unknown-trustworthiness packet, and the complete | trustworthiness packet, and the complete reassembled packet receives | |||
reassembled packet receives the aggregate of the Unknowns. | the aggregate of the Unknowns. | |||
In principle an implementation could remember the TTL of all received | In principle, an implementation could remember the TTL of all | |||
fragments, and then when reassembling the packet verify that the TTL | received fragments. Then when reassembling the packet, verify that | |||
of all fragments matches the required value for an associated GTSM- | the TTL of all fragments match the required value for an associated | |||
enabled session. In the likely common case that the implementation | GTSM-enabled session. In the likely common case that the | |||
does not do this check on all fragments, then it is possible for a | implementation does not do this check on all fragments, then it is | |||
legitimate first fragment (which passes the GTSM check) to be | possible for a legitimate first fragment (which passes the GTSM | |||
combined with spoofed non-initial fragments, implying that the | check) to be combined with spoofed non-initial fragments, implying | |||
integrity of the received packet is unknown and unprotected. If this | that the integrity of the received packet is unknown and unprotected. | |||
check is performed on all fragments at reassembly, and some fragment | If this check is performed on all fragments at reassembly, and some | |||
does not pass the GTSM check for a GTSM-enabled session, the | fragment does not pass the GTSM check for a GTSM-enabled session, the | |||
reassembled packet is categorized as a Dangerous-trustworthiness | reassembled packet is categorized as a Dangerous-trustworthiness | |||
packet and receives the corresponding treatment. | packet and receives the corresponding treatment. | |||
Further, reassembly requires to wait for all the fragments and | Further, reassembly requires to wait for all the fragments and | |||
therefore likely invalidates or weakens the fifth assumption | therefore likely invalidates or weakens the fifth assumption | |||
presented in Section 2: it may not be possible to classify non- | presented in Section 2: it may not be possible to classify non- | |||
initial fragments before going through a scarce resource in the | initial fragments before going through a scarce resource in the | |||
system, when fragments need to be buffered for reassembly and later | system, when fragments need to be buffered for reassembly and later | |||
processed by a CPU. That is, when classification cannot be done with | processed by a CPU. That is, when classification cannot be done with | |||
the required granularity, non-initial fragments of GTSM-enabled | the required granularity, non-initial fragments of GTSM-enabled | |||
session packets would not use different resource pools. | session packets would not use different resource pools. | |||
Consequently, to get practical protection from fragment attacks, | Consequently, to get practical protection from fragment attacks, | |||
operators may need to rate-limit or discard all received fragments. | operators may need to rate-limit or discard all received fragments. | |||
As such, it is highly RECOMMENDED for GTSM-protected protocols to | As such, it is highly RECOMMENDED for GTSM-protected protocols to | |||
avoid fragmentation and reassembly by manual MTU tuning, using | avoid fragmentation and reassembly by manual MTU tuning, using | |||
adaptive measures such as Path MTU Discovery (PMTUD) or any other | adaptive measures such as Path MTU Discovery (PMTUD), or any other | |||
available method [RFC1191], [RFC1981], [RFC4821]. | available method [RFC1191], [RFC1981], or [RFC4821]. | |||
5.5. Multi-Hop Protocol Sessions | 5.5. Multi-Hop Protocol Sessions | |||
GTSM could possibly offer some small though difficult to quantify | GTSM could possibly offer some small, though difficult to quantify, | |||
degree of protection when used with multi-hop protocol sessions (see | degree of protection when used with multi-hop protocol sessions (see | |||
Appendix A). In order to avoid having to quantify the degree of | Appendix A). In order to avoid having to quantify the degree of | |||
protection and the resulting applicability of multi-hop, we only | protection and the resulting applicability of multi-hop, we only | |||
describe the single-hop case because its security properties are | describe the single-hop case because its security properties are | |||
clearer. | clearer. | |||
6. Applicability Statement | 6. Applicability Statement | |||
GTSM is only applicable to environments with inherently limited | GTSM is only applicable to environments with inherently limited | |||
topologies (and is most effective in those cases where protocol peers | topologies (and is most effective in those cases where protocol peers | |||
skipping to change at page 12, line 49 | skipping to change at page 12, line 34 | |||
GTSM will not protect against attackers who are as close to the | GTSM will not protect against attackers who are as close to the | |||
protected station as its legitimate peer. For example, if the | protected station as its legitimate peer. For example, if the | |||
legitimate peer is one hop away, GTSM will not protect from attacks | legitimate peer is one hop away, GTSM will not protect from attacks | |||
from directly connected devices on the same interface (see | from directly connected devices on the same interface (see | |||
Section 2.2 for more). | Section 2.2 for more). | |||
Experimentation on GTSM's applicability and security properties is | Experimentation on GTSM's applicability and security properties is | |||
needed in multi-hop scenarios. The multi-hop scenarios where GTSM | needed in multi-hop scenarios. The multi-hop scenarios where GTSM | |||
might be applicable is expected to have the following | might be applicable is expected to have the following | |||
characteristics: the topology between peers is fairly static and well | characteristics: the topology between peers is fairly static and | |||
known, and in which the intervening network (between the peers) is | well-known, and in which the intervening network (between the peers) | |||
trusted. | is trusted. | |||
6.1. Backwards Compatibility | 6.1. Backwards Compatibility | |||
RFC 3682 [RFC3682] did not specify how to handle "related messages" | RFC 3682 [RFC3682] did not specify how to handle "related messages" | |||
(ICMP errors). This specification mandates setting and verifying | (ICMP errors). This specification mandates setting and verifying | |||
TTL=255 of those as well as the main protocol packets. | TTL=255 of those as well as the main protocol packets. | |||
Setting TTL=255 in related messages does not cause issues for RFC | Setting TTL=255 in related messages does not cause issues for RFC | |||
3682 implementations. | 3682 implementations. | |||
skipping to change at page 13, line 30 | skipping to change at page 13, line 14 | |||
as Dangerous and treated as described in Section 3. This is not | as Dangerous and treated as described in Section 3. This is not | |||
believed to be a significant problem because protocols do not depend | believed to be a significant problem because protocols do not depend | |||
on related messages (e.g., typically having a protocol exchange for | on related messages (e.g., typically having a protocol exchange for | |||
closing the session instead of doing a TCP-RST), and indeed the | closing the session instead of doing a TCP-RST), and indeed the | |||
delivery of related messages is not reliable. As such, related | delivery of related messages is not reliable. As such, related | |||
messages typically provide an optimization to shorten a protocol | messages typically provide an optimization to shorten a protocol | |||
keepalive timeout. Regardless of these issues, given that related | keepalive timeout. Regardless of these issues, given that related | |||
messages provide a significant attack vector to e.g., reset protocol | messages provide a significant attack vector to e.g., reset protocol | |||
sessions, making this further restriction seems sensible. | sessions, making this further restriction seems sensible. | |||
7. IANA Considerations | 7. References | |||
This document requires no action from IANA. | ||||
8. References | ||||
8.1. Normative References | 7.1. Normative References | |||
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, | [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, | |||
September 1981. | September 1981. | |||
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, | [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, | |||
October 1996. | October 1996. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
skipping to change at page 14, line 25 | skipping to change at page 14, line 5 | |||
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms | [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms | |||
for IPv6 Hosts and Routers", RFC 4213, October 2005. | for IPv6 Hosts and Routers", RFC 4213, October 2005. | |||
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway | [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway | |||
Protocol 4 (BGP-4)", RFC 4271, January 2006. | Protocol 4 (BGP-4)", RFC 4271, January 2006. | |||
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the | [RFC4301] Kent, S. and K. Seo, "Security Architecture for the | |||
Internet Protocol", RFC 4301, December 2005. | Internet Protocol", RFC 4301, December 2005. | |||
8.2. Informative References | 7.2. Informative References | |||
[BITW] "Thread: 'IP-in-IP, TTL decrementing when forwarding and | [BITW] "Thread: 'IP-in-IP, TTL decrementing when forwarding and | |||
BITW' on int-area list, Message-ID: | BITW' on int-area list, Message-ID: | |||
<Pine.LNX.4.64.0606020830220.12705@netcore.fi>", | <Pine.LNX.4.64.0606020830220.12705@netcore.fi>", | |||
June 2006, <http://www1.ietf.org/mail-archive/web/ | June 2006, <http://www1.ietf.org/mail-archive/web/ | |||
int-area/current/msg00267.html>. | int-area/current/msg00267.html>. | |||
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, | [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, | |||
November 1990. | November 1990. | |||
skipping to change at page 15, line 6 | skipping to change at page 15, line 5 | |||
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed | [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed | |||
Networks", BCP 84, RFC 3704, March 2004. | Networks", BCP 84, RFC 3704, March 2004. | |||
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", | [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", | |||
RFC 4272, January 2006. | RFC 4272, January 2006. | |||
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU | [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU | |||
Discovery", RFC 4821, March 2007. | Discovery", RFC 4821, March 2007. | |||
Appendix A. Multi-hop GTSM | Appendix A. Multi-Hop GTSM | |||
NOTE: This is a non-normative part of the specification. | NOTE: This is a non-normative part of the specification. | |||
The main applicability of GTSM is for directly connected peers. GTSM | The main applicability of GTSM is for directly connected peers. GTSM | |||
could be used for non-directly connected sessions as well, where the | could be used for non-directly connected sessions as well, where the | |||
recipient would check that the TTL is within a configured number of | recipient would check that the TTL is within a configured number of | |||
hops from 255 (e.g., check that packets have 254 or 255). As such | hops from 255 (e.g., check that packets have 254 or 255). As such | |||
deployment is expected to have a more limited applicability and | deployment is expected to have a more limited applicability and | |||
different security implications, it is not specified in this | different security implications, it is not specified in this | |||
document. | document. | |||
skipping to change at page 15, line 36 | skipping to change at page 15, line 35 | |||
o Explicitly require that related messages (ICMP errors) must also | o Explicitly require that related messages (ICMP errors) must also | |||
be sent and checked to have TTL=255. See Section 6.1 for | be sent and checked to have TTL=255. See Section 6.1 for | |||
discussion on backwards compatibility. | discussion on backwards compatibility. | |||
o Clarifications relating to fragmentation, security with tunneling, | o Clarifications relating to fragmentation, security with tunneling, | |||
and implications of ingress filtering. | and implications of ingress filtering. | |||
o A significant number of editorial improvements and clarifications. | o A significant number of editorial improvements and clarifications. | |||
Appendix C. Draft Changelog | ||||
NOTE to the RFC-editor: please remove this section before | ||||
publication. | ||||
Appendix C.1. Changes between -09 and -10 | ||||
o Editorial updates from IETF LC and IESG review. | ||||
o Clarify fragmentation and integrity issues, from Sam Hartman. | ||||
o Repeat the hop limit's protection implication in Applicability | ||||
Statement (Ron Bonica). | ||||
o Remove "TCP RSTs" from "related messages" examples (Lars Eggert). | ||||
o Only define ICMP errors as related messages (Ross Callon). | ||||
Appendix C.2. Changes between -08 and -09 | ||||
o Clarify that GTSM may be enabled on existing protocols if the | ||||
protocols include a capability negotiation feature and both | ||||
parties support GTSM. | ||||
o Editorial updates. | ||||
Appendix C.3. Changes between -07 and -08 | ||||
o Describe the assumption of ingress filtering to protect against | ||||
on-link attacks. | ||||
o Rewrite the IP over MPLS section based on the new MPLS TTL | ||||
handling procedure (from Carlos Pignataro) to get the details of | ||||
new MPLS architecture right. | ||||
o Rephrase IP over IP tunneling section a bit, to make distinction | ||||
between encapsulation and decapsulation behavior clearer. | ||||
o Make it clearer in the tunneling section that unless the tunnel | ||||
peer is also the protocol peer, GTSM should be able to offer | ||||
protection. | ||||
o Describe better the applicability of GTSM when tunneling. | ||||
o Rephrase Multi-hop GTSM section to mainly refer to the difficult- | ||||
to-quantify security properties as a reason for exclusion at this | ||||
point. | ||||
o Some editorial updates. | ||||
Appendix C.4. Changes between -06 and -07 | ||||
o Be more reserved about multi-hop security properties in section | ||||
'Multi-Hop Protocol Sessions'. | ||||
o Clarify IP-in-IP tunnel decapsulation/forwarding as decrementing | ||||
TTL. | ||||
o Add text on related messages backwards compatibility. | ||||
o Editorial updates. | ||||
Appendix C.5. Changes between -05 and -06 | ||||
o Clarify the assumptions wrt. resource separation and protection | ||||
based on comments from Alex Zinin. | ||||
o Rewrite the GTSM procedure based on text from Alex Zinin. | ||||
o Reduce TrustRadius and multi-hop scenarios to a mention in an | ||||
Appendix. | ||||
o Describe TCP-RST, ICMP error and "related messages" handling. | ||||
o Update the tunneling security considerations text. | ||||
o Editorial updates (e.g., shortening the abstract). | ||||
Authors' Addresses | Authors' Addresses | |||
Vijay Gill | Vijay Gill | |||
EMail: vijay@umbc.edu | ||||
Email: vijay@umbc.edu | ||||
John Heasley | John Heasley | |||
EMail: heas@shrubbery.net | ||||
Email: heas@shrubbery.net | ||||
David Meyer | David Meyer | |||
EMail: dmm@1-4-5.net | ||||
Email: dmm@1-4-5.net | ||||
Pekka Savola (editor) | Pekka Savola (editor) | |||
Espoo | Espoo | |||
Finland | Finland | |||
EMail: psavola@funet.fi | ||||
Email: psavola@funet.fi | ||||
Carlos Pignataro | Carlos Pignataro | |||
EMail: cpignata@cisco.com | ||||
Email: cpignata@cisco.com | ||||
Full Copyright Statement | Full Copyright Statement | |||
Copyright (C) The IETF Trust (2007). | Copyright (C) The IETF Trust (2007). | |||
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 | |||
skipping to change at page 18, line 44 | skipping to change at line 710 | |||
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 | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at | this standard. Please address the information to the IETF at | |||
ietf-ipr@ietf.org. | ietf-ipr@ietf.org. | |||
Acknowledgment | ||||
Funding for the RFC Editor function is provided by the IETF | ||||
Administrative Support Activity (IASA). | ||||
End of changes. 46 change blocks. | ||||
221 lines changed or deleted | 105 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/ |