idnits 2.17.1 draft-ietf-savi-send-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Note that non-validated SEND messages always belong to the 'any other packet' category. The reduced set of messages being able to trigger a change simplifies the processing at SEND SAVI devices. o DAD_NADV and NUD_NADV are only processed when they are a response to a DAD_NSOL or a NUD_NSOL message. o ND messages are only used by SEND SAVI devices if they are valid. If any of the ND messages used by SEND SAVI is not valid, it is discarded. SEND SAVI devices SHOULD assume that such messages received from Trusted ports have been validated by other SEND SAVI devices, so they SHOULD not validate them in order to reduce processing load at the SEND SAVI device. o The only messages the SEND SAVI device is required to generate for SEND SAVI operation are NUD_NSOL messages. This also simplifies the state machine. o Well-behaved nodes are expected to initiate communication by sending secured DAD_NSOL messages. The SEND SAVI state machine is tailored to efficiently process these events. The reception of other packet types without receiving previously validated DAD_NSOL messages is assumed to be consequence of bad-behaving nodes or infrequent events (such as packet loss, a change in the topology connecting the switches, etc.) While a binding will ultimately be created for nodes affected by such events, simplicity of the state machine is prioritized over any possible optimization for these cases. o If a node has an address configured, and it can prove the ownership of this address, the binding is preserved regardless of any indication that a binding for the same source address could be configured in other SEND SAVI device. Bindings for the same source address in two or more SEND SAVI devices may occur due to several reasons, for example when a host moves (the two bindings exist just for a short period of time), or when many nodes generate the same address and the DAD procedure has failed. In these infrequent cases, SEND SAVI preserves connectivity for the resulting bindings. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: TENTATIVE_NUD To arrive to this state, a data packet has been received through port VP without any existing binding in the SEND SAVI device. The SEND SAVI device has sent a NUD_NSOL message to VP. The relevant events for this case are the reception of a NUD_NADV from port VP, the reception of DAD_NSOL from port VP, VP' or TP, and the reception of any packet other than DAD_NSOL and NUD_NADV for port VP, and different from DAD_NSOL for VP' or TP. In addition, the Waiting_timer may expire. o If a NUD_NADV message is received through port VP, the SEND SAVI device checks for its validity. If the message is not valid, it MUST be discarded. If the message is valid, the Waiting_timer is set to TENT_LT, and the state is changed to VALID. The message is not forwarded to any port. o If a DAD_NSOL message is received through port VP, the SEND SAVI device checks for its validity. If the message is not valid, it MUST be discarded. If the message is valid, it is forwarded to the appropriate Trusted ports, the Waiting_timer is set to TENT_LT and the state is changed to TENTATIVE_DAD. o Any packet other than NUD_NADV or DAD_NSOL received through port VP is discarded. o If a DAD_NSOL message is received through port VP' different from port VP, the SEND SAVI device checks for its validity. If the message is not valid, it MUST be discarded. If the message is valid, it is forwarded to the appropriate Trusted ports, the Waiting_timer is set to TENT_LT, the binding anchor of the DAD_NSOL message received from port VP' is set as the binding anchor, the Validating Port set to VP', and the state is changed to TENTATIVE_DAD. o Any packet other than DAD_NSOL received through port VP' MUST not be forwarded unless the next state for the binding is VALID. The packets received MAY be discarded or MAY be stored for being sent if the state changes later to VALID. The state is left unchanged. o If a DAD_NSOL message is received through a Trusted port, the SEND SAVI device SHOULD assume that the message has been validated. The message is forwarded to port VP, and the state is left unchanged. o Any other packet received from a Trusted port is forwarded appropriately. This packet may come from a SEND SAVI device that has securely validated the attachment of the node to its Validating port according to SEND SAVI rules. The state is left unchanged. o If Waiting_timer expires, the Waiting_timer is cleared and the state is changed to NO_BIND. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: SEND SAVI is defined to operate only with validated SEND messages. The interaction in a mixed scenario comprising SEND and non-SEND devices should be addressed in other document. However, nodes MUST not assume that all SEND messages received from a SEND SAVI device are validated, since these devices only validate the messages strictly required for SEND SAVI operation. Among the number of messages which are not validated, we can name NUD_NSOL messages generated by other nodes and its responses, or RSOL messages. -- The document date (April 15, 2011) is 4759 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: 'I-D.ietf-savi-fcfs' is defined on line 1308, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-savi-framework-04 == Outdated reference: A later version (-14) exists of draft-ietf-savi-fcfs-07 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SAVI Working Group M. Bagnulo 3 Internet-Draft A. Garcia-Martinez 4 Intended status: Standards Track UC3M 5 Expires: October 17, 2011 April 15, 2011 7 SEND-based Source-Address Validation Implementation 8 draft-ietf-savi-send-05 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 finer 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 October 17, 2011. 34 Copyright Notice 36 Copyright (c) 2011 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. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Non-normative Background to SEND SAVI . . . . . . . . . . . . 4 54 3.1. Address Validation Scope . . . . . . . . . . . . . . . . . 4 55 3.2. Binding Creation for SEND SAVI . . . . . . . . . . . . . . 4 56 3.3. SAVI Logging . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.4. SEND SAVI Protection Perimeter . . . . . . . . . . . . . . 6 58 4. SEND SAVI Specification . . . . . . . . . . . . . . . . . . . 8 59 4.1. SEND SAVI Data Structures . . . . . . . . . . . . . . . . 8 60 4.2. SEND SAVI Device Configuration . . . . . . . . . . . . . . 9 61 4.3. Traffic Processing . . . . . . . . . . . . . . . . . . . . 10 62 4.3.1. Transit Traffic Processing . . . . . . . . . . . . . . 10 63 4.3.2. Local Traffic Processing . . . . . . . . . . . . . . . 10 64 4.4. SEND SAVI Port Configuration Guidelines . . . . . . . . . 22 65 4.5. VLAN Support . . . . . . . . . . . . . . . . . . . . . . . 23 66 4.6. Protocol Constants . . . . . . . . . . . . . . . . . . . . 23 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24 68 5.1. Protection Against Replay Attacks . . . . . . . . . . . . 25 69 5.2. Protection Against Denial of Service Attacks . . . . . . . 26 70 5.3. Security Logging . . . . . . . . . . . . . . . . . . . . . 28 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 28 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 29 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 78 1. Requirements notation 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 2. Introduction 86 This memo describes SEND SAVI (SEcure Neighbor Discovery Source- 87 Address Validation Implementation), a mechanism to provide source 88 address validation for IPv6 networks using the SEND protocol 89 [RFC3971]. The proposed mechanism is intended to complement ingress 90 filtering techniques to provide a finer granularity on the control of 91 the source addresses used. 93 SEND SAVI uses DAD_NSOL (Duplicate Address Detection Neighbor 94 SOLicitation), DAD_NADV (DAD Neighbor ADVertisement), NUD_NSOL 95 (Neighbor Unreachability Detection Neigbor SOLicitation) and NUD_NADV 96 (NUD Neighbor ADVertisement) messages to validate the address 97 ownership claim of a node. In additon, SEND SAVI uses RADV (Router 98 ADVertisement) messages to identify routers, and therefore restrict 99 the nodes which can generate packets containing off-link IPv6 source 100 addresses. Using the information contained in these messages, host 101 and router IPv6 addresses are associated to layer-2 binding anchors, 102 so that data packets will be validated by checking for consistency in 103 this binding, as described in [I-D.ietf-savi-framework]. 105 Scalability of a distributed SAVI system comprised of multiple SEND 106 SAVI devices is preserved by means of a deployment scenario in which 107 SEND SAVI devices form a "protection perimeter". In this deployment 108 scenario, validation is only performed when the packet ingress to the 109 protection perimeter. 111 The SEND SAVI specification, as defined in this document, is limited 112 to links and prefixes in which every IPv6 host and every IPv6 router 113 uses the SEND protocol [RFC3971] to protect the exchange of Neighbor 114 Discovery information. 116 SEND SAVI is designed to be deployed in existing SEND networks with a 117 minimum set of changes. In particular, SEND SAVI does not require 118 any changes in the nodes whose source address is to be verified. 119 This is due to the fact that verification solely relies in the usage 120 of already available protocols. Therefore, SEND SAVI does neither 121 define a new protocol, nor define any new message on existing 122 protocols, nor require that a host or router uses an existent 123 protocol message in a different way. 125 An overview of the general framework about Source Address Validation 126 Implementation is presented in [I-D.ietf-savi-framework]. 128 3. Non-normative Background to SEND SAVI 130 3.1. Address Validation Scope 132 The application scenario of SEND SAVI is limited to the local link. 133 This means that the goal of SEND SAVI is to verify that the source 134 addresses of the packets generated by the nodes attached to the local 135 link have not been spoofed, and that only legitimate routers generate 136 packets with off-link IPv6 source addresses. 138 In a link there usually are hosts and routers attached. Hosts 139 generate packets with their own addresses as the source address. 140 This is the so-called local traffic, while routers send packets 141 containing a source address other than their own, since they are 142 forwarding packets generated by other hosts (usually located in a 143 different link). This is the so-called transit traffic. 145 SEND SAVI allows the validation of the source address of the local 146 traffic, i.e. it allows to verify that the source addresses of the 147 packets generated by the nodes attached to the local link have not 148 been spoofed. In addition, since SEND does provide the means to 149 verify that a node claiming to act as a router is indeed authorized 150 to do so, SEND SAVI also provides means to prevent hosts from 151 generating packets with source addresses derived from off-link 152 prefixes. Note, however, that SEND SAVI does not provide the means 153 to verify if a given router is actually authorized to forward packets 154 containing a particular off-link source address. Other techniques, 155 like ingress filtering [RFC2827], are recommended to validate transit 156 traffic. 158 3.2. Binding Creation for SEND SAVI 160 Filtering is performed according to the binding existing between a 161 layer-2 anchor (the binding anchor) and an IPv6 address. These 162 bindings should allow legitimate nodes to use the bounded IPv6 163 address as source address, and prevent illegitimate nodes to do so. 165 SEND [RFC3971] provides tools to assure that a ND (Neighbor 166 Discovery) message containing a CGA option and signed by a RSA option 167 has been generated by the legitimate owner of the CGA IPv6 address. 168 It also provides tools to verify that a Router Advertisement (RADV) 169 message signed by a RSA option with a key bounded to a CGA [RFC3972] 170 or a certificate, has been generated by a legitimate router. 172 SEND SAVI uses SEND validated messages to create bindings between the 173 binding anchor and the CGA. The events that trigger the binding 174 creation process in a SEND SAVI device are: 175 o The reception of a DAD_NSOL message, indicating the attempt of a 176 node to configure an address. This may occur when a node 177 configures an address for the first time or after being idle for 178 some time, or when the node has changed the physical attachment 179 point to the layer-2 infrastructure. 180 o The reception of any other packet (including data packets) with a 181 source address for which no binding exists. This would occur if a 182 DAD_NSOL message was lost, or if a node has changed the physical 183 attachment point to the layer-2 infrastructure without issuing a 184 DAD_NSOL message, a SAVI device loses a binding (for example, due 185 to a restart) or the link topology changes and the SAVI instances 186 through which the packets ingress to the protected perimeter do 187 not have a binding for the node. 189 When the binding creation process is triggered, the SEND SAVI device 190 has to assure that the node for which the binding is to be created is 191 the legitimate owner of the address. For a binding creation process 192 initiated by a DAD_NSOL exchange, the messages to consider for 193 address ownership validation are validated DAD_NSOL messages arriving 194 from other locations or a validated DAD_NADV message indicating that 195 other node had configured the address before. For the case in which 196 other packets than a DAD_NSOL initiate the creation of the binding, 197 the SEND SAVI device explicitly requires the node to prove address 198 ownership by issuing a secured NUD_NSOL which has to be answered by a 199 secured NUD_NADV by the probed node. 201 Bindings are refreshed periodically by means of a secured NUD_NSOL 202 message issued by the SEND SAVI device which has to be answered by a 203 valid NUD_NADV message by the node for which the binding exist. 205 Validated RADV messages are used to associate router authorization to 206 existing bindings (i.e. to an IPv6 address which is also associated 207 to a binding anchor). In this case, packets with off-link source 208 addresses are only forwarded if they are received with a binding 209 anchor which is associated to the IPv6 address of a router. 211 SEND SAVI could be sensible to replay attacks, i.e. situations in 212 which a secured SEND message is replayed by a non-legitimate node. 213 For example, if ports are used as binding anchors, a node could 214 immediately re-inject a valid SEND message being received from a 215 legitimate node to force, in the SAVI device to which it is attached 216 to, the creation of a binding for which it is not authorized. While 217 SEND provides some means to prevent the replaying of ND messages, 218 this built-in protection is not enough for SEND SAVI. SEND anti- 219 replay protection relies on the use of nonces to validate 220 advertisements that were previously solicited, and the use of 221 timestamps to validate solicitation messages and unsolicited 222 advertisements. The emphasis for SEND anti-replay protection is to 223 assure that confidence in some information (for example, the 224 relationship between an IPv6 address and a layer-2 address) is not 225 kept for more time than reasonable. However, in SEND SAVI, 226 information which may be expected to be true for some period, like 227 the relationship of an IPv6 address and a layer-2 address, can be 228 abused to create an illegitimate SAVI binding in a time span shorter 229 than the time reasonable to consider the information aged. As a 230 consequence, SEND SAVI is designed to rely only on messages with a 231 low chance of being replayed: 232 o Unsolicited DAD_NSOL messages. According to the SEND SAVI 233 specification (Section 4.3.2), these messages can only be 234 forwarded to ports through which a previous binding for the same 235 IPv6 address existed. 236 o Valid NUD_NADV messages in response to a secured NUD_NSOL sent by 237 the SEND SAVI device, both exchanged through the same port. 239 Section 5.2 discusses the resulting protection provided by SEND SAVI 240 against replay attacks. 242 3.3. SAVI Logging 244 While the primary goal of SEND SAVI is simply to prevent improper use 245 of IP addresses, a secondary goal is to assist in traceability for 246 determining who an improper actor is. For example, if a remote site 247 reports that a DoS (or component of a DDoS) is coming from the SEND 248 SAVI site, SEND SAVI enforcement can be a useful component in a 249 response. 251 In order to support these and other similar activities, it is a good 252 idea if SAVI devices perform logging of the creation, modification, 253 or removal of address bindings. Any protocol support, such as SYSLOG 254 support for sending those logs to a common server, would be a topic 255 for a future separate document. 257 3.4. SEND SAVI Protection Perimeter 259 In order to reduce computing and state requirements in SEND SAVI 260 devices, SEND SAVI devices can form a "protection perimeter" 261 [I-D.ietf-savi-framework]. In this model, source address validation 262 is performed only when packets enter in a protected realm defined 263 through the protection perimeter. The perimeter is defined by 264 appropriate configuration of the roles of each port, which can be 265 'Validating ports' and 'Trusted ports': 267 o Validating ports (VPs) are those in which SEND SAVI filtering and 268 binding creation is performed. 269 o Trusted ports (TPs) are those in which neither SEND SAVI filtering 270 nor binding creation are performed. So, packets received through 271 Trusted ports are not filtered by SEND SAVI. The only SEND 272 messages received through a Trusted port which are processed are 273 those related with certificates, prefix information and Neighbor 274 Advertisements for Duplicate Address Detection (DAD_NADV). 276 The following figure shows a typical topology involving trusted and 277 untrusted infrastructure. 279 +--+ +--+ +--+ +--+ 280 |H1| |H2| |H3| |R1| 281 +--+ +--+ +--+ +--+ 282 | | | | 283 +----------SEND SAVI-PROTECTION-PERIMETER-------------+ 284 | | | | | | 285 | +-1-----2-+ +-1-----2-+ | 286 | | SEND- | | SEND- | | 287 | | SAVI1 | | SAVI2 | | 288 | +-3--4----+ +--3------+ | 289 | | | +--------------+ | | 290 | | +----------| |--------+ | 291 | | | SWITCH-A | | 292 | | +----------| |--------+ | 293 | | | +--------------+ | | 294 | +-1--2----+ +--1------+ | 295 | | SEND- | | SEND- | | 296 | | SAVI3 | | SAVI4 | | 297 | +-3-----4-+ +----4----+ | 298 | | | | | 299 +------------SEND SAVI-PROTECTION-PERIMETER-----------+ 300 | | | 301 +--+ +--+ +---------+ 302 |R2| |H4| |SWITCH-B | 303 +--+ +--+ +---------+ 304 | | 305 +--+ +--+ 306 |H5| |H6| 307 +--+ +--+ 309 Trusted ports are used for connections with trusted infrastructure, 310 including the communication between SEND SAVI devices or other 311 trusted nodes. 313 Port 3 of SEND-SAVI1 and port 1 of SEND-SAVI3 are trusted because 314 they connect two SAVI devices. Port 4 of SEND-SAVI1, port 3 of SEND- 315 SAVI2, port 2 of SEND-SAVI3 and port 1 of SEND-SAVI4 are trusted 316 because they connect to SWITCH-A to which only trusted nodes are 317 connected. 319 Validating ports are used for connection with non-trusted 320 infrastructure and with routers. Therefore, hosts are normally 321 connected to Validating ports. Routers are also recommended to be 322 connected to Validating ports. Non-SEND SAVI switches that are 323 outside of the SAVI protection perimeter are also connected through 324 Validating ports. In particular, non-SEND-SAVI devices which connect 325 directly to hosts or which do not have a SEND SAVI capable device 326 between themselves and the hosts, are connected through a Validating 327 port. So, in the figure above, ports 1 and 2 of SEND-SAVI1, port 1 328 of SEND-SAVI2, port 4 of SEND-SAVI3 are Validating ports because they 329 connect to hosts. Port 2 of SEND-SAVI2 and port 3 of SEND-SAVI3 are 330 Validating ports because they connect to routers. Port 4 of SEND- 331 SAVI4 is also a Validating port because it is connected to SWITCH-B 332 which is a non-SEND-SAVI capable switch which is connected to hosts 333 H5 and H6. 335 4. SEND SAVI Specification 337 4.1. SEND SAVI Data Structures 339 The following three data structures are defined for SEND SAVI 340 operation: 342 SEND SAVI Data Base. The SEND SAVI function relies on state 343 information binding the source IPv6 address used in data packets to 344 the port through which the legitimate node connects. Such 345 information is stored in the SEND SAVI Data Base. The SEND SAVI Data 346 Base contains one entry for each of the IPv6 source addresses in use 347 on a Validating port of the SEND SAVI device. The SEND SAVI Data 348 Base is populated with the contents of validated SEND messages. Each 349 entry contains the following information: 350 o IPv6 source address 351 o Binding anchor, such as Layer-2 address, port through which the 352 packet was received, etc. 353 o Validating Port through which the packet was received. Note that 354 if the binding anchor used is also the port, the information 355 stored in both elements is the same. 356 o Lifetime 357 o Status: TENTATIVE_DAD, TENTATIVE_NUD, VALID, TESTING_VP, 358 TESTING_VP' 360 o Alternative binding anchor, to be used when the entry is in 361 TESTING_VP' state 362 o Alternative Validating port, VP', to be used when the entry is in 363 TESTING_VP' state 364 o Creation time: the value of the local clock when the entry was 365 firstly created 367 SEND SAVI Prefix list. SEND SAVI devices need to know which are the 368 link prefixes, in order to identify local and off-link traffic. A 369 SEND SAVI device MUST be able to obtain this information from 370 validated RADV messages, either coming from Validating or Trusted 371 ports, as described in Section 4.3.2. This information is not 372 specific to a given port. The SEND SAVI Prefix list contains one 373 entry per prefix in use, as follows: 374 o Prefix 375 o Lifetime 377 When the SEND SAVI device boots, it MUST send a secured RSOL message. 378 The SAVI device SHOULD issue a secured RSOL in case the prefix entry 379 is about to expire. 381 SEND SAVI Router list. SEND SAVI keeps a table with one entry for 382 each authorized router in use connected to a Validating port of the 383 SAVI device. This entry is created for the IPv6 source address from 384 which a validated RADV message addressed to the all-nodes multicast 385 address or to the IPv6 address of the SEND SAVI device has been 386 received from a Validating port. The SAVI device SHOULD issue a 387 secured RSOL through the Validating port through which the router is 388 reachable (according to the information stored in the SEND SAVI Data 389 Base) in case the entry is about to expire, in order to ensure that 390 the node is still a router. The information stored in the table is 391 the following: 392 o Router IPv6 address. There MUST be an entry in the SEND SAVI Data 393 Base for the same IPv6 address. If the corresponding entry in the 394 SEND SAVI Data Base expires, the entry in this table MUST be 395 removed. 396 o Lifetime 398 4.2. SEND SAVI Device Configuration 400 In order to perform SEND SAVI operation, some basic parameters of the 401 SEND SAVI device have to be configured. Since a SEND SAVI device 402 operates as a SEND node to generate NUD_NSOL, RSOL or CPS message, it 403 o MUST be configured with a valid CGA address. Note that when the 404 SEND SAVI device configures this address, it MUST behave as 405 regular SEND node, i.e. using secured NSOL messages to perform 406 DAD, etc. 408 o MUST be configured with at least one Trust anchor to validate the 409 Certification Paths that is used to validate router information. 410 o MAY be configured with Certification Paths. The alternative is 411 obtaining them by means of issuing Certification Path Solicitation 412 messages, as detailed in the SEND specification [RFC3971]. 414 In addition, the port role for each port of the SEND SAVI device 415 SHOULD be configured. The guidelines for this configuration are 416 specified in Section 4.4. Unconfigured ports MUST be labeled as 417 Validating ports; in this case performance may be degraded, as 418 discussed in [I-D.ietf-savi-framework]. 420 4.3. Traffic Processing 422 In this section we describe how packets are processed by a SEND SAVI 423 device. Behavior varies depending on if the packet belogn to local 424 or transit traffic. This is determined by checking if the prefix of 425 the source address is included in the SEND SAVI Prefix List (local 426 traffic) or not included (transit traffic). 428 4.3.1. Transit Traffic Processing 430 Transit traffic processing occurs as follows: 431 o If the transit traffic packet is received through a Trusted port, 432 the data packet is forwarded and no SAVI processing performed. 433 o If the transit traffic packet is received through a Validating 434 port, the packet is only forwarded if the binding anchor for the 435 packet is associated to the binding anchor of an IPv6 address for 436 which an entry in the Router list exists. If transit traffic is 437 received from a Validating port with a binding anchor which is not 438 associated to an entry in the SEND SAVI Router list, the SEND SAVI 439 device SHOULD discard the packets, and MAY send a RSOL message to 440 the all-routers multicast address to the port though which the 441 packet was received. 443 4.3.2. Local Traffic Processing 445 If the verification of the source address of a packet shows that it 446 belongs to local traffic, this packet is processed using the state 447 machine described in this section. SEND SAVI is designed to perform 448 source address validation for both hosts and routers, so in the 449 following description we will refer in general to nodes. 451 For the rest of the section, the following assumptions hold: 452 o When it is stated that a secured NUD_NSOL message is issued by a 453 SEND SAVI device through a port P, this means the following: the 454 SEND SAVI device generates NUD_NSOL messages according to the 455 Neighbor Unreachability Detection procedure described in 457 [RFC4861], addressed to the IPv6 target address (source address of 458 the packet triggering the procedure). These messages are secured 459 by SEND as defined in [RFC3971]. The source address used for 460 issuing the NUD_NSOL is the source address of the SEND SAVI 461 device. The message is sent only through port P. 462 o When it is stated that a validated NUD_NADV message is received by 463 a SEND SAVI device, this means that: a SEND secured NUD_NADV 464 message has been received by the same port P through which the 465 corresponding NUD_NSOL message was issued, and the NUD_NADV 466 message has been validated according to [RFC3971] to prove 467 ownership for the IPv6 address under consideration and to prove 468 that it is a response for the previous NUD_NSOL message issued by 469 the SEND SAVI device (containing the same nonce value as the 470 NUD_NSOL message to which it answers). 472 We use VP to refer to a Validating port, and TP to refer to a Trusted 473 port. 475 The state machine is defined for a binding of a given source IP 476 address in a given SEND SAVI device. In the transitions considered, 477 packets described as inputs refer to the IPaddr IPv6 address 478 associated to the state machine. 480 The possible states for a given IPaddr are: NO_BIND, TENTATIVE_DAD, 481 TENTATIVE_NUD, VALID, TESTING_VP and TESTING_VP'. The NO_BIND state 482 represents that no binding exists for IPaddr; this is the state for 483 all addresses unless a binding is explicitly created. 485 The states can be classified into forwarding states, i.e. states in 486 which packets with the binding anchor associated to the IPv6 address 487 are forwarded, and non-forwarding states, i.e. states in which 488 packets coming from the binding anchor associated to the IPv6 address 489 different to the ones used for signaling are not forwarded. VALID, 490 TENTATIVE_DAD, TESTING_VP and TESTING_VP' are forwarding states, 491 while NO_BIND and TENTATIVE_NUD are non-forwarding states. 493 The state machine defined for SEND SAVI operation adheres to the 494 following design guidelines: 495 o The only events which trigger state changes from forwarding to 496 non-forwarding states and vice versa are the reception of 497 DAD_NSOL, DAD_NADV and NUD_NADV, or the expiration of a timer.The 498 other possible input to consider is 'any other packet', which 499 could generate changes to states belonging to the same forwarding 500 or non-forwarding class as the original state (i.e. when 'any 501 other packet' is received, the state cannot move from being 502 forwarding to non-forwarding and vice versa). A special case of 503 'any other packet' is when validated RADV are received, which can 504 result in the update of the SEND SAVI Prefix or Router lists. 506 Note that non-validated SEND messages always belong to the 'any 507 other packet' category. The reduced set of messages being able to 508 trigger a change simplifies the processing at SEND SAVI devices. 509 o DAD_NADV and NUD_NADV are only processed when they are a response 510 to a DAD_NSOL or a NUD_NSOL message. 511 o ND messages are only used by SEND SAVI devices if they are valid. 512 If any of the ND messages used by SEND SAVI is not valid, it is 513 discarded. SEND SAVI devices SHOULD assume that such messages 514 received from Trusted ports have been validated by other SEND SAVI 515 devices, so they SHOULD not validate them in order to reduce 516 processing load at the SEND SAVI device. 517 o The only messages the SEND SAVI device is required to generate for 518 SEND SAVI operation are NUD_NSOL messages. This also simplifies 519 the state machine. 520 o Well-behaved nodes are expected to initiate communication by 521 sending secured DAD_NSOL messages. The SEND SAVI state machine is 522 tailored to efficiently process these events. The reception of 523 other packet types without receiving previously validated DAD_NSOL 524 messages is assumed to be consequence of bad-behaving nodes or 525 infrequent events (such as packet loss, a change in the topology 526 connecting the switches, etc.) While a binding will ultimately be 527 created for nodes affected by such events, simplicity of the state 528 machine is prioritized over any possible optimization for these 529 cases. 530 o If a node has an address configured, and it can prove the 531 ownership of this address, the binding is preserved regardless of 532 any indication that a binding for the same source address could be 533 configured in other SEND SAVI device. Bindings for the same 534 source address in two or more SEND SAVI devices may occur due to 535 several reasons, for example when a host moves (the two bindings 536 exist just for a short period of time), or when many nodes 537 generate the same address and the DAD procedure has failed. In 538 these infrequent cases, SEND SAVI preserves connectivity for the 539 resulting bindings. 541 The SEND SAVI device MUST join the Solicited Node Multicast group for 542 all the addresses which state is other than NO_BIND. This is needed 543 to make sure that the SEND SAVI device receives DAD_NSOL messages 544 issued for those addresses. Note that it may not be enough to relay 545 on the IGMP messages being sent by the node behind the Validating 546 port, for which a binding for the corresponding address exist, since 547 the node may move and after a while, and the packets for that 548 particular Solicited Node Multicast group will no longer be forwarded 549 to the SEND SAVI device. 551 SEND SAVI devices MUST be able to use validated CPA messages, sent in 552 reply to CPS messages, to acquire certificates used to validate ND 553 messages. In order to process a CPA message received from a 554 Validating port, an entry for the source address of the message MUST 555 exist in the SEND SAVI Data Base. CPA messages received from Trusted 556 ports are always checked and processed. 558 SEND SAVI devices MUST use validated RADV messages to update the SEND 559 SAVI Prefix list and the SEND SAVI Router list. SEND SAVI devices 560 MAY only consider for this purpose (updating SEND SAVI Prefix and 561 Router lists) RADV messages addressed to either its own IPv6 address 562 or to the all-nodes multicast address. Validated RADV messages 563 received from Trusted ports MUST be used to update accordingly the 564 SEND SAVI Prefix and Router lists in the SEND SAVI device. Validated 565 RADV messages received from Validating ports MUST be processed 566 according to the specific rules defined in the state machine for 567 local traffic processing. In short, RADV messages received from 568 Validating ports are only processed for updating the SEND SAVI Router 569 and Prefix lists if a binding for the source IPv6 address of the RADV 570 message is in a forwarding state. 572 We next describe how different inputs are processed depending on the 573 state of the binding of the IP address 'IPaddr'. A Waiting_lifetime 574 timer is associated to each binding. 576 A simplified version is depicted in the next figure (note that all ND 577 messages are assumed to be validated): 579 +-------------+ 580 | | 581 | TESTING_VP' | 582 | | 583 +-------------+ 584 | ^ 585 Timeout / VP=VP' | | 586 VP_NUD_NADV | | VP'_DAD_NSOL/ 587 | | NUD_NSOL 588 | | 589 v | 590 VP_DAD_NSOL +--------+ 591 +------------- | | 592 | | VALID |< -------------------+ 593 | +-------- >| | | 594 | | +--------+ | 595 | | ^ | | 596 | | VP_NUD_ | | Timeout, | 597 | | NADV/- | | TP_DAD_NSOL/NUD_NSOL | 598 | | | v | 599 | | +------------+ | 600 | | | | | 601 | | | TESTING_VP | | 602 | | | | | 603 | | +------------+ | 604 | | | | 605 | | | Timeout | 606 | | VP*, | | 607 | | Timeout/- | VP_NUD_NADV | 608 v | | | 609 +---------------+ | +---------------+ 610 | | | | | 611 | TENTATIVE_DAD | | | TENTATIVE_NUD | 612 | | | | | 613 +---------------+ | +---------------+ 614 ^ | | | ^ 615 | | | Timeout/- | | 616 | | TP_DAD_NSOL, | | | 617 | | TP_DAD_NADV/- | | | 618 | | v | | 619 | | +---------+ | | 620 | +--------- >| |< -----+ | 621 | | NO_BIND | | 622 +--------------| |-----------------+ 623 VP_DAD_NSOL/- +---------+ VP*/VP_NUD_NSOL 625 Simplified SEND SAVI state machine 627 NO_BIND 629 When the node is in this state, there are no unresolved DAD_NSOL or 630 NUD_NSOL messages (generated by SEND SAVI), so the only relevant 631 inputs are DAD_NSOL messages coming either from VP or TP, or any 632 packet other than DAD_NSOL coming from VP or TP. There are no timers 633 configured for this state. 634 o If a DAD_NSOL message is received from a Validating port VP, the 635 SEND SAVI device checks for its validity. If the message is not 636 valid, it MUST be discarded. If the message is valid, then the 637 SEND SAVI device forwards this message to all appropriate Trusted 638 ports (the subset of Trusted ports which belong to the forwarding 639 layer-2 topology, with the restrictions imposed by the MLD 640 snooping mechanism, if applied). DAD_NSOL messages are not sent 641 through any of the ports configured as Validating Ports. The SEND 642 SAVI device sets the Waiting_timer to TENT_LT, stores all the 643 information required for future validation of the corresponding 644 DAD_NADV message (such as the nonce of the message), creates a new 645 entry in the SEND SAVI Data Base for IPaddr and the binding anchor 646 of the received DAD_NSOL, and changes the state to TENTATIVE_DAD. 647 Creation time is set to the current value of the local clock. 648 Note that in this case it is not possible to check address 649 ownership by sending a NUD_NSOL because while the node is waiting 650 for a possible DAD_NADV its address is in tentative state and the 651 node cannot respond to NSOL messages ([RFC4862]). 652 o If any packet other than a DAD_NSOL is received through a 653 Validating port VP, the SEND SAVI device issues a secured NUD_NSOL 654 through port VP. The SEND SAVI device sets the Waiting_timer to 655 TENT_LT. The SEND SAVI device creates a new entry in the SEND 656 SAVI Data Base for IPaddr and the binding anchor of the received 657 packet, and the state is changed to TENTATIVE_NUD. Creation time 658 is set to the current value of the local clock. The SAVI device 659 MAY discard the packet while the DAD procedure is being executed, 660 or MAY store it in order to send it if the next transitions are 661 (strictly) TENTATIVE_NUD and then VALID. 662 o If a DAD_NSOL message containing IPaddr as the target address is 663 received through a Trusted port, the SEND SAVI device SHOULD 664 assume that the message has been validated. This message is not 665 forwarded through any of the Validating ports but they are sent 666 through the proper Trusted Ports (as defined by the switch 667 behavior that will depend on whether it performs MLD snooping or 668 not). The state is not changed. 669 o Any packet other than a DAD_NSOL received from a Trusted port is 670 forwarded to its destination. This packet is assumed to come from 671 a SEND SAVI device that has securely validated the binding 672 according to SEND SAVI rules (unless the SEND SAVI perimeter has 673 been breached). The state is not changed. 675 TENTATIVE_DAD 677 To arrive to this state, the SEND SAVI device has received a 678 validated DAD_NSOL coming from port VP and it has forwarded it to the 679 appropriate TPs. The relevatn events occurring in this state are: 680 the reception of a DAD_NADV message from a TP, a DAD_NSOL message 681 from VP, other Validating port VP' or TP, a data packet from VP, and 682 the expiration of the timer initiated when the DAD_NSOL was received 683 at port VP. 684 o If a DAD_NADV is received from a Trusted port, the SEND SAVI 685 device SHOULD assume that the message has been validated. The 686 reception of a valid DAD_NADV message indicates that the binding 687 cannot be configured for port VP. The state is changed to 688 NO_BIND, and the Waiting_timer cleared. 689 o If a DAD_NSOL is received from a Trusted port, the SEND SAVI 690 device SHOULD assume that the message has been validated. The 691 reception of a valid DAD_NSOL indicates that a node connected to 692 another SEND SAVI device may be trying to configure the same 693 address at the same time. The DAD_NSOL message is forwarded to 694 port VP, so that the node at port VP will not configure the 695 address, as stated in [RFC4862]. The DAD_NSOL message is also 696 forwarded to all appropriate Trusted ports. Then, the 697 Waiting_timer is cleared, and the state is changed to NO_BIND. 698 o Any packet other than a validated DAD_NSOL or DAD_NADV received 699 from a Trusted port is forwarded to its destination. This packet 700 is assumed to come from a SEND SAVI device that has securely 701 validated the binding according to SEND SAVI rules (unless the 702 SEND SAVI perimeter has been breached). The state is not changed. 703 o If a DAD_NSOL is received from a Validating port VP' different to 704 VP, the SEND SAVI device checks for its validity. If the message 705 is not valid, it MUST be discarded. The reception of a valid 706 DAD_NSOL from port VP' indicates that a node connected to VP' may 707 be trying to configure the same address at the same time. The 708 DAD_NSOL message is forwarded to port VP, so that the node at port 709 VP will not configure the address, as stated in [RFC4862]. The 710 DAD_NSOL message is also forwarded to all appropriate Trusted 711 ports. Then, the entry in the SEND SAVI Data Base for IPaddr is 712 updated with the binding anchor of the DAD_NSOL received from port 713 VP', the Waiting_timer is set to TENT_LT, and the state remains in 714 TENTATIVE_DAD, although in this case with VP=VP'. 715 o Any other packet than a validated DAD_NSOL is received from a 716 Validating port VP' different from VP is discarded. The state is 717 not changed. 718 o If a DAD_NSOL is received from port VP, the SEND SAVI device 719 checks for its validity. If the message is not valid, it MUST be 720 discarded. If the DAD_NSOL message is valid, the Waiting_timer is 721 set to TENT_LT, and the state remains in TENTATIVE_DAD. 723 o If any packet other than a DAD_NSOL is received from VP, it is 724 assumed that the node has configured its address, although it has 725 done it in less time than expected by the SEND SAVI device (less 726 than TENT_LT). Since the node proved address ownership by means 727 of the validated DAD_NSOL message, the Waiting_timer is set to 728 DEFAULT_LT, and the state is changed to VALID. 729 A particular case occur if the packet received is a RADV message. 730 The RADV message is checked for validity, and it is discarded if 731 it is not valid (and the Waiting_timer is not changed, and the 732 state reamins in TENTATIVE_DAD). If it is valid, the message is 733 forwarded to the appropriate Trusted ports. In addition, either 734 an entry for this IPv6 source address in the SEND SAVI Router List 735 is created, or the lifetime of an existing entry is updated with 736 the information received in this message. The SEND SAVI Prefix 737 list MUST also be updated according to the content of the RADV 738 message. The SEND SAVI device MAY not process (although it MUST 739 forward) RADV messages addressed to destinations other than the 740 all-nodes multicast address or to the IPv6 address of the SEND 741 SAVI device. 742 o If Waiting_timer expires, it is assumed that no other node has 743 configured this address. Therefore, the Validating port VP could 744 be bound to this IPv6 address. The Waiting_timer is set to 745 DEFAULT_LT, and the state is changed to VALID. 747 VALID 749 To arrive to this state, successful validation of address ownership 750 has been completed and a binding for IPaddr has been created. 751 Relevant transitions for this state are triggered by the reception of 752 DAD_NSOL from ports VP, VP' or TP, and any packet other than DAD_NSOL 753 from VP' or TP. The expiration of Waiting_timer is also relevant to 754 trigger a check for address ownership for the node at VP. 755 o If a DAD_NSOL with IPaddr as source address is received through 756 Validating port VP, the message is checked for validity. If the 757 message is not valid, it MUST be discarded. If the message is 758 valid, it is forwarded to the appropriate Trusted ports. The 759 Waiting_timer is set to TENT_LT and the state is changed to 760 TENTATIVE_DAD. 761 o Any packet other than a DAD_NSOL containing IPaddr as a source 762 address arriving from Validating port VP is forwarded 763 appropriately. The state is not changed. 764 A particular case occur if the packet received is a RADV message. 765 The RADV message is checked for validity, and it is discarded if 766 it is not valid. If it is valid, the message is forwarded to the 767 appropriate Trusted ports. In addition, either an entry for this 768 IPv6 source address in the SEND SAVI Router List is created, or 769 the lifetime of an existing entry is updated with the information 770 received in this message. The SEND SAVI Prefix list MUST also be 771 updated according to the content of the RADV message. The SEND 772 SAVI device MAY not process (although it MUST forward) RADV 773 messages addressed to destinations other than the all-nodes 774 multicast address or to the IPv6 address of the SEND SAVI device. 775 o If a DAD_NSOL with IPaddr as source address is received through a 776 Trusted port, the SEND SAVI device SHOULD assume that the message 777 has been validated. The message is forwarded to VP. The 778 Waiting_timer is set to TENT_LT, a secured NUD_NSOL message is 779 sent to IPaddr through VP and the state is changed to TESTING_VP. 780 o If any packet other than a DAD_NSOL with IPaddr as source address 781 is received through a Trusted port, the packet is forwarded to VP 782 and to other appropriate Trusted ports. A secured NUD_NSOL is 783 sent to VP, the Waiting_timer is set to TENT_LT, and the state is 784 changed to TESTING_VP. 785 o If a DAD_NSOL packet with IPaddr as source address is received 786 through a Validating Port VP' (VP' different from the current 787 Validating port for this binding), the SEND SAVI device checks for 788 its validity. If the message is not valid, it MUST be discarded. 789 If the message is valid, the message is forwarded to VP. In 790 addition, a secured NUD_NSOL is sent to VP, the binding of the 791 DAD_NSOL received from VP' is stored in the Alternative Binding 792 Anchor for future use if the node at VP' is finally selected, the 793 Alternative Validating Port is set to VP', the Waiting_timer is 794 set to TENT_LT, and the state is changed to TESTING_VP'. 795 o If any packet other than a DAD_NSOL with IPaddr as source address 796 is received from a Validating port VP', different from the current 797 Validating port for this binding, VP, the packet is discarded. 798 The SEND SAVI device MAY issue a secured NUD_NSOL through port VP, 799 store the binding of the DAD_NSOL received from VP' in the 800 Alternative Binding Anchor for possible future use, set the 801 Alternative Validating Port to VP', set the Waiting_timer to 802 TENT_LT, and change the state to TESTING_VP'. An alternative to 803 this behavior is that the SEND SAVI device MAY not do anything (in 804 this case, the state would eventually change after a maximum 805 DEFAULT_LT time, if the node at VP does not respond to a NUD_NSOL 806 at TESTING_VP, the state is moved to NO_BIND). Then a packet 807 arriving from VP' would trigger a process that may end up with 808 binding for the node connecting to VP'. 809 o If Waiting_timer expires, a secured NUD_NSOL message is sent 810 through port VP to IPaddr, the Waiting_timer is set to TENT_LT, 811 and the state is changed to TESTING_VP. In the TESTING_VP state 812 packets are still being forwarded until the timer expires without 813 receiving a NUD_NADV. 815 TESTING_VP 817 When the SEND SAVI device enters in the TESTING_VP state, the current 818 Validating port is under check through a secured NUD_NSOL message 819 generated by the SEND SAVI device. While testing, packets from the 820 current Validating port are forwarded. Packets coming from Trusted 821 ports are also forwarded. The relevant events for this state are the 822 reception of a NUD_NADV message from VP, the reception of a DAD_NSOL 823 message from VP, VP' or TP, the reception of any packet other than 824 the previous cases from VP, VP' or TP, and the expiration of the 825 timer associated to the reception of NUD_NADV. 826 o If a NUD_NADV packet is received from VP, the SEND SAVI device 827 checks for its validity. If the message is not valid, it MUST be 828 discarded. If the message is valid, the Waiting_timer is changed 829 to DEFAULT_LT, and the state is changed to VALID. The message is 830 not forwarded to any other port. 831 o If a DAD_NSOL message is received from VP, the SEND SAVI device 832 checks for its validity. If the message is not valid, it MUST be 833 discarded. If the message is valid, it is forwarded to the 834 appropriate Trusted ports, the Waiting_timer is set to DEFAULT_LT, 835 and the state is changed to TENTATIVE_DAD. 836 o If a RADV packet is received from VP, the message is checked for 837 validity, and it is discarded if it is not valid. If it is valid, 838 the message is forwarded appropriately. Either an entry for this 839 IPv6 source address in the SEND SAVI Router List is created, or 840 the lifetime of an existing entry is updated with the information 841 received in this message. The SEND SAVI Prefix list MUST also be 842 updated according to the content of the RADV message. The SEND 843 SAVI device MAY ignore and discard RADV messages addressed to 844 destinations other than the all-nodes multicast address or to the 845 IPv6 address of the SEND SAVI device. The state remains in 846 TESTING_VP. Note that if the timeout expires later, while still 847 in the TESTING_VP state, the entry of the SEND SAVI Router List 848 will also be removed. 849 o Any packet other than DAD_NSOL or NUD_NADV containing IPaddr as a 850 source address arriving from Validating port VP is forwarded. 851 Neither the Waiting_timer nor the state are changed. 852 o If a DAD_NSOL packet is received from a Trusted port, the SEND 853 SAVI device SHOULD assume that the message has been validated. 854 The message is forwarded to VP and the appropriate Trusted ports. 855 Neither the Waiting_timer nor the state are changed. The node at 856 VP port is under check: if it still is at port VP, it should 857 answer with a NUD_NADV, and also with a DAD_NADV. If it is not 858 there, neither the NUD_NADV nor the DAD_NADV will be received, the 859 timer will expire, the local state will move to NO_BIND, and the 860 state at the remote node will change to VALID. 861 o If a packet other than a DAD_NSOL arrives from a Trusted port, the 862 packet is forwarded. Neither the Waiting_timer nor the state are 863 changed. 864 o If a DAD_NSOL is received from a Validating port VP', the SEND 865 SAVI device checks for its validity. If the message is not valid, 866 it MUST be discarded. If it is valid, the message is forwarded to 867 VP and to the appropriate Trusted ports. In addition, a secured 868 NUD_NSOL is sent to VP, the binding of the DAD_NSOL received from 869 VP' is stored in the Alternative Binding Anchor for future use if 870 the node at VP' is finally selected, the Alternative Validating 871 Port is set to VP', the Waiting_timer is set to TENT_LT, and the 872 state is changed to TESTING_VP'. 873 o Any other packet received from a Validating port VP' is discarded. 874 This may occur because the node has moved but have not issued a 875 DAD_NSOL or the DAD_NSOL message has been lost. The state will 876 eventually move to NO_BIND, and then the packets sent from VP' 877 will trigger the creation of the binding for VP'. 878 o If the Waiting_timer expires, the Waiting_timer is cleared and the 879 state is changed to NO_BIND. 881 TESTING_VP' 883 To arrive to this state an indication that a node at VP' wants to 884 send data with IPaddr as source address occurred while a binding 885 existed for VP. The binding anchor of the packet received through 886 VP' which triggered the change of the state to TESTING_VP' was 887 stored, so that it can be retrieved if the node at VP' is determined 888 as the legitimate owner of IPaddr. The SEND SAVI device has issued a 889 NUD_NSOL to IPaddr through port VP. The relevant events that may 890 occur in this case are the reception of a NUD_NADV from port VP, the 891 reception of DAD_NSOL from VP, VP', TP and VP" (VP" different from VP 892 and VP'), the reception of any other packet from VP, VP', TP or VP", 893 and the expiration of the timer. 894 o If a NUD_NADV is received from port VP, the SEND SAVI device 895 checks for its validity. If the message is not valid, it MUST be 896 discarded. The reception of a valid NUD_NADV indicates that the 897 node at VP is defending its address. The binding anchor in use is 898 kept, VP is kept as the Validating port, the Waiting_timer is set 899 to DEFAULT_LT, and the state is changed to VALID. 900 o If a DAD_NSOL is received from port VP, the SEND SAVI device 901 checks for its validity. If the message is not valid, it MUST be 902 discarded. If the message is valid, it is forwarded to VP'. The 903 binding anchor in use is kept, VP is kept as the Validating port, 904 the Waiting_timer is set to TENT_LT and the state is changed to 905 TENTATIVE_DAD. When the DAD_NSOL message is received by the node 906 at VP', this node is expected to unconfigure its address. 907 o If a RADV message is received from VP, it is checked for validity, 908 and it is discarded if it is not valid. If it is valid, the 909 message is forwarded appropriately. Either an entry for this IPv6 910 source address in the SEND SAVI Router List is created, or the 911 lifetime of an existing entry is updated with the information 912 received in this message. The SEND SAVI Prefix list MUST also be 913 updated according to the content of the RADV message. The SEND 914 SAVI device MAY ignore and discard RADV messages addressed to 915 destinations other than the all-nodes multicast address or to the 916 IPv6 address of the SEND SAVI device. The state remains in 917 TESTING_VP' and the Waiting_timer is left unchanged. Note that if 918 the timeout expires later, while still in the TESTING_VP' state, 919 the entry of the SEND SAVI Router List will also be removed. 920 o Any packet other than a validated DAD_NSOL, a validated NUD_NADV 921 or a validated RADV coming from port VP, is forwarded, and the 922 state is not changed. 923 o If a DAD_NSOL is received from port VP', the SEND SAVI device 924 checks for its validity. If the message is not valid, it MUST be 925 discarded. If the message is valid, it is forwarded to VP. The 926 binding anchor in use is kept, the alternative binding anchor is 927 set to the binding anchor of the DAD_NSOL received from port VP', 928 VP' is kept as Alternative Validating Port, VP is kept as the 929 Validating port, the Waiting_timer is set to DEFAULT_LT, and the 930 state is not changed. 931 o Any packet other than a DAD_NSOL coming from port VP is discarded, 932 and the state is not changed. 933 o If a DAD_NSOL is received from port VP", different from VP and 934 VP', the SEND SAVI device checks for its validity. If the message 935 is not valid, it MUST be discarded. If the message is valid, it 936 is forwarded to VP and VP'. VP' is expected to unconfigure its 937 address if the message triggering the transition to this state was 938 a VP'_DAD_NSOL message (and not any other packet). The state 939 remains in TESTING_VP' although the binding of the DAD_NSOL 940 received from VP" is stored in the Alternative Binding Anchor for 941 future use if the node at VP" is finally selected, and the 942 Alternative Validating Port is set to VP". The Waiting_timer is 943 not changed. 944 o Any packet other than a DAD_NSOL received from port VP" is 945 discarded and does not affect to the state. 946 o If a DAD_NSOL is received from a Trusted port, the SEND SAVI 947 device SHOULD assume that the message has been validated. Then, 948 the message is forwarded to ports VP, VP' and other appropriate 949 Trusted ports. The Waiting_timer is left unchanged and the state 950 is changed to TESTING_VP. VP' is expected to unconfigure its 951 address if the packet triggering the transition to this state was 952 a VP'_DAD_NSOL message. 953 o Any packet other than a DAD_NSOL coming from a Trusted port is 954 forwarded appropriately, but the state is not changed. 955 o If Waiting_timer expires, it is assumed that the node for which 956 the binding existed is no longer connected through port VP. 957 Therefore, the Validating port VP' could be bound to this IPv6 958 address. The Waiting_timer is set to DEFAULT_LT and the state is 959 changed to VALID. 961 TENTATIVE_NUD 962 To arrive to this state, a data packet has been received through port 963 VP without any existing binding in the SEND SAVI device. The SEND 964 SAVI device has sent a NUD_NSOL message to VP. The relevant events 965 for this case are the reception of a NUD_NADV from port VP, the 966 reception of DAD_NSOL from port VP, VP' or TP, and the reception of 967 any packet other than DAD_NSOL and NUD_NADV for port VP, and 968 different from DAD_NSOL for VP' or TP. In addition, the 969 Waiting_timer may expire. 970 o If a NUD_NADV message is received through port VP, the SEND SAVI 971 device checks for its validity. If the message is not valid, it 972 MUST be discarded. If the message is valid, the Waiting_timer is 973 set to TENT_LT, and the state is changed to VALID. The message is 974 not forwarded to any port. 975 o If a DAD_NSOL message is received through port VP, the SEND SAVI 976 device checks for its validity. If the message is not valid, it 977 MUST be discarded. If the message is valid, it is forwarded to 978 the appropriate Trusted ports, the Waiting_timer is set to TENT_LT 979 and the state is changed to TENTATIVE_DAD. 980 o Any packet other than NUD_NADV or DAD_NSOL received through port 981 VP is discarded. 982 o If a DAD_NSOL message is received through port VP' different from 983 port VP, the SEND SAVI device checks for its validity. If the 984 message is not valid, it MUST be discarded. If the message is 985 valid, it is forwarded to the appropriate Trusted ports, the 986 Waiting_timer is set to TENT_LT, the binding anchor of the 987 DAD_NSOL message received from port VP' is set as the binding 988 anchor, the Validating Port set to VP', and the state is changed 989 to TENTATIVE_DAD. 990 o Any packet other than DAD_NSOL received through port VP' MUST not 991 be forwarded unless the next state for the binding is VALID. The 992 packets received MAY be discarded or MAY be stored for being sent 993 if the state changes later to VALID. The state is left unchanged. 994 o If a DAD_NSOL message is received through a Trusted port, the SEND 995 SAVI device SHOULD assume that the message has been validated. 996 The message is forwarded to port VP, and the state is left 997 unchanged. 998 o Any other packet received from a Trusted port is forwarded 999 appropriately. This packet may come from a SEND SAVI device that 1000 has securely validated the attachment of the node to its 1001 Validating port according to SEND SAVI rules. The state is left 1002 unchanged. 1003 o If Waiting_timer expires, the Waiting_timer is cleared and the 1004 state is changed to NO_BIND. 1006 4.4. SEND SAVI Port Configuration Guidelines 1008 The detailed guidelines for port configuration in SEND SAVI devices 1009 are: 1011 o Ports that are connected to another SEND SAVI devices SHOULD be 1012 configured as Trusted ports. Not doing so will increase 1013 significantly the CPU time, memory consumption and signaling 1014 traffic due to SEND SAVI validation, in both the SEND SAVI devices 1015 and the node whose address is being validated. 1016 o Ports connected to hosts SHOULD be configured as Validating ports. 1017 Not doing so will allow the host connected to that port to send 1018 packets with spoofed source address. 1019 o Ports connected to routers SHOULD be configured as Validating 1020 ports. However, the SEND SAVI specification also allows the 1021 routers to be connected to Trusted ports, as they are assumed to 1022 be part of the trusted infrastructure. When connected through a 1023 Trusted port, a router can generate traffic with any source 1024 address, even those belonging to the link, while when connected 1025 through a Validating port it can only send traffic using off-link 1026 source addresses, or its own source addresses. When routers are 1027 connected to Validating, authorization for the routing function is 1028 bound to the binding anchor of the router itself, instead of being 1029 bound to a port configured in a switch. 1030 o Ports connected to a chain of one or more legacy switches that 1031 have hosts connected SHOULD be configured as Validating ports. 1032 Not doing so will allow the host connected to any of these 1033 switches to send packets with spoofed source address. 1034 o Ports connected to a chain of one or more legacy switches that 1035 have other SEND SAVI devices but had no routers or hosts attached 1036 to them SHOULD be configured as Trusted ports. Not doing so will 1037 significantly increase the memory consumption in the SEND SAVI 1038 devices and increase the signaling traffic due to SEND SAVI 1039 validation. 1040 o Ports connected to a chain of one or more legacy switches that 1041 have hosts and possibly a mix of SEND SAVI devices and/or routers, 1042 SHOULD be configured as Validating ports. Not doing so will allow 1043 the host connected to that port to send packets with spoofed 1044 source address. 1046 4.5. VLAN Support 1048 In the case the SAVI device is a switch that supports VLANs, the SAVI 1049 implementation will behave as if there was one SAVI process per VLAN. 1050 The SAVI process of each VLAN will store the binding information 1051 corresponding the nodes attached to that particular VLAN. 1053 4.6. Protocol Constants 1055 TENT_LT is 500 milliseconds. 1057 DEFAULT_LT is 5 minutes. 1059 5. Security Considerations 1061 It should be noted that any SAVI solution is as strong as the binding 1062 anchor that it uses. In particular, if the binding anchor is 1063 forgeable, then the resulting SAVI solution will be weak. For 1064 example, if the binding anchor is a MAC address that can be easily 1065 spoofed, then the resulting SAVI will not be stronger than that. On 1066 the other hand, if we use switch ports as binding anchors (and there 1067 is only one node connected to each port) it is likely that the 1068 resulting SAVI solution will be considerably more secure. 1070 SEND SAVI performs its function by binding an IP source address to a 1071 binding anchor. If the attacker manages to send packets using the 1072 binding anchor associated to a given IP address, SEND SAVI validation 1073 will be successful and the SEND SAVI device will allow the packet 1074 through. This can be achieved by spoofing the binding anchor or 1075 because the binding anchor is shared among the legitimate owner of 1076 the address and the attacker. An example of the latter is the case 1077 where the binding anchor is a port of a switched network and a legacy 1078 switch (i.e. no SEND SAVI capable switch) is connected to that port. 1079 All the source addresses of the nodes connected to the legacy switch 1080 will share the same binding anchor (i.e. the switch port). This 1081 means that nodes connected to the legacy switch can spoof each 1082 other's IP address and this will not be detected by the SEND SAVI 1083 device. This can be prevented by not sharing binding anchors among 1084 nodes. 1086 SEND SAVI is defined to operate only with validated SEND messages. 1087 The interaction in a mixed scenario comprising SEND and non-SEND 1088 devices should be addressed in other document. However, nodes MUST 1089 not assume that all SEND messages received from a SEND SAVI device 1090 are validated, since these devices only validate the messages 1091 strictly required for SEND SAVI operation. Among the number of 1092 messages which are not validated, we can name NUD_NSOL messages 1093 generated by other nodes and its responses, or RSOL messages. 1095 SEND SAVI improves protection compared to conventional SAVI, as a 1096 result of the increased ability of SEND nodes to prove address 1097 ownership. 1099 A critical security consideration regarding to SEND SAVI deals with 1100 the need of proper configuration of the roles of the ports in a SEND 1101 SAVI deployment scenario. Regarding to security, the main 1102 requirement is that ports defining the protected perimeter SHOULD be 1103 configured as Validating ports. Not doing so will generate security 1104 breaches through which an attacker could send packets using any 1105 source address, regardless of the bindings established in other SEND 1106 SAVI devices. 1108 5.1. Protection Against Replay Attacks 1110 One possible concern about SEND SAVI is its behavior when an attacker 1111 tries to forge the identity of a legitimate node by replaying 1112 messages. Note that information that can be valid for SEND a short 1113 period after being generated (such as the binding between an IPv6 1114 address and a layer-2 MAC address), is not valid for SEND SAVI if the 1115 binding anchor used is the port and the message arrives from the port 1116 to which a node replaying a message to use an address illegitimately 1117 is connected. For example, with the values recommended by [RFC3971] 1118 for TIMESTAMP_FUZZ and TIMESTAMP_DRIFT, a node receiving a DAD_NSOL 1119 message, would not discard replays of this message being received 1120 within a period of aproximately 2 seconds (more precisely, 2/0.99 1121 seconds). An attacker could replay this message to abort the 1122 configuration of an address for a legitimate node, and to gain the 1123 right to use the address for LIFETIME_LT seconds. We now discuss the 1124 risks of such replay attacks and the protection provided by SEND 1125 SAVI. 1127 To perform a security analysis of such a replay attack for SEND SAVI, 1128 we have to consider two different cases: 1129 o When the information replayed is tied to the anchor binding, 1130 especially if the anchor binding being used is the port through 1131 which packets are received. In this case, all the messages which 1132 can be create a SEND SAVI binding may be sensible to the replay of 1133 valid SEND messages. SEND SAVI creates and maintains bindings as 1134 a result of the reception of DAD_NSOL messages and of the exchange 1135 of NUD_NSOL/NUD_NADV messages. 1136 o When the information replayed is not tied to the anchor binding 1137 (eg. to ports) in SEND SAVI operation. Such situations are the 1138 reception of CPA messages containing certificates, or the 1139 processing of an RADV message coming from a Trusted port, which 1140 can be used in SEND SAVI to populate the SEND SAVI Prefix list. 1141 In this case, the security risks are equivalent to those of SEND 1142 operation. 1143 A special case is the processing of a RADV message coming from a 1144 Validating port. Although part of the information obtained (the 1145 router condition of the node connecting to the port) is 1146 (indirectly) associated to the anchor binding, in this case the 1147 replay of the RADV message does not provide an advantage to an 1148 attacker. SEND SAVI requires a binding to exist (between the IPv6 1149 address and the binding anchor) prior to consider the RADV 1150 message, so protecting the binding also protects the ability of an 1151 attacker to become a router. 1153 We now discuss how replay attacks for DAD_NSOL messages and of the 1154 exchange of NUD_NSOL/NUD_NADV messages. For this discussion we 1155 assume that the anchor binding in use is the port through which 1156 packets are received. 1157 o To prevent DAD_NSOL replay attacks, DAD_NSOL messages are not 1158 forwarded to ports through which an existing binding existed. 1159 Therefore, to capture a message that could be used to launch a 1160 replay attack, an attacker has to be located either in the port 1161 through which the legitimate node is connected (in which case the 1162 attack is useless), or in a port in which a legitimate node was 1163 before, but it is not now, and for which a binding still exists. 1164 For this latter case, an attacker can prevent the configuration of 1165 a binding for a legitimate node in other port to which the node 1166 could have moved. This risk is inherent to allow layer-2 node 1167 mobility in an scenario in which many nodes can attach to the same 1168 port (either at the same time or in instants very close one to the 1169 other). Another consideration is that this situation reflect the 1170 fact that it is impossible to determine the legitimacy of a node 1171 without the more secure NUD_NSOL/NUD_NADV exchange, which cannot 1172 be used when the nodes claim to be configuring the address. 1173 o When a NUD_NSOL/NUD_NADV exchange is used to create or maintain a 1174 state, the messages are only forwarded to the port in which the 1175 node claiming to be legitimate is located. In this case, an 1176 attacker connected to the same port as the legitimate node can 1177 capture either the NUD_NSOL or the NUD_NADV message in order to 1178 replay it, but this is useless. The replay of NUD_NSOL is 1179 useless, since this message is not used to trigger the creation of 1180 a binding unless the SEND SAVI device had previously issued the 1181 corresponding NUD_NSOL. The replay of a NUD_NADV message through 1182 the same port is useless, since SEND SAVI does not protect against 1183 spoofers attached to the same port. Finally, the replay of a 1184 NUD_NADV message through a different port does result neither in 1185 the creation of a binding in other SEND SAVI device, nor in the 1186 binding created in the SEND SAVI device originating the NUD_NSOL 1187 message, since SEND SAVI devices only consider NUD_NADV message 1188 received from the same port through which the NUD_NSOL message was 1189 sent. 1191 5.2. Protection Against Denial of Service Attacks 1193 The attacks against the SAVI device basically consist on making the 1194 SEND SAVI device to consume its resource until it runs out of them, 1195 or to slow CPU operation. For instance, a possible attack would be 1196 to create state for different addresses in order to waste memory. At 1197 some point the SEND SAVI device runs out of memory and it needs to 1198 decide how to react in this situation. The result is that some form 1199 of garbage collection is needed to prune the entries. It is 1200 RECOMMENDED that when the SEND SAVI device runs out of the memory 1201 allocated for the SEND SAVI Data Base, it creates new entries by 1202 deleting the entries which Creation Time is higher. This implies 1203 that older entries are preserved and newer entries overwrite each 1204 other. In an attack scenario where the attacker sends a batch of 1205 data packets with different source address, each new source address 1206 is likely to rewrite another source address created by the attack 1207 itself. It should be noted that entries are also garbage collected 1208 using the LIFETIME, which is updated by NUD_NSOL/NUD_NADV exchange. 1209 The result is that in order for an attacker to actually fill the SAVI 1210 DB with false source addresses, it needs to continuously answer to 1211 NUD_NSOL for all the different source addresses, in order for the 1212 entries to grow old and compete with the legitimate entries. The 1213 result is that the cost of the attack for the attacker is highly 1214 increased. 1216 In addition, it is also RECOMMENDED that a SEND SAVI device reserves 1217 a minimum amount of memory for each available port (in the case where 1218 the port is used as part of the L2 anchor). The recommended minimum 1219 is the memory needed to store 4 bindings associated to the port. The 1220 motivation for this recommendation is as follows: an attacker 1221 attached to a given port of a SEND SAVI device may attempt to launch 1222 a DoS attack towards the SEND SAVI device by creating many bindings 1223 for different addresses. It can do so, by sending DAD NSOL for 1224 different addresses. The result is that the attack will consume all 1225 the memory available in the SEND SAVI device. The above 1226 recommendation aims to reserve a minimum amount of memory per port, 1227 so that nodes located in different ports can make use of the reserved 1228 memory for their port even if a DoS attack is occurring in a 1229 different port. 1231 As the SEND SAVI device may store data packets while the address is 1232 being verified, the memory for data packet storage may also be a 1233 target of DoS attacks. The effects of such attacks may be limited to 1234 the lack of capacity to store new data packets. The effect of such 1235 attack will be then that data packets will be dropped during the 1236 verification period. A SEND SAVI device MUST limit the amount of 1237 memory used to store data packets, allowing the other functions to 1238 have available memory even in the case of an attacks as the above 1239 described. 1241 It is worth to note that the potential of Denial of Service attacks 1242 against the SEND SAVI network is increased due to the use of costly 1243 cryptographic operations in order to validate the address of the 1244 nodes. An attacker could generate packets using new source addresses 1245 in order to make the closest SEND SAVI device spend CPU time to 1246 validate DAD_NSOL messages or to generate a secure NUD_NSOL. This 1247 attack can be used to drain CPU resources of SEND SAVI devices with a 1248 very low cost for the attacker. In order to solve this problem, 1249 rate-limiting the processing of packets which may trigger SEND SAVI 1250 events SHOULD be enforced in a per-port basis. 1252 5.3. Security Logging 1254 In order to improve the integration of SEND SAVI into an overall 1255 security environment, and enable response to additional indirect 1256 security issues which SAVI can help ameliorate, it is helpful if SEND 1257 SAVI systems log the creation, modification, and deletion of binding 1258 entries. 1260 6. IANA Considerations 1262 This document has no actions for IANA. 1264 7. Acknowledgments 1266 Thanks to Ana Kukec for her review and comments on this document. 1267 The text has also benefited from feedback provided by Tony Cheneau. 1269 Marcelo Bagnulo is partly funded by Trilogy, a research project 1270 supported by the European Commission under its Seventh Framework 1271 Program. 1273 Alberto Garcia-Martinez is partly funded by T2C2 1274 (TIN2008-06739-C04-01), a Spanish R&D project. 1276 8. References 1278 8.1. Normative References 1280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1281 Requirement Levels", BCP 14, RFC 2119, March 1997. 1283 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1284 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1286 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1287 RFC 3972, March 2005. 1289 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1290 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1291 September 2007. 1293 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1294 Address Autoconfiguration", RFC 4862, September 2007. 1296 8.2. Informative References 1298 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1299 Defeating Denial of Service Attacks which employ IP Source 1300 Address Spoofing", BCP 38, RFC 2827, May 2000. 1302 [I-D.ietf-savi-framework] 1303 Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 1304 "Source Address Validation Improvement Framework", 1305 draft-ietf-savi-framework-04 (work in progress), 1306 March 2011. 1308 [I-D.ietf-savi-fcfs] 1309 Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS- 1310 SAVI: First-Come First-Serve Source-Address Validation for 1311 Locally Assigned IPv6 Addresses", draft-ietf-savi-fcfs-07 1312 (work in progress), April 2011. 1314 Authors' Addresses 1316 Marcelo Bagnulo 1317 Universidad Carlos III de Madrid 1318 Av. Universidad 30 1319 Leganes, Madrid 28911 1320 SPAIN 1322 Phone: 34 91 6248814 1323 Email: marcelo@it.uc3m.es 1324 URI: http://www.it.uc3m.es 1326 Alberto Garcia-Martinez 1327 Universidad Carlos III de Madrid 1328 Av. Universidad 30 1329 Leganes, Madrid 28911 1330 SPAIN 1332 Phone: 34 91 6248782 1333 Email: alberto@it.uc3m.es 1334 URI: http://www.it.uc3m.es