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