Network Working Group M. Bagnulo Internet-Draft A. Garcia-Martinez Intended status: Standards Track UC3M Expires: April 29, 2010 October 26, 2009 SEND-based Source-Address Validation Implementation draft-ietf-savi-send-02 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 29, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This memo describes SEND SAVI, a mechanism to provide source address validation using the SEND protocol. The proposed mechanism is intended to complement ingress filtering techniques to provide a Bagnulo & Garcia-Martinez Expires April 29, 2010 [Page 1] Internet-Draft SEND SAVI October 2009 higher granularity on the control of the source addresses used. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Design considerations . . . . . . . . . . . . . . . . . . . . 3 2.1. Scope of SEND SAVI . . . . . . . . . . . . . . . . . . . . 3 2.2. Constraints for SEND SAVI . . . . . . . . . . . . . . . . 4 2.3. Address ownership proof for SEND SAVI . . . . . . . . . . 4 3. SEND SAVI topology and port configuration . . . . . . . . . . 4 3.1. SEND SAVI enforcement perimeter . . . . . . . . . . . . . 4 3.2. SEND SAVI port configuration guidelines . . . . . . . . . 7 4. SEND SAVI specification . . . . . . . . . . . . . . . . . . . 7 4.1. SEND SAVI Data structures . . . . . . . . . . . . . . . . 8 4.2. Address configuration of SEND SAVI devices . . . . . . . . 9 4.3. Obtaining Certification Paths . . . . . . . . . . . . . . 9 4.4. Authorized Router Discovery and On-link prefix discovery . . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. SEND SAVI algorithm . . . . . . . . . . . . . . . . . . . 10 4.5.1. Traffic processing . . . . . . . . . . . . . . . . . . 10 5. Performance benefits of the SEND SAVI perimetrical deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8. Normative References . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Bagnulo & Garcia-Martinez Expires April 29, 2010 [Page 2] Internet-Draft SEND SAVI October 2009 1. Introduction This memo describes SEND SAVI, a mechanism to provide source address validation for IPv6 networks using the SEND protocol. The proposed mechanism is intended to complement ingress filtering techniques to provide a higher granularity on the control of the source addresses used. 2. Design considerations 2.1. Scope of SEND SAVI In a link there usually are hosts and routers attached. Hosts generate packets with their own address as the source address. This is the so-called local traffic, while routers send packets containing a source address other than their own, since they are forwarding packets generated by other hosts (usually located in a different link). This is the so-called transit traffic. SEND SAVI allows the validation of the source address of the local- traffic, i.e. it allows to verify that the source address of the packets generated by the hosts attached to the local link have not been spoofed. In addition, since SEND does provide the means to verify that a node claiming to act as a router is indeed authorized to act as one, SEND SAVI also provides the means to verify that packets containing off-link prefixes in the source address are generated by authorized routers. However, SEND SAVI does not provide the means to verify if a given (authorized) router is actually authorized to forward packets containing a specific (off-link) source address. Other techniques, like ingress filtering [RFC2827], are recommended to validate transit traffic. In that sense, SEND SAVI complements ingress filtering. Hence, the security level is increased by the use of both SAVI and ingress filtering. SEND SAVI applicability is limited to IPv6 hosts and IPv6 routers using the SEND protocol [RFC3971]. SEND SAVI validation can be performed in different type of devices, including a router or a layer-2 bridge. The SEND SAVI function should be located in the points of the topology in which the correct usage of source address can be enforced by dropping the non-compliant packets. In the case the SAVI device is a switch that supports VLANs, the SAVI implementation will behave as if there was one SAVI process per VLAN. The SAVI process of each VLAN will store the binding information corresponding the the nodes attached to that particular VLAN. Bagnulo & Garcia-Martinez Expires April 29, 2010 [Page 3] Internet-Draft SEND SAVI October 2009 2.2. Constraints for SEND SAVI SEND SAVI is designed to be deployed in existing networks requiring a minimum set of changes. In particular, SEND SAVI does not require any changes in the hosts whose source address is to be verified. Any verification must solely rely in the usage of already available protocols. This means that SEND SAVI does neither define a new protocol, nor define any new message on existing protocols, nor require that a host uses an existent protocol message in a different way. SEND SAVI relies on the usage of the SEND protocol as defined in [RFC3971] and the usage of CGA addresses as defined in [RFC3972]. No changes to SEND or CGAs are required by SEND SAVI. 2.3. Address ownership proof for SEND SAVI The main function performed by SEND SAVI is to verify that the source address used in data packets actually belongs to the originator of the packet. In SEND SAVI the address ownership proof is based in the tools provided by SEND, namely CGAs and certificates. CGAs are used to verify that the generator of a packet containing an on-link source address is actually the owner of the address. Certificates are used to verify that a node sending packets with off-link source address is an authorized router. By using these two tools, SEND SAVI devices can verify that the source address used in any packet flowing through the local link is either generated by the host owner of the on-link source address or that it is generated by an authorized router. In both cases, the verification performed applies to a layer-2 anchor associated to the IPv6 address used as source address in the data packets. This anchor can be a layer-2 address, or the port of the layer-2 switch through which a packet containing the IPv6 address as source address should be received. SEND provides means to securely associate IPV6 addresses with layer-2 addresses. However, unless an additional mechanism (such as IEEE 802.1AE) is used, the fact that layer-2 addresses can be spoofed suggest the use of ports as layer-2 anchors. For the rest of the document we assume the use of ports as layer-2 anchors. 3. SEND SAVI topology and port configuration 3.1. SEND SAVI enforcement perimeter SEND SAVI is designed to provide perimetrical protection. This deployment model is similar to the one presented in the SAVI framework document[I-D.vogt-savi-framework]. This design allows reducing computing and state requirements in SAVI devices by performing the cryptographic validations required to create the Bagnulo & Garcia-Martinez Expires April 29, 2010 [Page 4] Internet-Draft SEND SAVI October 2009 binding only in the SEND SAVI device through which a packet first enters in the secured perimeter. Once the packet is inside the perimeter, no further validations are performed in general. An exception to this is when a binding existed in the local SEND SAVI device, in which case a local check for that device is performed. It is worth to note that the deployment model allows connectivity to legitimate hosts even if the perimeter is not properly built, although in this case protection against spoofing cannot be provided. The proposed mechanism assures that coherency among the information available in the different SEND SAVI devices is preserved, if the perimeter is configured appropriately. In particular, it avoids to have a binding in different SAVI devices for the same source address. Should that occur, it would mean that two hosts are allowed to send packets with the same source address, which is undesirable according to the goals of SAVI. Ports in SEND SAVI devices may assume two roles according to its behavior when filtering and validating SEND messages: Validating ports and Trusted ports. o Validating ports are those in which SEND SAVI filtering is performed. This means that when a packet is received through one of the Validating ports, SEND SAVI filtering will be executed. Additionally, the validation of host identities by SEND SAVI is performed only through Validating ports. o Trusted ports are those in which SEND SAVI filtering is not performed. So, packets received through Trusted ports are not filtered by SEND SAVI. The only SEND messages received through a Trusted port which are processed are those related with certificate and router information. The following figure shows a typical topology involving trusted and untrusted infrastructure. Bagnulo & Garcia-Martinez Expires April 29, 2010 [Page 5] Internet-Draft SEND SAVI October 2009 +--+ +--+ +--+ +--+ |H1| |H2| |H3| |R1| +--+ +--+ +--+ +--+ | | | | +----------SEND SAVI-ENFORCEMENT-PERIMETER------------+ | | | | | | | +-1-----2-+ +-1-----2-+ | | | SEND- | | SEND- | | | SAVI1 | | SAVI2 | | | +-3--4----+ +--3------+ | | | | +--------------+ | | | | +----------| |--------+ | | | | SWITCH-A | | | | +----------| |--------+ | | | | +--------------+ | | | +-1--2----+ +--1------+ | | | SEND- | | SEND- | | | | SAVI3 | | SAVI4 | | | +-3---4---+ +----4----+ | | | | | | +----------SEND SAVI-ENFORCEMENT-PERIMETER------------+ | | | +--+ +--+ +---------+ |R2| |H4| |SWICTH-B | +--+ +--+ +---------+ | | +--+ +--+ |H5| |H6| +--+ +--+ Trusted ports are used for connections with trusted infrastructure, including the communication between SEND SAVI devices and the communication with other switches which are not SEND SAVI devices, but they are only connected to trusted infrastructure. (i.e. other SEND SAVI devices, routers or other trusted nodes). Port 3 of SEND-SAVI1 and port 1 of SEND-SAVI3 are trusted because the connect two SAVI devices. Port 4 of SEND-SAVI1, port 3 of SEND- SAVI2, port 2 of SEND-SAVI3 and port 1 of SEND-SAVI4 are trusted because they connect to SWITCH-A to which only trusted nodes are connected. Validating ports are used for connection with non-trusted infrastructure. Therefore, hosts are normally connected to validating ports. Non-SEND SAVI switches that are outside of the SAVI enforcement perimeter also are connected through validating port. In particular, non-SEND SAVI devices which connect directly to Bagnulo & Garcia-Martinez Expires April 29, 2010 [Page 6] Internet-Draft SEND SAVI October 2009 hosts or which have no SEND SAVI capable device between themselves and the hosts are connected through a validating port. So, in the figure above, ports 1 and 2 of SEND-SAVI1, port 1 of SEND-SAVI2, port 4 of SEND-SAVI3 are validating ports because they connect to hosts. Port 4 of SEND-SAVI4 is also a validating port because it is connected to SWITCH-B which is a non- SEND SAVI capable switch which is connected to hosts H5 and H6. Note that port 2 of SEND-SAVI2 and port 3 of SEND-SAVI3 are validating ports, although they connect to routers, since in SEND SAVI routers must use the appropriate SEND message exchange to create an appropriate binding. 3.2. SEND SAVI port configuration guidelines The guidelines for port configuration in SEND SAVI devices are: o Ports that are connected to another SEND SAVI device SHOULD be configured as Trusted ports. Not doing so will at least increase significantly the CPU time, memory consumption and signaling traffic due to SEND SAVI validation, in both the SEND SAVI devices and the host or router whose address is being validated. o Ports connected to hosts SHOULD be configured as Validating ports. Not doing so will allow the host connected to that port to send packets with spoofed source address. o Ports connected to routers SHOULD be configured as Validating ports. In this way, secured RADV, informing of the routing role of the node and about on-line prefixes, are validated according to SEND validation rules. o Ports connected to a chain of one or more legacy switches that have hosts connected SHOULD be configured as Validating ports. Not doing so will allow the host connected to any of these switches to send packets with spoofed source address. o Ports connected to a chain of one or more legacy switches that have other SEND SAVI devices and/or routers connected but had no hosts attached to them SHOULD be configured as Trusted ports. Not doing so will at least significantly increase the memory consumption in the SEND SAVI devices and increase the signaling traffic due to SEND SAVI validation. o Ports connected to a chain of one or more legacy switches that have a mix of SEND SAVI devices and/or routers with hosts, SHOULD be configured as Validating ports. Not doing so will allow the host connected to that port to send packets with spoofed source address. 4. SEND SAVI specification Bagnulo & Garcia-Martinez Expires April 29, 2010 [Page 7] Internet-Draft SEND SAVI October 2009 4.1. SEND SAVI Data structures The SEND SAVI function relies on state information binding the source IPv6 address used in data packets to the port through which the legitimate host connects. Such information is stored in SEND SAVI Data Base (DB). The SEND SAVI DB contains a set of entries about the currently used IPv6 source addresses. The SEND SAVI DB is populated with the contents of successfully validated SEND messages. So each entry will contain the following information: o IP source address o Layer-2 port Validating port to which the host is connected. o Timeout_Valid SEND SAVI also needs the anchor information (see [RFC3971]) required to validate the information generated by routers. Consequently, a SEND SAVI Trust Anchor table, containing the certificates that can be used as starting point for a certification path. The contents of this table are populated with other means than SEND operation, i.e. manual configuration, etc. The information contained in the SEND SAVI Trust Anchor table is the following: o Trust Anchor To be able to validate RADV messages, a SEND SAVI Router Certification Path Table is required. This table contains sequences of certificates that certify the authority of the routers. As [RFC3971] states, the Certification Paths should start from an anchor (contained in the SEND SAVI Trust Anchor table) to be stored in the SEND SAVI Router Certification Path Table. This table is populated as a result of the reception of validated Certification Path Solicitation messages. The contents of the table are: o Certification Path In addition to this, SEND SAVI need to know which are the link prefixes. This information is obtained from validated RADV messages. The corresponding data structure is called the SEND SAVI prefix list, and contains: o Prefix o Lifetime SEND SAVI keeps a list of the authorized routers, only for those routers attached to Validating ports. In the SEND SAVI Router List, the following information is stored: o Router IPv6 address o Layer-2 Validating port at which the router is connected. o Lifetime Finally, a SEND SAVI device must be configured with a valid CGA address. This address is used when the SEND SAVI needs to issue Bagnulo & Garcia-Martinez Expires April 29, 2010 [Page 8] Internet-Draft SEND SAVI October 2009 secured NSOL, RSOL or CPS messages. 4.2. Address configuration of SEND SAVI devices Each SEND SAVI device must have a valid CGA address to use it for secured ND operations. To configure this address, the usual processes involved in address configuration, according to the SEND specification [RFC3971], must be honored, such as performing DAD. 4.3. Obtaining Certification Paths SEND SAVI devices MAY issue a Certification Path Solicitation message to request a certification path from any router in the link, as it is specified in the SEND specification [RFC3971]. Alternatively, SEND SAVI devices may be configured not to request this information, in which case the public key certificate used by each router in the link must be available by other means (eg. manual configuration). 4.4. Authorized Router Discovery and On-link prefix discovery In order to be able to distinguish local from transit traffic, all SEND SAVI devices MUST listen and process RADV containing the SEND extensions. A SEND SAVI device receiving a secured RADV from a Validating port for a router not included in the SEND SAVI prefix list SHOULD validate the message, and if successful, issue a RSOL message to the router to receive a new RADV in which the nonce send by the SAVI SEND device is included and secured. If this check is successful, then the SEND SAVI device MUST forward the initial unsolicited RADV to the rest of the layer-2 network. After the successful validation of the RADV message, the advertised prefixes are included in the SEND SAVI Prefix List table. 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. A SEND SAVI device MAY send secured RSOL messages including the SEND extensions when needed to keep the Router list and/or the Prefix list up to date. Bagnulo & Garcia-Martinez Expires April 29, 2010 [Page 9] Internet-Draft SEND SAVI October 2009 4.5. SEND SAVI algorithm 4.5.1. Traffic processing In this section we describe how packets (with the exceptions considered in the previous sections, such as RADV or CPA/CPS messages) are processed. First, the source address of packet is analysed to determine if it is local or transit traffic, by checking if the prefix of the source address is included in the SEND SAVI Prefix List (local traffic) or not (transit traffic). Transit traffic processing occurs as follows: o If the transit traffic packet is received through a Trusted port, the data packet is forwarded and no SAVI processing performed. o If the transit traffic packet is received through a Validating port, the is only accepted if the port appears in the SEND SAVI Router List, indicating that a router has been validated through SEND procedures at this port. We next consider how local traffic is processed. 4.5.1.1. Processing of local traffic If the verification of the source address of a packet shows that it belongs to local traffic, this packet is processed using the state machine described in this section. For the rest of the section, the following assumptions hold: o When it is stated that a secured NUD NSOL message is issued by a SEND SAVI device through a given port, this means the following: the SEND SAVI device performs a Neighbor Unreachability Detection procedure as described in [RFC4861] with SEND secured messages as defined in [RFC3971] addressed to the IPv6 target address (source address of the packet triggering the procedure). The source address used for issuing the NUD NSOL is the source address of the SEND SAVI device. o When it is stated that a validated NUD NADV message is received by a SEND SAVI device through a port P, this means that: a SEND secured NUD NADV message has been received by the appropriate port P, and the NUD NADV message has been validated according to [RFC3971] to prove ownership for the IPv6 address under consideration, and being a response for the previous NUD NSOL message issued by the SEND SAVI device (containing the same nonce value as the NUD NSOL message to which it answers). Note that NUD NADV messages that were not generated as response to a secured NUD NSOL issued by the SEND SAVI device are not valid for updating the Bagnulo & Garcia-Martinez Expires April 29, 2010 [Page 10] Internet-Draft SEND SAVI October 2009 SEND SAVI state machine, in order to provide greater protection against reply attacks The state machine is defined for a binding of a given source IP address in a given SAVI device. In the transitions considered, packets described as inputs refer to the IPv6 address associated to the state machine. The possible states are o NO_BIND o TENTATIVE_DAD o TENTATIVE o VALID o TESTING For deploying the state machine, two additional elements are required: the Pending NUD NADV Messages table, and the Pending NUD NADVs Counter (which counts the number of rows in the Pending NUD NADV Messages table). One entry can be created per port (and per source address to check) in the SEND SAVI device. The Pending NUD NADV Messages table contains the following elements: o Port: Port through which the secured NUD NSOL message was sent. o Timeout_NUD: Time remaining until the timeout for receiving the NUD NADV expires, in which case the entry is removed from the table. o Any SEND-specific information required to validate the NUD NADV message, such as the nonce used in the NUD NSOL message. o (Optional) Buffer of Pending Packets: packets received while this port is in validation process. The availability of this buffer is implementation-dependant. If the buffer does not exists, packets are discarded until the port is validated. Protection against DoS is provided by blocking temporarily ports for which NUD detection has been issued, but no response has been obtained. This is to protect from an attack in which SEND SAVI device is forced to spend significant CPU resources in generating a secured NUD NSOL after receiving a data packet. Protection is enforced by means of the Port Blocking table: packets received from a port included in that table are discarded. Entries are removed from the table when the Blocking Timeout expires. The Port Blocking table contains the following information: o Blocked Port o Blocking Timeout A Tested Ports list is used to keep trace of the ports from which sending activity has been probed by the SEND SAVI deice with a NUD NSOL, while the SEND SAVI device was in a given state. This list is used to populate the Port Blocking table. Bagnulo & Garcia-Martinez Expires April 29, 2010 [Page 11] Internet-Draft SEND SAVI October 2009 When no binding exists, the state for all source IPv6 addresses is NO_BIND. We next describe how different inputs are processed depending on the state of the binding of the IP address. A simplified version can be found at http://www.it.uc3m.es/~alberto/SEND_SAVI_state_machine.pdf. NO_BIND o If a validated DAD NSOL message is received from a Validating port VP, the SEND SAVI device forwards this message to all appropriate ports (including other Validating ports), sets Timeout_DAD timer to TIMEOUT_DAD, includes VP in the Tested Port list, and changes the state to TENTATIVE_DAD. o Upon the reception of any other packet through a Validating port VP, the SEND SAVI device: * Issues a secured NUD NSOL through port VP. * Creates an entry associated to VP is created in the Pending NUD NADV Messages table. The packet that triggered the SEND SAVI validation process could be stored in the Buffer of Pending Packets of VP. Timeout_NUD is set to TIMEOUT_NUD, and the state is moved to TENTATIVE. * Includes VP in the Tested Port list. o Packets received from a Trusted port are forwarded to its destination. These packets may come from a SEND SAVI device that has securely validated the attachment of the host to its Validating port according to SEND SAVI rules (unless the SEND SAVI perimeter has been breached). TENTATIVE_DAD In this state, the host at VP has issued a secured DAD NSOL. While it is waiting for a possible DAD NADV, and therefore its address is tentative, the host does not response to NSOL messages, as it is mandated by [RFC4862], so validation of the address by means of a NUD NSOL/NADV exchange is not possible. In this state the SEND SAVI device waits until the host has configured its address to check later (by moving to TESTING state), with a NUD NSOL, if the host is the legitimate user of the address. The check performed in the TESTING state provides protection against reply attacks. o If a validated DAD NADV is received from any port, the binding cannot be configured for port VP. Therefore, the port VP is included in the Port Blocking table, with Blocking Timeout equal to BLOCKING_TIMEOUT, and the state is changed to NO_BIND. Note that protection against reply attacks come from requiring the SEND SAVI device to check for the DAD NSOL nonce in the DAD NADV message received. Bagnulo & Garcia-Martinez Expires April 29, 2010 [Page 12] Internet-Draft SEND SAVI October 2009 o If Timeout_DAD expires, then it is assumed that no other host has configured this address. Therefore, the Validating port VP could be bound to this IPv6 address. However, to provide additional protection against reply attacks, the SEND SAVI device issues a secured NUD NSOL to the Validating port, Timeout_NUD is set to TIMEOUT_NUD, and the state is changed to TESTING. During the IPv6 address is in the TESTING state, packets sent from port VP are forwarded. If the NUD test fails, the state is moved to NO_BIND. Note that a reply attack can success in this case in allowing packets to be sent from a port for TIMEOUT_NUD time. o If a packet different from DAD NADV is received from any port, the packet is discarded. TENTATIVE o If a validated NUD NADV message is successfully received through a port registered in the Pending NUD NADV Messages table: * The state is moved to VALID, with the port through which the message has been received associated to the binding. Timeout_valid is set to LIFETIME_VALID. Packets stored in the Buffer of Pending Packets associated to the entry are forwarded. * The rest of the ports included in the Tested Ports list (except the validated one) are used to create new entries in the Port Blocking table, with Blocking Timeout equal to BLOCKING_TIMEOUT. The Tested Port list is cleared. o If a packet is received from a Validating port VP', different to any of the ports registered in the Pending NUD NADV Messages table, * A secured NUD NSOL is issued through VP', and a new entry is created in the Pending NUD NADV Messages table for VP' with Timeout_NUD for the entry set to TIMEOUT_NUD. * VP' is included in the Tested Port list. o Packets received from a Trusted port are forwarded. These packets may come from a SEND SAVI device that has securely validated the attachment of the host to its Validating port according to SEND SAVI rules (unless the SEND SAVI perimeter has been breached). The host could have move to a new location while packets are still in transit. o If Pending NUD NADVs Counter arrives to 0 (i.e. all pending NUDs have expired without receiving any validated NUD NSOL message), * The state is moved to NO_BIND and all parameters associated to the binding cleared. * All ports included in the Tested Ports list are used to create new entries in the Port Blocking table, with Blocking Timeout equal to BLOCKING_TIMEOUT. The Tested Port list is cleared. VALID Bagnulo & Garcia-Martinez Expires April 29, 2010 [Page 13] Internet-Draft SEND SAVI October 2009 o If a packet containing IPaddr as a source address arrives from Validating port VP, the packet is forwarded. Note that in the SEND SAVI case Timeout_valid for the entry MUST NOT be set to LIFETIME_VALID (as occurred for the FCFS SAVI), since regular sending of packets does not provide the required security, which is achieved by performing secured NUD periodically with the sending host. o If Timeout_valid expires, a secured NUD NSOL message is sent through port VP to the IPv6 address, and a new entry is created in the Pending NUD NADV Messages table for VP with Timeout_NUD for the entry set to TIMEOUT_NUD. The state is changed to TESTING. o If a packet is received through a Trusted port, a secured NUD NSOL is sent to VP and a new entry is created in the Pending NUD NADV Messages table for VP with Timeout_NUD for the entry set to TIMEOUT_NUD. The state is changed to TESTING. NOTE:In the TESTING state, it is assumed that packets coming from Trusted ports have been appropriately validated by a remote SEND SAVI device, but this assumption is not considered so strong so as to clear the binding in this SEND SAVI device (by moving the state to NO_BIND) without an additional check. The check performed is a NUD NSOL request to VP. In this way, legitimate hosts are protected from being blocked by malicious hosts taking advantage of possible breaches in the perimeter. o If a packet is received from a Validating Port VP', different from the current Validating port for this binding: * The SEND SAVI device issues two secured NUD NSOL messages, one through VP', and another through VP. Entries for both ports VP and VP' are created in the Pending NUD NADV Messages table with Timeout_NUD for each entry set to TIMEOUT_NUD. The packet or packets received from port VP' that triggered the SEND SAVI validation process could be stored in the Buffer of Pending Packets, to be forwarded when the identity of the sender were validated. The state is changed to TESTING. * VP' is included in the Tested Port list. TESTING It is worth to note that when the SEND SAVI device enters in the TESTING state, the current Validating port is always under check (through a NUD NSOL message). Other Validating ports may also be tested when entering in this state. While testing, packets from the current Validating port are forwarded. Packets coming from Trusted ports are also forwarded. The detailed behavior is as follows: o If a packet containing IPaddr as a source address arrives from Validating port VP, the packet is forwarded. As a consequence of this behavior, packets sent with a given IPv6 source address are forwarded for a period equal to LIFETIME_VALID + TIMEOUT_NUD after the state was moved to TENTATIVE, even if the host is no longer Bagnulo & Garcia-Martinez Expires April 29, 2010 [Page 14] Internet-Draft SEND SAVI October 2009 connected to port VP. o If a packet arrives from a Trusted port, the packet is forwarded. This may occur because the host has moved to a port in another SEND SAVI device. However, we still wait for the NUD NADV that may come from VP, to provide protection against possible perimeter breaches. Note that if no NUD NADV arrives from a Validating port, the state moves to NO_BIND (which is the appropriate case for a host that is connected through a different SEND SAVI device). o If a packet arrives from a Validating port VP' different to VP: * The SEND SAVI device issues a secured NUD NSOL message through port VP', and creates a new entry in the Pending NUD NADV Messages table, setting the Timeout_NUD for the entry to TIMEOUT_NUD. The state is not changed. * VP' is included in the Tested Port list. o If a validated NUD NADV message is received from any validating port for which an entry in the Pending NUD NADV Messages table exists: * The Current Port is changed to this port, Timeout_Valid is set to LIFETIME_VALID, and state is changed to VALID. * If the port is different to VP, the packets in the Pending Packets Buffer are forwarded. * All ports included in the Tested Ports list, except for the port for which the NUD NADV was received, are used to create new entries in the Port Blocking table, with Blocking Timeout equal to BLOCKING_TIMEOUT. Note that VP (the current Validating Port when the state was VALID) is never in the list. * The Tested Port list is cleared. o If the Pending NUD NADV Messages Counter is set to 0 (i.e. all the entries in the Pending NUD NADV Messages table have been deleted because its timers have expired): * The state is moved to NO_BIND. * All ports included in the Tested Ports list are used to create new entries in the Port Blocking table, with Blocking Timeout equal to BLOCKING_TIMEOUT. Note that VP (the current Validating Port when the state was VALID) is never in the list. * The Tested Port list is cleared. o If Timeout_valid for the Validating port VP expires, no action is taken 5. Performance benefits of the SEND SAVI perimetrical deployment It is worth to note that the perimetrical deployment result in much lower computing, memory and bandwidth requirements, and lower delay of the validation process, compared to a deployment scenario without defined borders (i.e. in which all ports are Validating). To understand this, consider the scenario depicted in the next figure, Bagnulo & Garcia-Martinez Expires April 29, 2010 [Page 15] Internet-Draft SEND SAVI October 2009 in which no perimeter is considered, so all ports behave as Validating. +--+ +--+ +--+ +--+ |H1| |H2| |H3| |R1| +--+ +--+ +--+ +--+ | | | | | | | | +-1-----2-+ +---------+ +-1-----2-+ | SEND- | | SEND- | | SEND- | | SAVI1 | | SAVI2 | | SAVI3 | +-3--4----+ +-1-----2-+ +--3------+ | | | | ------------------- --------------- Suppose node H1 wants to communicate with node H3, and no state exists for H1 in neither of the SEND SAVI switches. H1 sends a data packet to H3. This packet arrives to port 1 of SEND-SAVI1. SEND- SAVI1 then issues a secured NUD NSOL message towards H1, with the RSA option signing the message (which cannot be reused, since the nonce and timestamp should vary for each message). H1 answers to the received NSOL message issuing a secured NUD NADV message to SEND- SAVI1. Upon the reception and validation of the NUD NADV, SEND-SAVI1 updates its SEND SAVI DB and forwards subsequent packets (maybe the initial one, if it implements a Buffer of Pending Packets). Now a packet arrives to SEND-SAVI2, which does not have a binding for source address H1, so it generates a secured NUD NSOL message towards H1, that must be validated by H1, answered with a NUD NADV (with different nonce, and possibly timestamp, than the NUD NADV for SEND- SAVI1), and validated by SEND-SAVI2. The same would be required for SEND-SAVI3. Therefore H1 will receive and must validate as many NUD NSOL messages as new SEND SAVI devices being traversed by a packet. Additionally, it must secure and generate as many NUD NSOL messages as new SEND SAVI devices being traversed. Initial communication delay depends on the time to sequentially perform each of this operations. In a perimetrical deployment, only SEND-SAVI1 performs validation, and it is the only switch to perform forwarding decisions according to per-packet inspection of the source address of H1, since the rest of SEND SAVI devices forwards packets received from Trusted ports without further analysis. Additionally, interaction with H1 is reduced to one NUD message exchange. Bagnulo & Garcia-Martinez Expires April 29, 2010 [Page 16] Internet-Draft SEND SAVI October 2009 6. Security Considerations First of all, it should be noted that any SAVI solution will be as strong as the lower layer anchor that it uses. In particular, if the lower layer anchor is forgeable, then the resulting SAVI solution will be weak. For example, if the lower layer anchor is a MAC address that can be easily spoofed, then the resulting SAVI will not be stronger than that. On the other hand, if we use switch ports as lower layer anchors (and there is only one host connected to each port) it is likely that the resulting SAVI solution will be considerably more secure. SEND SAVI improves protection compared to conventional SAVI, as a result of the increased ability of SEND hosts to prove address ownership. A critical security consideration regarding to SEND SAVI deals with the need of proper configuration of the roles of the ports in a SEND SAVI deployment scenario. Regarding to security, the main requirement is that ports defining the protected perimeter SHOULD be configured as Validating. Not doing so will generate security breaches through which an attacker could send packets using any source address, regardless of the bindings established in other SEND SAVI devices. However, SEND SAVI is designed to allow even in this case communication for legitimate users. The worst case for the misconfiguration of the perimeter is then that two hosts may use the same source IPv6 address. The reasons for having a misconfigured perimeter, apart from initial misconfiguration, are the dynamic operations performed by layer-2 routing mechanisms, for example, as a result of a failure in a link or switching device. To prevent the security risks associated, in the case of changes in the topology of the SEND SAVI devices, all ports of a SEND SAVI device MAY be changed automatically to Validating. Note that neither connectivity nor the protection offered are compromised by operating in a mode in which all ports of the SEND SAVI devices operate in Validating mode (only performance is affected by this setting). SEND SAVI design aims to enforce anti-reply protection by relying only in solicited messages that must honor appropriate nonce treatment defined in SEND. SEND SAVI devices rely in information received from Validating ports (i.e. outside the protected domain) only after performing secured and validated RSOL/RADV exchange for router information, and NUD NSOL/NADV exchange for host information. Certificate distribution in SEND (CPS/CPA) is not protected by neither nonce nor timestamp, but it can be argued that the risk of replying this information is not relevant for SAVI operation. It is worth to note that the potential of Denial of Service attacks Bagnulo & Garcia-Martinez Expires April 29, 2010 [Page 17] Internet-Draft SEND SAVI October 2009 against the SEND SAVI network is increased due to the use of costly cryptographic operations in order to validate the address of the hosts. An attacker could generate packets using new source addresses in order to make the closest SEND SAVI device spend CPU time to generate a NUD NSOL. This attack can be used to drain CPU resources of SEND SAVI devices with a very low cost for the attacker. In order to solve this problem, ports for which packets with a given source address have been sent, but no binding was created, are blocked for some time (TIMEOUT_BLOCKING). This means that a legitimate user moving to a new port may have to wait up to TIMEOUT_BLOCKING time until communication is allowed. Note that a similar mechanism could be used in a pure port basis (i.e. not related with a specific source address). Another alternative for the attacker could be to generate packets that trigger SEND SAVI validation, and to answer the NUD NSOL with a valid response (provided it has generated private/public key pairs for the attack), in order to waste memory from the SEND SAVI device. This attack seems to be less attractive compared to the case in which the attacker does not need to waste its own CPU power. However, it should also be protected, since a host can have much more computing power to perform cryptographic operations than a switching device. Apart from rate limitation measured to protect SEND SAVI computing resources, a mechanism similar to the one proposed for [I-D.bagnulo-savi-fcfs], in which newer entries are overwritten instead of older ones, in the case that memory is exhausted, could be enforced. 7. Acknowledgments Thanks to Ana Kukec for her review and comments on this document. Marcelo Bagnulo is partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program. Alberto Garcia-Martinez is partly funded by T2C2, a Spanish R&D project. 8. Normative References [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Bagnulo & Garcia-Martinez Expires April 29, 2010 [Page 18] Internet-Draft SEND SAVI October 2009 Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [I-D.vogt-savi-framework] Vogt, C., "Source Address Validation Improvement Protocol Framework", draft-vogt-savi-framework-01 (work in progress), October 2009. [I-D.bagnulo-savi-fcfs] Nordmark, E. and M. Bagnulo, "First-Come First-Serve Source-Address Validation Implementation", draft-bagnulo-savi-fcfs-01 (work in progress), January 2009. Authors' Addresses Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6248814 Email: marcelo@it.uc3m.es URI: http://www.it.uc3m.es Alberto Garcia-Martinez Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6248782 Email: alberto@it.uc3m.es URI: http://www.it.uc3m.es Bagnulo & Garcia-Martinez Expires April 29, 2010 [Page 19]