idnits 2.17.1 draft-ietf-mpls-gach-adv-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (February 5, 2013) is 4098 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-198' == Outdated reference: A later version (-10) exists of draft-ietf-karp-crypto-key-table-04 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-tp-ethernet-addressing-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS D. Frost 3 Internet-Draft S. Bryant 4 Intended status: Standards Track Cisco Systems 5 Expires: August 9, 2013 M. Bocci 6 Alcatel-Lucent 7 February 5, 2013 9 MPLS Generic Associated Channel (G-ACh) Advertisement Protocol 10 draft-ietf-mpls-gach-adv-05 12 Abstract 14 The MPLS Generic Associated Channel (G-ACh) provides an auxiliary 15 logical data channel associated with a Label Switched Path (LSP), a 16 pseudowire, or a section (link) over which a variety of protocols may 17 flow. These protocols are commonly used to provide Operations, 18 Administration, and Maintenance (OAM) mechanisms associated with the 19 primary data channel. This document specifies simple procedures by 20 which an endpoint of an LSP, pseudowire, or section may inform the 21 other endpoints of its capabilities and configuration parameters, or 22 other application-specific information. This information may then be 23 used by the receiver to validate or adjust its local configuration, 24 and by the network operator for diagnostic purposes. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 9, 2013. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 64 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4. G-ACh Advertisement Protocol TLVs . . . . . . . . . . . . . . 8 67 4.1. Source Address TLV . . . . . . . . . . . . . . . . . . . . 9 68 4.2. GAP Request TLV . . . . . . . . . . . . . . . . . . . . . 9 69 4.3. GAP Flush TLV . . . . . . . . . . . . . . . . . . . . . . 10 70 4.4. GAP Suppress TLV . . . . . . . . . . . . . . . . . . . . . 10 71 4.5. GAP Authentication TLV . . . . . . . . . . . . . . . . . . 11 72 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 5.1. Message Transmission . . . . . . . . . . . . . . . . . . . 12 74 5.2. Message Reception . . . . . . . . . . . . . . . . . . . . 12 75 6. Message Authentication . . . . . . . . . . . . . . . . . . . . 13 76 6.1. Authentication Key Identifiers . . . . . . . . . . . . . . 13 77 6.2. Authentication Process . . . . . . . . . . . . . . . . . . 14 78 6.3. Hash Computation . . . . . . . . . . . . . . . . . . . . . 15 79 7. Link-Layer Considerations . . . . . . . . . . . . . . . . . . 16 80 8. Managability Considerations . . . . . . . . . . . . . . . . . 16 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 83 10.1. Associated Channel Type Allocation . . . . . . . . . . . . 17 84 10.2. Allocation of Address Family Numbers . . . . . . . . . . . 18 85 10.3. Creation of G-ACh Advertisement Protocol Application 86 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 10.4. Creation of G-ACh Advertisement Protocol TLV Registry . . 18 88 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 91 12.2. Informative References . . . . . . . . . . . . . . . . . . 19 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 94 1. Introduction 96 The MPLS Generic Associated Channel (G-ACh) is defined and described 97 in [RFC5586]. It provides an auxiliary logical data channel over 98 which a variety of protocols may flow. Each such data channel is 99 associated with an MPLS Label Switched Path (LSP), a pseudowire, or a 100 section (link). An important use of the G-ACh and the protocols it 101 supports is to provide Operations, Administration, and Maintenance 102 (OAM) capabilities for the associated LSP, pseudowire, or section. 103 Examples of such capabilities include Pseudowire Virtual Circuit 104 Connectivity Verification (VCCV) [RFC5085], Bidirectional Forwarding 105 Detection (BFD) for MPLS [RFC5884], and MPLS packet loss, delay, and 106 throughput measurement [RFC6374], as well as OAM functions developed 107 for the MPLS Transport Profile (MPLS-TP) [RFC5921]. 109 This document specifies procedures for an MPLS Label Switching Router 110 (LSR) to advertise its capabilities and configuration parameters, or 111 other application-specific information, to its peers over LSPs, 112 pseudowires, and sections. Receivers can then make use of this 113 information to validate or adjust their own configurations, and 114 network operators can make use of it to diagnose faults and 115 configuration inconsistencies between endpoints. 117 The main principle guiding the design of the MPLS G-ACh Advertisement 118 Protocol (GAP) is simplicity. The protocol provides a one-way method 119 of distributing information about the sender. How this information 120 is used by a given receiver is a local matter. The data elements 121 distributed by the GAP are application-specific and, except for those 122 associated with the GAP itself, are outside the scope of this 123 document. An IANA registry is created to allow GAP applications to 124 be defined as needed. 126 1.1. Motivation 128 It is frequently useful in a network for a node to have general 129 information about its adjacent nodes, i.e., those nodes to which it 130 has links. At a minimum this allows a human operator or management 131 application with access to the node to determine which adjacent nodes 132 this node can see, which is helpful when troubleshooting connectivity 133 problems. A typical example of an "adjacency awareness protocol" is 134 the Link Layer Discovery Protocol [LLDP], which can provide various 135 pieces of information about adjacent nodes in Ethernet networks, such 136 as system name, basic functional capabilities, link speed/duplex 137 settings, and maximum supported frame size. Such data is useful both 138 for human diagnostics and for automated detection of configuration 139 inconsistencies. 141 In MPLS networks, the G-ACh provides a convenient link-layer-agnostic 142 means for communication between LSRs that are adjacent at the link 143 layer. The G-ACh advertisement protocol presented in this document 144 thus allows LSRs to exchange information of a similar sort to that 145 supported by LLDP for Ethernet links. The GAP, however, does not 146 depend on the specific link-layer protocol in use, and can be used to 147 advertise information on behalf of any MPLS application. 149 In networks based on the MPLS Transport Profile (MPLS-TP) [RFC5921] 150 that do not also support IP, the normal protocols used to determine 151 the Ethernet address of an adjacent MPLS node, such as the Address 152 Resolution Protocol [RFC0826] and IP version 6 Neighbor Discovery 153 [RFC4861], are not available. One possible use of the G-ACh 154 advertisement protocol is to discover the Ethernet MAC addresses of 155 MPLS-TP nodes lacking IP capability 156 [I-D.ietf-mpls-tp-ethernet-addressing]. However, where it is 157 anticipated that the only data that needs to be exchanged between 158 LSRs over an Ethernet link are their Ethernet addresses, then the 159 operator may instead choose to use LLDP for that purpose. 161 The applicability of the G-ACh advertisement protocol is not limited 162 to link-layer adjacency, either in terms of message distribution or 163 message content. The G-ACh exists for any MPLS LSP or pseudowire, so 164 GAP messages can be exchanged with remote LSP or pseudowire 165 endpoints. The content of GAP messages is extensible in a simple 166 manner, and can include any kind of information that might be useful 167 to MPLS LSRs connected by links, LSPs, or pseudowires. For example, 168 in networks that rely on the G-ACh for OAM functions, GAP messages 169 might be used to inform adjacent LSRs of a node's OAM capabilities 170 and configuration parameters. 172 1.2. Terminology 174 Term Definition 175 ----- ------------------------------------------- 176 G-ACh Generic Associated Channel 177 GAL G-ACh Label 178 GAP G-ACh Advertisement Protocol 179 LSP Label Switched Path 180 OAM Operations, Administration, and Maintenance 182 1.3. Requirements Language 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. 188 2. Overview 190 The G-ACh Advertisement Protocol has a simple one-way mode of 191 operation: a device configured to send information for a particular 192 data channel (MPLS LSP, pseudowire, or section) transmits GAP 193 messages over the G-ACh associated with the data channel. The 194 payload of a GAP message is a collection of Type-Length-Value (TLV) 195 objects, organized on a per-application basis. An IANA registry is 196 created to identify specific applications. Application TLV objects 197 primarily contain static data that the receiver is meant to retain 198 for a period of time, but may also represent metadata or special 199 processing instructions. 201 Each GAP message can contain data for several applications. A sender 202 may transmit a targeted update that refreshes the data for a subset 203 of applications without affecting the data of other applications sent 204 on a previous message. 206 For example, a GAP message might be sent containing the following 207 data: 209 Application A: A-TLV4, A-TLV15, A-TLV9 211 Application B: B-TLV1, B-TLV3 213 Application C: C-TLV6, 215 where the numbers are specific Type values. 217 A second message might then be sent containing: 219 Application B: B-TLV7, B-TLV3 221 Upon receiving the second message, the receiver retains B-TLV1 from 222 the first message and adds B-TLV7 to its B-database. How it handles 223 the new B-TLV3 depends on the rules B has specified for this object 224 type; this object could replace the old one or be combined with it in 225 some way. The second message has no effect on the databases 226 maintained by the receiver for Applications A and C. 228 The rate at which GAP messages are transmitted is at the discretion 229 of the sender, and may fluctuate over time as well as differ per 230 application. Each message contains, for each application it 231 describes, a lifetime that informs the receiver how long to wait 232 before discarding the data for that application. 234 The GAP itself provides no fragmentation and reassembly mechanisms. 235 In the event that an application wishes to send larger chunks of data 236 via GAP messages than fall within the limits of packet size, it is 237 the responsibility of the application to fragment its data 238 accordingly. 240 Note that for bidirectional channels communication may optimised 241 through the use of a number of messages defined for transmission from 242 the receiver back to the sender. These are optimizations and are not 243 required for protocol operation. 245 3. Message Format 247 An Associated Channel Header (ACH) Channel Type has been allocated 248 for the GAP as follows: 250 Protocol Channel Type 251 ---------------------------------- -------------------- 252 G-ACh Advertisement Protocol 0xXXXX (TBD by IANA) 254 For this Channel Type, the ACH SHALL NOT be followed by the ACH TLV 255 Header defined in [RFC5586]. 257 Fields in this document shown as Reserved or Resv are reserved for 258 future specification and MUST be set to zero. All integer values for 259 fields defined in this document SHALL be encoded in network byte 260 order. 262 A GAP message consists of a fixed header followed by a GAP payload. 263 The payload of a GAP message is an Application Data Block (ADB) 264 consisting of one or more block elements. Each block element 265 contains an application identifier, a lifetime, and a series of TLV 266 objects for the application it describes. 268 The following figure shows the format of a G-ACh Advertisement 269 Protocol message, which follows the Associated Channel Header (ACH): 271 0 1 2 3 272 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 |Version| Reserved | Message Length | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Message Identifier | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Timestamp | 279 | | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 ~ Application Data Block (ADB) ~ 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Figure 1: GAP Message Format 286 The meanings of the fields are: 288 Version: Protocol version, currently set to 0 290 Message Length: Size in octets of this message, i.e. of the 291 portion of the packet following the Associated Channel Header 293 Message Identifier (MI): Unique identifier of this message. A 294 sender MUST NOT re-use an MI over a given channel until the 295 message lifetime has expired. The sole purpose of this field is 296 duplicate detection in the event of a message burst (Section 5.1). 298 Timestamp: 64-bit Network Time Protocol (NTP) transmit timestamp, 299 as specified in Section 6 of [RFC5905] 301 An ADB consists of one or more elements of the following format: 303 0 1 2 3 304 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Application ID | Element Length | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Lifetime | Reserved | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 ~ TLV Object ~ 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 ~ TLV Object ~ 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 . . 315 . . 316 . . 318 Figure 2: Application Data Block Element 320 In this format, the Application ID identifies the application this 321 element describes; an IANA registry has been created to track the 322 values for this field. The Element Length field specifies the total 323 length in octets of this block element (including the Application ID 324 and Element Length fields). 326 The Lifetime field specifies how long, in seconds, the receiver 327 should retain the data in this message (i.e. it specifies the 328 lifetime of the static data carried in the TLV set of this ADB). For 329 TLVs not carrying static data the Lifetime is of no significance. If 330 the Lifetime is zero, TLVs in this ADB are processed by the receiver 331 and the data associated with these TLV types is immediately marked as 332 expired. If the ADB contains no TLVs, the receiver expires all data 333 associated TLVs previously sent to this application. The scope of 334 the Lifetime is the source-channel-application tuple. 336 The remainder of the Application Data Block element consists of a 337 sequence of zero or more TLV objects, which are of the form: 339 0 1 2 3 340 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Type | Reserved | Length | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 ~ Value ~ 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 Figure 3: TLV Object Format 349 The Type field identifies the TLV Object and is scoped to a specific 350 application; each application creates an IANA registry to track its 351 Type values. The Length field specifies the length in octets of the 352 Value field. 354 GAP messages do not contain a checksum. If validation of message 355 integrity is desired, the authentication procedures in Section 6 356 should be used. 358 4. G-ACh Advertisement Protocol TLVs 360 The GAP supports several TLV objects related to its own operation via 361 the Application ID 0x0000. These objects represent metadata and 362 processing instructions rather than static data that is meant to be 363 retained. When an ADB element for the GAP is present in a GAP 364 message, it MUST precede other elements. 366 Any application using the GAP inherits the ability to use facilities 367 provide by Application 0x0000. 369 4.1. Source Address TLV 371 The Source Address object identifies the sending device and possibly 372 the transmitting interface and the channel; it has the following 373 format: 375 0 1 2 3 376 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Type=0 | Reserved | Length | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Reserved | Address Family | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 ~ Address ~ 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 Figure 4: Source Address TLV Format 387 The Address Family field indicates the type of the address; it SHALL 388 be set to one of the assigned values in the IANA "Address Family 389 Numbers" registry. 391 In IP networks a Source Address SHOULD be included in GAP messages 392 and set to an IP address of the sending device; when the channel is a 393 link, this address SHOULD be an address of the transmitting 394 interface. 396 In non-IP MPLS-TP networks a Source Address SHOULD be included in GAP 397 messages and set to the endpoint identifier of the channel. The 398 formats of these channel identifiers SHALL be as given in Sections 399 3.5.1, 3.5.2, and 3.5.3 of [RFC6428] (excluding the initial Type and 400 Length fields shown in those sections). IANA has allocated Address 401 Family Numbers for these identifiers; see Section 10.2. 403 On multipoint channels a Source Address TLV is REQUIRED. 405 4.2. GAP Request TLV 407 This object is a request by the sender for the receiver to transmit 408 an immediate unicast GAP update to the sender. If the Length field 409 is zero, this signifies that an update for all applications is 410 requested. Otherwise, the Value field specifies the applications for 411 which an update is requested, in the form of a sequence of 412 Application IDs: 414 0 1 2 3 415 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Type=1 | Reserved | Length | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Application ID 1 | Application ID 2 | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 . . 422 . . 423 . . 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Application ID N-1 | Application ID N | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Figure 5: GAP Request TLV Format 430 The intent of this TLV is to request the immediate transmission of 431 data following a local event such as a restart rather than waiting 432 for a periodic update. Applications need to determine what 433 information is meaningful to send in response to such a request. 435 For an application 0x0000 GAP Request it is meaningful to respond 436 with the Source Address. 438 4.3. GAP Flush TLV 440 This object is an instruction to the receiver to flush the GAP data 441 for all applications associated with this (sender, channel) pair. It 442 is a null object, i.e. its Length is set to zero. 444 The GAP Flush instruction does not apply to data contained in the 445 message carrying the GAP Flush TLV object itself. Any application 446 data contained in the same message SHALL be processed and retained by 447 the receiver as usual. 449 The flush TLV type is 2. 451 4.4. GAP Suppress TLV 453 This object is a request to the receiver to cease sending GAP updates 454 to the transmitter over the current channel for the specified 455 duration (in seconds). The request is strictly advisory: the 456 receiver SHOULD accept and act on the request, but MAY override it at 457 any time. The format of this object is as follows: 459 0 1 2 3 460 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Type=3 | Reserved | Length | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Duration | Application ID 1 | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 . . 467 . . 468 . . 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Application ID N-1 | Application ID N | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Figure 6: GAP Suppress TLV Format 475 If the Length is set to 2, i.e. if the list of Application IDs is 476 empty, then suppression of all GAP messages is requested; otherwise 477 suppression of only those updates pertaining to the listed 478 applications is requested. A duration of zero cancels any existing 479 suppress requests for the listed applications. 481 This object makes sense only for point-to-point channels or when the 482 sender is receiving unicast GAP updates. 484 4.5. GAP Authentication TLV 486 This object is used to provide authentication and integrity 487 validation for a GAP message. It has the following format: 489 0 1 2 3 490 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Type=4 | Reserved | Length | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Reserved | Key ID | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 ~ Authentication Data ~ 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 Figure 7: GAP Authentication TLV Format 501 The data and procedures associated with this object are explained in 502 Section 6. 504 5. Operation 506 5.1. Message Transmission 508 G-ACh Advertisement Protocol message transmission SHALL operate on a 509 per-data-channel basis and be configurable by the operator 510 accordingly. 512 Because GAP message transmission may be active for many logical 513 channels on the same physical interface, message transmission timers 514 SHOULD be randomized across the channels supported by a given 515 interface so as to reduce the likelihood of large synchronized 516 message bursts. 518 The Message Identifier (MI) uniquely identifies this message and its 519 value is set at the sender's discretion. 521 The Timestamp field SHALL be set to the time at which this message is 522 transmitted. 524 The Lifetime field of each Application Data Block element SHALL be 525 set to the number of seconds the receiver is advised to retain the 526 data associated with this message and application. Lifetimes SHOULD 527 be set in such a way that at least three updates will be sent prior 528 to Lifetime expiration. For example, if updates are sent at least 529 every 60 seconds, a Lifetime of at least 210 seconds would typically 530 used. A sender deletes previously sent data by using the TLV 531 lifetime mechanism as previously described in Section 3 . 533 In some cases additional reliability may be desired for the delivery 534 of a GAP message. When this is the case, the RECOMMENDED procedure 535 is to send three instances of the message in succession, separated by 536 a delay appropriate to the application. This procedure SHOULD be 537 used, if at all, only for messages that are in some sense 538 exceptional; for example when sending a flush instruction following 539 device reset. 541 5.2. Message Reception 543 G-ACh Advertisement Protocol message reception SHALL operate on a 544 per-data-channel basis and be configurable by the operator 545 accordingly. 547 Upon receiving a G-ACh Advertisement Protocol message that contains 548 data for some application X, the receiver determines whether it can 549 interpret X-data. If it cannot, then the receiver MAY retain this 550 data for the number of seconds specified by the Lifetime field; 551 although it cannot parse this data, it may still be of use to the 552 operator. 554 If the receiver can interpret X-data, then it processes the data 555 objects accordingly, retaining the data associated with those that 556 represent static data for the number of seconds specified by the 557 Lifetime field. If the lifetime is zero, such data is immediately 558 marked as expired, and if no TLVs are specified all data associated 559 with previously received TLVs is marked as expired Section 3. If one 560 of the received TLV objects has the same Type as a previously 561 received TLV then the data from the new object SHALL replace the data 562 associated with that Type unless the X specification dictates a 563 different behavior. 565 The receiver MAY make use of the application data contained in a GAP 566 message to perform some level of auto-configuration, for example if 567 the application is an OAM protocol. The application SHOULD, however, 568 take care to prevent cases of oscillation resulting from each 569 endpoint attempting to adjust its configuration to match the other. 570 Any such auto-configuration based on GAP information MUST be disabled 571 by default. 573 The MI may be used to detect and discard duplicate messages. 575 6. Message Authentication 577 The GAP provides a means of authenticating messages and ensuring 578 their integrity. This is accomplished by attaching a GAP 579 Authentication TLV and including, in the Authentication Data field, 580 the output of a cryptographic hash function, the input to which is 581 the message together with a secret key known only to the sender and 582 receiver. Upon receipt of the message, the receiver computes the 583 same hash and compares the result with the hash value in the message; 584 if the hash values are not equal, the message is discarded. 586 The remainder of this section gives the details of this procedure, 587 which is based on the procedures for generic cryptographic 588 authentication for the Intermediate System to Intermediate System 589 (IS-IS) routing protocol as described in [RFC5310]. 591 6.1. Authentication Key Identifiers 593 An Authentication Key Identifier (Key ID) is a 16-bit tag shared by 594 the sender and receiver that identifies a set of authentication 595 parameters. These parameters are not sent over the wire; they are 596 assumed to be associated, on each node, with the Key ID by external 597 means, such as via explicit operator configuration or a separate key- 598 exchange protocol. Multiple Key IDs may be active on the sending and 599 receiving nodes simultaneously, in which case the sender locally 600 selects a Key ID from this set to use in an outbound message. This 601 capability facilitates key migration in the network. 603 The parameters associated with a Key ID are: 605 o Authentication Algorithm: This signifies the authentication 606 algorithm to use to generate or interpret authentication data. At 607 present, the following values are possible: HMAC-SHA-1, HMAC-SHA- 608 224, HMAC-SHA- 256, HMAC-SHA-384, and HMAC-SHA-512. 610 o Authentication Keystring: A secret string that forms the basis for 611 the cryptographic key used by the Authentication Algorithm. 613 Implementors SHOULD consider the use of 614 [I-D.ietf-karp-crypto-key-table] for key management. 616 6.2. Authentication Process 618 The authentication process for GAP messages is straightforward. 619 First, a Key ID is associated on both the sending and receiving nodes 620 with a set of authentication parameters. Following this, when the 621 sender generates a GAP message, it sets the Key ID field of the GAP 622 Authentication TLV accordingly. (The length of the Authentication 623 Data field is also known at this point, because it is a function of 624 the Authentication Algorithm.) The sender then computes a hash for 625 the message as described in Section 6.3 , and fills the 626 Authentication Data field of the GAP Authentication TLV with the hash 627 value. The message is then sent. 629 When the message is received, the receiver computes a hash for it as 630 described below. The receiver compares its computed value to the 631 hash value received in the Authentication Data field. If the two 632 hash values are equal, authentication of the message is considered to 633 have succeeded; otherwise it is considered to have failed. 635 This process suffices to ensure the authenticity and integrity of 636 messages, but is still vulnerable to a replay attack, in which a 637 third party captures a message and sends it on to the receiver at 638 some later time. The GAP message header contains a Timestamp field 639 which can be used to protect against replay attacks. To achieve this 640 protection, the receiver checks that the time recorded in the 641 timestamp field of a received and authenticated GAP message 642 corresponds to the current time, within a reasonable tolerance that 643 allows for message propagation delay, and accepts or rejects the 644 message accordingly. Clock corrections SHOULD be monotonic to avoid 645 replay attack unless operator intervention overrides this to achieve 646 a faster convergence with current time. 648 If the clocks of the sender and receiver are not synchronized with 649 one another, then the receiver must perform the replay check against 650 its best estimate of the current time according to the sender's 651 clock. The timestamps that appear in GAP messages can be used to 652 infer the approximate clock offsets of senders and, while this does 653 not yield high-precision clock synchronization, it suffices for 654 purposes of the replay check with an appropriately chosen tolerance. 656 6.3. Hash Computation 658 In the algorithm description below, the following nomenclature, which 659 is consistent with [FIPS-198], is used: 661 Symbol Definition 662 -------------- ------------------------------------------------------ 663 H The specific hash algorithm, e.g. SHA-256 664 K The Authentication Keystring 665 Ko The cryptographic key used with the hash algorithm 666 B The block size of H, measured in octets rather than in 667 bits. Note that B is the internal block size, not the 668 hash size. This is equal to 64 for SHA-1 and SHA-256, 669 and to 128 for SHA-384 and SHA-512. 670 L The length of the hash, measured in octets rather than 671 in bits 672 XOR The exclusive-or operation 673 Opad The hexadecimal value 0x5c repeated B times 674 Ipad The hexadecimal value 0x36 repeated B times 675 Apad hexadecimal value 0x878FE1F3 repeated (L/4) times 677 1. Preparation of the Key 679 In this application, Ko is always L octets long. 681 If the Authentication Keystring (K) is L octets long, then Ko 682 is equal to K. If the Authentication Keystring (K) is more 683 than L octets long, then Ko is set to H(K). If the 684 Authentication Keystring (K) is less than L octets long, then 685 Ko is set to the Authentication Keystring (K) with zeros 686 appended to the end of the Authentication Keystring (K) such 687 that Ko is L octets long. 689 2. First Hash 691 First, the Authentication Data field is filled with the value 692 Apad. 694 Then, a first hash, also known as the inner hash, is computed 695 as follows: 697 First-Hash = H(Ko XOR Ipad || (GAP Message)) 699 Here the GAP Message is the portion of the packet that follows 700 the Associated Channel Header. 702 3. Second Hash 704 Then a second hash, also known as the outer hash, is computed 705 as follows: 707 Second-Hash = H(Ko XOR Opad || First-Hash) 709 4. Result 711 The resulting second hash becomes the authentication data that 712 is sent in the Authentication Data field of the GAP 713 Authentication TLV. The length of the Authentication Data 714 field is always identical to the message digest size of the 715 specific hash function H that is being used. 717 This also means that the use of hash functions with larger 718 output sizes will increase the size of the GAP message as 719 transmitted on the wire. 721 7. Link-Layer Considerations 723 When the GAP is used to support device discovery on a data link, GAP 724 messages must be sent in such a way that they can be received by 725 other listeners on the link without the sender first knowing the 726 link-layer addresses of the listeners. In short, they must be 727 multicast. Considerations for multicast MPLS encapsulation are 728 discussed in [RFC5332]. For example, Section 8 of [RFC5332] 729 describes how destination Ethernet MAC addresses are selected for 730 multicast MPLS packets. Since a GAP packet transmitted over a data 731 link contains just one label, the G-ACh Label (GAL) with label value 732 13, the correct destination Ethernet address for frames carrying GAP 733 packets intended for device discovery, according to these selection 734 procedures, is 01-00-5e-80-00-0d. 736 8. Managability Considerations 738 The data sent and received by this protocol MUST be made accessible 739 for inspection by network operators, and where local configuration is 740 updated by the received information, it MUST be clear why the 741 configured value has been changed. The persistence of data 742 advertised by this protocol is applications specific, but in general 743 SHOULD be persistent across restarts. Received advertisements MUST 744 be discarded across restarts. If the received values change, the new 745 values MUST be used and the change made visible to the network 746 operators. 748 All applications MUST be disabled by default and need be enabled by 749 the operator if required. 751 9. Security Considerations 753 G-ACh Advertisement Protocol messages contain information about the 754 sending device and its configuration, which is sent in cleartext over 755 the wire. If an unauthorized third party gains access to the MPLS 756 data plane or the lower network layers between the sender and 757 receiver, it can observe this information. In general, however, the 758 information contained in GAP messages is no more sensitive than that 759 contained in other protocol messages, such as routing updates, which 760 are commonly sent in cleartext. No attempt is therefore made to 761 guarantee confidentiality of GAP messages. 763 A more significant potential threat is the transmission of GAP 764 messages by unauthorized sources, or the unauthorized manipulation of 765 messages in transit; this can disrupt the information receivers hold 766 about legitimate senders. To protect against this threat, message 767 authentication procedures are specified in Section 6 of this document 768 that enable receivers to ensure the authenticity and integrity of GAP 769 messages. These procedures include the means to protect against 770 replay attacks, in which a third party captures a legitimate message 771 and "replays" it to a receiver at some later time. 773 10. IANA Considerations 775 10.1. Associated Channel Type Allocation 777 This document requests that IANA allocate an entry in the "Pseudowire 778 Associated Channel Types" registry [RFC5586] (currently located 779 within the "Pseudowire Name Spaces (PWE3)" registry) for the "G-ACh 780 Advertisement Protocol", as follows: 782 Value Description TLV Follows Reference 783 --------- ---------------------------- ----------- ------------ 784 XXXX(TBD) G-ACh Advertisement Protocol No (this draft) 786 10.2. Allocation of Address Family Numbers 788 IANA is requested to allocate three entries from the Standards Track 789 range in the "Address Family Numbers" registry for MPLS-TP Section, 790 LSP, and Pseudowire endpoint identifiers, per Section 4.1. The 791 allocations are: 793 Number Description Reference 794 ------ -------------------------------------- ------------ 795 (TBD) MPLS-TP Section Endpoint Identifier (this draft) 796 (TBD) MPLS-TP LSP Endpoint Identifier (this draft) 797 (TBD) MPLS-TP Pseudowire Endpoint Identifier (this draft) 799 10.3. Creation of G-ACh Advertisement Protocol Application Registry 801 This document requests that IANA create a new registry, "G-ACh 802 Advertisement Protocol Applications" in the "Pseudowire Name Spaces 803 (PWE3)" registry, with fields and initial allocations as follows: 805 Application ID Description Reference 806 -------------- ---------------------------- ------------ 807 0x0000 G-ACh Advertisement Protocol (this draft) 809 The range of the Application ID field is 0x0000 - 0xFFFF. 811 The allocation policy for this registry is IETF Review. 813 10.4. Creation of G-ACh Advertisement Protocol TLV Registry 815 This document requests that IANA create a new registry, "G-ACh 816 Advertisement Protocol: GAP TLV Objects (Application ID 0)" in the 817 "Pseudowire Name Spaces (PWE3)" registry, with fields and initial 818 allocations as follows: 820 Type Name Type ID Reference 821 ------------------ ------- ------------ 822 Source Address 0 (this draft) 823 GAP Request 1 (this draft) 824 GAP Flush 2 (this draft) 825 GAP Suppress 3 (this draft) 826 GAP Authentication 4 (this draft) 828 The range of the Type ID field is 0 - 255. 830 The allocation policy for this registry is IETF Review. 832 11. Acknowledgements 834 We thank Adrian Farrel for his valuable review comments on this 835 document. 837 12. References 839 12.1. Normative References 841 [FIPS-198] 842 US National Institute of Standards and Technology, "The 843 Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 844 198, March 2002. 846 [I-D.ietf-karp-crypto-key-table] 847 Housley, R., Polk, T., Hartman, S., and D. Zhang, 848 "Database of Long-Lived Symmetric Cryptographic Keys", 849 draft-ietf-karp-crypto-key-table-04 (work in progress), 850 October 2012. 852 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 853 Requirement Levels", BCP 14, RFC 2119, March 1997. 855 [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 856 Multicast Encapsulations", RFC 5332, August 2008. 858 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 859 Associated Channel", RFC 5586, June 2009. 861 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 862 Time Protocol Version 4: Protocol and Algorithms 863 Specification", RFC 5905, June 2010. 865 [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive 866 Connectivity Verification, Continuity Check, and Remote 867 Defect Indication for the MPLS Transport Profile", 868 RFC 6428, November 2011. 870 12.2. Informative References 872 [I-D.ietf-mpls-tp-ethernet-addressing] 873 Frost, D., Bryant, S., and M. Bocci, "MPLS-TP Next-Hop 874 Ethernet Addressing", 875 draft-ietf-mpls-tp-ethernet-addressing-05 (work in 876 progress), February 2013. 878 [LLDP] IEEE, "Station and Media Access Control Connectivity 879 Discovery (802.1AB)", September 2009. 881 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 882 converting network protocol addresses to 48.bit Ethernet 883 address for transmission on Ethernet hardware", STD 37, 884 RFC 826, November 1982. 886 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 887 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 888 September 2007. 890 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 891 Connectivity Verification (VCCV): A Control Channel for 892 Pseudowires", RFC 5085, December 2007. 894 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 895 and M. Fanto, "IS-IS Generic Cryptographic 896 Authentication", RFC 5310, February 2009. 898 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 899 "Bidirectional Forwarding Detection (BFD) for MPLS Label 900 Switched Paths (LSPs)", RFC 5884, June 2010. 902 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 903 Berger, "A Framework for MPLS in Transport Networks", 904 RFC 5921, July 2010. 906 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 907 Measurement for MPLS Networks", RFC 6374, September 2011. 909 Authors' Addresses 911 Dan Frost 912 Cisco Systems 914 Email: danfrost@cisco.com 916 Stewart Bryant 917 Cisco Systems 919 Email: stbryant@cisco.com 920 Matthew Bocci 921 Alcatel-Lucent 923 Email: matthew.bocci@alcatel-lucent.com