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