Segment Routing over IPv6 (SRv6) Proof of Transit
draft-iannone-spring-srv6-pot-00

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,
              <https://doi.org/10.1109/ieeestd.2008.4493450>.

   [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,
              <https://doi.org/10.6028/nist.sp.800-38a>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/rfc/rfc4086>.

   [RFC4107]  Bellovin, S. and R. Housley, "Guidelines for Cryptographic
              Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107,
              June 2005, <https://www.rfc-editor.org/rfc/rfc4107>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc8126>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

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, <https://www.rfc-editor.org/rfc/rfc8402>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc8754>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc8937>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc9256>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc9459>.

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,
              <https://datatracker.ietf.org/doc/html/draft-dekater-
              panrg-scion-overview-05>.

   [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, <https://datatracker.ietf.org/doc/html/draft-ietf-
              sfc-proof-of-transit-08>.

   [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, <https://datatracker.ietf.org/doc/html/
              draft-liu-nasr-requirements-00>.

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,
              <https://datatracker.ietf.org/doc/html/draft-liu-path-
              validation-problem-statement-00>.

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]