1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
|
<pre>Network Working Group V. Gill
Request for Comments: 5082 J. Heasley
Obsoletes: <a href="./rfc3682">3682</a> D. Meyer
Category: Standards Track P. Savola, Ed.
C. Pignataro
October 2007
<span class="h1">The Generalized TTL Security Mechanism (GTSM)</span>
Status of This Memo
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
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
connected link has been used in many recent protocols. This document
generalizes this technique. This document obsoletes Experimental <a href="./rfc3682">RFC</a>
<a href="./rfc3682">3682</a>.
<span class="grey">Gill, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5082">RFC 5082</a> GTSM October 2007</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Assumptions Underlying GTSM . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. GTSM Negotiation . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. Assumptions on Attack Sophistication . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. GTSM Procedure . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4">4</a>. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5">5</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.1">5.1</a>. TTL (Hop Limit) Spoofing . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5.2">5.2</a>. Tunneled Packets . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5.2.1">5.2.1</a>. IP Tunneled over IP . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5.2.2">5.2.2</a>. IP Tunneled over MPLS . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5.3">5.3</a>. Onlink Attackers . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-5.4">5.4</a>. Fragmentation Considerations . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-5.5">5.5</a>. Multi-Hop Protocol Sessions . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-6">6</a>. Applicability Statement . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-6.1">6.1</a>. Backwards Compatibility . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-7">7</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-7.1">7.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-7.2">7.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#appendix-A">Appendix A</a>. Multi-Hop GTSM . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#appendix-B">Appendix B</a>. Changes Since <a href="./rfc3682">RFC 3682</a> . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Generalized TTL Security Mechanism (GTSM) is designed to protect
a router's IP-based control plane from CPU-utilization based attacks.
In particular, while cryptographic techniques can protect the router-
based infrastructure (e.g., BGP [<a href="./rfc4271" title=""A Border Gateway Protocol 4 (BGP-4)"">RFC4271</a>], [<a href="./rfc4272" title=""BGP Security Vulnerabilities Analysis"">RFC4272</a>]) from a wide
variety of attacks, many attacks based on CPU overload can be
prevented by the simple mechanism described in this document. Note
that the same technique protects against other scarce-resource
attacks involving a router's CPU, such as attacks against processor-
line card bandwidth.
GTSM is based on the fact that the vast majority of protocol peerings
are established between routers that are adjacent. Thus, most
protocol peerings are either directly between connected interfaces
or, in the worst case, are between loopback and loopback, with static
routes to loopbacks. Since TTL spoofing is considered nearly
impossible, a mechanism based on an expected TTL value can provide a
simple and reasonably robust defense from infrastructure attacks
based on forged protocol packets from outside the network. Note,
however, that GTSM is not a substitute for authentication mechanisms.
In particular, it does not secure against insider on-the-wire
attacks, such as packet spoofing or replay.
<span class="grey">Gill, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5082">RFC 5082</a> GTSM October 2007</span>
Finally, the GTSM mechanism is equally applicable to both TTL (IPv4)
and Hop Limit (IPv6), and from the perspective of GTSM, TTL and Hop
Limit have identical semantics. As a result, in the remainder of
this document the term "TTL" is used to refer to both TTL or Hop
Limit (as appropriate).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Assumptions Underlying GTSM</span>
GTSM is predicated upon the following assumptions:
1. The vast majority of protocol peerings are between adjacent
routers.
2. Service providers may or may not configure strict ingress
filtering [<a href="./rfc3704" title=""Ingress Filtering for Multihomed Networks"">RFC3704</a>] on non-trusted links. If maximal protection
is desired, such filtering is necessary as described in
<a href="#section-2.2">Section 2.2</a>.
3. Use of GTSM is OPTIONAL, and can be configured on a per-peer
(group) basis.
4. The peer routers both implement GTSM.
5. The router supports a method to use separate resource pools
(e.g., queues, processing quotas) for differently classified
traffic.
Note that this document does not prescribe further restrictions that
a router may apply to packets not matching the GTSM filtering rules,
such as dropping packets that do not match any configured protocol
session and rate-limiting the rest. This document also does not
suggest the actual means of resource separation, as those are
hardware and implementation-specific.
However, the possibility of denial-of-service (DoS) attack prevention
is based on the assumption that classification of packets and
separation of their paths are done before the packets go through a
scarce resource in the system. In practice, the closer GTSM
processing is done to the line-rate hardware, the more resistant the
system is to DoS attacks.
<span class="grey">Gill, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5082">RFC 5082</a> GTSM October 2007</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. GTSM Negotiation</span>
This document assumes that, when used with existing protocols, GTSM
will be manually configured between protocol peers. That is, no
automatic GTSM capability negotiation, such as is provided by <a href="./rfc3392">RFC</a>
<a href="./rfc3392">3392</a> [<a href="./rfc3392" title=""Capabilities Advertisement with BGP-4"">RFC3392</a>], is assumed or defined.
If a new protocol is designed with built-in GTSM support, then it is
recommended that procedures are always used for sending and
validating received protocol packets (GTSM is always on, see for
example [<a href="./rfc2461" title=""Neighbor Discovery for IP Version 6 (IPv6)"">RFC2461</a>]). If, however, dynamic negotiation of GTSM support
is necessary, protocol messages used for such negotiation MUST be
authenticated using other security mechanisms to prevent DoS attacks.
Also note that this specification does not offer a generic GTSM
capability negotiation mechanism, so messages of the protocol
augmented with the GTSM behavior will need to be used if dynamic
negotiation is deemed necessary.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Assumptions on Attack Sophistication</span>
Throughout this document, we assume that potential attackers have
evolved in both sophistication and access to the point that they can
send control traffic to a protocol session, and that this traffic
appears to be valid control traffic (i.e., it has the source/
destination of configured peer routers).
We also assume that each router in the path between the attacker and
the victim protocol speaker decrements TTL properly (clearly, if
either the path or the adjacent peer is compromised, then there are
worse problems to worry about).
For maximal protection, ingress filtering should be applied before
the packet goes through the scarce resource. Otherwise an attacker
directly connected to one interface could disturb a GTSM-protected
session on the same or another interface. Interfaces that aren't
configured with this filtering (e.g., backbone links) are assumed to
not have such attackers (i.e., are trusted).
As a specific instance of such interfaces, we assume that tunnels are
not a back-door for allowing TTL-spoofing on protocol packets to a
GTSM-protected peering session with a directly connected neighbor.
We assume that: 1) there are no tunneled packets terminating on the
router, 2) tunnels terminating on the router are assumed to be secure
and endpoints are trusted, 3) tunnel decapsulation includes source
address spoofing prevention [<a href="./rfc3704" title=""Ingress Filtering for Multihomed Networks"">RFC3704</a>], or 4) the GTSM-enabled session
does not allow protocol packets coming from a tunnel.
<span class="grey">Gill, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5082">RFC 5082</a> GTSM October 2007</span>
Since the vast majority of peerings are between adjacent routers, we
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
configured peers that do NOT have an inbound TTL of 255.
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
compromised multi-hop peering, that peering can be shut down.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. GTSM Procedure</span>
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
default in order to remain backward-compatible with the unmodified
protocol. However, if the protocol defines a built-in dynamic
capability negotiation for GTSM, a protocol peer MAY suggest the use
of GTSM provided that GTSM would only be enabled if both peers agree
to use it.
If GTSM is enabled for a protocol session, the following steps are
added to the IP packet sending and reception procedures:
Sending protocol packets:
The TTL field in all IP packets used for transmission of
messages associated with GTSM-enabled protocol sessions MUST be
set to 255. This also applies to the related ICMP error
handling messages.
On some architectures, the TTL of control plane originated
traffic is under some configurations decremented in the
forwarding plane. The TTL of GTSM-enabled sessions MUST NOT be
decremented.
Receiving protocol packets:
The GTSM packet identification step associates each received
packet addressed to the router's control plane with one of the
following three trustworthiness categories:
+ Unknown: these are packets that cannot be associated with
any registered GTSM-enabled session, and hence GTSM cannot
make any judgment on the level of risk associated with them.
+ Trusted: these are packets that have been identified as
belonging to one of the GTSM-enabled sessions, and their TTL
values are within the expected range.
<span class="grey">Gill, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5082">RFC 5082</a> GTSM October 2007</span>
+ Dangerous: these are packets that have been identified as
belonging to one of the GTSM-enabled sessions, but their TTL
values are NOT within the expected range, and hence GTSM
believes there is a risk that these packets have been
spoofed.
The exact policies applied to packets of different
classifications are not postulated in this document and are
expected to be configurable. Configurability is likely
necessary in particular with the treatment of related messages
(ICMP errors). It should be noted that fragmentation may
restrict the amount of information available for
classification.
However, by default, the implementations:
+ SHOULD ensure that packets classified as Dangerous do not
compete for resources with packets classified as Trusted or
Unknown.
+ MUST NOT drop (as part of GTSM processing) packets
classified as Trusted or Unknown.
+ MAY drop packets classified as Dangerous.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Acknowledgments</span>
The use of the TTL field to protect BGP originated with many
different people, including Paul Traina and Jon Stewart. Ryan
McDowell also suggested a similar idea. Steve Bellovin, Jay
Borkenhagen, Randy Bush, Alfred Hoenes, Vern Paxon, Robert Raszuk,
and Alex Zinin also provided useful feedback on earlier versions of
this document. David Ward provided insight on the generalization of
the original BGP-specific idea. Alex Zinin, Alia Atlas, and John
Scudder provided a significant amount of feedback for the newer
versions of the document. During and after the IETF Last Call,
useful comments were provided by Francis Dupont, Sam Hartman, Lars
Eggert, and Ross Callon.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
GTSM is a simple procedure that protects single-hop protocol
sessions, except in those cases in which the peer has been
compromised. In particular, it does not protect against the wide
range of on-the-wire attacks; protection from these attacks requires
more rigorous security mechanisms.
<span class="grey">Gill, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5082">RFC 5082</a> GTSM October 2007</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. TTL (Hop Limit) Spoofing</span>
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
packet passes through routers towards the destination, the TTL is
decremented by one per router. As a result, when a router receives a
packet, it may not be able to determine if the packet's IP address is
valid, but it can determine how many router hops away it is (again,
assuming none of the routers in the path are compromised in such a
way that they would reset the packet's TTL).
Note, however, that while engineering a packet's TTL such that it has
a particular value when sourced from an arbitrary location is
difficult (but not impossible), engineering a TTL value of 255 from
non-directly connected locations is not possible (again, assuming
none of the directly connected neighbors are compromised, the packet
has not been tunneled to the decapsulator, and the intervening
routers are operating in accordance with <a href="./rfc791">RFC 791</a> [<a href="./rfc0791" title=""Internet Protocol"">RFC0791</a>]).
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Tunneled Packets</span>
The security of any tunneling technique depends heavily on
authentication at the tunnel endpoints, as well as how the tunneled
packets are protected in flight. Such mechanisms are, however,
beyond the scope of this memo.
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
the tunnel is not integrity-protected (i.e., the lower layer is
compromised).
When the protocol packet is tunneled directly to the protocol peer
(i.e., the protocol peer is the decapsulator), the GTSM provides some
limited added protection as the security depends entirely on the
integrity of the tunnel.
For protocol adjacencies over a tunnel, if the tunnel itself is
deemed secure (i.e., the underlying infrastructure is deemed secure,
and the tunnel offers degrees of protection against spoofing such as
keys or cryptographic security), the GTSM can serve as a check that
the protocol packet did not originate beyond the head-end of the
tunnel. In addition, if the protocol peer can receive packets for
the GTSM-protected protocol session from outside the tunnel, the GTSM
can help thwart attacks from beyond the adjacent router.
When the tunnel tail-end decapsulates the protocol packet and then
IP-forwards the packet to a directly connected protocol peer, the TTL
is decremented as described below. This means that the tunnel
<span class="grey">Gill, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5082">RFC 5082</a> GTSM October 2007</span>
decapsulator is the penultimate node from the GTSM-protected protocol
peer's perspective. As a result, the GTSM check protects from
attackers encapsulating packets to your peers. However, specific
cases arise when the connection from the tunnel decapsulator node to
the protocol peer is not an IP forwarding hop, where TTL-decrementing
does not happen (e.g., layer-2 tunneling, bridging, etc). In the
IPsec architecture [<a href="./rfc4301" title=""Security Architecture for the Internet Protocol"">RFC4301</a>], another example is the use of Bump-in-
the-Wire (BITW) [<a href="#ref-BITW" title=""Thread: 'IP-in-IP, TTL decrementing when forwarding and BITW' on int-area list, Message-ID: <Pine.LNX.4.64.0606020830220.12705@netcore.fi>"">BITW</a>].
<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>. IP Tunneled over IP</span>
Protocol packets may be tunneled over IP directly to a protocol peer,
or to a decapsulator (tunnel endpoint) that then forwards the packet
to a directly connected protocol peer. Examples of tunneling IP over
IP include IP-in-IP [<a href="./rfc2003" title=""IP Encapsulation within IP"">RFC2003</a>], GRE [<a href="./rfc2784" title=""Generic Routing Encapsulation (GRE)"">RFC2784</a>], and various forms of
IPv6-in-IPv4 (e.g., [<a href="./rfc4213" title=""Basic Transition Mechanisms for IPv6 Hosts and Routers"">RFC4213</a>]). These cases are depicted below.
Peer router ---------- Tunnel endpoint router and peer
TTL=255 [tunnel] [TTL=255 at ingress]
[TTL=255 at processing]
Peer router -------- Tunnel endpoint router ----- On-link peer
TTL=255 [tunnel] [TTL=255 at ingress] [TTL=254 at ingress]
[TTL=254 at egress]
In both cases, the encapsulator (origination tunnel endpoint) is the
(supposed) sending protocol peer. The TTL in the inner IP datagram
can be set to 255, since <a href="./rfc2003">RFC 2003</a> specifies the following behavior:
When encapsulating a datagram, the TTL in the inner IP
header is decremented by one if the tunneling is being
done as part of forwarding the datagram; otherwise, the
inner header TTL is not changed during encapsulation.
In the first case, the encapsulated packet is tunneled directly to
the protocol peer (also a tunnel endpoint), and therefore the
encapsulated packet's TTL can be received by the protocol peer with
an arbitrary value, including 255.
In the second case, the encapsulated packet is tunneled to a
decapsulator (tunnel endpoint), which then forwards it to a directly
connected protocol peer. For IP-in-IP tunnels, <a href="./rfc2003">RFC 2003</a> specifies
the following decapsulator behavior:
The TTL in the inner IP header is not changed when decapsulating.
If, after decapsulation, the inner datagram has TTL = 0, the
decapsulator MUST discard the datagram. If, after decapsulation,
the decapsulator forwards the datagram to one of its network
<span class="grey">Gill, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5082">RFC 5082</a> GTSM October 2007</span>
interfaces, it will decrement the TTL as a result of doing normal
IP forwarding. See also <a href="#section-4.4">Section 4.4</a>.
And similarly, for GRE tunnels, <a href="./rfc2784">RFC 2784</a> specifies the following
decapsulator behavior:
When a tunnel endpoint decapsulates a GRE packet which has an IPv4
packet as the payload, the destination address in the IPv4 payload
packet header MUST be used to forward the packet and the TTL of
the payload packet MUST be decremented.
Hence the inner IP packet header's TTL, as seen by the decapsulator,
can be set to an arbitrary value (in particular, 255). If the
decapsulator is also the protocol peer, it is possible to deliver the
protocol packet to it with a TTL of 255 (first case). On the other
hand, if the decapsulator needs to forward the protocol packet to a
directly connected protocol peer, the TTL will be decremented (second
case).
<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a>. IP Tunneled over MPLS</span>
Protocol packets may also be tunneled over MPLS Label Switched Paths
(LSPs) to a protocol peer. The following diagram depicts the
topology.
Peer router -------- LSP Termination router and peer
TTL=255 MPLS LSP [TTL=x at ingress]
MPLS LSPs can operate in Uniform or Pipe tunneling models. The TTL
handling for these models is described in <a href="./rfc3443">RFC 3443</a> [<a href="./rfc3443" title=""Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks"">RFC3443</a>] that
updates <a href="./rfc3032">RFC 3032</a> [<a href="./rfc3032" title=""MPLS Label Stack Encoding"">RFC3032</a>] in regards to TTL processing in MPLS
networks. <a href="./rfc3443">RFC 3443</a> specifies the TTL processing in both Uniform and
Pipe Models, which in turn can used with or without penultimate hop
popping (PHP). The TTL processing in these cases results in
different behaviors, and therefore are analyzed separately. Please
refer to <a href="#section-3.1">Section 3.1</a> through <a href="./rfc3443#section-3.3">Section 3.3 of RFC 3443</a>.
The main difference from a TTL processing perspective between Uniform
and Pipe Models at the LSP termination node resides in how the
incoming TTL (iTTL) is determined. The tunneling model determines
the iTTL: For Uniform Model LSPs, the iTTL is the value of the TTL
field from the popped MPLS header (encapsulating header), whereas for
Pipe Model LSPs, the iTTL is the value of the TTL field from the
exposed header (encapsulated header).
<span class="grey">Gill, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5082">RFC 5082</a> GTSM October 2007</span>
For Uniform Model LSPs, <a href="./rfc3443">RFC 3443</a> states that at ingress:
For each pushed Uniform Model label, the TTL is copied from the
label/IP-packet immediately underneath it.
From this point, the inner TTL (i.e., the TTL of the tunneled IP
datagram) represents non-meaningful information, and at the egress
node or during PHP, the ingress TTL (iTTL) is equal to the TTL of the
popped MPLS header (see <a href="./rfc3443#section-3.1">Section 3.1 of RFC 3443</a>). In consequence,
for Uniform Model LSPs of more than one hop, the TTL at ingress
(iTTL) will be less than 255 (x <= 254), and as a result the check
described in <a href="#section-3">Section 3</a> of this document will fail.
The TTL treatment is identical between Short Pipe Model LSPs without
PHP and Pipe Model LSPs (without PHP only). For these cases, <a href="./rfc3443">RFC</a>
<a href="./rfc3443">3443</a> states that:
For each pushed Pipe Model or Short Pipe Model label, the TTL
field is set to a value configured by the network operator. In
most implementations, this value is set to 255 by default.
In these models, the forwarding treatment at egress is based on the
tunneled packet as opposed to the encapsulation packet. The ingress
TTL (iTTL) is the value of the TTL field of the header that is
exposed, that is the tunneled IP datagram's TTL. The protocol
packet's TTL as seen by the LSP termination can therefore be set to
an arbitrary value (including 255). If the LSP termination router is
also the protocol peer, it is possible to deliver the protocol packet
with a TTL of 255 (x = 255).
Finally, for Short Pipe Model LSPs with PHP, the TTL of the tunneled
packet is unchanged after the PHP operation. Therefore, the same
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, the TTL at egress has the same value with or without
PHP.
In conclusion, GTSM checks are possible for IP tunneled over Pipe
model LSPs, but not for IP tunneled over Uniform model LSPs.
Additionally, for all tunneling modes, if the LSP termination router
needs to forward the protocol packet to a directly connected protocol
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,
the outgoing TTL (oTTL) is calculated by decrementing iTTL by one.
<span class="grey">Gill, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5082">RFC 5082</a> GTSM October 2007</span>
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Onlink Attackers</span>
As described in <a href="#section-2">Section 2</a>, an attacker directly connected to one
interface can disturb a GTSM-protected session on the same or another
interface (by spoofing a GTSM peer's address) unless ingress
filtering has been applied on the connecting interface. As a result,
interfaces that do not include such protection need to be trusted not
to originate attacks on the router.
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Fragmentation Considerations</span>
As mentioned, fragmentation may restrict the amount of information
available for classification. Since non-initial IP fragments do not
contain Layer 4 information, it is highly likely that they cannot be
associated with a registered GTSM-enabled session. Following the
receiving protocol procedures described in <a href="#section-3">Section 3</a>, non-initial IP
fragments would likely be classified with Unknown trustworthiness.
And since the IP packet would need to be reassembled in order to be
processed, the end result is that the initial-fragment of a GTSM-
enabled session effectively receives the treatment of an Unknown-
trustworthiness packet, and the complete reassembled packet receives
the aggregate of the Unknowns.
In principle, an implementation could remember the TTL of all
received fragments. Then when reassembling the packet, verify that
the TTL of all fragments match the required value for an associated
GTSM-enabled session. In the likely common case that the
implementation does not do this check on all fragments, then it is
possible for a legitimate first fragment (which passes the GTSM
check) to be combined with spoofed non-initial fragments, implying
that the integrity of the received packet is unknown and unprotected.
If this check is performed on all fragments at reassembly, and some
fragment does not pass the GTSM check for a GTSM-enabled session, the
reassembled packet is categorized as a Dangerous-trustworthiness
packet and receives the corresponding treatment.
Further, reassembly requires to wait for all the fragments and
therefore likely invalidates or weakens the fifth assumption
presented in <a href="#section-2">Section 2</a>: it may not be possible to classify non-
initial fragments before going through a scarce resource in the
system, when fragments need to be buffered for reassembly and later
processed by a CPU. That is, when classification cannot be done with
the required granularity, non-initial fragments of GTSM-enabled
session packets would not use different resource pools.
Consequently, to get practical protection from fragment attacks,
operators may need to rate-limit or discard all received fragments.
As such, it is highly RECOMMENDED for GTSM-protected protocols to
<span class="grey">Gill, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5082">RFC 5082</a> GTSM October 2007</span>
avoid fragmentation and reassembly by manual MTU tuning, using
adaptive measures such as Path MTU Discovery (PMTUD), or any other
available method [<a href="./rfc1191" title=""Path MTU discovery"">RFC1191</a>], [<a href="./rfc1981" title=""Path MTU Discovery for IP version 6"">RFC1981</a>], or [<a href="./rfc4821" title=""Packetization Layer Path MTU Discovery"">RFC4821</a>].
<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>. Multi-Hop Protocol Sessions</span>
GTSM could possibly offer some small, though difficult to quantify,
degree of protection when used with multi-hop protocol sessions (see
<a href="#appendix-A">Appendix A</a>). In order to avoid having to quantify the degree of
protection and the resulting applicability of multi-hop, we only
describe the single-hop case because its security properties are
clearer.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Applicability Statement</span>
GTSM is only applicable to environments with inherently limited
topologies (and is most effective in those cases where protocol peers
are directly connected). In particular, its application should be
limited to those cases in which protocol peers are directly
connected.
GTSM will not protect against attackers who are as close to the
protected station as its legitimate peer. For example, if the
legitimate peer is one hop away, GTSM will not protect from attacks
from directly connected devices on the same interface (see
<a href="#section-2.2">Section 2.2</a> for more).
Experimentation on GTSM's applicability and security properties is
needed in multi-hop scenarios. The multi-hop scenarios where GTSM
might be applicable is expected to have the following
characteristics: the topology between peers is fairly static and
well-known, and in which the intervening network (between the peers)
is trusted.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Backwards Compatibility</span>
<a href="./rfc3682">RFC 3682</a> [<a href="./rfc3682" title=""The Generalized TTL Security Mechanism (GTSM)"">RFC3682</a>] did not specify how to handle "related messages"
(ICMP errors). This specification mandates setting and verifying
TTL=255 of those as well as the main protocol packets.
Setting TTL=255 in related messages does not cause issues for <a href="./rfc3682">RFC</a>
<a href="./rfc3682">3682</a> implementations.
Requiring TTL=255 in related messages may have impact with <a href="./rfc3682">RFC 3682</a>
implementations, depending on which default TTL the implementation
uses for originated packets; some implementations are known to use
255, while 64 or other values are also used. Related messages from
the latter category of <a href="./rfc3682">RFC 3682</a> implementations would be classified
<span class="grey">Gill, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5082">RFC 5082</a> GTSM October 2007</span>
as Dangerous and treated as described in <a href="#section-3">Section 3</a>. This is not
believed to be a significant problem because protocols do not depend
on related messages (e.g., typically having a protocol exchange for
closing the session instead of doing a TCP-RST), and indeed the
delivery of related messages is not reliable. As such, related
messages typically provide an optimization to shorten a protocol
keepalive timeout. Regardless of these issues, given that related
messages provide a significant attack vector to e.g., reset protocol
sessions, making this further restriction seems sensible.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-RFC0791">RFC0791</a>] Postel, J., "Internet Protocol", STD 5, <a href="./rfc791">RFC 791</a>,
September 1981.
[<a id="ref-RFC2003">RFC2003</a>] Perkins, C., "IP Encapsulation within IP", <a href="./rfc2003">RFC 2003</a>,
October 1996.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC2461">RFC2461</a>] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", <a href="./rfc2461">RFC 2461</a>,
December 1998.
[<a id="ref-RFC2784">RFC2784</a>] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", <a href="./rfc2784">RFC 2784</a>,
March 2000.
[<a id="ref-RFC3392">RFC3392</a>] Chandra, R. and J. Scudder, "Capabilities Advertisement
with BGP-4", <a href="./rfc3392">RFC 3392</a>, November 2002.
[<a id="ref-RFC3443">RFC3443</a>] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
in Multi-Protocol Label Switching (MPLS) Networks",
<a href="./rfc3443">RFC 3443</a>, January 2003.
[<a id="ref-RFC4213">RFC4213</a>] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", <a href="./rfc4213">RFC 4213</a>, October 2005.
[<a id="ref-RFC4271">RFC4271</a>] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", <a href="./rfc4271">RFC 4271</a>, January 2006.
[<a id="ref-RFC4301">RFC4301</a>] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", <a href="./rfc4301">RFC 4301</a>, December 2005.
<span class="grey">Gill, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5082">RFC 5082</a> GTSM October 2007</span>
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-BITW">BITW</a>] "Thread: 'IP-in-IP, TTL decrementing when forwarding and
BITW' on int-area list, Message-ID:
<Pine.LNX.4.64.0606020830220.12705@netcore.fi>",
June 2006, <<a href="http://www1.ietf.org/mail-archive/web/int-area/current/msg00267.html">http://www1.ietf.org/mail-archive/web/</a>
<a href="http://www1.ietf.org/mail-archive/web/int-area/current/msg00267.html">int-area/current/msg00267.html</a>>.
[<a id="ref-RFC1191">RFC1191</a>] Mogul, J. and S. Deering, "Path MTU discovery", <a href="./rfc1191">RFC 1191</a>,
November 1990.
[<a id="ref-RFC1981">RFC1981</a>] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", <a href="./rfc1981">RFC 1981</a>, August 1996.
[<a id="ref-RFC3032">RFC3032</a>] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", <a href="./rfc3032">RFC 3032</a>, January 2001.
[<a id="ref-RFC3682">RFC3682</a>] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL
Security Mechanism (GTSM)", <a href="./rfc3682">RFC 3682</a>, February 2004.
[<a id="ref-RFC3704">RFC3704</a>] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", <a href="https://www.rfc-editor.org/bcp/bcp84">BCP 84</a>, <a href="./rfc3704">RFC 3704</a>, March 2004.
[<a id="ref-RFC4272">RFC4272</a>] Murphy, S., "BGP Security Vulnerabilities Analysis",
<a href="./rfc4272">RFC 4272</a>, January 2006.
[<a id="ref-RFC4821">RFC4821</a>] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", <a href="./rfc4821">RFC 4821</a>, March 2007.
<span class="grey">Gill, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5082">RFC 5082</a> GTSM October 2007</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Multi-Hop GTSM</span>
NOTE: This is a non-normative part of the specification.
The main applicability of GTSM is for directly connected peers. GTSM
could be used for non-directly connected sessions as well, where the
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
deployment is expected to have a more limited applicability and
different security implications, it is not specified in this
document.
<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>. Changes Since <a href="./rfc3682">RFC 3682</a></span>
o Bring the work on the Standards Track (<a href="./rfc3682">RFC 3682</a> was Experimental).
o New text on GTSM applicability and use in new and existing
protocols.
o Restrict the scope to not specify multi-hop scenarios.
o Explicitly require that related messages (ICMP errors) must also
be sent and checked to have TTL=255. See <a href="#section-6.1">Section 6.1</a> for
discussion on backwards compatibility.
o Clarifications relating to fragmentation, security with tunneling,
and implications of ingress filtering.
o A significant number of editorial improvements and clarifications.
Authors' Addresses
Vijay Gill
EMail: vijay@umbc.edu
John Heasley
EMail: heas@shrubbery.net
David Meyer
EMail: dmm@1-4-5.net
Pekka Savola (editor)
Espoo
Finland
EMail: psavola@funet.fi
Carlos Pignataro
EMail: cpignata@cisco.com
<span class="grey">Gill, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5082">RFC 5082</a> GTSM October 2007</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Gill, et al. Standards Track [Page 16]
</pre>
|
