idnits 2.17.1 draft-ietf-mpls-gach-adv-06.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 12, 2013) is 4090 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 16, 2013 M. Bocci 6 Alcatel-Lucent 7 February 12, 2013 9 MPLS Generic Associated Channel (G-ACh) Advertisement Protocol 10 draft-ietf-mpls-gach-adv-06 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 16, 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 . . . . . . . . . . . . . . 9 67 4.1. Source Address TLV . . . . . . . . . . . . . . . . . . . . 9 68 4.2. GAP Request TLV . . . . . . . . . . . . . . . . . . . . . 10 69 4.3. GAP Flush TLV . . . . . . . . . . . . . . . . . . . . . . 10 70 4.4. GAP Suppress TLV . . . . . . . . . . . . . . . . . . . . . 11 71 4.5. GAP Authentication TLV . . . . . . . . . . . . . . . . . . 11 72 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 5.1. Message Transmission . . . . . . . . . . . . . . . . . . . 12 74 5.2. Message Reception . . . . . . . . . . . . . . . . . . . . 13 75 6. Message Authentication . . . . . . . . . . . . . . . . . . . . 14 76 6.1. Authentication Key Identifiers . . . . . . . . . . . . . . 14 77 6.2. Authentication Process . . . . . . . . . . . . . . . . . . 15 78 6.3. Hash Computation . . . . . . . . . . . . . . . . . . . . . 15 79 7. Link-Layer Considerations . . . . . . . . . . . . . . . . . . 17 80 8. Managability Considerations . . . . . . . . . . . . . . . . . 17 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 83 10.1. Associated Channel Type Allocation . . . . . . . . . . . . 18 84 10.2. Allocation of Address Family Numbers . . . . . . . . . . . 18 85 10.3. Creation of G-ACh Advertisement Protocol Application 86 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 10.4. Creation of G-ACh Advertisement Protocol TLV Registry . . 19 88 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 91 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 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 zero 266 or more TLV objects for the application it describes. 268 Malformed GAP messages MUST be discarded by the receiver, although an 269 error MAY be logged. 271 The following figure shows the format of a G-ACh Advertisement 272 Protocol message, which follows the Associated Channel Header (ACH): 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 |Version| Reserved | Message Length | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Message Identifier | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Timestamp | 282 | | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 ~ Application Data Block (ADB) ~ 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 1: GAP Message Format 289 The meanings of the fields are: 291 Version: Protocol version, currently set to 0 293 Message Length: Size in octets of this message, i.e. of the 294 portion of the packet following the Associated Channel Header 296 Message Identifier (MI): Unique identifier of this message. A 297 sender MUST NOT re-use an MI over a given channel until the 298 message lifetime has expired. The sole purpose of this field is 299 duplicate detection in the event of a message burst (Section 5.1). 301 Timestamp: 64-bit Network Time Protocol (NTP) transmit timestamp, 302 as specified in Section 6 of [RFC5905] 304 An ADB consists of one or more elements of the following format: 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Application ID | Element Length | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Lifetime | Reserved | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 ~ TLV Object ~ 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 ~ TLV Object ~ 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 . . 318 . . 319 . . 321 Figure 2: Application Data Block Element 323 In this format, the Application ID identifies the application this 324 element describes; an IANA registry has been created to track the 325 values for this field. More than one block element with the same 326 Application ID may be present in the same ADB, and block elements 327 with different Application IDs may also be present in the same ADB. 328 The protocol rules for the mechanism, including what ADB elements are 329 present and which TLVs are contained in an ADB element, are to be 330 defined in the document that specifies the application-specific 331 usage. 333 Editors note we prefer ", are to be defined in the application's 334 specification." 336 The Element Length field specifies the total length in octets of this 337 block element (including the Application ID and Element Length 338 fields). 340 The Lifetime field specifies how long, in seconds, the receiver 341 should retain the data in this message (i.e. it specifies the 342 lifetime of the static data carried in the TLV set of this ADB). For 343 TLVs not carrying static data the Lifetime is of no significance. If 344 the Lifetime is zero, TLVs in this ADB are processed by the receiver 345 and the data associated with these TLV types is immediately marked as 346 expired. If the ADB contains no TLVs, the receiver expires all data 347 associated TLVs previously sent to this application. The scope of 348 the Lifetime is the source-channel-application tuple. 350 The remainder of the Application Data Block element consists of a 351 sequence of zero or more TLV objects, which are of the form: 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Type | Reserved | Length | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 ~ Value ~ 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 Figure 3: TLV Object Format 363 The Type field identifies the TLV Object and is scoped to a specific 364 application; each application creates an IANA registry to track its 365 Type values. The Length field specifies the length in octets of the 366 Value field. The value field need not be padded to provide 367 alignment. 369 GAP messages do not contain a checksum. If validation of message 370 integrity is desired, the authentication procedures in Section 6 371 should be used. 373 4. G-ACh Advertisement Protocol TLVs 375 The GAP supports several TLV objects related to its own operation via 376 the Application ID 0x0000. These objects represent metadata and 377 processing instructions rather than static data that is meant to be 378 retained. When an ADB element for the GAP is present in a GAP 379 message, it MUST precede other elements. 381 Any application using the GAP inherits the ability to use facilities 382 provide by Application 0x0000. 384 4.1. Source Address TLV 386 The Source Address object identifies the sending device and possibly 387 the transmitting interface and the channel; it has the following 388 format: 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Type=0 | Reserved | Length | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Reserved | Address Family | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 ~ Address ~ 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Figure 4: Source Address TLV Format 402 The Address Family field indicates the type of the address; it SHALL 403 be set to one of the assigned values in the IANA "Address Family 404 Numbers" registry. 406 In IP networks a Source Address SHOULD be included in GAP messages 407 and set to an IP address of the sending device; when the channel is a 408 link, this address SHOULD be an address of the transmitting 409 interface. 411 In non-IP MPLS-TP networks a Source Address SHOULD be included in GAP 412 messages and set to the endpoint identifier of the channel. The 413 formats of these channel identifiers SHALL be as given in Sections 414 3.5.1, 3.5.2, and 3.5.3 of [RFC6428] (excluding the initial Type and 415 Length fields shown in those sections). IANA has allocated Address 416 Family Numbers for these identifiers; see Section 10.2. 418 On multipoint channels a Source Address TLV is REQUIRED. 420 4.2. GAP Request TLV 422 This object is a request by the sender for the receiver to transmit 423 an immediate unicast GAP update to the sender. If the Length field 424 is zero, this signifies that an update for all applications is 425 requested. Otherwise, the Value field specifies the applications for 426 which an update is requested, in the form of a sequence of 427 Application IDs: 429 0 1 2 3 430 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 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Type=1 | Reserved | Length | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Application ID 1 | Application ID 2 | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 . . 437 . . 438 . . 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Application ID N-1 | Application ID N | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 Figure 5: GAP Request TLV Format 445 The intent of this TLV is to request the immediate transmission of 446 data following a local event such as a restart rather than waiting 447 for a periodic update. Applications need to determine what 448 information is meaningful to send in response to such a request. 450 For an application 0x0000 GAP Request it is meaningful to respond 451 with the Source Address. 453 4.3. GAP Flush TLV 455 This object is an instruction to the receiver to flush the GAP data 456 for all applications associated with this (sender, channel) pair. It 457 is a null object, i.e. its Length is set to zero. 459 The GAP Flush instruction does not apply to data contained in the 460 message carrying the GAP Flush TLV object itself. Any application 461 data contained in the same message SHALL be processed and retained by 462 the receiver as usual. 464 The flush TLV type is 2. 466 4.4. GAP Suppress TLV 468 This object is a request to the receiver to cease sending GAP updates 469 to the transmitter over the current channel for the specified 470 duration (in seconds). The receiver MAY accept and act on the 471 request, MAY ignore the request, or MAY resume transmissions at any 472 time according to implementation or configuration choices, and 473 depending on local pragmatics. The format of this object is as 474 follows: 476 0 1 2 3 477 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 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Type=3 | Reserved | Length | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Duration | Application ID 1 | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 . . 484 . . 485 . . 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Application ID N-1 | Application ID N | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 Figure 6: GAP Suppress TLV Format 492 If the Length is set to 2, i.e. if the list of Application IDs is 493 empty, then suppression of all GAP messages is requested; otherwise 494 suppression of only those updates pertaining to the listed 495 applications is requested. A duration of zero cancels any existing 496 suppress requests for the listed applications. 498 This object makes sense only for point-to-point channels or when the 499 sender is receiving unicast GAP updates. 501 4.5. GAP Authentication TLV 503 This object is used to provide authentication and integrity 504 validation for a GAP message. It has the following format: 506 0 1 2 3 507 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 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Type=4 | Reserved | Length | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Reserved | Key ID | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 ~ Authentication Data ~ 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Figure 7: GAP Authentication TLV Format 518 The data and procedures associated with this object are explained in 519 Section 6. 521 5. Operation 523 5.1. Message Transmission 525 G-ACh Advertisement Protocol message transmission SHALL operate on a 526 per-data-channel basis and be configurable by the operator 527 accordingly. 529 Because GAP message transmission may be active for many logical 530 channels on the same physical interface, message transmission timers 531 SHOULD be randomized across the channels supported by a given 532 interface so as to reduce the likelihood of large synchronized 533 message bursts. 535 The Message Identifier (MI) uniquely identifies this message and its 536 value is set at the sender's discretion. 538 The Timestamp field SHALL be set to the time at which this message is 539 transmitted. 541 The Lifetime field of each Application Data Block element SHALL be 542 set to the number of seconds the receiver is advised to retain the 543 data associated with this message and application. 545 When the transmitter wishes the data previously sent in an ADB 546 element to persist then it must refresh the ADB element by sending 547 another update. Refresh times SHOULD be set in such a way that at 548 least three updates will be sent prior to Lifetime expiration. For 549 example, if the Lifetime is set to 210 seconds, then updates should 550 be sent at least once every 60 seconds. 552 A sender may signal that previously sent data SHOULD be marked as 553 expired by setting the ADB element lifetime to zero as previously 554 described in Section 3 . 556 In some cases an application may desire additional reliability for 557 the delivery of some of its data. When this is the case, the 558 transmitter MAY send several (for example three) instances of the 559 message in succession, separated by a delay appropriate to, or 560 specified by, the application. For example this procedure might be 561 invoked when sending a flush instruction following device reset. The 562 expectation is that the receiver will detect duplicate messages using 563 the MI. 565 5.2. Message Reception 567 G-ACh Advertisement Protocol message reception SHALL operate on a 568 per-data-channel basis and be configurable by the operator 569 accordingly. 571 Upon receiving a G-ACh Advertisement Protocol message that contains 572 data for some application X, the receiver determines whether it can 573 interpret X-data. If it cannot, then the receiver MAY retain this 574 data for the number of seconds specified by the Lifetime field; 575 although it cannot parse this data, it may still be of use to the 576 operator. 578 If the receiver can interpret X-data, then it processes the data 579 objects accordingly, retaining the data associated with those that 580 represent static data for the number of seconds specified by the 581 Lifetime field. If the lifetime is zero, such data is immediately 582 marked as expired, and if no TLVs are specified all data associated 583 with previously received TLVs is marked as expired Section 3. If one 584 of the received TLV objects has the same Type as a previously 585 received TLV then the data from the new object SHALL replace the data 586 associated with that Type unless the X specification dictates a 587 different behavior. 589 The receiver MAY make use of the application data contained in a GAP 590 message to perform some level of auto-configuration, for example if 591 the application is an OAM protocol. The application SHOULD, however, 592 take care to prevent cases of oscillation resulting from each 593 endpoint attempting to adjust its configuration to match the other. 594 Any such auto-configuration based on GAP information MUST be disabled 595 by default. 597 The MI may be used to detect and discard duplicate messages. 599 6. Message Authentication 601 The GAP provides a means of authenticating messages and ensuring 602 their integrity. This is accomplished by attaching a GAP 603 Authentication TLV and including, in the Authentication Data field, 604 the output of a cryptographic hash function, the input to which is 605 the message together with a secret key known only to the sender and 606 receiver. Upon receipt of the message, the receiver computes the 607 same hash and compares the result with the hash value in the message; 608 if the hash values are not equal, the message is discarded. 610 The remainder of this section gives the details of this procedure, 611 which is based on the procedures for generic cryptographic 612 authentication for the Intermediate System to Intermediate System 613 (IS-IS) routing protocol as described in [RFC5310]. 615 6.1. Authentication Key Identifiers 617 An Authentication Key Identifier (Key ID) is a 16-bit tag shared by 618 the sender and receiver that identifies a set of authentication 619 parameters. These parameters are not sent over the wire; they are 620 assumed to be associated, on each node, with the Key ID by external 621 means, such as via explicit operator configuration or a separate key- 622 exchange protocol. Multiple Key IDs may be active on the sending and 623 receiving nodes simultaneously, in which case the sender locally 624 selects a Key ID from this set to use in an outbound message. This 625 capability facilitates key migration in the network. 627 The parameters associated with a Key ID are: 629 o Authentication Algorithm: This signifies the authentication 630 algorithm to use to generate or interpret authentication data. At 631 present, the following values are possible: HMAC-SHA-1, HMAC-SHA- 632 224, HMAC-SHA- 256, HMAC-SHA-384, and HMAC-SHA-512. 634 o Authentication Keystring: A secret string that forms the basis for 635 the cryptographic key used by the Authentication Algorithm. 637 Implementors SHOULD consider the use of 638 [I-D.ietf-karp-crypto-key-table] for key management. 640 At the time of this writing, mechanisms for dynamic key management in 641 the absence of IP are not available. Key management in such 642 environments therefore needs to take place via the equipment 643 management system or some other out of band service. The MPLS layer 644 in a network is normally isolated from direct access by users and 645 thus is a relatively protected environment. Thus key turnover is a 646 relatively infrequent event. 648 6.2. Authentication Process 650 The authentication process for GAP messages is straightforward. 651 First, a Key ID is associated on both the sending and receiving nodes 652 with a set of authentication parameters. Following this, when the 653 sender generates a GAP message, it sets the Key ID field of the GAP 654 Authentication TLV accordingly. (The length of the Authentication 655 Data field is also known at this point, because it is a function of 656 the Authentication Algorithm.) The sender then computes a hash for 657 the message as described in Section 6.3 , and fills the 658 Authentication Data field of the GAP Authentication TLV with the hash 659 value. The message is then sent. 661 When the message is received, the receiver computes a hash for it as 662 described below. The receiver compares its computed value to the 663 hash value received in the Authentication Data field. If the two 664 hash values are equal, authentication of the message is considered to 665 have succeeded; otherwise it is considered to have failed. 667 This process suffices to ensure the authenticity and integrity of 668 messages, but is still vulnerable to a replay attack, in which a 669 third party captures a message and sends it on to the receiver at 670 some later time. The GAP message header contains a Timestamp field 671 which can be used to protect against replay attacks. To achieve this 672 protection, the receiver checks that the time recorded in the 673 timestamp field of a received and authenticated GAP message 674 corresponds to the current time, within a reasonable tolerance that 675 allows for message propagation delay, and accepts or rejects the 676 message accordingly. Clock corrections SHOULD be monotonic to avoid 677 replay attack unless operator intervention overrides this to achieve 678 a faster convergence with current time. 680 If the clocks of the sender and receiver are not synchronized with 681 one another, then the receiver must perform the replay check against 682 its best estimate of the current time according to the sender's 683 clock. The timestamps that appear in GAP messages can be used to 684 infer the approximate clock offsets of senders and, while this does 685 not yield high-precision clock synchronization, it suffices for 686 purposes of the replay check with an appropriately chosen tolerance. 688 6.3. Hash Computation 690 In the algorithm description below, the following nomenclature, which 691 is consistent with [FIPS-198], is used: 693 Symbol Definition 694 -------------- ------------------------------------------------------ 695 H The specific hash algorithm, e.g. SHA-256 696 K The Authentication Keystring 697 Ko The cryptographic key used with the hash algorithm 698 B The block size of H, measured in octets rather than in 699 bits. Note that B is the internal block size, not the 700 hash size. This is equal to 64 for SHA-1 and SHA-256, 701 and to 128 for SHA-384 and SHA-512. 702 L The length of the hash, measured in octets rather than 703 in bits 704 XOR The exclusive-or operation 705 Opad The hexadecimal value 0x5c repeated B times 706 Ipad The hexadecimal value 0x36 repeated B times 707 Apad hexadecimal value 0x878FE1F3 repeated (L/4) times 709 1. Preparation of the Key 711 In this application, Ko is always L octets long. 713 If the Authentication Keystring (K) is L octets long, then Ko 714 is equal to K. If the Authentication Keystring (K) is more 715 than L octets long, then Ko is set to H(K). If the 716 Authentication Keystring (K) is less than L octets long, then 717 Ko is set to the Authentication Keystring (K) with zeros 718 appended to the end of the Authentication Keystring (K) such 719 that Ko is L octets long. 721 2. First Hash 723 First, the Authentication Data field is filled with the value 724 Apad. 726 Then, a first hash, also known as the inner hash, is computed 727 as follows: 729 First-Hash = H(Ko XOR Ipad || (GAP Message)) 731 Here the GAP Message is the portion of the packet that follows 732 the Associated Channel Header. 734 3. Second Hash 736 Then a second hash, also known as the outer hash, is computed 737 as follows: 739 Second-Hash = H(Ko XOR Opad || First-Hash) 741 4. Result 743 The resulting second hash becomes the authentication data that 744 is sent in the Authentication Data field of the GAP 745 Authentication TLV. The length of the Authentication Data 746 field is always identical to the message digest size of the 747 specific hash function H that is being used. 749 This also means that the use of hash functions with larger 750 output sizes will increase the size of the GAP message as 751 transmitted on the wire. 753 7. Link-Layer Considerations 755 When the GAP is used to support device discovery on a data link, GAP 756 messages must be sent in such a way that they can be received by 757 other listeners on the link without the sender first knowing the 758 link-layer addresses of the listeners. In short, they must be 759 multicast. Considerations for multicast MPLS encapsulation are 760 discussed in [RFC5332]. For example, Section 8 of [RFC5332] 761 describes how destination Ethernet MAC addresses are selected for 762 multicast MPLS packets. Since a GAP packet transmitted over a data 763 link contains just one label, the G-ACh Label (GAL) with label value 764 13, the correct destination Ethernet address for frames carrying GAP 765 packets intended for device discovery, according to these selection 766 procedures, is 01-00-5e-80-00-0d. 768 8. Managability Considerations 770 The data sent and received by this protocol MUST be made accessible 771 for inspection by network operators, and where local configuration is 772 updated by the received information, it MUST be clear why the 773 configured value has been changed. The persistence of data 774 advertised by this protocol is applications specific, but in general 775 SHOULD be persistent across restarts. Received advertisements MUST 776 be discarded across restarts. If the received values change, the new 777 values MUST be used and the change made visible to the network 778 operators. 780 All applications MUST be disabled by default and need be enabled by 781 the operator if required. 783 9. Security Considerations 785 G-ACh Advertisement Protocol messages contain information about the 786 sending device and its configuration, which is sent in cleartext over 787 the wire. If an unauthorized third party gains access to the MPLS 788 data plane or the lower network layers between the sender and 789 receiver, it can observe this information. In general, however, the 790 information contained in GAP messages is no more sensitive than that 791 contained in other protocol messages, such as routing updates, which 792 are commonly sent in cleartext. No attempt is therefore made to 793 guarantee confidentiality of GAP messages. 795 A more significant potential threat is the transmission of GAP 796 messages by unauthorized sources, or the unauthorized manipulation of 797 messages in transit; this can disrupt the information receivers hold 798 about legitimate senders. To protect against this threat, message 799 authentication procedures are specified in Section 6 of this document 800 that enable receivers to ensure the authenticity and integrity of GAP 801 messages. These procedures include the means to protect against 802 replay attacks, in which a third party captures a legitimate message 803 and "replays" it to a receiver at some later time. 805 10. IANA Considerations 807 10.1. Associated Channel Type Allocation 809 This document requests that IANA allocate an entry in the "Pseudowire 810 Associated Channel Types" registry [RFC5586] (currently located 811 within the "Pseudowire Name Spaces (PWE3)" registry) for the "G-ACh 812 Advertisement Protocol", as follows: 814 Value Description TLV Follows Reference 815 --------- ---------------------------- ----------- ------------ 816 XXXX(TBD) G-ACh Advertisement Protocol No (this draft) 818 10.2. Allocation of Address Family Numbers 820 IANA is requested to allocate three entries from the Standards Track 821 range in the "Address Family Numbers" registry for MPLS-TP Section, 822 LSP, and Pseudowire endpoint identifiers, per Section 4.1. The 823 allocations are: 825 Number Description Reference 826 ------ -------------------------------------- ------------ 827 (TBD) MPLS-TP Section Endpoint Identifier (this draft) 828 (TBD) MPLS-TP LSP Endpoint Identifier (this draft) 829 (TBD) MPLS-TP Pseudowire Endpoint Identifier (this draft) 831 10.3. Creation of G-ACh Advertisement Protocol Application Registry 833 This document requests that IANA create a new registry, "G-ACh 834 Advertisement Protocol Applications" in the "Pseudowire Name Spaces 835 (PWE3)" registry, with fields and initial allocations as follows: 837 Application ID Description Reference 838 -------------- ---------------------------- ------------ 839 0x0000 G-ACh Advertisement Protocol (this draft) 841 The range of the Application ID field is 0x0000 - 0xFFFF. 843 The allocation policy for this registry is IETF Review. 845 10.4. Creation of G-ACh Advertisement Protocol TLV Registry 847 This document requests that IANA create a new registry, "G-ACh 848 Advertisement Protocol: GAP TLV Objects (Application ID 0)" in the 849 "Pseudowire Name Spaces (PWE3)" registry, with fields and initial 850 allocations as follows: 852 Type Name Type ID Reference 853 ------------------ ------- ------------ 854 Source Address 0 (this draft) 855 GAP Request 1 (this draft) 856 GAP Flush 2 (this draft) 857 GAP Suppress 3 (this draft) 858 GAP Authentication 4 (this draft) 860 The range of the Type ID field is 0 - 255. 862 The allocation policy for this registry is IETF Review. 864 11. Acknowledgements 866 We thank Adrian Farrel for his valuable review comments on this 867 document. 869 12. References 871 12.1. Normative References 873 [FIPS-198] 874 US National Institute of Standards and Technology, "The 875 Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 876 198, March 2002. 878 [I-D.ietf-karp-crypto-key-table] 879 Housley, R., Polk, T., Hartman, S., and D. Zhang, 880 "Database of Long-Lived Symmetric Cryptographic Keys", 881 draft-ietf-karp-crypto-key-table-04 (work in progress), 882 October 2012. 884 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 885 Requirement Levels", BCP 14, RFC 2119, March 1997. 887 [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 888 Multicast Encapsulations", RFC 5332, August 2008. 890 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 891 Associated Channel", RFC 5586, June 2009. 893 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 894 Time Protocol Version 4: Protocol and Algorithms 895 Specification", RFC 5905, June 2010. 897 [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive 898 Connectivity Verification, Continuity Check, and Remote 899 Defect Indication for the MPLS Transport Profile", 900 RFC 6428, November 2011. 902 12.2. Informative References 904 [I-D.ietf-mpls-tp-ethernet-addressing] 905 Frost, D., Bryant, S., and M. Bocci, "MPLS-TP Next-Hop 906 Ethernet Addressing", 907 draft-ietf-mpls-tp-ethernet-addressing-05 (work in 908 progress), February 2013. 910 [LLDP] IEEE, "Station and Media Access Control Connectivity 911 Discovery (802.1AB)", September 2009. 913 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 914 converting network protocol addresses to 48.bit Ethernet 915 address for transmission on Ethernet hardware", STD 37, 916 RFC 826, November 1982. 918 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 919 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 920 September 2007. 922 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 923 Connectivity Verification (VCCV): A Control Channel for 924 Pseudowires", RFC 5085, December 2007. 926 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 927 and M. Fanto, "IS-IS Generic Cryptographic 928 Authentication", RFC 5310, February 2009. 930 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 931 "Bidirectional Forwarding Detection (BFD) for MPLS Label 932 Switched Paths (LSPs)", RFC 5884, June 2010. 934 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 935 Berger, "A Framework for MPLS in Transport Networks", 936 RFC 5921, July 2010. 938 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 939 Measurement for MPLS Networks", RFC 6374, September 2011. 941 Authors' Addresses 943 Dan Frost 944 Cisco Systems 946 Email: danfrost@cisco.com 948 Stewart Bryant 949 Cisco Systems 951 Email: stbryant@cisco.com 953 Matthew Bocci 954 Alcatel-Lucent 956 Email: matthew.bocci@alcatel-lucent.com