Internet-Draft nasr-req October 2024
Liu, et al. Expires 24 April 2025 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-liu-nasr-requirements-03
Published:
Intended Status:
Informational
Expires:
Authors:
C. Liu
Huawei
L. Iannone
Huawei
D. Lopez
Telefonica
A. Pastor
Telefonica
M. Chen
China Mobile
L. Su
China Mobile

NASR Use Case and Requirements

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 24 April 2025.

Table of Contents

1. Introduction

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

1.1. Note for NASR participants

This document collates and synthesizes discussion outcomes of NASR mailing list and side meetings.

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.

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

Clients with high security and privacy requirements are not anymore satisfied with traffic signing and encryption mechanisms only; they now request information of the trustworthiness or security properties of the network paths over which the traffic is carried, preferably to choose the desired properties.

4. Definitions

We summarize the terms discussed in the list.

...

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 packet trace 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 forwarding.

SFC is used as an example, therefore 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.) needs to be validated.

Another example is SRv6 strict mode vs loose mode. Compared to the former, SRv6 loose mode does not specify a fixed forwarding baseline. In which case, we may need to use dial-test-like methods to specify a legitimate forwarding baseline, and verify the actual packet trace against this forwarding baseline. If changes must be made, e.g. path re-calculation due to partial failures, the update of baseline is permitted but must be known to the relying party.

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 with the requested properties. In this case, the forwarding baseline does not contain specific hop-by-hop paths, but the set of security properties only.

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 and have (preferably real-time) verifiable evidence or proof. Some compliance requirements also prohibit customer data escape a specific geolocation without authorization. To avoid data leakage and compliance risks, some clients are willing to pay a premium for high data routing security guarantees. NASR can prevent and detect accidental violations and make corrections promptly, therefore supporting SLAs incorporating these guarantees.

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

5.4. Use Case 4: Sensitive data transmission due to remote AI training

This use case is similar to Use Case 3 but is more specific. As AI trend rise, operators are investing in "AI training centers" for lease. Due to scalability and cost reduction considerations, training centers tend to be built separately from data centers. In manufacturing industry or other data-heavy industries, DCs or private storage is often built next to the campus. But in order to support training and utilize operator-running training centers, wide-area data transmission between DC and TC is needed. Enterprise clients, when faced with privacy-sensitive data leaving their DCs and go through wide-area transmission, are highly unhappy. Yet, it is also impractical for operators to build dedicated training centers next to the client DC. Without NASR guaranteeing dependable forwarding and non-leakage, the market sales of operator's training center business is hindered. This is more of a business use case, but technically same with use case 1.

5.5. Use Case 5: Ingress Filtering

Ingress Filtering techniques help prevent source IP address spoofing and denial-of-service (DoS) attacks [RFC8704][RFC5635]. Approches like uRPF 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. Requirements

Based on the main use-cases described in the previous section the following requirements are identified.

6.1. Requirement 1: Attributes of a network element, interfaces

According to goal 1 of NASR definition, NASR team will define security/trustworthiness attributes of network elements, for clients to request from operators. Attributes should be objective claims, including but not limited to existing remotely-attested claims, element type (physical or virtual network element), security capability it enables, cryptographic algorithms, key strength, deployed geolocation, etc. These attributes constructs a forwarding baseline needed for post-flight path validation.

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

Additionally, service request interface between clients and operators should also be defined.

6.2. Requirement 2: Forwarding Baseline

After a path attribute request is sent from the client to the operator, the operator will have to choose qualifying devices and calculate a L3 path. This L3 path (or routing baseline) must be translated to a deterministic forwarding baseline using dial-tests or device-controller communications. The actual packet trace should be verified against the forwarding baseline. The forwarding baseline should keep unchanged during the process, unless necessary events happen and the re-calculation result notifies the relying party.

6.3. Requirement 3: Path Attestation Procedures

The path attestation procedure will be the core protocol of NASR. It contains steps to create the forwarding baseline and verifying actual packet trace against it. Details are being designed in the NASR architecture document.

6.4. Requirement 4: 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 transited certain network elements, and it can include a verification of the order in which those elements where transited (Ordered POT, OPoT) 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.1

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 aggregated 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.4.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.4.2. Out-of-band POT extensions

For situations requiring real-time or near-real-time verification, meaning some external security operation centers (SOC) wish to have real-time visibility of the forwarding path (of an important flow, for example), out-of-band methods are needed to encapsulate and transmit POT. In this way, the SOC can verify the POT of each packet in order to make sure the forwarding is correct. For example, traffic monitoring protocols like IPFIX [RFC7011] or ICMP [RFC792], specific management and control protocols, etc. Similarly, exact size and specifications of data fields are subject to different POT mechanisms.

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, 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. Commonly Asked Questions and Answers

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

8.1. 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, but inter-domain scenario will be critical for standardization.

8.2. Does tunneling solve the problem?

Tunnels, VPNs do not perceive the underlying network devices. Quality measurements can be done, but other detail information of bearing devices are not visible.

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

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, Nicola Rustignoli, Michael Richardson, Mingxing Liu, 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, , <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, , <https://www.rfc-editor.org/rfc/rfc7011>.
[RFC792]
Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, , <https://www.rfc-editor.org/rfc/rfc792>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <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, , <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, , <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-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-rats-ar4si-07>.
[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-31, , <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-31>.
[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, , <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 Progress, Internet-Draft, draft-liu-path-validation-problem-statement-00, , <https://datatracker.ietf.org/doc/html/draft-liu-path-validation-problem-statement-00>.
[I-D.voit-rats-trustworthy-path-routing]
Birkholz, H., Voit, E., Liu, P. C., Lopez, D., and M. Chen, "Trusted Path Routing", Work in Progress, Internet-Draft, draft-voit-rats-trustworthy-path-routing-10, , <https://datatracker.ietf.org/doc/html/draft-voit-rats-trustworthy-path-routing-10>.
[RFC2828]
Shirey, R., "Internet Security Glossary", RFC 2828, DOI 10.17487/RFC2828, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc5635>.
[Yaar03]
Yaar, A., Perrig, A., and D. Song, "Pi: a path identification mechanism to defend against DDoS attacks", IEEE Comput. Soc, Proceedings 19th International Conference on Data Engineering (Cat. No.03CH37405), DOI 10.1109/secpri.2003.1199330, , <https://doi.org/10.1109/secpri.2003.1199330>.

Authors' Addresses

Chunchi Liu
Huawei
Luigi Iannone
Huawei
Diego Lopez
Telefonica
Antonio Pastor
Telefonica
Meiling Chen
China Mobile
Li Su
China Mobile