idnits 2.17.1 draft-ietf-savi-send-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 335: '... to another SEND SAVI device SHOULD be...' RFC 2119 keyword, line 340: '...nnected to hosts SHOULD be configured ...' RFC 2119 keyword, line 343: '...ected to routers SHOULD be configured ...' RFC 2119 keyword, line 355: '... hosts connected SHOULD be configured ...' RFC 2119 keyword, line 360: '...attached to them SHOULD be configured ...' (17 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 25, 2010) is 4931 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3972' is defined on line 1100, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-savi-framework-00 ** Downref: Normative reference to an Informational draft: draft-ietf-savi-framework (ref. 'I-D.ietf-savi-framework') == Outdated reference: A later version (-14) exists of draft-ietf-savi-fcfs-05 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bagnulo 3 Internet-Draft A. Garcia-Martinez 4 Intended status: Standards Track UC3M 5 Expires: April 28, 2011 October 25, 2010 7 SEND-based Source-Address Validation Implementation 8 draft-ietf-savi-send-04 10 Abstract 12 This memo describes SEND SAVI, a mechanism to provide source address 13 validation using the SEND protocol. The proposed mechanism is 14 intended to complement ingress filtering techniques to provide a 15 higher granularity on the control of the source addresses used. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 28, 2011. 34 Copyright Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Non-normative Background to SEND SAVI . . . . . . . . . . . . 3 53 2.1. Address Validation Scope . . . . . . . . . . . . . . . . . 3 54 2.2. SEND SAVI Enforcement Perimeter . . . . . . . . . . . . . 4 55 2.3. Binding Creation for SEND SAVI . . . . . . . . . . . . . . 5 56 3. Perimeter Configuration Guidelines for SEND SAVI . . . . . . . 6 57 4. SEND SAVI Specification . . . . . . . . . . . . . . . . . . . 9 58 4.1. SEND SAVI Data Structures . . . . . . . . . . . . . . . . 9 59 4.2. SEND SAVI Device Configuration . . . . . . . . . . . . . . 11 60 4.3. SEND SAVI Algorithm . . . . . . . . . . . . . . . . . . . 11 61 4.3.1. Traffic Processing . . . . . . . . . . . . . . . . . . 11 62 4.4. VLAN Support . . . . . . . . . . . . . . . . . . . . . . . 22 63 4.5. Protocol Constants . . . . . . . . . . . . . . . . . . . . 22 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 65 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 66 7. Normative References . . . . . . . . . . . . . . . . . . . . . 25 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 69 1. Introduction 71 This memo describes SEND SAVI (Source-Address Validation 72 Implementation), a mechanism to provide source address validation for 73 IPv6 networks using the SEND protocol [RFC3971]. The proposed 74 mechanism is intended to complement ingress filtering techniques to 75 provide a higher granularity on the control of the source addresses 76 used. 78 SEND SAVI uses DAD_NSOL (Duplicate Address Detection Neighbor 79 Solicitation), DAD_NADV (DAD Neighbor Advertisement), NUD_NSOL 80 (Neighbor Unreachability Detection NSOL) and NUD_NADV (NUD Neighbor 81 Advertisement) messages to validate the address ownership claim of a 82 node. Ports and other layer-2 binding anchors can be associated to 83 the IPv6 address of the neighbor, so that source address validation 84 could be performed. 86 Scalability of a distributed SAVI system comprised of multiple SEND 87 SAVI devices is preserved by means of a deployment scenario in which 88 SEND SAVI devices form a "protection perimeter" and validation is 89 only performed when the packet ingress to the protection perimeter. 91 The SEND SAVI specification, as defined in this document, is limited 92 to links in which every IPv6 host and every IPv6 router uses the SEND 93 protocol [RFC3971] to protect the exchange of Neighbor Discovery 94 information. However, SEND SAVI is designed to be deployed in 95 existing SEND networks requiring a minimum set of changes. In 96 particular, SEND SAVI does not require any changes in the hosts whose 97 source address is to be verified. Any verification must solely rely 98 in the usage of already available protocols. This means that SEND 99 SAVI does neither define a new protocol, nor define any new message 100 on existing protocols, nor require that a host uses an existent 101 protocol message in a different way. 103 An overview of the general framework about Source Address Validation 104 Implementation is presented in [I-D.ietf-savi-framework]. 106 2. Non-normative Background to SEND SAVI 108 2.1. Address Validation Scope 110 The application scenario of SEND SAVI is limited to the local link. 111 This means that the goal of SEND SAVI is to verify that the source 112 address of the packets generated by the hosts attached to the local 113 link have not been spoofed. 115 In a link there usually are hosts and routers attached. Hosts 116 generate packets with their own addresses as the source address. 117 This is the so-called local traffic, while routers send packets 118 containing a source address other than their own, since they are 119 forwarding packets generated by other hosts (usually located in a 120 different link). This is the so-called transit traffic. 122 SEND SAVI allows the validation of the source address of the local- 123 traffic, i.e. it allows to verify that the source address of the 124 packets generated by the hosts attached to the local link has not 125 been spoofed. In addition, since SEND does provide the means to 126 verify that a node claiming to act as a router is indeed authorized 127 to act as one, SEND SAVI also provides the means to verify that 128 packets containing off-link prefixes in the source address are 129 forwarded by authorized routers. However, SEND SAVI does not provide 130 the means to verify if a given router is actually authorized to 131 forward packets containing a specific off-link source address. Other 132 techniques, like ingress filtering [RFC2827], are recommended to 133 validate transit traffic. Hence, the security level is increased by 134 the use of both SAVI and ingress filtering. 136 2.2. SEND SAVI Enforcement Perimeter 138 SAVI devices prevent address spoofing by verifying that a layer-2 139 anchor is associated to the IPv6 address used as source address for 140 the packets being exchanged. The layer-2 anchor, which must be 141 difficult to spoof can be the port of the layer-2 switch through 142 which a packet containing a given IPv6 address is received, or a 143 layer-2 address. In this document we assume that MAC-specific 144 mechanisms to secure data packets, such as IEEE 802.1AE, are not 145 generally available, so SEND SAVI is defined to operate with ports as 146 the only available layer-2 anchor. 148 In order to reduce computing and state requirements in SEND SAVI 149 devices, SEND SAVI is designed according to the perimetrical 150 protection deployment model presented in the SAVI framework document 151 [I-D.ietf-savi-framework]. In this model, source address validation 152 is performed only when packets enter in a protected realm defined 153 through the protection perimeter. This perimeter must be deployed in 154 such a way that packets for which validation must be performed can 155 only enter in the protected realm through a port belonging to the 156 border performing the validation. The perimeter is defined by 157 appropriate configuration of the roles of each port, which can be 158 Validating ports and Trusted ports. Validating ports are the ports 159 forming the protection perimeter, so they are the ports in which 160 validation for incoming packets is performed. Trusted ports (TPs) 161 are those in which SEND SAVI filtering is not performed. 163 2.3. Binding Creation for SEND SAVI 165 Filtering is performed according to the bindings existing between a 166 layer-2 anchor and an IPv6 address. These bindings should allow 167 legitimate nodes to use the binding IPv6 address as source address, 168 and prevent illegitimate nodes to do so. When a protection perimeter 169 is defined, the binding must be created for a port of the border to 170 which a legitimate node is attached to, and must not be created in 171 other case. 173 SEND provides tools to assure that a ND message containing a CGA 174 option and signed by a RSA option has been generated by the 175 legitimate owner of the CGA IPv6 address. It also provides tools to 176 verify that a RADV message signed by a RSA option with a key bounded 177 to a CGA or a certificate has been generated by a legitimate router. 179 SEND SAVI benefits from SEND ability to prove address ownership and 180 router authorization to create SAVI bindings. SEND SAVI assumes that 181 a successfully validated SEND message ingressing to the protection 182 perimeter from a validating port guarantees that the host 183 legitimatelly issuing the message is connected to that port. In this 184 case, a binding for the host to this layer-2 port is created. 186 The events that trigger the binding creation process in a Validating 187 port of a SEND SAVI device are: 188 o The reception from a Validating port of a DAD_NSOL message, 189 indicating the attempt of a node to configure an address. This 190 may occur when a node configure an address after being idle for 191 sometime, or because the node has changed the physical attachment 192 point to the layer-2 infrastructure. 193 o The reception from a Validating port of any other packet 194 (including data packets) with a source address for which no 195 binding exists. This would occur if a DAD_NSOL message was lost 196 before arriving to the Validating port, or if a node has changed 197 the physical attachment point to the layer-2 infrastructure 198 without issuing a DAD_NSOL message. 200 When the binding creation process is triggered, the SEND SAVI device 201 has to assure that the host for which the binding is to be created is 202 the legitimate owner of the address. For a binding creation process 203 initiated by a DAD_NSOL exchange, the messages to consider for 204 address ownership validation are other DAD_NSOL messages arriving 205 from other locations or a DAD_NADV message indicating that other host 206 has configured the address before. For other packets initiating the 207 creation of the binding, the SEND SAVI device asks the host to prove 208 address ownership by issuing a NUD_NSOL which has to be answered by a 209 NUD_NADV by the probed node. Note that it is not required to ask 210 other SEND SAVI devices, as it is done in the non-SEND FCFS 211 specification [I-D.ietf-savi-fcfs], since in this case a SEND host 212 can prove authoritatively the ownership of its address. 214 Bindings are refreshed periodically by means of a NUD_NSOL message 215 issued by the SEND SAVI device through the bounded port which has to 216 be answered by a valid NUD_NADV message by the node for which the 217 binding exist. 219 SEND SAVI could be sensible to replay attacks, i.e. situations in 220 which a secured SEND message is replayed by a non-legitimate node. 221 For example, a node could immediatelly re-inject a valid SEND message 222 being received from other node, to force the creation of a binding 223 for which it is not authorized. SEND provides some means to prevent 224 the replaying of ND messages, in particular, the use of nonces to 225 validate advertisements that were previously solicited, and the use 226 of timestamps to validate solicitation messages and unsolicited 227 advertisements. However, the emphasis for SEND anti-replay 228 protection is to assure that confidence in some information (for 229 example, the relationship between an IPv6 address and a layer-2 230 address) is not hold for more time than reasonable, while in SEND 231 SAVI truthful information (in SEND sense, like the relationship of an 232 IPv6 address and a layer-2 address) can be used to create a SAVI 233 binding in a time span shorter than the time reasonable to consider 234 the information aged. As a consequence, SEND SAVI relies only in 235 messages with a low chance of being replayed from different ports to 236 the legitimate one and still being considered valid by SEND. The 237 messages being used by SEND SAVI to create bindings are: 238 o Unsolicited DAD_NSOL messages. According to the SEND SAVI 239 specification Section 4.3.1.1 These messages can only be forwarded 240 to ports through which a previous binding for the same IPv6 241 address existed. 242 o NUD_NADV messages in response to a NUD_NSOL sent by the SEND SAVI 243 device, both exchanged through the same Validating port. In this 244 case, anti-replay protection is assured by nonce exchange. This 245 message exchange is also used to refresh the binding. 247 Any validated RADV can be used to determine that a node for which a 248 binding exists in a Validating port is a router, since the 249 topological part of the binding has been assured before. In 250 addition, the acquisition of prefix information, required to 251 determine local and transit traffic, is not tied to topological 252 considerations too, so for this case regular SEND validating rules 253 are applied. 255 3. Perimeter Configuration Guidelines for SEND SAVI 257 As it has been discussed before, the perimeter is defined by 258 appropriate port configuration. Ports in SEND SAVI devices may 259 assume two roles according to its behavior when filtering and 260 validating SEND messages: Validating ports and Trusted ports. 261 o Validating ports (VPs) are those in which SEND SAVI filtering and 262 binding creation is performed. 263 o Trusted ports (TPs) are those in which neither SEND SAVI filtering 264 nor binding creation are performed. So, packets received through 265 Trusted ports are not filtered by SEND SAVI. The only SEND 266 messages received through a Trusted port which are processed are 267 those related with certificates, prefix information and Neighbor 268 Advertisements for Duplicate Address Detection (DAD_NADV). 270 The following figure shows a typical topology involving trusted and 271 untrusted infrastructure. 273 +--------+ 274 +--+ +--+ +--+ | +--+ | 275 |H1| |H2| |H3| | |R1| | 276 +--+ +--+ +--+ | +--+ | 277 | | | | | | 278 +----------SEND SAVI-ENFORCEMENT-PERIMETER---+ | 279 | | | | | | 280 | +-1-----2-+ +-1-----2-+ | 281 | | SEND- | | SEND- | | 282 | | SAVI1 | | SAVI2 | | 283 | +-3--4----+ +--3------+ | 284 | | | +--------------+ | | 285 | | +----------| |--------+ | 286 | | | SWITCH-A | | 287 | | +----------| |--------+ | 288 | | | +--------------+ | | 289 | +-1--2----+ +--1------+ | 290 | | SEND- | | SEND- | | 291 | | SAVI3 | | SAVI4 | | 292 | +-3-----4-+ +----4----+ | 293 | | | | | 294 | +----SEND SAVI-ENFORCEMENT-PERIMETER----------+ 295 | | | | | 296 | +--+ | +--+ +---------+ 297 | |R2| | |H4| |SWITCH-B | 298 | +--+ | +--+ +---------+ 299 | | | | 300 +-------+ +--+ +--+ 301 |H5| |H6| 302 +--+ +--+ 304 Trusted ports are used for connections with trusted infrastructure, 305 including the communication between SEND SAVI devices, the 306 communication with other switches which are not SEND SAVI devices, 307 routers or other trusted nodes. 309 Port 3 of SEND-SAVI1 and port 1 of SEND-SAVI3 are trusted because the 310 connect two SAVI devices. Port 4 of SEND-SAVI1, port 3 of SEND- 311 SAVI2, port 2 of SEND-SAVI3 and port 1 of SEND-SAVI4 are trusted 312 because they connect to SWITCH-A to which only trusted nodes are 313 connected. Port 2 of SEND-SAVI2 and port 3 of SEND-SAVI3 are trusted 314 ports, because they connect to routers. 316 Validating ports are used for connection with non-trusted 317 infrastructure. Therefore, hosts are normally connected to 318 validating ports. Non-SEND SAVI switches that are outside of the 319 SAVI enforcement perimeter also are connected through validating 320 port. In particular, non-SEND SAVI devices which connect directly to 321 hosts or which have no SEND SAVI capable device between themselves 322 and the hosts are connected through a validating port. So, in the 323 figure above, ports 1 and 2 of SEND-SAVI1, port 1 of SEND-SAVI2, port 324 4 of SEND-SAVI3 are validating ports because they connect to hosts. 325 Port 4 of SEND-SAVI4 is also a validating port because it is 326 connected to SWITCH-B which is a non- SEND SAVI capable switch which 327 is connected to hosts H5 and H6. 329 SEND SAVI requires all devices performing SAVI function to implement 330 SEND SAVI (for example, coexistence with non-SEND aware FCFS SAVI 331 [I-D.ietf-savi-fcfs] switches is not allowed). 333 The detailed guidelines for port configuration in SEND SAVI devices 334 are: 335 o Ports that are connected to another SEND SAVI device SHOULD be 336 configured as Trusted ports. Not doing so will at least increase 337 significantly the CPU time, memory consumption and signaling 338 traffic due to SEND SAVI validation, in both the SEND SAVI devices 339 and the node whose address is being validated. 340 o Ports connected to hosts SHOULD be configured as Validating ports. 341 Not doing so will allow the host connected to that port to send 342 packets with spoofed source address. 343 o Ports connected to routers SHOULD be configured as Validating 344 ports. However, the SEND SAVI specification also allows the 345 routers to be connected to Trusted ports, as they are assumed to 346 be part of the trusted infrastructure. When connected through a 347 trusted port, a router can generate traffic with any source 348 address, even those belonging to the link, while when connected 349 through a Validating port it can only send traffic using off-link 350 source addresses, or its own source addresses. When routers are 351 connected to Validating, authorization for the routing function is 352 bound to the router itself, instead of being bound to a port 353 configured in a switch. 354 o Ports connected to a chain of one or more legacy switches that 355 have hosts connected SHOULD be configured as Validating ports. 356 Not doing so will allow the host connected to any of these 357 switches to send packets with spoofed source address. 358 o Ports connected to a chain of one or more legacy switches that 359 have other SEND SAVI devices and/or routers connected but had no 360 hosts attached to them SHOULD be configured as Trusted ports. Not 361 doing so will at least significantly increase the memory 362 consumption in the SEND SAVI devices and increase the signaling 363 traffic due to SEND SAVI validation. 364 o Ports connected to a chain of one or more legacy switches that 365 have a mix of SEND SAVI devices and/or routers with hosts, SHOULD 366 be configured as Validating ports. Not doing so will allow the 367 host connected to that port to send packets with spoofed source 368 address. 370 4. SEND SAVI Specification 372 4.1. SEND SAVI Data Structures 374 The following data structures are defined for SEND SAVI operation: 376 SEND SAVI Port list. This structure defines an entry per port in the 377 SAVI device. Each entry indicates the role configured for the port 378 (Trusted port or Validating port). In addition, only for Validating 379 ports, the entry indicates the presence or absence of a router 380 connected through the port has been stated by successful validation 381 of a RADV message received from this port. This data structure is 382 used to determine the filtering behavior for each port when local- 383 link and off-link traffic is received. If the port is a Trusted 384 Port, both local-link and off-link traffic coming from the port is 385 accepted. If the port is a Validating port but not a Routing port, 386 then only local-link traffic coming from the port for which a binding 387 exists is accepted. If the port is a Validating port and a Routing 388 port, then off-link traffic coming from the port is accepted, but 389 only local-link traffic coming from the port for which a binding 390 exists is accepted. 392 Each entry of the SEND SAVI Port list contains the following 393 information: 394 o Layer-2 Validating port 395 o Configured port role (either Trusted port or Validating port). 396 The default configuration is Validating port. 398 o Router port bit. This value is only meaningful for ports with a 399 configured port role set to Validating port. It indicates whether 400 a RADV message received from the port has been successfully 401 validated, indicating that a router is connected to the port. For 402 this bit to be set, an entry containing this layer-2 port MUST 403 exist in the SEND SAVI Address table for an IP address of an entry 404 in the SEND SAVI Router table. 406 SEND SAVI Address list. The SEND SAVI function relies on state 407 information binding the source IPv6 address used in data packets to 408 the port through which the legitimate host connects. Such 409 information is stored in SEND SAVI Address table. The SEND SAVI 410 Address table contains one entry for each of the IPv6 source 411 addresses in use on a Validating port of the SEND SAVI device. The 412 SEND SAVI Address list is populated with the contents of successfully 413 validated SEND messages. Each entry contains the following 414 information: 415 o IP source address 416 o Layer-2 Validating port to which the host is connected. 417 o Lifetime 418 o Status: TENTATIVE_DAD, TENTATIVE_NUD, VALID, TESTING_VP, 419 TESTING_VP'. 421 SEND SAVI Prefix list. In addition to this, a SEND SAVI device needs 422 to know which are the link prefixes in order to identify local and 423 off-link traffic. This information is obtained from validated RADV 424 messages. This information is not specific to a given port. Note 425 that the information in this table is equivalent to the Prefix List 426 conceptual data structure defined in [RFC4861]. The SEND SAVI Prefix 427 list contains one entry per prefix in use, as follows: 428 o Prefix 429 o Lifetime 431 SEND SAVI Router list. SEND SAVI keeps a table with one entry for 432 each authorized router in use connected to a Validating port of the 433 SAVI device. In particular, it contains the address for which a 434 successfully validated RADV has been received. The information in 435 this table is used to populate the SEND SAVI port table when at least 436 one router has been validated in a layer-2 Validating port (the 437 layer-2 port can be obtained by looking-up for the IPv6 address of 438 the router in the SEND SAVI Address list). It can also be used to 439 issue a RSOL in case the entry is about to expire, in order to ensure 440 that the node is still performing as a router. Note that the 441 information in this table is equivalent to the Default Router List 442 conceptual data structure defined in [RFC4861]. The information 443 stored in the table is the following: 445 o Router IPv6 address 446 o Lifetime 448 4.2. SEND SAVI Device Configuration 450 In order to perform SEND SAVI operation, some basic parameters of a 451 SEND SAVI device have to be configured. 453 A SEND SAVI device operates as a full-fledged SEND node in some 454 cases: it may generate NUD_NSOL, RSOL or CPS messages. Therefore, a 455 SEND SAVI device 456 o MUST be configured with a valid CGA address. Note that when the 457 SEND SAVI device configures this address, it must follow the same 458 rules as regular SEND hosts (such as using secured NSOL messages 459 to perform DAD, etc.) 460 o MUST be configured with at least one Trust anchor to validate the 461 Certification Paths that authorizes route operation. 462 o MUST be configured with Certification Paths, either manually or by 463 means of issuing Certification Path Solicitation messages, as 464 detailed in the SEND specification [RFC3971]. 466 In addition, the port role for each port of the SEND SAVI Port list 467 SHOULD be configured. Otherwise, every port would be labeled as 468 Validating port, and performance may be degraded, as discussed in 469 [I-D.ietf-savi-framework]. 471 4.3. SEND SAVI Algorithm 473 4.3.1. Traffic Processing 475 In this section we describe how packets are processed. 477 First, the source address of packet is analysed to determine if it is 478 local or transit traffic, by checking if the prefix of the source 479 address is included in the SEND SAVI Prefix List (local traffic) or 480 not included (transit traffic). A special case of local traffic is 481 the traffic destined to the SEND SAVI device itself, either 482 specifically, or through a multicast address to which the SEND SAVI 483 device is registered (such as the all-nodes address, ff02::1). 485 Transit traffic processing occurs as follows: 486 o If the transit traffic packet is received through a Trusted port, 487 the data packet is forwarded and no SAVI processing performed. 488 o If the transit traffic packet is received through a Validating 489 port, the packet is only forwarded if the port appears with the 490 Routing bit set in the SEND SAVI Port list, indicating that a 491 router has been validated through SEND procedures at this port. 492 If transit traffic is received from a Validating port, and the 493 port does not appear with the Routing bit set in the SEND SAVI 494 Port list, the SAVI SEND device SHOULD send a RSOL message through 495 the considered port. 497 Processing of traffic addressed to the SEND SAVI device itself occurs 498 as follows: 499 o Packets received from Trusted ports are not filtered. In 500 particular, if a successfully validated CPA message is received 501 through a Trusted port, the certificate information is accepted by 502 the SEND SAVI device. If a successfully validated RADV message is 503 received through a Trusted port, the SEND SAVI Prefix list in the 504 SEND SAVI device is updated accordingly. 505 o NUD_NADV messages corresponding to SEND SAVI operation are 506 processed according to the specification of Section 4.3.1.1. 507 o Packets received from Validating ports are only processed by the 508 SEND SAVI device if a binding exists for the source IPv6 address 509 of the packet, and the state for the binding is VALID or TESTING 510 (see next section). In particular, If a successfully validated 511 RADV message is received through a Trusted port, the SEND SAVI 512 Prefix list in the SEND SAVI device is updated accordingly. The 513 Router bit of the SEND SAVI Port list is set only if the 514 destination address of the RADV message is not a multicast 515 address. If a SEND SAVI device receives a RADV sent to a 516 multicast address, it SHOULD issue a RSOL message to the port 517 through which this message has been received. 519 We next consider how local traffic is processed. 521 4.3.1.1. Processing of Local Traffic 523 If the verification of the source address of a packet shows that it 524 belongs to local traffic, this packet is processed using the state 525 machine described in this section. 527 For the rest of the section, the following assumptions hold: 528 o When it is stated that a secured NUD_NSOL message is issued by a 529 SEND SAVI device through a given port, this means the following: 530 the SEND SAVI device performs a Neighbor Unreachability Detection 531 procedure as described in [RFC4861] with SEND secured messages as 532 defined in [RFC3971] addressed to the IPv6 target address (source 533 address of the packet triggering the procedure). The source 534 address used for issuing the NUD_NSOL is the source address of the 535 SEND SAVI device. 536 o When it is stated that a validated NUD_NADV message is received by 537 a SEND SAVI device through a port P, this means that: a SEND 538 secured NUD_NADV message has been received by the same port 539 through which the corresponding NUD_NSOL message was issued, and 540 the NUD_NADV message has been validated according to [RFC3971] to 541 prove ownership for the IPv6 address under consideration, and 542 being a response for the previous NUD_NSOL message issued by the 543 SEND SAVI device (containing the same nonce value as the NUD_NSOL 544 message to which it answers). 546 We use VP to refer to a Validating port, and TP for Trusted port. 548 The state machine is defined for a binding of a given source IP 549 address in a given SAVI device. In the transitions considered, 550 packets described as inputs refer to the IPaddr IPv6 address 551 associated to the state machine. 553 The possible states are 554 o NO_BIND. This state represents that no binding exists for the 555 address. This is the state for all addresses unless a binding is 556 explicitly created. 557 o TENTATIVE_DAD. This state is reached when the SEND SAVI device 558 has received a validated DAD_NSOL message. The SEND SAVI device 559 waits for a possible DAD_NADV. Packets with the source address of 560 the binding are not forwarded. 561 o TENTATIVE_NUD. A packet different from a valid DAD_NSOL message 562 has been received from port VP and the SEND SAVI device has sent a 563 NUD_NSOL message to the port. Packets with the source address of 564 the binding are not forwarded. 565 o VALID. The binding for the source address has been verified. 566 Packets with the source address of the binding are forwarded. 567 o TESTING_VP. The lifetime of the binding has expired so SEND SAVI 568 device has sent a NUD_NSOL message to the port, or a DAD_NSOL 569 coming from other SEND SAVI device has been received. The SEND 570 SAVI device waits for a validated NADV. Packets with the source 571 address of the binding are allowed to be forwarded. 572 o TESTING_VP'. A validated DAD_NSOL message has been received from 573 a Validating port of the SEND SAVI device. The device waits for a 574 DAD_NADV coming from port VP, or changes the binding to port VP' 575 if no response is received after TENT_LT milliseconds. Packets 576 coming from port VP with the source address of the binding are 577 allowed to be forwarded. 579 The states can be classified into forwarding states, i.e. states in 580 which packets coming for the port associated to the IPv6 address 581 different to the ones used for signalling are forwarded (VALID, 582 TESTING_VP and TESTING_VP'), and non-forwarding states, i.e. states 583 in which packets coming from the port associated to the IPv6 address 584 different to the ones used for signalling are not forwarded (NO_BIND, 585 TENTATIVE_DAD and TENTATIVE_NUD). 587 The state machine defined for SEND SAVI operation adheres to the 588 following design guidelines: 590 o The only events which triggers state changes from forwarding to 591 non-forwarding states and vice versa are the reception of 592 DAD_NSOL, DAD_NADV and NUD_NADV, or the expiration of a timer. 593 Besides, DAD_NADV and NUD_NADV are only processed when expected as 594 a response to a DAD_NSOL or a NUD_NSOL message. The other 595 possible input to consider is 'any other packet', which could 596 generate changes to states belonging to the same class as the 597 original state (i.e. when 'any other packet' is received, the 598 state cannot move from being forwarding to non-forwarding and vice 599 versa). Note that non-validated SEND messages always belong to 600 the 'any other packet' cathegory. The reduced set of messages 601 being able to trigger a change simplifies the processing at SEND 602 SAVI devices. It is also convenient for defining a comprehensive 603 model regarding to anti-replay protection. 604 o The SEND SAVI device is only required to generate NUD_NSOL 605 messages for SEND SAVI operation. This also simplifies the state 606 machine. 607 o Well-behaved hosts are expected to initiate communication by 608 sending secured DAD_NSOL messages. The SEND SAVI state machine is 609 designed to process these events in an optimal way. The reception 610 of other packet types without receiving previously validated 611 DAD_NSOL messages is assumed to be the result of either bad- 612 behaving hosts or the lost of packets. While these events may 613 occur and a binding will ultimately be created for such hosts, the 614 case in which data packets are received without receiving 615 previously a DAD_NSOL message is not always optimized, for the 616 sake of simplicity of the state machine. It is also worth to note 617 that a validated DAD_NSOL provides a reliable hint about the 618 address ownership of a host attached to a given port, while this 619 is not the case for data packets, for example. 620 o If a host has an address configured, and it can prove the 621 ownership of this address, the state is preserved regardless of 622 any indication that a binding for the same source address could be 623 configured in other SEND SAVI device. Bindings for the same 624 source address in two (or more) SEND SAVI devices may occur due to 625 several reasons, for example when a host moves (the two bindings 626 exist just for a short period of time), if accidentally two hosts 627 generate the same address and the DAD procedure has failed. In 628 these unfrequent cases, connectivity is honored over security. 630 The SEND SAVI device must join the Solicited Node Multicast group for 631 all the addresses which state is other than NO_BIND. This is needed 632 to make sure that the SEND SAVI device will receive the DAD_NSOL for 633 those addresses. Please note that it may not be enough to relay on 634 the host behind the Validating port doing so, since the node may move 635 and after a while, the packets for that particular solicited node 636 multicast group will no longer be forwarded to the SEND SAVI device. 637 So, the SAVI device SHOULD join the solicited node multicast groups 638 for all the addresses that are in a state other than NO_BIND. 640 We next describe how different inputs are processed depending on the 641 state of the binding of the IP address 'IPaddr'. A Waiting_lifetime 642 timer is associated to each binding. 644 A simplified version is depicted in the next figure: 646 +-------------+ 647 | | 648 | TESTING_VP' | 649 | | 650 +-------------+ 651 | ^ 652 Timeout / VP=VP' | | 653 VP_NUD_NADV | | VP'_DAD_NSOL/ 654 | | NUD_NSOL 655 | | 656 v | 657 VP_DAD_NSOL +--------+ 658 +------------- | | 659 | | VALID |< -------------------+ 660 | +-------- >| | | 661 | | +--------+ | 662 | | ^ | | 663 | | VP_NUD_ | | Timeout, | 664 | | NADV/- | | TP_DAD_NSOL/NUD_NSOL | 665 | | | v | 666 | | +------------+ | 667 | | | | | 668 | | | TESTING_VP | | 669 | | | | | 670 | | +------------+ | 671 | | | | 672 | | | Timeout | 673 | | VP*, | | 674 | | Timeout/- | VP_NUD_NADV | 675 v | | | 676 +---------------+ | +---------------+ 677 | | | | | 678 | TENTATIVE_DAD | | | TENTATIVE_NUD | 679 | | | | | 680 +---------------+ | +---------------+ 681 ^ | | | ^ 682 | | | Timeout/- | | 683 | | TP_DAD_NSOL, | | | 684 | | TP_DAD_NADV/- | | | 685 | | v | | 686 | | +---------+ | | 687 | +--------- >| |< -----+ | 688 | | NO_BIND | | 689 +--------------| |-----------------+ 690 VP_DAD_NSOL/- +---------+ VP*/VP_NUD_NSOL 692 NO_BIND 693 Relevant inputs for this state: When the node is in this state, there 694 are no unresolved DAD_NSOL or NUD_NSOL messages (generated by SEND 695 SAVI), so the only relevant inputs are DAD_NSOL messages coming 696 either from VP or TP, or any packet other than DAD_NSOL coming from 697 VP or TP. There are no timers too. 698 o If a validated DAD_NSOL message is received from a Validating port 699 VP, the SEND SAVI device forwards this message to all appropriate 700 Trusted ports (the subset of Trusted ports which belong to the 701 forwarding layer-2 topology, and with the restrictions imposed by 702 the MLD snooping mechanism, if applied). The DAD_NSOL messages 703 are not sent through any of the ports configured as Validating 704 Ports. The SEND SAVI device sets the Waiting_timer to TENT_LT, 705 stores all the information required for future validation of the 706 corresponding DAD_NADV message (such as the nonce of the message) 707 and changes the state to TENTATIVE_DAD. Note that in this case it 708 is not possible to check address ownership by sending a NUD_NSOL 709 because while the host is waiting for a possible DAD_NADV its 710 address is in tentative state and it cannot respond to NSOL 711 messages ([RFC4862]). 712 o If any packet other than a DAD_NSOL is received through a 713 Validating port VP, the SEND SAVI device issues a secured NUD_NSOL 714 through port VP. The SEND SAVI device sets the Waiting_timer to 715 TENT_LT. The state is changed to TENTATIVE_NUD. 716 o Validated DAD_NSOL message containing IPAddr as the target address 717 received through a Trusted port are NOT forwarded through any of 718 the Validating ports but they are sent through the proper Trusted 719 Ports (as defined by the switch behavior that will depend on 720 whether it performs MLD snooping or not). The SEND SAVI device 721 MAY assume that any DAD_NSOL message received from a Trusted port 722 has been successfully validated by other SEND SAVI device, so that 723 no additional validation is required. The state is not changed. 724 o Any packet other than a DAD_NSOL received from a Trusted port is 725 forwarded to its destination. This packet is assumed to come from 726 a SEND SAVI device that has securely validated the attachment of 727 the host to its Validating port according to SEND SAVI rules 728 (unless the SEND SAVI perimeter has been breached). The state is 729 not changed. 731 TENTATIVE_DAD 733 To arrive to this state, the SEND SAVI device has received a 734 validated DAD_NSOL coming from port VP and forwarded to TP. The 735 possible events occuring in this state are: the reception of a 736 DAD_NADV message from a TP (the corresponding DAD_NSOL was forwarded 737 to this port), a DAD_NSOL message from VP, other validating port VP' 738 or TP, and the expiration of the timer initiated when the DAD_NSOL 739 was received at port VP. 741 o If a validated DAD_NADV is received from a Trusted port, the 742 binding cannot be configured for port VP. The state is changed to 743 NO_BIND, and the Waiting_timer cleared. 744 o If a validated DAD_NSOL is received from a Trusted port, a host 745 connected to another SEND SAVI device may be trying to configure 746 the same address at the same time. The DAD_NSOL message is 747 forwarded to port VP, so that the host at port VP will not 748 configure the address, as stated in [RFC4862]. The DAD_NSOL 749 message is also forwarded to all appropriate Trusted ports. Then, 750 the Waiting_timer is cleared, and the state is changed to NO_BIND. 751 o Any packet other than a validated DAD_NSOL or DAD_NADV received 752 from a Trusted port is forwarded to its destination. This packet 753 is assumed to come from a SEND SAVI device that has securely 754 validated the attachment of the host to its Validating port 755 according to SEND SAVI rules (unless the SEND SAVI perimeter has 756 been breached). The state is not changed. 757 o If a validated DAD_NSOL is received from a Validating port VP' 758 different to VP, a host connected to VP' may be trying to 759 configure the same address at the same time. The DAD_NSOL message 760 is forwarded to port VP, so that the host at port VP will not 761 configure the address, as stated in [RFC4862]. The DAD_NSOL 762 message is also forwarded to all appropriate Trusted ports. Then, 763 the Waiting_timer is set to TENT_LT, and the state remains in 764 TENTATIVE_DAD, although in this case with VP=VP'. 765 o Any other packet than a validated DAD_NSOL is received from a 766 Validating port VP' different from VP is discarded. The state is 767 not changed. 768 o If a validated DAD_NSOL is received from port VP, the 769 Waiting_timer is set to TENT_LT, and the state remains in 770 TENTATIVE_DAD. 771 o If any packet other than a validated DAD_NSOL is received from VP, 772 it is assumed that the host has configured its address, although 773 it has done it in less time than expected by the SEND SAVI device 774 (less than TENT_LT). Since the host proved address ownership by 775 means of the validated DAD_NSOL message, the binding is created. 776 The Waiting_timer is set to DEFAULT_LT, and the state is changed 777 to VALID. 778 o If Waiting_timer expires, it is assumed that no other host has 779 configured this address. Therefore, the Validating port VP could 780 be bound to this IPv6 address. The Waiting_timer is set to 781 DEFAULT_LT, and the state is changed to VALID. 783 VALID 785 To arrive to this state, successful validation of address ownership 786 has been completed. Relevant transitions for this state are 787 triggered by the reception of DAD_NSOL from ports VP, VP' or TP, and 788 any packet other than DAD_NSOL from VP' or TP. The expiration of 789 Waiting_timer is also relevant to check again for address ownership. 790 o If a validated DAD_NSOL with IPaddr as source address is received 791 through Validating port VP, this message is forwarded to the 792 appropriate trusted ports. The Waiting_timer is set to TENT_LT 793 and the state is changed to TENTATIVE_DAD. 794 o Any packet other than a validated DAD_NSOL containing IPaddr as a 795 source address arriving from Validating port VP is forwarded 796 appropriately. The state is not changed. Note that in the SEND 797 SAVI case Timeout_valid for the entry MUST NOT be set to 798 DEFAULT_LT (as occurs for FCFS SAVI), since regular sending of 799 packets does not provide the required security, which is achieved 800 by performing secured NUD periodically with the sending host. 801 o If a validated DAD_NSOL with IPaddr as source address is received 802 through a Trusted port, the message is forwarded to VP. The 803 Waiting_timer is set to TENT_LT, a secured NUD_NSOL message is 804 sent to IPaddr through VP and the state is changed to TESTING_VP. 805 o If any packet other than a DAD_NSOL with IPaddr as source address 806 is received through a Trusted port, the packet is forwarded to VP 807 and to other appropriate Trusted ports. A secured NUD_NSOL is 808 sent to VP, the Waiting_timer is set to TENT_LT, and the state is 809 changed to TESTING_VP. 810 o If a DAD_NSOL packet with IPaddr as source address is received 811 through a Validating Port VP' (VP' different from the current 812 Validating port for this binding), the message is forwarded to VP. 813 In addition, a secured NUD_NSOL is sent to VP, the Waiting_timer 814 is set to TENT_LT, and the state is changed to TESTING_VP'. 815 o If any packet other than a DAD_NSOL with IPaddr as source address 816 is received from a Validating Port VP', different from the current 817 Validating port for this binding, VP, the packet is discarded. 818 The SEND SAVI device MAY issue a secured NUD_NSOL through port VP, 819 set the Waiting_timer to TENT_LT, and change the state to 820 TESTING_VP'. An alternative to this behavior is that the SEND 821 SAVI device MAY not do anything (in this case, the state would 822 eventually change after a maximum DEFAULT_LT time, if the node at 823 VP does not respond to a NUD_NSOL at TESTING_VP, the state is 824 moved to NO_BIND, and a packet arrives from VP'. 825 o If Waiting_timer expires, a secured NUD_NSOL message is sent 826 through port VP to the IPv6 address, the Waiting_timer is set to 827 TENT_LT, and the state is changed to TESTING_VP. In the 828 TESTING_VP state packets are still being forwarded until the timer 829 expires without receiving a NUD_NADV. 831 TESTING_VP 833 When the SEND SAVI device enters in the TESTING_VP state, the current 834 Validating port is under check through a secured NUD_NSOL message 835 generated by the SEND SAVI device. While testing, packets from the 836 current Validating port are forwarded. Packets coming from Trusted 837 ports are also forwarded. The relevant events for this state are the 838 reception of a secured NUD_NADV message from VP, the reception of a 839 secured DAD_NSOL message from VP, VP' or TP, the reception of any 840 packet other than the previous cases from VP, VP' or TP, and the 841 expiration of the timer waiting for NUD_NADV. 842 o If a validated NUD_NADV message is received from VP, the message 843 is discarded, the Waiting_timer is changed to DEFAULT_LT, and the 844 state is changed to VALID. 845 o If a validated DAD_NSOL message is received from VP, the message 846 is forwarded to the appropriate Trusted ports, the Waiting_timer 847 is set to DEFAULT_LT, and the state is changed to TENTATIVE_DAD. 848 o Any packet other than DAD_NSOL or NUD_NADV containing IPaddr as a 849 source address arriving from Validating port VP is forwarded. 850 Neither the Waiting_timer nor the state are changed. 851 o If a DAD_NSOL message is received from a Trusted port, the message 852 is forwarded to VP and the appropriate Trusted ports. Neither the 853 Waiting_timer nor the state are changed. The host at VP port is 854 under check: if it still is at port VP, it should answer with a 855 NUD_NADV, and also with a DAD_NADV. If it is not there, neither 856 the NUD_NADV nor the DAD_NADV will be received, the timer will 857 expire, the local state will move to NO_BIND, and the state at the 858 remote node will change to VALID. 859 o If a packet other than a DAD_NSOL arrives from a Trusted port, the 860 packet is forwarded. Neither the Waiting_timer nor the state are 861 changed. 862 o If a DAD_NSOL is received from a validating port VP', the message 863 is forwarded to VP and the appropriate Trusted ports. In 864 addition, a secured NUD_NSOL is sent to VP, the Waiting_timer is 865 set to TENT_LT, and the state is changed to TESTING_VP'. 866 o Any other packet received from a validating port VP' is discarded. 867 This may occur because the host has moved but have not issued a 868 DAD_NSOL or the DAD_NSOL message has been lost. The state will 869 eventually move to NO_BIND, and then the packets sent from VP' 870 will trigger the creation of the binding for VP'. 871 o If the Waiting_timer expires, the Waiting_timer is cleared and the 872 state is changed to NO_BIND. 874 TESTING_VP' 876 To arrive to this state an indication that a host at VP' wants to 877 send data with IPaddr as source address while a binding existed for 878 VP. The SEND SAVI device has issued a NUD_NSOL to the host through 879 port VP. The possible events that may occur in this case are the 880 reception of a NUD_NADV from port VP, the reception of DAD_NSOL from 881 VP, VP', TP and VP" (VP" different from VP and VP'), the reception of 882 any other packet from VP, VP', TP or VP", and the expiration of the 883 timer. 885 o If a validated NUD_NADV is received from port VP, then the host at 886 VP is defending its address. VP is kept as the Validating port, 887 the Waiting_timer is set to DEFAULT_LT, and the state is changed 888 to VALID. 889 o If a validated DAD_NSOL is received from port VP, the message is 890 forwarded to VP'. The Waiting_timer is set to TENT_LT and the 891 state is changed to TENTATIVE_DAD. If the host at VP is 892 reconfiguring its address; when forwarding the DAD_NSOL message, 893 the node at VP' is expected to unconfigure its address. 894 o Any packet other than a validated DAD_NSOL or a validated NUD_NADV 895 coming from port VP is forwarded, and the state is not changed. 896 o If a validated DAD_NSOL is received from port VP', the message is 897 forwarded to VP. The Waiting_timer is set to DEFAULT_LT, and the 898 state is not changed. 899 o Any packet other than a validated DAD_NSOL coming from port VP is 900 discarded, and the state is not changed. 901 o If a validated DAD_NSOL is received from port VP", different from 902 VP and VP', the message is forwarded to VP and VP'. VP' is 903 expected to unconfigure its address if it was a VP'_DAD_NSOL 904 message (and not any other packet) the message triggering the 905 transition to this state. The state remains in TESTING_VP' 906 although with VP'=VP". The Waiting_timer is not changed. 907 o Any packet other than a validated DAD_NSOL received from port VP" 908 is discarded and does not affect to the state. 909 o If a validated DAD_NSOL is received from a Trusted port, the 910 message is forwarded to ports VP, VP' and other appropriate 911 Trusted ports. The Waiting_timer is left unchanged and the state 912 is changed to TESTING_VP. VP' is expected to unconfigure its 913 address if it was a VP'_DAD_NSOL message (and not any other 914 packet) the message triggering the transition to this state. 915 o Any packet other than a validated DAD_NSOL coming from a Trusted 916 port is forwarded appropriately, but the state is not changed. 917 o If Waiting_timer expires, it is assumed that the host for which 918 the binding existed is no longer connected through port VP. 919 Therefore, the Validating port VP' could be bound to this IPv6 920 address. The Waiting_timer is set to DEFAULT_LT and the state is 921 changed to VALID. 923 TENTATIVE_NUD 925 To arrive to this state a data packet has been received through port 926 VP without any existing binding in the SEND SAVI device. The SEND 927 SAVI device has sent a NUD_NSOL message to VP. The relevant events 928 for this case are the reception of a NUD_NADV from port VP, the 929 reception of DAD_NSOL from port VP, VP' or TP, and the reception of 930 any packet other than DAD_NSOL and NUD_NADV for port VP, and 931 different from DAD_NSOL for VP' or TP. In addition, the 932 Waiting_timer may expire. 934 o If a validated NUD_NADV message is received through port VP, the 935 message is discarded, the Waiting_timer is set to TENT_LT, and the 936 state is changed to VALID. 937 o If a validated DAD_NSOL message is received through port VP, the 938 message is forwarded to the appropriate Trusted ports, the 939 Waiting_timer is set to TENT_LT and the state is changed to 940 TENTATIVE_DAD. 941 o Any packet other than NUD_NADV or DAD_NSOL received through port 942 VP is discarded. 943 o If a validated DAD_NSOL message is received through port VP' 944 different from port VP, the message is forwarded to the 945 appropriate Trusted ports, the Waiting_timer is set to TENT_LT 946 with VP=VP', and the state is changed to TENTATIVE_DAD. 947 o Any packets other than DAD_NSOL received through port VP' are 948 discarded, and the state is left unchanged. 949 o If a validated DAD_NSOL message is received through a Trusted 950 port, the message is forwarded to port VP, and the state is left 951 unchanged. 952 o Any other packet received from a Trusted port are forwarded 953 appropriately. These packets may come from a SEND SAVI device 954 that has securely validated the attachment of the host to its 955 Validating port according to SEND SAVI rules. The state is left 956 unchanged. 957 o If Waiting_timer expires, the Waiting_timer is cleared and the 958 state is changed to NO_BIND. 960 4.4. VLAN Support 962 In the case the SAVI device is a switch that supports VLANs, the SAVI 963 implementation will behave as if there was one SAVI process per VLAN. 964 The SAVI process of each VLAN will store the binding information 965 corresponding the nodes attached to that particular VLAN. 967 4.5. Protocol Constants 969 TENT_LT is 500 milliseconds. 971 DEFAULT_LT is 5 minutes. 973 5. Security Considerations 975 It should be noted that any SAVI solution is as strong as the lower 976 layer anchor that it uses. In particular, if the lower layer anchor 977 is forgeable, then the resulting SAVI solution will be weak. For 978 example, if the lower layer anchor is a MAC address that can be 979 easily spoofed, then the resulting SAVI will not be stronger than 980 that. On the other hand, if we use switch ports as lower layer 981 anchors (and there is only one host connected to each port) it is 982 likely that the resulting SAVI solution will be considerably more 983 secure. 985 SEND SAVI improves protection compared to conventional SAVI, as a 986 result of the increased ability of SEND hosts to prove address 987 ownership. 989 A critical security consideration regarding to SEND SAVI deals with 990 the need of proper configuration of the roles of the ports in a SEND 991 SAVI deployment scenario. Regarding to security, the main 992 requirement is that ports defining the protected perimeter SHOULD be 993 configured as Validating. Not doing so will generate security 994 breaches through which an attacker could send packets using any 995 source address, regardless of the bindings established in other SEND 996 SAVI devices. However, SEND SAVI is designed to allow even in this 997 case communication for legitimate users. The worst case for the 998 misconfiguration of the perimeter is then that two hosts may use the 999 same source IPv6 address. The reasons for having a misconfigured 1000 perimeter, apart from initial misconfiguration, are the dynamic 1001 operations performed by layer-2 routing mechanisms, for example, as a 1002 result of a failure in a link or switching device. To prevent the 1003 security risks associated, in the case of changes in the topology of 1004 the SEND SAVI devices, all ports of a SEND SAVI device MAY be changed 1005 automatically to Validating. Note that neither connectivity nor the 1006 protection offered are compromised by operating in a mode in which 1007 all ports of the SEND SAVI devices operate in Validating mode (only 1008 performance is affected by this setting). 1010 SEND SAVI does not protect against spoofers being attached to the 1011 same port as a legitimate host. For this reason it is RECOMMENDED 1012 that only one host attaches at the same time to a given port. 1014 One possible concern about SEND SAVI is its behavior when an attacker 1015 tries to forge the identity of a legitimate host by replaying 1016 messages. Note that information that can be valid for SEND a short 1017 period after being generated (the binding between an IPv6 address and 1018 a layer-2 MAC address) is not valid for SEND SAVI if it arrives from 1019 an non-legitimate port. We now perform a security analysis of such a 1020 replay attack for SEND SAVI. On one hand, there is some information 1021 for which the security risks are equivalent to those of SEND 1022 operation, which are situations in which the information received is 1023 not tied to port-related state in SEND SAVI operation. Such 1024 situations are the reception of CPA messages containing certificates, 1025 or the processing of an unsolicited RADV message, which can be used 1026 in SEND SAVI to associate the router condition to the IPv6 address of 1027 an existing binding in the SEND SAVI Port list. On the other hand, 1028 all the messages which can be create a SEND SAVI binding may be 1029 sensible for the replaying of valid SEND messages. SEND SAVI creates 1030 and maintains bindings as a result of the reception of DAD_NSOL 1031 messages and of the exchange of NUD_NSOL/NUD_NADV messages. 1032 o To prevent DAD_NSOL replay attacks, DAD_NSOL messages are not 1033 forwarded to ports through which an existing binding existed. 1034 Therefore, to capture a message that could be used to launch a 1035 replay attack, an attacker must be located either in the port 1036 through which the legitimate host is (in which case the attack is 1037 useless), or in a port in which a legitimate host was before and 1038 for which a binding still exists. For this latter case, an 1039 attacker can prevent the configuration of binding for a legitimate 1040 host in other port (which could have moved from the initial 1041 location), and the binding would be available for the attacker for 1042 DEFAULT_LT ms. The attacker can do this either in the port for 1043 which a binding existed, or in other port to which it is connected 1044 or to which it can convey this information for a third node to 1045 perform this attack. This risk is inherent to allowing layer-2 1046 host mobility in an scenario in which many hosts can attach to the 1047 same port (either at the same time or in instants very close one 1048 to the other). Another consideration is that this situation 1049 reflect the fact that it is impossible to determine the legitimacy 1050 of a node with a more secure NUD_NSOL/NUD_NADV exchange when the 1051 nodes claim to be configuring the address. 1052 o When a NUD_NSOL/NUD_NADV exchange is used to create or maintain a 1053 state, the messages are only forwarded to the port in which the 1054 host claiming to be legitimate is located. In this case, an 1055 attacker must be connected to the same port of the legitimate host 1056 to be able to capture a message which could be replayed. The 1057 replay of NUD_NSOL is useless, since it is not used to trigger the 1058 creation of a binding. The replay of a NUD_NADV message through 1059 the same port is useless, since SEND SAVI does not protect against 1060 spoofers attached to the same port. The replay of a NUD_NADV 1061 message through a different port does result neither in the 1062 creation of a binding in other SEND SAVI device, nor in the 1063 binding created in the SEND SAVI device originating the NUD_NSOL 1064 message, since this SEND SAVI device only considers NUD_NADV 1065 message received from the same port through which the NUD_NSOL 1066 message was sent. 1068 It is worth to note that the potential of Denial of Service attacks 1069 against the SEND SAVI network is increased due to the use of costly 1070 cryptographic operations in order to validate the address of the 1071 hosts. An attacker could generate packets using new source addresses 1072 in order to make the closest SEND SAVI device spend CPU time to 1073 validate DAD_NSOL messages or generate a NUD_NSOL and create a state 1074 in which a NUD_NADV is waited for. This attack can be used to drain 1075 CPU resources of SEND SAVI devices with a very low cost for the 1076 attacker. In order to solve this problem, a rate-limiting mechanism 1077 SHOULD be enforced in a per-port basis. 1079 6. Acknowledgments 1081 Thanks to Ana Kukec for her review and comments on this document. 1082 The text has also benefited from feedback provided by Tony Cheneau. 1084 Marcelo Bagnulo is partly funded by Trilogy, a research project 1085 supported by the European Commission under its Seventh Framework 1086 Program. 1088 Alberto Garcia-Martinez is partly funded by T2C2, a Spanish R&D 1089 project. 1091 7. Normative References 1093 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1094 Defeating Denial of Service Attacks which employ IP Source 1095 Address Spoofing", BCP 38, RFC 2827, May 2000. 1097 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1098 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1100 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1101 RFC 3972, March 2005. 1103 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1104 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1105 September 2007. 1107 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1108 Address Autoconfiguration", RFC 4862, September 2007. 1110 [I-D.ietf-savi-framework] 1111 Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 1112 "Source Address Validation Improvement Protocol 1113 Framework", draft-ietf-savi-framework-00 (work in 1114 progress), September 2010. 1116 [I-D.ietf-savi-fcfs] 1117 Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS- 1118 SAVI: First-Come First-Serve Source-Address Validation for 1119 Locally Assigned Addresses", draft-ietf-savi-fcfs-05 (work 1120 in progress), October 2010. 1122 Authors' Addresses 1124 Marcelo Bagnulo 1125 Universidad Carlos III de Madrid 1126 Av. Universidad 30 1127 Leganes, Madrid 28911 1128 SPAIN 1130 Phone: 34 91 6248814 1131 Email: marcelo@it.uc3m.es 1132 URI: http://www.it.uc3m.es 1134 Alberto Garcia-Martinez 1135 Universidad Carlos III de Madrid 1136 Av. Universidad 30 1137 Leganes, Madrid 28911 1138 SPAIN 1140 Phone: 34 91 6248782 1141 Email: alberto@it.uc3m.es 1142 URI: http://www.it.uc3m.es