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
|
<pre>Internet Engineering Task Force (IETF) V. Manral
Request for Comments: 7175 Ionos Corp.
Category: Standards Track D. Eastlake 3rd
ISSN: 2070-1721 Huawei R&D USA
D. Ward
Cisco Systems
A. Banerjee
Cumulus Networks
May 2014
<span class="h1">Transparent Interconnection of Lots of Links (TRILL):</span>
<span class="h1">Bidirectional Forwarding Detection (BFD) Support</span>
Abstract
This document specifies use of the Bidirectional Forwarding Detection
(BFD) protocol in Routing Bridge (RBridge) campuses based on the
RBridge Channel extension to the Transparent Interconnection of Lots
of Links (TRILL) protocol.
BFD is a widely deployed Operations, Administration, and Maintenance
(OAM) mechanism in IP and MPLS networks, using UDP and Associated
Channel Header (ACH) encapsulation respectively. This document
specifies the BFD encapsulation over TRILL.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7175">http://www.rfc-editor.org/info/rfc7175</a>.
<span class="grey">Manral, 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="./rfc7175">RFC 7175</a> TRILL BFD Support May 2014</span>
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Terminology ................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. BFD over TRILL ..................................................<a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Sessions and Initialization ................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. TRILL BFD Control Protocol ......................................<a href="#page-5">5</a>
<a href="#section-3.1">3.1</a>. One-Hop TRILL BFD Control ..................................<a href="#page-5">5</a>
<a href="#section-3.2">3.2</a>. BFD Control Frame Processing ...............................<a href="#page-5">5</a>
<a href="#section-4">4</a>. TRILL BFD Echo Protocol .........................................<a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. BFD Echo Frame Processing ..................................<a href="#page-6">6</a>
<a href="#section-5">5</a>. Management and Operations Considerations ........................<a href="#page-7">7</a>
<a href="#section-6">6</a>. Default Authentication ..........................................<a href="#page-7">7</a>
<a href="#section-7">7</a>. Security Considerations .........................................<a href="#page-8">8</a>
<a href="#section-8">8</a>. IANA Considerations .............................................<a href="#page-9">9</a>
<a href="#section-9">9</a>. Acknowledgements ................................................<a href="#page-9">9</a>
<a href="#section-10">10</a>. References .....................................................<a href="#page-9">9</a>
<a href="#section-10.1">10.1</a>. Normative References ......................................<a href="#page-9">9</a>
<a href="#section-10.2">10.2</a>. Informative References ...................................<a href="#page-10">10</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Faster convergence is a critical feature of Transparent
Interconnection of Lots of Links (TRILL) [<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>] networks. The
TRILL IS-IS Hellos [<a href="./rfc7177" title=""Transparent Interconnection of Lots of Links (TRILL): Adjacency"">RFC7177</a>] [<a href="#ref-IS-IS" title=""Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"">IS-IS</a>] used between RBridges provide a
basic neighbor and continuity check for TRILL links. However,
failure detection by non-receipt of such Hellos is based on the
Holding Time parameter that is commonly set to a value of tens of
seconds and, in any case, has a minimum expressible value of one
second.
<span class="grey">Manral, 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="./rfc7175">RFC 7175</a> TRILL BFD Support May 2014</span>
Some applications, including Voice over IP, may wish, with high
probability, to detect interruptions in continuity within a much
shorter time period. In some cases, physical-layer failures can be
detected very rapidly, but this is not always possible, such as when
there is a failure between two bridges that are in turn between two
RBridges. There are also many subtle failures possible at higher
levels. For example, some forms of failure could affect unicast
frames while still letting multicast frames through; since all TRILL
IS-IS Hellos are multicast, such a failure cannot be detected with
Hellos. Thus, a low-overhead method for frequently testing
continuity for the TRILL Data between neighbor RBridges is necessary
for some applications. The BFD protocol [<a href="./rfc5880" title=""Bidirectional Forwarding Detection (BFD)"">RFC5880</a>] provides a low-
overhead method for the rapid detection of connectivity failures.
BFD is a widely deployed OAM [<a href="./rfc6291" title=""Guidelines for the Use of the "">RFC6291</a>] mechanism in IP and MPLS
networks, using UDP and ACH encapsulation, respectively. This
document describes a TRILL encapsulation for BFD packets for networks
that forward based on the TRILL Header.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Terminology</span>
This document uses the acronyms defined in [<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>] along with the
following:
BFD: Bidirectional Forwarding Detection
IP: Internet Protocol
IS-IS: Intermediate System to Intermediate System
MH: Multi-Hop
PPP: Point-to-Point Protocol
OAM: Operations, Administration, and Maintenance
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" 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>. BFD over TRILL</span>
TRILL supports unicast neighbor BFD Echo and one-hop and multi-hop
BFD Control, as specified below, over the RBridge Channel facility
[<a href="./rfc7178" title=""Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support"">RFC7178</a>]. (Multi-destination BFD is a work in progress [<a href="#ref-MultiBFD" title=""BFD for Multipoint Networks"">MultiBFD</a>].)
BFD-over-TRILL support is similar to BFD-over-IP support [<a href="./rfc5881" title=""Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)"">RFC5881</a>],
except where differences are explicitly mentioned.
<span class="grey">Manral, 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="./rfc7175">RFC 7175</a> TRILL BFD Support May 2014</span>
Asynchronous and demand modes MUST be supported [<a href="./rfc5880" title=""Bidirectional Forwarding Detection (BFD)"">RFC5880</a>]. BFD over
TRILL supports the Echo function; however, implementation of TRILL
BFD Echo is optional, and it can only be used for single-hop
sessions.
The TRILL Header hop count in the BFD packets is sent out with the
maximum value of 0x3F. To prevent spoofing attacks, the TRILL hop
count of a received session is checked [<a href="./rfc5082" title=""The Generalized TTL Security Mechanism (GTSM)"">RFC5082</a>]. For a single-hop
session, if the hop count is less than 0x3F and the RBridge Channel
Header MH flag is zero, the packet is discarded. For multi-hop
sessions, the hop count check can be disabled if the MH flag is one.
As in BFD for IP, the format of the Echo Packet content is not
defined.
New RBridge Channel code points for BFD TRILL Control and BFD Echo
packets are specified.
Authentication mechanisms as supported in BFD are also supported for
BFD running over TRILL.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Sessions and Initialization</span>
Within an RBridge campus, there will be no more than one TRILL BFD
Control session from any RBridge RB1 to RBridge RB2 for each RB1
TRILL port. This BFD session must be bound to this interface. As
such, both sides of a session MUST take the "Active" role (sending
initial BFD Control packets with a zero value of Your Discriminator),
and any BFD packet from the remote machine with a zero value of Your
Discriminator MUST be associated with the session bound to the remote
system and interface.
Note that TRILL BFD provides OAM facilities for the TRILL data plane.
This is above whatever protocol is in use on a particular link, such
as a pseudowire [<a href="./rfc7173" title=""Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires"">RFC7173</a>], Ethernet [<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>], or PPP link [<a href="./rfc6361" title=""PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol"">RFC6361</a>].
Link-technology-specific OAM protocols may be used on a link between
neighbor RBridges, for example, Continuity Fault Management [<a href="#ref-802.1Q" title=""IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">802.1Q</a>]
if the link is Ethernet. But such link-layer OAM (and coordination
between it and OAM in the TRILL data-plane layer, such as TRILL BFD)
is beyond the scope of this document.
If lower-level mechanisms are in use, such as link aggregation
[<a href="#ref-802.1AX" title=""IEEE Standard for Local and metropolitan area networks -- Link Aggregation"">802.1AX</a>], that present a single logical interface to TRILL IS-IS,
then only a single TRILL BFD session can be established to any other
RBridge over this logical interface. However, lower-layer OAM could
be aware of and/or run separately on each of the components of an
aggregation.
<span class="grey">Manral, 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="./rfc7175">RFC 7175</a> TRILL BFD Support May 2014</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. TRILL BFD Control Protocol</span>
TRILL BFD Control frames are unicast TRILL RBridge Channel frames
[<a href="./rfc7178" title=""Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support"">RFC7178</a>]. The RBridge Channel Protocol value is given in <a href="#section-8">Section 8</a>.
The protocol-specific data associated with the TRILL BFD Control
protocol is as shown in <a href="./rfc5880#section-4.1">Section 4.1 of [RFC5880]</a>.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. One-Hop TRILL BFD Control</span>
One-hop TRILL BFD Control is typically used to rapidly detect link
and RBridge failures. TRILL BFD frames over one hop for such
purposes SHOULD be sent with high priority; that is, the Inner.VLAN
tag priority should be 7, they should be queued for transmission as
maximum priority frames, and, if they are being sent on an Ethernet
link where the output port is configured to include an Outer.VLAN
tag, that tag should specify priority 7.
For neighbor RBridges RB1 and RB2, each RBridge sends one-hop TRILL
BFD Control frames to the other only if TRILL IS-IS has detected
bidirectional connectivity; that is, the adjacency is in the 2-Way or
Report state [<a href="./rfc7177" title=""Transparent Interconnection of Lots of Links (TRILL): Adjacency"">RFC7177</a>], and both RBridges indicate support of TRILL
BFD is enabled. The BFD-Enabled TLV is used to indicate this as
specified in [<a href="./rfc6213" title=""IS-IS BFD-Enabled TLV"">RFC6213</a>].
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. BFD Control Frame Processing</span>
The following tests SHOULD be performed on received TRILL BFD Control
frames before generic BFD processing.
o Is the M bit in the TRILL Header non-zero? If so, discard the
frame. (Multi-destination BFD is a work in progress [<a href="#ref-MultiBFD" title=""BFD for Multipoint Networks"">MultiBFD</a>].)
Failure to perform this test would make a denial-of-service attack
using bogus multi-destination BFD Control frames easier.
o If the Channel Header MH flag is zero, indicating one hop, test
that the TRILL Header hop count received was 0x3F (i.e., is 0x3E
if it has already been decremented); if it is any other value,
discard the frame. If the Channel Header MH flag is one,
indicating multi-hop, test that the TRILL Header hop count
received was not less than a configurable value that defaults to
0x30. If it is less, discard the frame. Failure to perform these
tests would make it easier to spoof BFD Control frames. However,
if forged BFD Control frames are a concern, then BFD
Authentication [<a href="./rfc5880" title=""Bidirectional Forwarding Detection (BFD)"">RFC5880</a>] should be used.
<span class="grey">Manral, 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="./rfc7175">RFC 7175</a> TRILL BFD Support May 2014</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. TRILL BFD Echo Protocol</span>
A TRILL BFD Echo frame is a unicast RBridge Channel frame, as
specified in [<a href="./rfc7178" title=""Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support"">RFC7178</a>], which should be forwarded back by an
immediate neighbor because both the ingress and egress nicknames are
set to a nickname of the originating RBridge. Normal TRILL Data
frame forwarding will cause the frame to be returned unless micro-
loop suppression logic in the neighbor RBridge prohibits sending a
frame back out the port on which it was received or the like.
RBridges with such prohibitions cannot support BFD Echo. The TRILL
OAM protocol number for BFD Echo is given in <a href="#section-8">Section 8</a>.
TRILL BFD Echo frames SHOULD be sent on a link only if the following
conditions are met. An Echo originating under other circumstances
will consume bandwidth and CPU resources but is unlikely to be
returned.
- A TRILL BFD Control session has been established,
- TRILL BFD Echo support is indicated by the RBridge that would
potentially respond to the BFD Echo,
- The adjacency is in the Report state [<a href="./rfc7177" title=""Transparent Interconnection of Lots of Links (TRILL): Adjacency"">RFC7177</a>], and
- The TRILL BFD Echo originating RBridge wishes to make use of this
optional feature.
Since the originating RBridge is the RBridge that will be processing
a returned Echo frame, the entire TRILL BFD Echo protocol-specific
data area is considered opaque and left to the discretion of the
originating RBridge. Nevertheless, it is suggested that this data
include information by which the originating RBridge can authenticate
the returned BFD Echo frame and confirm the neighbor that echoed the
frame back. For example, it could include its own System ID, the
neighbor's System ID, a session identifier, and a sequence count as
well as a Message Authentication Code.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. BFD Echo Frame Processing</span>
The following tests MUST be performed on returned TRILL BFD Echo
frames before other processing. The RBridge Channel document
[<a href="./rfc7178" title=""Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support"">RFC7178</a>] requires that the information in the TRILL Header be given
to the BFD protocol.
o Is the M bit in the TRILL Header non-zero? If so, discard the
frame. (Multi-destination BFD is a work in progress [<a href="#ref-MultiBFD" title=""BFD for Multipoint Networks"">MultiBFD</a>].)
<span class="grey">Manral, 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="./rfc7175">RFC 7175</a> TRILL BFD Support May 2014</span>
o The TRILL BFD Echo frame should have gone exactly two hops, so
test that the TRILL Header hop count as received was 0x3E (i.e.,
0x3D if it has already been decremented), and if it is any other
value, discard the frame. The RBridge Channel Header in the frame
MUST have the MH bit equal to one, and if it is zero, discard the
frame.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Management and Operations Considerations</span>
The TRILL BFD parameters on an RBridge are configurable. The default
values are the same as in the IP BFD case [<a href="./rfc5881" title=""Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)"">RFC5881</a>], except where
specified in this document, such as for hop count.
It is up to the operator of an RBridge campus to configure the rates
at which TRILL BFD frames are transmitted on a link to avoid
congestion (e.g., link, input/output (I/O), CPU) and false failure
detection. See also the discussion of congestion in <a href="./rfc5881#section-2">Section 2 of
[RFC5881]</a>.
As stated in [<a href="./rfc5880" title=""Bidirectional Forwarding Detection (BFD)"">RFC5880</a>]:
It is worth noting that a single BFD session does not consume a
large amount of bandwidth. An aggressive session that achieves a
detection time of 50 milliseconds, by using a transmit interval of
16.7 milliseconds and a detect multiplier of 3, will generate 60
packets per second. The maximum length of each packet on the wire
is on the order of 100 bytes, for a total of around 48 kilobits
per second of bandwidth consumption in each direction.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Default Authentication</span>
Consistent with TRILL's goal of being able to operate with minimum
configuration, the default for BFD authentication between neighbor
RBridges is based on the state of the IS-IS shared secret
authentication for Hellos between those RBridges as detailed below.
The BFD authentication algorithm and methods in this section MUST be
implemented at an RBridge if TRILL IS-IS authentication and BFD are
implemented at that RBridge. If such BFD authentication is
configured, then its configuration is not restricted by the
configuration of IS-IS security.
If IS-IS authentication is not in effect between neighbor RBridges,
then, by default, TRILL BFD between those RBridges is also unsecured.
If such IS-IS authentication is in effect, then, unless configured
otherwise, TRILL BFD Control frames sent between those RBridges MUST
use BFD Meticulous Keyed SHA1 authentication [<a href="./rfc5880" title=""Bidirectional Forwarding Detection (BFD)"">RFC5880</a>]. The BFD
authentication keys between neighbor RBridges by default are derived
<span class="grey">Manral, 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="./rfc7175">RFC 7175</a> TRILL BFD Support May 2014</span>
from the IS-IS shared secret authentication keys for Hellos between
those RBridges as detailed below. However, such BFD authentication
keys MAY be configured to some other value.
HMAC-SHA256 ( ( "TRILL BFD Control" | originPortID | originSysID ),
IS-IS-shared-key )
In the above, "|" indicates concatenation; HMAC-SHA256 is as
described in [<a href="#ref-FIPS180" title=""Secure Hash Standard (SHS)"">FIPS180</a>] and [<a href="./rfc6234" title=""US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)"">RFC6234</a>]; and "TRILL BFD Control" is the
17-byte US ASCII [<a href="#ref-ASCII" title=""Coded Character Set - 7-bit American Standard Code for Information Interchange"">ASCII</a>] string indicated that is then concatenated
with the 2-byte Port ID of the originating port and the 6-byte IS-IS
System ID of the originating RBridge, the last two items being in
network byte order. The Port and System IDs are included to minimize
exposure of the same key to improve resistance to cryptanalysis.
IS-IS-shared-key is secret keying material being used for IS-IS
authentication on the link.
The use of the above derived key is accomplished by associating the
above default authentication type and key with the Key ID of the
IS-IS-shared-key used in the derivation and then using that Key ID in
the Authentication Section of the BFD Control frame OAM protocol-
specific data. Also, Auth Type would be 5, and Auth Len would be 28
in the Authentication Section. RBridges MAY be configured to use
other BFD security modes or keying material or configured to use no
security.
Authentication for TRILL BFD Echo is a local implementation issue as
BFD Echo frames are authenticated by their sender when returned by a
neighbor. However, if TRILL IS-IS and BFD Control are being
authenticated to a neighbor and BFD Echo is in use, BFD Echo frames
to be returned by that neighbor should be authenticated, and such
authentication should use different keying material from other types
of authentication. For example, it could use keying material derived
as follows, where "|" indicates concatenation:
HMAC-SHA256 ( ( "TRILL BFD Echo" | originPortID | originSysID ),
IS-IS-shared-key )
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
BFD over TRILL utilizes the RBridge Channel extension to the TRILL
protocol and is generally analogous to BFD over IP. As such, the BFD
authentication facility is available to authenticate BFD-over-TRILL
packet payloads, but no encryption or other security features are
provided at the BFD-over-TRILL level. See the following:
- [<a href="./rfc5881" title=""Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)"">RFC5881</a>] for general BFD security considerations,
<span class="grey">Manral, 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="./rfc7175">RFC 7175</a> TRILL BFD Support May 2014</span>
- [<a href="./rfc7178" title=""Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support"">RFC7178</a>] for general RBridge Channel security considerations, and
- [<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>] for general TRILL protocol security considerations.
<a href="#section-3.2">Section 3.2</a> describes security concerns with multi-hop BFD Control
packets and failure to check the TRILL Header M bit in BFD Control
packets.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
IANA has allocated two RBridge Channel protocol numbers [<a href="./rfc7178" title=""Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support"">RFC7178</a>]
from the Standards Action range, as follows:
Protocol Number
-------- ------
BFD Control 0x002
BFD Echo 0x003
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgements</span>
The authors would like to specially thank Dave Katz, an author of
[<a href="./rfc5880" title=""Bidirectional Forwarding Detection (BFD)"">RFC5880</a>] and [<a href="./rfc5881" title=""Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)"">RFC5881</a>], from which some material herein has been
reproduced.
The following individuals are thanked for their comments and
suggestions: Scott Bradner, Stewart Bryant, Stephen Farrell, Eric
Gray, Brian Haberman, Barry Leiba, Erik Nordmark, John Scudder,
Robert Sparks, Martin Stiemerling, and Sean Turner.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-ASCII">ASCII</a>] American National Standards Institute, "Coded Character
Set - 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986.
[<a id="ref-FIPS180">FIPS180</a>] National Institute of Science and Technology, "Secure Hash
Standard (SHS)", Federal Information Processing Standard
(FIPS) 180-4, March 2012, <<a href="http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf">http://csrc.nist.gov/</a>
<a href="http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf">publications/fips/fips180-4/fips-180-4.pdf</a>>.
[<a id="ref-IS-IS">IS-IS</a>] International Organization for Standardization,
"Intermediate System to Intermediate System intra-domain
routeing information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode network service (ISO 8473)", Second
Edition, November 2002.
<span class="grey">Manral, 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="./rfc7175">RFC 7175</a> TRILL BFD Support May 2014</span>
[<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-RFC5880">RFC5880</a>] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", <a href="./rfc5880">RFC 5880</a>, June 2010.
[<a id="ref-RFC5881">RFC5881</a>] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", <a href="./rfc5881">RFC 5881</a>, June
2010.
[<a id="ref-RFC6213">RFC6213</a>] Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV", <a href="./rfc6213">RFC</a>
<a href="./rfc6213">6213</a>, April 2011.
[<a id="ref-RFC6325">RFC6325</a>] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", <a href="./rfc6325">RFC 6325</a>, July 2011.
[<a id="ref-RFC7177">RFC7177</a>] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and
V. Manral, "Transparent Interconnection of Lots of Links
(TRILL): Adjacency", <a href="./rfc7177">RFC 7177</a>, May 2014.
[<a id="ref-RFC7178">RFC7178</a>] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D.
Ward, "Transparent Interconnection of Lots of Links
(TRILL): RBridge Channel Support", <a href="./rfc7178">RFC 7178</a>, May 2014.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-802.1AX">802.1AX</a>] IEEE, "IEEE Standard for Local and metropolitan area
networks -- Link Aggregation", IEEE Std 802.1AX-2008,
January 2008.
[<a id="ref-802.1Q">802.1Q</a>] IEEE, "IEEE Standard for Local and metropolitan area
networks -- Media Access Control (MAC) Bridges and Virtual
Bridged Local Area Networks", IEEE Std 802.1Q-2011, August
2011.
[<a id="ref-MultiBFD">MultiBFD</a>] Katz, D. and D. Ward, <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&q=inurl:draft-+%22BFD+for+Multipoint+Networks%22'>"BFD for Multipoint Networks"</a>, Work
in Progress, February 2014.
[<a id="ref-RFC5082">RFC5082</a>] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", <a href="./rfc5082">RFC 5082</a>, October 2007.
[<a id="ref-RFC6234">RFC6234</a>] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", <a href="./rfc6234">RFC 6234</a>, May 2011.
<span class="grey">Manral, 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="./rfc7175">RFC 7175</a> TRILL BFD Support May 2014</span>
[<a id="ref-RFC6291">RFC6291</a>] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", <a href="https://www.rfc-editor.org/bcp/bcp161">BCP 161</a>, <a href="./rfc6291">RFC 6291</a>, June 2011.
[<a id="ref-RFC6361">RFC6361</a>] Carlson, J. and D. Eastlake 3rd, "PPP Transparent
Interconnection of Lots of Links (TRILL) Protocol Control
Protocol", <a href="./rfc6361">RFC 6361</a>, August 2011.
[<a id="ref-RFC7173">RFC7173</a>] Yong, L., Eastlake 3rd, D., Aldrin, S., and J. Hudson,
"Transparent Interconnection of Lots of Links (TRILL)
Transport Using Pseudowires", <a href="./rfc7173">RFC 7173</a>, May 2014.
<span class="grey">Manral, 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="./rfc7175">RFC 7175</a> TRILL BFD Support May 2014</span>
Authors' Addresses
Vishwas Manral
Ionos Corp.
4100 Moorpark Ave.
San Jose, CA 95117
USA
EMail: vishwas@ionosnetworks.com
Donald Eastlake 3rd
Huawei R&D USA
155 Beaver Street
Milford, MA 01757
USA
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Dave Ward
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95138
USA
EMail: dward@cisco.com
Ayan Banerjee
Cumulus Networks
1089 West Evelyn Avenue
Sunnyvale, CA 94086
USA
EMail: ayabaner@gmail.com
Manral, et al. Standards Track [Page 12]
</pre>
|
