NASR Use Case and Requirements

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 will stay as an informational draft.¶

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 authorities. NASR can help operator to attest to an orchestrated path and provide verifiable forwarding proofs to help clients/authorities audit the service.¶

SFC is used as an (possibly canon cal) example, therefor network elements are not limited to Service Functions, and paths are not limited to a SFC path. Other devices or network functions may incorporate features (built-in security capabilities, roots of trust and attestation mechanisms, etc.) suitable to support path validation.¶

5.2. Use Case 2: Verifying Path Properties

In use case 1, the orchestrated path is explicit and specific down to each network element. Sometimes, clients do not need to know every detail of the network path. Rather, clients will request the verification of a certain property within the path, such as trustworthiness, security level, geolocation, vendor characteristics, transit provider, etc. from the operator. Using NASR, the operator can orchestrate this path by selecting network elements and links with the requested properties, attest to the path, and verifiably prove to clients the path properties and that the traffic did follow this path.¶

In both this and the previous case, the order of the elements in the path may not be important, as the requests may be limited to a set of attributes for the path nodes, or the guarantee that traffic traversed a certain (set of) node(s).¶

5.3. Use Case 3: Sensitive Data Routing

Clients from specific industries such as finance or governments have very low tolerance to 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 and compliance risks, some clients are willing to pay a premium for high data routing security guarantees. NASR can detect such violations and make corrections promptly, therefore supporting SLAs incorporating these guarantees.¶

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 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. Furthermore, when uRPF is not available and source address cannot be trusted, NASR can offer a way to filter malicious traffic based on the path used to carry out such an attack [Yaar03]. The other usage is to check if a packet carries a valid trail of transit proofs. If it does then the packet is verified.¶

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, and it can include a verification of the order in which those elements where transited (Ordered POT, OPoO) or not. A secure POT mechanism should verifiably reflect the identity of the transited network elements and their relevant attributes, if applicable:¶

• For basic POT, there is no further attribute than the identity of the transited element and, optionally, its relative position/order within the path. This is the goal of the POT mechanism defined in [I-D.ietf-sfc-proof-of-transit-08].¶

• For extended POT, different attributes can be considered from a list of relevant ones: trustworthiness measure, available security capabilities, geolocation, vendor, etc. This needs the definition of the relevant attributes of a network element, which is discussed in Section 6.2¶

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 at 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.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, remotely-attested 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:¶

• hwmodel (Hardware Model)¶

• hwversion (Hardware Version)¶

• swname (Software Name )¶

• swversion (Software Version)¶

• location (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. Committed to prevent changes,¶

2. Publicized for common referencing and retrieval.¶

The stored path should contain this information: unique ID (within a domain), all network elements on the path, and attributes of them. (Schemas may vary depending on scenarios)¶

TBA¶

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, essentially, the opposite to Req. 1 Proof-of-Transit. Certain potential user have expressed their interest on 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, especially when Ordered POT (OPOT) is enforced. 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 transit X/Y/Z. To relax the security assumptions, if the devices are remotely attested 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 the 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 further stages of NASR, in case of a rechartering.¶

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 when static routing is used, we still need proof of transit for compliance checks.¶

8.2. Initially targeting for intra-domain or inter-domain scenario?

Limited domain with some trust assumptions and controls to devices will be easy to start with. Then we can go do the interdomain.¶

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 depends on the scenario. For example, in SFC use cases, we are only interested in verifying some important elements of interest processed the traffic.¶