idnits 2.17.1 draft-ietf-rtgwg-rfc3682bis-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 801. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 812. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 819. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 825. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC3682, but the abstract doesn't seem to directly say this. It does mention RFC3682 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 25, 2007) is 6121 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3392 (Obsoleted by RFC 5492) -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 3682 (Obsoleted by RFC 5082) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing WG V. Gill 3 Internet-Draft J. Heasley 4 Obsoletes: 3682 (if approved) D. Meyer 5 Intended status: Standards Track P. Savola, Ed. 6 Expires: December 27, 2007 C. Pignataro 7 June 25, 2007 9 The Generalized TTL Security Mechanism (GTSM) 10 draft-ietf-rtgwg-rfc3682bis-10.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 27, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) 44 to verify whether the packet was originated by an adjacent node on a 45 connected link has been used in many recent protocols. This document 46 generalizes this technique. This document obsoletes Experimental RFC 47 3682. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Assumptions Underlying GTSM . . . . . . . . . . . . . . . . . 3 53 2.1. GTSM Negotiation . . . . . . . . . . . . . . . . . . . . . 4 54 2.2. Assumptions on Attack Sophistication . . . . . . . . . . . 4 55 3. GTSM Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 58 5.1. TTL (Hop Limit) Spoofing . . . . . . . . . . . . . . . . . 7 59 5.2. Tunneled Packets . . . . . . . . . . . . . . . . . . . . . 7 60 5.2.1. IP Tunneled over IP . . . . . . . . . . . . . . . . . 8 61 5.2.2. IP Tunneled over MPLS . . . . . . . . . . . . . . . . 9 62 5.3. Onlink Attackers . . . . . . . . . . . . . . . . . . . . . 11 63 5.4. Fragmentation Considerations . . . . . . . . . . . . . . . 11 64 5.5. Multi-Hop Protocol Sessions . . . . . . . . . . . . . . . 12 65 6. Applicability Statement . . . . . . . . . . . . . . . . . . . 12 66 6.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 13 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 70 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 71 Appendix A. Multi-hop GTSM . . . . . . . . . . . . . . . . . . . 15 72 Appendix B. Changes Since RFC3682 . . . . . . . . . . . . . . . 15 73 Appendix C. Draft Changelog . . . . . . . . . . . . . . . . . . 15 74 Appendix C.1. Changes between -09 and -10 . . . . . . . . . . . . 15 75 Appendix C.2. Changes between -08 and -09 . . . . . . . . . . . . 16 76 Appendix C.3. Changes between -07 and -08 . . . . . . . . . . . . 16 77 Appendix C.4. Changes between -06 and -07 . . . . . . . . . . . . 16 78 Appendix C.5. Changes between -05 and -06 . . . . . . . . . . . . 17 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 80 Intellectual Property and Copyright Statements . . . . . . . . . . 18 82 1. Introduction 84 The Generalized TTL Security Mechanism (GTSM) is designed to protect 85 a router's IP based control plane from CPU-utilization based attacks. 86 In particular, while cryptographic techniques can protect the router- 87 based infrastructure (e.g., BGP [RFC4271], [RFC4272]) from a wide 88 variety of attacks, many attacks based on CPU overload can be 89 prevented by the simple mechanism described in this document. Note 90 that the same technique protects against other scarce-resource 91 attacks involving a router's CPU, such as attacks against processor- 92 line card bandwidth. 94 GTSM is based on the fact that the vast majority of protocol peerings 95 are established between routers that are adjacent. Thus most 96 protocol peerings are either directly between connected interfaces or 97 at the worst case, are between loopback and loopback, with static 98 routes to loopbacks. Since TTL spoofing is considered nearly 99 impossible, a mechanism based on an expected TTL value can provide a 100 simple and reasonably robust defense from infrastructure attacks 101 based on forged protocol packets from outside the network. Note, 102 however, that GTSM is not a substitute for authentication mechanisms. 103 In particular, it does not secure against insider on-the-wire 104 attacks, such as packet spoofing or replay. 106 Finally, the GTSM mechanism is equally applicable to both TTL (IPv4) 107 and Hop Limit (IPv6), and from the perspective of GTSM, TTL and Hop 108 Limit have identical semantics. As a result, in the remainder of 109 this document the term "TTL" is used to refer to both TTL or Hop 110 Limit (as appropriate). 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 2. Assumptions Underlying GTSM 118 GTSM is predicated upon the following assumptions: 120 1. The vast majority of protocol peerings are between adjacent 121 routers. 123 2. Service providers may or may not configure strict ingress 124 filtering [RFC3704] on non-trusted links. If maximal protection 125 is desired, such filtering is necessary as described in 126 Section 2.2. 128 3. Use of GTSM is OPTIONAL, and can be configured on a per-peer 129 (group) basis. 131 4. The peer routers both implement GTSM. 133 5. The router supports a method to use separate resource pools 134 (e.g., queues, processing quotas) for differently classified 135 traffic. 137 Note that this document does not prescribe further restrictions that 138 a router may apply to the packets not matching the GTSM filtering 139 rules, such as dropping packets that do not match any configured 140 protocol session and rate-limiting the rest. This document also does 141 not suggest the actual means of resource separation, as those are 142 hardware and implementation-specific. 144 The possibility of denial-of-service (DoS) attack prevention, 145 however, is based on the assumption that classification of packets 146 and separation of their paths are done before they go through a 147 scarce resource in the system. In practice, this means that, the 148 closer GTSM processing is done to the line-rate hardware, the more 149 resistant the system is to the DoS attacks. 151 2.1. GTSM Negotiation 153 This document assumes that, when used with existing protocols, GTSM 154 will be manually configured between protocol peers. That is, no 155 automatic GTSM capability negotiation, such as is provided by RFC 156 3392 [RFC3392] is assumed or defined. 158 If a new protocol is designed with built-in GTSM support, then it is 159 recommended that procedures are always used for sending and 160 validating received protocol packets (GTSM is always on, see for 161 example [RFC2461]). If, however, dynamic negotiation of GTSM support 162 is necessary, protocol messages used for such negotiation MUST be 163 authenticated using other security mechanisms to prevent DoS attacks. 165 Also note that this specification does not offer a generic GTSM 166 capability negotiation mechanism, so messages of the protocol 167 augmented with the GTSM behavior will need to be used if dynamic 168 negotiation is deemed necessary. 170 2.2. Assumptions on Attack Sophistication 172 Throughout this document, we assume that potential attackers have 173 evolved in both sophistication and access to the point that they can 174 send control traffic to a protocol session, and that this traffic 175 appears to be valid control traffic (i.e., has the source/destination 176 of configured peer routers). 178 We also assume that each router in the path between the attacker and 179 the victim protocol speaker decrements TTL properly (clearly, if 180 either the path or the adjacent peer is compromised, then there are 181 worse problems to worry about). 183 For maximal protection, ingress filtering should be applied before 184 the packet goes through the scarce resource. Otherwise an attacker 185 directly connected to one interface could disturb a GTSM-protected 186 session on the same or another interface. Interfaces which aren't 187 configured with this filtering (e.g., backbone links) are assumed to 188 not have such attackers (i.e., are trusted). 190 As a specific instance of such interfaces, we assume that tunnels are 191 not a back-door for allowing TTL-spoofing on protocol packets for a 192 GTSM-protected peering session with a directly connected neighbor. 193 We assume that: 1) there are no tunneled packets terminating on the 194 router, 2) tunnels terminating on the router are assumed to be secure 195 and endpoints are trusted, 3) tunnel decapsulation includes source 196 address spoofing prevention [RFC3704], or 4) the GTSM-enabled session 197 does not allow protocol packets coming from a tunnel. 199 Since the vast majority of peerings are between adjacent routers, we 200 can set the TTL on the protocol packets to 255 (the maximum possible 201 for IP) and then reject any protocol packets that come in from 202 configured peers which do NOT have an inbound TTL of 255. 204 GTSM can be disabled for applications such as route-servers and other 205 multi-hop peerings. In the event that an attack comes in from a 206 compromised multi-hop peering, that peering can be shut down. 208 3. GTSM Procedure 210 If GTSM is not built into the protocol and is used as an additional 211 feature (e.g., for BGP, LDP, or MSDP), it SHOULD NOT be enabled by 212 default in order to be backward-compatible with the unmodified 213 protocol. However, if the protocol defines a built-in dynamic 214 capability negotiation for GTSM, a protocol peer MAY suggest the use 215 of GTSM provided that GTSM would only be enabled if both peers agree 216 to use it. 218 If GTSM is enabled for a protocol session, the following steps are 219 added to the IP packet sending and reception procedures: 221 Sending protocol packets: 223 The TTL field in all IP packets used for transmission of 224 messages associated with GTSM-enabled protocol sessions MUST be 225 set to 255. This also applies to the related ICMP error 226 handling messages. 228 On some architectures, the TTL of control plane originated 229 traffic is under some configurations decremented in the 230 forwarding plane. The TTL of GTSM-enabled sessions MUST NOT be 231 decremented. 233 Receiving protocol packets: 235 The GTSM packet identification step associates each received 236 packet addressed to the router's control plane with one of the 237 following three trustworthiness categories: 239 + Unknown: these are packets that cannot be associated with 240 any registered GTSM-enabled session, and hence GTSM cannot 241 make any judgment on the level of risk associated with them. 243 + Trusted: these are packets that have been identified as 244 belonging to one of the GTSM-enabled sessions, and their TTL 245 values are within the expected range. 247 + Dangerous: these are packets that have been identified as 248 belonging to one of the GTSM-enabled sessions, but their TTL 249 values are NOT within the expected range, and hence GTSM 250 believes there is a risk that the packets have been spoofed. 252 The exact policies applied to packets of different 253 classifications are not postulated in this document and are 254 expected to be configurable. Configurability is likely 255 necessary in particular with the treatment of related messages 256 (ICMP errors). It should be noted that fragmentation may 257 restrict the amount of information available to the 258 classification. 260 However, by default, the implementations: 262 + SHOULD ensure that packets classified as Dangerous do not 263 compete for resources with packets classified as Trusted or 264 Unknown. 266 + MUST NOT drop (as part of GTSM processing) packets 267 classified as Trusted or Unknown. 269 + MAY drop packets classified as Dangerous. 271 4. Acknowledgments 273 The use of the TTL field to protect BGP originated with many 274 different people, including Paul Traina and Jon Stewart. Ryan 275 McDowell also suggested a similar idea. Steve Bellovin, Jay 276 Borkenhagen, Randy Bush, Alfred Hoenes, Vern Paxon, Robert Raszuk and 277 Alex Zinin also provided useful feedback on earlier versions of this 278 document. David Ward provided insight on the generalization of the 279 original BGP-specific idea. Alex Zinin, Alia Atlas, and John Scudder 280 provided significant amount of feedback for the newer versions of the 281 document. During and after the IETF Last Call, Francis Dupont, Sam 282 Hartman, Lars Eggert, and Ross Callon. 284 5. Security Considerations 286 GTSM is a simple procedure that protects single hop protocol 287 sessions, except in those cases in which the peer has been 288 compromised. In particular, it does not protect against the wide 289 range of on-the-wire attacks; protection from these attacks requires 290 more rigorous security mechanisms. 292 5.1. TTL (Hop Limit) Spoofing 294 The approach described here is based on the observation that a TTL 295 (or Hop Limit) value of 255 is non-trivial to spoof, since as the 296 packet passes through routers towards the destination, the TTL is 297 decremented by one per router. As a result, when a router receives a 298 packet, it may not be able to determine if the packet's IP address is 299 valid, but it can determine how many router hops away it is (again, 300 assuming none of the routers in the path are compromised in such a 301 way that they would reset the packet's TTL). 303 Note, however, that while engineering a packet's TTL such that it has 304 a particular value when sourced from an arbitrary location is 305 difficult (but not impossible), engineering a TTL value of 255 from 306 non-directly connected locations is not possible (again, assuming 307 none of the directly connected neighbors are compromised, the packet 308 has not been tunneled to the decapsulator, and the intervening 309 routers are operating in accordance with RFC 791 [RFC0791]). 311 5.2. Tunneled Packets 313 The security of any tunneling technique depends heavily on 314 authentication at the tunnel endpoints, as well as how the tunneled 315 packets are protected in flight. Such mechanisms are, however, 316 beyond the scope of this memo. 318 An exception to the observation that a packet with TTL of 255 is 319 difficult to spoof may occur when a protocol packet is tunneled and 320 the tunnel is not integrity-protected (i.e., the lower layer is 321 compromised). 323 When the protocol packet is tunneled directly to the protocol peer 324 (the protocol peer is the decapsulator), the GTSM provides some 325 limited added protection as the security depends entirely on the 326 integrity of the tunnel. 328 For protocol adjacencies over a tunnel, if the tunnel itself is 329 deemed secure (e.g., the underlying infrastructure is deemed secure, 330 and the tunnel offers degrees of protection against spoofing such as 331 keys or cryptographic security), the GTSM can serve as a check that 332 the protocol packet did not originate beyond the head-end of the 333 tunnel. In addition, if the protocol peer can receive packets for 334 the GTSM-protected protocol session from outside the tunnel, the GTSM 335 can help thwart attacks from beyond the adjacent router. 337 When the tunnel tail-end decapsulates the protocol packet and then 338 IP-forwards the packet to a directly connected protocol peer, TTL is 339 decremented as described below. This means that the tunnel 340 decapsulator is the penultimate node from the GTSM-protected protocol 341 peer's perspective. As a result, the GTSM check protects from 342 attackers encapsulating packets to your peers. However, specific 343 cases arise when the connection from the tunnel decapsulator node to 344 the protocol peer is not an IP forwarding hop, where TTL-decrementing 345 does not happen (e.g., layer-2 tunneling, bridging, etc). In the 346 IPsec architecture [RFC4301], another example is the use of Bump-in- 347 the-Wire (BITW) [BITW]. 349 5.2.1. IP Tunneled over IP 351 Protocol packets may be tunneled over IP directly to a protocol peer, 352 or to a decapsulator (tunnel endpoint) that then forwards the packet 353 to a directly connected protocol peer. Examples of tunneling IP over 354 IP include IP-in-IP [RFC2003], GRE [RFC2784], or various forms of 355 IPv6-in-IPv4 (e.g., [RFC4213]). These cases are depicted below. 357 Peer router ---------- Tunnel endpoint router and peer 358 TTL=255 [tunnel] [TTL=255 at ingress] 359 [TTL=255 at processing] 361 Peer router -------- Tunnel endpoint router ----- On-link peer 362 TTL=255 [tunnel] [TTL=255 at ingress] [TTL=254 at ingress] 363 [TTL=254 at egress] 365 In both cases, the encapsulator (origination tunnel endpoint) is the 366 (supposed) sending protocol peer. The TTL in the inner IP datagram 367 can be set to 255, since RFC 2003 specifies the following behavior: 369 When encapsulating a datagram, the TTL in the inner IP 370 header is decremented by one if the tunneling is being 371 done as part of forwarding the datagram; otherwise, the 372 inner header TTL is not changed during encapsulation. 374 In the first case, the encapsulated packet is tunneled directly to 375 the protocol peer (also a tunnel endpoint), and therefore the 376 encapsulated packet's TTL can be received by the protocol peer with 377 an arbitrary value, including 255. 379 In the second case, the encapsulated packet is tunneled to a 380 decapsulator (tunnel endpoint) which then forwards it to a directly 381 connected protocol peer. For IP-in-IP tunnels, RFC 2003 specifies 382 the following decapsulator behavior: 384 The TTL in the inner IP header is not changed when decapsulating. 385 If, after decapsulation, the inner datagram has TTL = 0, the 386 decapsulator MUST discard the datagram. If, after decapsulation, 387 the decapsulator forwards the datagram to one of its network 388 interfaces, it will decrement the TTL as a result of doing normal 389 IP forwarding. See also Section 4.4. 391 And similarly, for GRE tunnels, RFC 2784 specifies the following 392 decapsulator behavior: 394 When a tunnel endpoint decapsulates a GRE packet which has an IPv4 395 packet as the payload, the destination address in the IPv4 payload 396 packet header MUST be used to forward the packet and the TTL of 397 the payload packet MUST be decremented. 399 Hence the inner IP packet header's TTL, as seen by the decapsulator, 400 can be set to an arbitrary value (in particular, 255). If the 401 decapsulator is also the protocol peer, it is possible to deliver the 402 protocol packet to it with a TTL of 255 (first case). On the other 403 hand, if the decapsulator needs to forward the protocol packet to a 404 directly connected protocol peer, the TTL will be decremented (second 405 case). 407 5.2.2. IP Tunneled over MPLS 409 Protocol packets may also be tunneled over MPLS Label Switched Paths 410 (LSPs) to a protocol peer. The following diagram depicts the 411 topology. 413 Peer router -------- LSP Termination router and peer 414 TTL=255 MPLS LSP [TTL=x at ingress] 416 MPLS LSPs can operate in Uniform or Pipe tunneling models. The TTL 417 handling for these models is described in RFC 3443 [RFC3443] that 418 updates RFC 3032 [RFC3032] in regards to TTL processing in MPLS 419 networks. RFC 3443 specifies the TTL processing in both Uniform and 420 Pipe Models, which in turn can used with or without penultimate hop 421 popping (PHP). The TTL processing in these cases results in 422 different behaviors, and therefore are analyzed separately. Please 423 refer to Section 3.1 through Section 3.3 of RFC 3443. 425 The main difference from a TTL processing perspective between Uniform 426 and Pipe Models at the LSP termination node resides in how the 427 incoming TTL (iTTL) is determined. The tunneling model determines 428 the iTTL: For Uniform Model LSPs, the iTTL is the value of the TTL 429 field from the popped MPLS header (encapsulating header), whereas for 430 Pipe Model LSPs, the iTTL is the value of the TTL field from the 431 exposed header (encapsulated header). 433 For Uniform Model LSPs, RFC 3443 states that at ingress: 435 For each pushed Uniform Model label, the TTL is copied from the 436 label/IP-packet immediately underneath it. 438 From this point, the inner TTL (TTL of the tunneled IP datagram) 439 represents non-meaningful information, and at the egress node or 440 during PHP, the ingress TTL (iTTL) is equal to the TTL of the popped 441 MPLS header (see Section 3.1 of RFC 3443). In consequence, for 442 Uniform Model LSPs of more than one hop, the TTL at ingress (iTTL) 443 will be less than 255 (x <= 254), and as a result the check described 444 in Section 3 of this document will fail. 446 The TTL treatment is identical between Short Pipe Model LSPs without 447 PHP and Pipe Model LSPs (without PHP only). For these cases, RFC 448 3443 states that: 450 For each pushed Pipe Model or Short Pipe Model label, the TTL 451 field is set to a value configured by the network operator. In 452 most implementations, this value is set to 255 by default. 454 In these models, the forwarding treatment at egress is based on the 455 tunneled packet as opposed to the encapsulation packet. The ingress 456 TTL (iTTL) is the value of the TTL field of the header that is 457 exposed, that is the tunneled IP datagram's TTL. The protocol 458 packet's TTL as seen by the LSP termination can therefore be set to 459 an arbitrary value (including 255). If the LSP termination router is 460 also the protocol peer, it is possible to deliver the protocol packet 461 with a TTL of 255 (x = 255). 463 Finally, for Short Pipe Model LSPs with PHP, the TTL of the tunneled 464 packet is unchanged after the PHP operation. Therefore, the same 465 conclusions drawn regarding the Short Pipe Model LSPs without PHP and 466 Pipe Model LSPs (without PHP only) apply to this case. For Short 467 Pipe Model LSPs, the TTL at egress has the same value with or without 468 PHP. 470 In conclusion, GTSM-checks are possible for IP tunneled over Pipe 471 model LSPs, but not for IP tunneled over Uniform model LSPs. 472 Additionally, for all tunneling modes, if the LSP termination router 473 needs to forward the protocol packet to a directly connected protocol 474 peer, it is not possible to deliver the protocol packet to the 475 protocol peer with a TTL of 255. If the packet is further forwarded, 476 the outgoing TTL (oTTL) is calculated by decrementing iTTL by one. 478 5.3. Onlink Attackers 480 As described in Section 2, an attacker directly connected to one 481 interface can disturb a GTSM-protected session on the same or another 482 interface (by spoofing a GTSM peer's address) unless ingress 483 filtering has been applied on the connecting interface. As a result, 484 interfaces which do not include such protection need to be trusted 485 not to originate attacks on the router. 487 5.4. Fragmentation Considerations 489 As already mentioned, fragmentation may restrict the amount of 490 information available for classification. Since non-initial IP 491 fragments do not contain Layer 4 information, it is highly likely 492 that they cannot be associated with a registered GTSM-enabled 493 session. Following the receiving protocol procedures described in 494 Section 3, non-initial IP fragments would likely be classified with 495 Unknown trustworthiness. And since the IP packet would need to be 496 reassembled in order to be processed, the end result is that the 497 initial-fragment of a GTSM-enabled session effectively receives the 498 treatment of an Unknown-trustworthiness packet, and the complete 499 reassembled packet receives the aggregate of the Unknowns. 501 In principle an implementation could remember the TTL of all received 502 fragments, and then when reassembling the packet verify that the TTL 503 of all fragments matches the required value for an associated GTSM- 504 enabled session. In the likely common case that the implementation 505 does not do this check on all fragments, then it is possible for a 506 legitimate first fragment (which passes the GTSM check) to be 507 combined with spoofed non-initial fragments, implying that the 508 integrity of the received packet is unknown and unprotected. If this 509 check is performed on all fragments at reassembly, and some fragment 510 does not pass the GTSM check for a GTSM-enabled session, the 511 reassembled packet is categorized as a Dangerous-trustworthiness 512 packet and receives the corresponding treatment. 514 Further, reassembly requires to wait for all the fragments and 515 therefore likely invalidates or weakens the fifth assumption 516 presented in Section 2: it may not be possible to classify non- 517 initial fragments before going through a scarce resource in the 518 system, when fragments need to be buffered for reassembly and later 519 processed by a CPU. That is, when classification cannot be done with 520 the required granularity, non-initial fragments of GTSM-enabled 521 session packets would not use different resource pools. 523 Consequently, to get practical protection from fragment attacks, 524 operators may need to rate-limit or discard all received fragments. 525 As such, it is highly RECOMMENDED for GTSM-protected protocols to 526 avoid fragmentation and reassembly by manual MTU tuning, using 527 adaptive measures such as Path MTU Discovery (PMTUD) or any other 528 available method [RFC1191], [RFC1981], [RFC4821]. 530 5.5. Multi-Hop Protocol Sessions 532 GTSM could possibly offer some small though difficult to quantify 533 degree of protection when used with multi-hop protocol sessions (see 534 Appendix A). In order to avoid having to quantify the degree of 535 protection and the resulting applicability of multi-hop, we only 536 describe the single-hop case because its security properties are 537 clearer. 539 6. Applicability Statement 541 GTSM is only applicable to environments with inherently limited 542 topologies (and is most effective in those cases where protocol peers 543 are directly connected). In particular, its application should be 544 limited to those cases in which protocol peers are directly 545 connected. 547 GTSM will not protect against attackers who are as close to the 548 protected station as its legitimate peer. For example, if the 549 legitimate peer is one hop away, GTSM will not protect from attacks 550 from directly connected devices on the same interface (see 551 Section 2.2 for more). 553 Experimentation on GTSM's applicability and security properties is 554 needed in multi-hop scenarios. The multi-hop scenarios where GTSM 555 might be applicable is expected to have the following 556 characteristics: the topology between peers is fairly static and well 557 known, and in which the intervening network (between the peers) is 558 trusted. 560 6.1. Backwards Compatibility 562 RFC 3682 [RFC3682] did not specify how to handle "related messages" 563 (ICMP errors). This specification mandates setting and verifying 564 TTL=255 of those as well as the main protocol packets. 566 Setting TTL=255 in related messages does not cause issues for RFC 567 3682 implementations. 569 Requiring TTL=255 in related messages may have impact with RFC 3682 570 implementations, depending on which default TTL the implementation 571 uses for originated packets; some implementations are known to use 572 255, while 64 or other values are also used. Related messages from 573 the latter category of RFC 3682 implementations would be classified 574 as Dangerous and treated as described in Section 3. This is not 575 believed to be a significant problem because protocols do not depend 576 on related messages (e.g., typically having a protocol exchange for 577 closing the session instead of doing a TCP-RST), and indeed the 578 delivery of related messages is not reliable. As such, related 579 messages typically provide an optimization to shorten a protocol 580 keepalive timeout. Regardless of these issues, given that related 581 messages provide a significant attack vector to e.g., reset protocol 582 sessions, making this further restriction seems sensible. 584 7. IANA Considerations 586 This document requires no action from IANA. 588 8. References 590 8.1. Normative References 592 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 593 September 1981. 595 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 596 October 1996. 598 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 599 Requirement Levels", BCP 14, RFC 2119, March 1997. 601 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 602 Discovery for IP Version 6 (IPv6)", RFC 2461, 603 December 1998. 605 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 606 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 607 March 2000. 609 [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement 610 with BGP-4", RFC 3392, November 2002. 612 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 613 in Multi-Protocol Label Switching (MPLS) Networks", 614 RFC 3443, January 2003. 616 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 617 for IPv6 Hosts and Routers", RFC 4213, October 2005. 619 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 620 Protocol 4 (BGP-4)", RFC 4271, January 2006. 622 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 623 Internet Protocol", RFC 4301, December 2005. 625 8.2. Informative References 627 [BITW] "Thread: 'IP-in-IP, TTL decrementing when forwarding and 628 BITW' on int-area list, Message-ID: 629 ", 630 June 2006, . 633 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 634 November 1990. 636 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 637 for IP version 6", RFC 1981, August 1996. 639 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 640 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 641 Encoding", RFC 3032, January 2001. 643 [RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL 644 Security Mechanism (GTSM)", RFC 3682, February 2004. 646 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 647 Networks", BCP 84, RFC 3704, March 2004. 649 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 650 RFC 4272, January 2006. 652 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 653 Discovery", RFC 4821, March 2007. 655 Appendix A. Multi-hop GTSM 657 NOTE: This is a non-normative part of the specification. 659 The main applicability of GTSM is for directly connected peers. GTSM 660 could be used for non-directly connected sessions as well, where the 661 recipient would check that the TTL is within a configured number of 662 hops from 255 (e.g., check that packets have 254 or 255). As such 663 deployment is expected to have a more limited applicability and 664 different security implications, it is not specified in this 665 document. 667 Appendix B. Changes Since RFC3682 669 o Bring the work on the Standards Track (RFC 3682 was Experimental). 671 o New text on GTSM applicability and use in new and existing 672 protocols. 674 o Restrict the scope to not specify multi-hop scenarios. 676 o Explicitly require that related messages (ICMP errors) must also 677 be sent and checked to have TTL=255. See Section 6.1 for 678 discussion on backwards compatibility. 680 o Clarifications relating to fragmentation, security with tunneling, 681 and implications of ingress filtering. 683 o A significant number of editorial improvements and clarifications. 685 Appendix C. Draft Changelog 687 NOTE to the RFC-editor: please remove this section before 688 publication. 690 Appendix C.1. Changes between -09 and -10 692 o Editorial updates from IETF LC and IESG review. 694 o Clarify fragmentation and integrity issues, from Sam Hartman. 696 o Repeat the hop limit's protection implication in Applicability 697 Statement (Ron Bonica). 699 o Remove "TCP RSTs" from "related messages" examples (Lars Eggert). 701 o Only define ICMP errors as related messages (Ross Callon). 703 Appendix C.2. Changes between -08 and -09 705 o Clarify that GTSM may be enabled on existing protocols if the 706 protocols include a capability negotiation feature and both 707 parties support GTSM. 709 o Editorial updates. 711 Appendix C.3. Changes between -07 and -08 713 o Describe the assumption of ingress filtering to protect against 714 on-link attacks. 716 o Rewrite the IP over MPLS section based on the new MPLS TTL 717 handling procedure (from Carlos Pignataro) to get the details of 718 new MPLS architecture right. 720 o Rephrase IP over IP tunneling section a bit, to make distinction 721 between encapsulation and decapsulation behavior clearer. 723 o Make it clearer in the tunneling section that unless the tunnel 724 peer is also the protocol peer, GTSM should be able to offer 725 protection. 727 o Describe better the applicability of GTSM when tunneling. 729 o Rephrase Multi-hop GTSM section to mainly refer to the difficult- 730 to-quantify security properties as a reason for exclusion at this 731 point. 733 o Some editorial updates. 735 Appendix C.4. Changes between -06 and -07 737 o Be more reserved about multi-hop security properties in section 738 'Multi-Hop Protocol Sessions'. 740 o Clarify IP-in-IP tunnel decapsulation/forwarding as decrementing 741 TTL. 743 o Add text on related messages backwards compatibility. 745 o Editorial updates. 747 Appendix C.5. Changes between -05 and -06 749 o Clarify the assumptions wrt. resource separation and protection 750 based on comments from Alex Zinin. 752 o Rewrite the GTSM procedure based on text from Alex Zinin. 754 o Reduce TrustRadius and multi-hop scenarios to a mention in an 755 Appendix. 757 o Describe TCP-RST, ICMP error and "related messages" handling. 759 o Update the tunneling security considerations text. 761 o Editorial updates (e.g., shortening the abstract). 763 Authors' Addresses 765 Vijay Gill 767 Email: vijay@umbc.edu 769 John Heasley 771 Email: heas@shrubbery.net 773 David Meyer 775 Email: dmm@1-4-5.net 777 Pekka Savola (editor) 778 Espoo 779 Finland 781 Email: psavola@funet.fi 783 Carlos Pignataro 785 Email: cpignata@cisco.com 787 Full Copyright Statement 789 Copyright (C) The IETF Trust (2007). 791 This document is subject to the rights, licenses and restrictions 792 contained in BCP 78, and except as set forth therein, the authors 793 retain all their rights. 795 This document and the information contained herein are provided on an 796 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 797 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 798 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 799 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 800 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 801 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 803 Intellectual Property 805 The IETF takes no position regarding the validity or scope of any 806 Intellectual Property Rights or other rights that might be claimed to 807 pertain to the implementation or use of the technology described in 808 this document or the extent to which any license under such rights 809 might or might not be available; nor does it represent that it has 810 made any independent effort to identify any such rights. Information 811 on the procedures with respect to rights in RFC documents can be 812 found in BCP 78 and BCP 79. 814 Copies of IPR disclosures made to the IETF Secretariat and any 815 assurances of licenses to be made available, or the result of an 816 attempt made to obtain a general license or permission for the use of 817 such proprietary rights by implementers or users of this 818 specification can be obtained from the IETF on-line IPR repository at 819 http://www.ietf.org/ipr. 821 The IETF invites any interested party to bring to its attention any 822 copyrights, patents or patent applications, or other proprietary 823 rights that may cover technology that may be required to implement 824 this standard. Please address the information to the IETF at 825 ietf-ipr@ietf.org. 827 Acknowledgment 829 Funding for the RFC Editor function is provided by the IETF 830 Administrative Support Activity (IASA).