idnits 2.17.1 draft-lin-opsec-trustroute-problem-statement-00.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 (June 18, 2021) is 1043 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-13 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-16 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: December 20, 2021 X. Shi 6 X. Yin 7 Tsinghua University 8 W. Chen 9 Capital Normal University 10 June 18, 2021 12 Problem Statement and Use Cases of Trustworthiness-based Routing 13 draft-lin-opsec-trustroute-problem-statement-00 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 demand 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 December 20, 2021. 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 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 66 3.1. Use Case 1: Customers Require Security Service . . . . . 3 67 3.2. Use Case 2:Providers Require Secure defense . . . . . . . 4 68 4. Solution Discussions . . . . . . . . . . . . . . . . . . . . 5 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 71 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 74 8.2. Informative References . . . . . . . . . . . . . . . . . 6 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 For the traditional best effort service provided by IP networks, 80 routing is optimized for a single arbitrary metric, e.g. IGP cost in 81 OSPF and IS-IS. To support differentiated services, additional 82 routing metrics are used, such as bandwidth, jitter and delay. 83 However, security metrics and methods of corresponding treatment are 84 seldom taken into considerations. 86 Customers may request the network to transfer their traffic flows 87 with different security guarantees. Or the provider may classify 88 traffic flows into different classes by security-related features. 89 These traffic flows of different security service class are expected 90 to be transmitted by different sets of nodes, because the 91 trustworthiness of different nodes is possibly not the same. The 92 traffic flows which have higher security requests are expected to be 93 transmitted by the nodes with higher trustworthiness. 95 Trustworthiness is used as a security metric to evaluate the 96 qualification of network elements for differentiated security 97 services. 99 This document describes the requirements and use cases of 100 trustworthiness-based routing. 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in BCP 107 14 [RFC2119] [RFC8174] when, and only when, they appear in all 108 capitals, as shown here. 110 Trustworthiness: The attribute of a network element used to evaluate 111 its qualification for security services. 113 3. Problem Statement 115 With more and more security incidents occur repeatedly, security 116 continues to be an increasingly important common concern for network 117 users and network operators. Good connectivity is insufficient, 118 higher and higher requirements for network security are emerging. 119 From different perspectives of operators and end users, there will be 120 different needs. On the one hand, end users want network operators 121 to ensure network security, on the other hand, network operators want 122 to prevent the intrusion and attack from malicious users. Two 123 following use cases are identified: 125 3.1. Use Case 1: Customers Require Security Service 127 From the perspective of end users, different users will have 128 different security level requirements. Some users are sensitive to 129 security and would like the network path given by the operator to 130 have higher security. The network path is composed by many network 131 forwarding devices, and the trustworthiness of each device affects 132 the trustworthiness of the whole path. These network forwarding 133 devices come from different vendors, have different security 134 capabilities, and may have different security status at a certain 135 time. Therefore, operators need to evaluate the trustworthiness of 136 network forwarding devices, and choose different security level paths 137 for users with different security requirements. 139 +--------+ ########## +--------+ 140 Customer 1 --+--| node 1 |----# node 2 #----| node 3 |--- App Server 141 | +--------+ ########## +--------+ 142 Customer 2 --+ | | | 143 | | | 144 +--------+ +--------+ +--------+ 145 | node 4 |----| node 5 |----| node 6 | 146 +--------+ +--------+ +--------+ 148 In the above network, node 1, node 3, node 4, node 5 and node 6 have 149 advanced anti-hacker modules, but node 2 does not have such module. 150 Two customers at node 1 both need to visit the application server at 151 node 3. Customer 1 requests normal service. Customer 2 needs to 152 transmit confidential information and requests the network to provide 153 secure service. For the packets from Customer 1, the shortest path 154 is used. 156 For the packets from Customer 2, the path only contains the nodes 157 with advanced anti-hacker modules, which can reduce the risk of 158 manipulation or disclosure. Therefore, node 2 is excluded and the 159 best path is . 161 3.2. Use Case 2:Providers Require Secure defense 163 For network operators, different users have different levels of 164 trustworthiness. Most users are normal and harmless, but there are 165 also a small number of users suspected of threatening network 166 security. Therefore, for users with threats, operators may consider 167 choosing paths with different security levels. 169 Traffic Flow 1 170 -+ +--------+ ########## +--------+ +- Addr B 171 +-->| node 1 |----# node 2 #----| node 3 |--+ 172 Traffic Flow 2 -+ +--------+ ########## +--------+ +- Addr D 173 | | | 174 | | | 175 +--------+ +--------+ +--------+ 176 | node 4 |----| node 5 |----| node 6 | 177 +--------+ +--------+ +--------+ 179 In the above network, node 1, node 3, node 4, node 5 and node 6 have 180 tracing modules which can record attacking packets, but node 2 does 181 not have such module. Two traffic flows enter the network at node 1 182 and need to be transmitted to node 3. A and B are authenticated 183 addresses, but C or D is not. The traffic flow which comes from an 184 authenticated address and goes to another authenticated address is 185 classified by the provider as a credible flow. Therefore, Traffic 186 Flow 1 is classified as credible, and Traffic Flow 2 is classified as 187 incredible. For Traffic Flow 1, the shortest path is used. For Traffic Flow 2, the packets are transmitted by 189 the nodes with tracing modules. If there are attacking packets in 190 Traffic Flow 2, these packets will be recorded and may be analyzed to 191 trace the attacker. Therefore, node 2 is excluded and the best path 192 is . 194 4. Solution Discussions 196 To provide differentiated security services, specific traffic flows 197 should be identified by the network. For example, the IPv4 TOS 198 field, the IPv6 Traffic Class field, or the 5-tuple in the IP and 199 transport protocol header of a packet can be used to determine its 200 security service class. 202 For the traditional best effort service, routing is optimized for a 203 single arbitrary metric, e.g. IGP cost in OSPF and IS-IS. To 204 support differentiated services, additional routing metrics are used, 205 such as bandwidth, jitter and delay. 207 Trustworthiness is an attribute of a network element which is used as 208 a security metric to evaluate its qualification for differentiated 209 security services. Trustworthiness attributes may be taken into 210 consideration of device capability, administration authority, 211 security protocol, etc. 213 When computing paths for differentiated security services, 214 trustworthiness attributes are added into the constraints. Then 215 particular traffic flows are steered into these paths. There are 216 several existing technologies that can steer traffic over a path that 217 is computed using different constraints instead of the shortest IGP 218 path. They may be extended to implement trustworthiness-based 219 routing. For example, Segment Routing Policy, as defined in 220 [I-D.ietf-idr-segment-routing-te-policy], enables the instantiation 221 of an ordered list of segments on a node for implementing a source 222 routing policy with a specific intent for traffic steering from that 223 node. For another example, Flexible Algorithm, as defined in 224 [I-D.ietf-lsr-flex-algo], provides a mechanism for IGP to compute 225 constraint-based paths under a combination of calculation-type, 226 metric-type, and constraints. Other technologies, such as multi- 227 topology routing, may also be candidates. Because of the flexibility 228 of these technologies, they can adapt to different perspectives and 229 needs from end users and network operators. 231 5. Security Considerations 233 TBD. 235 6. IANA Considerations 237 No IANA action is required so far. 239 7. Contributors 241 In addition to the authors listed on the front page, the following 242 co-authors have also contributed to this document: 244 Mengxiao Chen 245 H3C 247 Email: chen.mengxiao@h3c.com 249 Xiangqing Chang 250 H3C 252 Email: chang.xiangqing@h3c.com 254 8. References 256 8.1. Normative References 258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 259 Requirement Levels", BCP 14, RFC 2119, 260 DOI 10.17487/RFC2119, March 1997, 261 . 263 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 264 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 265 May 2017, . 267 8.2. Informative References 269 [I-D.ietf-idr-segment-routing-te-policy] 270 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 271 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 272 Routing Policies in BGP", draft-ietf-idr-segment-routing- 273 te-policy-13 (work in progress), June 2021. 275 [I-D.ietf-lsr-flex-algo] 276 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 277 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 278 algo-16 (work in progress), May 2021. 280 Authors' Addresses 282 Tao Lin 283 H3C 285 Email: lintao@h3c.com 287 Hao Li 288 H3C 290 Email: lihao@h3c.com 292 Xingang Shi 293 Tsinghua University 295 Email: shixg@cernet.edu.cn 297 Xia Yin 298 Tsinghua University 300 Email: yxia@tsinghua.edu.cn 302 Wenlong Chen 303 Capital Normal University 305 Email: chenwenlong@cnu.edu.cn