idnits 2.17.1 draft-ietf-rtgwg-rfc3682bis-08.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 738. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 749. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 756. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 762. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (December 13, 2006) is 6337 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) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 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: June 16, 2007 C. Pignataro 7 December 13, 2006 9 The Generalized TTL Security Mechanism (GTSM) 10 draft-ietf-rtgwg-rfc3682bis-08.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 June 16, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2006). 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 RFC 3682. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Assumptions Underlying GTSM . . . . . . . . . . . . . . . . . 3 52 2.1. GTSM Negotiation . . . . . . . . . . . . . . . . . . . . . 4 53 2.2. Assumptions on Attack Sophistication . . . . . . . . . . . 4 54 3. GTSM Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 57 5.1. TTL (Hop Limit) Spoofing . . . . . . . . . . . . . . . . . 7 58 5.2. Tunneled Packets . . . . . . . . . . . . . . . . . . . . . 7 59 5.2.1. IP Tunneled over IP . . . . . . . . . . . . . . . . . 8 60 5.2.2. IP Tunneled over MPLS . . . . . . . . . . . . . . . . 9 61 5.3. Onlink Attackers . . . . . . . . . . . . . . . . . . . . . 11 62 5.4. Fragmentation Considerations . . . . . . . . . . . . . . . 11 63 5.5. Multi-Hop Protocol Sessions . . . . . . . . . . . . . . . 12 64 6. Applicability Statement . . . . . . . . . . . . . . . . . . . 12 65 6.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 12 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 70 Appendix A. Multi-hop GTSM . . . . . . . . . . . . . . . . . . . 14 71 Appendix B. Changes Since RFC3682 . . . . . . . . . . . . . . . 14 72 Appendix C. Draft Changelog . . . . . . . . . . . . . . . . . . 14 73 Appendix C.1. Changes between -07 and -08 . . . . . . . . . . . . 15 74 Appendix C.2. Changes between -06 and -07 . . . . . . . . . . . . 15 75 Appendix C.3. Changes between -05 and -06 . . . . . . . . . . . . 15 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 77 Intellectual Property and Copyright Statements . . . . . . . . . . 17 79 1. Introduction 81 The Generalized TTL Security Mechanism (GTSM) is designed to protect 82 a router's IP based control plane from CPU-utilization based attacks. 83 In particular, while cryptographic techniques can protect the router- 84 based infrastructure (e.g., BGP [RFC4271], [RFC4272]) from a wide 85 variety of attacks, many attacks based on CPU overload can be 86 prevented by the simple mechanism described in this document. Note 87 that the same technique protects against other scarce-resource 88 attacks involving a router's CPU, such as attacks against processor- 89 line card bandwidth. 91 GTSM is based on the fact that the vast majority of protocol peerings 92 are established between routers that are adjacent. Thus most 93 protocol peerings are either directly between connected interfaces or 94 at the worst case, are between loopback and loopback, with static 95 routes to loopbacks. Since TTL spoofing is considered nearly 96 impossible, a mechanism based on an expected TTL value can provide a 97 simple and reasonably robust defense from infrastructure attacks 98 based on forged protocol packets from outside the network. Note, 99 however, that GTSM is not a substitute for authentication mechanisms. 100 In particular, it does not secure against insider on-the-wire 101 attacks, such as packet spoofing or replay. 103 Finally, the GTSM mechanism is equally applicable to both TTL (IPv4) 104 and Hop Limit (IPv6), and from the perspective of GTSM, TTL and Hop 105 Limit have identical semantics. As a result, in the remainder of 106 this document the term "TTL" is used to refer to both TTL or Hop 107 Limit (as appropriate). 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 2. Assumptions Underlying GTSM 115 GTSM is predicated upon the following assumptions: 117 1. The vast majority of protocol peerings are between adjacent 118 routers. 120 2. Service providers may or may not configure strict ingress 121 filtering [RFC3704] on non-trusted links. If maximal protection 122 is desired, such filtering is necessary as described in 123 Section 2.2. 125 3. Use of GTSM is OPTIONAL, and can be configured on a per-peer 126 (group) basis. 128 4. The peer routers both implement GTSM. 130 5. The router supports a method to use separate resource pools 131 (e.g., queues, processing quotas) for differently classified 132 traffic. 134 Note that this document does not prescribe further restrictions that 135 a router may apply to the packets not matching the GTSM filtering 136 rules, such as dropping packets that do not match any configured 137 protocol session and rate-limiting the rest. This document also does 138 not suggest the actual means of resource separation, as those are 139 hardware and implementation-specific. 141 The possibility of denial-of-service (DoS) attack prevention, 142 however, is based on the assumption that packet classification and 143 separation of their paths is done before they go through a scarce 144 resource in the system. In practice, this means that, the closer 145 GTSM processing is done to the line-rate hardware, the more resistant 146 the system is to the DoS attacks. 148 2.1. GTSM Negotiation 150 This document assumes that, when used with existing protocols, GTSM 151 will be manually configured between protocol peers. That is, no 152 automatic GTSM capability negotiation, such as is provided by RFC 153 3392 [RFC3392] is assumed or defined. 155 If a new protocol is designed with built-in GTSM support, then it is 156 recommended that procedures are always used for sending and 157 validating received protocol packets (GTSM is always on, see for 158 example [RFC2461]). If, however, dynamic negotiation of GTSM support 159 is necessary, protocol messages used for such negotiation MUST be 160 authenticated using other security mechanisms to prevent DoS attacks. 162 Also note that this specification does not offer a generic GTSM 163 capability negotiation mechanism, so messages of the protocol 164 augmented with the GTSM behavior will need to be used if dynamic 165 negotiation is deemed necessary. 167 2.2. Assumptions on Attack Sophistication 169 Throughout this document, we assume that potential attackers have 170 evolved in both sophistication and access to the point that they can 171 send control traffic to a protocol session, and that this traffic 172 appears to be valid control traffic (i.e., has the source/destination 173 of configured peer routers). 175 We also assume that each router in the path between the attacker and 176 the victim protocol speaker decrements TTL properly (clearly, if 177 either the path or the adjacent peer is compromised, then there are 178 worse problems to worry about). 180 For maximal protection, ingress filtering should be applied before 181 the packet goes through the scarce resource. Otherwise an attacker 182 directly connected to one interface could disturb a GTSM-protected 183 session on the same or another interface. Interfaces which aren't 184 configured with this filtering (e.g., backbone links) are assumed to 185 not have such attackers (i.e., trusted). 187 As a specific instance of such interfaces, we assume that tunnels are 188 not a back-door for allowing TTL-spoofing on protocol packets for a 189 GTSM-protected peering session with a directly connected neighbor. 190 We assume that: 1) there are no tunneled packets terminating on the 191 router, 2) tunnels terminating on the router are assumed to be secure 192 and endpoints are trusted, 3) tunnel decapsulation includes source 193 address spoofing prevention [RFC3704], or 4) the GTSM-enabled session 194 does not allow protocol packets coming from a tunnel. 196 Since the vast majority of peerings are between adjacent routers, we 197 can set the TTL on the protocol packets to 255 (the maximum possible 198 for IP) and then reject any protocol packets that come in from 199 configured peers which do NOT have an inbound TTL of 255. 201 GTSM can be disabled for applications such as route-servers and other 202 multi-hop peerings. In the event that an attack comes in from a 203 compromised multi-hop peering, that peering can be shut down. 205 3. GTSM Procedure 207 If GTSM is not built into the protocol and used as an additional 208 feature (e.g., for BGP, LDP, or MSDP), it SHOULD NOT be enabled by 209 default in order to be backward-compatible with the unmodified 210 protocol. 212 If GTSM is enabled for a protocol session, the following steps are 213 added to the IP packet sending and reception procedures: 215 Sending protocol packets: 217 The TTL field in all IP packets used for transmission of 218 messages associated with GTSM-enabled protocol sessions MUST be 219 set to 255. This also applies to related error handling 220 messages associated with said session, such as TCP RSTs or ICMP 221 errors. 223 On some architectures, the TTL of control plane originated 224 traffic is under some configurations decremented in the 225 forwarding plane. The TTL of GTSM-enabled sessions MUST NOT be 226 decremented. 228 Receiving protocol packets: 230 The GTSM packet identification step associates each received 231 packet addressed to the router's control plane with one of the 232 following three trustworthiness categories: 234 + Unknown: these are packets that cannot be associated with 235 any registered GTSM-enabled session, and hence GTSM cannot 236 make any judgement on the level of risk associated with 237 them. 239 + Trusted: these are packets that have been identified as 240 belonging to one of the GTSM-enabled sessions, and their TTL 241 values are within the expected range. 243 + Dangerous: these are packets that have been identified as 244 belonging to one of the GTSM-enabled sessions, but their TTL 245 values are NOT within the expected range, and hence GTSM 246 believes there is a risk that the packets have been spoofed. 248 The exact policies applied to packets of different 249 classifications are not postulated in this document and are 250 expected to be configurable. Configurability is likely 251 necessary particular with the treatment of related messages 252 such as ICMP errors and TCP RSTs. It should be noted that 253 fragmentation may restrict the amount of information available 254 to the classification. 256 However, by default, the implementations: 258 + SHOULD ensure that packets classified as Dangerous do not 259 compete for resources with packets classified as Trusted or 260 Unknown. 262 + MUST NOT drop (as part of GTSM processing) packets 263 classified as Trusted or Unknown. 265 + MAY drop packets classified as Dangerous. 267 4. Acknowledgments 269 The use of the TTL field to protect BGP originated with many 270 different people, including Paul Traina and Jon Stewart. Ryan 271 McDowell also suggested a similar idea. Steve Bellovin, Jay 272 Borkenhagen, Randy Bush, Alfred Hoenes, Vern Paxon, Robert Raszuk and 273 Alex Zinin also provided useful feedback on earlier versions of this 274 document. David Ward provided insight on the generalization of the 275 original BGP-specific idea. Alex Zinin, Alia Atlas, and John Scudder 276 provided significant amount of feedback for the newer versions of the 277 document. 279 5. Security Considerations 281 GTSM is a simple procedure that protects single hop protocol 282 sessions, except in those cases in which the peer has been 283 compromised. In particular, it does not protect against the wide 284 range of on-the-wire attacks; protection from these attacks requires 285 more rigorous security mechanisms. 287 5.1. TTL (Hop Limit) Spoofing 289 The approach described here is based on the observation that a TTL 290 (or Hop Limit) value of 255 is non-trivial to spoof, since as the 291 packet passes through routers towards the destination, the TTL is 292 decremented by one per router. As a result, when a router receives a 293 packet, it may not be able to determine if the packet's IP address is 294 valid, but it can determine how many router hops away it is (again, 295 assuming none of the routers in the path are compromised in such a 296 way that they would reset the packet's TTL). 298 Note, however, that while engineering a packet's TTL such that it has 299 a particular value when sourced from an arbitrary location is 300 difficult (but not impossible), engineering a TTL value of 255 from 301 non-directly connected locations is not possible (again, assuming 302 none of the directly connected neighbors are compromised, the packet 303 hasn't been tunneled to the decapsulator, and the intervening routers 304 are operating in accordance with RFC 791 [RFC0791]). 306 5.2. Tunneled Packets 308 The security of any tunneling technique depends heavily on 309 authentication at the tunnel endpoints, as well as how the tunneled 310 packets are protected in flight. Such mechanisms are, however, 311 beyond the scope of this memo. 313 An exception to the observation that a packet with TTL of 255 is 314 difficult to spoof may occur when a protocol packet is tunneled and 315 the tunnel is not integrity-protected (i.e., the lower layer is 316 compromised). 318 When the protocol packet is tunneled directly to the protocol peer 319 (the protocol peer is the decapsulator), the GTSM provides some 320 limited added protection as the security depends entirely on the 321 integrity of the tunnel. 323 For protocol adjacencies over a tunnel, if the tunnel itself is 324 deemed secure (e.g., the underlying infrastructure is deemed secure, 325 and the tunnel offers degrees of protection against spoofing such as 326 keys or cryptographic security), the GTSM can serve as a check that 327 the protocol packet did not originate beyond the head-end of the 328 tunnel. In addition, if the protocol peer can receive packets for 329 the GTSM-protected protocol session from outside the tunnel, the GTSM 330 can help thwart attacks from beyond the adjacent router. 332 When the tunnel tail-end decapsulates the protocol packet and then 333 IP-forwards the packet to a directly connected protocol peer, TTL is 334 decremented as described below. This means that the tunnel 335 decapsulator is the penultimate node from the GTSM-protected protocol 336 peer's perspective. As a result, the GTSM check protects from 337 attackers encapsulating packets to your peers. However, specific 338 cases arise when the connection from the tunnel decapsulator node to 339 the protocol peer is not an IP forwarding hop, where TTL-decrementing 340 does not happen (e.g., layer-2 tunneling, bridging, etc). In the 341 IPsec architecture [RFC4301], another example is the use of Bump-in- 342 the-Wire (BITW) [BITW]. 344 5.2.1. IP Tunneled over IP 346 Protocol packets may be tunneled over IP directly to a protocol peer, 347 or to a decapsulator (tunnel endpoint) that then forwards the packet 348 to a directly connected protocol peer. Examples of tunneling IP over 349 IP include IP-in-IP [RFC2003], GRE [RFC2784], or various forms of 350 IPv6-in-IPv4 (e.g., [RFC4213]). These cases are depicted below. 352 Peer router ---------- Tunnel endpoint router and peer 353 TTL=255 [tunnel] [TTL=255 at ingress] 354 [TTL=255 at processing] 356 Peer router -------- Tunnel endpoint router ----- On-link peer 357 TTL=255 [tunnel] [TTL=255 at ingress] [TTL=254 at ingress] 358 [TTL=254 at egress] 360 In both cases, the encapsulator (origination tunnel endpoint) is the 361 (supposed) sending protocol peer. The TTL in the inner IP datagram 362 can be set to 255, since RFC 2003 specifies the following behavior: 364 When encapsulating a datagram, the TTL in the inner IP 365 header is decremented by one if the tunneling is being 366 done as part of forwarding the datagram; otherwise, the 367 inner header TTL is not changed during encapsulation. 369 In the first case, the encapsulated packet is tunneled directly to 370 the protocol peer (also a tunnel endpoint), and therefore the 371 encapsulated packet's TTL can be received by the protocol peer with 372 an arbitrary value, including 255. 374 In the second case, the encapsulated packet is tunneled to a 375 decapsulator (tunnel endpoint) which then forwards it to a directly 376 connected protocol peer. For IP-in-IP tunnels, RFC 2003 specifies 377 the following decapsulator behaviour: 379 The TTL in the inner IP header is not changed when decapsulating. 380 If, after decapsulation, the inner datagram has TTL = 0, the 381 decapsulator MUST discard the datagram. If, after decapsulation, 382 the decapsulator forwards the datagram to one of its network 383 interfaces, it will decrement the TTL as a result of doing normal 384 IP forwarding. See also Section 4.4. 386 And similarly, for GRE tunnels, RFC 2784 specifies the following 387 decapsulator behaviour: 389 When a tunnel endpoint decapsulates a GRE packet which has an IPv4 390 packet as the payload, the destination address in the IPv4 payload 391 packet header MUST be used to forward the packet and the TTL of 392 the payload packet MUST be decremented. 394 Hence the inner IP packet header's TTL, as seen by the decapsulator, 395 can be set to an arbitrary value (in particular, 255). If the 396 decapsulator is also the protocol peer, it is possible to deliver the 397 protocol packet to it with a TTL of 255 (first case). On the other 398 hand, if the decapsulator needs to forward the protocol packet to a 399 directly connected protocol peer, the TTL will be decremented (second 400 case). 402 5.2.2. IP Tunneled over MPLS 404 Protocol packets may also be tunneled over MPLS Label Switched Paths 405 (LSPs) to a protocol peer. The following diagram depicts the 406 topology. 408 Peer router -------- LSP Termination router and peer 409 TTL=255 MPLS LSP [TTL=x at ingress] 411 MPLS LSPs can operate in Uniform or Pipe tunneling models. The TTL 412 handling for these models is described in RFC 3443 [RFC3443] that 413 updates RFC 3032 [RFC3032] in regards to TTL processing in MPLS 414 networks. RFC 3443 specifies the TTL processing in both Uniform and 415 Pipe Models, which in turn can used with or without penultimate hop 416 popping (PHP). The TTL processing in these cases results in 417 different behaviors, and therefore are analyzed separately. Please 418 refer to Section 3.1 through Section 3.3 of RFC 3443. 420 The main difference from a TTL processing perspective between Uniform 421 and Pipe Models at the LSP termination node resides in how the 422 incoming TTL (iTTL) is determined. The tunneling model determines 423 the iTTL: For Uniform Model LSPs, the iTTL is the value of the TTL 424 field from the popped MPLS header (encapsulating header), whereas for 425 Pipe Model LSPs, the iTTL is the value of the TTL field from the 426 exposed header (encapsulated header). 428 For Uniform Model LSPs, RFC 3443 states that at ingress: 430 For each pushed Uniform Model label, the TTL is copied from the 431 label/IP-packet immediately underneath it. 433 From this point, the inner TTL (TTL of the tunneled IP datagram) 434 represents non-meaningful information, and at the egress node or 435 during PHP, the ingress TTL (iTTL) is equal to the TTL of the popped 436 MPLS header (see Section 3.1 of RFC 3443). In consequence, for 437 Uniform Model LSPs of more than one hop, the TTL at ingress (iTTL) 438 will be less than 255 (x <= 254), and as a result the check described 439 in Section 3 of this document will fail. 441 The TTL treatment is identical between Short Pipe Model LSPs without 442 PHP and Pipe Model LSPs (without PHP only). For these cases, RFC 443 3443 states that: 445 For each pushed Pipe Model or Short Pipe Model label, the TTL 446 field is set to a value configured by the network operator. In 447 most implementations, this value is set to 255 by default. 449 In these models, the forwarding treatment at egress is based on the 450 tunneled packet as opposed to the encapsulation packet. The ingress 451 TTL (iTTL) is the value of the TTL field of the header that is 452 exposed, that is the tunneled IP datagram's TTL. The protocol 453 packet's TTL as seen be the LSP termination can therefore be set to 454 an arbitrary value (including 255). If the LSP termination router is 455 also the protocol peer, it is possible to deliver the protocol packet 456 with a TTL of 255 (x = 255). 458 Finally, for Short Pipe Model LSPs with PHP, the TTL of the tunneled 459 packet is unchanged after the PHP operation. Therefore, the same 460 conclusions drawn regarding the Short Pipe Model LSPs without PHP and 461 Pipe Model LSPs (without PHP only) apply to this case. For Short 462 Pipe Model LSPs, the TTL at egress has the same value with or without 463 PHP. 465 In conclusion, GTSM-checks are possible for IP tunneled over Pipe 466 model LSPs, but not for IP tunneled over Uniform model LSPs. 467 Additionally, for all tunneling modes, if the LSP termination router 468 needs to forward the protocol packet to a directly connected protocol 469 peer, it is not possible to deliver the protocol packet to the 470 protocol peer with a TTL of 255. If the packet is further forwarded, 471 the outgoing TTL (oTTL) is calculated by decrementing iTTL by one. 473 5.3. Onlink Attackers 475 As described in Section 2, an attacker directly connected to one 476 interface can disturb a GTSM-protected session on the same or another 477 interface (by spoofing a GTSM peer's address) unless ingress 478 filtering has been applied on the connecting interface. As a result, 479 interfaces which do not include such protection need to be trusted 480 not to originate attacks on the router. 482 5.4. Fragmentation Considerations 484 As already mentioned, fragmentation may restrict the amount of 485 information available for classification. Since non-initial IP 486 fragments do not contain Layer 4 information, it is highly likely 487 that they cannot be associated with a registered GTSM-enabled 488 session. Following the receiving protocol procedures described in 489 Section 3, non-initial IP fragments would likely be classified with 490 Unknown trustworthiness. And since the IP packet would need to be 491 reassembled in order to be processed, the end result is that the 492 initial-fragment of a GTSM-enabled session effectively receives the 493 treatment of an Unknown-trustworthiness packet, and the complete 494 reassembled packet receives the aggregate of the Unknowns. 496 Further, reassembly requires to wait for all the fragments and 497 therefore likely invalidates or weakens the fifth assumption 498 presented in Section 2: it may not be possible to classify non- 499 initial fragments before going through a scarce resource in the 500 system, when fragments need to be buffered for reassembly and later 501 processed by a CPU. That is, when classification cannot be done with 502 the required granularity, non-initial fragments of GTSM-enabled 503 session packets would not use different resource pools. 505 Consequently, to get practical protection from fragment attacks, 506 operators may need to rate-limit or discard all received fragments. 508 As such, it is highly recommended for GTSM-protected protocols to 509 avoid fragmentation and reassembly by manual MTU tuning, using 510 adaptive measures such as Path MTU Discovery (PMTUD), or any other 511 available method. 513 5.5. Multi-Hop Protocol Sessions 515 GTSM could possibly offer some small though difficult to quantify 516 degree of protection when used with multi-hop protocol sessions (see 517 Appendix A). In order to avoid having to quantify the degree of 518 protection and the resulting applicability of multi-hop, we only 519 describe the single-hop because its security properties are clearer. 521 6. Applicability Statement 523 GTSM is only applicable to environments with inherently limited 524 topologies (and is most effective in those cases where protocol peers 525 are directly connected). In particular, its application should be 526 limited to those cases in which protocol peers are directly 527 connected. 529 Experimentation on GTSM's applicability and security properties is 530 needed in multi-hop scenarios. The multi-hop scenarios where GTSM 531 might be applicable is expected to have the following 532 characteristics: the topology between peers is fairly static and well 533 known, and in which the intervening network (between the peers) is 534 trusted. 536 6.1. Backwards Compatibility 538 RFC 3682 did not specify how to handle "related messages" such as TCP 539 RSTs or ICMP errors. This specification mandates setting and 540 verifying TTL=255 of those as well as the main protocol packets. 542 Setting TTL=255 in related messages does not cause issues for RFC 543 3682 implementations. 545 Requiring TTL=255 in related messages may have impact with RFC 3682 546 implementations, depending on which default TTL the implementation 547 uses for originated packets; some implementations are known to use 548 255, while 64 or other values are also used. Related messages from 549 the latter category of RFC 3682 implementations would be classified 550 as Dangerous and treated as described in Section 3. This is not 551 believed to be a significant problem because protocols do not depend 552 on related messages (e.g., typically having a protocol exchange for 553 closing the session instead of doing a TCP-RST), and indeed the 554 delivery of related messages is not reliable. As such, related 555 messages typically provide an optimization to shorten a protocol 556 keepalive timeout. Regardless of these issues, given that related 557 messages provide a significant attack vector to e.g., reset protocol 558 sessions, making this further restriction seems sensible. 560 7. IANA Considerations 562 This document requires no action from IANA. 564 8. References 566 8.1. Normative References 568 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 569 September 1981. 571 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 572 October 1996. 574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", BCP 14, RFC 2119, March 1997. 577 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 578 Discovery for IP Version 6 (IPv6)", RFC 2461, 579 December 1998. 581 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 582 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 583 March 2000. 585 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 586 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 587 Encoding", RFC 3032, January 2001. 589 [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement 590 with BGP-4", RFC 3392, November 2002. 592 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 593 in Multi-Protocol Label Switching (MPLS) Networks", 594 RFC 3443, January 2003. 596 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 597 for IPv6 Hosts and Routers", RFC 4213, October 2005. 599 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 600 Protocol 4 (BGP-4)", RFC 4271, January 2006. 602 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 603 Internet Protocol", RFC 4301, December 2005. 605 8.2. Informative References 607 [BITW] "Thread: 'IP-in-IP, TTL decrementing when forwarding and 608 BITW' on int-area list, Message-ID: 609 ", 610 June 2006, . 613 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 614 Networks", BCP 84, RFC 3704, March 2004. 616 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 617 RFC 4272, January 2006. 619 Appendix A. Multi-hop GTSM 621 NOTE: This is a non-normative part of the specification. 623 The main applicability of GTSM is for directly connected peers. GTSM 624 could be used for non-directly connected sessions as well, where the 625 recipient would check that the TTL is within "TrustRadius" (e.g., 1) 626 of 255 instead of 255. As such deployment is expected to have a more 627 limited applicability and different security implications, it is not 628 specified in this document. 630 Appendix B. Changes Since RFC3682 632 o New text on GTSM applicability and use in new and existing 633 protocols. 635 o Explicitly require that related messages (e.g., TCP RSTs, ICMP 636 errors) must also be sent and checked to have TTL=255. See 637 Section 6.1 for discussion on backwards compatibility. 639 o Clarifications relating to security with tunneling. 641 o A significant number of editorial improvements and clarifications. 643 Appendix C. Draft Changelog 645 NOTE to the RFC-editor: please remove this section before 646 publication. 648 Appendix C.1. Changes between -07 and -08 650 o Describe the assumption of ingress filtering to protect against 651 on-link attacks. 653 o Rewrite the IP over MPLS section based on the new MPLS TTL 654 handling procedure (from Carlos Pignataro) to get the details of 655 new MPLS architecture right. 657 o Rephrase IP over IP tunneling section a bit, to make distinction 658 between encapsulation and decapsulation behaviour clearer. 660 o Make it clearer in the tunneling section that unless the tunnel 661 peer is also the protocol peer, GTSM should be able to offer 662 protection. 664 o Describe better the applicability of GTSM when tunneling. 666 o Rephrase Multi-hop GTSM section to mainly refer to the difficult- 667 to-quantify security properties as a reason for exclusion at this 668 point. 670 o Some editorial updates. 672 Appendix C.2. Changes between -06 and -07 674 o Be more reserved about multi-hop security properties in section 675 'Multi-Hop Protocol Sessions'. 677 o Clarify IP-in-IP tunnel decapsulation/forwarding as decrementing 678 TTL. 680 o Add text on related messages backwards compatibility. 682 o Editorial updates. 684 Appendix C.3. Changes between -05 and -06 686 o Clarify the assumptions wrt. resource separation and protection 687 based on comments from Alex Zinin. 689 o Rewrite the GTSM procedure based on text from Alex Zinin. 691 o Reduce TrustRadius and multi-hop scenarios to a mention in an 692 Appendix. 694 o Describe TCP-RST, ICMP error and "related messages" handling. 696 o Update the tunneling security considerations text. 698 o Editorial updates (e.g., shortening the abstract). 700 Authors' Addresses 702 Vijay Gill 704 Email: vijay@umbc.edu 706 John Heasley 708 Email: heas@shrubbery.net 710 David Meyer 712 Email: dmm@1-4-5.net 714 Pekka Savola (editor) 715 Espoo 716 Finland 718 Email: psavola@funet.fi 720 Carlos Pignataro 722 Email: cpignata@cisco.com 724 Full Copyright Statement 726 Copyright (C) The IETF Trust (2006). 728 This document is subject to the rights, licenses and restrictions 729 contained in BCP 78, and except as set forth therein, the authors 730 retain all their rights. 732 This document and the information contained herein are provided on an 733 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 734 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 735 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 736 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 737 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 738 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 740 Intellectual Property 742 The IETF takes no position regarding the validity or scope of any 743 Intellectual Property Rights or other rights that might be claimed to 744 pertain to the implementation or use of the technology described in 745 this document or the extent to which any license under such rights 746 might or might not be available; nor does it represent that it has 747 made any independent effort to identify any such rights. Information 748 on the procedures with respect to rights in RFC documents can be 749 found in BCP 78 and BCP 79. 751 Copies of IPR disclosures made to the IETF Secretariat and any 752 assurances of licenses to be made available, or the result of an 753 attempt made to obtain a general license or permission for the use of 754 such proprietary rights by implementers or users of this 755 specification can be obtained from the IETF on-line IPR repository at 756 http://www.ietf.org/ipr. 758 The IETF invites any interested party to bring to its attention any 759 copyrights, patents or patent applications, or other proprietary 760 rights that may cover technology that may be required to implement 761 this standard. Please address the information to the IETF at 762 ietf-ipr@ietf.org. 764 Acknowledgment 766 Funding for the RFC Editor function is provided by the IETF 767 Administrative Support Activity (IASA).