SPRING Working Group L. Iannone Internet-Draft A. Fressancourt Intended status: Standards Track Huawei Expires: 31 August 2024 28 February 2024 Segment Routing over IPv6 (SRv6) Proof of Transit draft-iannone-spring-srv6-pot-00 Abstract Various technologies, including SRv6, allow to perform Traffic Engineering (TE), steering IP traffic through a specific path. However, there is no native mechanism in IP that allows to verify whether or not a packet did follow the path it was supposed to. This document specifies a new TLV for the Segment Routing Header (SRH) that allows to provide a cryptographically generated proof of transit over the different segments. The proposed mechanisms allows to verify whether a packet did go through the segments listed in its SRH header in the intended order. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 31 August 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components Iannone & Fressancourt Expires 31 August 2024 [Page 1] Internet-Draft SRv6 POT February 2024 extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 3. Definitions of Terms . . . . . . . . . . . . . . . . . . . . 3 4. Proof of Transit Procedure . . . . . . . . . . . . . . . . . 3 4.1. Processing at the ingress node . . . . . . . . . . . . . 4 4.2. Processing at the middle segments . . . . . . . . . . . . 5 4.3. Processing at the last segment . . . . . . . . . . . . . 5 5. Proof of Transit TLV . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7.1. Nonce Considerations . . . . . . . . . . . . . . . . . . 8 7.2. Hashing and Encryption algorithms considerations . . . . 8 7.3. Key Management Considerations . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Validating the network paths taken by packets is critical in constructing a secure Internet architecture (like SCION [I-D.dekater-panrg-scion-overview]). The objective is to enforce packet forwarding along ingress-specified paths and verify whether packets have taken those paths. However, path validation and proof of transit is also a desireable property for a wider range of use cases, like for instance Service Function Chaining (SFC), workload identity, traffic path compliance, uRFP validation, and Segment Routing Security ([I-D.liu-nasr-requirements], [I-D.ietf-sfc-proof-of -transit],[I-D.liu-path-validation-problem-statement]). Iannone & Fressancourt Expires 31 August 2024 [Page 2] Internet-Draft SRv6 POT February 2024 Segment Routing over IPv6 does provide a mechanism, namely the keyed Hashed Message Authentication Code (HMAC) TLV, to verify whether the Segment Routing Header (SRH) applied to a packet was done by an authorized trusted party also ensuring that the segment list has not been modified after generation (see Section 2.1.2 in [RFC8754]). Intermediate segments can verify the HMAC and discard packets that do not pass the validation. However, at the egress, HMAC alone does not allow to verify whether a packet actually went through the listed segments. It does only allow to validate that the list of segments has not been tempered and has been generated by the trusted ingress, or by a segment belonging to the group of holders of the key used to generate the HMAC. This documents proposes a new TLV, that leverages on the HMAC mechanism but extends it in order for the egress node to be able to verify whether or not the packet did go through the list of segments in the desired order. The basic idea being to recursively encrypt the HMAC at the ingress with a key specific to each segment. Then each segment does one decrypt operation when forwarding the packet. The egress will first decrypt and then validate the obtained un- encrypted HMAC using the procedure defined in [RFC8754]. The HMAC validation at the egress can be successful only if the packet went through all segments of the segment list also respecting the order of the list. If the packet does not go through even one single segment, or the order is different, the decryption at the egress will not return a valid HMAC, and the proof of transit fails. 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Definitions of Terms This document assumes familiarity with the terminology defined in [RFC8754], [RFC8402], and [RFC9256]. 4. Proof of Transit Procedure The target of the SRv6 Proof of Transit (POT) is to make prove that the packet goes from the ingress through the sequence of segment identifiers (SID) encoded in the SRH segment list, from SID(N) to SID(0) (recall that segments are encoded in reverse order in the segment list), where SID(0) is also the egress. So the encoded path is a simple linear path as depicted in Figure 1. Iannone & Fressancourt Expires 31 August 2024 [Page 3] Internet-Draft SRv6 POT February 2024 +--------+ +--------+ +--------+ +--------+ +--------+ |Ingress +---+ SID(N) +---+SID(N-1)| - - - - | SID(1) +---+ SID(0) | +--------+ +--------+ +--------+ +--------+ +--------+ Figure 1: Reference topology. In order to perform POT the following set on shared keys is necessary. * K_hmac_ie: A shared key between the ingress and the egress, i.e. SID(0), used to generated and validate the HMAC. * K_pot_in(i): A shared key between the ingress and SID (i), including SID(0), the egress. There is one shared key between the ingress and each SID in the segment list. It is assumed that the key allows as well to identify encryption or hashing algorithm to be used as well. The operations to be carried out by the ingress and the various segments are different, as described in the following, and they are based on the following primitives: HMAC[key](value): Calculate HMAC using shared key "key" on "value". ENC[key](value, salt): Encrypt "value" using the key "key" and the "salt" . DEC[key](value, salt): Decrypt "value" using the key "key" and the "salt". 4.1. Processing at the ingress node The ingress node has the role to prepend the SRv6 header to each packet, including the POT TLV. To this end, for each packet, it performs the following steps: 1. Generate a Path Verification Factor (PVF) using the HMAC of the generated SRH following the specifications in [RFC8754] and the key shared with the egress and identified by a Key Set ID: PVF = HMAC[K_hmac_ie](srh) 2. Generate a random Nonce value used to avoid replay attacks (see Section 7) and uses this Nonce as a "salt" in the encryption procedure. The encryption is repeated for every SID in the segment list: Iannone & Fressancourt Expires 31 August 2024 [Page 4] Internet-Draft SRv6 POT February 2024 For i = 0 to N do PVF = ENC[K_pot_in(i)](PVF, Nonce) After this loop PVF is the result of "N" encryption operations using different keys. It is also worth noting that the encryption order is the reverse of the segment order. Indeed the last encryption operation is performed using the key K_pot_in(N) of the first segment SID(N). The encryption/Decryption operations basically follow a Last-In First-Out (LIFO) policy. 3. The resulting PVF, the Key Set ID and the Nonce are copied in the POT TLV and the packet is sent out. The ingress node is the one that needs more resources. It has to share and store locally a secret key with all SIDs along the path (and an additional HMAC shared key), hence require more memory. It has to repeatedly encrypt the PVF as many times as the number of segments in the path, hence requiring more computation. 4.2. Processing at the middle segments Middle segments do perform a relatively simple operation. When they receive a packet with the POT TLV in the SRH, they do a lookup on the Key Set ID to retrieve the locally stored key shared with the ingress and use it along the Nonce found in the TLV to decrypt (only once) the PVF in the POT TLV PVF = DEC[k_pot_in(i)](PVF, Nonce) Then it updates the the POT TLV with the obtained value and forwards the packet. 4.3. Processing at the last segment The last segment SHOULD keep track of the most recently received Nonces, if the Nonce contained in the received POT TLV is a duplicate, then the packet MUST be discarded (see Section 7). If the Nonce has never been seen before, the egress will first perform a last decryption operation in the same way like the other segments in the segment list: PVF = DEC[k_pot_in(0)](PVF, Nonce) Iannone & Fressancourt Expires 31 August 2024 [Page 5] Internet-Draft SRv6 POT February 2024 In this way it obtains an un-encrypted HMAC. Then it will verify this HMAC using the procedure described in Section 2.1.2.1 of [RFC8754]. If the verification is successful the overall procedure described allows to state that the packet did transit through the segments listed in the SRH. If the verification fails, the reason is one of the following: * The HMAC has been tempered. * The packet did not go through all segments (missing at least one). * The packet went though the complete list of segments but not in the right order. The present specification does not allow to distinguish the specific reason of the failed verification but allow to identify those faulty cases and take action. 5. Proof of Transit TLV The format of the Proof of Transit TLV use to transport the previously described values is depicted in Figure 2. 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 | Length | Reserved | Nonce Length | +---------------+---------------+---------------+---------------+ | Key Set ID (4 octets) | +---------------------------------------------------------------+ | | ~ Nonce ~ | (Variable Length) | +---------------------------------------------------------------+ | | ~ Encrypted HMAC ~ | (Variable Length) | +---------------------------------------------------------------+ Figure 2: Proof of Transit TLV format. Where: Type: (TBD) Length: The length of the variable-length data in octets. Reserved: 8 reserved bits. It MUST be initialized to zero by the Iannone & Fressancourt Expires 31 August 2024 [Page 6] Internet-Draft SRv6 POT February 2024 sender and MUST be ignored by the receiver. Nonce Length: The length of the variable-length Nonce in octets. Different cryptographic algorithm use different nonce size. Key Set ID: A 4-octet opaque number that uniquely identifies the set of pre-shared keys and algorithm used in the cryptographic operations. Encrypted HMAC: This is the same as defined in Section 2.1.2 of [RFC8754], with the only difference that it is recursively encrypted on the ingress and decrypted along the path (see Section 4.1). In the HMAC TLV defined [RFC8754], the length of the HMAC field is not explicitly encoded in the TLV, since it can be easily calculated by subtracting 8 from the TLV length. Where 8 is the number of octets occupied by the fixed size fields at the beginning of the TLV. However, here there is a second variable length field, namely the Nonce, which makes it impossible to calculate its size and the size of the HMAC directly from the TLV length, hence the need to explicitly encode the Nonce length in the TLV. In this way the HMAC size is simply the TLV length minus the Nonce length minus 8 (where again 8 account for the first 8 fixed size fields). 6. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to this specification, in accordance with BCP 26 [RFC8126]. To be completed in future revision to request a SRH TLV code point. 7. Security Considerations This specification relies on [RFC8754], as such security consideration for SRH apply. The POT TLV does not introduce any vulnerability to the overall architecture and has the same security risk as HMAC. Iannone & Fressancourt Expires 31 August 2024 [Page 7] Internet-Draft SRv6 POT February 2024 7.1. Nonce Considerations Symmetric cryptography uses a "salt" or "Initialization Vector" to increase security level. An initialization vector (IV) is a cryptographically-secure random non-repeating value added as the initial state to a block cipher algorithm depending on the mode of operation, preventing the cipher from producing the same ciphertext for similar blocks. In the case of this specification the Nonce is the salt value and is used to avoid generating the same POT TLV for packets having the same SRH. This allows to protect against replay attacks, where a malicious attacker re-uses the POT TLV to make the egress believe the packet went through the path encoded in SRH. However, to work correctly the egress has to keep track of the most recently received Nonces and discard any packet carrying a duplicate Nonce. Nonce values MUST be generated following [RFC4086] and [RFC8937]. An alternative solution to the replay attack is to use keys that are unique for each packet. This can be achieved using a key derivation function that derives a new unique key from a pre-shared master key for each packet. The POT TLV should be capable of encoding such solution by converting the Nonce field to a key index field that allows to retrieve the right derived key to be used on each segment. However, such a solution is out of the scope of this document. 7.2. Hashing and Encryption algorithms considerations The proposed POT mechanism uses two types of algorithms: an authentication algorithm based on a hash function and an encryption algorithm. As with the computation of the SRH HMAC described in Section 2.1.2 of [RFC8754], an implementation of the POT mechanism described in this document can use multiple hash functions. Security recommendations of [RFC8754] concerning HMAC apply as well to this specification. Regarding the encryption algorithm, the mechanism described in this document does not use an Authenticated Encryption with Associated Data (AEAD) algorithm given that the encryption algorithm is used to encrypt an authentication tag sequentially. Using an AEAD algorithm would increase the size of the POT proof by the size of the authentication tag with each hop, which would make the size of the TLV too big for long paths. An algorithm suitable to be used to encrypt the POT HMAC is AES-XTS [IEEE1619-2007], or alternatively AES-CTR [MODES], taking in consideration the usage restriction presented in Section 4 of [RFC9459]. Iannone & Fressancourt Expires 31 August 2024 [Page 8] Internet-Draft SRv6 POT February 2024 7.3. Key Management Considerations While key management is outside the scope of this document, the recommendations of BCP 107 [RFC4107] should be considered when choosing the key management system. 8. References 8.1. Normative References [IEEE1619-2007] "IEEE Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices", IEEE standard, DOI 10.1109/ieeestd.2008.4493450, October 2008, . [MODES] Dworkin, M., "Recommendation for block cipher modes of operation :: methods and techniques", National Institute of Standards and Technology report, DOI 10.6028/nist.sp.800-38a, 2001, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, June 2005, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Iannone & Fressancourt Expires 31 August 2024 [Page 9] Internet-Draft SRv6 POT February 2024 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . [RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., and C. Wood, "Randomness Improvements for Security Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020, . [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022, . [RFC9459] Housley, R. and H. Tschofenig, "CBOR Object Signing and Encryption (COSE): AES-CTR and AES-CBC", RFC 9459, DOI 10.17487/RFC9459, September 2023, . 8.2. Informative References [I-D.dekater-panrg-scion-overview] de Kater, C., Rustignoli, N., and A. Perrig, "SCION Overview", Work in Progress, Internet-Draft, draft- dekater-panrg-scion-overview-05, 5 November 2023, . [I-D.ietf-sfc-proof-of-transit] Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S. Youell, "Proof of Transit", Work in Progress, Internet- Draft, draft-ietf-sfc-proof-of-transit-08, 1 November 2020, . [I-D.liu-nasr-requirements] Liu, P. C., "NASR Use Case and Requirements", Work in Progress, Internet-Draft, draft-liu-nasr-requirements-00, 8 February 2024, . Iannone & Fressancourt Expires 31 August 2024 [Page 10] Internet-Draft SRv6 POT February 2024 [I-D.liu-path-validation-problem-statement] Liu, P. C., Wu, Q., and L. Xia, "Path Validation Problem Statement, History, Gap Analysis and Use Cases", Work in Progress, Internet-Draft, draft-liu-path-validation- problem-statement-00, 23 October 2023, . Authors' Addresses Luigi Iannone Huawei Technologies France S.A.S.U. 18, Quai du Point du Jour 92100 Boulogne-Billancourt France Email: luigi.iannone@huawei.com Antoine Fressancourt Huawei Technologies France S.A.S.U. 18, Quai du Point du Jour 92100 Boulogne-Billancourt France Email: antoine.fressancourt@huawei.com Iannone & Fressancourt Expires 31 August 2024 [Page 11]