idnits 2.17.1 draft-ietf-savi-send-01.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 262: '... to another SEND SAVI device SHOULD be...' RFC 2119 keyword, line 267: '...nnected to hosts SHOULD be configured ...' RFC 2119 keyword, line 270: '...ected to routers SHOULD be configured ...' RFC 2119 keyword, line 275: '... hosts connected SHOULD be configured ...' RFC 2119 keyword, line 280: '...attached to them SHOULD be configured ...' (12 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 21, 2009) is 5300 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) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 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 24, 2010 October 21, 2009 7 SEND-based Source-Address Validation Implementation 8 draft-ietf-savi-send-01 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 24, 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 . . . . . . . . . . . . . . . . 3 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. Interaction with non-SEND hosts . . . . . . . . . . . . . . . 16 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 73 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 74 9. Normative References . . . . . . . . . . . . . . . . . . . . . 18 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 77 1. Introduction 79 This memo describes SEND SAVI, a mechanism to provide source address 80 validation for IPv6 networks using the SEND protocol. The proposed 81 mechanism is intended to complement ingress filtering techniques to 82 provide a higher granularity on the control of the source addresses 83 used. 85 2. Design considerations 87 2.1. Scope of SEND SAVI 89 In a link there usually are hosts and routers attached. Hosts 90 generate packets with their own address as the source address. This 91 is the so-called local traffic, while routers send packets containing 92 a source address other than their own, since they are forwarding 93 packets generated by other hosts (usually located in a different 94 link). This is the so-called transit traffic. 96 SEND SAVI allows the validation of the source address of the local- 97 traffic, i.e. it allows to verify that the source address of the 98 packets generated by the hosts attached to the local link have not 99 been spoofed. In addition, since SEND does provide the means to 100 verify that a node claiming to act as a router is indeed authorized 101 to act as one, SEND SAVI also provides the means to verify that 102 packets containing off-link prefixes in the source address are 103 generated by authorized routers. However, SEND SAVI does not provide 104 the means to verify if a given (authorized) router is actually 105 authorized to forward packets containing a specific (off-link) source 106 address. Other techniques, like ingress filtering [RFC2827], are 107 recommended to validate transit traffic. In that sense, SEND SAVI 108 complements ingress filtering. Hence, the security level is 109 increased by the use of both SAVI and ingress filtering. 111 SEND SAVI applicability is limited to IPv6 hosts and IPv6 routers 112 using the SEND protocol [RFC3971]. 114 SEND SAVI validation can be performed in different type of devices, 115 including a router or a layer-2 bridge. The SEND SAVI function 116 should be located in the points of the topology in which the correct 117 usage of source address can be enforced by dropping the non-compliant 118 packets. 120 2.2. Constraints for SEND SAVI 122 SEND SAVI is designed to be deployed in existing networks requiring a 123 minimum set of changes. In particular, SEND SAVI does not require 124 any changes in the hosts whose source address is to be verified. Any 125 verification must solely rely in the usage of already available 126 protocols. This means that SEND SAVI does neither define a new 127 protocol, nor define any new message on existing protocols, nor 128 require that a host uses an existent protocol message in a different 129 way. SEND SAVI relies on the usage of the SEND protocol as defined 130 in [RFC3971] and the usage of CGA addresses as defined in [RFC3972]. 131 No changes to SEND or CGAs are required by SEND SAVI. 133 2.3. Address ownership proof for SEND SAVI 135 The main function performed by SEND SAVI is to verify that the source 136 address used in data packets actually belongs to the originator of 137 the packet. In SEND SAVI the address ownership proof is based in the 138 tools provided by SEND, namely CGAs and certificates. CGAs are used 139 to verify that the generator of a packet containing an on-link source 140 address is actually the owner of the address. Certificates are used 141 to verify that a node sending packets with off-link source address is 142 an authorized router. By using these two tools, SEND SAVI devices 143 can verify that the source address used in any packet flowing through 144 the local link is either generated by the host owner of the on-link 145 source address or that it is generated by an authorized router. 147 In both cases, the verification performed applies to a layer-2 anchor 148 associated to the IPv6 address used as source address in the data 149 packets. This anchor can be a layer-2 address, or the port of the 150 layer-2 switch through which a packet containing the IPv6 address as 151 source address should be received. SEND provides means to securely 152 associate IPV6 addresses with layer-2 addresses. However, unless an 153 additional mechanism (such as IEEE 802.1AE) is used, the fact that 154 layer-2 addresses can be spoofed suggest the use of ports as layer-2 155 anchors. For the rest of the document we assume the use of ports as 156 layer-2 anchors. 158 3. SEND SAVI topology and port configuration 160 3.1. SEND SAVI enforcement perimeter 162 SEND SAVI is designed to provide perimetrical protection. This 163 deployment model is similar to the one presented in FCFS SAVI 164 [I-D.bagnulo-savi-fcfs]. This design allows reducing computing and 165 state requirements in SAVI devices by performing the cryptographic 166 validations required to create the binding only in the SEND SAVI 167 device through which a packet first enters in the secured perimeter. 168 Once the packet is inside the perimeter, no further validations are 169 performed in general. An exception to this is when a binding existed 170 in the local SEND SAVI device, in which case a local check for that 171 device is performed. It is worth to note that the deployment model 172 allows connectivity to legitimate hosts even if the perimeter is not 173 properly built, although in this case protection against spoofing 174 cannot be provided. 176 The proposed mechanism assures that coherency among the information 177 available in the different SEND SAVI devices is preserved, if the 178 perimeter is configured appropriately. In particular, it avoids to 179 have a binding in different SAVI devices for the same source address. 180 Should that occur, it would mean that two hosts are allowed to send 181 packets with the same source address, which is undesirable according 182 to the goals of SAVI. 184 Ports in SEND SAVI devices may assume two roles according to its 185 behavior when filtering and validating SEND messages: Validating 186 ports and Trusted ports. 187 o Validating ports are those in which SEND SAVI filtering is 188 performed. This means that when a packet is received through one 189 of the Validating ports, SEND SAVI filtering will be executed. 190 Additionally, the validation of host identities by SEND SAVI is 191 performed only through Validating ports. 192 o Trusted ports are those in which SEND SAVI filtering is not 193 performed. So, packets received through Trusted ports are not 194 filtered by SEND SAVI. The only SEND messages received through a 195 Trusted port which are processed are those related with 196 certificate and router information. 198 The following figure shows a typical topology involving trusted and 199 untrusted infrastructure. 201 +--+ +--+ +--+ +--+ 202 |H1| |H2| |H3| |R1| 203 +--+ +--+ +--+ +--+ 204 | | | | 205 +----------SEND SAVI-ENFORCEMENT-PERIMETER------------+ 206 | | | | | | 207 | +-1-----2-+ +-1-----2-+ | 208 | | SEND- | | SEND- | 209 | | SAVI1 | | SAVI2 | | 210 | +-3--4----+ +--3------+ | 211 | | | +--------------+ | | 212 | | +----------| |--------+ | 213 | | | SWITCH-A | | 214 | | +----------| |--------+ | 215 | | | +--------------+ | | 216 | +-1--2----+ +--1------+ | 217 | | SEND- | | SEND- | | 218 | | SAVI3 | | SAVI4 | | 219 | +-3---4---+ +----4----+ | 220 | | | | | 221 +----------SEND SAVI-ENFORCEMENT-PERIMETER------------+ 222 | | | 223 +--+ +--+ +---------+ 224 |R2| |H4| |SWICTH-B | 225 +--+ +--+ +---------+ 226 | | 227 +--+ +--+ 228 |H5| |H6| 229 +--+ +--+ 231 Trusted ports are used for connections with trusted infrastructure, 232 including the communication between SEND SAVI devices and the 233 communication with other switches which are not SEND SAVI devices, 234 but they are only connected to trusted infrastructure. (i.e. other 235 SEND SAVI devices, routers or other trusted nodes). 237 Port 3 of SEND-SAVI1 and port 1 of SEND-SAVI3 are trusted because the 238 connect two SAVI devices. Port 4 of SEND-SAVI1, port 3 of SEND- 239 SAVI2, port 2 of SEND-SAVI3 and port 1 of SEND-SAVI4 are trusted 240 because they connect to SWITCH-A to which only trusted nodes are 241 connected. 243 Validating ports are used for connection with non-trusted 244 infrastructure. Therefore, hosts are normally connected to 245 validating ports. Non-SEND SAVI switches that are outside of the 246 SAVI enforcement perimeter also are connected through validating 247 port. In particular, non-SEND SAVI devices which connect directly to 248 hosts or which have no SEND SAVI capable device between themselves 249 and the hosts are connected through a validating port. So, in the 250 figure above, ports 1 and 2 of SEND-SAVI1, port 1 of SEND-SAVI2, port 251 4 of SEND-SAVI3 are validating ports because they connect to hosts. 252 Port 4 of SEND-SAVI4 is also a validating port because it is 253 connected to SWITCH-B which is a non- SEND SAVI capable switch which 254 is connected to hosts H5 and H6. Note that port 2 of SEND-SAVI2 and 255 port 3 of SEND-SAVI3 are validating ports, although they connect to 256 routers, since in SEND SAVI routers must use the appropriate SEND 257 message exchange to create an appropriate binding. 259 3.2. SEND SAVI port configuration guidelines 261 The guidelines for port configuration in SEND SAVI devices are: 262 o Ports that are connected to another SEND SAVI device SHOULD be 263 configured as Trusted ports. Not doing so will at least increase 264 significantly the CPU time, memory consumption and signaling 265 traffic due to SEND SAVI validation, in both the SEND SAVI devices 266 and the host or router whose address is being validated. 267 o Ports connected to hosts SHOULD be configured as Validating ports. 268 Not doing so will allow the host connected to that port to send 269 packets with spoofed source address. 270 o Ports connected to routers SHOULD be configured as Validating 271 ports. In this way, secured RADV, informing of the routing role 272 of the node and about on-line prefixes, are validated according to 273 SEND validation rules. 274 o Ports connected to a chain of one or more legacy switches that 275 have hosts connected SHOULD be configured as Validating ports. 276 Not doing so will allow the host connected to any of these 277 switches to send packets with spoofed source address. 278 o Ports connected to a chain of one or more legacy switches that 279 have other SEND SAVI devices and/or routers connected but had no 280 hosts attached to them SHOULD be configured as Trusted ports. Not 281 doing so will at least significantly increase the memory 282 consumption in the SEND SAVI devices and increase the signaling 283 traffic due to SEND SAVI validation. 284 o Ports connected to a chain of one or more legacy switches that 285 have a mix of SEND SAVI devices and/or routers with hosts, SHOULD 286 be configured as Validating ports. Not doing so will allow the 287 host connected to that port to send packets with spoofed source 288 address. 290 4. SEND SAVI specification 291 4.1. SEND SAVI Data structures 293 The SEND SAVI function relies on state information binding the source 294 IPv6 address used in data packets to the port through which the 295 legitimate host connects. Such information is stored in SEND SAVI 296 Data Base (DB). The SEND SAVI DB contains a set of entries about the 297 currently used IPv6 source addresses. Each binding must be unique 298 for a given VLAN (although the same address may appear in different 299 VLANs, eg. two IPv6 link-local addresses). The SEND SAVI DB is 300 populated with the contents of successfully validated SEND messages. 301 So each entry will contain the following information: 302 o IP source address 303 o VLAN 304 o Layer-2 port Validating port to which the host is connected. 305 o Timeout_Valid 307 SEND SAVI also needs the anchor information (see [RFC3971]) required 308 to validate the information generated by routers. Consequently, a 309 SEND SAVI Trust Anchor table, containing the certificates that can be 310 used as starting point for a certification path. Different trust 311 anchors can be associated to different VLANs. The contents of this 312 table are populated with other means than SEND operation, i.e. manual 313 configuration, etc. The information contained in the SEND SAVI Trust 314 Anchor table is the following: 315 o Trust Anchor 316 o VLAN 318 To be able to validate RADV messages, a SEND SAVI Router 319 Certification Path Table is required. This table contains sequences 320 of certificates that certify the authority of the routers. As 321 [RFC3971] states, the Certification Paths should start from an anchor 322 (contained in the SEND SAVI Trust Anchor table) to be stored in the 323 SEND SAVI Router Certification Path Table. Different trust anchors 324 can be associated to different VLANs. This table is populated as a 325 result of the reception of validated Certification Path Solicitation 326 messages. The contents of the table are: 327 o Certification Path 328 o VLAN 330 In addition to this, SEND SAVI need to know which are the link 331 prefixes. This information is obtained from validated RADV messages. 332 The corresponding data structure is called the SEND SAVI prefix list, 333 and contains: 334 o Prefix 335 o VLAN 336 o Lifetime 338 SEND SAVI keeps a list of the authorized routers, only for those 339 routers attached to Validating ports. In the SEND SAVI Router List, 340 the following information is stored: 341 o Router IPv6 address 342 o Layer-2 Validating port at which the router is connected. 343 o VLAN 344 o Lifetime 346 Finally, a SEND SAVI device must be configured with a valid CGA 347 address. This address is used when the SEND SAVI needs to issue 348 secured NSOL, RSOL or CPS messages. 350 4.2. Address configuration of SEND SAVI devices 352 Each SEND SAVI device must have a valid CGA address to use it for 353 secured ND operations. To configure this address, the usual 354 processes involved in address configuration, according to the SEND 355 specification [RFC3971], must be honored, such as performing DAD. 356 Different addresses may be used for different VLANs. 358 4.3. Obtaining Certification Paths 360 SEND SAVI devices MAY issue a Certification Path Solicitation message 361 to request a certification path from any router in the link, as it is 362 specified in the SEND specification [RFC3971]. This message MAY be 363 sent in all VLANs configured in the switch. 365 Alternatively, SEND SAVI devices may be configured not to request 366 this information, in which case the public key certificate used by 367 each router in the link must be available by other means (eg. manual 368 configuration). 370 4.4. Authorized Router Discovery and On-link prefix discovery 372 In order to be able to distinguish local from transit traffic, all 373 SEND SAVI devices MUST listen and process RADV containing the SEND 374 extensions. A SEND SAVI device receiving a secured RADV from a 375 Validating port for a router not included in the SEND SAVI prefix 376 list SHOULD validate the message, and if successful, issue a RSOL 377 message to the router to receive a new RADV in which the nonce send 378 by the SAVI SEND device is included and secured. If this check is 379 successful, then the SEND SAVI device MUST forward the initial 380 unsolicited RADV to the rest of the layer-2 network. After the 381 successful validation of the RADV message, the advertised prefixes 382 are included in the SEND SAVI Prefix List table. 384 SEND SAVI devices receiving RADV messages through Trusted ports MAY 385 trust that other SEND SAVI switches have validated the router 386 information, and include the prefix information in the SEND SAVI 387 Prefix List table. Lifetime for prefixes and routerare updated 388 according to the information included in the RADV message. Note that 389 routers only have to prove liveliness through nonce response for the 390 first SEND SAVI device in the SEND SAVI perimeter. The reception of 391 a RADV message through a Trusted port MUST not trigger the generation 392 of a secured RSOL. 394 A SEND SAVI device MAY send secured RSOL messages including the SEND 395 extensions when needed to keep the Router list and/or the Prefix list 396 up to date. 398 4.5. SEND SAVI algorithm 400 4.5.1. Traffic processing 402 In this section we describe how packets (with the exceptions 403 considered in the previous sections, such as RADV or CPA/CPS 404 messages) are processed. 406 First, the source address of packet is analysed to determine if it is 407 local or transit traffic, by checking if the prefix of the source 408 address is included in the SEND SAVI Prefix List (local traffic) or 409 not (transit traffic). 411 Transit traffic processing occurs as follows: 412 o If the transit traffic packet is received through a Trusted port, 413 the data packet is forwarded and no SAVI processing performed. 414 o If the transit traffic packet is received through a Validating 415 port, the is only accepted if the port appears in the SEND SAVI 416 Router List, indicating that a router has been validated through 417 SEND procedures at this port. 419 We next consider how local traffic is processed. 421 4.5.1.1. Processing of local traffic 423 If the verification of the source address of a packet shows that it 424 belongs to local traffic, this packet is processed using the state 425 machine described in this section. 427 For the rest of the section, the following assumptions hold: 428 o When it is stated that a secured NUD NSOL message is issued by a 429 SEND SAVI device through a given port, this means the following: 430 the SEND SAVI device performs a Neighbor Unreachability Detection 431 procedure as described in [RFC4861] with SEND secured messages as 432 defined in [RFC3971] addressed to the IPv6 target address (source 433 address of the packet triggering the procedure). The source 434 address used for issuing the NUD NSOL is the source address of the 435 SEND SAVI device. 436 o When it is stated that a validated NUD NADV message is received by 437 a SEND SAVI device through a port P, this means that: a SEND 438 secured NUD NADV message has been received by the appropriate port 439 P, and the NUD NADV message has been validated according to 440 [RFC3971] to prove ownership for the IPv6 address under 441 consideration, and being a response for the previous NUD NSOL 442 message issued by the SEND SAVI device (containing the same nonce 443 value as the NUD NSOL message to which it answers). Note that NUD 444 NADV messages that were not generated as response to a secured NUD 445 NSOL issued by the SEND SAVI device are not valid for updating the 446 SEND SAVI state machine, in order to provide greater protection 447 against reply attacks 449 The state machine is defined for a binding of a given source IP 450 address in a given VLAN and in a given SAVI device. In the 451 transitions considered, packets described as inputs refer to the IPv6 452 address associated to the state machine. 454 The possible states are 455 o NO_BIND 456 o TENTATIVE 457 o VALID 458 o TESTING 460 For deploying the state machine, two additional elements are 461 required: the Pending NUD NADV Messages table, and the Pending NUD 462 NADVs Counter (which counts the number of rows in the Pending NUD 463 NADV Messages table). One entry can be created per port (and per 464 source address to check) in the SEND SAVI device. The Pending NUD 465 NADV Messages table contains the following elements: 466 o Port: Port through which the secured NUD NSOL message was sent. 467 o Timeout_NUD: Time remaining until the timeout for receiving the 468 NUD NADV expires, in which case the entry is removed from the 469 table. 470 o Any SEND-specific information required to validate the NUD NADV 471 message, such as the nonce used in the NUD NSOL message. 472 o (Optionally) Buffer of Pending Packets: packets received while 473 this port is in validation process. The availability of this 474 buffer is implementation-dependant. If the buffer does not 475 exists, packets are discarded until the port is validated. 477 NOTE: THE FOLLOWING PARAGRAPH IS FOR DEPLOYING A PER-SOURCE-ADDRESS 478 RATE LIMITING MECHANISM FOR PROTECTION AGAINST DoS. MAYBE A SIMILAR 479 MECHANISM COULD BE DEPLOYED IN A GENERAL (NON PER-SOURCE-ADDRESS) 480 BASIS. We can delete the stuff related with this. 482 Protection against DoS is provided by blocking temporarily ports for 483 which NUD detection has been issued, but no response has been 484 obtained. This is to protect from an attack in which SEND SAVI 485 device is forced to spend significant CPU resources in generating a 486 secured NUD NSOL after receiving a data packet. Protection is 487 enforced by means of the Port Blocking table: packets received from a 488 port included in that table are discarded. Entries are removed from 489 the table when the Blocking Timeout expires. The Port Blocking table 490 contains the following information: 491 o Blocked Port 492 o Blocking Timeout 494 A Tested Ports list is used to keep trace of the ports from which 495 sending activity has been probed by the SEND SAVI deice with a NUD 496 NSOL, while the SEND SAVI device was in a given state. This list is 497 used to populate the Port Blocking table. 499 When no binding exists, the state for all source IPv6 addresses is 500 NO_BIND. 502 We next describe how different inputs are processed depending on the 503 state of the binding of the IP address. A simplified version can be 504 found at http://www.it.uc3m.es/~alberto/SEND_SAVI_state_machine.pdf. 506 NO_BIND 507 o Upon the reception of any packet through a Validating port VP, the 508 SEND SAVI device: 509 * Issues a secured NUD NSOL through port VP. 510 * Creates an entry associated to VP is created in the Pending NUD 511 NADV Messages table. The packet that triggered the SEND SAVI 512 validation process could be stored in the Buffer of Pending 513 Packets of VP. Timeout_NUD is set to TIMEOUT_NUD, and the 514 state is moved to TENTATIVE. 515 * Includes VP in the Tested Port list. 516 o Packets received from a Trusted port are forwarded to its 517 destination. These packets may come from a SEND SAVI device that 518 has securely validated the attachment of the host to its 519 Validating port according to SEND SAVI rules (unless the SEND SAVI 520 perimeter has been breached). 522 TENTATIVE 523 o If a validated NUD NADV message is successfully received through a 524 port registered in the Pending NUD NADV Messages table: 525 * The state is moved to VALID, with the port through which the 526 message has been received associated to the binding. 527 Timeout_valid is set to LIFETIME_VALID. Packets stored in the 528 Buffer of Pending Packets associated to the entry are 529 forwarded. 531 * The rest of the ports included in the Tested Ports list (except 532 the validated one) are used to create new entries in the Port 533 Blocking table, with Blocking Timeout equal to 534 BLOCKING_TIMEOUT. The Tested Port list is cleared. 535 o If a packet is received from a Validating port VP', different to 536 any of the ports registered in the Pending NUD NADV Messages 537 table, 538 * A secured NUD NSOL is issued through VP', and a new entry is 539 created in the Pending NUD NADV Messages table for VP' with 540 Timeout_NUD for the entry set to TIMEOUT_NUD. 541 * VP' is included in the Tested Port list. 542 o Packets received from a Trusted port are forwarded. These packets 543 may come from a SEND SAVI device that has securely validated the 544 attachment of the host to its Validating port according to SEND 545 SAVI rules (unless the SEND SAVI perimeter has been breached). 546 The host could have move to a new location while packets are still 547 in transit. 548 o If Pending NUD NADVs Counter arrives to 0 (i.e. all pending NUDs 549 have expired without receiving any validated NUD NSOL message), 550 * The state is moved to NO_BIND and all parameters associated to 551 the binding cleared. 552 * All ports included in the Tested Ports list are used to create 553 new entries in the Port Blocking table, with Blocking Timeout 554 equal to BLOCKING_TIMEOUT. The Tested Port list is cleared. 556 VALID 557 o If a packet containing IPaddr as a source address arrives from 558 Validating port VP, the packet is forwarded. Note that in the 559 SEND SAVI case Timeout_valid for the entry MUST NOT be set to 560 LIFETIME_VALID (as occurred for the FCFS SAVI), since regular 561 sending of packets does not provide the required security, which 562 is achieved by performing secured NUD periodically with the 563 sending host. 564 o If Timeout_valid expires, a secured NUD NSOL message is sent 565 through port VP to the IPv6 address, and a new entry is created in 566 the Pending NUD NADV Messages table for VP with Timeout_NUD for 567 the entry set to TIMEOUT_NUD. The state is changed to TESTING. 568 o If a packet is received through a Trusted port, a secured NUD NSOL 569 is sent to VP and a new entry is created in the Pending NUD NADV 570 Messages table for VP with Timeout_NUD for the entry set to 571 TIMEOUT_NUD. The state is changed to TESTING. NOTE:In the 572 TESTING state, it is assumed that packets coming from Trusted 573 ports have been appropriately validated by a remote SEND SAVI 574 device, but this assumption is not considered so strong so as to 575 clear the binding in this SEND SAVI device (by moving the state to 576 NO_BIND) without an additional check. The check performed is a 577 NUD NSOL request to VP. In this way, legitimate hosts are 578 protected from being blocked by malicious hosts taking advantage 579 of possible breaches in the perimeter. 580 o If a packet is received from a Validating Port VP', different from 581 the current Validating port for this binding: 582 * The SEND SAVI device issues two secured NUD NSOL messages, one 583 through VP', and another through VP. Entries for both ports VP 584 and VP' are created in the Pending NUD NADV Messages table with 585 Timeout_NUD for each entry set to TIMEOUT_NUD. The packet or 586 packets received from port VP' that triggered the SEND SAVI 587 validation process could be stored in the Buffer of Pending 588 Packets, to be forwarded when the identity of the sender were 589 validated. The state is changed to TESTING. 590 * VP' is included in the Tested Port list. 592 TESTING 594 It is worth to note that when the SEND SAVI device enters in the 595 TESTING state, the current Validating port is always under check 596 (through a NUD NSOL message). Other Validating ports may also be 597 tested when entering in this state. While testing, packets from the 598 current Validating port are forwarded. Packets coming from Trusted 599 ports are also forwarded. The detailed behavior is as follows: 600 o If a packet containing IPaddr as a source address arrives from 601 Validating port VP, the packet is forwarded. As a consequence of 602 this behavior, packets sent with a given IPv6 source address are 603 forwarded for a period equal to LIFETIME_VALID + TIMEOUT_NUD after 604 the state was moved to TENTATIVE, even if the host is no longer 605 connected to port VP. 606 o If a packet arrives from a Trusted port, the packet is forwarded. 607 This may occur because the host has moved to a port in another 608 SEND SAVI device. However, we still wait for the NUD NADV that 609 may come from VP, to provide protection against possible perimeter 610 breaches. Note that if no NUD NADV arrives from a Validating 611 port, the state moves to NO_BIND (which is the appropriate case 612 for a host that is connected through a different SEND SAVI 613 device). 614 o If a packet arrives from a Validating port VP' different to VP: 615 * The SEND SAVI device issues a secured NUD NSOL message through 616 port VP', and creates a new entry in the Pending NUD NADV 617 Messages table, setting the Timeout_NUD for the entry to 618 TIMEOUT_NUD. The state is not changed. 619 * VP' is included in the Tested Port list. 620 o If a validated NUD NADV message is received from any validating 621 port for which an entry in the Pending NUD NADV Messages table 622 exists: 623 * The Current Port is changed to this port, Timeout_Valid is set 624 to LIFETIME_VALID, and state is changed to VALID. 626 * If the port is different to VP, the packets in the Pending 627 Packets Buffer are forwarded. 628 * All ports included in the Tested Ports list, except for the 629 port for which the NUD NADV was received, are used to create 630 new entries in the Port Blocking table, with Blocking Timeout 631 equal to BLOCKING_TIMEOUT. Note that VP (the current 632 Validating Port when the state was VALID) is never in the list. 633 * The Tested Port list is cleared. 634 o If the Pending NUD NADV Messages Counter is set to 0 (i.e. all the 635 entries in the Pending NUD NADV Messages table have been deleted 636 because its timers have expired): 637 * The state is moved to NO_BIND. 638 * All ports included in the Tested Ports list are used to create 639 new entries in the Port Blocking table, with Blocking Timeout 640 equal to BLOCKING_TIMEOUT. Note that VP (the current 641 Validating Port when the state was VALID) is never in the list. 642 * The Tested Port list is cleared. 643 o If Timeout_valid for the Validating port VP expires, no action is 644 taken 646 5. Performance benefits of the SEND SAVI perimetrical deployment 648 It is worth to note that the perimetrical deployment result in much 649 lower computing, memory and bandwidth requirements, and lower delay 650 of the validation process, compared to a deployment scenario without 651 defined borders (i.e. in which all ports are Validating). To 652 understand this, consider the scenario depicted in the next figure, 653 in which no perimeter is considered, so all ports behave as 654 Validating. 656 +--+ +--+ +--+ +--+ 657 |H1| |H2| |H3| |R1| 658 +--+ +--+ +--+ +--+ 659 | | | | 660 | | | | 661 +-1-----2-+ +---------+ +-1-----2-+ 662 | SEND- | | SEND- | | SEND- | 663 | SAVI1 | | SAVI2 | | SAVI3 | 664 +-3--4----+ +-1-----2-+ +--3------+ 665 | | | | 666 ------------------- --------------- 668 Suppose node H1 wants to communicate with node H3, and no state 669 exists for H1 in neither of the SEND SAVI switches. H1 sends a data 670 packet to H3. This packet arrives to port 1 of SEND-SAVI1. SEND- 671 SAVI1 then issues a secured NUD NSOL message towards H1, with the RSA 672 option signing the message (which cannot be reused, since the nonce 673 and timestamp should vary for each message). H1 answers to the 674 received NSOL message issuing a secured NUD NADV message to SEND- 675 SAVI1. Upon the reception and validation of the NUD NADV, SEND-SAVI1 676 updates its SEND SAVI DB and forwards subsequent packets (maybe the 677 initial one, if it implements a Buffer of Pending Packets). 679 Now a packet arrives to SEND-SAVI2, which does not have a binding for 680 source address H1, so it generates a secured NUD NSOL message towards 681 H1, that must be validated by H1, answered with a NUD NADV (with 682 different nonce, and possibly timestamp, than the NUD NADV for SEND- 683 SAVI1), and validated by SEND-SAVI2. The same would be required for 684 SEND-SAVI3. 686 Therefore H1 will receive and must validate as many NUD NSOL messages 687 as new SEND SAVI devices being traversed by a packet. Additionally, 688 it must secure and generate as many NUD NSOL messages as new SEND 689 SAVI devices being traversed. Initial communication delay depends on 690 the time to sequentially perform each of this operations. 692 In a perimetrical deployment, only SEND-SAVI1 performs validation, 693 and it is the only switch to perform forwarding decisions according 694 to per-packet inspection of the source address of H1, since the rest 695 of SEND SAVI devices forwards packets received from Trusted ports 696 without further analysis. Additionally, interaction with H1 is 697 reduced to one NUD message exchange. 699 6. Interaction with non-SEND hosts 701 TBD 703 7. Security Considerations 705 First of all, it should be noted that any SAVI solution will be as 706 strong as the lower layer anchor that it uses. In particular, if the 707 lower layer anchor is forgeable, then the resulting SAVI solution 708 will be weak. For example, if the lower layer anchor is a MAC 709 address that can be easily spoofed, then the resulting SAVI will not 710 be stronger than that. On the other hand, if we use switch ports as 711 lower layer anchors (and there is only one host connected to each 712 port) it is likely that the resulting SAVI solution will be 713 considerably more secure. 715 SEND SAVI improves protection compared to conventional SAVI, as a 716 result of the increased ability of SEND hosts to prove address 717 ownership. 719 A critical security consideration regarding to SEND SAVI deals with 720 the need of proper configuration of the roles of the ports in a SEND 721 SAVI deployment scenario. Regarding to security, the main 722 requirement is that ports defining the protected perimeter SHOULD be 723 configured as Validating. Not doing so will generate security 724 breaches through which an attacker could send packets using any 725 source address, regardless of the bindings established in other SEND 726 SAVI devices. However, SEND SAVI is designed to allow even in this 727 case communication for legitimate users. The worst case for the 728 misconfiguration of the perimeter is then that two hosts may use the 729 same source IPv6 address. The reasons for having a misconfigured 730 perimeter, apart from initial misconfiguration, are the dynamic 731 operations performed by layer-2 routing mechanisms, for example, as a 732 result of a failure in a link or switching device. To prevent the 733 security risks associated, in the case of changes in the topology of 734 the SEND SAVI devices, all ports of a SEND SAVI device MAY be changed 735 automatically to Validating. Note that neither connectivity nor the 736 protection offered are compromised by operating in a mode in which 737 all ports of the SEND SAVI devices operate in Validating mode (only 738 performance is affected by this setting). 740 SEND SAVI design enforces anti-reply protection by relying only in 741 solicited messages that must honor appropriate nonce treatment 742 defined in SEND. SEND SAVI devices rely in information received from 743 Validating ports (i.e. outside the protected domain) only after 744 performing secured and validated RSOL/RADV exchange for router 745 information, and NUD NSOL/NADV exchange for host information. 746 Certificate distribution in SEND (CPS/CPA) is not protected by 747 neither nonce nor timestamp, but it can be argued that the risk of 748 replying this information is not relevant for SAVI operation. 750 It is worth to note that the potential of Denial of Service attacks 751 against the SEND SAVI network is increased due to the use of costly 752 cryptographic operations in order to validate the address of the 753 hosts. An attacker could generate packets using new source addresses 754 in order to make the closest SEND SAVI device spend CPU time to 755 generate a NUD NSOL. This attack can be used to drain CPU resources 756 of SEND SAVI devices with a very low cost for the attacker. In order 757 to solve this problem, ports for which packets with a given source 758 address have been sent, but no binding was created, are blocked for 759 some time (TIMEOUT_BLOCKING). This means that a legitimate user 760 moving to a new port may have to wait up to TIMEOUT_BLOCKING time 761 until communication is allowed. Note that a similar mechanism could 762 be used in a pure port basis (i.e. not related with a specific source 763 address). 765 Another alternative for the attacker could be to generate packets 766 that trigger SEND SAVI validation, and to answer the NUD NSOL with a 767 valid response (provided it has generated private/public key pairs 768 for the attack), in order to waste memory from the SEND SAVI device. 769 This attack seems to be less attractive compared to the case in which 770 the attacker does not need to waste its own CPU power. However, it 771 should also be protected, since a host can have much more computing 772 power to perform cryptographic operations than a switching device. 773 Apart from rate limitation measured to protect SEND SAVI computing 774 resources, a mechanism similar to the one proposed for 775 [I-D.bagnulo-savi-fcfs], in which newer entries are overwritten 776 instead of older ones, in the case that memory is exhausted, could be 777 enforced. 779 8. Acknowledgments 781 Thanks to Ana Kukec for her review and comments on this document. 783 Marcelo Bagnulo is partly funded by Trilogy, a research project 784 supported by the European Commission under its Seventh Framework 785 Program. 787 Alberto Garcia-Martinez is partly funded by T2C2, a Spanish R&D 788 project. 790 9. Normative References 792 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 793 Defeating Denial of Service Attacks which employ IP Source 794 Address Spoofing", BCP 38, RFC 2827, May 2000. 796 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 797 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 798 September 2007. 800 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 801 Neighbor Discovery (SEND)", RFC 3971, March 2005. 803 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 804 RFC 3972, March 2005. 806 [I-D.bagnulo-savi-fcfs] 807 Nordmark, E. and M. Bagnulo, "First-Come First-Serve 808 Source-Address Validation Implementation", 809 draft-bagnulo-savi-fcfs-01 (work in progress), 810 January 2009. 812 Authors' Addresses 814 Marcelo Bagnulo 815 Universidad Carlos III de Madrid 816 Av. Universidad 30 817 Leganes, Madrid 28911 818 SPAIN 820 Phone: 34 91 6248814 821 Email: marcelo@it.uc3m.es 822 URI: http://www.it.uc3m.es 824 Alberto Garcia-Martinez 825 Universidad Carlos III de Madrid 826 Av. Universidad 30 827 Leganes, Madrid 28911 828 SPAIN 830 Phone: 34 91 6248782 831 Email: alberto@it.uc3m.es 832 URI: http://www.it.uc3m.es