Internet DRAFT - draft-liu-path-validation-problem-statement
draft-liu-path-validation-problem-statement
Network Working Group C. Liu
Internet-Draft Q. Wu
Updates: draft-liu-on-network-path-validation-00 L. Xia
(if approved) Huawei
Intended status: Standards Track 23 October 2023
Expires: 25 April 2024
Path Validation Problem Statement, History, Gap Analysis and Use Cases
draft-liu-path-validation-problem-statement-00
Abstract
This document provides a problem statement, history revisiting, gap
analysis and use cases for path validation techniques.
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 25 April 2024.
Copyright Notice
Copyright (c) 2023 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.
Liu, et al. Expires 25 April 2024 [Page 1]
Internet-Draft Path Validation Problems Statement October 2023
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem Statement of Path Validation . . . . . . . . . . . . 2
2.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Goal . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Routing Integrity vs Forwarding Integrity . . . . . . . . 4
3.2. Proof-of-Transit Security . . . . . . . . . . . . . . . . 4
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Service Function Chaining . . . . . . . . . . . . . . . . 5
4.2. Workload Identity . . . . . . . . . . . . . . . . . . . . 5
4.3. Traffic Path Compliance . . . . . . . . . . . . . . . . . 5
4.4. High Security traffic path . . . . . . . . . . . . . . . 6
4.5. Validating uRPF path . . . . . . . . . . . . . . . . . . 6
4.6. Segment Routing Security . . . . . . . . . . . . . . . . 6
5. Out-of-scopes . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Path validation has been interpreted differently in different
contexts due to its ambiguous name and long history. This document
aims to deliver a clearer understanding of the path validation
problem and help navigate exploration towards potential solutions.
2. Problem Statement of Path Validation
2.1. History
The term "path validation" was first used in the BGP context,
referring to validating the correctness of AS-level path propagation.
The term "path validation" mostly refers to verifying that a BGP
route advertisement (an AS-path) is authentic, indeed authorized by
all ASes on the path, and correctly representing the inter-AS
propagation path, which later becomes BGPSec [RFC8205][BGPSEC].
While some RFCs also discussed data plane consistency with control
plane [RFC5123], mentioning validating also the actual path that a
packet has traversed, it remains a minority of understanding to this
term.
Liu, et al. Expires 25 April 2024 [Page 2]
Internet-Draft Path Validation Problems Statement October 2023
Later, as the inconsistency gap between control plane and data plane
becomes bigger, the term "path validation" later be interpreted by a
lot of research papers [PATHVALIDATIONPAPER1][PATHVALIDATIONPAPER2][P
ATHVALIDATIONPAPER3][PATHVALIDATIONPAPER4] as "Validating what path a
packet has actually traversed". The unambiguous equivalence to this
interpretation in the IETF community is the concept of Proof-of-
Transit [I-D.ietf-sfc-proof-of-transit-08].
2.2. Scope
Despite the different focus, control plane or the data plane, we
think they are two sides of a same coin. The former is to make sure
the router receives the correct routing reference (routing table,
interface configurations, segment list etc) before the forwarding
happens, while the latter is to directly verify the correctness of
forwarding outcome, after the forwarding is done. As a result, the
scope of path validation should be:
1. Validating the planned path is a trusted, authorized path.
2. Validating what path a packet has actually traversed.
With the former protecting routing integrity and the latter
protecting forwarding security.
2.3. Goal
Given the above scope, the goal of path validation is to achieve:
* Verifiable assurance of hop-by-hop forwarding integrity.
3. Gap Analysis
There are three major gaps in path validation.
1. The gap between path validation and proof of transit
2. The gap between BGP scenarios and more scenarios
3. The gap between routing integrity and forwarding integrity
The first gap is explained in the history section. Now we believe
proof of transit is part of path validation. The second gap requires
use case analysis which we will discuss later. The third gap exists
in both explict routing and conventional routing scenarios, and it is
the main gap for path validation to fill.
Liu, et al. Expires 25 April 2024 [Page 3]
Internet-Draft Path Validation Problems Statement October 2023
3.1. Routing Integrity vs Forwarding Integrity
Also known as the inconsistency between control plane and data plane.
To achieve secure routing, three basic steps are needed:
1. Secure path propagation
2. Secure router execution
3. Secure proof of transit
Secure path propagation relies on secure control plane techniques
such as BGPSec and RPKI, leading to the correctness of routing
reference information such as routing table, segment list, etc.
Secure router execution relies on remote attestations on the
trustworthiness of the router hardware, firmware, software and
configurations. Achieving these two leads to routing integrity, and
_implies_ forwarding integrity. However, misconfigurations and/or
various of new attacks could circumvent the security measures,
leading to the deviation of actual forwarding path from the correct
routing path [SECUREROUTINGFAIL], which can only be directly
discoverable by data plane validation mechanisms like proof of
transit. A secure proof of transit mechanism would significantly
help fill the gap between routing integrity and forwarding integrity
as it verifies the final results directly.
Note that a probing mechanism such as IFIT/IOAM or other new path
tracing mechanisms [I-D.filsfils-spring-path-tracing-05] also has the
same purpose. But they still rely on a secure proof of transit
mechanism.
3.2. Proof-of-Transit Security
As discussed earlier, the gap between routing integrity and
forwarding integrity can be filled by a secure proof of transit
mechanism that directly verifies the final forwarding results. Proof
of Transit (POT) is thus the critical part of the path validation
problem and we model path validation security around the security of
a POT mechanism. We say a Proof-of-Transit mechanism is secure if
the transit proof is correct, unforgeable identity-binding and
position-binding.
* *Correctness:* A transit proof created by the right node n_i at
the position i must pass the verification. (probability of a
correct proof not passing verification is smaller than a
negligible function)
Liu, et al. Expires 25 April 2024 [Page 4]
Internet-Draft Path Validation Problems Statement October 2023
* *Unforgeability:* A transit proof at position i must only be
created by the node n_i. (probability of a forged proof passing
verification is smaller than a negligible function)
* *Identity-binding:* A transit proof computed by a false node n_z
at position i cannot pass a verification check.
* *Position-binding* A transit proof computed by a correct node n_i
in the wrong position j, where i != j, cannot pass a verification
check.
* *Hiding* * A transit proof may or may not directly reveal the
creator's identity and/or his position.
4. Use Cases
4.1. Service Function Chaining
Service Function Chaining enables the traffic to traverse virtual
network functions in a user-defined order. Compliance or legal
requirements may demand the service provider to prove that all
packets have followed a specific path, preferably cryptographically
verifiable. In today's deployments, this proof is typically
delivered in an indirect way. A path validation mechanism can
produce a cryptographically verifiable transit proof, proving that
the corresponding packet has indeed been processed by a sequence of
service functions.
4.2. Workload Identity
Enterprises have been migrating their production-level IT systems to
the cloud. This means that some of the enterprises' key production
workflow security now heavily relies on the ordered calling of
different microservices or APIs. Similar to the SFC case, workload
identity [I-D.gilman-wimse-use-cases-00] also requires some kind of
ordered proof-of-processing, proving to the enterprise management
that the production systems are working correctly, or proving to the
customers that they indeed received a sequence of services with a
designated order.
4.3. Traffic Path Compliance
For legal or business compliance reasons, customers' personal data
cannot travel outside of certain geolocations, i.e., customer campus
or native country (GeoFencing). Path validation can detect and avoid
such exception. Similarly, path validation can make sure certain
undesired geolocations will not be travelled too.
Liu, et al. Expires 25 April 2024 [Page 5]
Internet-Draft Path Validation Problems Statement October 2023
4.4. High Security traffic path
1. End-to-end Security: Some customers have high-security service
path requirement for their sensitive traffic, i.e., VOIP calls or
video conferences for VIP clients, or a bank's financial data.
They need to make sure their data does not leak outside of their
chosen secure path, especially to some insecure devices or
domain.
2. To provide high-security VPN services for VIP customers, the
operator needs to prove that the VPN connection indeed passes
through a high security level service path.
4.5. Validating uRPF path
uRPF is a security feature that helps prevent source IP address
spoofing and denial-of-service (DoS) attacks
[RFC8704][RFC5635][RFC3704]. 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. Now path validation can do one more step of
validation, by sending a request for proof-of-transit all the way
back to the source. By sending the request to the source and
collecting transit proof of every hop on the path, the router can
validate if the currently stored path does not only exist but is also
unexpired, potentially reducing the false negative rate.
4.6. Segment Routing Security
In certain scenarios, user wishes to have explicit control over the
path that network traffic takes, in order to meet certain
performance, security or regulatory compliance requirements. Segment
routing enables source-based packet steering through networks using
segment lists. However current segment routing security is also
implied by assuming the router will truthfully forward the packet
according to the segment list. Path validation is a critical
verification technique that checks whether the planned path was
strictly followed, and could support segment routing as potential
security extensions.
5. Out-of-scopes
* Illegal data copy: This refers to an attack where the router
illegally copies and sends out the data he is currently
forwarding. We believe this is out-of-scope because data is
intangible by nature. Once fully obtained in the plaintext, there
is no mechanism to trace it unless using a data watermark
technique, which is out-of-scope.
Liu, et al. Expires 25 April 2024 [Page 6]
Internet-Draft Path Validation Problems Statement October 2023
* Stealth nodes: Stealth nodes are the inferior nodes that not
perceivable in the current layer. They could be old or
computationally weak nodes, or nodes within transparent tunnels.
We believe this is out-of-scope because layered design of the
Internet purposely makes tunnels and inferior nodes not
perceivable. It does not make sense to violate layered design
principle just trying to perceive stealth nodes. To the very
least, it is a problem that the control plane (BGPSec) also
suffers from [BGPSECATTACK], and the goal of this work is to fill
the gap between the control and data planes thus leaving the
problem out-of-scope.
6. Security Considerations
This document has no further security considerations.
7. IANA Considerations
This document has no IANA actions.
8. References
8.1. Normative References
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/rfc/rfc8205>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/rfc/rfc3704>.
[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>.
8.2. Informative References
[RFC5123] White, R. and B. Akyol, "Considerations in Validating the
Path in BGP", RFC 5123, DOI 10.17487/RFC5123, February
2008, <https://www.rfc-editor.org/rfc/rfc5123>.
[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>.
Liu, et al. Expires 25 April 2024 [Page 7]
Internet-Draft Path Validation Problems Statement October 2023
[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.filsfils-spring-path-tracing-05]
Filsfils, C., Abdelsalam, A., Camarillo, P., Yufit, M.,
Graf, T., Su, Y., Matsushima, S., Valentine, M., and
Dhamija, "Path Tracing in SRv6 networks", Work in
Progress, Internet-Draft, draft-filsfils-spring-path-
tracing-05, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-filsfils-
spring-path-tracing-05>.
[I-D.gilman-wimse-use-cases-00]
Gilman, E., Richer, J., Kasselman, P., and J. A. Salowey,
"Workload Identity Use Cases", Work in Progress, Internet-
Draft, draft-gilman-wimse-use-cases-00, 28 August 2023,
<https://datatracker.ietf.org/doc/html/draft-gilman-wimse-
use-cases-00>.
[BGPSEC] "Securing BGP with BGPsec", July 2011,
<https://www.potaroo.net/ispcol/2011-07/bgpsec.html>.
[BGPSECATTACK]
"BGP with BGPsec":" Attacks and Countermeasures", August
2019, <https://yihchun.com/papers/ieee-net-19.pdf>.
[SECUREROUTINGFAIL]
"Opinion":" Is secured routing a market failure?",
December 2022, <https://blog.apnic.net/2022/12/16/opinion-
is-secured-routing-a-market-failure/>.
[PATHVALIDATIONPAPER1]
"Atomos":" Constant-Size Path Validation Proof", January
2020, <https://dl.acm.org/doi/10.1109/TIFS.2020.3001669>.
[PATHVALIDATIONPAPER2]
"Unveiling the Mystery of Internet Packet Forwarding":" A
Survey of Network Path Validation", September 2020,
<https://dl.acm.org/doi/10.1145/3409796>.
[PATHVALIDATIONPAPER3]
"Lightweight source authentication and path validation",
August 2014,
<https://dl.acm.org/doi/abs/10.1145/2619239.2626323>.
Liu, et al. Expires 25 April 2024 [Page 8]
Internet-Draft Path Validation Problems Statement October 2023
[PATHVALIDATIONPAPER4]
"EPIC":" Every Packet Is Checked in the Data Plane of a
Path-Aware Internet", January 2020,
<https://www.usenix.org/conference/usenixsecurity20/
presentation/legner>.
Authors' Addresses
Chunchi Liu
Huawei
101 Ruanjian Ave
Nanjing
210012
China
Email: liuchunchi@huawei.com
Qin Wu
Huawei
China
Email: bill.wu@huawei.com
Liang Xia
Huawei
China
Email: frank.xialiang@huawei.com
Liu, et al. Expires 25 April 2024 [Page 9]
