idnits 2.17.1 draft-ietf-savi-send-09.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 -- The document date (April 2, 2013) is 4041 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) -- Obsolete informational reference (is this intentional?): RFC 6434 (Obsoleted by RFC 8504) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 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 4, 2013 April 2, 2013 7 SEND-based Source-Address Validation Implementation 8 draft-ietf-savi-send-09 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 4, 2013. 34 Copyright Notice 36 Copyright (c) 2013 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. Background to SEND SAVI . . . . . . . . . . . . . . . . . . . 4 53 2.1. Address Validation Scope . . . . . . . . . . . . . . . . . 4 54 2.2. Binding Creation for SEND SAVI . . . . . . . . . . . . . . 4 55 2.3. SEND SAVI Protection Perimeter . . . . . . . . . . . . . . 7 56 2.4. Special cases . . . . . . . . . . . . . . . . . . . . . . 8 57 3. SEND SAVI Specification . . . . . . . . . . . . . . . . . . . 9 58 3.1. SEND SAVI Data Structures . . . . . . . . . . . . . . . . 9 59 3.2. SEND SAVI Device Configuration . . . . . . . . . . . . . . 10 60 3.3. Traffic Processing . . . . . . . . . . . . . . . . . . . . 11 61 3.3.1. Transit Traffic Processing . . . . . . . . . . . . . . 11 62 3.3.2. Local Traffic Processing . . . . . . . . . . . . . . . 11 63 3.4. SEND SAVI Port Configuration Guidelines . . . . . . . . . 24 64 3.5. VLAN Support . . . . . . . . . . . . . . . . . . . . . . . 24 65 3.6. Protocol Constants . . . . . . . . . . . . . . . . . . . . 25 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 25 67 4.1. Protection Against Replay Attacks . . . . . . . . . . . . 25 68 4.2. Protection Against Denial of Service Attacks . . . . . . . 27 69 4.3. Residual threats . . . . . . . . . . . . . . . . . . . . . 29 70 4.4. Privacy considerations . . . . . . . . . . . . . . . . . . 29 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 72 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 74 7.1. Normative References . . . . . . . . . . . . . . . . . . . 30 75 7.2. Informative References . . . . . . . . . . . . . . . . . . 30 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 78 1. Introduction 80 This memo describes SEND SAVI (SEcure Neighbor Discovery Source 81 Address Validation Implementation), a mechanism to provide source 82 address validation for IPv6 networks using the SEND protocol 83 [RFC3971]. The proposed mechanism is intended to complement ingress 84 filtering techniques to provide a finer granularity on the control of 85 the source addresses used. 87 SEND SAVI uses the DAD_NSOL (Duplicate Address Detection Neighbor 88 SOLicitation) and the DAD_NADV (DAD Neighbor ADVertisement) messages 89 defined in [RFC4862], and the NUD_NSOL (Neighbor Unreachability 90 Detection Neigbor SOLicitation) and NUD_NADV (NUD Neighbor 91 ADVertisement) messages defined in [RFC4861] to validate the address 92 ownership claim of a node. In addition, SEND SAVI uses RADV (Router 93 ADVertisement) messages defined in [RFC4861] to identify routers, and 94 therefore restrict the nodes which can generate packets containing 95 off-link IPv6 source addresses. Using the information contained in 96 these messages, host and router IPv6 addresses are associated to 97 switch ports, so that data packets will be validated by checking for 98 consistency in this binding, as described in 99 [I-D.ietf-savi-framework]. 101 Scalability of a distributed SAVI system comprised of multiple SEND 102 SAVI devices is preserved by means of a deployment scenario in which 103 SEND SAVI devices form a "protection perimeter". In this deployment 104 scenario, validation is only performed when the packet ingress to the 105 protection perimeter. 107 The SEND SAVI specification, as defined in this document, is limited 108 to links and prefixes in which every IPv6 host and every IPv6 router 109 uses the SEND protocol [RFC3971] to protect the exchange of Neighbor 110 Discovery information. 112 SEND SAVI is designed to be deployed in SEND networks with a minimum 113 set of changes. In particular, SEND SAVI does not require any 114 changes in the nodes whose source address is to be verified. This is 115 because verification solely relies in the usage of already available 116 protocols. Therefore, SEND SAVI does neither define a new protocol, 117 nor define any new message on existing protocols, nor require that a 118 host or router uses an existing protocol message in a different way. 120 An overview of the general framework about Source Address Validation 121 Implementation is presented in [I-D.ietf-savi-framework]. 123 2. Background to SEND SAVI 125 2.1. Address Validation Scope 127 The application scenario of SEND SAVI is limited to the local link. 128 This means that the goal of SEND SAVI is to verify that the source 129 addresses of the packets generated by the nodes attached to the local 130 link have not been spoofed, and that only legitimate routers generate 131 packets with off-link IPv6 source addresses. 133 In a link there usually are hosts and routers attached. Hosts 134 generate packets with their own addresses as the source address. 135 This is called local traffic. Routers may send packets containing a 136 source address other than their own, since they can forward packets 137 generated by other hosts (usually located in a different link). This 138 is the so-called transit traffic. 140 SEND SAVI allows the validation of the source address of the local 141 traffic, i.e., it allows to verify that the source addresses of the 142 packets generated by the nodes attached to the local link have not 143 been spoofed. In addition, since SEND does provide the means to 144 verify that a node claiming to act as a router is indeed authorized 145 to do so, SEND SAVI also provides means to prevent hosts from 146 generating packets with source addresses derived from off-link 147 prefixes. However, SEND SAVI does not provide the means to verify if 148 a given router is actually authorized to forward packets containing a 149 particular off-link source address. Other techniques, like ingress 150 filtering [RFC2827], are recommended to validate transit traffic. 152 2.2. Binding Creation for SEND SAVI 154 Filtering is performed according to bindings between a layer-2 anchor 155 (the binding anchor) and an IPv6 address. These bindings should 156 allow legitimate nodes to use the bounded IPv6 address as source 157 address, and prevent illegitimate nodes to do so. 159 Any SAVI solution is not stronger than the binding anchor it uses. 160 If the binding anchor is easily spoofable (e.g., a Media Access 161 Control (MAC) address), then the resulting solution will be weak. 162 The treatment of non-compliant packets needs to be tuned accordingly. 163 In particular, if the binding anchor is easily spoofable and the SEND 164 SAVI device is configured to drop non-compliant packets, then the 165 usage of FCFS SAVI may open a new vector of Denial-of-Service (DoS) 166 attacks, based on spoofed binding anchors. For that reason, in this 167 specification, only switch ports MUST be used as binding anchors. 168 Other forms of binding anchors are out of the scope of this 169 specification, and proper analysis of the implications of using them, 170 should be performed before their usage. 172 SEND [RFC3971] provides tools to assure that a ND (Neighbor 173 Discovery) message containing a CGA (Cryptographically Generated 174 Addresses) option and signed by a RSA option has been generated by 175 the legitimate owner of the CGA IPv6 address. It also provides tools 176 to verify that a Router Advertisement (RADV) message signed by a RSA 177 option with a key bounded to a CGA [RFC3972] or a certificate, has 178 been generated by a legitimate router. 180 SEND SAVI uses SEND validated messages to create bindings between the 181 CGA and the port of the SEND SAVI device from which it is reasonable 182 to receive packets with the CGA as source addresses. The events that 183 trigger the binding creation process in a SEND SAVI device are: 184 o The reception of a DAD_NSOL message, indicating the attempt of a 185 node to configure an address. This may occur when a node 186 configures an address for the first time or after being idle for 187 some time, or when the node has changed the physical attachment 188 point to the layer-2 infrastructure. 189 o The reception of any other packet (including data packets) with a 190 source address for which no binding exists. This would occur if 191 DAD_NSOL messages were lost, a node has changed the physical 192 attachment point to the layer-2 infrastructure without issuing a 193 DAD_NSOL message, a SAVI device loses a binding (for example, due 194 to a restart), or the link topology changed. 196 When the binding creation process is triggered, the SEND SAVI device 197 has to assure that the node for which the binding is to be created is 198 the legitimate owner of the address. For the case in which the 199 binding creation process initiated by a DAD_NSOL exchange, the SEND 200 SAVI device waits for the reception of a validated DAD_NADV message 201 indicating that other node had configured the address before, or 202 validated DAD_NSOL messages arriving from other locations indicating 203 that another node is trying to configure the same address at the same 204 time. For the case in which other packets than a DAD_NSOL initiate 205 the creation of the binding, the SEND SAVI device explicitly requires 206 the node sending those packets to prove address ownership by issuing 207 a secured NUD_NSOL which has to be answered by a secured NUD_NADV by 208 the probed node. 210 Bindings are refreshed periodically by means of secured NUD_NSOL 211 message issued by the SEND SAVI device, which had to be answered by a 212 valid NUD_NADV message by the node for which the binding exists. 214 Validated RADV messages are used to associate router authorization to 215 existing bindings (i.e., to an IPv6 address which is also associated 216 to a port). Packets with off-link source addresses are only 217 forwarded if they are received from a port associated to the IPv6 218 address of a router. 220 SEND SAVI needs to be protected against replay attacks, i.e., attacks 221 in which a secured SEND message is replayed by another node. As 222 discussed before, the SEND SAVI specification uses SEND messages to 223 create a binding between the address contained in the message (that 224 must be signed by a node possessing the private key associated to the 225 address) and the port through which the message is received. If an 226 attacker manages to obtain such a message from another node, for 227 example because the message was sent to the all-nodes multicast 228 address or because the attacker has subscribed to the Solicited Node 229 multicast address associated to a remote node, it could replay it 230 preserving the original signature. This may create an illegitimate 231 binding in the SEND SAVI device, or could be used to abort address 232 configuration at other node. While SEND provides some means to limit 233 the impact of the replay of ND messages, the emphasis for SEND anti- 234 replay protection is to limit to a short period of time the validity 235 of the ND information transmitted in the message, for example, the 236 relationship between an IPv6 address and a layer-2 address. Note 237 that the period must be long enough to assure that the information 238 sent by the legitimate sender is considered valid despite the 239 possible differences in clock synchronization between sender and 240 receiver(s). For example, with the values recommended by [RFC3971] 241 for TIMESTAMP_FUZZ and TIMESTAMP_DRIFT, a node receiving a DAD_NSOL 242 message would not discard replays of this message being received 243 within a period of approximately 2 seconds (more precisely, 2/0.99 244 seconds). The underlying assumption for SEND security is that even 245 if the message is replayed by another node during this period of 246 time, the information disseminated by ND is still the same. However, 247 allowing a node to replay a SEND message do have impact to SEND SAVI 248 operation, regardless the time elapsed since it was generated, since 249 it can create a new binding in a SEND SAVI device for the port to 250 which an illegitimate node attaches. As can be concluded, the 251 protection provided by SEND may be not enough for SEND SAVI. 253 SEND SAVI is designed to increase the protection against the replay 254 attacks compared to SEND. First, each node is required to connect to 255 the SEND SAVI topology through a different port to prevent 256 eavesdropping before entering to the SAVI protection perimeter. 257 Then, SEND SAVI bindings are updated only according to messages whose 258 dissemination can be restricted in the SEND SAVI topology without 259 interfering with normal SEND operation. The messages used by SEND 260 SAVI to create bindings are DAD_NSOL messages, for which SEND SAVI 261 limits its propagation to the ports through which a previous binding 262 for the same IPv6 address existed (see Section 3.3.2), and NUD_NADV 263 messages in response to a secured NUD_NSOL sent by the SEND SAVI 264 device only through the tested port. Finally, SEND SAVI filtering 265 rules prevent nodes from replaying messages generated by the SEND 266 SAVI devices themselves. Section 4.1 discusses in more detail the 267 protection provided by SEND SAVI against replay attacks. 269 2.3. SEND SAVI Protection Perimeter 271 In order to reduce computing and state requirements in SEND SAVI 272 devices, SEND SAVI devices can be deployed to form a "protection 273 perimeter" [I-D.ietf-savi-framework]. With this deployment strategy, 274 source address validation is performed only when packets enter in the 275 protected realm defined through the protection perimeter. The 276 perimeter is defined by appropriate configuration of the roles of 277 each port, which can be 'Validating' or 'Trusted': 278 o Validating ports (VPs) are those in which SEND SAVI filtering and 279 binding creation is performed. 280 o Trusted ports (TPs) are ports in which limited processing is 281 performed. Only SEND messages related with certificates, prefix 282 information and DAD operation are processed, in order to update 283 the state of the SEND SAVI device or the state related with any of 284 the Validating ports of the switch. 286 The following figure shows a typical topology involving trusted and 287 untrusted infrastructure. 289 +--+ +--+ +--+ +--+ 290 |H1| |H2| |H3| |R1| 291 +--+ +--+ +--+ +--+ 292 | | | | 293 +----------SEND SAVI PROTECTION PERIMETER-------------+ 294 | | | | | | 295 | +-1-----2-+ +-1-----2-+ | 296 | | SEND- | | SEND- | | 297 | | SAVI1 | | SAVI2 | | 298 | +-3--4----+ +--3--4---+ | 299 | | | +--------------+ | | | 300 | | +----------| |--------+ | | 301 | | | SWITCH-A | | | 302 | | +----------| | | | 303 | | | +--------------+ | | 304 | +-1--2----+ +-----1---+ | 305 | | SEND- | | SEND- | | 306 | | SAVI3 | | SAVI4 | | 307 | +-3-----4-+ +----4----+ | 308 | | | | | 309 +------------SEND SAVI PROTECTION PERIMETER-----------+ 310 | | | 311 +--+ +--+ +--+ 312 |R2| |H4| |H5| 313 +--+ +--+ +--+ 315 Trusted ports are used for connections with trusted infrastructure, 316 such as other SEND SAVI devices. Port 3 of SEND-SAVI1 and port 1 of 317 SEND-SAVI3, and port 4 of SEND-SAVI2 and port 1 of SEND-SAVI4 are 318 trusted because they connect two SAVI devices. Port 4 of SEND-SAVI1, 319 port 3 of SEND-SAVI2 and port 2 of SEND-SAVI3 are trusted because 320 they connect to SWITCH-A to which only trusted nodes are connected. 322 Validating ports are used for connection with non-trusted 323 infrastructure. Therefore, hosts are normally connected to 324 Validating ports. Routers are also recommended to be connected to 325 Validating ports, although they could also be attached to Trusted 326 ports. For a more detailed discussion on this, see Section 3.4. So, 327 in the figure above, ports 1 and 2 of SEND-SAVI1, port 1 of SEND- 328 SAVI2, port 4 of SEND-SAVI3 are Validating ports because they connect 329 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 host H5. 333 2.4. Special cases 335 Multi-subnet links: In some cases, a given subnet may have several 336 prefixes. This is supported by SEND SAVI as any port can support 337 multiple prefixes. 339 Multihomed hosts: A multihomed host is a host with multiple 340 interfaces. The interaction between SEND SAVI and multihomed hosts 341 is as follows. If the different interfaces of the host are assigned 342 different IP addresses and packets sent from each interface always 343 carry the address assigned to that interface as source address, then 344 from the perspective of a SEND SAVI device, this is equivalent to two 345 hosts with a single interface, each with an IP address. This is 346 supported by SAVI without need for additional considerations. If the 347 different interfaces share the same IP address or if the interfaces 348 have different addresses but the host sends packets using the address 349 of one of the interfaces through any of the interfaces, then SEND 350 SAVI does not directly support it. It would require either 351 connecting at least one interface of the multihomed host to a Trusted 352 port, or manually configure the SEND SAVI bindings to allow binding 353 the address of the multihomed host to multiple anchors 354 simultaneously. 356 Untrusted routers: One can envision scenarios where routers are 357 dynamically attached to a SEND SAVI network. A typical example would 358 be a mobile phone connecting to a SEND SAVI switch where the mobile 359 phone is acting as a router for other personal devices that are 360 accessing the network through it. In this case, the router does not 361 seem to directly fall in the category of Trusted infrastructure (as 362 if this was the case, it is likely that all devices would be 363 trusted), hence it cannot be connected to a trusted port and if it is 364 connected to a Validating port, the SEND SAVI switch would discard 365 all the packets containing an off-link source address coming from 366 that device. As a result, the default recommendation specified in 367 this specification does not support such a scenario. 369 3. SEND SAVI Specification 371 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 372 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 373 document are to be interpreted as described in [RFC2119]. 375 3.1. SEND SAVI Data Structures 377 The following three data structures are defined for SEND SAVI 378 operations: 380 SEND SAVI Data Base. The SEND SAVI function relies on state 381 information binding the source IPv6 address used in data packets to 382 the port through which the legitimate node connects. Such 383 information is stored in the SEND SAVI Data Base. The SEND SAVI Data 384 Base is populated with the contents of validated SEND messages. Each 385 entry contains the following information: 386 o IPv6 source address 387 o Binding anchor: port through which the packet was received 388 o Lifetime 389 o Status: TENTATIVE_DAD, TENTATIVE_NUD, VALID, TESTING_VP, 390 TESTING_VP' 391 o Alternative binding anchor: port from which a DAD_NSOL message or 392 any data packet has been received while a different port was 393 stored in the binding anchor for the address. 394 o Creation time: the value of the local clock when the entry was 395 firstly created 397 SEND SAVI Prefix list. SEND SAVI devices need to know which are the 398 link prefixes in order to identify local and off-link traffic. A 399 SEND SAVI device MUST support discovering this information from the 400 Prefix Information option [RFC4861] with the L set bit set of 401 validated RADV messages, either coming from Validating or Trusted 402 ports, as described in Section 3.3.2. The list of prefixes MAY also 403 be configured manually. This information is not specific to a given 404 port. The SEND SAVI Prefix list contains one entry per prefix in 405 use, as follows: 406 o Prefix: prefix included in a Prefix Information option 407 o Prefix lifetime: time in seconds that the prefix is valid. 408 Initially set to the Valid Lifetime value of the Prefix 409 Information option of a valid RADV message, or set to a value of 410 all one bits (0xffffffff), which represents infinity, if 411 configured manually. 413 When the SEND SAVI device boots, it MUST send a Router Solicitation 414 (RSOL) message, which does not need to be secured if the unspecified 415 address is used (see [RFC3971], sections 5.1.1 and 5.2.1). The SAVI 416 device SHOULD issue a RSOL message in case the prefix entry is about 417 to expire. 419 SEND SAVI Router list. SEND SAVI keeps a table with one entry for 420 each authorized router in use connected to a Validating port of the 421 SAVI device. A SEND SAVI device MUST support discovering this 422 information from a validated RADV message received from a Validating 423 port, addressed to the all-nodes multicast address or to the IPv6 424 address of the SEND SAVI device. If the SEND SAVI device uses RADV 425 messages to obtain this information, the SAVI device SHOULD issue a 426 RSOL through the Validating port through which the router is 427 reachable (according to the information stored in the SEND SAVI Data 428 Base) in case the entry is about to expire, in order to ensure that 429 the node is still a router. Alternatively, the list of routers MAY 430 be configured manually. The information stored in the table is the 431 following: 432 o IPv6 address of the Router. There MUST be an entry in the SEND 433 SAVI Data Base for the same IPv6 address. If the corresponding 434 entry in the SEND SAVI Data Base expires, the entry in this table 435 MUST be removed. 436 o Router lifetime: Lifetime associated with the default router in 437 units of seconds. Initially set to the Router Lifetime of a valid 438 RADV message. 440 3.2. SEND SAVI Device Configuration 442 In order to perform SEND SAVI operation, some basic parameters of the 443 SEND SAVI device have to be configured. Since a SEND SAVI device 444 operates as a SEND node to generate NUD_NSOL, RSOL or Certification 445 Path Solicitation (CPS) messages, 446 o the SEND SAVI device MUST be configured with a valid CGA address. 447 This CGA address SHOULD be a link-local address, to recover from 448 the following situation: the DAD_NSOL message used by a router 449 when it configures its link-local address has not been received, 450 so a binding has not been created for the router address. If the 451 port to which the router connects is a Validating port, the SEND 452 SAVI device cannot accept any packet, so no RADV issued by the 453 router will be accepted. Then, the SEND SAVI device may not 454 receive prefix configuration to configure any other address than a 455 link-local. However, if the SEND SAVI device configures a link- 456 local CGA, it can issue a NUD_NSOL to the router, and create the 457 binding according to the process described in Section 3.3.2. 459 When the SEND SAVI device configures this address, it MUST behave 460 as regular SEND node, i.e., using secured NSOL messages to perform 461 DAD, etc., in addition to fulfill the requirements stated for 462 regular IPv6 nodes [RFC6434]. 463 o the SEND SAVI device MUST be configured with at least one trust 464 anchor to validate the Certification Paths that is used to 465 validate router information. 466 o the SEND SAVI device MAY be configured with Certification Paths. 467 The alternative is obtaining them by means of issuing 468 Certification Path Solicitation messages, as detailed in the SEND 469 specification [RFC3971]. 471 In addition, the port role for each port of the SEND SAVI device 472 SHOULD be configured. The guidelines for this configuration are 473 specified in Section 3.4. Unconfigured ports MUST be labeled as 474 Validating ports; in this case performance may be degraded, as 475 discussed in [I-D.ietf-savi-framework]. 477 3.3. Traffic Processing 479 In this section we describe how packets are processed by a SEND SAVI 480 device. Behavior varies depending on if the packet belongs to local 481 or transit traffic. This is determined by checking if the prefix of 482 the source address is included in the SEND SAVI prefix list or the 483 unspecified address (local traffic), or not included in the SEND SAVI 484 prefix list (transit traffic). 486 3.3.1. Transit Traffic Processing 488 Transit traffic processing occurs as follows: 489 o If the transit traffic packet is received through a Trusted port, 490 the data packet is forwarded and no SAVI processing performed. 491 o If the transit traffic packet is received through a Validating 492 port, the packet is only forwarded if the port through which the 493 packet has been received is associated to the port of an IPv6 494 address for which an entry in the Router list exists. If transit 495 traffic is received from a Validating port which is not associated 496 to an entry in the SEND SAVI Router list, the SEND SAVI device 497 SHOULD discard the packets, and MAY send a RSOL message to the 498 all-routers multicast address to the port through which the packet 499 was received. 501 3.3.2. Local Traffic Processing 503 If the verification of the source address of a packet shows that it 504 belongs to local traffic, this packet is processed using the state 505 machine described in this section. SEND SAVI is designed to perform 506 source address validation for both hosts and routers, so in the 507 following description we refer to nodes. 509 For the rest of the section, the following assumptions hold: 510 o When it is stated that a secured NUD_NSOL message is issued by a 511 SEND SAVI device through a port P, this means the following: the 512 SEND SAVI device generates a NUD_NSOL message according to the 513 Neighbor Unreachability Detection procedure described in 514 [RFC4861], addressed to the IPv6 target address, which is the 515 source address of the packet triggering the procedure. This 516 message is secured by SEND as defined in [RFC3971]. The source 517 address used for issuing the NUD_NSOL message is the source 518 address of the SEND SAVI device. The message is sent only through 519 port P. 520 o When it is stated that a validated NUD_NADV message is received by 521 a SEND SAVI device, this means that: a SEND secured NUD_NADV 522 message has been received by the same port P through which the 523 corresponding NUD_NSOL message was issued, and the NUD_NADV 524 message has been validated according to [RFC3971] to prove 525 ownership for the IPv6 address under consideration and to prove 526 that it is a response for the previous NUD_NSOL message issued by 527 the SEND SAVI device (containing the same nonce value as the 528 NUD_NSOL message to which it answers). 530 We use VP to refer to a Validating port, and TP to refer to a Trusted 531 port. 533 The state machine is defined for a binding of a given source IPv6 534 address in a given SEND SAVI device. In the transitions considered, 535 packets described as inputs refer to the IPaddr IPv6 address 536 associated to the state machine. 538 The possible states for a given IPaddr are: NO_BIND, TENTATIVE_DAD, 539 TENTATIVE_NUD, VALID, TESTING_VP and TESTING_VP'. The NO_BIND state 540 represents that no binding exists for IPaddr; this is the state for 541 all addresses unless a binding is explicitly created. 543 The states can be classified into 'forwarding' states, i.e., states 544 in which packets received from the port associated to the IPv6 545 address are forwarded, and 'non-forwarding' states, i.e., states in 546 which packets different to the ones used for signaling are not 547 forwarded. VALID, TENTATIVE_DAD, TESTING_VP and TESTING_VP' are 548 forwarding states, and NO_BIND and TENTATIVE_NUD are non-forwarding 549 states. 551 The SEND SAVI device MUST join the Solicited Node Multicast group for 552 all the addresses whose state is other than NO_BIND. This is needed 553 to make sure that the SEND SAVI device receives DAD_NSOL messages 554 issued for those addresses. Note that it may not be enough to relay 555 on the Multicast Listener Discovery (MLD) messages being sent by the 556 node attached to a Validating port for which a binding for the 557 corresponding address exist, since the node may move and packets sent 558 to that particular Solicited Node Multicast group may no longer be 559 forwarded to the SEND SAVI device. 561 SEND SAVI devices MUST support the processing of validated 562 Certification Path Advertisement (CPA) messages, sent in reply to CPS 563 messages, to acquire certificates used to validate ND messages. In 564 order to process a CPA message received from a Validating port, an 565 entry for the source address of the message MUST exist in the SEND 566 SAVI Data Base. CPA messages received from Trusted ports are always 567 checked and processed. 569 SEND SAVI devices MUST use validated RADV messages to update the SEND 570 SAVI Prefix list and the SEND SAVI Router list. SEND SAVI devices 571 MAY only consider for updating these structures RADV messages 572 addressed to either its own IPv6 address or to the all-nodes 573 multicast address. Validated RADV messages received from Trusted 574 ports MUST be used to update the SEND SAVI Prefix and Router lists in 575 the SEND SAVI device. Validated RADV messages received from 576 Validating ports MUST be processed according to the specific rules 577 defined in the state machine for local traffic processing. In short, 578 RADV messages received from Validating ports are only processed for 579 updating the SEND SAVI Router and Prefix lists if a binding for the 580 source IPv6 address of the RADV message is in a forwarding state. 582 In order to determine which traffic is on-link and off-link, the SEND 583 SAVI device MUST support discovery of this information from the 584 Prefix Information option with the L set bit set of validated RADV 585 messages. In this case, at least one router MUST be configured to 586 advertise RADV messages containing a Prefix Information option with 587 the prefixes that the untrusted nodes can use as source addresses, 588 and the bit L set. An alternative to this is to configure manually 589 the SEND SAVI prefix list. 591 The state machine defined for SEND SAVI operation adheres to the 592 following design guidelines: 593 o The only events which trigger state changes from forwarding to 594 non-forwarding states and vice versa are the reception of 595 DAD_NSOL, DAD_NADV and NUD_NADV, or the expiration of a timer. 596 The other possible input to consider is 'any other packet', which 597 could generate changes to states belonging to the same forwarding 598 or non-forwarding class as the original state. In other words, 599 when 'any other packet' is received, the state cannot move from 600 being forwarding to non-forwarding and vice versa. A special case 601 of 'any other packet' is when validated RADV are received, which 602 can result in the update of the SEND SAVI Prefix or Router lists. 604 The reduced set of messages being able to trigger a change 605 simplifies the processing at SEND SAVI devices. 606 o DAD_NADV and NUD_NADV are only processed when they are a response 607 to a DAD_NSOL or a NUD_NSOL message. 608 o ND messages are only used by SEND SAVI devices if they are valid. 609 If any of the ND messages used by SEND SAVI is not valid, it is 610 discarded. SEND SAVI devices SHOULD assume that such messages 611 received from Trusted ports have been validated by other SEND SAVI 612 devices, so they SHOULD NOT attempt to validate them in order to 613 reduce processing load at the SEND SAVI device. 614 o The only messages the SEND SAVI device is required to generate 615 specifically per each source IP address are MLD and NUD_NSOL 616 messages. This also keeps the state machine simple. 617 o Well-behaved nodes are expected to initiate communication by 618 sending secured DAD_NSOL messages. The SEND SAVI state machine is 619 tailored to efficiently process these events. The reception of 620 other packet types without receiving previously validated DAD_NSOL 621 messages is assumed to be consequence of bad-behaving nodes or 622 infrequent events (such as packet loss, a change in the topology 623 connecting the switches, etc.) While a binding will ultimately be 624 created for nodes affected by such events, simplicity of the state 625 machine is prioritized over any possible optimization for these 626 cases. 627 o If a node has an address configured, and it can prove that it owns 628 this address, the binding is preserved regardless of any 629 indication that a binding for the same source address could be 630 configured in other SEND SAVI device. Bindings for the same 631 source address in two or more SEND SAVI devices may occur due to 632 several reasons, for example when a host moves (the two bindings 633 exist just for a short period of time), or when many nodes 634 generate the same address and the DAD procedure has failed. In 635 these infrequent cases, SEND SAVI preserves connectivity for the 636 resulting bindings. 638 We next describe how different inputs are processed depending on the 639 state of the binding of the IP address 'IPaddr'. Note that every ND 640 message is assumed to be validated according to SEND specification. 642 To facilitate the reader understanding the most relevant transitions 643 of the SEND SAVI state machine, a simplified version, which does not 644 contain every possible transition, 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 Simplified SEND SAVI state machine 694 NO_BIND 696 When the node is in this state, there are no unresolved NUD_NSOL 697 messages generated by SEND SAVI or DAD_NSOL propagated to any 698 Validating port, so the only relevant inputs are DAD_NSOL messages 699 coming either from a Validating port (VP) or Trusted port (TP), or 700 any packet other than DAD_NSOL coming from VP or TP. There are no 701 timers configured for this state. 702 o If a DAD_NSOL message is received from a Validating port VP, the 703 SEND SAVI device checks for its validity. If the message is not 704 valid, it MUST be discarded. If the message is valid, then the 705 SEND SAVI device forwards this message to all appropriate Trusted 706 ports (the subset of Trusted ports which belong to the forwarding 707 layer-2 topology, with the restrictions imposed by the MLD 708 snooping mechanism, if applied). DAD_NSOL messages are not sent 709 through any of the ports configured as Validating Ports. The SEND 710 SAVI device sets the LIFETIME to TENT_LT, stores all the 711 information required for future validation of the corresponding 712 DAD_NADV message (such as the nonce of the message), creates a new 713 entry in the SEND SAVI Data Base for IPaddr, sets BINDING_ANCHOR 714 to VP, and changes the state to TENTATIVE_DAD. Creation time is 715 set to the current value of the local clock. 716 Note that in this case it is not possible to check address 717 ownership by sending a NUD_NSOL because while the node is waiting 718 for a possible DAD_NADV its address is in tentative state and the 719 node cannot respond to NSOL messages [RFC4862]. 720 o If any packet other than a DAD_NSOL is received through a 721 Validating port VP, the SEND SAVI device issues a secured NUD_NSOL 722 through port VP. The SEND SAVI device sets the LIFETIME to 723 TENT_LT. The SEND SAVI device creates a new entry in the SEND 724 SAVI Data Base for IPaddr, sets BINDING_ANCHOR to VP, and the 725 state is changed to TENTATIVE_NUD. Creation time is set to the 726 current value of the local clock. The SAVI device MAY discard the 727 packet while the NUD procedure is being executed, or MAY store it 728 in order to send it if the next transitions are (strictly) 729 TENTATIVE_NUD and then VALID. 730 o If a DAD_NSOL message containing IPaddr as the target address is 731 received through a Trusted port, the SEND SAVI device SHOULD 732 assume that the message has been validated. This message MUST NOT 733 be forwarded through any of the Validating ports but it is sent 734 through the proper Trusted ports (as defined by the switch 735 behavior that will depend on whether it performs MLD snooping or 736 not). The state is not changed. 737 o Any packet other than a DAD_NSOL received from a Trusted port is 738 forwarded to its destination. This packet is assumed to come from 739 a SEND SAVI device that has securely validated the binding 740 according to SEND SAVI rules (unless the SEND SAVI perimeter has 741 been breached). The state is not changed. 743 TENTATIVE_DAD 745 To arrive to this state, the SEND SAVI device has received a 746 validated DAD_NSOL coming from the BINDING_ANCHOR port and it has 747 forwarded it to the appropriate TPs. The relevant events occurring 748 in this state are: the reception of a DAD_NADV message from a TP, a 749 DAD_NSOL message from the BINDING_ANCHOR port, other Validating port 750 or TP, a data packet from the BINDING_ANCHOR port, and the expiration 751 of the LIFETIME timer initiated when the DAD_NSOL was received at 752 port the BINDING_ANCHOR port. 753 o If a DAD_NADV is received from a Trusted port, the SEND SAVI 754 device SHOULD assume that the message has been validated. The 755 reception of a valid DAD_NADV message indicates that the binding 756 cannot be configured for the BINDING_ANCHOR port. The state is 757 changed to NO_BIND, and the LIFETIME cleared. 758 o If a DAD_NSOL is received from a Trusted port, the SEND SAVI 759 device SHOULD assume that the message has been validated. The 760 reception of a valid DAD_NSOL indicates that a node connected to 761 another SEND SAVI device may be trying to configure the same 762 address at the same time. The DAD_NSOL message is forwarded to 763 the BINDING_ANCHOR port, so that the node at this port will not 764 configure the address, as stated in [RFC4862]. The DAD_NSOL 765 message is also forwarded to all appropriate Trusted ports. Then, 766 the LIFETIME is cleared, and the state is changed to NO_BIND. 767 o Any packet other than a validated DAD_NSOL or DAD_NADV received 768 from a Trusted port is forwarded to its destination. This packet 769 is assumed to come from a SEND SAVI device that has securely 770 validated the binding according to SEND SAVI rules (unless the 771 SEND SAVI perimeter has been breached). The state is not changed. 772 o If a DAD_NSOL is received from a Validating port VP' different the 773 BINDING_ANCHOR port, the SEND SAVI device checks for its validity. 774 If the message is not valid, it MUST be discarded. The reception 775 of a valid DAD_NSOL from port VP' indicates that a node connected 776 to VP' may be trying to configure the same address at the same 777 time. The DAD_NSOL message is forwarded to the BINDING_ANCHOR 778 port, so that the node at this port will not configure the 779 address, as stated in [RFC4862]. The DAD_NSOL message is also 780 forwarded to all appropriate Trusted ports. Then, the 781 BINDING_ANCHOR is set to VP' (through which the DAD_NSOL message 782 was received), the LIFETIME is set to TENT_LT, and the state 783 remains in TENTATIVE_DAD. 784 o Any other packet than a validated DAD_NSOL is received from a 785 Validating port VP' different from the BINDING_ANCHOR port is 786 discarded. The state is not changed. 787 o If a DAD_NSOL is received from the BINDING_ANCHOR port, the SEND 788 SAVI device checks for its validity. If the message is not valid, 789 it MUST be discarded. If the DAD_NSOL message is valid, the 790 LIFETIME is set to TENT_LT, and the state remains in 791 TENTATIVE_DAD. 792 o If any packet other than a DAD_NSOL is received from the 793 BINDING_ANCHOR port, it is assumed that the node has configured 794 its address, although it has done it in less time than expected by 795 the SEND SAVI device (less than TENT_LT). Since the node proved 796 address ownership by means of the validated DAD_NSOL message, the 797 LIFETIME is set to DEFAULT_LT, and the state is changed to VALID. 798 A particular case occur if the packet received is a RADV message. 799 The RADV message is checked for validity, and it is discarded if 800 it is not valid (and the LIFETIME is not changed, and the state 801 remains in TENTATIVE_DAD). If it is valid, the message is 802 forwarded to the appropriate Trusted ports. In addition, either 803 an entry for this IPv6 source address in the SEND SAVI Router List 804 is created, or the LIFETIME of an existing entry is updated with 805 the information received in this message. The SEND SAVI Prefix 806 list MUST also be updated according to the content of the RADV 807 message. The SEND SAVI device MAY not process (although it MUST 808 forward them) RADV messages addressed to destinations other than 809 the all-nodes multicast address or to the IPv6 address of the SEND 810 SAVI device. 811 o If LIFETIME expires, it is assumed that no other node has 812 configured this address. Therefore, the Validating port VP 813 (currently stored in the BINDING_ANCHOR) could be bound to this 814 IPv6 address. The LIFETIME is set to DEFAULT_LT, and the state is 815 changed to VALID. 817 VALID 819 To arrive to this state, successful validation of address ownership 820 has been completed and a binding for IPaddr has been created. 821 Relevant transitions for this state are triggered by the reception of 822 DAD_NSOL from the BINDING_ANCHOR port, other Validating port or a TP, 823 and any packet other than DAD_NSOL from other validating port than 824 the BINDING_ANCHOR or a TP. The expiration of LIFETIME is also 825 relevant to trigger a check for address ownership for the node at the 826 BINDING_ANCHOR port. 827 o If a DAD_NSOL with IPaddr as source address is received through 828 the BINDING_ANCHOR port, the message is checked for validity. If 829 the message is not valid, it MUST be discarded. If the message is 830 valid, it is forwarded to the appropriate Trusted ports. The 831 LIFETIME is set to TENT_LT and the state is changed to 832 TENTATIVE_DAD. 833 o Any packet other than a DAD_NSOL containing IPaddr as a source 834 address arriving from the BINDING_ANCHOR port is forwarded 835 appropriately. The state is not changed. 836 A particular case occur if the packet received is a RADV message. 837 The RADV message is checked for validity, and it is discarded if 838 it is not valid. If it is valid, the message is forwarded to the 839 appropriate Trusted ports. In addition, either an entry for this 840 IPv6 source address in the SEND SAVI Router List is created, or 841 the lifetime of an existing entry is updated with the information 842 received in this message. The SEND SAVI Prefix list MUST also be 843 updated according to the content of the RADV message. The SEND 844 SAVI device MAY not process (although it MUST forward) RADV 845 messages addressed to destinations other than the all-nodes 846 multicast address or to the IPv6 address of the SEND SAVI device. 847 o If a DAD_NSOL with IPaddr as source address is received through a 848 Trusted port, the SEND SAVI device SHOULD assume that the message 849 has been validated. The message is forwarded to VP. The LIFETIME 850 is set to TENT_LT, a secured NUD_NSOL message is sent to IPaddr 851 through VP and the state is changed to TESTING_VP. 852 o If any packet other than a DAD_NSOL with IPaddr as source address 853 is received through a Trusted port, the packet is forwarded to VP 854 and to other appropriate Trusted ports. A secured NUD_NSOL is 855 sent to the BINDING_ANCHOR port, the LIFETIME is set to TENT_LT, 856 and the state is changed to TESTING_VP. 857 o If a DAD_NSOL packet with IPaddr as source address is received 858 through a Validating Port VP' (VP' different from the current 859 BINDING ANCHOR), the SEND SAVI device checks for its validity. If 860 the message is not valid, it MUST be discarded. If the message is 861 valid, the message is forwarded to the BINDING_ANCHOR port. In 862 addition, a secured NUD_NSOL is sent to BINDING_ANCHOR port, the 863 ALTERNATIVE BINDING ANCHOR is set to port VP' (for future use if 864 the node at VP' is finally selected), the LIFETIME is set to 865 TENT_LT, and the state is changed to TESTING_VP'. 866 o If any packet other than a DAD_NSOL with IPaddr as source address 867 is received from a Validating port VP', different from the current 868 BINDING_ANCHOR for this binding, VP, the packet is discarded. The 869 SEND SAVI device MAY issue a secured NUD_NSOL through the 870 BINDING_ANCHOR port, store VP' in the ALTERNATIVE BINDING ANCHOR 871 for possible future use, set the LIFETIME to TENT_LT, and change 872 the state to TESTING_VP'. An alternative to this behavior is that 873 the SEND SAVI device MAY not do anything (in this case, the state 874 would eventually change after a maximum DEFAULT_LT time, if the 875 node at VP does not respond to a NUD_NSOL at TESTING_VP, the state 876 is moved to NO_BIND). Then a packet arriving from VP' would 877 trigger a process that may end up with binding for the node 878 connecting to VP'. 879 o If LIFETIME expires, a secured NUD_NSOL message is sent through 880 the BINDING_ANCHOR port to IPaddr, the LIFETIME is set to TENT_LT, 881 and the state is changed to TESTING_VP. In the TESTING_VP state 882 packets are still being forwarded until the timer expires without 883 receiving a NUD_NADV. 885 TESTING_VP 886 When the SEND SAVI device enters in the TESTING_VP state, the current 887 Validating port is under check through a secured NUD_NSOL message 888 generated by the SEND SAVI device. While testing, packets from the 889 current Validating port are forwarded. Packets coming from Trusted 890 ports are also forwarded. The relevant events for this state are the 891 reception of a NUD_NADV message from VP, the reception of a DAD_NSOL 892 message from VP, VP' or TP, the reception of any packet other than 893 the previous cases from VP, VP' or TP, and the expiration of the 894 timer associated to the reception of NUD_NADV. 895 o If a NUD_NADV packet is received from VP, the SEND SAVI device 896 checks for its validity. If the message is not valid, it MUST be 897 discarded. If the message is valid, the LIFETIME is changed to 898 DEFAULT_LT, and the state is changed to VALID. The message is not 899 forwarded to any other port. 900 o If a DAD_NSOL message is received from 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 the 903 appropriate Trusted ports, the LIFETIME is set to DEFAULT_LT, and 904 the state is changed to TENTATIVE_DAD. 905 o If a RADV packet is received from VP, the message is checked for 906 validity, and it is discarded if it is not valid. If it is valid, 907 the message is forwarded appropriately. Either an entry for this 908 IPv6 source address in the SEND SAVI Router List is created, or 909 the lifetime of an existing entry is updated with the information 910 received in this message. The SEND SAVI Prefix list MUST also be 911 updated according to the content of the RADV message. The SEND 912 SAVI device MAY ignore and discard RADV messages addressed to 913 destinations other than the all-nodes multicast address or to the 914 IPv6 address of the SEND SAVI device. The state remains in 915 TESTING_VP. Note that if the timeout expires later, while still 916 in the TESTING_VP state, the entry of the SEND SAVI Router List 917 will also be removed. 918 o Any packet other than DAD_NSOL or NUD_NADV containing IPaddr as a 919 source address arriving from the BINDING_ANCHOR port is forwarded. 920 Neither the LIFETIME nor the state are changed. 921 o If a DAD_NSOL packet is received from a Trusted port, the SEND 922 SAVI device SHOULD assume that the message has been validated. 923 The message is forwarded to VP and the appropriate Trusted ports. 924 Neither the LIFETIME nor the state are changed. The node at the 925 BINDING_ANCHOR port is under check: if it still is at this port, 926 it should answer with a NUD_NADV, and also with a DAD_NADV. If it 927 is not there, neither the NUD_NADV nor the DAD_NADV will be 928 received, the timer will expire and the local state will move to 929 NO_BIND. 930 o If a packet other than a DAD_NSOL arrives from a Trusted port, the 931 packet is forwarded. Neither the LIFETIME nor the state are 932 changed. 934 o If a DAD_NSOL is received from a Validating port VP' other than 935 the current BINDING_ANCHOR port, the SEND SAVI device checks for 936 its validity. If the message is not valid, it MUST be discarded. 937 If it is valid, the message is forwarded to the BINDING_ANCHOR 938 port and to the appropriate Trusted ports. In addition, a secured 939 NUD_NSOL is sent to the BINDING_ANCHOR port, the ALTERNATIVE 940 BINDING ANCHOR is set to VP' (for future use if the node at VP' is 941 finally selected), the LIFETIME is set to TENT_LT, and the state 942 is changed to TESTING_VP'. 943 o Any other packet received from a Validating port VP' other than 944 the BINDING_ANCHOR port is discarded. This may occur because the 945 node has moved but have not issued a DAD_NSOL or the DAD_NSOL 946 message has been lost. The state will eventually move to NO_BIND, 947 and then the packets sent from VP' will trigger the creation of 948 the binding for VP'. 949 o If the LIFETIME expires, the LIFETIME is cleared and the state is 950 changed to NO_BIND. 952 TESTING_VP' 954 To arrive to this state an indication that a node at VP' different 955 from the BINDING_ANCHOR port wants to send data with IPaddr as source 956 address occurred while a binding existed for VP. The port VP' which 957 triggered the change of the state to TESTING_VP' was stored at the 958 ALTERNATIVE_BINDING_ACNHOR, so that it can be retrieved if the node 959 at VP' is determined as the legitimate owner of IPaddr. The SEND 960 SAVI device has issued a NUD_NSOL to IPaddr through the 961 BINDING_ANCHOR port. The relevant events that may occur in this case 962 are the reception of a NUD_NADV from port VP (the BINDING_ANCHOR 963 port), the reception of DAD_NSOL from VP, VP', TP and VP" (VP" 964 different from VP and VP'), the reception of any other packet from 965 VP, VP', TP or VP", and the expiration of the timer. 966 o If a NUD_NADV is received from the BINDING_ANCHOR port, the SEND 967 SAVI device checks for its validity. If the message is not valid, 968 it MUST be discarded. The reception of a valid NUD_NADV indicates 969 that the node at VP is defending its address. The BINDING_ANCHOR 970 in use is kept, the LIFETIME is set to DEFAULT_LT, and the state 971 is changed to VALID. 972 o If a DAD_NSOL is received from the BINDING_ANCHOR port, the SEND 973 SAVI device checks for its validity. If the message is not valid, 974 it MUST be discarded. If the message is valid, it is forwarded to 975 VP' (the port stored in the ALTERNATIVE_BINDING_ANCHOR). The 976 BINDING_ANCHOR in use is kept, the LIFETIME is set to TENT_LT and 977 the state is changed to TENTATIVE_DAD. When the DAD_NSOL message 978 is received by the node at VP', this node is expected to 979 unconfigure its address. 981 o If a RADV message is received from the BINDING_ANCHOR port, it is 982 checked for validity, and it is discarded if it is not valid. If 983 it is valid, the message is forwarded appropriately. Either an 984 entry for this IPv6 source address in the SEND SAVI Router List is 985 created, or the lifetime of an existing entry is updated with the 986 information received in this message. The SEND SAVI Prefix list 987 MUST also be updated according to the content of the RADV message. 988 The SEND SAVI device MAY ignore and discard RADV messages 989 addressed to destinations other than the all-nodes multicast 990 address or to the IPv6 address of the SEND SAVI device. The state 991 remains in TESTING_VP' and the LIFETIME is left unchanged. Note 992 that if the timeout expires later, while still in the TESTING_VP' 993 state, the entry of the SEND SAVI Router List will also be 994 removed. 995 o Any packet other than a validated DAD_NSOL, a validated NUD_NADV 996 or a validated RADV coming from the BINDING_ANCHOR port, is 997 forwarded, and the state is not changed. 998 o If a DAD_NSOL is received from the port stored in the 999 ALTERNATIVE_BINDING_ANCHOR, the SEND SAVI device checks for its 1000 validity. If the message is not valid, it MUST be discarded. If 1001 the message is valid, it is forwarded to the BINDING_ANCHOR port. 1002 The BINDING_ANCHOR and the ALTERNATIVE BINDING ANCHOR are kept, 1003 the LIFETIME is set to DEFAULT_LT, and the state is not changed. 1004 o Any packet other than a DAD_NSOL coming from the 1005 ALTERNATIVE_BINDING_ANCHOR port is discarded, and the state is not 1006 changed. 1007 o If a DAD_NSOL is received from port VP", different from 1008 BINDING_ANCHOR and the ALTERNATIVE_BINDING_ANCHOR ports, the SEND 1009 SAVI device checks for its validity. If the message is not valid, 1010 it MUST be discarded. If the message is valid, it is forwarded to 1011 the BINDING_ANCHOR and the ALTERNATIVE_BINDING_ANCHOR ports. The 1012 node at ALTERNATIVE BINDING ANCHOR port is expected to unconfigure 1013 its address if the message triggering the transition to this state 1014 was a DAD_NSOL message received from the 1015 ALTERNATIVE_BINDING_ANCHOR port (and not any other packet). The 1016 state remains in TESTING_VP' although VP" is stored in the 1017 ALTERNATIVE_BINDING_ANCHOR for future use if the node at VP" is 1018 finally selected. The LIFETIME is not changed. 1019 o Any packet other than a DAD_NSOL received from port VP" is 1020 discarded and does not affect to the state. 1021 o If a DAD_NSOL is received from a Trusted port, the SEND SAVI 1022 device SHOULD assume that the message has been validated. Then, 1023 the message is forwarded to the BINDING_ANCHOR and the 1024 ALTERNATIVE_BINDING_ANCHOR ports and other appropriate Trusted 1025 ports. The LIFETIME is left unchanged and the state is changed to 1026 TESTING_VP. The node at the ALTERNATIVE_BINDING_ANCHOR port is 1027 expected to unconfigure its address if the packet triggering the 1028 transition to this state was a DAD_NSOL message received from the 1029 ALTERNATIVE_BINDING_ANCHOR port. 1030 o Any packet other than a DAD_NSOL coming from a Trusted port is 1031 forwarded appropriately, but the state is not changed. 1032 o If LIFETIME expires, it is assumed that the node for which the 1033 binding existed is no longer connected through the BINDING_ANCHOR 1034 port. Therefore, the BINDING_ANCHOR is set to the 1035 ALTERNATIVE_BINDING_ANCHOR port value. The LIFETIME is set to 1036 DEFAULT_LT and the state is changed to VALID. 1038 TENTATIVE_NUD 1040 To arrive to this state, a data packet has been received through the 1041 BINDING_ANCHOR port without any existing binding in the SEND SAVI 1042 device. The SEND SAVI device has sent a NUD_NSOL message to the 1043 BINDING_ANCHOR port. The relevant events for this case are the 1044 reception of a NUD_NADV from port the BINDING_ANCHOR port; the 1045 reception of DAD_NSOL from the BINDING_ANCHOR port, other VP 1046 different from the BINDING_ANCHOR port, or a TP; and the reception of 1047 any packet other than DAD_NSOL and NUD_NADV from the BINDING_ANCHOR 1048 port, and other than DAD_NSOL for other VP different than the 1049 BINDING_ANCHOR port, or TP. In addition, the LIFETIME may expire. 1050 o If a NUD_NADV message is received through the BINDING_ANCHOR port, 1051 the SEND SAVI device checks for its validity. If the message is 1052 not valid, it MUST be discarded. If the message is valid, the 1053 LIFETIME is set to TENT_LT, and the state is changed to VALID. 1054 The message is not forwarded to any port. 1055 o If a DAD_NSOL message is received through the BINDING_ANCHOR port, 1056 the SEND SAVI device checks for its validity. If the message is 1057 not valid, it MUST be discarded. If the message is valid, it is 1058 forwarded to the appropriate Trusted ports, the LIFETIME is set to 1059 TENT_LT and the state is changed to TENTATIVE_DAD. 1060 o Any packet other than NUD_NADV or DAD_NSOL received through the 1061 BINDING_ANCHOR port is discarded. 1062 o If a DAD_NSOL message is received through port VP' different from 1063 the BINDING_ANCHOR port, the SEND SAVI device checks for its 1064 validity. If the message is not valid, it MUST be discarded. If 1065 the message is valid, it is forwarded to the appropriate Trusted 1066 ports, the LIFETIME is set to TENT_LT, the BINDING_ANCHOR is set 1067 to VP', and the state is changed to TENTATIVE_DAD. 1068 o Any packet other than DAD_NSOL received through port VP' MUST NOT 1069 be forwarded unless the next state for the binding is VALID. The 1070 packets received MAY be discarded or MAY be stored for being sent 1071 if the state changes later to VALID. The state is left unchanged. 1072 o If a DAD_NSOL message is received through a Trusted port, the SEND 1073 SAVI device SHOULD assume that the message has been validated. 1074 The message is forwarded to the BINDING_ANCHOR port, and the state 1075 is left unchanged. 1077 o Any other packet received from a Trusted port is forwarded 1078 appropriately. This packet may come from a SEND SAVI device that 1079 has securely validated the attachment of the node to its 1080 Validating port according to SEND SAVI rules. The state is left 1081 unchanged. 1082 o If LIFETIME expires, the LIFETIME is cleared and the state is 1083 changed to NO_BIND. 1085 3.4. SEND SAVI Port Configuration Guidelines 1087 The detailed guidelines for port configuration in SEND SAVI devices 1088 are: 1089 o Ports that are connected to another SEND SAVI devices SHOULD be 1090 configured as Trusted ports. Not doing so will increase 1091 significantly the CPU time, memory consumption and signaling 1092 traffic due to SEND SAVI validation, in both the SEND SAVI devices 1093 and the node whose address is being validated. 1094 o Ports connected to hosts SHOULD be configured as Validating ports. 1095 Not doing so will allow the host connected to that port to send 1096 packets with spoofed source address. 1097 o No more than one host SHOULD be connected to each port. Not doing 1098 so will allow hosts to generate packets with the same source 1099 address as the other hosts connected to the same port, and will 1100 allow performing replaying attacks as described in Section 4.1. 1101 o Ports connected to routers SHOULD be configured as Validating 1102 ports. However, the SEND SAVI specification also allows the 1103 routers to be connected to Trusted ports, as they are assumed to 1104 be part of the trusted infrastructure. When connected through a 1105 Trusted port, a router can generate traffic with any source 1106 address, even those belonging to the link, while when connected 1107 through a Validating port it can only send traffic using off-link 1108 source addresses, or its own source addresses. When routers are 1109 connected to Validating ports, authorization for the routing 1110 function is bound to the binding anchor of the router itself, 1111 instead of being bound to a port configured in a switch. 1112 o Ports connected to a chain of one or more legacy switches that 1113 have other SEND SAVI devices but had no routers or hosts attached 1114 to them SHOULD be configured as Trusted ports. Not doing so will 1115 significantly increase the memory consumption in the SEND SAVI 1116 devices and increase the signaling traffic due to SEND SAVI 1117 validation. 1119 3.5. VLAN Support 1121 In the case the SEND SAVI device is a switch that supports customer 1122 VLANs [IEEE.802-1Q.2005], the SEND SAVI implementation MUST behave as 1123 if there was one SEND SAVI process per customer VLAN. The SEND SAVI 1124 process of each customer VLAN will store the binding information 1125 corresponding the nodes attached to that particular customer VLAN. 1127 3.6. Protocol Constants 1129 TENT_LT is 500 milliseconds. 1131 DEFAULT_LT is 5 minutes. 1133 4. Security Considerations 1135 SEND SAVI is defined to operate only with validated SEND messages. 1136 The interaction in a mixed scenario comprising SEND and non-SEND 1137 devices should be addressed in other document. However, nodes MUST 1138 NOT assume that all SEND messages received from a SEND SAVI device 1139 are validated, since these devices only validate the messages 1140 strictly required for SEND SAVI operation. Among the number of 1141 messages which are not validated, we can name NUD_NSOL messages 1142 generated by other nodes and its responses, or RSOL messages. 1144 SEND SAVI improves protection compared to conventional SAVI, as a 1145 result of the increased ability of SEND nodes to prove address 1146 ownership. 1148 A critical security consideration regarding to SEND SAVI deals with 1149 the need of proper configuration of the roles of the ports in a SEND 1150 SAVI deployment scenario. Regarding to security, the main 1151 requirement is that ports defining the protected perimeter SHOULD be 1152 configured as Validating ports. Not doing so will generate security 1153 breaches through which an attacker could send packets using any 1154 source address, regardless of the bindings established in other SEND 1155 SAVI devices. 1157 4.1. Protection Against Replay Attacks 1159 One possible concern about SEND SAVI is its behavior when an attacker 1160 tries to forge the identity of a legitimate node by replaying SEND 1161 messages used by the SEND SAVI specification. An attacker could 1162 replay any of these messages to interfere with SEND SAVI operation. 1163 For example, it could replay a DAD_NSOL message to abort the 1164 configuration of an address for a legitimate node and to gain the 1165 right to use the address for DEFAULT_LT seconds. We now discuss the 1166 risks of such replay attacks and the protection provided by SEND 1167 SAVI. 1169 To perform a security analysis of such SEND SAVI reply attacks, we 1170 have to consider two different cases: 1172 o When the SEND message replayed is used to create or update binding 1173 information for SEND SAVI, since the port through which this 1174 message is received is key to SEND SAVI operation. SEND SAVI 1175 creates and maintains bindings as a result of the reception of 1176 DAD_NSOL messages and of the exchange of NUD_NSOL/NUD_NADV 1177 messages. 1178 o When the SEND message replayed does not result in the update of 1179 binding information for SEND SAVI, and thus it is not related to 1180 the specific port through which it was received. Such situations 1181 are the reception of CPA messages containing certificates, and the 1182 processing of an RADV message coming from a Trusted port, which 1183 can be used in SEND SAVI to populate the SEND SAVI Prefix list. 1184 In this two cases, the security risks are equivalent to those of 1185 SEND operation, i.e., we can consider that the information will 1186 not be changed by its legitimate sender for the time during which 1187 the SEND specification allows replaying (which depends on the 1188 values of TIMESTAMP_FUZZ and TIMESTAMP_DRIFT, [RFC3971]). 1189 A special case is the processing of a RADV message coming from a 1190 Validating port. Although part of the information obtained (the 1191 router condition of the node connecting to the port) is 1192 (indirectly) associated to the binding, the replay of this RADV 1193 message does not provide an advantage to an attacker. This is so 1194 because SEND SAVI requires a binding to exist (between the IPv6 1195 address and the port of the SEND SAVI device) prior to consider 1196 the RADV message, so protecting the creation of the binding also 1197 protects the ability of an attacker to become a router. 1199 We now discuss the protection provided by SEND SAVI against the 1200 replay of messages used to create or update bindig information, i.e., 1201 the replay of DAD_NSOL and NUD_NSOL/NUD_NADV messages. In this case, 1202 protection results from requiring a one-to-one correspondence between 1203 SEND SAVI ports and nodes connected to the link (see Section 3.4), 1204 and careful filtering when transmitting the messages involved in SEND 1205 SAVI operation. Note that if many nodes are attached to the same 1206 SEND SAVI Validating port, i.e., the one-to-one correspondence is 1207 violated, any of them can generate packets with the legitimate source 1208 address of any other node, defeating the source address validation of 1209 SEND SAVI. Moreover, any of these nodes may interfere with the 1210 communication capacity of the legitimate node in many ways, as it is 1211 considered next. Assume two nodes H1 and H2 are connected to switch 1212 A, not enabled for SEND SAVI operation, which accesses to the SEND 1213 SAVI protection perimeter through port 1. H1 is switched off. Node 1214 H2 knows IP1, the address H1 will configure when it switches on, so 1215 H2 subscribes to the Solicited Node of IP1 address. Although H2 1216 cannot generate a valid SEND message for H1's address, when H1 1217 switches on H2 receives the DAD_NSOL issued by H1, and replays it in 1218 a time shorter than the time required to invalidate the SEND message. 1219 When H1 receives a valid DAD_NSOL message for its own address, it 1220 stops its address configuration process for IP1. The SEND SAVI 1221 device receives this second message, but it has no way to know that 1222 the message has been issued by a different node, so it forwards it. 1223 After TENT_LT time, the binding is configured in the SEND SAVI 1224 device, and H2 can use IP1 for DEFAULT_LT time. Alternatively, the 1225 SEND SAVI binding could also be configured in a different port, 1226 provided that there exists a host H3 connected to that port which 1227 receives from H2 (using a tunnel, to prevent the processing from a 1228 SEND SAVI device) the DAD_NSOL message legitimately issued by H1. 1230 +---------+ | 1231 | SEND | | +--+ 1232 | SAVI 2--------------|H3| 1233 +----1----+ | +--+ 1234 | | 1235 ----SEND SAVI PROTECTION PERIMETER---+ 1236 | 1237 +---------+ 1238 |SWITCH A | 1239 +---------+ 1240 | | 1241 +--+ +--+ 1242 |H1| |H2| 1243 +--+ +--+ 1245 If a one-to-one correspondence among ports and hosts is honored, the 1246 traffic generated by a node cannot be captured before arriving to the 1247 SEND SAVI protection perimeter. In this case, the protection 1248 provided by SEND SAVI is the following: 1249 o To prevent the replay of DAD_NSOL messages, SEND SAVI devices only 1250 forward them to ports for which a binding to the address being 1251 tested by the DAD_NSOL message existed. Therefore, it is not 1252 enough for an attacker to subscribe to a Solicited Node address to 1253 receive DAD_NSOL messages sent to that address, but the attacker 1254 needs to generate a valid DAD_NSOL message associated to the 1255 address for which the binding is being tested, which is deemed 1256 unfeasible [RFC3971]. 1258 4.2. Protection Against Denial of Service Attacks 1260 The attacks against the SEND SAVI device basically consist of making 1261 the SEND SAVI device consume its resources until it runs out of them. 1262 For instance, a possible attack would be to send packets with 1263 different source addresses, making the SEND SAVI device create state 1264 for each of the addresses and waste memory. At some point, the SEND 1265 SAVI device runs out of memory and needs to decide how to react. The 1266 result is that some form of garbage collection is needed to prune the 1267 entries. When the SEND SAVI device runs out of the memory allocated 1268 for the SEND SAVI Data Base, it is RECOMMENDED that it create new 1269 entries by deleting the entries with a higher Creation time. This 1270 implies that older entries are preserved and newer entries overwrite 1271 each other. In an attack scenario where the attacker sends a batch 1272 of data packets with different source addresses, each new source 1273 address is likely to rewrite another source address created by the 1274 attack itself. It should be noted that entries are also garbage 1275 collected using the DEFAULT_LT, which is updated by NUD_NSOL/NUD_NADV 1276 exchange. The result is that in order for an attacker to actually 1277 fill the FCFS SAVI Data Base with false source addresses, it needs to 1278 continuously answer to NUD_NSOL for all the different source 1279 addresses so that the entries grow old and compete with the 1280 legitimate entries. The result is that the cost of the attack is 1281 highly increased for the attacker. 1283 In addition, it is also RECOMMENDED that a SEND SAVI device reserves 1284 a minimum amount of memory for each available port (in the case where 1285 the port is used as part of the L2 anchor). The recommended minimum 1286 is the memory needed to store 4 bindings associated to the port. The 1287 motivation for this recommendation is as follows. An attacker 1288 attached to a given port of a SEND SAVI device may attempt to launch 1289 a DoS attack towards the SEND SAVI device by creating many bindings 1290 for different addresses. It can do so, by sending DAD_NSOL for 1291 different addresses. The result is that the attack will consume all 1292 the memory available in the SEND SAVI device. The above 1293 recommendation aims to reserve a minimum amount of memory per port, 1294 so that nodes located in different ports can make use of the reserved 1295 memory for their port even if a DoS attack is occurring in a 1296 different port. 1298 As the SEND SAVI device may store data packets while the address is 1299 being verified, the memory for data packet storage may also be a 1300 target of DoS attacks. The effects of such attacks may be limited to 1301 the lack of capacity to store new data packets. The effect of such 1302 attack will be then that data packets will be dropped during the 1303 verification period. A SEND SAVI device MUST limit the amount of 1304 memory used to store data packets, allowing the other functions to 1305 have available memory even in the case of an attacks such those 1306 described above. 1308 It is worth to note that the potential of Denial of Service attacks 1309 against the SEND SAVI network is increased due to the use of costly 1310 cryptographic operations in order to validate the address of the 1311 nodes. An attacker could generate packets using new source addresses 1312 in order to make the closest SEND SAVI device spend CPU time to 1313 validate DAD_NSOL messages or to generate a secure NUD_NSOL. This 1314 attack can be used to drain CPU resources of SEND SAVI devices with a 1315 very low cost for the attacker. In order to solve this problem, 1316 rate-limiting the processing of packets which may trigger SEND SAVI 1317 events SHOULD be enforced in a per-port basis. 1319 4.3. Residual threats 1321 SEND SAVI assumes that a host will be able to defend its address when 1322 the DAD procedure is executed for its addresses, and that it will 1323 answer to a NUD_NSOL with a NUD_NADV when required. This is needed, 1324 among other things, to support mobility within a link (i.e., to allow 1325 a host to detach and reconnect to a different Layer_2 anchor of the 1326 same IP subnetwork, without changing its IP address). If the SEND 1327 SAVI device does not see the DAD_NADV or the NUD_NADV, it may grant 1328 the binding to a different binding anchor. This means that if an 1329 attacker manages to prevent a host from defending its source address, 1330 it will be able to destroy the existing binding and create a new one, 1331 with a different binding anchor. An attacker may do so for example 1332 by launching a DoS attack to the host that will prevent it to issue 1333 proper replies. 1335 4.4. Privacy considerations 1337 Personally identifying information MUST NOT be included in the SEND 1338 SAVI Data Base with the MAC address as the canonical example, except 1339 when there is an attempt of attack involved. Moreover, compliant 1340 implementation MUST NOT log binding anchor information except where 1341 there is an identified reason why that information is likely to be 1342 involved in detection, prevention or tracing of actual source address 1343 spoofing. Information that is not logged MUST be deleted as soon as 1344 possible (i.e., as soon as the state for a given address is back to 1345 NO_BIND). Information about the majority of hosts that never spoof 1346 SHOULD NOT be logged. 1348 5. IANA Considerations 1350 This document has no actions for IANA. 1352 6. Acknowledgments 1354 Thanks to Jean-Michel Combes and Ana Kukec for their review and 1355 comments on this document. The text has also benefited from feedback 1356 provided by Tony Cheneau and Greg Daley. 1358 Marcelo Bagnulo is partly funded by Trilogy, a research project 1359 supported by the European Commission under its Seventh Framework 1360 Program. 1362 7. References 1364 7.1. Normative References 1366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1367 Requirement Levels", BCP 14, RFC 2119, March 1997. 1369 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1370 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1372 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1373 RFC 3972, March 2005. 1375 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1376 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1377 September 2007. 1379 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1380 Address Autoconfiguration", RFC 4862, September 2007. 1382 7.2. Informative References 1384 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1385 Defeating Denial of Service Attacks which employ IP Source 1386 Address Spoofing", BCP 38, RFC 2827, May 2000. 1388 [I-D.ietf-savi-framework] 1389 Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 1390 "Source Address Validation Improvement Framework", 1391 draft-ietf-savi-framework-06 (work in progress), 1392 January 2012. 1394 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 1395 Requirements", RFC 6434, December 2011. 1397 [IEEE.802-1Q.2005] 1398 Institute of Electrical and Electronics Engineers, "IEEE 1399 Standard for Local and metropolitan area networks / 1400 Virtual Bridged Local Area Networks", IEEE Standard 1401 802.1Q, May 2005. 1403 Authors' Addresses 1405 Marcelo Bagnulo 1406 Universidad Carlos III de Madrid 1407 Av. Universidad 30 1408 Leganes, Madrid 28911 1409 SPAIN 1411 Phone: 34 91 6248814 1412 Email: marcelo@it.uc3m.es 1413 URI: http://www.it.uc3m.es 1415 Alberto Garcia-Martinez 1416 Universidad Carlos III de Madrid 1417 Av. Universidad 30 1418 Leganes, Madrid 28911 1419 SPAIN 1421 Phone: 34 91 6248782 1422 Email: alberto@it.uc3m.es 1423 URI: http://www.it.uc3m.es