idnits 2.17.1 draft-shi-savi-access-06.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 a Security Considerations section. ** 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.) ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 10, 2014) is 3452 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- == Missing Reference: 'I-D.ietf-savi-mix' is mentioned on line 123, but not defined == Missing Reference: 'RFC2119' is mentioned on line 136, but not defined == Unused Reference: 'RFC 2119' is defined on line 513, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-savi-dhcp-10 == Outdated reference: A later version (-14) exists of draft-ietf-savi-fcfs-09 == Outdated reference: A later version (-11) exists of draft-ietf-savi-send-06 == Outdated reference: A later version (-06) exists of draft-ietf-savi-framework-05 Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SAVI F.Shi 2 Internet Draft China Telecom 3 Intended status: Standard Tracks K.Xu, L.Zhu, G.Hu 4 Expires: May 2015 Tsinghua Univ 5 Y.Bo 6 Huawei Technology 7 November 10, 2014 9 SAVI Requirements and Solutions for ISP IPv6 Access Network 10 draft-shi-savi-access-06.txt 12 Abstract 14 Internet is always confronted with many security threats based on IP 15 address spoofing which can enable impersonation and malicious traffic 16 redirection. Unfortunately, the Internet architecture fails to 17 provide the defense mechanism. Source Address Validation Improvement 18 (SAVI) was developed to prevent IP source address spoofing. 19 Especially, the mechanism is essential for ISPs. However, due to the 20 diversity of address assignment methods, SAVI solution is also 21 different accordingly. This document describes five scenarios of 22 ISPs'IPv6 access network, and moreover, states its SAVI requirements 23 and tentative solutions accordingly. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 10, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents carefully, 51 as they describe your rights and restrictions with respect to this 52 document. Code Components extracted from this document must include 53 Simplified BSD License text as described in Section 4.e of the Trust 54 Legal Provisions and are provided without warranty as described in 55 the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 10 59 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction ................................................ 3 72 2. Conventions used in this document ........................... 4 73 3. Terminology ................................................. 4 74 4. Scenarios for ISPs'IPv6 Access Network ...................... 4 75 4.1. Scenario 1: HRG acts as DHCPv6 proxy ................... 5 76 4.2. Scenario 2: STB gets IP address via DHCPv6 ............. 7 77 4.3. Scenario 3: PC gets IP address via PPPoE & RA .......... 8 78 4.4. Scenario 4: Laptop accesses Internet via WLAN .......... 9 79 4.5. Scenario 5: Laptop accesses Internet via C+W .......... 10 80 5. Conclusions ................................................ 12 81 6. References ................................................. 13 82 6.1. Normative References .................................. 13 83 7. Acknowledgments ............................................ 14 85 1. Introduction 87 Spoofing of IP source addresses can jeopardize people's privacy, 88 enable malicious traffic redirection which causes the network 89 topology and traffic information to be leaked out. Further, it will 90 be difficult to trace the source host which has forged the packet. 91 The Source Address Validation Improvement (SAVI) method was designed 92 to prevent hosts attached to the same link from spoofing each other's 93 IP address. It is developed to complement ingress filtering with 94 finer-grained, standardized IP source address validation. It is also 95 can be deployed easily in networks due to its modularization and 96 extensibility. 98 ISPs that provide Internet access services, information services and 99 value-added services to the customers always have to be confronted 100 with many threats enabled by IP source address spoofing, while the 101 Internet architecture fails to prevent IP source address spoofing 102 [draft-ietf-savi-threat-scope]. So they have an imperative demand to 103 apply the mechanism in order to defend the attack and ensure the 104 security of its network and customers' privacy. 106 Internet Service Provider has multiple access scenarios not limited 107 to Ethernet, and usually is deployed with DHCP. Other scenarios such 108 as ADSL with PPP and Ethernet with PPP are also popular in the real 109 world. Unfortunately, SAVI Switch only works in the scenarios of wire 110 or wireless Ethernet and does not support all address assignment 111 methods that can be used in access network. There are four address 112 assigned methods identified in one of the SAVI documents: 114 1. Stateless Address Auto Configuration (SLACC) [I-D.ietf-savi-fcfs] 116 2. Dynamic Host Control Protocol address assignment (DHCP) 117 [I-D.ietf-savi-dhcp] 119 3. Secure Neighbor Discovery (SeND) address assignment 120 [I-D.ietf-savi-send] 122 4. Mix Address assignment methods 123 [I-D.ietf-savi-mix] 125 Thus, According to different access network scenarios, SAVI should 126 adjust its deployment and make improvement to adapt to the real 127 situation. This note analyzes five scenarios of ISPs' IPv6 access 128 network, and on this basis, gives tentative SAVI solutions 129 accordingly. 131 2. Conventions used in this document 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC-2119 [RFC2119]. 137 In this document, these words will appear with that interpretation 138 only when in ALL CAPS. Lower case uses of these words are not to be 139 interpreted as carrying RFC-2119 significance. 141 3. Terminology 143 The following acronyms and terms are used throughout this document. 145 HRG: Home Residential Gateway, an intelligent gateway between network 146 devices and external network in a family. 148 BRAS: Broadband Remote Access Server, a network switch that funnels 149 traffic from DSL and/or cable modem aggregation devices to various 150 carriers' networks based on the type of an application or that of 151 a service required. 153 STB: Set Top Box, a device which can provide value-added services 154 used to enhance or extend the function of TV. 156 AAA: Authentication, Authorization, Accounting. AAA server can 157 provide verification and authority service. 159 C+W: CDMA (CDMA2000) + WLAN, an integrated wireless broadband network 160 business of China telecom. 162 WAG: Wireless Access Gateway. 164 PDSN: Packet Data Serving Node, responsible for the establishment and 165 terminating point-to-point protocol (PPP) connection and assign 166 dynamic address for nodes. 168 4. Scenarios for ISPs'IPv6 Access Network 170 There are various access methods for ISPs'IPv6 access network. To 171 facilitate the deployment of the SAVI method in networks of various 172 kinds, the SAVI method is designed to support different IP address 173 assignment methods [I-D.ietf-savi-framework]. However, there are 174 still some mixed address assignment methods which cannot be supported. 175 It is important to note that the deployment of SAVI device has been 176 impacted greatly by access network scenarios and its address 177 assignment methods. In order to meet different IP Source Address 178 Validation requirements, SAVI solutions may need to be improved to 179 adapt to the real situation. 181 From the perspective of SAVI deployment, there are five typical 182 scenarios of ISPs'IPv6 access network: 184 1. Home Residential gateway (HRG) acts as DHCPv6 proxy. 186 2. Set Top-box (STB) gets an IP address via DHCPv6. 188 3. Host gets IP address via PPPoE & RA. 190 4. Laptop accesses Internet via WLAN. 192 5. Laptop accesses Internet via C+W. 194 We will discuss the SAVI solution for each scenario in detail in the 195 next section. 197 4.1. Scenario 1: Home Residential gateway (HRG) acts as DHCPv6 proxy 199 +--------+ 200 | BRAS | 201 +-------,+ 202 (PPPoE/ND/RA)|| (DHCPv6-PD) 203 || 204 +---||---+ 205 | HRG | 206 +---/----/+ 207 (DHCPv6)| |(DHCPv6) 208 +----\-+ +\-----+ 209 | PC | | STB | 210 +------+ +------+ 212 Figure 1: Scenario 1 214 Figure 1 shows the main elements in scenario 1. PC and STB connect to 215 the Internet via HRG. Its address assignment mechanism can be 216 described as follows: First, HRG gets a link-local IPv6-IPv6 address 217 from BRAS via PPPoE and ND/RA. Then, HRG gets an IPv6 address from 218 BRAS via DHCPv6-PD. At last, PC and STB get IPv6 addresses from HRG 219 via DHCPv6. Of course, PC and STB can also get IPv6 addresses via 220 ND/RA, but the DHCPv6 is much more popular. 222 According to the SAVI mechanism, in order to achieve Source Address 223 Validation, the SAVI device must snoop the whole procedure of Address 224 assignment. In addition, the preferred location of SAVI instances is 225 close to hosts, such as in access switches that directly attach to 226 the hosts where host IP addresses are being validated [I-D.ietf-savi- 227 framework]. So we can deploy the SAVI device in places close to the 228 HRG, such as the first hop access device. It can be illustrated in 229 figure 2. 231 +--------+ 232 | BRAS | 233 +-------,+ 234 (PPPoE/ND/RA)|| (DHCPv6-PD) 235 || 236 . . . . . .|| . . . . . . . 237 . || Protection. 238 . +-------+ Perimeter. 239 . | SAVI | . 240 . | Device| . 241 . +-------+ . 242 . || . 243 . . . . . .|| . . . . . . . 244 +--||---+ 245 | HRG | 246 +-/----/+ 247 (DHCPv6) | |(DHCPv6) 248 +----\--+ +\-----+ 249 | PC | | STB | 250 | | | | 251 +-------+ +------+ 253 Figure 2: SAVI solution for Scenario 1 255 Figure 2 shows the deployment of SAVI device. It also allows multiple 256 SAVI devices and non-SAVI devices co-existing on a link. In addition, 257 for this solution, the SAVI mechanism needs to improve to snoop the 258 procedure of DHCPv6-PD, so as to bind the relationship . 261 4.2. Scenario 2: STB gets an IP address via DHCPv6 263 The difference between scenario 1 and scenario 2 is the absence of HG 264 which acts as DHCPv6 proxy. In scenario 2, STB, having its internal 265 account and password gets IPv6 prefix by DHCPv6. The general scene 266 workflow includes the following steps: STB sends requests to all 267 routers on a local link by using a link-local address based on its 268 MAC address. The BRAS gives a message to STB to adopt DHCPv6 address 269 assignment method as a response. STB initiates the DHCPv6 procedure 270 and BRAS acts as a DHCP Relay to add some authorities' messages. An 271 AAA server decides whether assign address parameters depend on the 272 result of authentication. At last, BRAS receives IPv6 parameters from 273 AAA server, and then, informs STB via DHCPv6 protocol. It can be 274 illustrated in figure 3. 276 +--------+ +-----------+ 277 | AAA | |DHCP server| 278 +--------+ +-----------+ 279 \/ 280 || 281 || 282 +---||---+ 283 | BRAS | 284 +--------+ 285 | 286 (DHCPv6) 287 | 288 +-------+ 289 | STB | 290 +-------+ 292 Figure 3: Scenario2 294 Figure 3 shows the main elements in scenario 2. Due to the pure 295 DHCPv6 address assignment method in this scenario, we can deploy SAVI 296 device in places close to STB directly and SAVI mechanism need not 297 make any improvement. It just needs to bind relationship which is supported in the existing 299 SAVI function. The solution can be illustrated in figure 4. 301 +--------+ +-----------+ 302 | AAA | |DHCP server| 303 +--------+ +-----------+ 304 \ / 305 +---||---+ 306 | BRAS | 307 +--------+ 308 | 309 (DHCPv6) 310 | 311 . . . . . . . . . . . 312 . +---------------+ . 313 . | SAVI device | . 314 . +---------------+ . 315 . . . . . . . . . . . 316 | 317 +-------+ 318 | STB | 319 +-------+ 321 Figure 4: SAVI solution for Scenario 2 323 4.3. Scenario 3: PC gets an IP address via PPPoE & RA 325 In this scenario, first of all, PC gets a link-local address from 326 BRAS via PPPoE. BRAS broadcasts IPv6 prefix via RA. Finally, PC 327 configures its address automatically and gets some additional 328 messages from BRAS. 330 +--------+ 331 | AAA | 332 +--------+ 333 \ 334 | 335 +---|---+ 336 | BRAS | 337 +-------+ 338 |(ND) 339 +-------+ 340 | PC | 341 +-------+ 343 Figure 5: Scenario3 345 Figure 5 shows the main elements in scenario 3. As the function of ND 346 snooping has already been designed, we only take PPPoE snooping into 347 account. Thus, the solution to this scenario which is illustrated in 348 figure 6 is to deploy the SAVI device directly and binding 349 relationship . In this scenario, 350 SAVI needs to improve in order to realize PPPoE snooping. 352 +--------+ 353 | AAA | 354 +--------+ 355 \ 356 +--- |---+ 357 | BRAS | 358 +--------+ 359 (ND)| 360 . . . . . . . . . . . 361 . +---------------+ . 362 . | SAVI device | . 363 . +---------------+ . 364 . . . . . . . . . . . 365 | 366 +-------+ 367 | PC | 368 +-------+ 370 Figure 6: SAVI solution for Scenario 3 372 4.4. Scenario 4: Laptop accesses Internet via public WLAN 374 The interaction in this scenario is relatively simple. The laptop 375 gets an IPv6 address via DHCPv6. Then, users are enforced to be 376 certified by submitting a password on a portal page. 378 +--------+ +-----------+ 379 | AAA | |DHCP server| 380 +--------+ +-----------+ 381 \/ 382 +--||---+ 383 | BRAS | 384 +-------+ 385 |(DHCPv6) 386 +-------+ 387 |LAPTOP | 388 +-------+ 390 Figure 7: Scenario 4 392 Figure 7 shows the main elements in scenario 4. We can deploy the 393 SAVI device directly and bind relationship . The solution can be illustrated in figure 8. 396 +--------+ +-----------+ 397 | AAA | |DHCP server| 398 +--------+ +-----------+ 399 \ / 400 || 401 +---||---+ 402 | BRAS | 403 +--------+ 404 |(DHCPv6) 405 | 406 . . . . . . . . . . . 407 . +---------------+ . 408 . | SAVI device | . 409 . +---------------+ . 410 . . . . . . . . . . . 411 | 412 +-------+ 413 |LAPTOP | 414 +-------+ 416 Figure 8: SAVI solution for Scenario 4 418 4.5. Scenario 5: Laptop accesses Internet via C+W 420 This scenario describes that the laptop accesses the Internet via 421 CDMA and WLAN. The general scene workflow includes the following 422 steps: The laptop gets a temporary IPv6 address from BARS via DHCPv6, 423 and then, obtains the WAG address from a DNS server. The laptop 424 establishes a UDP tunnel to WAG by sending register request. If the 425 tunnel is established successfully, the laptop can get IPv6 prefix 426 from PDSN via PPP and RA, whereas PDSN acts as the PPP terminal. At 427 last, the laptop gets some additional information such as the DNS 428 address. When the above steps are all accomplished, the laptop 429 acquires the ability to access the Internet. 431 +--------+ +-----------+ 432 | AAA |--| PDSN | 433 +--------+ +------|----+ 434 +--------+ +------|----+ 435 |AN-AAA |--| WAG | 436 +--------+ +-----------+ 437 // 438 // UDP tunnel 439 || 440 || 441 +---||---+ 442 | BRAS | 443 +--------+ 444 | 445 |(DHCPv6) 446 | 447 +-------+ 448 | LAPTOP| 449 +-------+ 451 Figure 9: Scenario 5 453 Figure 9 shows the main elements in scenario 5. in this scenario, we 454 also can deploy the SAVI device in places close to the LAPTOP. SAVI 455 needs to improve to support the PPPoE protocol snooping. It also 456 binds relationship . The 457 solution is described in figure 10. 459 +--------+ +-----------+ 460 | AAA |--| PDSN | 461 +--------+ +------|----+ 462 +--------+ +------|----+ 463 |AN-AAA |--| WAG | 464 +--------+ +-----------+ 465 // 466 // UDP tunnel 467 || 468 || 469 +--||---+ 470 | BRAS | 471 +-------+ 472 | 473 (DHCPv6) 474 | 475 +--------+ 476 | SAVI | 477 | device| 478 | | 479 +--------+ 480 | 481 | 482 +-------+ 483 |LAPTOP | 484 +-------+ 486 Figure 10: SAVI solution for Scenario 5 488 5. Conclusions 490 For ISPs, SAVI can defend against many security attacks effectively 491 which are based on IP address spoofing. There are various scenarios 492 of ISPs'IPv6 Access Network. As each scenario uses a different 493 address assignment method and protocol, there are a variety of 494 requirements to validate the source address for ISPs' IPv6 access 495 network. Though SAVI cannot support all protocols and methods right 496 now, due to expansibility of SAVI, the mechanism can satisfy various 497 demands with a small improvement. This document presents five typical 498 scenarios of ISPs'IPv6 access network, and proposes tentative SAVI 499 solutions. 501 Moreover, for functional verification, we conducted an experiment on 502 China Telecom's access network using the network devices of 503 HuaWei(officially huawei technologies Co Ltd.) in Hunan province. The 504 experimental results show that source addresses can be validated 505 effectively as we expected in most access scenarios. Next, we will 506 deploy more SAVI devices on a large-scale network in order to form a 507 complete architecture. 509 6. References 511 6.1. Normative References 513 [RFC 2119] Bradner, S., "Key words for use in RFCs to 514 Indicate Requirement Levels", BCP 14, RFC 515 2119, March 1997. 517 [draft-ietf-savi-threat-scope] 519 McPherson, D., Baker, F., and J. Halpern, 520 "SAVI Threat Scope", draft-ietf-savi- 521 threat-scope-05, April 2011. 523 [I-D.ietf-savi-dhcp] Wu, J., Yao, G., Bi, J., and F. Baker, 524 "SAVI Solution for DHCP", draft-ietf-savi- 525 dhcp-10 (work in progress), July 2011. 527 [I-D.ietf-savi-fcfs] Nordmark, E., Bagnulo, M., and E. Levy- 528 Abegnoli, "FCFSSAVI: First-Come First-Serve 529 Source-Address Validation for Locally 530 Assigned IPv6 Addresses", draft-ietf-savi- 531 fcfs-09(work in progress), April 2011. 533 [I-D.ietf-savi-send] Bagnulo, M. and A. Garcia-Martinez, "SEND- 534 based Source-Address Validation 535 Implementation", draft-ietf-savi-send-06 536 (work in progress), October 2011. 538 [I-D.ietf-savi-framework] Wu, J., Bi, J., Bagnulo, M., Baker, F., and 539 C. Vogt, "Source Address Validation 540 Improvement Framework",draft-ietf-savi- 541 framework-05 (work in progress), July 2011. 543 7. Acknowledgments 545 This document was prepared using 2-Word-v2.0.template.dot. 547 Authors' Addresses 549 Fan Shi 550 China Telecom 551 Beijing Research Institute, China Telecom 552 Beijing, 100035 553 China 554 Email: shifan@ctbri.com.cn 556 Ke Xu 557 Tsinghua University 558 Department of Computer Science, Tsinghua University 559 Beijing, 100084 560 China 561 Email: xuke@mail.tsinghua.edu.cn 563 Liang Zhu 564 Tsinghua University 565 Department of Computer Science, Tsinghua University 566 Beijing, 100084 567 China 568 Email: tshbruce@gmail.com 570 Guangwu Hu 571 Tsinghua University 572 Department of Computer Science, Tsinghua University 573 Beijing, 100084 574 China 575 Email: hgw09@mails.tsinghua.edu.cn 577 Yang Bo 578 Huawei Technology 579 Switch Communication Telepresence Product Dept, Huawei Techonolgy 580 Beijing, 100085 581 China 582 Email: boyang.bo@huawei.com