0                   1                   2                   3
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type=4    |    Reserved   |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Reserved             |            Key ID             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                    Authentication Data                        ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          

Figure 7: GAP Authentication TLV Format

The data and procedures associated with this object are explained in Section 6.

5. Operation

5.1. Message Transmission

G-ACh Advertisement Protocol message transmission SHALL operate on a per-data-channel basis and be configurable by the operator accordingly.

Because GAP message transmission may be active for many logical channels on the same physical interface, message transmission timers SHOULD be randomized across the channels supported by a given interface so as to reduce the likelihood of large synchronized message bursts.

The Message Identifier (MI) uniquely identifies this message and its value is set at the sender's discretion.

The Timestamp field SHALL be set to the time at which this message is transmitted.

The Lifetime field of each Application Data Block element SHALL be set to the number of seconds the receiver is advised to retain the data associated with this message and application.

When the transmitter wishes the data previously sent in an ADB element to persist then it must refresh the ADB element by sending another update. Refresh times SHOULD be set in such a way that at least three updates will be sent prior to Lifetime expiration. For example, if the Lifetime is set to 210 seconds, then updates should be sent at least once every 60 seconds.

A sender may signal that previously sent data SHOULD be marked as expired by setting the ADB element lifetime to zero as previously described in Section 3 .

In some cases an application may desire additional reliability for the delivery of some of its data. When this is the case, the transmitter MAY send several (for example three) instances of the message in succession, separated by a delay appropriate to, or specified by, the application. For example this procedure might be invoked when sending a flush instruction following device reset. The expectation is that the receiver will detect duplicate messages using the MI.

5.2. Message Reception

G-ACh Advertisement Protocol message reception SHALL operate on a per-data-channel basis and be configurable by the operator accordingly.

Upon receiving a G-ACh Advertisement Protocol message that contains data for some application X, the receiver determines whether it can interpret X-data. If it cannot, then the receiver MAY retain this data for the number of seconds specified by the Lifetime field; although it cannot parse this data, it may still be of use to the operator.

If the receiver can interpret X-data, then it processes the data objects accordingly, retaining the data associated with those that represent static data for the number of seconds specified by the Lifetime field. If the lifetime is zero, such data is immediately marked as expired, and if no TLVs are specified all data associated with previously received TLVs is marked as expired Section 3. If one of the received TLV objects has the same Type as a previously received TLV then the data from the new object SHALL replace the data associated with that Type unless the X specification dictates a different behavior.

The receiver MAY make use of the application data contained in a GAP message to perform some level of auto-configuration, for example if the application is an OAM protocol. The application SHOULD, however, take care to prevent cases of oscillation resulting from each endpoint attempting to adjust its configuration to match the other. Any such auto-configuration based on GAP information MUST be disabled by default.

The MI may be used to detect and discard duplicate messages.

6. Message Authentication

The GAP provides a means of authenticating messages and ensuring their integrity. This is accomplished by attaching a GAP Authentication TLV and including, in the Authentication Data field, the output of a cryptographic hash function, the input to which is the message together with a secret key known only to the sender and receiver. Upon receipt of the message, the receiver computes the same hash and compares the result with the hash value in the message; if the hash values are not equal, the message is discarded.

The remainder of this section gives the details of this procedure, which is based on the procedures for generic cryptographic authentication for the Intermediate System to Intermediate System (IS-IS) routing protocol as described in [RFC5310].

6.1. Authentication Key Identifiers

An Authentication Key Identifier (Key ID) is a 16-bit tag shared by the sender and receiver that identifies a set of authentication parameters. These parameters are not sent over the wire; they are assumed to be associated, on each node, with the Key ID by external means, such as via explicit operator configuration or a separate key-exchange protocol. Multiple Key IDs may be active on the sending and receiving nodes simultaneously, in which case the sender locally selects a Key ID from this set to use in an outbound message. This capability facilitates key migration in the network.

The parameters associated with a Key ID are: [I-D.ietf-karp-crypto-key-table] for key management.

• Authentication Algorithm: This signifies the authentication algorithm to use to generate or interpret authentication data. At present, the following values are possible: HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA- 256, HMAC-SHA-384, and HMAC-SHA-512.
• Authentication Keystring: A secret string that forms the basis for the cryptographic key used by the Authentication Algorithm.

Implementors SHOULD consider the use of

At the time of this writing, mechanisms for dynamic key management in the absence of IP are not available. Key management in such environments therefore needs to take place via the equipment management system or some other out of band service. The MPLS layer in a network is normally isolated from direct access by users and thus is a relatively protected environment. Thus key turnover is a relatively infrequent event.

6.2. Authentication Process

The authentication process for GAP messages is straightforward. First, a Key ID is associated on both the sending and receiving nodes with a set of authentication parameters. Following this, when the sender generates a GAP message, it sets the Key ID field of the GAP Authentication TLV accordingly. (The length of the Authentication Data field is also known at this point, because it is a function of the Authentication Algorithm.) The sender then computes a hash for the message as described in Section 6.3 , and fills the Authentication Data field of the GAP Authentication TLV with the hash value. The message is then sent.

When the message is received, the receiver computes a hash for it as described below. The receiver compares its computed value to the hash value received in the Authentication Data field. If the two hash values are equal, authentication of the message is considered to have succeeded; otherwise it is considered to have failed.

This process suffices to ensure the authenticity and integrity of messages, but is still vulnerable to a replay attack, in which a third party captures a message and sends it on to the receiver at some later time. The GAP message header contains a Timestamp field which can be used to protect against replay attacks. To achieve this protection, the receiver checks that the time recorded in the timestamp field of a received and authenticated GAP message corresponds to the current time, within a reasonable tolerance that allows for message propagation delay, and accepts or rejects the message accordingly. Clock corrections SHOULD be monotonic to avoid replay attack unless operator intervention overrides this to achieve a faster convergence with current time.

If the clocks of the sender and receiver are not synchronized with one another, then the receiver must perform the replay check against its best estimate of the current time according to the sender's clock. The timestamps that appear in GAP messages can be used to infer the approximate clock offsets of senders and, while this does not yield high-precision clock synchronization, it suffices for purposes of the replay check with an appropriately chosen tolerance.

6.3. Hash Computation

In the algorithm description below, the following nomenclature, which is consistent with [FIPS-198], is used:

Symbol	Definition
H	The specific hash algorithm, e.g. SHA-256
K	The Authentication Keystring
Ko	The cryptographic key used with the hash algorithm
B	The block size of H, measured in octets rather than in bits. Note that B is the internal block size, not the hash size. This is equal to 64 for SHA-1 and SHA-256, and to 128 for SHA-384 and SHA-512.
L	The length of the hash, measured in octets rather than in bits
XOR	The exclusive-or operation
Opad	The hexadecimal value 0x5c repeated B times
Ipad	The hexadecimal value 0x36 repeated B times
Apad	hexadecimal value 0x878FE1F3 repeated (L/4) times

1. Preparation of the Key
   • In this application, Ko is always L octets long.
   • If the Authentication Keystring (K) is L octets long, then Ko is equal to K. If the Authentication Keystring (K) is more than L octets long, then Ko is set to H(K). If the Authentication Keystring (K) is less than L octets long, then Ko is set to the Authentication Keystring (K) with zeros appended to the end of the Authentication Keystring (K) such that Ko is L octets long.
2. First Hash
   • First, the Authentication Data field is filled with the value Apad.
   • Then, a first hash, also known as the inner hash, is computed as follows:
     • First-Hash = H(Ko XOR Ipad || (GAP Message))
   • Here the GAP Message is the portion of the packet that follows the Associated Channel Header.
3. Second Hash
   • Then a second hash, also known as the outer hash, is computed as follows:
     • Second-Hash = H(Ko XOR Opad || First-Hash)
4. Result
   • The resulting second hash becomes the authentication data that is sent in the Authentication Data field of the GAP Authentication TLV. The length of the Authentication Data field is always identical to the message digest size of the specific hash function H that is being used.
   • This also means that the use of hash functions with larger output sizes will increase the size of the GAP message as transmitted on the wire.

7. Link-Layer Considerations

When the GAP is used to support device discovery on a data link, GAP messages must be sent in such a way that they can be received by other listeners on the link without the sender first knowing the link-layer addresses of the listeners. In short, they must be multicast. Considerations for multicast MPLS encapsulation are discussed in [RFC5332]. For example, Section 8 of [RFC5332] describes how destination Ethernet MAC addresses are selected for multicast MPLS packets. Since a GAP packet transmitted over a data link contains just one label, the G-ACh Label (GAL) with label value 13, the correct destination Ethernet address for frames carrying GAP packets intended for device discovery, according to these selection procedures, is 01-00-5e-80-00-0d.

8. Managability Considerations

The data sent and received by this protocol MUST be made accessible for inspection by network operators, and where local configuration is updated by the received information, it MUST be clear why the configured value has been changed. The persistence of data advertised by this protocol is applications specific, but in general SHOULD be persistent across restarts. Received advertisements MUST be discarded across restarts. If the received values change, the new values MUST be used and the change made visible to the network operators.

All applications MUST be disabled by default and need be enabled by the operator if required.

9. Security Considerations

G-ACh Advertisement Protocol messages contain information about the sending device and its configuration, which is sent in cleartext over the wire. If an unauthorized third party gains access to the MPLS data plane or the lower network layers between the sender and receiver, it can observe this information. In general, however, the information contained in GAP messages is no more sensitive than that contained in other protocol messages, such as routing updates, which are commonly sent in cleartext. No attempt is therefore made to guarantee confidentiality of GAP messages.

A more significant potential threat is the transmission of GAP messages by unauthorized sources, or the unauthorized manipulation of messages in transit; this can disrupt the information receivers hold about legitimate senders. To protect against this threat, message authentication procedures are specified in Section 6 of this document that enable receivers to ensure the authenticity and integrity of GAP messages. These procedures include the means to protect against replay attacks, in which a third party captures a legitimate message and "replays" it to a receiver at some later time.

10. IANA Considerations

10.1. Associated Channel Type Allocation

This document requests that IANA allocate an entry in the "Pseudowire Associated Channel Types" registry [RFC5586] (currently located within the "Pseudowire Name Spaces (PWE3)" registry) for the "G-ACh Advertisement Protocol", as follows:

Value	Description	TLV Follows	Reference
XXXX(TBD)	G-ACh Advertisement Protocol	No	(this draft)

10.2. Allocation of Address Family Numbers

IANA is requested to allocate three entries from the Standards Track range in the "Address Family Numbers" registry for MPLS-TP Section, LSP, and Pseudowire endpoint identifiers, per Section 4.1. The allocations are:

Number	Description	Reference
(TBD)	MPLS-TP Section Endpoint Identifier	(this draft)
(TBD)	MPLS-TP LSP Endpoint Identifier	(this draft)
(TBD)	MPLS-TP Pseudowire Endpoint Identifier	(this draft)

10.3. Creation of G-ACh Advertisement Protocol Application Registry

This document requests that IANA create a new registry, "G-ACh Advertisement Protocol Applications" in the "Pseudowire Name Spaces (PWE3)" registry, with fields and initial allocations as follows:

Application ID	Description	Reference
0x0000	G-ACh Advertisement Protocol	(this draft)

The range of the Application ID field is 0x0000 - 0xFFFF.

The allocation policy for this registry is IETF Review.

10.4. Creation of G-ACh Advertisement Protocol TLV Registry

This document requests that IANA create a new registry, "G-ACh Advertisement Protocol: GAP TLV Objects (Application ID 0)" in the "Pseudowire Name Spaces (PWE3)" registry, with fields and initial allocations as follows:

Type Name	Type ID	Reference
Source Address	0	(this draft)
GAP Request	1	(this draft)
GAP Flush	2	(this draft)
GAP Suppress	3	(this draft)
GAP Authentication	4	(this draft)

The range of the Type ID field is 0 - 255.

The allocation policy for this registry is IETF Review.

11. Acknowledgements

We thank Adrian Farrel for his valuable review comments on this document.

12. References

12.1. Normative References

[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5332]	Eckert, T., Rosen, E., Aggarwal, R. and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008.
[RFC5586]	Bocci, M., Vigoureux, M. and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5905]	Mills, D., Martin, J., Burbank, J. and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC6428]	Allan, D., Swallow Ed. , G. and J. Drake Ed. , "Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile", RFC 6428, November 2011.
[FIPS-198]	US National Institute of Standards and Technology, "The Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 198, March 2002.
[I-D.ietf-karp-crypto-key-table]	Housley, R., Polk, T., Hartman, S. and D. Zhang, "Database of Long-Lived Symmetric Cryptographic Keys", Internet-Draft draft-ietf-karp-crypto-key-table-06, February 2013.

12.2. Informative References

[I-D.ietf-mpls-tp-ethernet-addressing]	Frost, D., Bryant, S. and M. Bocci, "MPLS-TP Next-Hop Ethernet Addressing", Internet-Draft draft-ietf-mpls-tp-ethernet-addressing-05, February 2013.
[RFC0826]	Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[RFC4861]	Narten, T., Nordmark, E., Simpson, W. and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC5085]	Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5310]	Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R. and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009.
[RFC5884]	Aggarwal, R., Kompella, K., Nadeau, T. and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5921]	Bocci, M., Bryant, S., Frost, D., Levrau, L. and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[RFC6374]	Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011.
[LLDP]	IEEE, , "Station and Media Access Control Connectivity Discovery (802.1AB)", September 2009.

Authors' Addresses