idnits 2.17.00 (12 Aug 2021) /tmp/idnits3222/draft-xu-psav-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 document date (12 February 2022) is 91 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5210' is defined on line 365, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Xu 3 Internet-Draft J. Wu 4 Intended status: Informational X. Wang 5 Expires: 16 August 2022 Y. Guo 6 Tsinghua University 7 12 February 2022 9 Practical Inter-Domain Source Address Validation 10 draft-xu-psav-00 12 Abstract 14 Because the Internet forwards packets according to the IP destination 15 address, packet forwarding typically takes place without inspection 16 of the source address and malicious attacks have been launched using 17 spoofed source addresses. The inter-domain source address validation 18 architecture is an effort to enhance the Internet by using state 19 machine to generate consistent tags. When communicating between two 20 end hosts at different ASes, tags will be added to the packets to 21 identify the authenticity of the IP source address. 23 This memo introduces PSAV, an Inter-AS source address validation 24 mechanism. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 16 August 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology and Abbreviation . . . . . . . . . . . . . . . . 3 61 3. PSAV Framework . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. Consistency . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 7. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 7.1. Compatibility . . . . . . . . . . . . . . . . . . . . . . 7 67 7.2. Expansion Management . . . . . . . . . . . . . . . . . . 7 68 8. Security Consideration . . . . . . . . . . . . . . . . . . . 7 69 8.1. Attack towards community information . . . . . . . . . . 8 70 8.2. Attacks towards Initial Status Negotiation . . . . . . . 8 71 8.3. Tag Guessing and Key Cracking . . . . . . . . . . . . . . 8 72 9. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 8 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 74 11. Normative References . . . . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 IP spoofing has been a long-recognized threat to Internet security 80 for decades. Inter-domain source address validation (SAV) has long 81 served as the primary defense mechanism due to its better cost- 82 effectiveness. However, over years of effort, the deployment of 83 inter-domain source address validation is still not optimistic. An 84 important reason for this is the difficulty of balancing the clear 85 security benefits of partial deployments with the scalability of 86 large-scale deployments. uRPF [RFC5635], for example, routing-based 87 schemes to filter spoofed traffic, which may result in a lack of 88 security benefits due to the dynamic nature of routing or incomplete 89 information caused by partial deployments. And while cryptography- 90 based schemes such as IPsec [RFC4301] can provide clear security 91 gains, the additional end-to-end overhead will present new challenges 92 in scalability. 94 This document provides a framework of practical inter-domain SAV 95 (PSAV). PSAV is a cryptography-based SAV to guarantee consistent 96 security benefits. Key maintenance is performed between the source 97 and destination ASes, and the key is used to generate packet tags to 98 validate the authenticity of the source address. Meanwhile, in PSAV, 99 ASes are organized as a hierarchical structure to provide 100 scalability, in which only fully-connected key maintenance is 101 performed between ASes on the same layer, and ASes between different 102 layers achieve end-to-end source address validation through cross- 103 layer validation and tag replacement. 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119, BCP 14 108 [RFC2119] and indicate requirement layers for compliant CoAP 109 implementations. 111 2. Terminology and Abbreviation 113 +==============+======================================+ 114 | Abbreviation | Description | 115 +==============+======================================+ 116 | TA | Trust Alliance, the IPv6 network | 117 | | that uses the SAVA-X mechanism. | 118 +--------------+--------------------------------------+ 119 | ACS | AD Control Server, the server that | 120 | | matains state machine with other ACS | 121 | | and distribute information to AER. | 122 +--------------+--------------------------------------+ 123 | ABR | AS or AS community border router, | 124 | | which is placed at the boundary of | 125 | | an AS of trust alliance. | 126 +--------------+--------------------------------------+ 127 | Tag | The authentic identification of | 128 | | source address of a packet. | 129 +--------------+--------------------------------------+ 131 Table 1 133 3. PSAV Framework 135 PSAV is a cryptography-based end-to-end inter-domain source address 136 verification method that guarantees security benefits at partial 137 deployment. PSAV implements inter-AS tag maintenance by establishing 138 a hierarchical community structure that utilizes border nodes on the 139 forwarding path for tag replacement and validation. This mainly 140 includes the following components. 142 1. Tag generation. In PSAV, the packet tag is generated by 143 maintaining the key between ASes and using the generation 144 algorithm. The destination AS will validate the source address 145 by the packet tag. The above process requires a mapping 146 relationship between AS-IP_Prfix-Key, which will be provided 147 based on existing Internet infrastructure, e.g., such as RPKI, 148 ROVER, etc. 150 2. Hierarchical structure. In PSAV, AS is organized into 151 hierarchical AS communities, which can provide good scalability 152 by reducing the tag maintenance overhead in large-scale 153 deployments, managing the validation responsibilities 154 corresponding to address allocation, and shielding external 155 community changes. To implement tag validation in AS 156 communities, PSAV will provide corresponding tag cross-layer 157 validation and replacement methods. 159 3. Membership configuration. AS sends join, exit, or update to all 160 participating nodes through a specific message format, and the 161 participating nodes further complete membership configuration by 162 verifying the authenticity of the messages to form a distributed 163 consensus. 165 A typical workflow of PSAV is shown in Figure 1. AS1 joins the PSAV 166 trust alliance with the signed join information, maintains the packet 167 tag with AS2. After that, AS1 sends out the packet with Tag , and AS2 validates it and replaces the Tag with . 169 Then AS3 validates and replaces the tag with . After AS4 170 validation, confirm that the packet source address is true. 172 +----------------------------------------------------------------+ 173 | +---------------+ +---------------+ | 174 | | | | | | 175 | | AS3 |****************| AS4 | | 176 | | | | | | 177 | +---------------+ +---------------+ | 178 | // * \\ | 179 | // * \\ AS Community (N-1) | 180 +-------//------------------*------\\----------------------------+ 181 // * \\ 182 // * \\ 183 // * \\ 184 // * \\ 185 +--------------------------------*-----------+ 186 | * | 187 | +----------+ +----------+ | 188 | | | | | | 189 | | AS1 |******************| AS2 | | 190 | | | | | | 191 | +----------+ +----------+ | 192 | AS Community N | 193 +--------------------------------------------+ 195 Figure 1: PSAV workflow example. 197 4. Control Plane 199 The functions of control plane of PSAV includes AS community 200 information management, ACS-ACS communication, and ACS-ABR 201 communication. 203 To eliminate the impact of routing dynamic caused by BGP or other 204 routing protocols, PSAV requires its own AS community information 205 management. These information of one AS includes AS Number (ASN), AS 206 Community Number (ASCN), IP Prefix and Public Key. PSAV does not bind 207 any methods of inter-domain mapping information, and it can both use 208 centralized or distributed methods to maintain AS community 209 information independently. When an AS or AS community wants to join 210 or exit the Trust Alliance construted by all the member ASes and AS 211 communities, it SHOULD submit an certificate signning request message 212 containing its own information. It also needs to submit such CSR 213 message for updating its information recorded by all members in trust 214 alliance. 216 The communication among ACSes is to maintain the tags used in packets 217 in network. PSAV provides a tag generation mechanism on one-to-one 218 state machine. In this mechanism, each AS or AS community needs one 219 ACS. ACS negotiates initial state of the state machine with its 220 relavent ACS. The state transfers to the next state triggered by 221 time flies. For crossing different layer of AS communities, it is 222 used the tag generated by the state machine maintained by AS or AS 223 community with its direct paternal AS community in PSAV. The 224 communication between ACS and ABR is to deliver the AS community 225 information and tags. 227 PSAV requires a heart-beat mechanism for service availability 228 implemented in ACS-ACS commmunication and ACS-ABR communication. 229 When it detects that one ACS or ABR has 'died', the other end WOULD 230 remove its tag generation mechanism maintained with this 'died' end 231 and sends a request message to force execute the exit trust alliance 232 process of the other end. 234 5. Data Plane 236 The functions of data plane of PSAV includes prefix checking and tag 237 processing. 239 The tag delivered from the control plane indicates the source address 240 of one packet is not tampered. As the tag in use is generated by 241 one-to-one state machine pair, it MUST be completely consistent at 242 the same time. 244 It needs to divide the role of different interfaces of an ABR for 245 functioning properly. In ABR, the interface takes the role of 246 INGRESS, EGRESS, or TRUST. The INGRESS port links to the devices 247 inside the AS or AS community, the EGRESS port links to the devices 248 outside the AS or AS community, and the TRUST port links to the ABR 249 inside the same AS or AS community. The INGRESS port validates and 250 removes the tag in use. The EGRESS port adds or replaces the tag in 251 the packet. The TRUST port does nothing to the packet. 253 When a packet arrives at the ABR, it SHOULD be checked its source 254 address and destination address first. If it originates and 255 destinates the trust alliance, it MUST be tagged with a tag at the 256 first hop and removed tag at the last hop. When this packet forwards 257 crossing different layers of AS communities, it SHOULD be replaced 258 with relavent tags maintained by its ACS with direct paternal ACS. 259 In ABR, it maintains two mapping tables to record the AS community 260 information and tags in use. The AS-Prefix mapping table preserves 261 the ASN or ASCN and IP address prefix relationships. The AS-Tag 262 mapping table holds the ASN or ASCN and relevant tags. When a packet 263 is needed to add, replace, or remove tag, the ABR WOULD get the ASN 264 or ASCN which the packet belongs to first via the source address of 265 the packet from the AS-Prefix mapping table. The ABR WOULD obtain 266 the tag should be used by the ASN or ASCN from the AS-Tag mapping 267 table. 269 6. Consistency 271 PSAV is a cryptography-based source address validation mechanism to 272 guarantee consistent security benefits and provide scalability for 273 different deployment scales and validation granularity. PSAV uses 274 the hierarchical structure to reduce the size of the secret symmetric 275 keys to cut down the maintenance overhead. Hierarchy validation 276 filters malicious traffic as early as possible to avoid wasting 277 network resources. PSAV also provides clear security 278 responsibilities corresponding to IP address allocation authority. 280 7. Scalability 282 7.1. Compatibility 284 Hierarchy effectively blocks external changes and provides 285 scalability in large-scale deployments. AS the forwarding path is 286 indepent of the tag validation by using a mechanism for crossing 287 different layers, PSAV is a segmented end-to-end cryptography scheme 288 essentially. So it does not need to obtain the routing information 289 and has nothing influence on existing routing infrastructure. 290 Meanwhile, PSAV supports that packets can pass through networks where 291 PSAV has not yes been deployed without affecting validation as it is 292 end-to-end validation in nature, which is guaranteeing a definite 293 security benefit for the deployer without requiring a deployment 294 rate. 296 7.2. Expansion Management 298 On one hand, PSAV effectively isolates structural changes outside the 299 community from internal nodes, as the hierarchical community design 300 minimizes the impact of changes on the rest of the system. On the 301 other hand, PSAV can be implemented with any existing distributed 302 consensus algorithm for inter-AS consensus infrastructure. It should 303 be noted that PSAV has no special requirements for the efficiency of 304 this process based on the assumption that AS community information 305 does not change frequently. Therefore, the decentralized maintenance 306 approach can further reduce the management complexity of the 307 expansion process. 309 8. Security Consideration 310 8.1. Attack towards community information 312 The distributied method to maintain the AS community information MAY 313 suffer from the consistency challenges, such as witch attacks and 314 eclipse attacks. However, the situation in PSAV is different from 315 the normal distributed consensus scenario. Due to the hierarchical 316 structure of PSAV, the failure of consensus on local community 317 information does not affect other non-adjacent communities in the 318 system. At the same time, the updated community information only 319 needs the signature confirmation of its parent, brother and child 320 communities, which means that the attack on the special node needs to 321 hold specific resources, which further increases the difficulty of 322 the attack. 324 8.2. Attacks towards Initial Status Negotiation 326 This is the problem posed in the PSAV implementation. As the clock- 327 synchronized state machine will run locally after the initial status 328 negotiation stage, the attacker can only attack on this negotiation. 329 However, when the ACS-ACS pair or ACS-ABR pair is going to connect, 330 the SSL/TLS will be used to guarantee security in communication. 331 Therefore PSAV can ensure that attackers cannot obtain the initial 332 status even if it can eavesdrop the negotiation packet online. 334 8.3. Tag Guessing and Key Cracking 336 For resisting reply attack, the eventual tag used in a packet is 337 generated by the ABR with hashing a five-tuple including the 338 signature generated from the state machine, the source address, the 339 destination address, the first 8-bit of payload and source address 340 prefix length. The attacker could guess the tag and crack that key 341 using brute force. Nevertheless, it depends on the irreversibility 342 of a Hash function to prevent backstepping the key from the tag. 343 Furthermore, to decrease such probability, the signature generatated 344 from the state machine will be updated periodically. 346 9. IANA Consideration 348 TBD. 350 10. Acknowledgements 352 TBD. 354 11. Normative References 356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", BCP 14, RFC 2119, 358 DOI 10.17487/RFC2119, March 1997, 359 . 361 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 362 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 363 December 2005, . 365 [RFC5210] Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams, 366 "A Source Address Validation Architecture (SAVA) Testbed 367 and Deployment Experience", RFC 5210, 368 DOI 10.17487/RFC5210, June 2008, 369 . 371 [RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole 372 Filtering with Unicast Reverse Path Forwarding (uRPF)", 373 RFC 5635, DOI 10.17487/RFC5635, August 2009, 374 . 376 Authors' Addresses 378 Ke Xu 379 Computer Science, Tsinghua University 380 Qinghuayuan street, Haidian District 381 Beijing 382 100084 383 China 385 Email: xuke@tsinghua.edu.cn 387 Jianping Wu 388 Computer Science, Tsinghua University 389 Qinghuayuan street, Haidian District 390 Beijing 391 100084 392 China 394 Email: jianping@cernet.edu.cn 395 Xiaoliang Wang 396 Computer Science, Tsinghua University 397 Qinghuayuan street, Haidian District 398 Beijing 399 100084 400 China 402 Email: wangxiaoliang0623@foxmail.com 404 Yangfei Guo 405 Institute for Network Sciences and Cyberspace, Tsinghua University 406 Qinghuayuan street, Haidian District 407 Beijing 408 100084 409 China 411 Email: guoyangf19@mails.tsinghua.edu.cn