Internet DRAFT - draft-lin-opsec-trustroute-problem-statement
draft-lin-opsec-trustroute-problem-statement
Network Working Group T. Lin
Internet-Draft H. Li
Intended status: Informational New H3C Technologies
Expires: 27 July 2024 X. Shi
X. Yin
Tsinghua University
W. Chen
Capital Normal University
M. Chen
New H3C Technologies
24 January 2024
Problem Statement and Use Cases of Trustworthiness-based Routing
draft-lin-opsec-trustroute-problem-statement-04
Abstract
Currently, network operators are trying to provide fine-granularity
Service Level Agreement (SLA) guarantee to achieve better Quality of
Experience (QoE) for end users and engage customers, such as ultra-
low latency and high reliability service. However, with increasing
security threats, differentiated QoE services are insufficient, the
demands for more differentiated security service are emerging.
This document explores the requirements for differentiated security
services and identifies the scenarios for network operators. To
provide differentiated security services, possible trustworthiness-
based routing solution is discussed.
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 27 July 2024.
Lin, et al. Expires 27 July 2024 [Page 1]
Internet-Draft Trustworthiness Routing Problem Statemen January 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Use Case 1: Customers Require Security Service . . . . . 3
3.2. Use Case 2: Providers Require Secure defense . . . . . . 4
4. Solution Discussions . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
For the traditional best effort service provided by IP networks,
routing is optimized for a single arbitrary metric, e.g. IGP cost in
OSPF and IS-IS. To support differentiated services, additional
routing metrics are used, such as bandwidth, jitter and delay.
However, security metrics and methods of corresponding treatment are
seldom taken into considerations.
Lin, et al. Expires 27 July 2024 [Page 2]
Internet-Draft Trustworthiness Routing Problem Statemen January 2024
Customers may request the network to transfer their traffic flows
with different security guarantees. Or the provider may classify
traffic flows into different classes by security-related features.
These traffic flows of different security service classes are
expected to be transmitted by different sets of nodes, because the
trustworthiness of different nodes is possibly not the same. The
traffic flows which have higher security requests are expected to be
transmitted by the nodes with higher trustworthiness.
Trustworthiness is used as a security metric to evaluate the
qualification of network elements for differentiated security
services.
This document describes the requirements and use cases of
trustworthiness-based routing.
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.
Trustworthiness: The attribute of a network element used to evaluate
its qualification for security services.
3. Problem Statement
With more and more security incidents occur repeatedly, security
continues to be an increasingly important common concern for network
users and network operators. Good connectivity is insufficient,
higher and higher requirements for network security are emerging.
From different perspectives of operators and end users, there will be
different needs. On the one hand, end users require network
operators to ensure network security, on the other hand, network
operators need to prevent the intrusion and attack from malicious
users. Two following use cases are described:
3.1. Use Case 1: Customers Require Security Service
From the perspective of end users, different users may have different
security level requirements. Some users are sensitive to security
and would like the network path given by the operator to have higher
security. The network path is composed by many network forwarding
devices, and the trustworthiness of each device affects the
trustworthiness of the whole path. These network forwarding devices
come from different vendors, have different security capabilities,
and may have different security status at a certain time. Therefore,
Lin, et al. Expires 27 July 2024 [Page 3]
Internet-Draft Trustworthiness Routing Problem Statemen January 2024
operators need to evaluate the trustworthiness of network forwarding
devices, and choose different security level paths for users with
different security requirements.
+--------+ ########## +--------+
Customer 1 --+--| node 1 |----# node 2 #----| node 3 |--- App Server
| +--------+ ########## +--------+
Customer 2 --+ | | |
| | |
+--------+ +--------+ +--------+
| node 4 |----| node 5 |----| node 6 |
+--------+ +--------+ +--------+
In the above network, node 1, node 3, node 4, node 5 and node 6 have
advanced anti-hacker modules, but node 2 does not have such module.
Two customers at node 1 both need to visit the application server at
node 3. Customer 1 requests normal service. Customer 2 needs to
transmit confidential information and requests the network to provide
secure service.
For the packets from Customer 1, the shortest path <node 1, node 2,
node 3> is used. For the packets from Customer 2, the path only
contains the nodes with advanced anti-hacker modules, which can
reduce the risk of manipulation or disclosure. Therefore, node 2 is
excluded and the best path is <node 1, node 4, node 5, node 6, node
3>.
3.2. Use Case 2: Providers Require Secure defense
For network operators, different users have different levels of
trustworthiness. Most users are normal and harmless, but there are
also a small number of users suspected of threatening network
security. Therefore, for users with threats, operators may consider
choosing paths with different security levels.
Traffic Flow 1
<Src A, Dest B>-+ +--------+ ########## +--------+ +- Addr B
+-->| node 1 |----# node 2 #----| node 3 |--+
Traffic Flow 2 -+ +--------+ ########## +--------+ +- Addr D
<Src C, Dest D> | | |
| | |
+--------+ +--------+ +--------+
| node 4 |----| node 5 |----| node 6 |
+--------+ +--------+ +--------+
In the above network, node 1, node 3, node 4, node 5 and node 6 have
tracing modules which can record attacking packets, but node 2 does
not have such module. Two traffic flows enter the network at node 1
Lin, et al. Expires 27 July 2024 [Page 4]
Internet-Draft Trustworthiness Routing Problem Statemen January 2024
and need to be transmitted to node 3. A and B are authenticated
addresses, but C or D is not. The traffic flow which comes from an
authenticated address and goes to another authenticated address is
classified by the provider as a credible flow. Therefore, Traffic
Flow 1 is classified as credible, and Traffic Flow 2 is classified as
incredible. For Traffic Flow 1, the shortest path <node 1, node 2,
node 3> is used. For Traffic Flow 2, the packets are transmitted by
the nodes with tracing modules. If there are attacking packets in
Traffic Flow 2, these packets will be recorded and may be analyzed to
trace the attacker. Therefore, node 2 is excluded and the best path
is <node 1, node 4, node 5, node 6, node 3>.
4. Solution Discussions
To provide differentiated security services, specific traffic flows
should be identified by the network. For example, the IPv4 TOS
field, the IPv6 Traffic Class field, or the 5-tuple in the IP and
transport protocol header of a packet can be used to determine its
security service class.
For the traditional best effort service, routing is optimized for a
single arbitrary metric, e.g. IGP cost in OSPF and IS-IS. To
support differentiated services, additional routing metrics are used,
such as bandwidth, jitter and delay.
Trustworthiness is an attribute of a network element which is used as
a security metric to evaluate its qualification for differentiated
security services. Trustworthiness attributes may be taken into
consideration of device capability, administration authority,
security protocol, etc.
When computing paths for differentiated security services,
trustworthiness attributes are added into the constraints. Then
particular traffic flows are steered into these paths. There are
several existing technologies that can steer traffic over a path that
is computed using different constraints instead of the shortest IGP
path. They may be extended to implement trustworthiness-based
routing. For example, Segment Routing Policy, as defined in
[RFC9256], enables the instantiation of an ordered list of segments
on a node for implementing a source routing policy with a specific
intent for traffic steering from that node. For another example,
Flexible Algorithm, as defined in [RFC9350], provides a mechanism for
IGP to compute constraint-based paths under a combination of
calculation-type, metric-type, and constraints. Other technologies,
such as multi-topology routing, may also be candidates. Because of
the flexibility of these technologies, they can adapt to different
perspectives and needs from end users and network operators.
Lin, et al. Expires 27 July 2024 [Page 5]
Internet-Draft Trustworthiness Routing Problem Statemen January 2024
5. Security Considerations
TBD.
6. IANA Considerations
No IANA action is required so far.
7. Contributors
In addition to the authors listed on the front page, the following
co-authors have also contributed to this document:
Xiangqing Chang
New H3C Technologies
Email: chang.xiangqing@h3c.com
8. References
8.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/info/rfc2119>.
[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/info/rfc8174>.
8.2. Informative References
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
DOI 10.17487/RFC9350, February 2023,
<https://www.rfc-editor.org/info/rfc9350>.
Authors' Addresses
Tao Lin
New H3C Technologies
Email: lintao@h3c.com
Lin, et al. Expires 27 July 2024 [Page 6]
Internet-Draft Trustworthiness Routing Problem Statemen January 2024
Hao Li
New H3C Technologies
Email: lihao@h3c.com
Xingang Shi
Tsinghua University
Email: shixg@cernet.edu.cn
Xia Yin
Tsinghua University
Email: yxia@tsinghua.edu.cn
Wenlong Chen
Capital Normal University
Email: chenwenlong@cnu.edu.cn
Mengxiao Chen
New H3C Technologies
Email: chen.mengxiao@h3c.com
Lin, et al. Expires 27 July 2024 [Page 7]
