idnits 2.17.1 draft-ietf-mpls-gach-adv-04.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 (December 6, 2012) is 4157 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-02 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, Ed. 3 Internet-Draft S. Bryant, Ed. 4 Intended status: Standards Track Cisco Systems 5 Expires: June 9, 2013 M. Bocci, Ed. 6 Alcatel-Lucent 7 December 6, 2012 9 MPLS Generic Associated Channel (G-ACh) Advertisement Protocol 10 draft-ietf-mpls-gach-adv-04 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 June 9, 2013. 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4. G-ACh Advertisement Protocol TLVs . . . . . . . . . . . . . . 8 67 4.1. Source Address TLV . . . . . . . . . . . . . . . . . . . . 8 68 4.2. GAP Request TLV . . . . . . . . . . . . . . . . . . . . . 9 69 4.3. GAP Flush TLV . . . . . . . . . . . . . . . . . . . . . . 9 70 4.4. GAP Suppress TLV . . . . . . . . . . . . . . . . . . . . . 9 71 4.5. GAP Authentication TLV . . . . . . . . . . . . . . . . . . 10 72 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 5.1. Message Transmission . . . . . . . . . . . . . . . . . . . 11 74 5.2. Message Reception . . . . . . . . . . . . . . . . . . . . 11 75 6. Message Authentication . . . . . . . . . . . . . . . . . . . . 12 76 6.1. Authentication Key Identifiers . . . . . . . . . . . . . . 12 77 6.2. Authentication Process . . . . . . . . . . . . . . . . . . 13 78 6.3. Hash Computation . . . . . . . . . . . . . . . . . . . . . 14 79 7. Link-Layer Considerations . . . . . . . . . . . . . . . . . . 15 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 9.1. Associated Channel Type Allocation . . . . . . . . . . . . 16 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 . . 17 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 89 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 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. An 98 important use of the G-ACh and the protocols it supports is to 99 provide Operations, Administration, and Maintenance (OAM) 100 capabilities associated with the underlying LSP, pseudowire, or 101 section. Examples of such capabilities include Pseudowire Virtual 102 Circuit Connectivity Verification (VCCV) [RFC5085], Bidirectional 103 Forwarding Detection (BFD) for MPLS [RFC5884], and MPLS packet loss, 104 delay, and throughput measurement [RFC6374], as well as OAM functions 105 developed for the 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 applications 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 In networks based on the MPLS Transport Profile (MPLS-TP) [RFC5921] 146 that do not also support IP, the normal protocols used to determine 147 the Ethernet address of an adjacent MPLS node, such as the Address 148 Resolution Protocol [RFC0826] and IP version 6 Neighbor Discovery 149 [RFC4861], are not available. The G-ACh advertisement protocol can 150 be used to discover the Ethernet MAC addresses of MPLS-TP nodes 151 lacking IP capability [I-D.ietf-mpls-tp-ethernet-addressing]. Where 152 it is anticipated that the sole purpose of the GAP will be to provide 153 Ethernet MAC address learning, the use of LLDP SHOULD be considered. 155 The applicability of the G-ACh advertisement protocol is not limited 156 to link-layer adjacency, either in terms of message distribution or 157 message content. The G-ACh exists for any MPLS LSP or pseudowire, so 158 GAP messages can be exchanged with remote LSP or pseudowire 159 endpoints. The content of GAP messages is extensible in a simple 160 manner, and can include any kind of information that might be useful 161 to MPLS LSRs connected by links, LSPs, or pseudowires. For example, 162 in networks that rely on the G-ACh for OAM functions, GAP messages 163 might be used to inform adjacent LSRs of a node's OAM capabilities 164 and configuration parameters. 166 1.2. Terminology 168 Term Definition 169 ----- ------------------------------------------- 170 G-ACh Generic Associated Channel 171 GAL G-ACh Label 172 GAP G-ACh Advertisement Protocol 173 LSP Label Switched Path 174 LSR Label Switching Router 175 OAM Operations, Administration, and Maintenance 177 1.3. Requirements Language 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in [RFC2119]. 183 2. Overview 185 The G-ACh Advertisement Protocol has a simple one-way mode of 186 operation: a device configured to send information for a particular 187 data channel (MPLS LSP, pseudowire, or section) transmits GAP 188 messages over the G-ACh associated with the data channel. The 189 payload of a GAP message is a collection of Type-Length-Value (TLV) 190 objects, organized on a per-application basis. An IANA registry is 191 created to identify specific applications. Application TLV objects 192 primarily contain static data that the receiver is meant to retain 193 for a period of time, but may also represent metadata or special 194 processing instructions. 196 Although one GAP message can contain data for several applications, 197 the receiver maintains the data associated with each application 198 separately. This enables the sender to transmit a targeted update 199 that refreshes the data for a subset of applications without 200 affecting the data of other applications. 202 For example, a GAP message might be sent containing the following 203 data: 205 Application A: A-TLV4, A-TLV15, A-TLV9 207 Application B: B-TLV1, B-TLV3 209 Application C: C-TLV6, 211 where the numbers are specific Type values. 213 A second message might then be sent containing: 215 Application B: B-TLV7, B-TLV3 217 Upon receiving the second message, the receiver retains B-TLV1 from 218 the first message and adds B-TLV7 to its B-database. How it handles 219 the new B-TLV3 depends on the rules B has specified for this object 220 type; this object could replace the old one or be combined with it in 221 some way. The second message has no effect on the databases 222 maintained by the receiver for Applications A and C. 224 The rate at which GAP messages are transmitted is at the discretion 225 of the sender, and may fluctuate over time as well as differ per 226 application. Each message contains, for each application it 227 describes, a lifetime that informs the receiver how long to wait 228 before discarding the data for that application. 230 The GAP itself provides no fragmentation and reassembly mechanisms. 231 In the event that an application wishes to send larger chunks of data 232 via GAP messages than fall within the limits of packet size, it is 233 the responsibility of the application to fragment its data 234 accordingly. 236 3. Message Format 238 An Associated Channel Header (ACH) Channel Type has been allocated 239 for the GAP as follows: 241 Protocol Channel Type 242 ---------------------------------- ------------ 243 G-ACh Advertisement Protocol 0xXXXX 245 For this Channel Type, the ACH SHALL NOT be followed by the ACH TLV 246 Header defined in [RFC5586]. 248 Fields in this document shown as Reserved or Resv are reserved for 249 future specification and MUST be set to zero. All integer values for 250 fields defined in this document SHALL be encoded in network byte 251 order. 253 A Gap message consits of a fixed header followed by a GAP payload. 254 The payload of a GAP message is an Application Data Block (ADB) 255 consisting of one or more block elements. Each block element 256 contains an application identifier, a lifetime, and a series of TLV 257 objects for the application it describes. 259 The following figure shows the format of a G-ACh Advertisement 260 Protocol message, which follows the Associated Channel Header (ACH): 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 |Version| Reserved | Message Length | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Message Identifier | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Timestamp | 270 | | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 ~ Application Data Block (ADB) ~ 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 GAP Message Format 277 The meanings of the fields are: 279 Version: Protocol version, currently set to 0 281 Message Length: Size in octets of this message, i.e. of the 282 portion of the packet following the Associated Channel Header 283 Message Identifier: Unique identifier of this message 285 Timestamp: 64-bit Network Time Protocol (NTP) transmit timestamp, 286 as specified in Section 6 of [RFC5905] 288 An ADB consists of one or more elements of the following format: 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Application ID | Element Length | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Lifetime | Reserved | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 ~ TLV Object ~ 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 ~ TLV Object ~ 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 . . 302 . . 303 . . 305 Application Data Block Element 307 In this format, the Application ID identifies the application this 308 element describes; an IANA registry has been created to track the 309 values for this field. The Element Length field specifies the total 310 length in octets of this block element (including the Application ID 311 and Element Length fields). The Lifetime field specifies how long, 312 in seconds, the receiver should retain the data in this message. If 313 the lifetime is zero the data is immediately marked as expired. 315 The remainder of the Application Data Block element consists of a 316 sequence of one or more TLV objects, which are of the form: 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Type | Reserved | Length | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 ~ Value ~ 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 TLV Object Format 328 The Type field identifies the TLV Object and is scoped to a specific 329 application; each application creates an IANA registry to track its 330 Type values. The Length field specifies the length in octets of the 331 Value field. 333 GAP messages do not contain a checksum. If validation of message 334 integrity is desired, the authentication procedures in Section 6 335 should be used. 337 4. G-ACh Advertisement Protocol TLVs 339 The GAP supports several TLV objects related to its own operation via 340 the Application ID 0x0000. These objects represent metadata and 341 processing instructions rather than static data that is meant to be 342 retained. When an ADB element for the GAP is present in a GAP 343 message, it MUST precede other elements. 345 Any application using the GAP inherits the ability to use facilities 346 provide by Application 0x0000. 348 4.1. Source Address TLV 350 The Source Address object identifies the sending device and possibly 351 the transmitting interface and the channel; it has the following 352 format: 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Type | Reserved | Length | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Reserved | Address Family | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 ~ Address ~ 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Source Address TLV Format 366 The Address Family field indicates the type of the address; it SHALL 367 be set to one of the assigned values in the IANA "Address Family 368 Numbers" registry. 370 In IP networks a Source Address SHOULD be included in GAP messages 371 and set to an IP address of the sending device; when the channel is a 372 link, this address SHOULD be an address of the transmitting 373 interface. 375 In non-IP MPLS-TP networks a Source Address SHOULD be included in GAP 376 messages and set to the endpoint identifier of the channel. The 377 formats of these channel identifiers SHALL be as given in Sections 378 3.5.1, 3.5.2, and 3.5.3 of [RFC6428] (excluding the initial Type and 379 Length fields shown in those sections). IANA has allocated Address 380 Family Numbers for these identifiers; see Section 9.2. 382 4.2. GAP Request TLV 384 This object is a request by the sender for the receiver to transmit 385 an immediate unicast GAP update to the sender. If the Length field 386 is zero, this signifies that an update for all applications is 387 requested. Otherwise, the Value field specifies the applications for 388 which an update is requested, in the form of a sequence of 389 Application IDs: 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Type | Reserved | Length | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Application ID 1 | Application ID 2 | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 . . 399 . . 400 . . 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Application ID N-1 | Application ID N | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 GAP Request TLV Format 407 4.3. GAP Flush TLV 409 This object is an instruction to the receiver to flush the GAP data 410 for all applications associated with this (sender, channel) pair. It 411 is a null object, i.e. its Length is set to zero. 413 The GAP Flush instruction does not apply to data contained in the 414 message carrying the GAP Flush TLV object itself. Any application 415 data contained in the same message SHALL be processed and retained by 416 the receiver as usual. 418 4.4. GAP Suppress TLV 420 This object is a request to the receiver to cease sending GAP updates 421 to the transmitter over the current channel for the specified 422 duration (in seconds). The request is strictly advisory: the 423 receiver SHOULD accept and act on the request, but MAY override it at 424 any time. The format of this object is as follows: 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Type | Reserved | Length | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Duration | Application ID 1 | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 . . 434 . . 435 . . 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Application ID N-1 | Application ID N | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 GAP Suppress TLV Format 442 If the Length is set to 2, i.e. if the list of Application IDs is 443 empty, then suppression of all GAP messages is requested; otherwise 444 suppression of only those updates pertaining to the listed 445 applications is requested. A duration of zero cancels any existing 446 suppress requests for the listed applications. 448 This object makes sense only for point-to-point channels or when the 449 sender is receiving unicast GAP updates. 451 4.5. GAP Authentication TLV 453 This object is used to provide authentication and integrity 454 validation for a GAP message. It has the following format: 456 0 1 2 3 457 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 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Type | Reserved | Length | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Reserved | Key ID | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 ~ Authentication Data ~ 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 GAP Authentication TLV Format 468 The data and procedures associated with this object are explained in 469 Section 6. 471 5. Operation 473 5.1. Message Transmission 475 G-ACh Advertisement Protocol message transmission SHALL operate on a 476 per-data-channel basis and be configurable by the operator 477 accordingly. 479 Because GAP message transmission may be active for many logical 480 channels on the same physical interface, message transmission timers 481 SHOULD be randomized across the channels supported by a given 482 interface so as to reduce the likelihood of large synchronized 483 message bursts. 485 The Message Identifier (MI) uniquely identifies this message and is 486 set at the sender's discretion. The Timestamp field SHALL be set to 487 the time at which this message is transmitted. 489 The Lifetime field of each Application Data Block element SHALL be 490 set to the number of seconds the receiver is advised to retain the 491 data associated with this message and application. 493 Lifetimes SHOULD be set in such a way that at least three updates 494 will be sent prior to Lifetime expiration. For example, if updates 495 are sent at least every 60 seconds, a Lifetime of 185 seconds may be 496 used. 498 In some cases additional reliability may be desired for the delivery 499 of a GAP message. When this is the case, the RECOMMENDED procedure 500 is to send three instances of the message in succession, separated by 501 a delay appropriate to the application. This procedure SHOULD be 502 used, if at all, only for messages that are in some sense 503 exceptional; for example when sending a flush instruction following 504 device reset. The MI may be used to detect and discard duplicate 505 messages. 507 5.2. Message Reception 509 G-ACh Advertisement Protocol message reception SHALL operate on a 510 per-data-channel basis and be configurable by the operator 511 accordingly. 513 Upon receiving a G-ACh Advertisement Protocol message that contains 514 data for some application X, the receiver determines whether it can 515 interpret X-data. If it cannot, then the receiver MAY retain this 516 data for the number of seconds specified by the Lifetime field; 517 although it cannot parse this data, it may still be of use to the 518 operator. 520 If the receiver can interpret X-data, then it processes the data 521 objects accordingly, retaining those that represent static data for 522 the number of seconds specified by the Lifetime field. If one of 523 these objects has the same Type as an object currently retained by 524 the receiver in its X-database, then the new object SHALL replace the 525 old object in the database unless the X specification dictates a 526 different behavior for this object type. 528 The receiver MAY make use of the application data contained in a GAP 529 message to perform some level of autoconfiguration, for example if 530 the application is an OAM protocol. The implementation SHOULD, 531 however, take care to prevent cases of oscillation resulting from 532 each endpoint attempting to adjust its configuration to match the 533 other. Any such autoconfiguration based on GAP information MUST be 534 disabled by default. 536 6. Message Authentication 538 The GAP provides a means of authenticating messages and ensuring 539 their integrity. This is accomplished by attaching a GAP 540 Authentication TLV and including, in the Authentication Data field, 541 the output of a cryptographic hash function, the input to which is 542 the message together with a secret key known only to the sender and 543 receiver. Upon receipt of the message, the receiver computes the 544 same hash and compares the result with the hash value in the message; 545 if the hash values are not equal, the message is discarded. 547 The remainder of this section gives the details of this procedure, 548 which is based on the procedures for generic cryptographic 549 authentication for the Intermediate System to Intermediate System 550 (IS-IS) routing protocol as described in [RFC5310]. 552 6.1. Authentication Key Identifiers 554 An Authentication Key Identifier (Key ID) is a 16-bit tag shared by 555 the sender and receiver that identifies a set of authentication 556 parameters. These parameters are not sent over the wire; they are 557 assumed to be associated, on each node, with the Key ID by external 558 means, such as via explicit operator configuration or a separate key- 559 exchange protocol. Multiple Key IDs may be active on the sending and 560 receiving nodes simultaneously, in which case the sender locally 561 selects a Key ID from this set to use in an outbound message. This 562 capability facilitates key migration in the network. 564 The parameters associated with a Key ID are: 566 o Authentication Algorithm: This signifies the authentication 567 algorithm to use to generate or interpret authentication data. At 568 present, the following values are possible: HMAC-SHA-1, HMAC-SHA- 569 224, HMAC-SHA- 256, HMAC-SHA-384, and HMAC-SHA-512. 571 o Authentication Keystring: A secret string that forms the basis for 572 the cryptographic key used by the Authentication Algorithm. 574 6.2. Authentication Process 576 The authentication process for GAP messages is straightforward. 577 First, a Key ID is associated on both the sending and receiving nodes 578 with a set of authentication parameters. Following this, when the 579 sender generates a GAP message, it sets the Key ID field of the GAP 580 Authentication TLV accordingly. (The length of the Authentication 581 Data field is also known at this point, because it is a function of 582 the Authentication Algorithm.) The sender then computes a hash for 583 the message as described in Section 6.3 , and fills the 584 Authentication Data field of the GAP Authentication TLV with the hash 585 value. The message is then sent. 587 When the message is received, the receiver computes a hash for it as 588 described below. The receiver compares its computed value to the 589 hash value received in the Authentication Data field. If the two 590 hash values are equal, authentication of the message is considered to 591 have succeeded; otherwise it is considered to have failed. 593 This process suffices to ensure the authenticity and integrity of 594 messages, but is still vulnerable to a replay attack, in which a 595 third party captures a message and sends it on to the receiver at 596 some later time. The GAP message header contains a Timestamp field 597 which can be used to protect against replay attacks. To achieve this 598 protection, the receiver checks that the time recorded in the 599 timestamp field of a received and authenticated GAP message 600 corresponds to the current time, within a reasonable tolerance that 601 allows for message propagation delay, and accepts or rejects the 602 message accordingly. 604 If the clocks of the sender and receiver are not synchronized with 605 one another, then the receiver must perform the replay check against 606 its best estimate of the current time according to the sender's 607 clock. The timestamps that appear in GAP messages can be used to 608 infer the approximate clock offsets of senders and, while this does 609 not yield high-precision clock synchronization, it suffices for 610 purposes of the replay check with an appropriately chosen tolerance. 612 Implementors SHOULD consider the use of 613 [I-D.ietf-karp-crypto-key-table] for key management. 615 6.3. Hash Computation 617 In the algorithm description below, the following nomenclature, which 618 is consistent with [FIPS-198], is used: 620 Symbol Definition 621 -------------- ------------------------------------------------------ 622 H The specific hash algorithm, e.g. SHA-256 623 K The Authentication Keystring 624 Ko The cryptographic key used with the hash algorithm 625 B The block size of H, measured in octets rather than in 626 bits. Note that B is the internal block size, not the 627 hash size. This is equal to 64 for SHA-1 and SHA-256, 628 and to 128 for SHA-384 and SHA-512. 629 L The length of the hash, measured in octets rather than 630 in bits 631 XOR The exclusive-or operation 632 Opad The hexadecimal value 0x5c repeated B times 633 Ipad The hexadecimal value 0x36 repeated B times 634 Apad hexadecimal value 0x878FE1F3 repeated (L/4) times 636 1. Preparation of the Key 638 In this application, Ko is always L octets long. 640 If the Authentication Keystring (K) is L octets long, then Ko 641 is equal to K. If the Authentication Keystring (K) is more 642 than L octets long, then Ko is set to H(K). If the 643 Authentication Keystring (K) is less than L octets long, then 644 Ko is set to the Authentication Keystring (K) with zeros 645 appended to the end of the Authentication Keystring (K) such 646 that Ko is L octets long. 648 2. First Hash 650 First, the Authentication Data field is filled with the value 651 Apad. 653 Then, a first hash, also known as the inner hash, is computed 654 as follows: 656 First-Hash = H(Ko XOR Ipad || (GAP Message)) 658 Here the GAP Message is the portion of the packet that follows 659 the Associated Channel Header. 661 3. Second Hash 663 Then a second hash, also known as the outer hash, is computed 664 as follows: 666 Second-Hash = H(Ko XOR Opad || First-Hash) 668 4. Result 670 The resulting second hash becomes the authentication data that 671 is sent in the Authentication Data field of the GAP 672 Authentication TLV. The length of the Authentication Data 673 field is always identical to the message digest size of the 674 specific hash function H that is being used. 676 This also means that the use of hash functions with larger 677 output sizes will increase the size of the GAP message as 678 transmitted on the wire. 680 7. Link-Layer Considerations 682 When the GAP is used to support device discovery on a data link, GAP 683 messages must be sent in such a way that they can be received by 684 other listeners on the link without the sender first knowing the 685 link-layer addresses of the listeners. In short, they must be 686 multicast. Considerations for multicast MPLS encapsulation are 687 discussed in [RFC5332]. For example, Section 8 of [RFC5332] 688 describes how destination Ethernet MAC addresses are selected for 689 multicast MPLS packets. Since a GAP packet transmitted over a data 690 link contains just one label, the G-ACh Label (GAL) with label value 691 13, the correct destination Ethernet address for frames carrying GAP 692 packets intended for device discovery, according to these selection 693 procedures, is 01-00-5e-80-00-0d. 695 8. Security Considerations 697 G-ACh Advertisement Protocol messages contain information about the 698 sending device and its configuration, which is sent in cleartext over 699 the wire. If an unauthorized third party gains access to the MPLS 700 data plane or the lower network layers between the sender and 701 receiver, it can observe this information. In general, however, the 702 information contained in GAP messages is no more sensitive than that 703 contained in other protocol messages, such as routing updates, which 704 are commonly sent in cleartext. No attempt is therefore made to 705 guarantee confidentiality of GAP messages. 707 A more significant potential threat is the transmission of GAP 708 messages by unauthorized sources, or the unauthorized manipulation of 709 messages in transit; this can disrupt the information receivers hold 710 about legitimate senders. To protect against this threat, message 711 authentication procedures are specified in this document that enable 712 receivers to ensure the authenticity and integrity of GAP messages. 713 These procedures include the means to protect against replay attacks, 714 in which a third party captures a legitimate message and "replays" it 715 to a receiver at some later time. 717 9. IANA Considerations 719 9.1. Associated Channel Type Allocation 721 This document requests that IANA allocate an entry in the "Pseudowire 722 Associated Channel Types" registry [RFC5586] (currently located 723 within the "Pseudowire Name Spaces (PWE3)" registry) for the "G-ACh 724 Advertisement Protocol", as follows: 726 Value Description TLV Follows Reference 727 ----- ---------------------------- ----------- ------------ 728 (TBD) G-ACh Advertisement Protocol No (this draft) 730 9.2. Allocation of Address Family Numbers 732 IANA is requested to allocate three entries from the Standards Track 733 range in the "Address Family Numbers" registry for MPLS-TP Section, 734 LSP, and Pseudowire endpoint identifiers, per Section 4.1. The 735 allocations are: 737 Number Description Reference 738 ------ -------------------------------------- ------------ 739 (TBD) MPLS-TP Section Endpoint Identifier (this draft) 740 (TBD) MPLS-TP LSP Endpoint Identifier (this draft) 741 (TBD) MPLS-TP Pseudowire Endpoint Identifier (this draft) 743 9.3. Creation of G-ACh Advertisement Protocol Application Registry 745 This document requests that IANA create a new registry, "G-ACh 746 Advertisement Protocol Applications" in the "Pseudowire Name Spaces 747 (PWE3)" registry, with fields and initial allocations as follows: 749 Application ID Description Reference 750 -------------- ---------------------------- ------------ 751 0x0000 G-ACh Advertisement Protocol (this draft) 753 The range of the Application ID field is 0x0000 - 0xFFFF. 755 The allocation policy for this registry is IETF Review. 757 9.4. Creation of G-ACh Advertisement Protocol TLV Registry 759 This document requests that IANA create a new registry, "G-ACh 760 Advertisement Protocol: GAP TLV Objects (Application ID 0)" in the 761 "Pseudowire Name Spaces (PWE3)" registry, with fields and initial 762 allocations as follows: 764 Type Name Type ID Reference 765 ------------------ ------- ------------ 766 Source Address 0 (this draft) 767 GAP Request 1 (this draft) 768 GAP Flush 2 (this draft) 769 GAP Suppress 3 (this draft) 770 GAP Authentication 4 (this draft) 772 The range of the Type ID field is 0 - 255. 774 The allocation policy for this registry is IETF Review. 776 10. References 778 10.1. Normative References 780 [FIPS-198] 781 US National Institute of Standards and Technology, "The 782 Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 783 198, March 2002. 785 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 786 Requirement Levels", BCP 14, RFC 2119, March 1997. 788 [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 789 Multicast Encapsulations", RFC 5332, August 2008. 791 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 792 Associated Channel", RFC 5586, June 2009. 794 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 795 Time Protocol Version 4: Protocol and Algorithms 796 Specification", RFC 5905, June 2010. 798 [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive 799 Connectivity Verification, Continuity Check, and Remote 800 Defect Indication for the MPLS Transport Profile", 801 RFC 6428, November 2011. 803 10.2. Informative References 805 [I-D.ietf-karp-crypto-key-table] 806 Housley, R., Polk, T., Hartman, S., and D. Zhang, 807 "Database of Long-Lived Symmetric Cryptographic Keys", 808 draft-ietf-karp-crypto-key-table-04 (work in progress), 809 October 2012. 811 [I-D.ietf-mpls-tp-ethernet-addressing] 812 Frost, D., Bryant, S., and M. Bocci, "MPLS-TP Next-Hop 813 Ethernet Addressing", 814 draft-ietf-mpls-tp-ethernet-addressing-02 (work in 815 progress), November 2012. 817 [LLDP] IEEE, "Station and Media Access Control Connectivity 818 Discovery (802.1AB)", September 2009. 820 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 821 converting network protocol addresses to 48.bit Ethernet 822 address for transmission on Ethernet hardware", STD 37, 823 RFC 826, November 1982. 825 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 826 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 827 September 2007. 829 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 830 Connectivity Verification (VCCV): A Control Channel for 831 Pseudowires", RFC 5085, December 2007. 833 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 834 and M. Fanto, "IS-IS Generic Cryptographic 835 Authentication", RFC 5310, February 2009. 837 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 838 "Bidirectional Forwarding Detection (BFD) for MPLS Label 839 Switched Paths (LSPs)", RFC 5884, June 2010. 841 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 842 Berger, "A Framework for MPLS in Transport Networks", 843 RFC 5921, July 2010. 845 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 846 Measurement for MPLS Networks", RFC 6374, September 2011. 848 Authors' Addresses 850 Dan Frost (editor) 851 Cisco Systems 853 Email: danfrost@cisco.com 855 Stewart Bryant (editor) 856 Cisco Systems 858 Email: stbryant@cisco.com 860 Matthew Bocci (editor) 861 Alcatel-Lucent 863 Email: matthew.bocci@alcatel-lucent.com