idnits 2.17.1 draft-wu-sava-testbed-experience-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1101. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1112. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1119. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1125. 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 abstract seems to contain references ([Wu07]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 15, 2008) is 5815 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Wu 3 Internet-Draft J. Bi 4 Intended status: Experimental X. Li 5 Expires: November 16, 2008 G. Ren 6 K. Xu 7 Tsinghua University 8 M. Williams 9 Juniper Networks 10 May 15, 2008 12 SAVA Testbed and Experiences to Date 13 draft-wu-sava-testbed-experience-06 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on November 16, 2008. 40 Abstract 42 Because the Internet forwards packets according to the IP destination 43 address, packet forwarding typically takes place without inspection 44 of the source address and malicious attacks have been launched using 45 spoofed source addresses. In an effort to enhance the Internet with 46 IP source address validation, a prototype implementation of the IP 47 Source Address Validation Architecture (SAVA) was created [Wu07] and 48 an evaluation was conducted on an IPv6 network. This document 49 reports on the prototype implementation and the test results, as well 50 as the lessons and insights gained from experimentation. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. A Prototype SAVA Implementation . . . . . . . . . . . . . . . 5 57 2.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 5 58 2.2. IP Source Address Validation in the Access Network . . . . 7 59 2.3. IP Source Address Validation at Intra-AS/Ingress Point . . 10 60 2.4. IP Source Address Validation in Inter-AS Case 61 (Neighboring AS) . . . . . . . . . . . . . . . . . . . . . 10 62 2.5. IP Source Address Validation in Inter-AS Case 63 (Non-Neighboring AS) . . . . . . . . . . . . . . . . . . . 13 65 3. SAVA Testbed . . . . . . . . . . . . . . . . . . . . . . . . . 17 66 3.1. CNGI-CERNET2 . . . . . . . . . . . . . . . . . . . . . . . 17 67 3.2. SAVA Testbed on CNGI-CERNET2 Infrastructure . . . . . . . 17 69 4. Test Experience and Results . . . . . . . . . . . . . . . . . 20 70 4.1. Test Scenarios . . . . . . . . . . . . . . . . . . . . . . 20 71 4.2. Test Results . . . . . . . . . . . . . . . . . . . . . . . 20 73 5. Limitations and Issues . . . . . . . . . . . . . . . . . . . . 22 74 5.1. General Issues . . . . . . . . . . . . . . . . . . . . . . 22 75 5.2. Security Issues . . . . . . . . . . . . . . . . . . . . . 23 76 5.3. Protocol Details . . . . . . . . . . . . . . . . . . . . . 23 78 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 25 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 87 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 88 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 91 Intellectual Property and Copyright Statements . . . . . . . . . . 32 93 1. Introduction 95 By design the Internet forwards data packets solely based on the 96 destination IP address. The source IP address is not checked during 97 the forwarding process in most cases. This makes it easy for 98 malicious hosts to spoof the source address of the IP packet. We 99 believe that it would be useful to enforce the validity of the source 100 IP address for all the packets being forwarded. 102 Enforcing the source IP address validity would help us achieve the 103 following goals: 105 o Since packets which carry spoofed source addresses would not be 106 forwarded, it would be impossible to launch network attacks which 107 are enabled by using spoofed source addresses and more difficult 108 to successfully carry out attacks enhanced or strengthened by the 109 use of spoofed source addresses. 111 o Being able to assume that all packet source addresses are correct 112 would allow traceback to be accomplishedaccurately and with 113 confidence. This would benefit network diagnosis, management, 114 accounting and applications. 116 As part of the effort in developing a Source Address Validation 117 Architecture (SAVA), we implemented a SAVA prototype and deployed the 118 prototype in 12 ASes in an operational network as part of China Next 119 Gerneration Internet (CNGI) Project. We conducted evaluation 120 experiments. In this document we first describe the prototype 121 solutions and then report experimental results. We hope that this 122 document can provide useful insights to those interested in the 123 subject, and can serve as an initial input to future IETF effort in 124 this area. 126 In recent years there have been a number of research and engineering 127 efforts to design IP source address validation mechanisms, such as 128 [RFC2827][Park01][Li02][Brem05][Snoe01]. Our SAVA prototype 129 implementation was inspired by some of the schemes from the proposed 130 or existing solutions. 132 The prototype implementation and experimental results presented in 133 this report serve only as an input, and by no means pre-empt any 134 solution development that may be carried out by future IETF effort. 135 Indeed, the presented solutions are experimental approaches and have 136 a number of limitations as discussed in sections 5 and 6. 138 2. A Prototype SAVA Implementation 140 2.1. Solution Overview 142 A multiple-fence solution is proposed in this document. That is, 143 there are multiple points in the network at which the validity of a 144 packet's source address can be checked. This is because in the 145 current single-fence model where source address validity is 146 essentially checked only at ingress to the network, deployment has 147 been inadequate to the point that there are always sufficient 148 opportunity to mount attacks based on spoofed source addresses and it 149 seems likely that this condition will continue in the forseeable 150 future. A multiple-fence solution will allow "holes" in deployment 151 to be covered and and validity of the source address to be evaluated 152 with increased confidence across the whole Internet. The assumption 153 here is that when validity checking is not universal, it is still 154 worthwhile to increase the confidence in the validity of source 155 addresses and to reduce the opportunities to mount a source address 156 spoofing attack. 158 Furthermore, the architecture allows for multiple independent and 159 loosely-coupled checking mechanisms. The motivation for this is that 160 in the Internet at large, it is unrealistic to expect any single IP 161 source address validation mechanism to be universally supported. 162 Different operators and vendors may choose to deploy/develop 163 different mechanisms to achieve the same end, and there need to be 164 different mechanisms to solve the problem at different places in the 165 network. Furthermore, implementation bugs or configuration errors 166 could potentially render an implementation ineffective. Therefore 167 our prototype SAVA implementation is a combination of multiple 168 coexisting and cooperating mechanisms. More specifically, we 169 implement source IP address validation at three levels: access 170 network source address validation; intra-AS source address 171 validation; and inter-AS source address validation, as shown in 172 Figure 1. The system details can be found in [WRL2007]. 174 __ ____ __ ____ 175 .-'' `': .-'' `': 176 | | | | 177 | +-+----+ | Inter-AS SAV | +-+----+ | 178 | |Router+--+------------------+---|Router+ + 179 | +--.---+ | | +--.---+ | 180 Intra-AS | | | Intra-AS | | | 181 SAV | +--+---+ | SAV | +--+---+ | 182 | |Router| | | |Router| | 183 '_ +--.---+ _ '_ +--.---+ _ 184 `'---|---''' `'---|---''' 185 _.--|-----. _.--|-----. 186 ,-'' | `--. ,-'' | `--. 187 |'+-----------------+`| |'+-----------------+`| 188 | | Router | | | | Router | | 189 | ++----------------+ | | ++----------------+ | 190 Access | | | | | Access | | | | | 191 Network| | +------++------+ | Network| | +------++------+ | 192 SAV | | |Switch||Router| | SAV | | |Switch||Router| | 193 | | +------++------+ | | | +------++------+ | 194 | | | | | | | | | | 195 |+-+--+ +----+ +----+ | |+-+--+ +----+ +----+ | 196 ||Host| |Host| |Host| | ||Host| |Host| |Host| | 197 `.----+ +----+ +----+,' `.----+ +----+ +----+,' 198 `--. _.-' `--. _.-' 199 `--------'' `--------'' 200 Key: SAV== Source Address Validation 202 Figure 1: Solution Overview 204 It is important to enforce IP source address validity at the access 205 network. That is, when an IP packet is sent from a host, the 206 routers, switches or other devices should check to make sure that the 207 packet carries a valid source IP address. If this access network 208 source address validation is missing, then a host may be able to 209 spoof the source IP address which belongs to another local host. The 210 Internet Best-Current-Practice [RFC2827] and [RFC3704] can be used in 211 access networks where hosts are individually directly attached to one 212 interface of a router, but this is not the normal case in an access 213 network. 215 We use the term "intra-AS source address validation" to mean the IP 216 source address validation at the attachment point of an access 217 network to its provider network, also called the ingress point. IP 218 source address validation at ingress points can enforce the source IP 219 address correctness at the IP prefix level, assuming the access 220 network owns one or more IP address blocks. This practice has been 221 adopted as the Internet Best-Current-Practice [RFC2827] and 223 [RFC3704]. Even in the absence of the access network source address 224 checking, this ingress checking can still prevent the hosts within 225 one access network from spoofing IP addresses belonging to other 226 networks. 228 In theory, everyone would do validation at the access network level 229 and again at the intra-AS level. In reality, some packets will get 230 validated and some will not get validated. As a result, the 231 different levels provide additional layers of defense. 233 Inter-AS IP source address validation refers to mechanisms that 234 enforce packet source address correctness at AS boundaries. The 235 first two steps of source address validation utilize the network 236 physical connectivity of the access network and the ingress points. 237 Because the global Internet has a mesh topology, and because 238 different networks belong to different administrative authorities, IP 239 source address validation at Inter-AS level is more challenging. 240 Nevertheless we believe this third level of protection is necessary 241 to detect packets with spoofed source addresses, when the first two 242 levels of source address validation are missing or ineffective. 244 In the rest of this section we describe the specific mechanisms 245 implemented at each of the three levels in detail. 247 2.2. IP Source Address Validation in the Access Network 249 At the access network level, the solution ensures the host inside the 250 access network cannot use the source address of another host. The 251 host address should be a valid address assigned to the host 252 statically or dynamically. The solution implemented in the 253 experiment provides such a function for Ethernet networks. A layer-3 254 source address validation device (SAVA Device) for the access network 255 (the device can be a function inside the CPE router or a separate 256 device) is deployed at the exit of the access network. Source 257 address validation agents (SAVA Agents) are deployed inside the 258 access network. (In fact these agents could be a function inside the 259 first hop router/switch connected to the hosts.) A set of protocols 260 was designed for communication between the host, SAVA Agent and SAVA 261 Device. Only a packet originating from the host that was assigned 262 that particular source address may pass through the SAVA Agent and 263 SAVA Device. 265 Two possible deployment variants exist. In one variant an agent is 266 mandatory and each host is attached to the agent on a dedicated 267 physical port. In another variant hosts are required to perform 268 network access authentication and generate key material needed to 269 protect each packet. In this second variant the agent is optional. 271 The key function of the first variant is to create a dynamic binding 272 between a switch port and valid source IP address, or a binding 273 between MAC address, source IP address and switch port. In the 274 prototype, this is established by having hosts employ a new address 275 configuration protocol that the switch is capable of tracking. 277 Note: In a production environment the approach in the prototype would 278 not be sufficient due to reasons discussed in Section 5. 280 In this variant, there are three main participants: Source Address 281 Request Client (SARC) on the host, Source Address Validation Proxy 282 (SAVP) on the switch, and Source Address Management Server (SAMS). as 283 shown inFigure 2.The solution follows the basic steps below: 285 1. The SARC on the end host sends an IP address request. The SAVP 286 on the switch relays this request to the SAMS and records the MAC 287 address and incoming port. If the address has already been 288 predetermined by the end host, the end host still needs to put 289 that address in the request message for verification by SAMS. 291 2. After the SAMS receives the IP address request, it then allocates 292 a source address for that SARC based on the address allocation 293 and management policy of the access network, it stores the 294 allocation of the IP address in the SAMS history database for 295 traceback, then sends response message containing the allocated 296 address to the SARC. 298 3. After the SAVP on the access switch receives the response, it 299 binds the IP address and the former stored MAC address of the 300 request message with the switch port on the binding table. Then, 301 it forwards the issued address to SARC on the end host. 303 4. The access switch begins to filter packets sent from the end 304 host. Packets which do not conform to the tuple (IP address, 305 Switch Port) are discarded. 307 ---------------- 308 | SERVER | 309 | ------- | 310 | | SAMS | | 311 | -------- | 312 ----------------- 313 | 314 | 315 ---------------- 316 | SWITCH | 317 | ------- | 318 | | SAVP | | 319 | -------- | 320 ----------------- 321 | 322 | 323 ---------------- 324 | END HOST | 325 | ------- | 326 | | SARC | | 327 | -------- | 328 ----------------- 329 Key: SARC == Source Address Request Client , SAVP == Source Address 330 Validation Proxy, SAMS== Source Address Management Server 332 Figure 2: Binding Based IP Source Address Validation in the Access 333 Network 335 The main idea of the second variant is to employ key material from 336 network access authentication for some additional validation process. 337 A session key is derived for each host connecting to the network, and 338 each packet sent by the host has cryptographic protection that 339 employs this session key. Having established which host the packet 340 comes from, it again becomes possible to track that the addresses 341 allocated to the host and used by the host match. The mechanism 342 details can be found in [XBW07], but the the process follows these 343 basic steps: 345 1. When a host wants to establish connectivity, it first needs to 346 perform network access authentication. 348 2. The network access devices provide the SAVA Agent (often co- 349 located) a session key S. This key is further distributed to the 350 SAVA Device. The SAVA Device binds the session key and the 351 host's IP address. 353 3. When the host sends packet M to somewhere outside the access 354 network, either the host or the SAVA Agent needs to generate a 355 message authentication code for each using key S and packet M. In 356 the prototype, the message authentication code is carried in an 357 experimental IPv6 extension header. 359 4. The SAVA Device uses the session key to authenticate the 360 signature carried in the packet so that it can validate the 361 source address. 363 In our testbed, we implemented and tested both solutions. The 364 switch-based solution has better performance but the switches in the 365 access network would need to be upgraded (usually the number of 366 switches in an access network is large) . The signature based 367 solution could be deployed between host and the exit router, but it 368 has some extra cost in inserting and validating the signature. 370 2.3. IP Source Address Validation at Intra-AS/Ingress Point 372 We adopted the solution of the source address validation of IP 373 packets at ingress points described in [RFC2827] and [RFC3704]; the 374 latter describes source address validation at the ingress points of 375 multi-homed access networks. 377 2.4. IP Source Address Validation in Inter-AS Case (Neighboring AS) 379 Our design for the Inter-AS Source Address Validation aimed at the 380 following characteristics: It should cooperate among different ASes 381 with different administrative authorities and different interests. 382 It should be light-weight enough to support high throughput and not 383 to influence forwarding efficiency. 385 The inter-AS level of SAVA can be classified into two sub-cases: 387 o Two SAVA-compliant ASes exchanging traffic are directly connected; 389 o Two SAVA-compliant ASes are separated by one or more intervening, 390 SAVA-non-compliant providers. 392 --------- 393 | AIMS | 394 ------|- 395 | 396 -------------- -----------|----- 397 | AS-4 |-------- --------| AS-1 | |------- Global 398 | ------ |ASBR,VE|->|ASBR,VE| ------|- |ASBR,VE|--->IPv6 399 | |VRGE| |-------- --------| | VRGE | |------- Network 400 | ------ | | -------- | 401 --------------- ----- ----------------- 402 |ASBR,VE| |ASBR,VE| 403 --------- --------- 404 / | 405 / | 406 / | 407 / | 408 ---------- -------- 409 |ASBR, VE| |ASBR,VE| 410 --------------- ------------- 411 | AS-2 | | AS-3 | 412 | ----- | | ----- | 413 | |VRGE| | | |VRGE| | 414 | ----- | | ------ | 415 --------------- ------------- 417 Key: AIMS == AS-IPv6 prefix Mapping Server, VRGE == Validation Rule 418 Generating Engine, VE == Validating Engine, ASBR = AS Border Router, 419 VR==Validation Rule 421 Figure 3: Inter-ISP (Neighboring AS) Solution 423 Two ASes that exchange traffic have a customer-to-provider, provider- 424 to-customer,peer-to-peer, or sibling-to-sibling relationship. In a 425 customer-to-provider or provider-to-customer relationship, the 426 customer typically belongs to a smaller administrative domain that 427 pays a larger administrative domain for access to the rest of 428 Internet. The provider is an AS that belongs to the larger 429 administrative domain. In a peer-to-peer relationship, the two peers 430 typically belong to administrative domains of comparable size and 431 find it mutually advantageous to exchange traffic between their 432 respective customers. Two ASes have a sibling-to-sibling 433 relationship if they belong to the same administrative domain or to 434 the administrative domains that have a mutual-transit agreement. 436 An AS relation based mechanism is used for neighboring SAVA-compliant 437 ASes. The basic ideas of this AS-relation based mechanism are as 438 follows. It builds a VR table that associates each incoming 439 interface of a router with a set of valid source address blocks, and 440 then uses it to filter spoofed packets. 442 In the solution implemented on the testbed, the solution for the 443 validation of IPv6 prefixes is separated into three functional 444 modules: The Validation Rule Generating Engine (VRGE), the Validation 445 Engine (VE) and the the AS-IPv6 prefix Mapping Server(AIMS). 446 Validation rules (VR) that are generated by the VRGE are expressed as 447 IPv6 address prefixes. 449 The VRGE generates validation rules which are derived according to 450 the table shown in figure 4, and each AS has a VRGE. The VE loads 451 validation rules generated by VRGE to filter packets passed between 452 ASes (in the case of Figure 3, from neighboring ASes into AS-1). In 453 the SAVA testbed, the VE is implemented as a simulated L2 device on a 454 Linux-based machine inserted into the data path just outside each 455 ASBR interface that faces a neighboring AS, but in a real-world 456 implementation, it would probably be implemented as a packet 457 filtering set on the ASBR. The AS-IPv6 prefix mapping server is also 458 implemented on a Linux machine and derives a mapping between IPv6 459 prefix and the AS number of that prefix. 460 ---------------------------------------------------------------------- 461 | \Export| Own | Customer's| Sibling's | Provider's | Peer's | 462 |To \ | Address | Address | Address | Address | Address | 463 |-----\--------------------------------------------------------------| 464 | Provider | Y | Y | Y | | | 465 |--------------------------------------------------------------------| 466 | Customer | Y | Y | Y | Y | Y | 467 |--------------------------------------------------------------------| 468 | Peer | Y | Y | Y | | | 469 |--------------------------------------------------------------------| 470 | Sibling | Y | Y | Y | Y | Y | 471 ---------------------------------------------------------------------- 473 Figure 4: AS-Relation Based Inter-AS Filtering 475 Different ASes exchange and transmit VR information using the AS- 476 Relation Based Export Rules in the VRGE. As per Figure 4, an AS 477 exports the address prefixes of its own, its customers, its 478 providers, its siblings and its peers to its customers and siblings 479 as valid prefixes, while it only exports the address prefixes of its 480 own, its customers and its siblings to its providers and peers as 481 valid prefixes. With the support of AS Number to IPv6 Address 482 Mapping service, only AS numbers of valid address prefixes are 483 transferred between ASes and the AS number is mapped to address 484 prefixes at the VRGE. Only changes of AS relation and changes of IP 485 address prefixes belonging to an AS require the generation of VR 486 updates. 488 The procedure's principle steps are as follows (Seeing from AS-1 in 489 Figure 3): 491 1. When the VRGE has initialized, it reads its neighboring SAVA- 492 compliant AS table and establishes connections to all the VEs in 493 its own AS. 495 2. The VRGE initiates a VR renewal. According to its export table, 496 it sends its own originated VR to VRGEs of neighboring ASes. In 497 this process, VR are expressed as AS numbers. 499 3. When a VRGE receives a new VR from its neighbor, it uses its own 500 export table to decide whether it should accept the VR and, if it 501 accepts a VR, whether or not it should re-export the VR to other 502 neighboring ASes. 504 4. If the VRGE accepts a VR, it uses the AIMS to transform AS- 505 expressed VR into IPv6 prefix-expressed VR. 507 5. The VRGE pushes the VR to all the VEs in its AS. 509 The VEs use these prefix-based VRs to validate the source IP 510 addresses of incoming packets. 512 2.5. IP Source Address Validation in Inter-AS Case (Non-Neighboring AS) 514 In the case where two ASes do not exchange packets directly, it is 515 not possible to deploy a solution like that described in the previous 516 section. However, it is highly desirable for non-neighboring ISPs to 517 be able to form a trust alliance such that packets leaving one AS 518 will be recognized by the other and inherit the validation status 519 they possessed on leaving the first AS. There is more than one way 520 to do this. For the SAVA experiments to date, an authentication tag 521 method has been used. This solution is inspired by the work 522 [Brem05]. The key elements of this light-weight authentication tag 523 based mechanism are as follows: For each pair of SAVA-compliant ASes, 524 there is a pair of unique temporary authentication tags. All SAVA- 525 compliant ASes together form a SAVA AS Alliance. When a packet is 526 leaving its own AS, if the destination IP address belongs to an AS in 527 the SAVA AS Alliance, the edge router of this AS looks up for the 528 authentication tag based on the destination AS number, and tags a 529 authentication tag to the packet. When a packet arrives at the 530 destination AS, if the source address of the packet belongs to an AS 531 in the SAVA AS Alliance, so the edge router of the destination AS 532 searches its table for the authentication tag using the source AS 533 number as the key and the authentication tag carried in the packet is 534 verified and removed. This particular method uses a light-weight 535 authentication tag. For every packet forwarded, the authentication 536 tag can be put in an IPv6 hop-by-hop extension header. It is 537 reasonable to use a 128-bit shared random number as the 538 authentication tag to save the processing overhead of using a 539 cryptographic method to generate the authentication tag. 541 The benefit of this scheme compared to merely turning on local 542 address validation such as RFC 2827 is as follows: when local address 543 validation is employed within a group of networks, it is assured that 544 their networks do not send spoofed packets. However, other networks 545 may still do this. With the above scheme, however, this capability 546 is eliminated. If someone outside the alliance spoofs a packet using 547 a source address from someone within the alliance, the members of the 548 alliance refuse to accept such a packet. 549 +-----+ 550 .-----------------+.REG |-----------------. 551 | +-----+ | 552 | | 553 ,-----+-------- ,------+------- 554 ,' `| `. ,' ` | `. 555 / | \ / | \ 556 / | \ / | \ 557 ; +--'--+ +----+ +----+ +-----+ ; 558 | | ASC +------+ASBR| |ASBR+-----+ ASC | | 559 : +--.--+ +----+` +----+ +--+--+ : 560 \ |__________________________________________| / 561 \ / \ / 562 `. ,' `. ,' 563 '-------------' '-------------' 564 AS-1 AS-2 565 KEY: REG == Registration Server, ASC == AS Control Server, ASBR == AS 566 Border Router. 568 Figure 5: Inter-AS (Non-neighboring AS) Solution 570 There are three major components in the system: the Registration 571 Server (REG), the AS Control Server (ASC), and the AS Border Router 572 (ASBR). 574 The Registration Server is the "center" of the trust alliance (TA). 575 It maintains a member list for the TA. It performs two major 576 functions: 578 o Processes requests from the AS Control Server, to get the member 579 list for the TA. 581 o When the member list is changed, notifies each AS Control Server. 583 Each AS deploying the method has an AS Control Server. The AS 584 Control Server has three major functions: 586 o Communicates with the Registration Server, to get the up-to-date 587 member list of TA. 589 o Communicates with the AS Control Server in other member AS in the 590 TA, to exchange updates of prefix ownership information, and to 591 exchange authentication tags. 593 o Communicates with all AS Border routers of the local AS, to 594 configure the processing component on the AS Border routers. 596 The AS Border Router does the work of adding authentication tag to 597 the packet at the sending AS, and the work of verifying and removing 598 the authentication tag at the destination AS. 600 In the design of this system, in order to decrease the burden on the 601 REG, most of the control traffic happens between ASCs. 603 The authentication tag needs to be changed periodically. Although 604 the overhead of maintaining and exchanging authentication tags 605 between AS pairs is O(N) rather than O(N^2), the traffic and 606 processing overhead do increase as the number of ASes increases. 607 Therefore an automatic authentication tag refresh mechanism is 608 utilized in this solution. In this mechanism, each peers run the 609 same algorithm to automatically generate an authentication tag 610 sequence. Then the authentication tag in packets can be changed 611 automatically with high frequency. To enhance the security, a seed 612 is used for the algorithm to generate an authentication tag sequence 613 robust against guessing. Thus, the peers need only to negotiate and 614 change the seed at very low frequency. This lowers the overhead 615 associated with frequently negotiating and changing the 616 authentication tag while maintaining acceptable security. 618 Since the authentication tag is put in an IPv6 hop-by-hop extension 619 header, the MTU issues should be considered. Currently we have two 620 solutions to this problem. Neither of the solutions is perfect, but 621 they are both feasible. One possible way is to set the MTU at the 622 AER to be 1280, which is the minimum MTU for the IPv6. Thus there 623 should be no ICMP "Packet Too Big" message received from the down- 624 stream gateways. The disadvantage of this solution is that it 625 doesn't make good use of the available MTU. The other possible way 626 is to let AER catch all coming ICMP "Packet Too Big" message", and 627 decrease the value in the MTU field before forwarding it into the AS. 628 The advantage of this solution is that it can make good use of the 629 available MTU. But such processing of ICMP packet at AER may create 630 a DoS attack target. 632 Because the authentication tag is validated at the border router of 633 destination AS, not destination host, the destination options header 634 is not chosen to carry the authentication tag. 636 Authentication tag management is a critical issue. Our work focused 637 on two points: tag negotiation and tag refresh. The tag negotiation 638 happens between the ACS of a pair of ASes in the SAVA AS Alliance. 639 Considering the issue of synchronization and the incentive of 640 enabling SAVA, receiver-driven tag negotiation is suggested. It 641 gives more decision power to receiver AS rather than the sender AS. 642 With a receiver-driven scheme, the receiver AS can decide the 643 policies of tag management. The packets tagged with an old 644 authentication tag should not be allowed indefinitely. Rather, after 645 having negotiated a new tag, the old tag should be set to be invalid 646 after a period of time. The length of this period is a parameter 647 which will control how long the old tag will be valid after the new 648 tag has been assigned. In the experiment, we use five seconds. 650 The trust alliance is intended to be established dynamically (join 651 and quit), but in this testbed we need to confirm offline the initial 652 trust among alliance members. 654 3. SAVA Testbed 656 3.1. CNGI-CERNET2 658 The prototypes of our solutions for SAVA are implemented and tested 659 on CNGI-CERNET2. CNGI-CERNET2 is one of the China Next Generation 660 Internet (CNGI) backbones. CNGI-CERNET2 connects 25 core nodes 661 distributed in 20 cities in China at speeds of 2.5-10 Gb/s. The 662 CNGI-CERNET2 backbones are IPv6-only networks rather than being a 663 mixed IPv4/IPv6 infrastructure. Only Some CPNs are dual-stacked. 664 The CNGI-CERNET2 backbones, CNGI-CERNET2 CPNs, and CNGI-6IX all have 665 globally unique AS numbers. Thus a multi-AS testbed environment is 666 provided. 668 3.2. SAVA Testbed on CNGI-CERNET2 Infrastructure 670 It is intended that eventually the SAVA testbed will be implemented 671 directly on the CNGI-CERNET2 backbone, but in the early stages the 672 testbed has been implemented across 12 universities connected to 673 CNGI-CERNET2. This is because first, some of the algorithms need to 674 be implemented in the testbed routers themselves and to date they 675 have not been implemented on any of the commercial routers forming 676 the CNGI-CERNET2 backbone. Second, since CNGI-CERNET2 is an 677 operational backbone, any new protocols and networking techniques 678 need to be tested in a non-disruptive way. 680 __ 681 ,' \ _,...._ 682 ,' \____---------------+ ,'Beijing`. 683 / \ | Inter-AS SAV |-----| Univ | 684 +---------------+ | | +---------------+ `-._____,' 685 | Inter-AS SAV +-----| | 686 +------.--------+ | CNGI- | _,...._ 687 | | CERNET2 |__---------------+ ,Northeast`. 688 | | | |Inter-AS SAV |-----| Univ | 689 Tsinghua|University | Backbone| +---------------+ `-._____,' 690 ,,-|-._ | | 691 ,' | `. | | 692 ,'+---------+\ | | 693 | |Intra-AS | | | | ... 694 | | SAV | | | | 695 | +---------+ | | | 696 | | | | | _,...._ 697 | +---------+ | | |__---------------+ ,Chongqing`. 698 | | Access | | | | |Inter-AS SAV |-----|Univ | 699 | | Network | | | | +---------------+ `-._____,' 700 | | SAV | | | | 701 \ +---------+.' \ .' 702 \ ,' \ | 703 `. ,' \ / 704 ``---' -_,' 705 KEY: SAV=Source Address Validation 707 Figure 6: CNGI-CERNET2 SAVA Testbed 709 In any case, the testbed is fully capable of functional testing of 710 solutions for all parts of the SAVA architecture. This includes 711 testing procedures for ensuring the validity of IPv6 source addresses 712 in the access network and in packets sent from the access network to 713 an IPv6 service provider, packets sent within one service provider's 714 network, packets sent between neighboring service providers and 715 packets sent between service providers separated by an intervening 716 transit network. 718 The testbed is distributed across 12 universities connected to CNGI- 719 CERNET2. 721 Each of the university installations is connected to the CNGI-CERNET2 722 backbone through a set of inter-AS Source Address Validation 723 prototype equipment and traffic monitoring equipment for test result 724 display. 726 Each university deployed one AS. Six universities deployed all parts 727 of the solution and are hence fully-featured, with inter-AS, intra-AS 728 and access network level validation all able to be tested. In 729 addition, a suite of applications that could be subject to spoofing 730 attacks or which can be subverted to carry out spoofing attacks were 731 installed on a variety of servers. Two solutions for the access 732 network were deployed. 734 4. Test Experience and Results 736 The solutions outlined in section 2 were implemented on the testbed 737 described in section 3. Successful testing of all solutions was been 738 carried out, as detailed in the following sections. 740 4.1. Test Scenarios 742 For each of the test scenarios, we tested many cases. Taking 743 Inter-AS (non-neighboring AS) SAVA solution test as an example, we 744 classified the test cases into three classes: normal class, dynamic 745 class and anti-spoofing class. 747 1. For normal class, there are three cases: Adding authentication 748 tag Test, Removing authentication tag Test and Forwarding packets 749 with valid source address. 751 2. For dynamic class, there are four cases: Updating the 752 authentication tag between ASes, The protection for a newly 753 joined member AS, Adding address space and Deleting address 754 space. 756 3. For anti-spoofing class, there is one case: Filtering of packets 757 with forged IP address. 759 As is shown in Fig.6, we have "multiple-fence" design for our SAVA 760 testbed. If source address validation is deployed in the access 761 network, we can get a host granularity validation. If source address 762 validation is deployed at intra-AS level, we can guarantee that the 763 packets sent from this point have a correct IP prefix. If source 764 address validation is deployed at inter-AS level, we can guarantee 765 that the packets sent from this point are from the correct AS. 767 4.2. Test Results 769 1. The test results are consistent with the expected ones. For an 770 AS which has fully-featured SAVA deployment with inter-AS, 771 intra-AS and access network level validation, packets that do not 772 hold an authenticated source address will not be forwarded in the 773 network. As a result, it is not possible to launch network 774 attacks with spoofed source addresses. Moreover, the traffic in 775 the network can be traced back accurately. 777 2. For the Inter-AS (non-neighboring AS) SAVA solution, during the 778 period of authentication tag update, the old and the new 779 authentication tag are both valid for source address validation, 780 thus there is no packet loss. 782 3. For the Inter-AS (non-neighboring AS) SAVA solution, the 783 validation function is implemented in software on a device 784 running Linux, which simulates the source address validation 785 functions of a router interface. It is a layer-two device 786 because it has to be transparent to router interface, During the 787 test, If the devices were connected directly, it could achieve a 788 normal line rate forwarding. If the devices were connected with 789 routers from another vendor, it could only achieve a very limited 790 line speed. The reason is that the authentication tags are added 791 on the IPv6 hop-by-hop option header and many current routers can 792 handle the hop-by-hop options only at a limited rate. 794 5. Limitations and Issues 796 There are several issues both within this overall problem area and 797 with the particular approach taken in the experiment. 799 5.1. General Issues 801 There is a long standing debate about whether the lack of universal 802 deployment of source address validation is a technical issue that 803 needs a technical solution, or if mere further deployment of existing 804 tools (such as RFC 2827) would be a more cost effective way to 805 improve the situation. Further deployment efforts of this tool have 806 proved to be slow, however. Some of solutions prototyped in this 807 experiment allow a group of network operators to have additional 808 protection for their networks while waiting for universal deployment 809 of simpler tools in the rest of the Internet. This allows them to 810 prevent spoofing attacks that the simple tools alone would not be 811 able to prevent, even if already deployed within the group. 813 Similarly, since a large fraction of current denial-of-service 814 attacks can be launcched employing legitimate IP addresses belonging 815 to botnet clients, even universal deployment of better source address 816 validation techniques would be unable to prevent these attacks. 817 However, tracing these attacks would be easier given that there would 818 be more reliance on the validity of source address. 820 There is also a question about the optimal placement of the source 821 address validation checks. The simplest model is placing the checks 822 on the border of a network. Such RFC 2827-style checks are more 823 widely deployed than full checks ensuring that all addresses within 824 the network are correct. It can be argued that it is sufficient to 825 provide such a coarse granularity checks, because this makes it at 826 least possible to find the responsible network administrators. 827 However, depending on the type of a network in question, those 828 administrators may or may not find it easy to track the specific 829 offending machines or users. It is obviously required that the 830 administrators have a way to trace offending equipment or users -- 831 even if the network does not block spoofed packets in real-time. 833 New technology for address validation would also face a number of 834 deployment barriers. For instance, all current technology can be 835 locally and independently applied. A system that requires global 836 operation (such as the Inter-AS validation mechanism) would require 837 significant coordination, deployment synchronization, configuration, 838 key setup, and other issues, given the number of ASes. 840 Similarly, deploying host-based access network address validation 841 mechanisms requires host changes, and can generally be done only when 842 the network owners are in control of all hosts. Even then, 843 availability of the host changes for all types of products and 844 platforms would likely prevent universal deployment even within a 845 single network. 847 There may be also be significant costs involved in some of these 848 solutions. For instance, in an environment where access network 849 authentication is normally not required, employing an authentication- 850 based access network address validation would require deployment of 851 equipment capable of this authentication as well as credentials 852 distribution for all devices. Such undertaking is typically only 853 initiated after careful evaluation of the costs and benefits 854 involved. 856 Finally, all the presented solutions have issues in situations that 857 go beyond a simple model of a host connecting to a network via the 858 same single interface at all times. Multihoming, failover and some 859 forms of mobility or wireless solutions may collide with the 860 requirements of source address validation. In general, dynamic 861 changes to the attachment of hosts and topology of the routing 862 infrastructure is something that would have to be handled in 863 production environment. 865 5.2. Security Issues 867 The security vs. scalability of the authentication tags in the 868 Inter-AS (non-neighboring AS) SAVA solution presents a difficult 869 tradeoff. Some analysis about the difficulty of guessing the 870 authentication tag between two AS members was discussed in [Brem05]. 871 It is relatively difficult, even with using a random number as a 872 "authentication tag". The difficulty of guessing can be increased by 873 increasing the length of the authentication tag. 875 In any case, the random number approach is definitely vulnerable to 876 attackers who are on the path between the two ASes. 878 On the other hand, using an actual cryptographic hash in the packets 879 will cause a significant increase in the amount of effort needed to 880 forward a packet. In general, addition of the option and the 881 calculation of the authentication tag consumes valuable resources on 882 the forwarding path. This resource usage comes on top of everything 883 else that modern routers need to do at ever increasing line speeds. 884 It is far from clear that costs are worth the benefits. 886 5.3. Protocol Details 888 In current CNGI-CERNET2 SAVA testbed, a 128-bit authentication tag is 889 placed in IPv6 a new hop-by-hop option header. The size of the 890 packets increases with the authentication tags. This by itself is 891 expected to be acceptable, if the network administrator feels that 892 the additional protection is needed. The size increases may result 893 in MTU issue and we found a way to resolve it in the testbed. Given 894 the choice to use an IPv6 hop-by-hop option has to be looked at by 895 all intervening routers. While in theory this should pose no 896 concern, the test results show that many current routers handle hop- 897 by-hop options with a much reduced throughput compared to normal 898 traffic. 900 The Inter-AS (neighboring AS) SAVA solution is based on AS relation, 901 thus it may not synchronize with the dynamics of route changes very 902 quickly and cause false positives. Currently CNGI-CERNET2 is a 903 relatively stable network and this method works well in the testbed. 904 We will further study the impact of false positives in an unstable 905 network. 907 The access network address validation solution is merely one option 908 among many. Solutions appear to depend highly on the chosen link 909 technology and network architecture. For instance, source address 910 validation on point-to-point links is easy and has generally been 911 supported by implementations for years. Validation in a shared 912 networks has been more problematic, but is increasing in importance 913 given the use Ethernet technology across administrative boundaries 914 (such as in DSL). In any case, the prototyped solution has a number 915 of limitations, including the decision to use a new address 916 configuration protocol. In a production environment a solution which 917 is suitable for all IPv6 address assignment mechanisms would be 918 needed.. 920 6. Conclusion 922 Several conclusions can be drawn from the experiment. 924 First, the experiment is a proof that a prototype can be built that 925 is deployable on loosely-coupled domains of test networks in a 926 limited scale and "multiple-fence" design for source address 927 validation. The solution allows different validation granularities, 928 and also allows different providers to use different solutions. The 929 coupling of components at different levels of granularity can be 930 loose enough to allow component substitution. 932 Incremental deployment is another design principle that was used in 933 the experiment. The tests have demonstrated that benefit is derived 934 even when deployment is incomplete, which gives providers an 935 incentive to be early adopters. 937 The experiment also provided a proof of concept for the switch-based 938 local subnet validation, network authentication based validation, 939 filter-based Inter-AS validation, and authentication tag-based 940 Inter-AS validation mechanisms. The client host and network 941 equipment need to be modified and some new servers should be 942 deployed. 944 Nevertheless, as discussed in the previous section, there are a 945 number of limitations, issues, and question marks in the prototype 946 designs and the overall source address validation space. 948 It is our hope that some of the experiences will help vendors and the 949 Internet standards community in these efforts. Future work in this 950 space should attempt to answer some of the issues raised in Section 951 5. Some of the key issues going forward include: 953 o Scalability questions and per-packet operations. 955 o Protocol design issues, such as integration to existing address 956 allocation mechanisms, use of hop-by-hop headers, etc. 958 o Cost vs. benefit questions. These may be ultimately answered only 959 by actually employing some of these technologies in production 960 networks. 962 o Trust establishment issue and study of false positives. 964 o Deployability considerations, e.g. modifiability of switches, 965 hosts, etc. 967 7. IANA Considerations 969 This document makes no request of IANA. 971 Note to RFC Editor: this section may be removed on publication as an 972 RFC. 974 8. Security Considerations 976 The purpose of the draft is to report experimental results. Some 977 security considerations of the solution mechanisms of testbed are 978 mentioned in the document, but not the main problem to be described 979 in this document. 981 9. Acknowledgements 983 This experiment was conducted among 12 universities, namely Tsinghua 984 University, Beijing University, Beijing University of Post and 985 Telecommunications, Shanghai Jiaotong University, Huazhong University 986 of Science and Technology in Wuhan, Southeast University in Nanjing, 987 and South China University of Technology in Guangzhou, Northeast 988 University in Shenyang, Xi'an Jiaotong University, Shandong 989 University in Jinan, University of Electronic Science and Technology 990 of China in Chengdu and Chongqing University. The authors would like 991 to thank everyone involved in this effort in these universities. 993 The authors would like to thank Jari Arkko, Lixia Zhang and Pekka 994 Savola for their detailed review comments on this draft, and thank 995 Paul Ferguson and Ron Bonica for their valuable advice on the 996 solution development and the testbed implementation. 998 10. References 1000 10.1. Normative References 1002 [RFC2827] Paul, F. and D. Senie, "Network Ingress Filtering: 1003 Defeating Denial of Service Attacks which employ IP Source 1004 Address Spoofing", BCP 38, RFC 2827, May 2000. 1006 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1007 Networks", BCP 84, RFC 3704, 2004. 1009 10.2. Informative References 1011 [Brem05] Bremler-Barr, A. and H. Levy, "Spoofing Prevention 1012 Method", INFOCOM 2005. 1014 [Li02] Li,, J., Mirkovic, J., Wang, M., Reiher, P., and L. 1015 Zhang, "SAVE: Source Address Validity Enforcement 1016 Protocol", INFOCOM 2002. 1018 [Park01] Park, K. and H. Lee, "On the effectiveness of route-based 1019 packet filtering for distributed DoS attack prevention in 1020 power-law internets", SIGCOMM 2001. 1022 [Snoe01] Snoeren, A., Partridge, C., Sanchez, L., and C. 1023 Jones......, "A Hash-based IP traceback", SIGCOMM 2001. 1025 [WRL2007] Wu, J., Ren, G., and X. Li, "Source Address Validation: 1026 Architecture and Protocol Design", ICNP 2007. 1028 http://www.icnp2007.edu.cn/files/ICNP_papers/ 1029 28_wuj-sava.pdf 1031 [Wu07] Wu, J., Ren, G., and X. Li, "Source Address Validation: 1032 Architecture and Protocol Design", ICNP 2007. 1034 [XBW07] Xie, L., Bi, J., and J. Wu, "An Authentication based 1035 Source Address Spoofing Prevention Method Deployed in IPv6 1036 Edge Network", ICCS 2007. 1038 Authors' Addresses 1040 Jianping Wu 1041 Tsinghua University 1042 Computer Science, Tsinghua University 1043 Beijing 100084 1044 China 1046 Email: jianping@cernet.edu.cn 1048 Jun Bi 1049 Tsinghua University 1050 Network Research Center, Tsinghua University 1051 Beijing 100084 1052 China 1054 Email: junbi@cernet.edu.cn 1056 Xing Li 1057 Tsinghua University 1058 Electronic Engineering, Tsinghua University 1059 Beijing 100084 1060 China 1062 Email: xing@cernet.edu.cn 1064 Gang Ren 1065 Tsinghua University 1066 Computer Science, Tsinghua University 1067 Beijing 100084 1068 China 1070 Email: rg03@mails.tsinghua.edu.cn 1072 Ke Xu 1073 Tsinghua University 1074 Computer Science, Tsinghua University 1075 Beijing 100084 1076 China 1078 Email: xuke@csnet1.cs.tsinghua.edu.cn 1079 Mark I. Williams 1080 Juniper Networks 1081 Suite 1508, W3 Tower, Oriental Plaza, 1 East Chang'An Ave 1082 Dong Cheng District, Beijing 100738 1083 China 1085 Email: miw@juniper.net 1087 Full Copyright Statement 1089 Copyright (C) The IETF Trust (2008). 1091 This document is subject to the rights, licenses and restrictions 1092 contained in BCP 78, and except as set forth therein, the authors 1093 retain all their rights. 1095 This document and the information contained herein are provided on an 1096 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1097 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1098 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1099 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1100 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1101 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1103 Intellectual Property 1105 The IETF takes no position regarding the validity or scope of any 1106 Intellectual Property Rights or other rights that might be claimed to 1107 pertain to the implementation or use of the technology described in 1108 this document or the extent to which any license under such rights 1109 might or might not be available; nor does it represent that it has 1110 made any independent effort to identify any such rights. Information 1111 on the procedures with respect to rights in RFC documents can be 1112 found in BCP 78 and BCP 79. 1114 Copies of IPR disclosures made to the IETF Secretariat and any 1115 assurances of licenses to be made available, or the result of an 1116 attempt made to obtain a general license or permission for the use of 1117 such proprietary rights by implementers or users of this 1118 specification can be obtained from the IETF on-line IPR repository at 1119 http://www.ietf.org/ipr. 1121 The IETF invites any interested party to bring to its attention any 1122 copyrights, patents or patent applications, or other proprietary 1123 rights that may cover technology that may be required to implement 1124 this standard. Please address the information to the IETF at 1125 ietf-ipr@ietf.org.