idnits 2.17.00 (12 Aug 2021) /tmp/idnits22956/draft-li-dsav-framework-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (11 January 2022) is 123 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2827' is defined on line 353, but no explicit reference was found in the text == Unused Reference: 'RFC5210' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'RFC7039' is defined on line 368, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Li 3 Internet-Draft J. Wu 4 Intended status: Informational Tsinghua University 5 Expires: 15 July 2022 M. Huang 6 Huawei 7 L. Qin 8 Tsinghua University 9 N. Geng 10 Huawei 11 11 January 2022 13 Distributed Source Address Validation (DSAV) Framework 14 draft-li-dsav-framework-01 16 Abstract 18 This document provides an overall framework of Distributed Source 19 Address Validation (DSAV) including both intra-domain and inter- 20 domain levels. It also describes related considerations. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 8174 [RFC8174]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 15 July 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. DSAV Framework . . . . . . . . . . . . . . . . . . . . . . . 3 64 3.1. Separate Source Information Advertisement . . . . . . . . 5 65 3.2. Destination Information Identifier . . . . . . . . . . . 6 66 4. Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5. Consistency . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 6. Deployability . . . . . . . . . . . . . . . . . . . . . . . . 8 69 7. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 Source address validation (SAV) is important to mitigate source 76 address spoofing and contribute to the Internet security. However, 77 existing SAV mechanisms have limitations in accuracy. Specifically, 78 intra-domain SAV mechanisms (e.g. strict uRPF[RFC3704]) usually 79 improperly block legitimate traffic in the case of routing asymmetry, 80 while inter-domain SAV mechanisms (e.g. loose uRPF[RFC3704] and EFP- 81 uRPF[RFC8704]) provide overly loose SAV rules which can improperly 82 permit spoofed traffic. The root cause of their limitations is that 83 they all achieve SAV based on local forwarding information base (FIB) 84 or routing information base (RIB), which may not match the real 85 forwarding direction from the source. In order to guarantee the 86 accuracy, SAV should follow the real data-plane forwarding path. 88 This document provides a framework to generate accurate SAV rules on 89 routers at both intra-domain and inter-domain levels. In Distributed 90 Source Address Validation (DSAV) framework, each router or AS 91 originates individual protocol messages to its neighbors, carrying 92 local source information and corresponding destination information 93 which takes the neighbor as the next hop. Upon receiving a protocol 94 message, the router or AS identifies a valid incoming interface for 95 the related source addresses. After that, it decides whether to 96 terminate the message or further relay new protocol messages to its 97 neighbors based on the destination information of the received 98 message. In this way, the source information will propogate through 99 all possible forwarding paths originated from the source. 101 This document also describes basic considerations related to DSAV, 102 including accuracy, consistency, deployability, and security. 104 2. Terminology 106 Some definitions during a propagation process: 108 * Node: A router or AS in this document. 110 * Initial node: The node generating original protocol messages. 112 * Terminal node: The node terminating the received protocol message 113 from a neighbor node. 115 3. DSAV Framework 117 DSAV provides a framework for distributedly generating SAV rules on 118 nodes at both intra-domain and inter-domain levels. Intra-domain SAV 119 avoids source address spoofing within the same AS. Inter-domain SAV 120 prevents source address spoofing among ASes. Despite of different 121 application scenarios and protocol details, DSAVs at the two levels 122 hold the same key idea. The core workflow of DSAV is briefly 123 described as follows: 125 a. An initial node A generates an original message for each neighbor 126 node, carrying the source prefixes originated locally and the 127 destination prefixes which take the neighbor node as the next 128 hop. 130 b. When node B receives a protocol message at interface I, it 131 determines interface I as a valid incoming interface for the 132 source prefixes of the received message. In other words, it 133 generates the SAV rule . 135 c. After that, node B checks the destination prefixes of the 136 received message against its local FIB/RIB. If the next hop of 137 all the destination prefixes point to its local subnets/networks, 138 the message is terminated; otherwise, node B relays new messages. 139 It groups all destination prefixes according to their next-hop 140 node. For each next-hop node C, node B generates a new message 141 destined to C, with the corresponding destination prefixes taking 142 node C as the next hop. The source prefixes in each relayed 143 message should keep the same. 145 d. In DSAV, with the exception of some special cases, such as 146 multipath routing, nodes usually receive only one message 147 originated from each source. 149 e. The above steps can be executed periodically or when any of 150 source prefixes, destination information, or forwarding paths 151 change. The updated message should add updated SAV rules or 152 delete outdated SAV rules for the affected Nodes. Particularly, 153 to reduce the communication overhead, only the changed 154 information should be propagated again when dynamic updating. 156 Figure 1 illustrates the workflow of DSAV. The network runs some 157 routing protocols such as OSPF, IS-IS, or BGP among the four nodes. 158 Each node owns a unique source prefix ( e.g. P1 for Node 1). Let's 159 consider the propagation process where Node 1 is the initial node. 160 Node 1 sends an original message to the neighbor Node 2, carrying its 161 source prefix (i.e., P1) and destination prefixes whose next-hop node 162 in FIB is Node 2 (i.e., P2, P3, P4). When Node 2 receives the 163 message, it specifies interface '#' as the valid incoming interface 164 for prefix P1. Then, Node 2 checks the destination prefixes 165 according to its local FIB. Since P3 and P4 are not Node 2's source 166 prefixes, it should relay messages to the corresponding next-hop 167 nodes, i.e. Node 3 and Node 4. The message destined to Node 3 168 carries the destination prefix P3, while the message destined to Node 169 4 carries the destination prefix P4. The source prefix in each 170 relayed message keeps the same. When Node 3 or Node 4 receives the 171 message from Node 2, it also learns and enables the SAV rule but terminates the message. 174 +----------+ 175 | Node 1 +---+P1 176 +----+-----+ 177 | pkt:src_v=[P1], 178 | dst_v=[P2,P3,P4] 179 pkt:src_v=[P1], | 180 +----------+ dst_v=[P4] +-----#-----+ 181 | Node 4 #-------------+ Node 2 |---+P2 182 +-----+----+ +-----+-----+ 183 | | pkt:src_v=[P1], 184 + | dst_v=[P3] 185 P4 | 186 +-----#-----+ 187 | Node 3 +---+P3 188 +-----------+ 190 - P1, P2, P3, and P4 are prefixes belonging to 191 Node 1, 2, 3, and 4, respectively. 192 - Node 1 is the initial node, and Node 3 and Node 4 193 are the terminate nodes in this propagation process. 194 - '#' means the legitimate interface for the 195 data-plane packets with source addresses of P1. 197 Figure 1: The workflow of DSAV 199 3.1. Separate Source Information Advertisement 201 Containing source prefixes and destination prefixes in a message 202 sometimes induces much unnecessary overhead. For example, a change 203 on a destination prefix or forwarding path will make the initial node 204 advertise its source prefixes again even though no changes happen on 205 its local source prefixes at all. A separate source information 206 advertisement is taken to tackle the above problem. 208 Particularly, a node can be represented by a node ID (e.g., the 209 router-ID for a router or the ASN for an AS). For each initial node, 210 its source prefixes together with its node ID can be advertised to 211 other nodes through broadcast or existing underlay routing protocols 212 (such as OSPF, IS-IS, and BGP). Then, other nodes will know the 213 mapping from a node ID to a list of source prefixes. Now, the 214 protocol message does not need to carry a long list of source 215 prefixes whose field can be replaced with just one source node ID. 217 3.2. Destination Information Identifier 219 Although separate source information advertisement help reduce 220 communication overhead, including destination prefixes in messages 221 can still be costly, especially in inter-domain scenarios with a 222 large number of destination prefixes. 224 Similarly, a list of destination prefixes can also be replaced with a 225 destination node IDs (e.g., the router-ID for a router or the ASN for 226 an AS). Considering that a node may have hundreds of different 227 prefixes, this can significantly reduce overhead. However, the 228 replacement of destination prefixes may result in accuracy problems 229 in some scenarios where the destination prefixes belonging to a same 230 destination node have different forwarding paths. Some additional 231 mechanisms need to be imported into these scenarios. 233 4. Accuracy 235 The goal of DSAV is to achieve high accuracy, i.e., avoid improper 236 block problems and try best to reduce improper permit problems. The 237 improper block problem means legitimate traffic is mistakenly 238 dropped. The improper permit problem means spoofed traffic is 239 mistakenly passed. 241 The accuracy of DSAV is determined by the accuracy of source 242 information advertisement and propagation process. The 243 incompleteness of received source information can compromise the 244 accuracy of SAV. So, each initial node should discover and advertise 245 local source information carefully with the help of either automatic 246 programs or manual configurations. In the case of incomplete source 247 information, the node can take a remedy method at the data plane, 248 i.e., only drop packets with known source addresses but coming from 249 invalid interfaces. Packets with unknown source addresses should be 250 accepted by default. More details will be described in Section 6. 252 The key of DSAV is to generate SAV rules strictly following the real 253 data-plane forwarding paths. Any factor that can affect forwarding 254 should be considered. Here are three kinds of common forwarding 255 cases: 257 * Only FIBs affect forwarding. 259 * ECMP (Equal-cost multi-path routing) or UCMP (Unequal-cost multi- 260 path routing). To achieve multi-path routing, hashing functions 261 are usually taken, which map packet header field values (e.g., 262 source/destination IP address, source/destination port number, 263 protocol number) to candidate next hops. Packets with the same 264 destination IP address may be forwarded to different next hops. 266 * ACL redirection. An ACL rule can have multiple match fields, and 267 the match field of destination IP addresses can be included or not 268 in an ACL rule. So, similar to ECMP/UCMP, the packets with the 269 same destination IP address may have different next-hop 270 interfaces. 272 As described in Section3, DSAV can work well in the first case. To 273 ensure accuracy in arbitrary routing scenarios, the last two cases 274 should also be considered. 276 5. Consistency 278 The factors influencing the accuracy of DSAV may change with time. 279 Such changes will lower the performance of SAV and lead to improper 280 block or improper permit problems. The SAV rules generated through 281 DSAV should be updated in time so as to keep consistent with routing 282 states. The consistency of DSAV is important for the SAV framework 283 working well in real networks. 285 A simple method is to send updated messages periodically. An aging 286 mechanism can also be used for SAV rules. That is, SAV rules will 287 expire after a period of time. However, these solutions may take 288 much time before eliminating improper block and improper permit 289 problems. Some quick convergence mechanisms are necessary to achieve 290 consistency of DSAV in time. Here are some preliminary ideas for 291 different cases: 293 * Source information changes. A node sends new source information 294 advertisements immediately upon discovering its local source 295 prefixes change. 297 * Routing state changes. When route configuration or topology 298 changes, the forwarding path to a destination prefix may change. 299 These changes can trigger the initial node to generate updated 300 messages for the changed forwarding paths. Then, new SAV rules 301 can be added and outdated SAV rules can be withdrawn at other 302 nodes quickly. For the scenarios where fast reroute (FRR) is 303 deployed, the initial node can send message to the backup 304 forwarding paths in advance, and the backup SAV rules can be 305 installed for fast convergence under failures. 307 6. Deployability 309 It is difficult to ensure that all nodes deploy DSAV simultaneously, 310 especially at inter-domain level. In this case, each node only 311 learns partial source address information or incomplete legitimate 312 incoming interfaces for a source prefix, which can lead to improper 313 block problems. Therefore, DSAV should support incremental and 314 partial deployment. 316 When deployed incrementally or partially, nodes should still aviod 317 improper block problems and minimize improper permit problems based 318 on incomplete SAV tables. The process of data-plane SAV is as 319 follows: 321 * For the source address whose source address information and 322 incoming interface information are fully learned, nodes can 323 strictly validate the authenticity by querying in SAV tables. 326 * For the source address whose source address information or 327 incoming interface information is only partially learned or even 328 not learned, nodes should pass those packets by default to avoid 329 improper block problems, since it is hard to identify the 330 authenticity with incomplete information. 332 Since inter-domain topology is greatly complex and ASes are managed 333 by individual network operators, determining whether the incoming 334 interface information for a source prefix is learned completely is a 335 real challenge. Besides, in DSAV framework, neighboring (next-hop) 336 node plays an important role in the propagation of probing packets, 337 namely, a node cannot send or receive any probing packet if its 338 neighboring nodes don't support DSAV. Hence, at inter-domain level, 339 DSAV recommends incremental deployment by customer cones. This 340 deployment pattern ensures that each AS learns complete source 341 address information and incoming interface information for other ASes 342 within the same customer cone. With the merger of different customer 343 cones where DSAV is deployed, the deployment scope of DSAV will 344 gradually expand, and the defense capability against source address 345 spoofing will gradually increase. 347 7. Security 349 TBD 351 8. Normative References 353 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 354 Defeating Denial of Service Attacks which employ IP Source 355 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 356 May 2000, . 358 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 359 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 360 2004, . 362 [RFC5210] Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams, 363 "A Source Address Validation Architecture (SAVA) Testbed 364 and Deployment Experience", RFC 5210, 365 DOI 10.17487/RFC5210, June 2008, 366 . 368 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 369 "Source Address Validation Improvement (SAVI) Framework", 370 RFC 7039, DOI 10.17487/RFC7039, October 2013, 371 . 373 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 374 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 375 May 2017, . 377 [RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced 378 Feasible-Path Unicast Reverse Path Forwarding", BCP 84, 379 RFC 8704, DOI 10.17487/RFC8704, February 2020, 380 . 382 Authors' Addresses 384 Dan Li 385 Tsinghua University 386 Beijing 387 China 389 Email: tolidan@tsinghua.edu.cn 391 Jianping Wu 392 Tsinghua University 393 Beijing 394 China 396 Email: jianping@cernet.edu.cn 397 Mingqing Huang 398 Huawei 399 Beijing 400 China 402 Email: huangmingqing@huawei.com 404 Lancheng Qin 405 Tsinghua University 406 Beijing 407 China 409 Email: qlc19@mails.tsinghua.edu.cn 411 Nan Geng 412 Huawei 413 Beijing 414 China 416 Email: gengnan@huawei.com