idnits 2.17.1 draft-ietf-mpls-gach-adv-01.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 (May 23, 2012) is 4356 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 (-08) exists of draft-ietf-mpls-tp-ethernet-addressing-00 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS D. Frost, Ed. 3 Internet-Draft S. Bryant, Ed. 4 Intended status: Standards Track Cisco Systems 5 Expires: November 24, 2012 M. Bocci, Ed. 6 Alcatel-Lucent 7 May 23, 2012 9 MPLS Generic Associated Channel (G-ACh) Advertisement Protocol 10 draft-ietf-mpls-gach-adv-01 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 November 24, 2012. 43 Copyright Notice 45 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. G-ACh Advertisement Protocol TLVs . . . . . . . . . . . . . . 8 67 4.1. Source Address TLV . . . . . . . . . . . . . . . . . . . . 8 68 4.2. GAP Request TLV . . . . . . . . . . . . . . . . . . . . . 8 69 4.3. GAP Flush TLV . . . . . . . . . . . . . . . . . . . . . . 9 70 4.4. GAP Suppress TLV . . . . . . . . . . . . . . . . . . . . . 9 71 4.5. GAP Authentication TLV . . . . . . . . . . . . . . . . . . 10 72 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 5.1. G-ACh Advertisement Message Transmission . . . . . . . . . 11 74 5.2. G-ACh Advertisement Message Reception . . . . . . . . . . 11 75 6. Message Authentication . . . . . . . . . . . . . . . . . . . . 12 76 6.1. Authentication Key Identifiers . . . . . . . . . . . . . . 12 77 6.2. Authentication Process . . . . . . . . . . . . . . . . . . 12 78 6.3. Hash Computation . . . . . . . . . . . . . . . . . . . . . 13 79 7. Link-Layer Considerations . . . . . . . . . . . . . . . . . . 15 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 82 9.1. Associated Channel Type Allocation . . . . . . . . . . . . 15 83 9.2. Allocation of Address Family Numbers . . . . . . . . . . . 16 84 9.3. Creation of G-ACh Advertisement Protocol Application 85 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 9.4. Creation of G-ACh Advertisement Protocol TLV Registry . . 16 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 89 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 92 1. Introduction 94 The MPLS Generic Associated Channel (G-ACh) is defined and described 95 in [RFC5586]. It provides an auxiliary logical data channel 96 associated with an MPLS Label Switched Path (LSP), a pseudowire, or a 97 section (link) over which a variety of protocols may flow. A primary 98 purpose of the G-ACh and the protocols it supports is to provide 99 Operations, Administration, and Maintenance (OAM) capabilities 100 associated with the underlying LSP, pseudowire, or section. Examples 101 of such capabilities include Pseudowire Virtual Circuit Connectivity 102 Verification (VCCV) [RFC5085], Bidirectional Forwarding Detection 103 (BFD) for MPLS [RFC5884], and MPLS packet loss, delay, and throughput 104 measurement [RFC6374], as well as OAM functions developed for the 105 MPLS Transport Profile (MPLS-TP) [RFC5921]. 107 This document specifies procedures for an MPLS Label Switching Router 108 (LSR) to advertise its capabilities and configuration parameters, or 109 other application-specific information, to its peers over LSPs, 110 pseudowires, and sections. Receivers can then make use of this 111 information to validate or adjust their own configurations, and 112 network operators can make use of it to diagnose faults and 113 configuration inconsistencies between endpoints. 115 The main principle guiding the design of the MPLS G-ACh advertisement 116 protocol (GAP) is simplicity. The protocol provides a one-way method 117 of distributing information about the sender. How this information 118 is used by a given receiver is a local matter. The data elements 119 distributed by the GAP are application-specific and, except for those 120 associated with the GAP itself, are outside the scope of this 121 document. An IANA registry is created to allow GAP data elements to 122 be defined as needed. 124 1.1. Motivation 126 It is frequently useful in a network for a node to have general 127 information about its adjacent nodes, i.e., those nodes to which it 128 has links. At a minimum this allows a human operator or management 129 application with access to the node to determine which adjacent nodes 130 this node can see, which is helpful when troubleshooting connectivity 131 problems. A typical example of an "adjacency awareness protocol" is 132 the Link Layer Discovery Protocol [LLDP], which can provide various 133 pieces of information about adjacent nodes in Ethernet networks, such 134 as system name, basic functional capabilities, link speed/duplex 135 settings, and maximum supported frame size. Such data is useful both 136 for human diagnostics and for automated detection of configuration 137 inconsistencies. 139 In MPLS networks, the G-ACh provides a convenient link-layer-agnostic 140 means for communication between LSRs that are adjacent at the link 141 layer. The G-ACh advertisement protocol presented in this document 142 thus allows LSRs to exchange information of a similar sort to that 143 supported by LLDP for Ethernet links. 145 An important special case arises in networks based on the MPLS 146 Transport Profile (MPLS-TP) [RFC5921] that do not also support IP: 147 without IP, protocols for determining the Ethernet address of an 148 adjacent MPLS node, such as the Address Resolution Protocol [RFC0826] 149 and IP version 6 Neighbor Discovery [RFC4861], are not available. 150 The G-ACh advertisement protocol can be used to discover the Ethernet 151 MAC addresses of MPLS nodes lacking IP capability 152 [I-D.ietf-mpls-tp-ethernet-addressing]. 154 The applicability of the G-ACh advertisement protocol is not limited 155 to link-layer adjacency, either in terms of message distribution or 156 message content. The G-ACh exists for any MPLS LSP or pseudowire, so 157 GAP messages can be exchanged with remote LSP or pseudowire 158 endpoints. The content of GAP messages is extensible in a simple 159 manner, and can include any kind of information that might be useful 160 to MPLS LSRs connected by links, LSPs, or pseudowires. For example, 161 in networks that rely on the G-ACh for OAM functions, GAP messages 162 might be used to inform adjacent LSRs of a node's OAM capabilities 163 and configuration parameters. 165 1.2. Terminology 167 Term Definition 168 ----- ------------------------------------------- 169 G-ACh Generic Associated Channel 170 GAL G-ACh Label 171 GAP G-ACh Advertisement Protocol 172 LSP Label Switched Path 173 LSR Label Switching Router 174 OAM Operations, Administration, and Maintenance 176 1.3. Requirements Language 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [RFC2119]. 182 2. Overview 184 The G-ACh Advertisement Protocol has a simple one-way mode of 185 operation: a device configured to send information for a particular 186 data channel (MPLS LSP, pseudowire, or section) transmits GAP 187 messages over the G-ACh associated with the data channel. The 188 payload of a GAP message is a collection of Type-Length-Value (TLV) 189 objects, organized on a per-application basis. An IANA registry is 190 created to identify specific applications. 192 Although one GAP message can contain data for several applications, 193 the receiver maintains the data associated with each application 194 separately. This enables the sender to transmit a targeted update 195 that refreshes the data for a subset of applications without 196 affecting the data of other applications. 198 For example, a GAP message might be sent containing the following 199 data: 201 Application A: A-TLV1, A-TLV2, A-TLV3 203 Application B: B-TLV1 205 Application C: C-TLV1, C-TLV2 207 A second message might then be sent containing: 209 Application B: B-TLV1, B-TLV2 211 Upon receiving the second message, the receiver flushes the old data 212 for Application B and replaces it with the new data. The data 213 associated with Applications A and C from the first message is 214 retained. In other words, the GAP update granularity is per- 215 application, not per-message or per-TLV-object. 217 The rate at which GAP messages are transmitted is at the discretion 218 of the sender, and may fluctuate over time as well as differ per- 219 application. Each message contains, for each application it 220 describes, a lifetime that informs the receiver how long to wait 221 before discarding the data for that application. 223 The GAP itself provides no fragmentation and reassembly mechanisms. 224 In the event that an application wishes to send larger chunks of data 225 via GAP messages than fall within the limits of packet size, it is 226 the responsibility of the application to fragment its data 227 accordingly. 229 3. Message Format 231 An Associated Channel Header (ACH) Channel Type has been allocated 232 for the GAP as follows: 234 Protocol Channel Type 235 ---------------------------------- ------------ 236 G-ACh Advertisement Protocol 0xXXXX 238 For this Channel Type, the ACH SHALL NOT be followed by the ACH TLV 239 Header defined in [RFC5586]. 241 Fields in this document shown as Reserved or Resv are reserved for 242 future specification and MUST be set to zero. All integer values for 243 fields defined in this document SHALL be encoded in network byte 244 order. 246 The payload of a GAP message is an Application Data Block (ADB) 247 consisting of one or more block elements. Each block element 248 contains an application identifier, a lifetime, and a series of TLV 249 objects for the application it describes. 251 The following figure shows the format of a G-ACh Advertisement 252 Protocol message, which follows the Associated Channel Header (ACH): 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 |Version| Reserved | Message Length | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Message Identifier | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Timestamp | 262 | | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 ~ Application Data Block (ADB) ~ 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 GAP Message Format 269 The meanings of the fields are: 271 Version: Protocol version, currently set to 0 273 Message Length: Size in octets of this message, i.e. of the 274 portion of the packet following the Associated Channel Header 276 Message Identifier: Unique identifier of this message 278 Timestamp: 64-bit Network Time Protocol (NTP) transmit timestamp, 279 as specified in Section 6 of [RFC5905] 281 An ADB consists of one or more elements of the following format: 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Application ID | Element Length | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Lifetime | Reserved | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 ~ TLV Object ~ 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 ~ TLV Object ~ 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 . . 295 . . 296 . . 298 Application Data Block Element 300 In this format, the Application ID identifies the application this 301 element describes; an IANA registry has been created to track the 302 values for this field. Any two ADB elements in the same ADB SHALL 303 have distinct Application IDs. The Element Length field specifies 304 the total length in octets of this block element. The Lifetime field 305 specifies how long, in seconds, the receiver should retain the data 306 in this message. 308 The remainder of the Application Data Block element consists of a 309 sequence of TLV objects, which are of the form: 311 0 1 2 3 312 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 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Type | Reserved | Length | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 ~ Value ~ 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 TLV Object Format 321 The Type field identifies the TLV Object; an IANA registry has been 322 created to track the values for this field, which are defined on a 323 per-application basis. The Length field specifies the length in 324 octets of the Value field. 326 It is permissible for the sequence of TLV objects in an ADB element 327 to be empty. This is useful in conjunction with setting the Lifetime 328 to zero in order to instruct the receiver to flush all data 329 associated with this application. 331 GAP messages do not contain a checksum. If validation of message 332 integrity is desired, the authentication procedures in Section 6 333 should be used. 335 4. G-ACh Advertisement Protocol TLVs 337 The GAP supports several TLV objects related to its own operation via 338 the Application ID 0x0000. When an ADB element for the GAP is 339 present in a GAP message, it MUST precede other elements. 341 4.1. Source Address TLV 343 The Source Address object identifies the sending device and possibly 344 the transmitting interface and the channel; it has the following 345 format: 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Type | Reserved | Length | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Reserved | Address Family | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 ~ Address ~ 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Source Address TLV Format 359 The Address Family field indicates the type of the address; it SHALL 360 be set to one of the assigned values in the "IANA Address Family 361 Numbers" registry. 363 In IP networks the Source Address SHOULD be included in GAP messages 364 and set to an IP address of the sending device; when the channel is a 365 link, this address SHOULD be an address of the transmitting 366 interface. 368 In non-IP MPLS-TP networks the Source Address SHOULD be included in 369 GAP messages and set to the endpoint identifier of the channel. The 370 formats of these channel identifiers SHALL be as given in Sections 371 3.5.1, 3.5.2, and 3.5.3 of [RFC6428] (excluding the initial Type and 372 Length fields shown in those sections). 374 4.2. GAP Request TLV 376 This object is a request by the sender for the receiver to transmit 377 an immediate unicast GAP update to the sender. If the Length field 378 is zero, this signifies that an update for all applications is 379 requested. Otherwise, the Value field specifies the applications for 380 which an update is requested, in the form of a sequence of 381 Application IDs: 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Type | Reserved | Length | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Application ID 1 | Application ID 2 | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 . . 391 . . 392 . . 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Application ID N-1 | Application ID N | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 GAP Request TLV Format 399 4.3. GAP Flush TLV 401 This object is an instruction to the receiver to flush the GAP data 402 for all applications associated with this sender. It is a null 403 object, i.e. its Length is set to zero. Note that data for a 404 specific application can be flushed by sending an update for the 405 application with the Lifetime set to zero. 407 The GAP Flush instruction does not apply to data contained in the 408 message carrying the GAP Flush TLV object itself. Any application 409 data contained in the same message SHALL be processed and retained by 410 the receiver as usual. 412 4.4. GAP Suppress TLV 414 This object is a request to the receiver to cease sending GAP updates 415 to the transmitter over the current channel for the specified 416 duration (in seconds). The request is strictly advisory: the 417 receiver SHOULD accept and act on the request, but MAY override it at 418 any time. The format of this object is as follows: 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Type | Reserved | Length | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Duration | Application ID 1 | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 . . 428 . . 429 . . 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Application ID N-1 | Application ID N | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 GAP Suppress TLV Format 436 If the Length is set to 2, i.e. if the list of Application IDs is 437 empty, then suppression of all GAP messages is requested; otherwise 438 suppression of only those updates pertaining to the listed 439 applications is requested. 441 This object makes sense only for point-to-point channels or when the 442 sender is receiving unicast GAP updates. 444 4.5. GAP Authentication TLV 446 This object is used to provide authentication and integrity 447 validation for a GAP message. It has the following format: 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Type | Reserved | Length | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Reserved | Key ID | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 ~ Authentication Data ~ 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 GAP Authentication TLV Format 461 The data and procedures associated with this object are explained in 462 Section 6. 464 5. Operation 465 5.1. G-ACh Advertisement Message Transmission 467 G-ACh Advertisement Protocol message transmission SHALL operate on a 468 per-data-channel basis and be configurable by the operator 469 accordingly. 471 Because GAP message transmission may be active for many logical 472 channels on the same physical interface, message transmission timers 473 SHOULD be randomized across the channels supported by a given 474 interface so as to reduce the likelihood of large synchronized 475 message bursts. 477 The Message Identifier uniquely identifies this message and is set at 478 the sender's discretion. The Timestamp field SHALL be set to the 479 time at which this message is transmitted. 481 The Lifetime field of each Application Data Block element SHALL be 482 set to the number of seconds the receiver is advised to retain the 483 data associated with this message and application. 485 Lifetimes SHOULD be set in such a way that at least three updates 486 will be sent prior to Lifetime expiration. For example, if updates 487 are sent at least every 60 seconds, a Lifetime of 185 seconds may be 488 used. 490 In some cases additional reliability may be desired for the delivery 491 of a GAP message. When this is the case, the RECOMMENDED procedure 492 is to send three instances of the message in succession, separated by 493 a delay appropriate to the application. This procedure SHOULD be 494 used, if at all, only for messages that are in some sense 495 'exceptional'; for example when sending a flush instruction following 496 device reset. 498 5.2. G-ACh Advertisement Message Reception 500 Upon receiving a G-ACh Advertisement Protocol message containing data 501 for a set of applications, the receiver MUST discard any earlier data 502 retained for each application in the set, and SHOULD retain the new 503 data associated with each application in the set by this message for 504 the number of seconds specified by the Lifetime field, or until a 505 newer message describing the application is received. 507 The receiver MAY make use of the application data contained in a GAP 508 message to perform some level of autoconfiguration, for example if 509 the application is an OAM protocol. The implementation SHOULD, 510 however, take care to prevent cases of oscillation resulting from 511 each endpoint attempting to adjust its configuration to match the 512 other. Any such autoconfiguration based on GAP information MUST be 513 disabled by default. 515 6. Message Authentication 517 The GAP provides a means of authenticating messages and ensuring 518 their integrity. This is accomplished by attaching a GAP 519 Authentication TLV and including, in the Authentication Data field, 520 the output of a cryptographic hash function, the input to which is 521 the message together with a secret key known only to the sender and 522 receiver. Upon receipt of the message, the receiver computes the 523 same hash and compares the result with the hash value in the message; 524 if the hash values are not equal, the message is discarded. 526 The remainder of this section gives the details of this procedure, 527 which is based on the procedures for generic cryptographic 528 authentication for the Intermediate System to Intermediate System 529 (IS-IS) routing protocol as described in [RFC5310]. 531 6.1. Authentication Key Identifiers 533 An Authentication Key Identifier (Key ID) is a 16-bit tag shared by 534 the sender and receiver that identifies a set of authentication 535 parameters. These parameters are not sent over the wire; they are 536 assumed to be associated, on each node, with the Key ID by external 537 means, such as via explicit operator configuration or a separate key- 538 exchange protocol. Multiple Key IDs may be active on the sending and 539 receiving nodes simultaneously, in which case the sender locally 540 selects a Key ID from this set to use in an outbound message. This 541 capability facilitates key migration in the network. 543 The parameters associated with a Key ID are: 545 o Authentication Algorithm: This signifies the authentication 546 algorithm to use to generate or interpret authentication data. At 547 present, the following values are possible: HMAC-SHA-1, HMAC-SHA- 548 224, HMAC-SHA- 256, HMAC-SHA-384, and HMAC-SHA-512. 550 o Authentication Keystring: A secret string that forms the basis for 551 the crytographic key used by the Authentication Algorithm. 553 6.2. Authentication Process 555 The authentication process for GAP messages is straightforward. 556 First, a Key ID is associated on both the sending and receiving nodes 557 with a set of authentication parameters. Following this, when the 558 sender generates a GAP message, it sets the Key ID field of the GAP 559 Authentication TLV accordingly. (The length of the Authentication 560 Data field is also known at this point, because it is a function of 561 the Authentication Algorithm.) The sender then computes a hash for 562 the message as described below, and fills the Authentication Data 563 field of the GAP Authentication TLV with the hash value. The message 564 is then sent. 566 When the message is received, the receiver computes a hash for it as 567 described below. The receiver compares its computed value to the 568 hash value received in the Authentication Data field. If the two 569 hash values are equal, authentication of the message is considered to 570 have succeeded; otherwise it is considered to have failed. 572 This process suffices to ensure the authenticity and integrity of 573 messages, but is still vulnerable to a replay attack, in which a 574 third party captures a message and sends it on to the receiver at 575 some later time. The GAP message header contains a Timestamp field 576 which can be used to protect against replay attacks. To achieve this 577 protection, the receiver checks that the time recorded in the 578 timestamp field of a received and authenticated GAP message 579 corresponds to the current time, within a reasonable tolerance that 580 allows for message propagation delay, and accepts or rejects the 581 message accordingly. 583 If the clocks of the sender and receiver are not synchronized with 584 one another, then the receiver must perform the replay check against 585 its best estimate of the current time according to the sender's 586 clock. The timestamps that appear in GAP messages can be used to 587 infer the approximate clock offsets of senders and, while this does 588 not yield high-precision clock synchronization, it suffices for 589 purposes of the replay check with an appropriately chosen tolerance. 591 6.3. Hash Computation 593 In the algorithm description below, the following nomenclature, which 594 is consistent with [FIPS-198], is used: 596 Symbol Definition 597 -------------- ------------------------------------------------------ 598 H The specific hash algorithm, e.g. SHA-256 599 K The Authentication Keystring 600 Ko The cryptographic key used with the hash algorithm 601 B The block size of H, measured in octets rather than in 602 bits. Note that B is the internal block size, not the 603 hash size. This is equal to 64 for SHA-1 and SHA-256, 604 and to 128 for SHA-384 and SHA-512. 605 L The length of the hash, measured in octets rather than 606 in bits 607 XOR The exclusive-or operation 608 Opad The hexadecimal value 0x5c repeated B times 609 Ipad The hexadecimal value 0x36 repeated B times 610 Apad hexadecimal value 0x878FE1F3 repeated (L/4) times 612 1. Preparation of the Key 614 In this application, Ko is always L octets long. 616 If the Authentication Keystring (K) is L octets long, then Ko 617 is equal to K. If the Authentication Keystring (K) is more 618 than L octets long, then Ko is set to H(K). If the 619 Authentication Keystring (K) is less than L octets long, then 620 Ko is set to the Authentication Keystring (K) with zeros 621 appended to the end of the Authentication Keystring (K) such 622 that Ko is L octets long. 624 2. First Hash 626 First, the Authentication Data field is filled with the value 627 Apad. 629 Then, a first hash, also known as the inner hash, is computed 630 as follows: 632 First-Hash = H(Ko XOR Ipad || (GAP Message)) 634 Here the GAP Message is the portion of the packet that follows 635 the Associated Channel Header. 637 3. Second Hash 639 Then a second hash, also known as the outer hash, is computed 640 as follows: 642 Second-Hash = H(Ko XOR Opad || First-Hash) 644 4. Result 646 The resulting second hash becomes the authentication data that 647 is sent in the Authentication Data field of the GAP 648 Authentication TLV. The length of the Authentication Data 649 field is always identical to the message digest size of the 650 specific hash function H that is being used. 652 This also means that the use of hash functions with larger 653 output sizes will increase the size of the GAP message as 654 transmitted on the wire. 656 7. Link-Layer Considerations 658 When the GAP is used to support device discovery on a data link, GAP 659 messages must be sent in such a way that they can be received by 660 other listeners on the link without the sender first knowing the 661 link-layer addresses of the listeners. In short, they must be 662 multicast. Considerations for multicast MPLS encapsulation are 663 discussed in [RFC5332]. For example, Section 8 of [RFC5332] 664 describes how destination Ethernet MAC addresses are selected for 665 multicast MPLS packets. Since a GAP packet transmitted over a data 666 link contains just one label, the G-ACh Label (GAL) with label value 667 13, the correct destination Ethernet address for frames carrying GAP 668 packets intended for device discovery, according to these selection 669 procedures, is 01-00-5e-80-00-0d. 671 8. Security Considerations 673 G-ACh Advertisement Protocol messages contain information about the 674 sending device and its configuration, which is sent in cleartext over 675 the wire. If an unauthorized third party gains access to the MPLS 676 data plane or the lower network layers between the sender and 677 receiver, it can observe this information. In general, however, the 678 information contained in GAP messages is no more sensitive than that 679 contained in other protocol messages, such as routing updates, which 680 are commonly sent in cleartext. No attempt is therefore made to 681 guarantee confidentiality of GAP messages. 683 A more significant potential threat is the transmission of GAP 684 messages by unauthorized sources, or the unauthorized manipulation of 685 messages in transit; this can disrupt the information receivers hold 686 about legitimate senders. To protect against this threat, message 687 authentication procedures are specified in this document that enable 688 receivers to ensure the authenticity and integrity of GAP messages. 689 These procedures include the means to protect against replay attacks, 690 in which a third party captures a legitimate message and "replays" it 691 to a receiver at some later time. 693 9. IANA Considerations 695 9.1. Associated Channel Type Allocation 697 This document requests that IANA allocate an entry in the Pseudowire 698 Associated Channel Types registry [RFC5586] for the G-ACh 699 Advertisement Protocol, as follows: 701 Value Description TLV Follows Reference 702 ----- ---------------------------- ----------- ------------ 703 (TBD) G-ACh Advertisement Protocol No (this draft) 705 9.2. Allocation of Address Family Numbers 707 This document requests that IANA allocate three entries in the 708 Address Family Numbers registry for MPLS-TP Section, LSP, and 709 Pseudowire endpoint identifiers, based on Sections 3.5.1, 3.5.2, and 710 3.5.3 of [RFC6428]. The allocations are: 712 Number Description Reference 713 ------ -------------------------------------- ------------ 714 (TBD) MPLS-TP Section Endpoint Identifier (this draft) 715 (TBD) MPLS-TP LSP Endpoint Identifier (this draft) 716 (TBD) MPLS-TP Pseudowire Endpoint Identifier (this draft) 718 9.3. Creation of G-ACh Advertisement Protocol Application Registry 720 This document requests that IANA create a new registry, "G-ACh 721 Advertisement Protocol Applications", with fields and initial 722 allocations as follows: 724 Application ID Description Reference 725 -------------- ---------------------------- ------------ 726 0x0000 G-ACh Advertisement Protocol (this draft) 728 The range of the Application ID field is 0x0000 - 0xFFFF. 730 The allocation policy for this registry is Specification Required. 732 9.4. Creation of G-ACh Advertisement Protocol TLV Registry 734 This document requests that IANA create a new registry, "G-ACh 735 Advertisement Protocol: GAP TLV Objects", with fields and initial 736 allocations as follows: 738 Type Name Type ID Reference 739 ------------------ ------- ------------ 740 Source Address 0 (this draft) 741 GAP Request 1 (this draft) 742 GAP Flush 2 (this draft) 743 GAP Suppress 3 (this draft) 744 GAP Authentication 4 (this draft) 746 The range of the Type ID field is 0 - 255. 748 The allocation policy for this registry is IETF Review. 750 10. References 752 10.1. Normative References 754 [FIPS-198] 755 US National Institute of Standards and Technology, "The 756 Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 757 198, March 2002. 759 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 760 Requirement Levels", BCP 14, RFC 2119, March 1997. 762 [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 763 Multicast Encapsulations", RFC 5332, August 2008. 765 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 766 Associated Channel", RFC 5586, June 2009. 768 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 769 Time Protocol Version 4: Protocol and Algorithms 770 Specification", RFC 5905, June 2010. 772 [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive 773 Connectivity Verification, Continuity Check, and Remote 774 Defect Indication for the MPLS Transport Profile", 775 RFC 6428, November 2011. 777 10.2. Informative References 779 [I-D.ietf-mpls-tp-ethernet-addressing] 780 Frost, D., Bocci, M., and S. Bryant, "MPLS-TP Next-Hop 781 Ethernet Addressing", 782 draft-ietf-mpls-tp-ethernet-addressing-00 (work in 783 progress), January 2012. 785 [LLDP] IEEE, "Station and Media Access Control Connectivity 786 Discovery (802.1AB)", September 2009. 788 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 789 converting network protocol addresses to 48.bit Ethernet 790 address for transmission on Ethernet hardware", STD 37, 791 RFC 826, November 1982. 793 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 794 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 795 September 2007. 797 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 798 Connectivity Verification (VCCV): A Control Channel for 799 Pseudowires", RFC 5085, December 2007. 801 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 802 and M. Fanto, "IS-IS Generic Cryptographic 803 Authentication", RFC 5310, February 2009. 805 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 806 "Bidirectional Forwarding Detection (BFD) for MPLS Label 807 Switched Paths (LSPs)", RFC 5884, June 2010. 809 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 810 Berger, "A Framework for MPLS in Transport Networks", 811 RFC 5921, July 2010. 813 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 814 Measurement for MPLS Networks", RFC 6374, September 2011. 816 Authors' Addresses 818 Dan Frost (editor) 819 Cisco Systems 821 Email: danfrost@cisco.com 823 Stewart Bryant (editor) 824 Cisco Systems 826 Email: stbryant@cisco.com 828 Matthew Bocci (editor) 829 Alcatel-Lucent 831 Email: matthew.bocci@alcatel-lucent.com