idnits 2.17.1 draft-wu-sava-solution-firsthop-eap-01.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 342. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 353. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 366. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 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 (July 13, 2008) is 5758 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'I-D.wu-sava-problem-statement' is defined on line 274, but no explicit reference was found in the text -- No information found for draft-wu-sava-problem-statement - is the name correct? Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Wu 3 Internet-Draft G. Ren 4 Intended status: Experimental J. Bi 5 Expires: January 14, 2009 X. Li 6 CERNET 7 M. Williams 8 Juniper Networks 9 July 13, 2008 11 A Solution For Source Address Validation in Local Subnet Environment 12 draft-wu-sava-solution-firsthop-eap-01 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 14, 2009. 39 Abstract 41 This document describes a solution for preventing source address 42 spoofing in the local subnet of the Internet. The main idea of the 43 solution is to get a dynamic binding between IP address and access 44 switch port. 46 Requirements Language 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC 2119 [RFC2119]. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Local Subnet Source Address Validation . . . . . . . . . . . . 3 56 2.1. Problem Description . . . . . . . . . . . . . . . . . . . . 3 57 2.2. Focus of the Solution . . . . . . . . . . . . . . . . . . . 4 58 3. An IP Address-Switch Port Binding Solution . . . . . . . . . . 4 59 3.1. System Architecture . . . . . . . . . . . . . . . . . . . . 4 60 3.2. Key Mechanisms . . . . . . . . . . . . . . . . . . . . . . 6 61 3.3. Discussion of Control Protocol . . . . . . . . . . . . . . 6 62 4. CNGI-CERNET2 Test Experience . . . . . . . . . . . . . . . . . 6 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 70 Intellectual Property and Copyright Statements . . . . . . . . . . 9 72 1. Introduction 74 The problem of source address validation is decomposed hierarchically 75 into three levels of granularity in [I-D.wu-sava-framework] for 76 discussion: local subnet source validation, intra-AS source 77 validation, and inter-AS source validation. 79 The local subnet source validation is the crucial level in the 80 hierarchy when it comes to achieving "strict-validated"SAVA status, 81 which means the packet can be traced back to an individual host that 82 is authorized to emit packets with that source address. An IP 83 address-switch port binding solution is proposed in this document. 85 There have been many efforts in the research and engineering 86 community to design mechanisms related to source address validation 87 in local subnet environment. IP Source Guard and DHCP Lease Query 88 are related solution examples. 90 It should be stressed that at this early stage, the solutions 91 proposed in this solution document are not intended to pre-empt other 92 work carried out by the IETF in the solution space. Furthermore, it 93 is envisaged that more than one solution could be devised and 94 deployed for each of the proposed solution elements required under 95 the framework, in keeping with the requirement for a loosely-coupled 96 architecture and, as far as possible, a plug-and-play framework. 98 The intention of this document is to provide some potential solution 99 ideas which have been implemented on the testbed described 100 in[I-D.wu-sava-testbed-experience]. Some other procedures that could 101 be used as solution elements in the local subnet source validation 102 have been devised and one is introduced and discussed in 103 [I-D.baker-sava-cisco-ip-source-guard]. 105 2. Local Subnet Source Address Validation 107 2.1. Problem Description 109 The deployment of BCP38 typically requires that the source address of 110 a packet entering the provider network belong to a prefix that is 111 allocated to or has transit through the attached access network. If 112 there is no special consideration, one host can still spoof source 113 address by sending packet with the "legal" IP address of another host 114 with same IP prefix. The goal of the Local Subnet source address 115 validation is to solve the source address spoofing problem in these 116 scenarios. That is, to achieve "strict-validated" SAVA validation 117 status, which means the packet can be traced back to an individual 118 host that is authorized to emit packets with that source address. 120 See detail in [I-D.wu-sava-framework]. 122 2.2. Focus of the Solution 124 There are several different local subnet scenarios: enterprise 125 networks with switches, home broadband access, access from a wireless 126 mobile device etc. The focus of the solution described in this 127 document is enterprise networks with switches.The source address may 128 be assigned to the host in a static way or a dynamic way. 130 The solution tested in the SAVA testbed takes the strongest 131 requirement for validation in the local subnet. That is, any IPv6 132 address should have a unique association with an entity that is 133 specifically authorised to use that IPv6 address. The SAVA testbed 134 has implemented a solution for IPv6 only. The principles can be 135 extended to IPv4 without difficulty. 137 3. An IP Address-Switch Port Binding Solution 139 3.1. System Architecture 141 The main idea of the solution described in this document is based on 142 creating a dynamic binding between a switch port and valid source IP 143 address, or a binding between MAC address, source IP address and 144 switch port. 146 There are four main modules of the system: Source Address Request 147 Client (SARC) on the host, Source Address Validation Proxy (SAVP) on 148 the switch, Source Address Management Server (SAMS) and Interface to 149 the Authentication Server (IAS). The system architecture is shown in 150 Figure 1. 152 --------- 153 | IAS | 154 ------|- 155 | 156 ---------------- 157 | SERVER | 158 | ------- | 159 | | SAMS | | 160 | -------- | 161 ----------------- 162 | 163 | 164 ---------------- 165 | SWITCH | 166 | ------- | 167 | | SAVP | | 168 | -------- | 169 ----------------- 170 | 171 | 172 ---------------- 173 | END HOST | 174 | ------- | 175 | | SARC | | 176 | -------- | 177 ----------------- 178 Key: SARC == Source Address Request Client , SAVP == Source Address 179 Validation Proxy, SAMS== Source Address Management Server, IAS== 180 Interface to the Authentication Server 182 Figure 1: System Architecture 184 o SARC sends an IP address request to the SAMS. 186 o SAVP relays the IP address request from SARC to SAMS and the IP 187 addess response from SAMS to SARC. It maintain a binding table 188 between switch port and source IP address. 190 o SAMS receives the request from SARC and generates an address 191 response to SARC based on the address allocation and management 192 policy of the local subnet. It can contact to the authentication 193 server for identification and access control via IAS. The 194 allocation history of the address is stored in SAMS for future 195 traceback. 197 o IAS is the interface between the SAMS and authentication server. 198 In many cases, the allocation and binding of IP addresses is 199 performed after a process of identity discovery and application of 200 access control policy. 202 3.2. Key Mechanisms 204 The solution's principle steps are as follows: 206 1. The SARC on the end host sends an IP address request. The SAVP 207 on the switch relays this request to the SAMS. If the address 208 has been predetermined by the end host, it still needs to put it 209 in the request datagram for acceptance from SAMS. 211 2. SAMS receives the IP address request, and generates an address 212 response to SARC based on the address allocation and management 213 policy of the local subnet. The allocation of the IP address is 214 stored in the history database of SAMS for traceback. If the 215 allocation and binding of IP address is performed process of 216 identity discovery and application of access control policy, do 217 the identification via IAS. If authorization is successful, send 218 the IP address response to the SARC. 220 3. The SAVP on the access switch receives the response, and binds 221 the IP address with the switch port on the binding table. In 222 addition, it forwards the issued address to SARC on the end host. 224 4. The access switch begins to filter packets sent from the end 225 host. Packets which do not conform to the tuple (IP address, 226 Switch Port) are discarded. 228 3.3. Discussion of Control Protocol 230 The control protocol for generating binding rules of IP address and 231 switch port can be an extension of DHCP, or a new protocol. The 232 allocation and binding of IP address can also performed after a 233 process of access control and identification. For the implementation 234 in CNGI-CERNET2 testbed, The communication between SARC and SAVP is 235 an extension of EAP, and the communication between SAVP and SAMS is 236 an extension of Radius. 238 4. CNGI-CERNET2 Test Experience 240 The solutions outlined above have been implemented on the testbed of 241 CNGI-CERNET2. An extension of EAP is used for the communication 242 between SARC and SAVP, and an extension of Radius is used for the 243 communication between SAVP and SAMS. Successful testing of the 244 solution has been carried out. A more detailed discussion is 245 described in [I-D.wu-sava-testbed-experience]. 247 5. IANA Considerations 249 This document makes no request of IANA. 251 6. Security Considerations 253 7. Acknowledgements 255 8. References 257 8.1. Normative References 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, March 1997. 262 8.2. Informative References 264 [I-D.baker-sava-cisco-ip-source-guard] 265 Baker, F., "Cisco IP Version 4 Source Guard", 266 draft-baker-sava-cisco-ip-source-guard-00 (work in 267 progress), November 2007. 269 [I-D.wu-sava-framework] 270 Wu, J., "Source Address Validation Architecture (SAVA) 271 Framework", draft-wu-sava-framework-01 (work in progress), 272 July 2007. 274 [I-D.wu-sava-problem-statement] 275 Wu, J., Bonica, R., Bi, J., Li, X., Ren, G., and M. 276 Williams, ""Source Address Validation Architecture (SAVA) 277 Problem Statement", draft-wu-sava-problem-statement-00 278 (Work in Progress)", February 2007. 280 [I-D.wu-sava-testbed-experience] 281 Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams, 282 "SAVA Testbed and Experiences to Date", 283 draft-wu-sava-testbed-experience-06 (work in progress), 284 May 2008. 286 Authors' Addresses 288 Jianping Wu 289 CERNET 290 Network Center, Tsinghua University 291 Beijing 100084 292 China 294 Email: jianping@cernet.edu.cn 296 Gang Ren 297 CERNET 298 Network Center, Tsinghua University 299 Beijing 100084 300 China 302 Email: rg03@mails.tsinghua.edu.cn 304 Jun Bi 305 CERNET 306 Network Center, Tsinghua University 307 Beijing 100084 308 China 310 Email: junbi@cernet.edu.cn 312 Xing Li 313 CERNET 314 Network Center, Tsinghua University 315 Beijing 100084 316 China 318 Email: xing@cernet.edu.cn 320 Mark I. Williams 321 Juniper Networks 322 Suite 1508, W3 Tower, Oriental Plaza, 1 East Chang'An Ave 323 Dong Cheng District, Beijing 100738 324 China 326 Email: miw@juniper.net 328 Full Copyright Statement 330 Copyright (C) The IETF Trust (2008). 332 This document is subject to the rights, licenses and restrictions 333 contained in BCP 78, and except as set forth therein, the authors 334 retain all their rights. 336 This document and the information contained herein are provided on an 337 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 338 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 339 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 340 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 341 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 342 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 344 Intellectual Property 346 The IETF takes no position regarding the validity or scope of any 347 Intellectual Property Rights or other rights that might be claimed to 348 pertain to the implementation or use of the technology described in 349 this document or the extent to which any license under such rights 350 might or might not be available; nor does it represent that it has 351 made any independent effort to identify any such rights. Information 352 on the procedures with respect to rights in RFC documents can be 353 found in BCP 78 and BCP 79. 355 Copies of IPR disclosures made to the IETF Secretariat and any 356 assurances of licenses to be made available, or the result of an 357 attempt made to obtain a general license or permission for the use of 358 such proprietary rights by implementers or users of this 359 specification can be obtained from the IETF on-line IPR repository at 360 http://www.ietf.org/ipr. 362 The IETF invites any interested party to bring to its attention any 363 copyrights, patents or patent applications, or other proprietary 364 rights that may cover technology that may be required to implement 365 this standard. Please address the information to the IETF at 366 ietf-ipr@ietf.org.