Pseudowire Security (PWsec)

The PWE3 architecture [RFC3985] defines a pseudowire (PW) connecting customer networks over a provider network. The customer networks run a native service, which may be Ethernet, ATM, frame relay, TDM, etc. On both sides of the PW a customer edge (CE) connects to a provider edge (PE) via an attachment circuit (AC). The PW itself is a tunnel that transports the native service data across the provider network, here assumed to be based on MPLS. PW tunnels may be set up using the PWE control protocol [RFC4447]. Security threats specific to pseudowires were discussed in [PW-sec-req], where the following nonexhaustive list of user plane threats were considered: accidental connection to untrusted network compromising user traffic maliciously setting up a PW to gain access to a customer network forking of a PW to snoop PW packets malicious rerouting of a PW to snoop or modify PW packets unauthorized tearing down of a PW unauthorized snooping of PW packets traffic analysis of PW connectivity unauthorized deletion of PW packets unauthorized modification of PW packets unauthorized insertion of PW packets replay of PW packets denial of service or significantly impacting PW service quality. In order to counter these threats, several security measures are needed. State-of-the-art encryption algorithms provide data confidentiality in order to frustrate snooping and prevent unintended data leakage. Mechanisms to ensure data integrity thwart packet insertion and modification. Source authentication may prevent malicious access to resources and denial of service attacks. In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119].

From 1976 to 2000 the Data Encryption Standard (DES) was the standard block cipher. In 2000, after an open competition for the selction of a successor to DES, the National Institute of Standards and Technology (NIST) announced that Rijndael had been selected as the basis for a new standard, and in 2001 the Advanced Encryption Standard (AES) was published [AES]. Agencies of the US government have certified that AES is sufficient to protect SECRET and even TOP SECRET classified information. AES has a fixed block size of 128 bits and allows key sizes of 128, 192 or 256 bits. Like other block ciphers, in order to encrypt larger amounts of data, various 'modes of operation' may be used. The simplest mode is Electronic CodeBook (ECB), wherein the message is segmented into blocks each of which is separately encrypted. This mode is not recommended due to inherent weaknesses. Other modes, such as Cipher Block Chaining (CBC) and Output FeedBack (OFB) provide confidentiality but do not ensure overall message integrity, nor do they authenticate the claimed source. Newer modes, such as Offset CodeBook (OCB) and Counter (CTR) are designed to address these limitations. The Galois/Counter Mode (GCM) has numerous advantages over other proposed modes of operation. Its most important characteristics: encryption is provided by AES with a counter-type mode of operation an Integrity Check Value (ICV) verifies the payload integrity data that is not part of the packet payload (for example source identifiers) can be authenticated encryption, integrity, and source authentication are performed by a single algorithm authentication can be performed without encrypting data the Initialization Vector (IV) nonce can be of arbitrary length the algorithm can be efficiently implemented in software the computation can be pipelined and parallelized, enabling high speed hardware implementations GCM mode is unencumbered by IPR claims. For these reasons, AES/GCM has been adopted by the IEEE as the default cipher suite for 802.1ae (MACsec), and has been specified for IPsec ESP [RFC4106] and AH [RFC4543]. It is also being considered by other bodies for applications where high-speed authenticated encryption is required. When used to provide security for MPLS PWs, we shall call it PWsec. When encrypting, AES/GCM takes the following as input: the plaintext to be encrypted (up to 2^36 - 32 bytes in length) the encryption key (128 or 256 bits in length) a per-packet randomly generated IV (12 bytes is recommended for efficiency) additional data to be authenticated but not encrypted (between 0 and 2^61 bytes) and returns the following as output the ciphertext, whose length is precisely that of the plaintext the ICV (which we shall take to be 16 bytes in length). For a given encryption key IV values SHOULD NOT be repeated. In MACsec, the IV consists of a 4-byte Packet Number (PN) and a 8-byte Secure Channel Identifier (SCI). The PN is increased from frame to frame, and a new encryption key must be supplied before the PN recycles. An alternative way of conforming to the requirement is selecting random IV values such that repetition is highly unlikely. When decrypting, AES/GCM takes the following as input: the ciphertext to be decrypted the encryption key the IV nonce that was used when encrypting the ICV generated during encryption and returns the following as output a boolean value specifying whether the integrity test passed or failed if the integrity test passed, the plaintext.

PWsec may be employed whether or not the control word [RFC4385] is used. If the control word is used, it is not encrypted. If an RTP header is used [RFC3985], it is encrypted. The format of a PWsec encrypted packet is given in Figure 1. Note that unlike MACsec, PWsec does not use the sequence number as part of the IV.

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Label | EXP |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW label | EXP |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| flags |FRG| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Initialization Vector (IV) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Encrypted Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Integrity Check Value (ICV) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. PWsec Packet Format PWsec performs source authentication by using an identifier that uniquely identifies the source as additional data to be authenticated but not encrypted. If the control word is used and the sequence number is nonzero, the sequence number is authenticated in this way as well. If the PW is set up using the PWE control protocol [RFC4447] using FEC 128, then the source identifier can be taken to be the source PE identifier plus the 4-byte Group ID plus the 4-byte PW ID. If the PW is set up using the PWE control protocol using FEC 129, then the source identifier can be taken to be the source PE identifier plus the Attachment Identifier (AI); where the latter will usually consist of the Attachment Group Identifier (AGI) plus the Source Attachment Individual Identifier (SAII). For both cases, the entire contents of the FEC element MAY be authenticated. If the PW is statically provisioned, then a unique source identifier MUST be provisioned.

When setting up a PW to use PWsec using the PWE3 control protocol, a new TLV, called the PWsec TLV MUST be used in the LDP label mapping message. This TLV specifies the parameters of the encryption and authentication, including a code indicating the use of AES/GCM, the encryption key length (128 or 256 bits), the length of the IV (here a constant 12 bytes), the length of the ICV (here a constant 16 bytes), and the additional data to be authenticated. The format of this TLV will be specified in the next revision of this document. The key used to encrypt and decrypt PW packets should be regularly changed. Methods for key distribution are beyond the scope of this document, but mechanisms such as the Internet Key Exchange (IKE) [RFC4306] are appropriate for this task.

This document proposes a security mechanism for the MPLS PW user plane based on symmetric key cryptography. The mechanism is based on AES in GCM mode, which has been adopted by the IEEE as the default cipher suite for MACsec and has been specified for IPsec ESP [RFC4106] and AH [RFC4543]. Mechanisms for key distribution will be required, but were not specified. Our discussion has focused on the PW user plane. To complement the proposed mechanism, security solutions for the PWE3 control protocol and for the management plane will be required.

In order to signal the use of PWsec, a new TLV to be used in the LDP label mapping message of the PWE3 control protocol [RFC4447] will be required.