Skip to main content

NASR Use Case and Requirements
draft-liu-nasr-requirements-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Author Peter Chunchi Liu
Last updated 2024-02-08
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-liu-nasr-requirements-00
Network Working Group                                             C. Liu
Internet-Draft                                                    Huawei
Intended status: Informational                           8 February 2024
Expires: 11 August 2024

                     NASR Use Case and Requirements
                     draft-liu-nasr-requirements-00

Abstract

   This document describes the use cases and requirements that guide the
   specification of a Network Attestation for Secure Routing framework
   (NASR).

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://liuchunchi.github.io/draft-liu-nasr-requirements/draft-liu-
   nasr-requirements.html.  Status information for this document may be
   found at https://datatracker.ietf.org/doc/draft-liu-nasr-
   requirements/.

   Source for this draft and an issue tracker can be found at
   https://github.com/liuchunchi/draft-liu-nasr-requirements.

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 11 August 2024.

Liu                      Expires 11 August 2024                 [Page 1]
Internet-Draft                  nasr-req                   February 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
   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Note for NASR participants  . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Backgrounds . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.1.  Use Case 1: Network Path Validation . . . . . . . . . . .   4
     5.2.  Use Case 2: Verifying Path Properties . . . . . . . . . .   4
     5.3.  Use Case 3: Sensitive Data Routing  . . . . . . . . . . .   5
     5.4.  Use Case 4: Ingress Filtering . . . . . . . . . . . . . .   5
   6.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  Requirement 1: Proof-of-Transit (POT) Mechanisms  . . . .   5
       6.1.1.  Per-hop POT header extensions . . . . . . . . . . . .   6
       6.1.2.  Out-of-band POT extensions  . . . . . . . . . . . . .   6
     6.2.  Requirement 2: Attributes of a network element  . . . . .   6
     6.3.  Requirement 3: Path Attestation Procedures  . . . . . . .   7
   7.  Non-Requirements  . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Non-Requirements 1: Proof-of-Non-Transit (PONT)
           Mechanisms  . . . . . . . . . . . . . . . . . . . . . . .   7
     7.2.  Future Requirement 2: Packet Steering and Preventive
           Mechanisms  . . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Commonly Asked Questions and Answers  . . . . . . . . . . . .   8
     8.1.  Why not use static routing? . . . . . . . . . . . . . . .   8
     8.2.  Initially targeting for intradomain or interdomain
           scenario? . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.3.  Does tunneling solve the problem? . . . . . . . . . . . .   9
     8.4.  Does all nodes on the path need to compute the POT? . . .   9
   9.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   9
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   9
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     12.1.  Normative References . . . . . . . . . . . . . . . . . .   9

Liu                      Expires 11 August 2024                 [Page 2]
Internet-Draft                  nasr-req                   February 2024

     12.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   This document outlines the use cases and requirements that guide the
   specification of a Network Attestation for Secure Routing framework
   (NASR).

   NASR is targeted to help attest to a specific network path and verify
   if actual forwarding result is compliant to this path.  This network
   path can be both an underlay path consists of physical devices or a
   virtual path consists of virtual network functions.

1.1.  Note for NASR participants

   This document collates and synthesizes discussion outcomes of NASR
   mailing list and IETF 118 path validation side meeting.

   It is created to help 1.  Foster consensus among list members.  2.
   Orient non-list members to NASR goals and current progress

   This document may become a WG-draft but stay informational.

2.  Terminology

   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.  Backgrounds

   TBA

4.  Definitions

   We summarize the terms discussed in the list.

   *  NASR: Network Attestation For Secure Routing, a proposed framework
      that mainly does the following:

      1.  Attest to a network path

      2.  Verify actual forwarding path complies with the attested path

      3.  Prevent non-compliant forwarding (optional)

Liu                      Expires 11 August 2024                 [Page 3]
Internet-Draft                  nasr-req                   February 2024

   [Details to be added]

   *  Routing Security: [RFC4593], [RFC2828]

   *  Path Validation: [I-D.liu-path-validation-problem-statement]

   *  Secure Routing: [I-D.chen-secure-routing-use-cases-00]

   *  Proof-of-Transit: [I-D.ietf-sfc-proof-of-transit-08]

   *  Trustworthy Path Routing: [I-D.voit-rats-trustworthy-path-routing]

   ...

5.  Use Cases

5.1.  Use Case 1: Network Path Validation

   Explicit routing protocols permit explicit control over the traffic
   path, in order to meet certain performance, security or compliance
   requirements.  For example, operators can use SRv6 to orchestrate a
   Service Function Chaining (SFC) path and provide packaged security
   services or compliance services.  For either of them, validating the
   actual traffic path in the forwarding plane as an auditing measure is
   needed for clients and/or authorties.  NASR can help operator to
   attest to an orchestrated path and provide verifiable forwarding
   proofs to help clients/authorities audit the service.

   The network element is not limited to Service Function-- it can also
   be devices that has certain built-in security capabilities (or other
   attributes), or workloads.  Hence the path is not limited to a SFC
   path.

5.2.  Use Case 2: Verifying Path Properties

   In use case 1, The orchestrated path is explict and specfic down to
   each network element.  Sometimes, the client does not need to know
   every detail.  Rather, the clients will request a path of a certain
   property, such as trustworthiness, security level, location, vendor,
   etc, from the operator.  With NASR, the operator can orchestrate this
   path by selecting network elements with requested properties, attest
   to the path, and verifiably prove to the clients the traffic did
   follow this path.

   Compared to the first use case, the order of the elements may not be
   important.  This use case is more focused on validating the
   attributes of the path.

Liu                      Expires 11 August 2024                 [Page 4]
Internet-Draft                  nasr-req                   February 2024

5.3.  Use Case 3: Sensitive Data Routing

   Clients from specific industries such as finance, governments have
   very low tolerance of data leakage.  These clients require assurance
   that their data only travels on top of their selected leased line,
   MPLS VPN or SD-WAN path, and have (preferably real-time) visibility
   evidence or proof.  Some compliance requirements also prohibit
   customer data escape a specific geolocation without permission.  To
   avoid data leakage risks and compliance risks, some clients are
   willing to pay a premium for high data routing security guarantees.
   NASR can detect for such violations and make corrections promptly.

   Compared to the first and second use case, this use case also
   requires some preventive measures before a wrongful forwarding
   happens at the first place.

5.4.  Use Case 4: Ingress Filtering

   Ingress Filtering techniques, such as uRPF, help prevent source IP
   address spoofing and denial-of-service (DoS) attacks
   [RFC8704][RFC5635].  It works by validating the source IP address of
   a received packet by performing a reverse path lookup in FIB table,
   all the way to the source.  If the path does not exist, the packet is
   dropped.  NASR can be used to regularly validate the path stored in
   the FIB table, and tell if it continues to exist.  This can
   potentially reduce the false negative rate.

6.  Requirements

   (TBA: To add an architecture diagram integrating below components and
   show basic interactive flows)

6.1.  Requirement 1: Proof-of-Transit (POT) Mechanisms

   All use cases requested public verifiability of packet transit
   history.  Proof-of-Transit (POT) is a proof that a packet DID transit
   certain network elements.  A secure POT mechanism should truthfully
   reflect the identity of the network element and its attributes.  The
   "attribute" could be different:

   *  For simple POT, the "attribute" means the path it is on, and its
      relative position/order on the path.  This is the goal of POT
      mechanism defined in [I-D.ietf-sfc-proof-of-transit-08].

   *  For richer POT, the "attribute" means it could be a list of
      attributes: trustworthiness, security capabilities it has,
      geolocation, vendor, etc.  This needs the definition of attributes
      of a network element, which is discussed in Section 6.2

Liu                      Expires 11 August 2024                 [Page 5]
Internet-Draft                  nasr-req                   February 2024

   According to use case 2, the granularity of POT may also differ.  POT
   can be generated and recorded on a per-hop basis, or can be merged
   into one collective summary in the path level.

   The most appropriate POT mechanism for each scenarios may differ--
   inter-domain or intra-domain, with or without a pre-attest, per-
   packet or on-demand, privacy-preserving or not, etc.

6.1.1.  Per-hop POT header extensions

   POT could be either encapsulated and passed along the original path,
   or sent out-of-band.  It depends on the different operation modes:
   who should verify the POT (other elements on the path, the end host,
   or external security operation center (SOC)), timeliness of
   verification, etc.

   When the POT is passed along the path, it should be encapsulated in
   hop-by-hop header extensions, such as IPv6 hop-by-hop options header,
   In-situ OAM hop-by-hop option etc.  Exact size and specifications of
   data fields are subject to different POT mechanisms.

6.1.2.  Out-of-band POT extensions

   For situations requiring real-time or near-real-time verification,
   out-of-band methods are needed to encapsulate and transmit POT.  For
   example, traffic monitoring protocols like IPFIX [RFC7011], SNMP,
   etc.  Similarly, exact size and specifications of data fields are
   subject to different POT mechanisms.

6.2.  Requirement 2: Attributes of a network element

   The identity of a subject should be defined by the attributes (or
   claims) it owns.  Attribute-defined identity is a paradigm widely
   accepted in SCIM [RFC7643], OAuth [RFC7519], SAML [SAML2], etc.  POT
   proof should reflect the identity and associated attributes, such as
   element type, security level, security capability it has, remote-
   attestated or not, vendor, deployed geolocation, current timestamp,
   path it is on, hop index on the path etc.

   Such attributes/claims/attestation results can reuse existing
   specifications, for example [I-D.ietf-rats-eat],
   [I-D.ietf-rats-ar4si] in RATS WG.  Some existing claims that we can
   reuse:

Liu                      Expires 11 August 2024                 [Page 6]
Internet-Draft                  nasr-req                   February 2024

   hwmodel
   hwversion
   swname
   swversion
   location

   Some new claim extensions can be made:

   elemtype
   pathid
   index
   secfunctions
   vendor
   ...

   (subject to discussion, add, change)

   NASR could work closely with RATS on the standardization of above
   attributes and means of proving them.

6.3.  Requirement 3: Path Attestation Procedures

   After a path is selected, it should be

   1.  commited to prevent changes,

   2.  publicized for common referencing and retrival.

   The stored path should contain these information: univeral ID, all
   network elements on the path, and attributes of them.  (Schemas may
   vary depending on scenarios)

   TBA

7.  Non-Requirements

7.1.  Non-Requirements 1: Proof-of-Non-Transit (PONT) Mechanisms

   Proof-of-Non-Transit (PONT) is a proof that a packet did NOT transit
   certain network elements.  It is to the opposite to the Req. 1 Proof-
   of-Transit.  Certain customers requested PONT for compliance or
   security purposes.

   First of all, PONT is a non-inclusion proof, and such non-existence
   proof cannot be directly given.  Second, under certain circumstances,
   PONT can be _inferred_ from POT.  For example, assume devices are
   perfectly secure and their behaviors completely compliant to
   expectations, then POT over A-B-C indicates the packet did not

Liu                      Expires 11 August 2024                 [Page 7]
Internet-Draft                  nasr-req                   February 2024

   transit X/Y/Z.  To relax the security assumptions, if the devices are
   remote attestated and such claim is proved by POT, then the packet
   _should_ only transited these trusted devices, assuming the RATS
   procedure is secure.  The reliability of such reasoning decreases as
   the security level of device decreases.

   NASR mailing list has agreed NOT to provide PONT mechanisms, but
   could provide some informational measures and conditions that could
   indicate PONT from POT results.  For example, under xxx constraints
   and circumstances, if traffic passed X AND Y (device or geolocation),
   then it did NOT (or with a quantifiably low probability it did not)
   pass Z.

   Since this part is research-related, NASR will work with PANRG and
   Academia for counseling.

7.2.  Future Requirement 2: Packet Steering and Preventive Mechanisms

   In sensitive data routing use case, it is certainly necessary to know
   and verify the transit path of a packet using POT mechanisms.
   However, it might be too late to have the data already exposed to the
   insecure devices and risk leakage.  There should be packet steering
   mechanisms or other preventive measures that help traffic stay in the
   desired path.  For example, doing an egress check before sending to
   the next hop, preventing sending packet to a device with a non-
   desirable attribute.

   The mailing list and side meeting has received requests to this
   requirement, it should fall in NASR interest, but also agreed this
   may not be part of the initial scope of NASR-- it is a topic to be
   included in the next stage of NASR when rechartering.

8.  Commonly Asked Questions and Answers

   (From side meeting and mailing list feedbacks, to be updated)

8.1.  Why not use static routing?

   Static routing severely limits the scalability and flexibility for
   performance optimizations and reconfigurations.  Flexible
   orchestration of paths will be prohibited.  Also, even static routing
   is used, we still need proof of transit for compliance check.

Liu                      Expires 11 August 2024                 [Page 8]
Internet-Draft                  nasr-req                   February 2024

8.2.  Initially targeting for intradomain or interdomain scenario?

8.3.  Does tunneling solve the problem?

8.4.  Does all nodes on the path need to compute the POT?

   Whether the validation is strict or loose is dependent on the
   scenario.  For example in SFC use case, we are only interested in
   verifying some important elements of interes processed the traffic.

9.  Contributors

   This document is made possible by NASR proponents, active mailing
   list members and side meeting participants.  Including but not
   limited to: Andrew Alston, Meiling Chen, Diego Lopez, Luigi Iannone,
   Nicola Rustignoli, Michael Richardson, Adnan Rashid and many others.

   Please create *Github issues* to comment, or raise a question.
   Please create new commits and *Github Pull Requests* to propose new
   contents.

10.  Security Considerations

   This document has no further security considerations.

11.  IANA Considerations

   This document has no IANA actions.

12.  References

12.1.  Normative References

   [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>.

   [RFC7011]  Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
              "Specification of the IP Flow Information Export (IPFIX)
              Protocol for the Exchange of Flow Information", STD 77,
              RFC 7011, DOI 10.17487/RFC7011, September 2013,
              <https://www.rfc-editor.org/rfc/rfc7011>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7519>.

Liu                      Expires 11 August 2024                 [Page 9]
Internet-Draft                  nasr-req                   February 2024

   [RFC7643]  Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C.
              Mortimore, "System for Cross-domain Identity Management:
              Core Schema", RFC 7643, DOI 10.17487/RFC7643, September
              2015, <https://www.rfc-editor.org/rfc/rfc7643>.

   [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>.

   [RFC8704]  Sriram, K., Montgomery, D., and J. Haas, "Enhanced
              Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
              RFC 8704, DOI 10.17487/RFC8704, February 2020,
              <https://www.rfc-editor.org/rfc/rfc8704>.

12.2.  Informative References

   [I-D.chen-secure-routing-use-cases-00]
              Chen, M. and L. Su, "The Use Cases for Secure Routing",
              Work in Progress, Internet-Draft, draft-chen-secure-
              routing-use-cases-00, 5 March 2023,
              <https://datatracker.ietf.org/doc/html/draft-chen-secure-
              routing-use-cases-00>.

   [I-D.ietf-rats-ar4si]
              Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V.
              Scarlata, "Attestation Results for Secure Interactions",
              Work in Progress, Internet-Draft, draft-ietf-rats-ar4si-
              05, 30 August 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-rats-
              ar4si-05>.

   [I-D.ietf-rats-eat]
              Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
              Wallace, "The Entity Attestation Token (EAT)", Work in
              Progress, Internet-Draft, draft-ietf-rats-eat-25, 15
              January 2024, <https://datatracker.ietf.org/doc/html/
              draft-ietf-rats-eat-25>.

   [I-D.ietf-sfc-proof-of-transit-08]
              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-path-validation-problem-statement]
              Liu, P. C., Wu, Q., and L. Xia, "Path Validation Problem
              Statement, History, Gap Analysis and Use Cases", Work in

Liu                      Expires 11 August 2024                [Page 10]
Internet-Draft                  nasr-req                   February 2024

              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>.

   [I-D.voit-rats-trustworthy-path-routing]
              Voit, E., Gaddam, C. R., Fedorkow, G., Birkholz, H., and
              M. Chen, "Trusted Path Routing", Work in Progress,
              Internet-Draft, draft-voit-rats-trustworthy-path-routing-
              08, 28 August 2023,
              <https://datatracker.ietf.org/doc/html/draft-voit-rats-
              trustworthy-path-routing-08>.

   [RFC2828]  Shirey, R., "Internet Security Glossary", RFC 2828,
              DOI 10.17487/RFC2828, May 2000,
              <https://www.rfc-editor.org/rfc/rfc2828>.

   [RFC4593]  Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
              Routing Protocols", RFC 4593, DOI 10.17487/RFC4593,
              October 2006, <https://www.rfc-editor.org/rfc/rfc4593>.

   [RFC5635]  Kumari, W. and D. McPherson, "Remote Triggered Black Hole
              Filtering with Unicast Reverse Path Forwarding (uRPF)",
              RFC 5635, DOI 10.17487/RFC5635, August 2009,
              <https://www.rfc-editor.org/rfc/rfc5635>.

   [SAML2]    "Assertions and Protocols for the OASIS Security Assertion
              Markup Language (SAML) V2.0", March 2005,
              <https://docs.oasis-open.org/security/saml/v2.0/saml-core-
              2.0-os.pdf>.

Author's Address

   Chunchi Liu
   Huawei
   101 Ruanjian Ave
   Nanjing
   210012
   China
   Email: liuchunchi@huawei.com

Liu                      Expires 11 August 2024                [Page 11]