idnits 2.17.1 draft-lin-opsec-trustroute-problem-statement-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (14 December 2021) is 864 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-14 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-18 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Lin 3 Internet-Draft H. Li 4 Intended status: Informational H3C 5 Expires: 17 June 2022 X. Shi 6 X. Yin 7 Tsinghua University 8 W. Chen 9 Capital Normal University 10 14 December 2021 12 Problem Statement and Use Cases of Trustworthiness-based Routing 13 draft-lin-opsec-trustroute-problem-statement-01 15 Abstract 17 Currently, network operators are trying to provide fine-granularity 18 Service Level Agreement (SLA) guarantee to achieve better Quality of 19 Experience (QoE) for end users and engage customers, such as ultra- 20 low latency and high reliability service. However, with increasing 21 security threats, differentiated QoE services are insufficient, the 22 demands for more differentiated security service are emerging. 24 This document explores the requirements for differentiated security 25 services and identifies the scenarios for network operators. To 26 provide differentiated security services, possible trustworthiness- 27 based routing solution is discussed. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 17 June 2022. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 65 3.1. Use Case 1: Customers Require Security Service . . . . . 3 66 3.2. Use Case 2: Providers Require Secure defense . . . . . . 4 67 4. Solution Discussions . . . . . . . . . . . . . . . . . . . . 5 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 73 8.2. Informative References . . . . . . . . . . . . . . . . . 6 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 For the traditional best effort service provided by IP networks, 79 routing is optimized for a single arbitrary metric, e.g. IGP cost in 80 OSPF and IS-IS. To support differentiated services, additional 81 routing metrics are used, such as bandwidth, jitter and delay. 82 However, security metrics and methods of corresponding treatment are 83 seldom taken into considerations. 85 Customers may request the network to transfer their traffic flows 86 with different security guarantees. Or the provider may classify 87 traffic flows into different classes by security-related features. 88 These traffic flows of different security service classes are 89 expected to be transmitted by different sets of nodes, because the 90 trustworthiness of different nodes is possibly not the same. The 91 traffic flows which have higher security requests are expected to be 92 transmitted by the nodes with higher trustworthiness. 93 Trustworthiness is used as a security metric to evaluate the 94 qualification of network elements for differentiated security 95 services. 97 This document describes the requirements and use cases of 98 trustworthiness-based routing. 100 2. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in BCP 105 14 [RFC2119] [RFC8174] when, and only when, they appear in all 106 capitals, as shown here. 108 Trustworthiness: The attribute of a network element used to evaluate 109 its qualification for security services. 111 3. Problem Statement 113 With more and more security incidents occur repeatedly, security 114 continues to be an increasingly important common concern for network 115 users and network operators. Good connectivity is insufficient, 116 higher and higher requirements for network security are emerging. 117 From different perspectives of operators and end users, there will be 118 different needs. On the one hand, end users require network 119 operators to ensure network security, on the other hand, network 120 operators need to prevent the intrusion and attack from malicious 121 users. Two following use cases are described: 123 3.1. Use Case 1: Customers Require Security Service 125 From the perspective of end users, different users may have different 126 security level requirements. Some users are sensitive to security 127 and would like the network path given by the operator to have higher 128 security. The network path is composed by many network forwarding 129 devices, and the trustworthiness of each device affects the 130 trustworthiness of the whole path. These network forwarding devices 131 come from different vendors, have different security capabilities, 132 and may have different security status at a certain time. Therefore, 133 operators need to evaluate the trustworthiness of network forwarding 134 devices, and choose different security level paths for users with 135 different security requirements. 137 +--------+ ########## +--------+ 138 Customer 1 --+--| node 1 |----# node 2 #----| node 3 |--- App Server 139 | +--------+ ########## +--------+ 140 Customer 2 --+ | | | 141 | | | 142 +--------+ +--------+ +--------+ 143 | node 4 |----| node 5 |----| node 6 | 144 +--------+ +--------+ +--------+ 146 In the above network, node 1, node 3, node 4, node 5 and node 6 have 147 advanced anti-hacker modules, but node 2 does not have such module. 148 Two customers at node 1 both need to visit the application server at 149 node 3. Customer 1 requests normal service. Customer 2 needs to 150 transmit confidential information and requests the network to provide 151 secure service. 153 For the packets from Customer 1, the shortest path is used. For the packets from Customer 2, the path only 155 contains the nodes with advanced anti-hacker modules, which can 156 reduce the risk of manipulation or disclosure. Therefore, node 2 is 157 excluded and the best path is . 160 3.2. Use Case 2: Providers Require Secure defense 162 For network operators, different users have different levels of 163 trustworthiness. Most users are normal and harmless, but there are 164 also a small number of users suspected of threatening network 165 security. Therefore, for users with threats, operators may consider 166 choosing paths with different security levels. 168 Traffic Flow 1 169 -+ +--------+ ########## +--------+ +- Addr B 170 +-->| node 1 |----# node 2 #----| node 3 |--+ 171 Traffic Flow 2 -+ +--------+ ########## +--------+ +- Addr D 172 | | | 173 | | | 174 +--------+ +--------+ +--------+ 175 | node 4 |----| node 5 |----| node 6 | 176 +--------+ +--------+ +--------+ 178 In the above network, node 1, node 3, node 4, node 5 and node 6 have 179 tracing modules which can record attacking packets, but node 2 does 180 not have such module. Two traffic flows enter the network at node 1 181 and need to be transmitted to node 3. A and B are authenticated 182 addresses, but C or D is not. The traffic flow which comes from an 183 authenticated address and goes to another authenticated address is 184 classified by the provider as a credible flow. Therefore, Traffic 185 Flow 1 is classified as credible, and Traffic Flow 2 is classified as 186 incredible. For Traffic Flow 1, the shortest path is used. For Traffic Flow 2, the packets are transmitted by 188 the nodes with tracing modules. If there are attacking packets in 189 Traffic Flow 2, these packets will be recorded and may be analyzed to 190 trace the attacker. Therefore, node 2 is excluded and the best path 191 is . 193 4. Solution Discussions 195 To provide differentiated security services, specific traffic flows 196 should be identified by the network. For example, the IPv4 TOS 197 field, the IPv6 Traffic Class field, or the 5-tuple in the IP and 198 transport protocol header of a packet can be used to determine its 199 security service class. 201 For the traditional best effort service, routing is optimized for a 202 single arbitrary metric, e.g. IGP cost in OSPF and IS-IS. To 203 support differentiated services, additional routing metrics are used, 204 such as bandwidth, jitter and delay. 206 Trustworthiness is an attribute of a network element which is used as 207 a security metric to evaluate its qualification for differentiated 208 security services. Trustworthiness attributes may be taken into 209 consideration of device capability, administration authority, 210 security protocol, etc. 212 When computing paths for differentiated security services, 213 trustworthiness attributes are added into the constraints. Then 214 particular traffic flows are steered into these paths. There are 215 several existing technologies that can steer traffic over a path that 216 is computed using different constraints instead of the shortest IGP 217 path. They may be extended to implement trustworthiness-based 218 routing. For example, Segment Routing Policy, as defined in 219 [I-D.ietf-idr-segment-routing-te-policy], enables the instantiation 220 of an ordered list of segments on a node for implementing a source 221 routing policy with a specific intent for traffic steering from that 222 node. For another example, Flexible Algorithm, as defined in 223 [I-D.ietf-lsr-flex-algo], provides a mechanism for IGP to compute 224 constraint-based paths under a combination of calculation-type, 225 metric-type, and constraints. Other technologies, such as multi- 226 topology routing, may also be candidates. Because of the flexibility 227 of these technologies, they can adapt to different perspectives and 228 needs from end users and network operators. 230 5. Security Considerations 232 TBD. 234 6. IANA Considerations 236 No IANA action is required so far. 238 7. Contributors 240 In addition to the authors listed on the front page, the following 241 co-authors have also contributed to this document: 243 Mengxiao Chen 244 H3C 246 Email: chen.mengxiao@h3c.com 248 Xiangqing Chang 249 H3C 251 Email: chang.xiangqing@h3c.com 253 8. References 255 8.1. Normative References 257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 258 Requirement Levels", BCP 14, RFC 2119, 259 DOI 10.17487/RFC2119, March 1997, 260 . 262 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 263 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 264 May 2017, . 266 8.2. Informative References 268 [I-D.ietf-idr-segment-routing-te-policy] 269 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 270 Jain, D., and S. Lin, "Advertising Segment Routing 271 Policies in BGP", Work in Progress, Internet-Draft, draft- 272 ietf-idr-segment-routing-te-policy-14, 10 November 2021, 273 . 276 [I-D.ietf-lsr-flex-algo] 277 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 278 A. Gulko, "IGP Flexible Algorithm", Work in Progress, 279 Internet-Draft, draft-ietf-lsr-flex-algo-18, 25 October 280 2021, . 283 Authors' Addresses 285 Tao Lin 286 H3C 288 Email: lintao@h3c.com 290 Hao Li 291 H3C 293 Email: lihao@h3c.com 295 Xingang Shi 296 Tsinghua University 298 Email: shixg@cernet.edu.cn 300 Xia Yin 301 Tsinghua University 303 Email: yxia@tsinghua.edu.cn 305 Wenlong Chen 306 Capital Normal University 308 Email: chenwenlong@cnu.edu.cn