idnits 2.17.1 draft-ietf-savi-send-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 266: '... to another SEND SAVI device SHOULD be...' RFC 2119 keyword, line 271: '...nnected to hosts SHOULD be configured ...' RFC 2119 keyword, line 274: '...ected to routers SHOULD be configured ...' RFC 2119 keyword, line 279: '... hosts connected SHOULD be configured ...' RFC 2119 keyword, line 284: '...attached to them SHOULD be configured ...' (11 more instances...) 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 'MUST not' in this paragraph: SEND SAVI devices receiving RADV messages through Trusted ports MAY trust that other SEND SAVI switches have validated the router information, and include the prefix information in the SEND SAVI Prefix List table. Lifetime for prefixes and routerare updated according to the information included in the RADV message. Note that routers only have to prove liveliness through nonce response for the first SEND SAVI device in the SEND SAVI perimeter. The reception of a RADV message through a Trusted port MUST not trigger the generation of a secured RSOL. -- The document date (October 26, 2009) is 5286 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-02) exists of draft-vogt-savi-framework-01 ** Downref: Normative reference to an Informational draft: draft-vogt-savi-framework (ref. 'I-D.vogt-savi-framework') Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bagnulo 3 Internet-Draft A. Garcia-Martinez 4 Intended status: Standards Track UC3M 5 Expires: April 29, 2010 October 26, 2009 7 SEND-based Source-Address Validation Implementation 8 draft-ietf-savi-send-02 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 29, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This memo describes SEND SAVI, a mechanism to provide source address 47 validation using the SEND protocol. The proposed mechanism is 48 intended to complement ingress filtering techniques to provide a 49 higher granularity on the control of the source addresses used. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Design considerations . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Scope of SEND SAVI . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Constraints for SEND SAVI . . . . . . . . . . . . . . . . 4 57 2.3. Address ownership proof for SEND SAVI . . . . . . . . . . 4 58 3. SEND SAVI topology and port configuration . . . . . . . . . . 4 59 3.1. SEND SAVI enforcement perimeter . . . . . . . . . . . . . 4 60 3.2. SEND SAVI port configuration guidelines . . . . . . . . . 7 61 4. SEND SAVI specification . . . . . . . . . . . . . . . . . . . 7 62 4.1. SEND SAVI Data structures . . . . . . . . . . . . . . . . 8 63 4.2. Address configuration of SEND SAVI devices . . . . . . . . 9 64 4.3. Obtaining Certification Paths . . . . . . . . . . . . . . 9 65 4.4. Authorized Router Discovery and On-link prefix 66 discovery . . . . . . . . . . . . . . . . . . . . . . . . 9 67 4.5. SEND SAVI algorithm . . . . . . . . . . . . . . . . . . . 10 68 4.5.1. Traffic processing . . . . . . . . . . . . . . . . . . 10 69 5. Performance benefits of the SEND SAVI perimetrical 70 deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 73 8. Normative References . . . . . . . . . . . . . . . . . . . . . 18 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 76 1. Introduction 78 This memo describes SEND SAVI, a mechanism to provide source address 79 validation for IPv6 networks using the SEND protocol. The proposed 80 mechanism is intended to complement ingress filtering techniques to 81 provide a higher granularity on the control of the source addresses 82 used. 84 2. Design considerations 86 2.1. Scope of SEND SAVI 88 In a link there usually are hosts and routers attached. Hosts 89 generate packets with their own address as the source address. This 90 is the so-called local traffic, while routers send packets containing 91 a source address other than their own, since they are forwarding 92 packets generated by other hosts (usually located in a different 93 link). This is the so-called transit traffic. 95 SEND SAVI allows the validation of the source address of the local- 96 traffic, i.e. it allows to verify that the source address of the 97 packets generated by the hosts attached to the local link have not 98 been spoofed. In addition, since SEND does provide the means to 99 verify that a node claiming to act as a router is indeed authorized 100 to act as one, SEND SAVI also provides the means to verify that 101 packets containing off-link prefixes in the source address are 102 generated by authorized routers. However, SEND SAVI does not provide 103 the means to verify if a given (authorized) router is actually 104 authorized to forward packets containing a specific (off-link) source 105 address. Other techniques, like ingress filtering [RFC2827], are 106 recommended to validate transit traffic. In that sense, SEND SAVI 107 complements ingress filtering. Hence, the security level is 108 increased by the use of both SAVI and ingress filtering. 110 SEND SAVI applicability is limited to IPv6 hosts and IPv6 routers 111 using the SEND protocol [RFC3971]. 113 SEND SAVI validation can be performed in different type of devices, 114 including a router or a layer-2 bridge. The SEND SAVI function 115 should be located in the points of the topology in which the correct 116 usage of source address can be enforced by dropping the non-compliant 117 packets. 119 In the case the SAVI device is a switch that supports VLANs, the SAVI 120 implementation will behave as if there was one SAVI process per VLAN. 121 The SAVI process of each VLAN will store the binding information 122 corresponding the the nodes attached to that particular VLAN. 124 2.2. Constraints for SEND SAVI 126 SEND SAVI is designed to be deployed in existing networks requiring a 127 minimum set of changes. In particular, SEND SAVI does not require 128 any changes in the hosts whose source address is to be verified. Any 129 verification must solely rely in the usage of already available 130 protocols. This means that SEND SAVI does neither define a new 131 protocol, nor define any new message on existing protocols, nor 132 require that a host uses an existent protocol message in a different 133 way. SEND SAVI relies on the usage of the SEND protocol as defined 134 in [RFC3971] and the usage of CGA addresses as defined in [RFC3972]. 135 No changes to SEND or CGAs are required by SEND SAVI. 137 2.3. Address ownership proof for SEND SAVI 139 The main function performed by SEND SAVI is to verify that the source 140 address used in data packets actually belongs to the originator of 141 the packet. In SEND SAVI the address ownership proof is based in the 142 tools provided by SEND, namely CGAs and certificates. CGAs are used 143 to verify that the generator of a packet containing an on-link source 144 address is actually the owner of the address. Certificates are used 145 to verify that a node sending packets with off-link source address is 146 an authorized router. By using these two tools, SEND SAVI devices 147 can verify that the source address used in any packet flowing through 148 the local link is either generated by the host owner of the on-link 149 source address or that it is generated by an authorized router. 151 In both cases, the verification performed applies to a layer-2 anchor 152 associated to the IPv6 address used as source address in the data 153 packets. This anchor can be a layer-2 address, or the port of the 154 layer-2 switch through which a packet containing the IPv6 address as 155 source address should be received. SEND provides means to securely 156 associate IPV6 addresses with layer-2 addresses. However, unless an 157 additional mechanism (such as IEEE 802.1AE) is used, the fact that 158 layer-2 addresses can be spoofed suggest the use of ports as layer-2 159 anchors. For the rest of the document we assume the use of ports as 160 layer-2 anchors. 162 3. SEND SAVI topology and port configuration 164 3.1. SEND SAVI enforcement perimeter 166 SEND SAVI is designed to provide perimetrical protection. This 167 deployment model is similar to the one presented in the SAVI 168 framework document[I-D.vogt-savi-framework]. This design allows 169 reducing computing and state requirements in SAVI devices by 170 performing the cryptographic validations required to create the 171 binding only in the SEND SAVI device through which a packet first 172 enters in the secured perimeter. Once the packet is inside the 173 perimeter, no further validations are performed in general. An 174 exception to this is when a binding existed in the local SEND SAVI 175 device, in which case a local check for that device is performed. It 176 is worth to note that the deployment model allows connectivity to 177 legitimate hosts even if the perimeter is not properly built, 178 although in this case protection against spoofing cannot be provided. 180 The proposed mechanism assures that coherency among the information 181 available in the different SEND SAVI devices is preserved, if the 182 perimeter is configured appropriately. In particular, it avoids to 183 have a binding in different SAVI devices for the same source address. 184 Should that occur, it would mean that two hosts are allowed to send 185 packets with the same source address, which is undesirable according 186 to the goals of SAVI. 188 Ports in SEND SAVI devices may assume two roles according to its 189 behavior when filtering and validating SEND messages: Validating 190 ports and Trusted ports. 191 o Validating ports are those in which SEND SAVI filtering is 192 performed. This means that when a packet is received through one 193 of the Validating ports, SEND SAVI filtering will be executed. 194 Additionally, the validation of host identities by SEND SAVI is 195 performed only through Validating ports. 196 o Trusted ports are those in which SEND SAVI filtering is not 197 performed. So, packets received through Trusted ports are not 198 filtered by SEND SAVI. The only SEND messages received through a 199 Trusted port which are processed are those related with 200 certificate and router information. 202 The following figure shows a typical topology involving trusted and 203 untrusted infrastructure. 205 +--+ +--+ +--+ +--+ 206 |H1| |H2| |H3| |R1| 207 +--+ +--+ +--+ +--+ 208 | | | | 209 +----------SEND SAVI-ENFORCEMENT-PERIMETER------------+ 210 | | | | | | 211 | +-1-----2-+ +-1-----2-+ | 212 | | SEND- | | SEND- | 213 | | SAVI1 | | SAVI2 | | 214 | +-3--4----+ +--3------+ | 215 | | | +--------------+ | | 216 | | +----------| |--------+ | 217 | | | SWITCH-A | | 218 | | +----------| |--------+ | 219 | | | +--------------+ | | 220 | +-1--2----+ +--1------+ | 221 | | SEND- | | SEND- | | 222 | | SAVI3 | | SAVI4 | | 223 | +-3---4---+ +----4----+ | 224 | | | | | 225 +----------SEND SAVI-ENFORCEMENT-PERIMETER------------+ 226 | | | 227 +--+ +--+ +---------+ 228 |R2| |H4| |SWICTH-B | 229 +--+ +--+ +---------+ 230 | | 231 +--+ +--+ 232 |H5| |H6| 233 +--+ +--+ 235 Trusted ports are used for connections with trusted infrastructure, 236 including the communication between SEND SAVI devices and the 237 communication with other switches which are not SEND SAVI devices, 238 but they are only connected to trusted infrastructure. (i.e. other 239 SEND SAVI devices, routers or other trusted nodes). 241 Port 3 of SEND-SAVI1 and port 1 of SEND-SAVI3 are trusted because the 242 connect two SAVI devices. Port 4 of SEND-SAVI1, port 3 of SEND- 243 SAVI2, port 2 of SEND-SAVI3 and port 1 of SEND-SAVI4 are trusted 244 because they connect to SWITCH-A to which only trusted nodes are 245 connected. 247 Validating ports are used for connection with non-trusted 248 infrastructure. Therefore, hosts are normally connected to 249 validating ports. Non-SEND SAVI switches that are outside of the 250 SAVI enforcement perimeter also are connected through validating 251 port. In particular, non-SEND SAVI devices which connect directly to 252 hosts or which have no SEND SAVI capable device between themselves 253 and the hosts are connected through a validating port. So, in the 254 figure above, ports 1 and 2 of SEND-SAVI1, port 1 of SEND-SAVI2, port 255 4 of SEND-SAVI3 are validating ports because they connect to hosts. 256 Port 4 of SEND-SAVI4 is also a validating port because it is 257 connected to SWITCH-B which is a non- SEND SAVI capable switch which 258 is connected to hosts H5 and H6. Note that port 2 of SEND-SAVI2 and 259 port 3 of SEND-SAVI3 are validating ports, although they connect to 260 routers, since in SEND SAVI routers must use the appropriate SEND 261 message exchange to create an appropriate binding. 263 3.2. SEND SAVI port configuration guidelines 265 The guidelines for port configuration in SEND SAVI devices are: 266 o Ports that are connected to another SEND SAVI device SHOULD be 267 configured as Trusted ports. Not doing so will at least increase 268 significantly the CPU time, memory consumption and signaling 269 traffic due to SEND SAVI validation, in both the SEND SAVI devices 270 and the host or router whose address is being validated. 271 o Ports connected to hosts SHOULD be configured as Validating ports. 272 Not doing so will allow the host connected to that port to send 273 packets with spoofed source address. 274 o Ports connected to routers SHOULD be configured as Validating 275 ports. In this way, secured RADV, informing of the routing role 276 of the node and about on-line prefixes, are validated according to 277 SEND validation rules. 278 o Ports connected to a chain of one or more legacy switches that 279 have hosts connected SHOULD be configured as Validating ports. 280 Not doing so will allow the host connected to any of these 281 switches to send packets with spoofed source address. 282 o Ports connected to a chain of one or more legacy switches that 283 have other SEND SAVI devices and/or routers connected but had no 284 hosts attached to them SHOULD be configured as Trusted ports. Not 285 doing so will at least significantly increase the memory 286 consumption in the SEND SAVI devices and increase the signaling 287 traffic due to SEND SAVI validation. 288 o Ports connected to a chain of one or more legacy switches that 289 have a mix of SEND SAVI devices and/or routers with hosts, SHOULD 290 be configured as Validating ports. Not doing so will allow the 291 host connected to that port to send packets with spoofed source 292 address. 294 4. SEND SAVI specification 295 4.1. SEND SAVI Data structures 297 The SEND SAVI function relies on state information binding the source 298 IPv6 address used in data packets to the port through which the 299 legitimate host connects. Such information is stored in SEND SAVI 300 Data Base (DB). The SEND SAVI DB contains a set of entries about the 301 currently used IPv6 source addresses. The SEND SAVI DB is populated 302 with the contents of successfully validated SEND messages. So each 303 entry will contain the following information: 304 o IP source address 305 o Layer-2 port Validating port to which the host is connected. 306 o Timeout_Valid 308 SEND SAVI also needs the anchor information (see [RFC3971]) required 309 to validate the information generated by routers. Consequently, a 310 SEND SAVI Trust Anchor table, containing the certificates that can be 311 used as starting point for a certification path. The contents of 312 this table are populated with other means than SEND operation, i.e. 313 manual configuration, etc. The information contained in the SEND 314 SAVI Trust Anchor table is the following: 315 o Trust Anchor 317 To be able to validate RADV messages, a SEND SAVI Router 318 Certification Path Table is required. This table contains sequences 319 of certificates that certify the authority of the routers. As 320 [RFC3971] states, the Certification Paths should start from an anchor 321 (contained in the SEND SAVI Trust Anchor table) to be stored in the 322 SEND SAVI Router Certification Path Table. This table is populated 323 as a result of the reception of validated Certification Path 324 Solicitation messages. The contents of the table are: 325 o Certification Path 327 In addition to this, SEND SAVI need to know which are the link 328 prefixes. This information is obtained from validated RADV messages. 329 The corresponding data structure is called the SEND SAVI prefix list, 330 and contains: 331 o Prefix 332 o Lifetime 334 SEND SAVI keeps a list of the authorized routers, only for those 335 routers attached to Validating ports. In the SEND SAVI Router List, 336 the following information is stored: 337 o Router IPv6 address 338 o Layer-2 Validating port at which the router is connected. 339 o Lifetime 341 Finally, a SEND SAVI device must be configured with a valid CGA 342 address. This address is used when the SEND SAVI needs to issue 343 secured NSOL, RSOL or CPS messages. 345 4.2. Address configuration of SEND SAVI devices 347 Each SEND SAVI device must have a valid CGA address to use it for 348 secured ND operations. To configure this address, the usual 349 processes involved in address configuration, according to the SEND 350 specification [RFC3971], must be honored, such as performing DAD. 352 4.3. Obtaining Certification Paths 354 SEND SAVI devices MAY issue a Certification Path Solicitation message 355 to request a certification path from any router in the link, as it is 356 specified in the SEND specification [RFC3971]. 358 Alternatively, SEND SAVI devices may be configured not to request 359 this information, in which case the public key certificate used by 360 each router in the link must be available by other means (eg. manual 361 configuration). 363 4.4. Authorized Router Discovery and On-link prefix discovery 365 In order to be able to distinguish local from transit traffic, all 366 SEND SAVI devices MUST listen and process RADV containing the SEND 367 extensions. A SEND SAVI device receiving a secured RADV from a 368 Validating port for a router not included in the SEND SAVI prefix 369 list SHOULD validate the message, and if successful, issue a RSOL 370 message to the router to receive a new RADV in which the nonce send 371 by the SAVI SEND device is included and secured. If this check is 372 successful, then the SEND SAVI device MUST forward the initial 373 unsolicited RADV to the rest of the layer-2 network. After the 374 successful validation of the RADV message, the advertised prefixes 375 are included in the SEND SAVI Prefix List table. 377 SEND SAVI devices receiving RADV messages through Trusted ports MAY 378 trust that other SEND SAVI switches have validated the router 379 information, and include the prefix information in the SEND SAVI 380 Prefix List table. Lifetime for prefixes and routerare updated 381 according to the information included in the RADV message. Note that 382 routers only have to prove liveliness through nonce response for the 383 first SEND SAVI device in the SEND SAVI perimeter. The reception of 384 a RADV message through a Trusted port MUST not trigger the generation 385 of a secured RSOL. 387 A SEND SAVI device MAY send secured RSOL messages including the SEND 388 extensions when needed to keep the Router list and/or the Prefix list 389 up to date. 391 4.5. SEND SAVI algorithm 393 4.5.1. Traffic processing 395 In this section we describe how packets (with the exceptions 396 considered in the previous sections, such as RADV or CPA/CPS 397 messages) are processed. 399 First, the source address of packet is analysed to determine if it is 400 local or transit traffic, by checking if the prefix of the source 401 address is included in the SEND SAVI Prefix List (local traffic) or 402 not (transit traffic). 404 Transit traffic processing occurs as follows: 405 o If the transit traffic packet is received through a Trusted port, 406 the data packet is forwarded and no SAVI processing performed. 407 o If the transit traffic packet is received through a Validating 408 port, the is only accepted if the port appears in the SEND SAVI 409 Router List, indicating that a router has been validated through 410 SEND procedures at this port. 412 We next consider how local traffic is processed. 414 4.5.1.1. Processing of local traffic 416 If the verification of the source address of a packet shows that it 417 belongs to local traffic, this packet is processed using the state 418 machine described in this section. 420 For the rest of the section, the following assumptions hold: 421 o When it is stated that a secured NUD NSOL message is issued by a 422 SEND SAVI device through a given port, this means the following: 423 the SEND SAVI device performs a Neighbor Unreachability Detection 424 procedure as described in [RFC4861] with SEND secured messages as 425 defined in [RFC3971] addressed to the IPv6 target address (source 426 address of the packet triggering the procedure). The source 427 address used for issuing the NUD NSOL is the source address of the 428 SEND SAVI device. 429 o When it is stated that a validated NUD NADV message is received by 430 a SEND SAVI device through a port P, this means that: a SEND 431 secured NUD NADV message has been received by the appropriate port 432 P, and the NUD NADV message has been validated according to 433 [RFC3971] to prove ownership for the IPv6 address under 434 consideration, and being a response for the previous NUD NSOL 435 message issued by the SEND SAVI device (containing the same nonce 436 value as the NUD NSOL message to which it answers). Note that NUD 437 NADV messages that were not generated as response to a secured NUD 438 NSOL issued by the SEND SAVI device are not valid for updating the 439 SEND SAVI state machine, in order to provide greater protection 440 against reply attacks 442 The state machine is defined for a binding of a given source IP 443 address in a given SAVI device. In the transitions considered, 444 packets described as inputs refer to the IPv6 address associated to 445 the state machine. 447 The possible states are 448 o NO_BIND 449 o TENTATIVE_DAD 450 o TENTATIVE 451 o VALID 452 o TESTING 454 For deploying the state machine, two additional elements are 455 required: the Pending NUD NADV Messages table, and the Pending NUD 456 NADVs Counter (which counts the number of rows in the Pending NUD 457 NADV Messages table). One entry can be created per port (and per 458 source address to check) in the SEND SAVI device. The Pending NUD 459 NADV Messages table contains the following elements: 460 o Port: Port through which the secured NUD NSOL message was sent. 461 o Timeout_NUD: Time remaining until the timeout for receiving the 462 NUD NADV expires, in which case the entry is removed from the 463 table. 464 o Any SEND-specific information required to validate the NUD NADV 465 message, such as the nonce used in the NUD NSOL message. 466 o (Optional) Buffer of Pending Packets: packets received while this 467 port is in validation process. The availability of this buffer is 468 implementation-dependant. If the buffer does not exists, packets 469 are discarded until the port is validated. 471 Protection against DoS is provided by blocking temporarily ports for 472 which NUD detection has been issued, but no response has been 473 obtained. This is to protect from an attack in which SEND SAVI 474 device is forced to spend significant CPU resources in generating a 475 secured NUD NSOL after receiving a data packet. Protection is 476 enforced by means of the Port Blocking table: packets received from a 477 port included in that table are discarded. Entries are removed from 478 the table when the Blocking Timeout expires. The Port Blocking table 479 contains the following information: 480 o Blocked Port 481 o Blocking Timeout 483 A Tested Ports list is used to keep trace of the ports from which 484 sending activity has been probed by the SEND SAVI deice with a NUD 485 NSOL, while the SEND SAVI device was in a given state. This list is 486 used to populate the Port Blocking table. 488 When no binding exists, the state for all source IPv6 addresses is 489 NO_BIND. 491 We next describe how different inputs are processed depending on the 492 state of the binding of the IP address. A simplified version can be 493 found at http://www.it.uc3m.es/~alberto/SEND_SAVI_state_machine.pdf. 495 NO_BIND 496 o If a validated DAD NSOL message is received from a Validating port 497 VP, the SEND SAVI device forwards this message to all appropriate 498 ports (including other Validating ports), sets Timeout_DAD timer 499 to TIMEOUT_DAD, includes VP in the Tested Port list, and changes 500 the state to TENTATIVE_DAD. 501 o Upon the reception of any other packet through a Validating port 502 VP, the SEND SAVI device: 503 * Issues a secured NUD NSOL through port VP. 504 * Creates an entry associated to VP is created in the Pending NUD 505 NADV Messages table. The packet that triggered the SEND SAVI 506 validation process could be stored in the Buffer of Pending 507 Packets of VP. Timeout_NUD is set to TIMEOUT_NUD, and the 508 state is moved to TENTATIVE. 509 * Includes VP in the Tested Port list. 510 o Packets received from a Trusted port are forwarded to its 511 destination. These packets may come from a SEND SAVI device that 512 has securely validated the attachment of the host to its 513 Validating port according to SEND SAVI rules (unless the SEND SAVI 514 perimeter has been breached). 516 TENTATIVE_DAD 518 In this state, the host at VP has issued a secured DAD NSOL. While 519 it is waiting for a possible DAD NADV, and therefore its address is 520 tentative, the host does not response to NSOL messages, as it is 521 mandated by [RFC4862], so validation of the address by means of a NUD 522 NSOL/NADV exchange is not possible. In this state the SEND SAVI 523 device waits until the host has configured its address to check later 524 (by moving to TESTING state), with a NUD NSOL, if the host is the 525 legitimate user of the address. The check performed in the TESTING 526 state provides protection against reply attacks. 527 o If a validated DAD NADV is received from any port, the binding 528 cannot be configured for port VP. Therefore, the port VP is 529 included in the Port Blocking table, with Blocking Timeout equal 530 to BLOCKING_TIMEOUT, and the state is changed to NO_BIND. Note 531 that protection against reply attacks come from requiring the SEND 532 SAVI device to check for the DAD NSOL nonce in the DAD NADV 533 message received. 535 o If Timeout_DAD expires, then it is assumed that no other host has 536 configured this address. Therefore, the Validating port VP could 537 be bound to this IPv6 address. However, to provide additional 538 protection against reply attacks, the SEND SAVI device issues a 539 secured NUD NSOL to the Validating port, Timeout_NUD is set to 540 TIMEOUT_NUD, and the state is changed to TESTING. During the IPv6 541 address is in the TESTING state, packets sent from port VP are 542 forwarded. If the NUD test fails, the state is moved to NO_BIND. 543 Note that a reply attack can success in this case in allowing 544 packets to be sent from a port for TIMEOUT_NUD time. 545 o If a packet different from DAD NADV is received from any port, the 546 packet is discarded. 548 TENTATIVE 549 o If a validated NUD NADV message is successfully received through a 550 port registered in the Pending NUD NADV Messages table: 551 * The state is moved to VALID, with the port through which the 552 message has been received associated to the binding. 553 Timeout_valid is set to LIFETIME_VALID. Packets stored in the 554 Buffer of Pending Packets associated to the entry are 555 forwarded. 556 * The rest of the ports included in the Tested Ports list (except 557 the validated one) are used to create new entries in the Port 558 Blocking table, with Blocking Timeout equal to 559 BLOCKING_TIMEOUT. The Tested Port list is cleared. 560 o If a packet is received from a Validating port VP', different to 561 any of the ports registered in the Pending NUD NADV Messages 562 table, 563 * A secured NUD NSOL is issued through VP', and a new entry is 564 created in the Pending NUD NADV Messages table for VP' with 565 Timeout_NUD for the entry set to TIMEOUT_NUD. 566 * VP' is included in the Tested Port list. 567 o Packets received from a Trusted port are forwarded. These packets 568 may come from a SEND SAVI device that has securely validated the 569 attachment of the host to its Validating port according to SEND 570 SAVI rules (unless the SEND SAVI perimeter has been breached). 571 The host could have move to a new location while packets are still 572 in transit. 573 o If Pending NUD NADVs Counter arrives to 0 (i.e. all pending NUDs 574 have expired without receiving any validated NUD NSOL message), 575 * The state is moved to NO_BIND and all parameters associated to 576 the binding cleared. 577 * All ports included in the Tested Ports list are used to create 578 new entries in the Port Blocking table, with Blocking Timeout 579 equal to BLOCKING_TIMEOUT. The Tested Port list is cleared. 581 VALID 582 o If a packet containing IPaddr as a source address arrives from 583 Validating port VP, the packet is forwarded. Note that in the 584 SEND SAVI case Timeout_valid for the entry MUST NOT be set to 585 LIFETIME_VALID (as occurred for the FCFS SAVI), since regular 586 sending of packets does not provide the required security, which 587 is achieved by performing secured NUD periodically with the 588 sending host. 589 o If Timeout_valid expires, a secured NUD NSOL message is sent 590 through port VP to the IPv6 address, and a new entry is created in 591 the Pending NUD NADV Messages table for VP with Timeout_NUD for 592 the entry set to TIMEOUT_NUD. The state is changed to TESTING. 593 o If a packet is received through a Trusted port, a secured NUD NSOL 594 is sent to VP and a new entry is created in the Pending NUD NADV 595 Messages table for VP with Timeout_NUD for the entry set to 596 TIMEOUT_NUD. The state is changed to TESTING. NOTE:In the 597 TESTING state, it is assumed that packets coming from Trusted 598 ports have been appropriately validated by a remote SEND SAVI 599 device, but this assumption is not considered so strong so as to 600 clear the binding in this SEND SAVI device (by moving the state to 601 NO_BIND) without an additional check. The check performed is a 602 NUD NSOL request to VP. In this way, legitimate hosts are 603 protected from being blocked by malicious hosts taking advantage 604 of possible breaches in the perimeter. 605 o If a packet is received from a Validating Port VP', different from 606 the current Validating port for this binding: 607 * The SEND SAVI device issues two secured NUD NSOL messages, one 608 through VP', and another through VP. Entries for both ports VP 609 and VP' are created in the Pending NUD NADV Messages table with 610 Timeout_NUD for each entry set to TIMEOUT_NUD. The packet or 611 packets received from port VP' that triggered the SEND SAVI 612 validation process could be stored in the Buffer of Pending 613 Packets, to be forwarded when the identity of the sender were 614 validated. The state is changed to TESTING. 615 * VP' is included in the Tested Port list. 617 TESTING 619 It is worth to note that when the SEND SAVI device enters in the 620 TESTING state, the current Validating port is always under check 621 (through a NUD NSOL message). Other Validating ports may also be 622 tested when entering in this state. While testing, packets from the 623 current Validating port are forwarded. Packets coming from Trusted 624 ports are also forwarded. The detailed behavior is as follows: 625 o If a packet containing IPaddr as a source address arrives from 626 Validating port VP, the packet is forwarded. As a consequence of 627 this behavior, packets sent with a given IPv6 source address are 628 forwarded for a period equal to LIFETIME_VALID + TIMEOUT_NUD after 629 the state was moved to TENTATIVE, even if the host is no longer 630 connected to port VP. 631 o If a packet arrives from a Trusted port, the packet is forwarded. 632 This may occur because the host has moved to a port in another 633 SEND SAVI device. However, we still wait for the NUD NADV that 634 may come from VP, to provide protection against possible perimeter 635 breaches. Note that if no NUD NADV arrives from a Validating 636 port, the state moves to NO_BIND (which is the appropriate case 637 for a host that is connected through a different SEND SAVI 638 device). 639 o If a packet arrives from a Validating port VP' different to VP: 640 * The SEND SAVI device issues a secured NUD NSOL message through 641 port VP', and creates a new entry in the Pending NUD NADV 642 Messages table, setting the Timeout_NUD for the entry to 643 TIMEOUT_NUD. The state is not changed. 644 * VP' is included in the Tested Port list. 645 o If a validated NUD NADV message is received from any validating 646 port for which an entry in the Pending NUD NADV Messages table 647 exists: 648 * The Current Port is changed to this port, Timeout_Valid is set 649 to LIFETIME_VALID, and state is changed to VALID. 650 * If the port is different to VP, the packets in the Pending 651 Packets Buffer are forwarded. 652 * All ports included in the Tested Ports list, except for the 653 port for which the NUD NADV was received, are used to create 654 new entries in the Port Blocking table, with Blocking Timeout 655 equal to BLOCKING_TIMEOUT. Note that VP (the current 656 Validating Port when the state was VALID) is never in the list. 657 * The Tested Port list is cleared. 658 o If the Pending NUD NADV Messages Counter is set to 0 (i.e. all the 659 entries in the Pending NUD NADV Messages table have been deleted 660 because its timers have expired): 661 * The state is moved to NO_BIND. 662 * All ports included in the Tested Ports list are used to create 663 new entries in the Port Blocking table, with Blocking Timeout 664 equal to BLOCKING_TIMEOUT. Note that VP (the current 665 Validating Port when the state was VALID) is never in the list. 666 * The Tested Port list is cleared. 667 o If Timeout_valid for the Validating port VP expires, no action is 668 taken 670 5. Performance benefits of the SEND SAVI perimetrical deployment 672 It is worth to note that the perimetrical deployment result in much 673 lower computing, memory and bandwidth requirements, and lower delay 674 of the validation process, compared to a deployment scenario without 675 defined borders (i.e. in which all ports are Validating). To 676 understand this, consider the scenario depicted in the next figure, 677 in which no perimeter is considered, so all ports behave as 678 Validating. 680 +--+ +--+ +--+ +--+ 681 |H1| |H2| |H3| |R1| 682 +--+ +--+ +--+ +--+ 683 | | | | 684 | | | | 685 +-1-----2-+ +---------+ +-1-----2-+ 686 | SEND- | | SEND- | | SEND- | 687 | SAVI1 | | SAVI2 | | SAVI3 | 688 +-3--4----+ +-1-----2-+ +--3------+ 689 | | | | 690 ------------------- --------------- 692 Suppose node H1 wants to communicate with node H3, and no state 693 exists for H1 in neither of the SEND SAVI switches. H1 sends a data 694 packet to H3. This packet arrives to port 1 of SEND-SAVI1. SEND- 695 SAVI1 then issues a secured NUD NSOL message towards H1, with the RSA 696 option signing the message (which cannot be reused, since the nonce 697 and timestamp should vary for each message). H1 answers to the 698 received NSOL message issuing a secured NUD NADV message to SEND- 699 SAVI1. Upon the reception and validation of the NUD NADV, SEND-SAVI1 700 updates its SEND SAVI DB and forwards subsequent packets (maybe the 701 initial one, if it implements a Buffer of Pending Packets). 703 Now a packet arrives to SEND-SAVI2, which does not have a binding for 704 source address H1, so it generates a secured NUD NSOL message towards 705 H1, that must be validated by H1, answered with a NUD NADV (with 706 different nonce, and possibly timestamp, than the NUD NADV for SEND- 707 SAVI1), and validated by SEND-SAVI2. The same would be required for 708 SEND-SAVI3. 710 Therefore H1 will receive and must validate as many NUD NSOL messages 711 as new SEND SAVI devices being traversed by a packet. Additionally, 712 it must secure and generate as many NUD NSOL messages as new SEND 713 SAVI devices being traversed. Initial communication delay depends on 714 the time to sequentially perform each of this operations. 716 In a perimetrical deployment, only SEND-SAVI1 performs validation, 717 and it is the only switch to perform forwarding decisions according 718 to per-packet inspection of the source address of H1, since the rest 719 of SEND SAVI devices forwards packets received from Trusted ports 720 without further analysis. Additionally, interaction with H1 is 721 reduced to one NUD message exchange. 723 6. Security Considerations 725 First of all, it should be noted that any SAVI solution will be as 726 strong as the lower layer anchor that it uses. In particular, if the 727 lower layer anchor is forgeable, then the resulting SAVI solution 728 will be weak. For example, if the lower layer anchor is a MAC 729 address that can be easily spoofed, then the resulting SAVI will not 730 be stronger than that. On the other hand, if we use switch ports as 731 lower layer anchors (and there is only one host connected to each 732 port) it is likely that the resulting SAVI solution will be 733 considerably more secure. 735 SEND SAVI improves protection compared to conventional SAVI, as a 736 result of the increased ability of SEND hosts to prove address 737 ownership. 739 A critical security consideration regarding to SEND SAVI deals with 740 the need of proper configuration of the roles of the ports in a SEND 741 SAVI deployment scenario. Regarding to security, the main 742 requirement is that ports defining the protected perimeter SHOULD be 743 configured as Validating. Not doing so will generate security 744 breaches through which an attacker could send packets using any 745 source address, regardless of the bindings established in other SEND 746 SAVI devices. However, SEND SAVI is designed to allow even in this 747 case communication for legitimate users. The worst case for the 748 misconfiguration of the perimeter is then that two hosts may use the 749 same source IPv6 address. The reasons for having a misconfigured 750 perimeter, apart from initial misconfiguration, are the dynamic 751 operations performed by layer-2 routing mechanisms, for example, as a 752 result of a failure in a link or switching device. To prevent the 753 security risks associated, in the case of changes in the topology of 754 the SEND SAVI devices, all ports of a SEND SAVI device MAY be changed 755 automatically to Validating. Note that neither connectivity nor the 756 protection offered are compromised by operating in a mode in which 757 all ports of the SEND SAVI devices operate in Validating mode (only 758 performance is affected by this setting). 760 SEND SAVI design aims to enforce anti-reply protection by relying 761 only in solicited messages that must honor appropriate nonce 762 treatment defined in SEND. SEND SAVI devices rely in information 763 received from Validating ports (i.e. outside the protected domain) 764 only after performing secured and validated RSOL/RADV exchange for 765 router information, and NUD NSOL/NADV exchange for host information. 766 Certificate distribution in SEND (CPS/CPA) is not protected by 767 neither nonce nor timestamp, but it can be argued that the risk of 768 replying this information is not relevant for SAVI operation. 770 It is worth to note that the potential of Denial of Service attacks 771 against the SEND SAVI network is increased due to the use of costly 772 cryptographic operations in order to validate the address of the 773 hosts. An attacker could generate packets using new source addresses 774 in order to make the closest SEND SAVI device spend CPU time to 775 generate a NUD NSOL. This attack can be used to drain CPU resources 776 of SEND SAVI devices with a very low cost for the attacker. In order 777 to solve this problem, ports for which packets with a given source 778 address have been sent, but no binding was created, are blocked for 779 some time (TIMEOUT_BLOCKING). This means that a legitimate user 780 moving to a new port may have to wait up to TIMEOUT_BLOCKING time 781 until communication is allowed. Note that a similar mechanism could 782 be used in a pure port basis (i.e. not related with a specific source 783 address). 785 Another alternative for the attacker could be to generate packets 786 that trigger SEND SAVI validation, and to answer the NUD NSOL with a 787 valid response (provided it has generated private/public key pairs 788 for the attack), in order to waste memory from the SEND SAVI device. 789 This attack seems to be less attractive compared to the case in which 790 the attacker does not need to waste its own CPU power. However, it 791 should also be protected, since a host can have much more computing 792 power to perform cryptographic operations than a switching device. 793 Apart from rate limitation measured to protect SEND SAVI computing 794 resources, a mechanism similar to the one proposed for 795 [I-D.bagnulo-savi-fcfs], in which newer entries are overwritten 796 instead of older ones, in the case that memory is exhausted, could be 797 enforced. 799 7. Acknowledgments 801 Thanks to Ana Kukec for her review and comments on this document. 803 Marcelo Bagnulo is partly funded by Trilogy, a research project 804 supported by the European Commission under its Seventh Framework 805 Program. 807 Alberto Garcia-Martinez is partly funded by T2C2, a Spanish R&D 808 project. 810 8. Normative References 812 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 813 Defeating Denial of Service Attacks which employ IP Source 814 Address Spoofing", BCP 38, RFC 2827, May 2000. 816 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 817 Neighbor Discovery (SEND)", RFC 3971, March 2005. 819 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 820 RFC 3972, March 2005. 822 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 823 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 824 September 2007. 826 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 827 Address Autoconfiguration", RFC 4862, September 2007. 829 [I-D.vogt-savi-framework] 830 Vogt, C., "Source Address Validation Improvement Protocol 831 Framework", draft-vogt-savi-framework-01 (work in 832 progress), October 2009. 834 [I-D.bagnulo-savi-fcfs] 835 Nordmark, E. and M. Bagnulo, "First-Come First-Serve 836 Source-Address Validation Implementation", 837 draft-bagnulo-savi-fcfs-01 (work in progress), 838 January 2009. 840 Authors' Addresses 842 Marcelo Bagnulo 843 Universidad Carlos III de Madrid 844 Av. Universidad 30 845 Leganes, Madrid 28911 846 SPAIN 848 Phone: 34 91 6248814 849 Email: marcelo@it.uc3m.es 850 URI: http://www.it.uc3m.es 852 Alberto Garcia-Martinez 853 Universidad Carlos III de Madrid 854 Av. Universidad 30 855 Leganes, Madrid 28911 856 SPAIN 858 Phone: 34 91 6248782 859 Email: alberto@it.uc3m.es 860 URI: http://www.it.uc3m.es