idnits 2.17.1 draft-bagnulo-savi-send-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 394. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 204: '...SeND SAVI device MUST listen and proce...' RFC 2119 keyword, line 211: '...SeND SAVI device MAY send periodic Rou...' RFC 2119 keyword, line 240: '... then the packet SHOULD be discarded.(...' RFC 2119 keyword, line 242: '...ND SAVI function MAY send an ICMP Dest...' RFC 2119 keyword, line 280: '...ND SAVI function MAY send an ICMP Dest...' (1 more instance...) 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 (October 26, 2008) is 5632 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 3 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 M. Bagnulo 3 Internet-Draft UC3M 4 Intended status: Standards Track October 26, 2008 5 Expires: April 29, 2009 7 SeND-based Source-Address Validation Implementation 8 draft-bagnulo-savi-send-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 29, 2009. 35 Abstract 37 This memo describes SeND SAVI, a mechanism to provide source address 38 validation using the SeND protocol. The proposed mechanism is 39 intended to complement ingress filtering techniques to provide a 40 higher granularity on the control of the source addresses used. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. Design considerations . . . . . . . . . . . . . . . . . . . . 3 46 2.1. Scope of SeND SAVI . . . . . . . . . . . . . . . . . . . . 3 47 2.2. Constraints for SeND SAVI . . . . . . . . . . . . . . . . 3 48 2.3. Address ownership proof . . . . . . . . . . . . . . . . . 4 49 3. SeND SAVI specification . . . . . . . . . . . . . . . . . . . 5 50 3.1. SeND SAVI Data structures . . . . . . . . . . . . . . . . 5 51 3.2. SeND SAVI algorithm . . . . . . . . . . . . . . . . . . . 5 52 3.2.1. Auhtorized Router Discovery and On-link prefix 53 discovery . . . . . . . . . . . . . . . . . . . . . . 5 54 3.3. SeND SAVI DB maintenance . . . . . . . . . . . . . . . . . 7 55 4. Handling special cases . . . . . . . . . . . . . . . . . . . . 7 56 5. Interaction with FCFS SAVI . . . . . . . . . . . . . . . . . . 8 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 58 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 59 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 Intellectual Property and Copyright Statements . . . . . . . . . . 10 63 1. Introduction 65 This memo describes SeND SAVI, a mechanism to provide source address 66 validation for IPv6 networks using the SeND protocol. The proposed 67 mechanism is intended to complement ingress filtering techniques to 68 provide a higher granularity on the control of the source addresses 69 used. 71 2. Design considerations 73 2.1. Scope of SeND SAVI 75 SeND SAVI applicability is limited to IPv6 hosts and IPv6 routers 76 using the SeND protocol [RFC3971]. 78 The application scenario for SeND SAVI is limited to verify the 79 source address of the packets generated by hosts connected to the 80 local link. 82 In a link there usually are hosts and routers attached. Hosts 83 generate packets with their own address as the source address. This 84 is the so-called local traffic, while routers send packets containing 85 a source address other than their own, since they are forwarding 86 packets generated by other hosts (usually located in a different 87 link). This what the so-called transit traffic. 89 SeND SAVI allows the validation of the source address of the local- 90 traffic i.e. it allows to verify that the source address of the 91 packets generated by the hosts attached to the local link have not 92 been spoofed. In addition, since SeND does provide the means to 93 verify that a node claiming to act as a router is indeed authorized 94 to act as one, SeND SAVI also provides the means to verify that 95 packets containing off-link prefixes in the source address are 96 generated by authorized routers. However, SeND SAVI does not provide 97 the means to verify if a given (authorized) router is actually 98 authorized to forward packets containing a specific (off-link) source 99 address Other techniques, like ingress filtering [RFC2827], are 100 recommended to validate transit traffic. In that sense, SeND SAVI 101 complements ingress filtering. Hence, the security level is 102 increased by using these two techniques. 104 2.2. Constraints for SeND SAVI 106 SeND SAVI is designed to be susceptible of deployment in existing 107 networks requiring a minimum set of changes. For that reason, SeND 108 SAVI does not require any changes in the hosts which source address 109 is to be verified. Any verification must solely rely in the usage of 110 already available protocols. This means that SeND SAVI cannot define 111 a new protocol nor to define any new message on existing protocols 112 nor to require that a host uses an existent protocol message in a 113 different way. In other words, the requirement is no host changes. 114 SeND SAVI relies on the usage of the SeND protocol as defined in 115 [RFC3971] and the usage of CGA addresses as defined in [RFC3972]. No 116 changes to SeND or CGAs are required by SeND SAVI 118 SeND SAVI validation is performed by the SeND SAVI function. Such 119 function can be placed in different type of devices, including a 120 router or a layer-2 bridge. The basic idea is that the SeND SAVI 121 function is located in the points of the topology that can enforce 122 the correct usage of source address by dropping the non-compliant 123 packets. 125 2.3. Address ownership proof 127 The main function performed by SeND SAVI is to verify that the source 128 address used in data packets actually belongs to the originator of 129 the packet. Since SeND SAVI scope is limited to the local-link, the 130 originator of the packet is attached to the local-link. In order to 131 to define any source address validation solution, we need to define 132 some address ownership proof concept i.e. what it means to be able to 133 proof that a given host owns a given address in the sense that the 134 host is entitled to send packet with that source address. 136 Since no hast changes are acceptable, we need to find the means to 137 proof address ownership without requiring a new protocol. In SeND 138 SAVI the address ownership proof is based in the tools used by SeND, 139 namely CGAs and certificates. CGAs are used to verify that the 140 generator of a packet containing an on-link source address is 141 actually the owner of the address. Certificates are used to verify 142 that a node sending packets with off-link source address is an 143 authorized router. By using these two tools, we can verify the 144 source address used in any packet flowing through the local-link is 145 either generated by the host owner of the on-link source address or 146 is generated by an authorized router. 148 In both cases, the verification performed applies to the layer-2 149 address used in the data packets. In the case of the CGA 150 verification, we use CGas and the SeND protocol to verify the 151 Neighbor Advertisement message which contains the binding between the 152 CGA source address and the layer-2 address which will later be used 153 in data packets. By this mean we can verify that is the owner of the 154 CGA source address the one that is claiming to be willing to use the 155 layer-2 address in data packets. We assume that data packets 156 containing this layer-2 information are valid. In the case of the 157 certificate validation, we use the certificate to validate that a 158 given node is an authorized router. Then we use the CGA of that 159 router to verify the binding between the address of the authorized 160 router and the layer-2 information for that router. After these two 161 checks, we assume that packets containing off-link addresses coming 162 from that layer-2 address are valid, since they come from the layer-2 163 address of an authorized router. 165 3. SeND SAVI specification 167 3.1. SeND SAVI Data structures 169 SeND SAVI function relies on state information binding the source 170 address used in data packets to the layer-2 information that 171 contained the first packet that used that source IP address. Such 172 information is stored in SeND SAVI Data Base (DB). The SeND SAVI DB 173 will contain a set of entries about the currently used IP source 174 addresses. So each entry will contain the following information: 175 o IP source address 176 o Layer-2 address and additional relevant Layer-2 information like 177 the port used in case of switched networks. 178 o Lifetime 180 In addition to this, SeND SAVI need to know what are the prefixes 181 that are directly connected, so it maintains a data structure called 182 the SeND SAVI prefix list, which contains: 183 o Prefix 184 o Interface where prefix is directly connected 185 o Lifetime 187 Finally, SeND SAVI keep a list of the authorized routers that are 188 directly connected. In the SeND SAVI Router List, the following 189 information is stored: 190 o Router IP address (of the directly connected interface) 191 o Router Layer-2 address and additional relevant Layer-2 information 192 like the port used in case of switched networks. 194 3.2. SeND SAVI algorithm 196 3.2.1. Auhtorized Router Discovery and On-link prefix discovery 198 In order to be able to determine which devices are entitled to send 199 transit traffic, the SeND SAVI device needs to learn both the set of 200 routers that are connected to the link and the prefixes that are 201 available on-link (in order to be able to differentiate local traffic 202 and transit traffic). 204 For that the SeND SAVI device MUST listen and process Router 205 Advertisements (RA) containing the SeND extensions. After the 206 successful validation of the RA message, the advertised prefixes are 207 included in the SeND SAVI prefix list and the router address is 208 included in the SeND SAVI router list, including the associated 209 Layer-2 information. 211 In addition, the SeND SAVI device MAY send periodic Router 212 Solicitation messages including the SeND extensions to keep the 213 Router list and the prefix list up to date. (Question, should we use 214 the unspecified address for these messages?) 216 The SeND SAVI function is located in a forwarding device, such as a 217 router or a layer-2 bridge. Upon the reception of a data packet, the 218 packet will be passed to the SeND SAVI function which will perform 219 the processing detailed in this section. The outcome of such 220 processing can be that the packet is discarded or that is forwarded 221 as usual. 223 After a data packet is received, the SeND SAVI function checks 224 whether the received data packet is local traffic or transit traffic. 225 It does so by verifying if the source address of the packet belongs 226 to one of the directly connected prefixes available in the receiving 227 interface. It does so by searching the SeND SAVI Prefix List. 228 o If the IP source address belongs to one of the local prefixes of 229 the receiving interface, the data packet is local traffic and the 230 SeND SAVI algorithm is executed as described next. 231 o If the IP source address does not belong to one of the local 232 prefixes of the receiving interface, this means that the dat 233 packet is transit traffic. The SeND SAVI verifies if the layer-2 234 information of the packet corresponds to one of the routers 235 available in the receiving interface, by using the information 236 available in the SeND SAVI router list. If the packet comes from 237 one of the know routers for that interface, then the packet is 238 passed so additional checks such as ingress filtering can be 239 performed. If the packet does not comes from one of the known 240 routers, then the packet SHOULD be discarded.(Note: we could send 241 a RS at this stage to actually verify if the router exists). The 242 SeND SAVI function MAY send an ICMP Destination Unreachable Error 243 with code 5 (Source address failed ingress/egress policy) back to 244 the source address of the data packet. 246 After checking that the data packet is local traffic, the SeND SAVI 247 function will verify the source address used in the packet. In order 248 to do so, it searches the SeND SAVI DB using the IP source address as 249 a key. 250 o If no entry is found, the SeND SAVI performs a Neighbor 251 Unreachability Detection procedure as described in [RFC4861] with 252 SeND secured messages as defined in [RFC3971] including the IP 253 source address and Layer-2 information of the received data 254 packet. If the NUD procedure is successful and also the SeND 255 validation, then a new entry is created, using the information of 256 the data packet, including all the related layer-2 information of 257 where the packet was received from and the lifetime of the entry 258 is set to LIFETIME. The packet is forwarded as usual. 259 o If an entry is found and the layer-2 information of the received 260 data packet matches to the information contained in the existing 261 entry, then the lifetime is set to LIFETIME and the packet is 262 forwarded as usual. 263 o If an entry is found and the layer-2 information of the received 264 data packet does not match the information contained in the 265 existing matching entry, then the SeND SAVI performs a Neighbor 266 Unreachability Detection procedure as described in [RFC4861] with 267 SeND secured messages as defined in [RFC3971] using the IP source 268 address and Layer-2 information available of the received data 269 packet. 270 * If the procedure is successful, then the entry information is 271 updated to include also the new information about the data 272 packet received (in particular the new layer-2 information) and 273 lifetime of the entry is updated to LIFETIME. (Note that in 274 this case, the entry may have more than one layer-2 address for 275 the same entry). The packet is forwarded as usual. 276 (Discussion: We could also verify the existing address using 277 NUD for them as well, in order to detect mobility events and 278 discard the ancient location) 279 * If the procedure is not successful, then the data packet is 280 discarded. The SeND SAVI function MAY send an ICMP Destination 281 Unreachable Error with code 5 (Source address failed ingress/ 282 egress policy) back to the source address of the data packet. 284 3.3. SeND SAVI DB maintenance 286 SeND SAVI SHOULD perform Neighbor Unreachability Detection procedure 287 as defined [RFC4861] in using SeND secured messages periodically for 288 all addresses contained in the SeND SAVI DB. If the NUD procedure is 289 successful, the lifetime value for the entry is updated to LIFETIME. 290 If the procedure is not successful, then the entry is deleted. 292 4. Handling special cases 294 SeND SAVI naturally supports the following special cases: 295 o Mobile nodes are handled naturally, since the node in its new 296 location will pass the NUD procedure and the new location will be 297 included in the SeND SAVI DB. The old entry will be removed by 298 the periodic NUD check. It would be possible to track the 299 location more aggressively by checking the old location when a new 300 location is verified. 301 o Hosts with multiple interfaces connected to the same LAN are 302 compatible with SeND SAVI cause they will be able to pass the NUD 303 procedure, since the host is the owner of the CGA. In this case, 304 the SeND SAVI DB will contain multiple layer-2 addresses for the 305 same IP address. 306 o Anycast services can also be supported. In this case, all to 307 nodes should have the CGA keying material, so they all can pass 308 the NUD procedure. As in the previous case, the SeND SAVI DB 309 entry will contain multiple layer-2 addresses for the same IP 310 address. 312 5. Interaction with FCFS SAVI 314 TBD 316 6. Security Considerations 318 Residual threats. 320 7. Acknowledgments 322 Thanks to Ana Kukec for her review and comments on this document. 324 Marcelo Bagnulo is partly funded by Trilogy, a research project 325 supported by the European Commission under its Seventh Framework 326 Program. 328 8. Normative References 330 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 331 Defeating Denial of Service Attacks which employ IP Source 332 Address Spoofing", BCP 38, RFC 2827, May 2000. 334 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 335 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 336 September 2007. 338 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 339 Neighbor Discovery (SEND)", RFC 3971, March 2005. 341 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 342 RFC 3972, March 2005. 344 Author's Address 346 Marcelo Bagnulo 347 Universidad Carlos III de Madrid 348 Av. Universidad 30 349 Leganes, Madrid 28911 350 SPAIN 352 Phone: 34 91 6248814 353 Email: marcelo@it.uc3m.es 354 URI: http://www.it.uc3m.es 356 Full Copyright Statement 358 Copyright (C) The IETF Trust (2008). 360 This document is subject to the rights, licenses and restrictions 361 contained in BCP 78, and except as set forth therein, the authors 362 retain all their rights. 364 This document and the information contained herein are provided on an 365 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 366 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 367 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 368 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 369 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 370 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 372 Intellectual Property 374 The IETF takes no position regarding the validity or scope of any 375 Intellectual Property Rights or other rights that might be claimed to 376 pertain to the implementation or use of the technology described in 377 this document or the extent to which any license under such rights 378 might or might not be available; nor does it represent that it has 379 made any independent effort to identify any such rights. Information 380 on the procedures with respect to rights in RFC documents can be 381 found in BCP 78 and BCP 79. 383 Copies of IPR disclosures made to the IETF Secretariat and any 384 assurances of licenses to be made available, or the result of an 385 attempt made to obtain a general license or permission for the use of 386 such proprietary rights by implementers or users of this 387 specification can be obtained from the IETF on-line IPR repository at 388 http://www.ietf.org/ipr. 390 The IETF invites any interested party to bring to its attention any 391 copyrights, patents or patent applications, or other proprietary 392 rights that may cover technology that may be required to implement 393 this standard. Please address the information to the IETF at 394 ietf-ipr@ietf.org.