NASR Use Case and Requirements
draft-liu-nasr-requirements-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Peter Chunchi Liu , Luigi Iannone , Diego Lopez , Antonio Pastor , Meiling Chen , Li Su | ||
| Last updated | 2024-07-08 | ||
| RFC stream | (None) | ||
| Intended RFC status | (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-02
Network Working Group C. Liu
Internet-Draft L. Iannone
Intended status: Informational Huawei
Expires: 9 January 2025 D. Lopez
A. Pastor
Telefonica
M. Chen
L. Su
China Mobile
8 July 2024
NASR Use Case and Requirements
draft-liu-nasr-requirements-02
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."
Liu, et al. Expires 9 January 2025 [Page 1]
Internet-Draft nasr-req July 2024
This Internet-Draft will expire on 9 January 2025.
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 . . . . . . . . . . 5
5.3. Use Case 3: Sensitive Data Routing . . . . . . . . . . . 5
5.4. Use Case 4: Sensitive data transmission due to remote AI
training . . . . . . . . . . . . . . . . . . . . . . . . 5
5.5. Use Case 5: Ingress Filtering . . . . . . . . . . . . . . 6
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Requirement 1: Attributes of a network element,
interfaces . . . . . . . . . . . . . . . . . . . . . . . 6
6.2. Requirement 2: Path Attestation Procedures . . . . . . . 7
6.3. Requirement 3: Proof-of-Transit (POT) Mechanisms . . . . 7
6.3.1. Per-hop POT header extensions . . . . . . . . . . . . 8
6.3.2. Out-of-band POT extensions . . . . . . . . . . . . . 8
7. Non-Requirements . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Non-Requirements 1: Proof-of-Non-Transit (PONT)
Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. Future Requirement 2: Packet Steering and Preventive
Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 9
8. Commonly Asked Questions and Answers . . . . . . . . . . . . 9
8.1. Initially targeting for intra-domain or inter-domain
scenario? . . . . . . . . . . . . . . . . . . . . . . . . 9
8.2. Does tunneling solve the problem? . . . . . . . . . . . . 9
8.3. Does all nodes on the path need to compute the POT? . . . 10
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
Liu, et al. Expires 9 January 2025 [Page 2]
Internet-Draft nasr-req July 2024
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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.
* NASR: Network Attestation For Secure Routing, a technical
framework to be proposed that mainly does the following:
Liu, et al. Expires 9 January 2025 [Page 3]
Internet-Draft nasr-req July 2024
1. Allow clients to choose desired security attributes of his
received network service
2. Achieve dependable forwarding by routing on top of only
devices that satisfies his trust requirements
3. Provide proof to the clients that certain packets or flows
traversed a network path that has certain trust or security
properties.
* Routing Security: Practices and protocols designed to protect the
integrity, confidentiality, and availability of network routing
information and processes. [RFC4593], [RFC2828]
* Path Validation: [I-D.liu-path-validation-problem-statement]
* Secure Routing: [I-D.chen-secure-routing-use-cases-00]
* Proof-of-Transit: A verifiable cryptographic tag proving data of
specific granularity was processed by a network device.
[I-D.ietf-sfc-proof-of-transit-08]
* Trustworthy Path Routing: Path computation and routing according
to the trustworthiness of a network device, in order to avoid less
trustworthy, unsecure or risky devices.
[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 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 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.) suitable to support path validation.
Liu, et al. Expires 9 January 2025 [Page 4]
Internet-Draft nasr-req July 2024
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 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 also
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
Liu, et al. Expires 9 January 2025 [Page 5]
Internet-Draft nasr-req July 2024
the client DC. Without NASR guaranteeing dependable forwarding and
non-leakage, the market sales of operator's training center business
is hindered.
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 (to-be) Working Group
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.
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)
Liu, et al. Expires 9 January 2025 [Page 6]
Internet-Draft nasr-req July 2024
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: Path Attestation Procedures
After a path attribute request is sent from the client to the
operator, the operator will have to choose qualifying devices and
orchestrate a path. According to the goal 2 of NASR definition, the
path attestation procedure will be the core protocol of NASR. The
procedure should be able to re-attest to the whole path and provide
path-level attribute proofs (attestation results), proving the
delivered path complies with client request, which should reuse RATS
procedures. Details are being designed in the NASR architecture
document.
6.3. Requirement 3: 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
Liu, et al. Expires 9 January 2025 [Page 7]
Internet-Draft nasr-req July 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
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.3.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.3.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, 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
Liu, et al. Expires 9 January 2025 [Page 8]
Internet-Draft nasr-req July 2024
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.
Liu, et al. Expires 9 January 2025 [Page 9]
Internet-Draft nasr-req July 2024
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, 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>.
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<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,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
Liu, et al. Expires 9 January 2025 [Page 10]
Internet-Draft nasr-req July 2024
[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-
06, 4 March 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-ar4si-06>.
[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-28, 25 June
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
rats-eat-28>.
[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
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>.
Liu, et al. Expires 9 January 2025 [Page 11]
Internet-Draft nasr-req July 2024
[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-
09, 22 February 2024,
<https://datatracker.ietf.org/doc/html/draft-voit-rats-
trustworthy-path-routing-09>.
[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>.
[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, May 2004,
<https://doi.org/10.1109/secpri.2003.1199330>.
Authors' Addresses
Chunchi Liu
Huawei
Email: liuchunchi@huawei.com
Luigi Iannone
Huawei
Email: luigi.iannone@huawei.com
Diego Lopez
Telefonica
Email: diego.r.lopez@telefonica.com
Antonio Pastor
Telefonica
Email: antonio.pastorperales@telefonica.com
Liu, et al. Expires 9 January 2025 [Page 12]
Internet-Draft nasr-req July 2024
Meiling Chen
China Mobile
Email: chenmeiling@chinamobile.com
Li Su
China Mobile
Email: suli@chinamobile.com
Liu, et al. Expires 9 January 2025 [Page 13]