< draft-ietf-savi-send-10.txt   draft-ietf-savi-send-11.txt >
SAVI Working Group M. Bagnulo SAVI Working Group M. Bagnulo
Internet-Draft A. Garcia-Martinez Internet-Draft A. Garcia-Martinez
Intended status: Standards Track UC3M Intended status: Standards Track UC3M
Expires: October 28, 2013 April 26, 2013 Expires: July 24, 2014 January 20, 2014
SEND-based Source-Address Validation Implementation SEND-based Source-Address Validation Improvement
draft-ietf-savi-send-10 draft-ietf-savi-send-11
Abstract Abstract
This memo describes SEND SAVI, a mechanism to provide source address This memo specifies SEND SAVI, a mechanism to provide source address
validation using the SEND protocol. The proposed mechanism is validation using the SEND protocol. The proposed mechanism
intended to complement ingress filtering techniques to provide a complements ingress filtering techniques to provide a finer
finer granularity on the control of the source addresses used. granularity on the control of IPv6 source addresses.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 28, 2013. This Internet-Draft will expire on July 24, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background to SEND SAVI . . . . . . . . . . . . . . . . . . . 4 2. Background to SEND SAVI . . . . . . . . . . . . . . . . . . . 4
2.1. Address Validation Scope . . . . . . . . . . . . . . . . . 4 2.1. Address Validation Scope . . . . . . . . . . . . . . . . . 4
2.2. Binding Creation for SEND SAVI . . . . . . . . . . . . . . 4 2.2. Binding Creation for SEND SAVI . . . . . . . . . . . . . . 4
2.3. SEND SAVI Protection Perimeter . . . . . . . . . . . . . . 7 2.3. SEND SAVI Protection Perimeter . . . . . . . . . . . . . . 7
2.4. Special cases . . . . . . . . . . . . . . . . . . . . . . 8 2.4. Special cases . . . . . . . . . . . . . . . . . . . . . . 8
3. SEND SAVI Specification . . . . . . . . . . . . . . . . . . . 9 3. SEND SAVI Specification . . . . . . . . . . . . . . . . . . . 10
3.1. SEND SAVI Data Structures . . . . . . . . . . . . . . . . 9 3.1. SEND SAVI Data Structures . . . . . . . . . . . . . . . . 10
3.2. SEND SAVI Device Configuration . . . . . . . . . . . . . . 10 3.2. SEND SAVI Device Configuration . . . . . . . . . . . . . . 11
3.3. Traffic Processing . . . . . . . . . . . . . . . . . . . . 11 3.3. Traffic Processing . . . . . . . . . . . . . . . . . . . . 11
3.3.1. Transit Traffic Processing . . . . . . . . . . . . . . 11 3.3.1. Transit Traffic Processing . . . . . . . . . . . . . . 12
3.3.2. Local Traffic Processing . . . . . . . . . . . . . . . 11 3.3.2. Local Traffic Processing . . . . . . . . . . . . . . . 12
3.4. SEND SAVI Port Configuration Guidelines . . . . . . . . . 24 3.4. SEND SAVI Port Configuration Guidelines . . . . . . . . . 25
3.5. VLAN Support . . . . . . . . . . . . . . . . . . . . . . . 25 3.5. VLAN Support . . . . . . . . . . . . . . . . . . . . . . . 26
3.6. Protocol Constants . . . . . . . . . . . . . . . . . . . . 25 3.6. Protocol Constants . . . . . . . . . . . . . . . . . . . . 26
4. Protocol Walkthrough . . . . . . . . . . . . . . . . . . . . . 26 4. Protocol Walkthrough . . . . . . . . . . . . . . . . . . . . . 26
4.1. Change of the attachment point of a host . . . . . . . . . 26 4.1. Change of the attachment point of a host . . . . . . . . . 26
4.1.1. Moving to a port of the same switch . . . . . . . . . 26 4.1.1. Moving to a port of the same switch . . . . . . . . . 26
4.1.2. Moving to a port of a different switch . . . . . . . . 27 4.1.2. Moving to a port of a different switch . . . . . . . . 28
4.2. Attack of a malicious host . . . . . . . . . . . . . . . . 28 4.2. Attack of a malicious host . . . . . . . . . . . . . . . . 29
4.2.1. M attaches to the same switch as the victim's 4.2.1. M attaches to the same switch as the victim's
switch . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.2. M attaches to a different switch to the victim's
switch . . . . . . . . . . . . . . . . . . . . . . . . 29 switch . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.2. M attaches to a different switch to the victim's
switch . . . . . . . . . . . . . . . . . . . . . . . . 30
5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 5. Security Considerations . . . . . . . . . . . . . . . . . . . 30
5.1. Protection Against Replay Attacks . . . . . . . . . . . . 30 5.1. Protection Against Replay Attacks . . . . . . . . . . . . 31
5.2. Protection Against Denial of Service Attacks . . . . . . . 31 5.2. Protection Against Denial of Service Attacks . . . . . . . 32
5.3. Residual threats . . . . . . . . . . . . . . . . . . . . . 32 5.3. Considerations on the deployment model for trust
5.4. Privacy considerations . . . . . . . . . . . . . . . . . . 33 anchors . . . . . . . . . . . . . . . . . . . . . . . . . 33
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 5.4. Residual threats . . . . . . . . . . . . . . . . . . . . . 34
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 5.5. Privacy considerations . . . . . . . . . . . . . . . . . . 34
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
8.1. Normative References . . . . . . . . . . . . . . . . . . . 33 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
8.2. Informative References . . . . . . . . . . . . . . . . . . 34 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 8.1. Normative References . . . . . . . . . . . . . . . . . . . 35
8.2. Informative References . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
This memo describes SEND SAVI (SEcure Neighbor Discovery Source This memo specifies SEND SAVI (SEcure Neighbor Discovery Source
Address Validation Implementation), a mechanism to provide source Address Validation Improvement), a mechanism to provide source
address validation for IPv6 networks using the SEND protocol address validation for IPv6 networks using the SEND protocol
[RFC3971]. The proposed mechanism is intended to complement ingress [RFC3971]. The proposed mechanism complements ingress filtering
filtering techniques to provide a finer granularity on the control of techniques to provide a finer granularity on the control of the
the source addresses used. source addresses used.
SEND SAVI uses the DAD_NSOL (Duplicate Address Detection Neighbor SEND SAVI uses the DAD_NSOL (Duplicate Address Detection Neighbor
SOLicitation) and the DAD_NADV (DAD Neighbor ADVertisement) messages SOLicitation) and the DAD_NADV (DAD Neighbor ADVertisement) messages
defined in [RFC4862], and the NUD_NSOL (Neighbor Unreachability defined in [RFC4862], and the NUD_NSOL (Neighbor Unreachability
Detection Neigbor SOLicitation) and NUD_NADV (NUD Neighbor Detection Neigbor SOLicitation) and NUD_NADV (NUD Neighbor
ADVertisement) messages defined in [RFC4861] to validate the address ADVertisement) messages defined in [RFC4861] to validate the address
ownership claim of a node. In addition, SEND SAVI uses RADV (Router ownership claim of a node. Using the information contained in these
ADVertisement) messages defined in [RFC4861] to identify routers, and messages, host IPv6 addresses are associated to switch ports, so that
therefore restrict the nodes which can generate packets containing data packets will be validated by checking for consistency in this
off-link IPv6 source addresses. Using the information contained in binding, as described in [RFC7039]. In addition, SEND SAVI prevents
these messages, host and router IPv6 addresses are associated to hosts from generating packets containing off-link IPv6 source
switch ports, so that data packets will be validated by checking for addresses.
consistency in this binding, as described in
[I-D.ietf-savi-framework].
Scalability of a distributed SAVI system comprised of multiple SEND Scalability of a distributed SAVI system comprising multiple SEND
SAVI devices is preserved by means of a deployment scenario in which SAVI devices is preserved by means of a deployment scenario in which
SEND SAVI devices form a "protection perimeter". In this deployment SEND SAVI devices form a "protection perimeter". In this deployment
scenario, validation is only performed when the packet ingress to the scenario, the distributed SAVI system only validates the packets when
protection perimeter. they ingress to the protection perimeter, not in every SEND SAVI
device traversed.
The SEND SAVI specification, as defined in this document, is limited The SEND SAVI specification, as defined in this document, is limited
to links and prefixes in which every IPv6 host and every IPv6 router to links and prefixes in which every IPv6 host and every IPv6 router
uses the SEND protocol [RFC3971] to protect the exchange of Neighbor uses the SEND protocol [RFC3971] to protect the exchange of Neighbor
Discovery information. Discovery information. If the SEND protocol is not used, we can
deploy other SAVI solutions relying on monitoring different address
configuration mechanisms to prove address ownership. For example,
FCFS (First-Come, First-Served) SAVI [RFC6620] can be used by nodes
locally configuring IPv6 addresses by means of the Stateless Address
Autoconfiguration mechanism [RFC4862].
SEND SAVI is designed to be deployed in SEND networks with a minimum SEND SAVI is designed to be deployed in SEND networks with as few
set of changes. In particular, SEND SAVI does not require any changes to the deployed implementations as possible. In particular,
changes in the nodes whose source address is to be verified. This is SEND SAVI does not require any changes in the nodes whose source
because verification solely relies in the usage of already available address is to be verified. This is because verification solely
protocols. Therefore, SEND SAVI does neither define a new protocol, relies in the usage of already available protocols. Therefore, SEND
nor define any new message on existing protocols, nor require that a SAVI does neither define a new protocol, nor define any new message
host or router uses an existing protocol message in a different way. on existing protocols, nor require that a host or router uses an
existing protocol message in a different way.
An overview of the general framework about Source Address Validation An overview of the general framework about Source Address Validation
Implementation is presented in [I-D.ietf-savi-framework]. Improvement is presented in [RFC7039].
2. Background to SEND SAVI 2. Background to SEND SAVI
2.1. Address Validation Scope 2.1. Address Validation Scope
The application scenario of SEND SAVI is limited to the local link. The application scenario of SEND SAVI is limited to the local link.
This means that the goal of SEND SAVI is to verify that the source This means that the goal of SEND SAVI is to verify that the source
addresses of the packets generated by the nodes attached to the local addresses of the packets generated by the nodes attached to the local
link have not been spoofed, and that only legitimate routers generate link have not been spoofed, and that only legitimate routers generate
packets with off-link IPv6 source addresses. packets with off-link IPv6 source addresses.
skipping to change at page 4, line 25 skipping to change at page 4, line 26
In a link there usually are hosts and routers attached. Hosts In a link there usually are hosts and routers attached. Hosts
generate packets with their own addresses as the source address. generate packets with their own addresses as the source address.
This is called local traffic. Routers may send packets containing a This is called local traffic. Routers may send packets containing a
source address other than their own, since they can forward packets source address other than their own, since they can forward packets
generated by other hosts (usually located in a different link). This generated by other hosts (usually located in a different link). This
is the so-called transit traffic. is the so-called transit traffic.
SEND SAVI allows the validation of the source address of the local SEND SAVI allows the validation of the source address of the local
traffic, i.e., it allows to verify that the source addresses of the traffic, i.e., it allows to verify that the source addresses of the
packets generated by the nodes attached to the local link have not packets generated by the nodes attached to the local link have not
been spoofed. In addition, since SEND does provide the means to been spoofed. SEND SAVI also provides means to prevent hosts from
verify that a node claiming to act as a router is indeed authorized
to do so, SEND SAVI also provides means to prevent hosts from
generating packets with source addresses derived from off-link generating packets with source addresses derived from off-link
prefixes. However, SEND SAVI does not provide the means to verify if prefixes. However, SEND SAVI does not provide the means to verify if
a given router is actually authorized to forward packets containing a a given router is actually authorized to forward packets containing a
particular off-link source address. Other techniques, like ingress particular off-link source address. Other techniques, like ingress
filtering [RFC2827], are recommended to validate transit traffic. filtering [RFC2827], are recommended to validate transit traffic.
2.2. Binding Creation for SEND SAVI 2.2. Binding Creation for SEND SAVI
Filtering is performed according to bindings between a layer-2 anchor SEND SAVI devices filter packets according to bindings between a
(the binding anchor) and an IPv6 address. These bindings should layer-2 anchor (the binding anchor) and an IPv6 address. These
allow legitimate nodes to use the bounded IPv6 address as source bindings should allow legitimate nodes to use the bounded IPv6
address, and prevent illegitimate nodes to do so. address as source address, and prevent illegitimate nodes to do so.
Any SAVI solution is not stronger than the binding anchor it uses. Any SAVI solution is not stronger than the binding anchor it uses.
If the binding anchor is easily spoofable (e.g., a Media Access If the binding anchor is easily spoofable (e.g., a Media Access
Control (MAC) address), then the resulting solution will be weak. Control (MAC) address), then the resulting solution will be weak.
The treatment of non-compliant packets needs to be tuned accordingly. The treatment of non-compliant packets needs to be tuned accordingly.
In particular, if the binding anchor is easily spoofable and the SEND In particular, if the binding anchor is easily spoofable and the SEND
SAVI device is configured to drop non-compliant packets, then the SAVI device is configured to drop non-compliant packets, then the
usage of FCFS SAVI may open a new vector of Denial-of-Service (DoS) usage of SEND SAVI may open a new vector of Denial-of-Service (DoS)
attacks, based on spoofed binding anchors. For that reason, in this attacks, based on spoofed binding anchors. For that reason,
specification, only switch ports MUST be used as binding anchors. implementations of this specification use switch ports as their
Other forms of binding anchors are out of the scope of this binding anchors. Other forms of binding anchors are out of the scope
specification, and proper analysis of the implications of using them, of this specification, and proper analysis of the implications of
should be performed before their usage. using them, should be performed before their usage.
SEND [RFC3971] provides tools to assure that a ND (Neighbor SEND [RFC3971] provides tools to assure that a ND (Neighbor
Discovery) message containing a CGA (Cryptographically Generated Discovery) message containing a CGA (Cryptographically Generated
Addresses) option and signed by a RSA option has been generated by Addresses) option and signed by a RSA option has been generated by
the legitimate owner of the CGA IPv6 address. It also provides tools the legitimate owner of the CGA IPv6 address.
to verify that a Router Advertisement (RADV) message signed by a RSA
option with a key bounded to a CGA [RFC3972] or a certificate, has
been generated by a legitimate router.
SEND SAVI uses SEND validated messages to create bindings between the SEND SAVI uses SEND validated messages to create bindings between the
CGA and the port of the SEND SAVI device from which it is reasonable CGA and the port of the SEND SAVI device from which it is reasonable
to receive packets with the CGA as source addresses. The events that to receive packets with the CGA as source addresses. The events that
trigger the binding creation process in a SEND SAVI device are: trigger the binding creation process in a SEND SAVI device are:
o The reception of a DAD_NSOL message, indicating the attempt of a o The reception of a DAD_NSOL message, indicating the attempt of a
node to configure an address. This may occur when a node node to configure an address. This may occur when a node
configures an address for the first time or after being idle for configures an address for the first time or after being idle for
some time, or when the node has changed the physical attachment some time, or when the node has changed the physical attachment
point to the layer-2 infrastructure. point to the layer-2 infrastructure.
o The reception of any other packet (including data packets) with a o The reception of any other packet (including data packets) with a
source address for which no binding exists. This would occur if source address for which no binding exists. This may occur if
DAD_NSOL messages were lost, a node has changed the physical DAD_NSOL messages were lost, a node has changed the physical
attachment point to the layer-2 infrastructure without issuing a attachment point to the layer-2 infrastructure without issuing a
DAD_NSOL message, a SAVI device loses a binding (for example, due DAD_NSOL message, a SAVI device loses a binding (for example, due
to a restart), or the link topology changed. to a restart), or the link topology changed.
When the binding creation process is triggered, the SEND SAVI device When the binding creation process is triggered, the SEND SAVI device
has to assure that the node for which the binding is to be created is has to assure that the node for which the binding is to be created is
the legitimate owner of the address. For the case in which the the legitimate owner of the address. For the case in which the
binding creation process initiated by a DAD_NSOL exchange, the SEND binding creation process initiated by a DAD_NSOL exchange, the SEND
SAVI device waits for the reception of a validated DAD_NADV message SAVI device waits for the reception of a validated DAD_NADV message
indicating that other node had configured the address before, or indicating that other node had configured the address before, or
validated DAD_NSOL messages arriving from other locations indicating validated DAD_NSOL messages arriving from other locations indicating
that another node is trying to configure the same address at the same that another node is trying to configure the same address at the same
time. For the case in which other packets than a DAD_NSOL initiate time. For the case in which other packets than a DAD_NSOL initiate
the creation of the binding, the SEND SAVI device explicitly requires the creation of the binding, the SEND SAVI device explicitly requires
the node sending those packets to prove address ownership by issuing the node sending those packets to prove address ownership by issuing
a secured NUD_NSOL which has to be answered by a secured NUD_NADV by a secured NUD_NSOL which has to be answered with a secured NUD_NADV
the probed node. by the probed node.
Bindings are refreshed periodically by means of secured NUD_NSOL SEND SAVI devices issue secured NUD_NSOL messages periodically in
message issued by the SEND SAVI device, which had to be answered by a order to refresh bindings, which had to be answered with a valid
valid NUD_NADV message by the node for which the binding exists. NUD_NADV message by the node for which the binding exists.
Validated RADV messages are used to associate router authorization to SEND SAVI devices only forward packets with off-link source addresses
existing bindings (i.e., to an IPv6 address which is also associated if they are received from a port manually configured to connect to a
to a port). Packets with off-link source addresses are only router.
forwarded if they are received from a port associated to the IPv6
address of a router.
SEND SAVI needs to be protected against replay attacks, i.e., attacks SEND SAVI needs to be protected against replay attacks, i.e., attacks
in which a secured SEND message is replayed by another node. As in which a secured SEND message is replayed by another node. As
discussed before, the SEND SAVI specification uses SEND messages to discussed before, the SEND SAVI specification uses SEND messages to
create a binding between the address contained in the message (that create a binding between the address contained in the message (that
must be signed by a node possessing the private key associated to the must be signed by a node possessing the private key associated to the
address) and the port through which the message is received. If an address) and the port through which the message is received. If an
attacker manages to obtain such a message from another node, for attacker manages to obtain such a message from another node, for
example because the message was sent to the all-nodes multicast example because the message was sent to the all-nodes multicast
address or because the attacker has subscribed to the Solicited Node address or because the attacker has subscribed to the Solicited Node
skipping to change at page 6, line 34 skipping to change at page 6, line 30
possible differences in clock synchronization between sender and possible differences in clock synchronization between sender and
receiver(s). For example, with the values recommended by [RFC3971] receiver(s). For example, with the values recommended by [RFC3971]
for TIMESTAMP_FUZZ and TIMESTAMP_DRIFT, a node receiving a DAD_NSOL for TIMESTAMP_FUZZ and TIMESTAMP_DRIFT, a node receiving a DAD_NSOL
message would not discard replays of this message being received message would not discard replays of this message being received
within a period of approximately 2 seconds (more precisely, 2/0.99 within a period of approximately 2 seconds (more precisely, 2/0.99
seconds). The underlying assumption for SEND security is that even seconds). The underlying assumption for SEND security is that even
if the message is replayed by another node during this period of if the message is replayed by another node during this period of
time, the information disseminated by ND is still the same. However, time, the information disseminated by ND is still the same. However,
allowing a node to replay a SEND message do have impact to SEND SAVI allowing a node to replay a SEND message do have impact to SEND SAVI
operation, regardless the time elapsed since it was generated, since operation, regardless the time elapsed since it was generated, since
it can create a new binding in a SEND SAVI device for the port to the node can create a new binding in a SEND SAVI device for the port
which an illegitimate node attaches. As can be concluded, the to which an illegitimate node attaches. As can be concluded, the
protection provided by SEND is not enough in all cases for SEND SAVI. protection provided by SEND is not enough in all cases for SEND SAVI.
SEND SAVI is designed to increase the protection against the replay SEND SAVI increases the protection against the replay attacks
attacks compared to SEND. First, each node is required to connect to compared to SEND. First, each node is required to connect to the
the SEND SAVI topology through a different port to prevent SEND SAVI topology through a different port to prevent eavesdropping
eavesdropping before entering to the SAVI protection perimeter. before entering to the SAVI protection perimeter. Then, SEND SAVI
Then, SEND SAVI bindings are updated only according to messages whose bindings are updated only according to messages whose dissemination
dissemination can be restricted in the SEND SAVI topology without can be restricted in the SEND SAVI topology without interfering with
interfering with normal SEND operation. The messages used by SEND normal SEND operation. The messages used by SEND SAVI to create
SAVI to create bindings are DAD_NSOL messages, for which SEND SAVI bindings are DAD_NSOL messages, for which SEND SAVI limits its
limits its propagation to the ports through which a previous binding propagation to the ports through which a previous binding for the
for the same IPv6 address existed (see Section 3.3.2), and NUD_NADV same IPv6 address existed (see Section 3.3.2), and NUD_NADV messages
messages in response to a secured NUD_NSOL sent by the SEND SAVI in response to a secured NUD_NSOL sent by the SEND SAVI device only
device only through the tested port. Finally, SEND SAVI filtering through the tested port. Finally, SEND SAVI filtering rules prevent
rules prevent nodes from replaying messages generated by the SEND nodes from replaying messages generated by the SEND SAVI devices
SAVI devices themselves. Section 5.1 discusses in more detail the themselves. Section 5.1 discusses in more detail the protection
protection provided by SEND SAVI against replay attacks. provided by SEND SAVI against replay attacks.
2.3. SEND SAVI Protection Perimeter 2.3. SEND SAVI Protection Perimeter
In order to reduce computing and state requirements in SEND SAVI In order to reduce computing and state requirements in SEND SAVI
devices, SEND SAVI devices can be deployed to form a "protection devices, SEND SAVI devices can be deployed to form a "protection
perimeter" [I-D.ietf-savi-framework]. With this deployment strategy, perimeter" [RFC7039]. With this deployment strategy, SEND SAVI
source address validation is performed only when packets enter in the devices perform source address validation only when packets enter in
protected realm defined through the protection perimeter. The the protected realm defined through the protection perimeter. The
perimeter is defined by appropriate configuration of the roles of perimeter is defined by appropriate configuration of the roles of
each port, which can be 'Validating' or 'Trusted': each port, which can be 'Validating' or 'Trusted':
o Validating ports (VPs) are those in which SEND SAVI filtering and o Validating ports (VPs) are ports in which SEND SAVI filtering and
binding creation is performed. binding creation is performed.
o Trusted ports (TPs) are ports in which limited processing is o Trusted ports (TPs) are ports in which limited processing is
performed. Only SEND messages related with certificates, prefix performed. Only SEND messages related with certificates, prefix
information and DAD operation are processed, in order to update information and DAD operation are processed, in order to update
the state of the SEND SAVI device or the state related with any of the state of the SEND SAVI device or the state related with any of
the Validating ports of the switch. the Validating ports of the switch.
The following figure shows a typical topology involving trusted and The following figure shows a typical topology involving trusted and
untrusted infrastructure. untrusted infrastructure.
skipping to change at page 8, line 6 skipping to change at page 8, line 6
| | SAVI3 | | SAVI4 | | | | SAVI3 | | SAVI4 | |
| +-3-----4-+ +----4----+ | | +-3-----4-+ +----4----+ |
| | | | | | | | | |
+------------SEND SAVI PROTECTION PERIMETER-----------+ +------------SEND SAVI PROTECTION PERIMETER-----------+
| | | | | |
+--+ +--+ +--+ +--+ +--+ +--+
|R2| |H4| |H5| |R2| |H4| |H5|
+--+ +--+ +--+ +--+ +--+ +--+
Trusted ports are used for connections with trusted infrastructure, Trusted ports are used for connections with trusted infrastructure,
such as other SEND SAVI devices. Port 3 of SEND-SAVI1 and port 1 of such as routers and other SEND SAVI devices. Port 2 of SEND-SAVI2
SEND-SAVI3, and port 4 of SEND-SAVI2 and port 1 of SEND-SAVI4 are and port 3 of SEND-SAVI3 are Validating ports because they connect to
trusted because they connect two SAVI devices. Port 4 of SEND-SAVI1, routers. Port 3 of SEND-SAVI1 and port 1 of SEND-SAVI3, and port 4
port 3 of SEND-SAVI2 and port 2 of SEND-SAVI3 are trusted because of SEND-SAVI2 and port 1 of SEND-SAVI4 are trusted because they
they connect to SWITCH-A to which only trusted nodes are connected. connect two SAVI devices. Finally, port 4 of SEND-SAVI1, port 3 of
SEND-SAVI2 and port 2 of SEND-SAVI3 are trusted because they connect
to SWITCH-A to which only trusted nodes are connected.
Validating ports are used for connection with non-trusted Validating ports are used for connection with non-trusted
infrastructure. Therefore, hosts are normally connected to infrastructure. Therefore, hosts connect normally to Validating
Validating ports. Routers are also recommended to be connected to ports. So, in the figure above, ports 1 and 2 of SEND-SAVI1, port 1
Validating ports, although they could also be attached to Trusted of SEND-SAVI2, port 4 of SEND-SAVI3 are Validating ports because they
ports. For a more detailed discussion on this, see Section 3.4. So, connect to hosts. Port 4 of SEND-SAVI4 is also a Validating port
in the figure above, ports 1 and 2 of SEND-SAVI1, port 1 of SEND- because it is connected to host H5.
SAVI2, port 4 of SEND-SAVI3 are Validating ports because they connect
to hosts. Port 2 of SEND-SAVI2 and port 3 of SEND-SAVI3 are For a more detailed discussion on this, see Section 3.4.
Validating ports because they connect to routers. Port 4 of SEND-
SAVI4 is also a Validating port because it is connected to host H5.
2.4. Special cases 2.4. Special cases
Multi-subnet links: In some cases, a given subnet may have several Multi-subnet links: In some cases, a given subnet may have several
prefixes. This is supported by SEND SAVI as any port can support prefixes. This is supported by SEND SAVI as any port can support
multiple prefixes. multiple prefixes.
Multihomed hosts: A multihomed host is a host with multiple Multihomed hosts: A multihomed host is a host with multiple
interfaces. The interaction between SEND SAVI and multihomed hosts interfaces. The interaction between SEND SAVI and multihomed hosts
is as follows. If the different interfaces of the host are assigned is as follows. If the different interfaces of the host are assigned
different IP addresses and packets sent from each interface always different IP addresses and packets sent from each interface always
carry the address assigned to that interface as source address, then carry the address assigned to that interface as source address, then
from the perspective of a SEND SAVI device, this is equivalent to two from the perspective of a SEND SAVI device, this is equivalent to two
hosts with a single interface, each with an IP address. This is hosts with a single interface, each with an IP address. SEND SAVI
supported by SAVI without need for additional considerations. If the supports this without additional considerations. If the different
different interfaces share the same IP address or if the interfaces interfaces share the same IP address or if the interfaces have
have different addresses but the host sends packets using the address different addresses but the host sends packets using the address of
of one of the interfaces through any of the interfaces, then SEND one of the interfaces through any of the interfaces, then SEND SAVI
SAVI does not directly support it. It would require either does not directly support it. It would require either connecting at
connecting at least one interface of the multihomed host to a Trusted least one interface of the multihomed host to a Trusted port, or
port, or manually configure the SEND SAVI bindings to allow binding manually configure the SEND SAVI bindings to allow binding the
the address of the multihomed host to multiple anchors address of the multihomed host to multiple anchors simultaneously.
simultaneously.
Virtual switches: A hypervisor or a host Operating System may perform
bridging functions between virtual hosts running on the same machine.
The hypervisor or host OS may in turn connect to a SEND SAVI system.
This scenario is depicted in the next figure, with two virtual
machines VM1 and VM2 connected through a virtual switch VS1 to SEND
SAVI device SEND-SAVI1. The attachment points of VS1 to VM1 and VM2
are configured as Validating.
Host1
+----------------+
| +---+ +---+ |
| |VM1| |VM2| |
| +---+ +---+ |
| | | |
| +-1-----2--+ |
| | VS1 | |
| +--3-------+ |
| | |
+----|-----------+
|
|
+--1-----2--+
| SEND- |
| SAVI1 |
+--3---4----+
| |
In order to provide proper security against replay attacks, it is
recommended to perform SEND SAVI filtering as close to untrusted
hosts as possible (see Section 3.4 and Section 5.1). In this
scenario, this objective can be achieved by enabling SEND SAVI
validation in VS1. Ideally, VS1 could be integrated into the SEND
SAVI protection perimeter, if the hypervisor or host OS at Host1 can
be trusted (even though VM1 and VM2 could not be trusted). To do so,
both the attachment to SEND-SAVI1 at VS1, and port 1 at SEND-SAVI1,
are configured as Trusted.
If the administrator of the network does not trust on VS1, port 1 of
SEND-SAVI1 is configured as Validating, so that every address being
used at Host1 is validated at SEND-SAVI1 by SEND SAVI. The
attachment point to the physical network at VS1 should be configured
as Trusted, if the host administrator knows that it is connected to a
SEND SAVI device; in this case, VS1 relies on the infrastructure
comprised by the physical SEND SAVI devices, but not the other way.
Packets egressing from VM1 are validated twice, first at VS1, and
then at SEND-SAVI1; packets going in the reverse direction (from an
external host to VM1) are validated once, when they first reach a
SEND SAVI device. If the administrator of VS1 does not trust on the
physical switch to which it attaches, it can configure the attachment
to SEND-SAVI1 as Validating. In the figure above, this means that a
packet going from another host to VM1 would be validated twice, once
when entering the SEND SAVI perimeter formed by the physical devices,
and the other when entering at VS1.
Untrusted routers: One can envision scenarios where routers are Untrusted routers: One can envision scenarios where routers are
dynamically attached to a SEND SAVI network. A typical example would dynamically attached to a SEND SAVI network. A typical example would
be a mobile phone connecting to a SEND SAVI switch where the mobile be a mobile phone connecting to a SEND SAVI switch where the mobile
phone is acting as a router for other personal devices that are phone is acting as a router for other personal devices that are
accessing the network through it. In this case, the router does not accessing the network through it. Regarding to the validation of the
seem to directly fall in the category of Trusted infrastructure (as source address performed in a SEND SAVI device, such an untrusted
if this was the case, it is likely that all devices would be router does not seem to directly fall in the category of Trusted
trusted), hence it cannot be connected to a trusted port and if it is infrastructure (as if this was the case, it is likely that all
connected to a Validating port, the SEND SAVI switch would discard devices would be trusted), hence it cannot be connected to a trusted
all the packets containing an off-link source address coming from port and if it is connected to a Validating port, the SEND SAVI
that device. As a result, the default recommendation specified in switch would discard all the packets containing an off-link source
this specification does not support such a scenario. address coming from that device. Although the SEND SAVI device to
which this router attaches could be configured to permit the transit
of packets with source addresses belonging to the set of prefixes
reachable through the untrusted router, such a mechanism is out of
the scope of this document. As a result, the default mechanism
described in this specification cannot be applied in such a scenario.
3. SEND SAVI Specification 3. SEND SAVI Specification
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3.1. SEND SAVI Data Structures 3.1. SEND SAVI Data Structures
The following three data structures are defined for SEND SAVI The following three data structures are defined for SEND SAVI
skipping to change at page 9, line 41 skipping to change at page 11, line 6
TESTING_VP' TESTING_VP'
o Alternative binding anchor: port from which a DAD_NSOL message or o Alternative binding anchor: port from which a DAD_NSOL message or
any data packet has been received while a different port was any data packet has been received while a different port was
stored in the binding anchor for the address. stored in the binding anchor for the address.
o Creation time: the value of the local clock when the entry was o Creation time: the value of the local clock when the entry was
firstly created firstly created
SEND SAVI Prefix list. SEND SAVI devices need to know which are the SEND SAVI Prefix list. SEND SAVI devices need to know which are the
link prefixes in order to identify local and off-link traffic. A link prefixes in order to identify local and off-link traffic. A
SEND SAVI device MUST support discovering this information from the SEND SAVI device MUST support discovering this information from the
Prefix Information option [RFC4861] with the L set bit set of Prefix Information option [RFC4861] with the L set bit set of RADV
validated RADV messages, either coming from Validating or Trusted messages coming from Trusted ports, as described in Section 3.3.2.
ports, as described in Section 3.3.2. The list of prefixes MAY also The list of prefixes MAY also be configured manually. This
be configured manually. This information is not specific to a given information is not specific to a given port. The SEND SAVI Prefix
port. The SEND SAVI Prefix list contains one entry per prefix in list contains one entry per prefix in use, as follows:
use, as follows:
o Prefix: prefix included in a Prefix Information option o Prefix: prefix included in a Prefix Information option
o Prefix lifetime: time in seconds that the prefix is valid. o Prefix lifetime: time in seconds that the prefix is valid.
Initially set to the Valid Lifetime value of the Prefix Initially set to the Valid Lifetime value of the Prefix
Information option of a valid RADV message, or set to a value of Information option of a valid RADV message, or set to a value of
all one bits (0xffffffff), which represents infinity, if all one bits (0xffffffff), which represents infinity, if
configured manually. configured manually.
When the SEND SAVI device boots, it MUST send a Router Solicitation When the SEND SAVI device boots, it MUST send a Router Solicitation
(RSOL) message, which does not need to be secured if the unspecified (RSOL) message, which does not need to be secured if the unspecified
address is used (see [RFC3971], sections 5.1.1 and 5.2.1). The SAVI address is used (see [RFC3971], sections 5.1.1 and 5.2.1). The SAVI
device SHOULD issue a RSOL message in case the prefix entry is about device SHOULD issue a RSOL message in case the prefix entry is about
to expire. to expire.
SEND SAVI Router list. SEND SAVI keeps a table with one entry for
each authorized router in use connected to a Validating port of the
SAVI device. A SEND SAVI device MUST support discovering this
information from a validated RADV message received from a Validating
port, addressed to the all-nodes multicast address or to the IPv6
address of the SEND SAVI device. Alternatively, the list of routers
MAY be configured manually. The information stored in the table is
the following:
o IPv6 address of the Router. There MUST be an entry in the SEND
SAVI Data Base for the same IPv6 address. If the corresponding
entry in the SEND SAVI Data Base expires, the entry in this table
MUST be removed.
o Router lifetime: Lifetime associated with the default router in
units of seconds. Initially set to the Router Lifetime of a valid
RADV message. If the router lifetime expires, the entry in this
table is removed.
3.2. SEND SAVI Device Configuration 3.2. SEND SAVI Device Configuration
In order to perform SEND SAVI operation, some basic parameters of the In order to perform SEND SAVI operation, some basic parameters of the
SEND SAVI device have to be configured. Since a SEND SAVI device SEND SAVI device have to be configured. Since a SEND SAVI device
operates as a SEND node to generate NUD_NSOL, RSOL or Certification operates as a SEND node to generate NUD_NSOL, RSOL or Certification
Path Solicitation (CPS) messages, Path Solicitation (CPS) messages,
o the SEND SAVI device MUST be configured with a valid CGA address. o the SEND SAVI device MUST be configured with a valid CGA address.
This CGA address SHOULD be a link-local address, to recover from
the following situation: the DAD_NSOL message used by a router
when it configures its link-local address has not been received,
so a binding has not been created for the router address. If the
port to which the router connects is a Validating port, the SEND
SAVI device cannot accept any packet, so no RADV issued by the
router will be accepted. Then, the SEND SAVI device may not
receive prefix configuration to configure any other address than a
link-local. However, if the SEND SAVI device configures a link-
local CGA, it can issue a NUD_NSOL to the router, and create the
binding according to the process described in Section 3.3.2.
When the SEND SAVI device configures this address, it MUST behave When the SEND SAVI device configures this address, it MUST behave
as regular SEND node, i.e., using secured NSOL messages to perform as regular SEND node, i.e., using secured NSOL messages to perform
DAD, etc., in addition to fulfill the requirements stated for DAD, etc., in addition to fulfill the requirements stated for
regular IPv6 nodes [RFC6434]. regular IPv6 nodes [RFC6434].
o the SEND SAVI device MAY be configured with at least one trust
anchor, if it is configured to validate RADV messages (see
Section 3.3.2). In this case the SEND SAVI device MAY be
configured with certification paths. The alternative is obtaining
them by means of issuing Certification Path Solicitation messages,
as detailed in the SEND specification SEND specification
[RFC3971].
o the SEND SAVI device MUST be configured with at least one trust In addition, the port role for each port of the SEND SAVI device MUST
anchor to validate the Certification Paths that is used to be configured. The guidelines for this configuration are specified
validate router information. in Section 3.4.
o the SEND SAVI device MAY be configured with Certification Paths.
The alternative is obtaining them by means of issuing
Certification Path Solicitation messages, as detailed in the SEND
specification [RFC3971].
In addition, the port role for each port of the SEND SAVI device
SHOULD be configured. The guidelines for this configuration are
specified in Section 3.4. Unconfigured ports MUST be labeled as
Validating ports; in this case performance may be degraded, as
discussed in [I-D.ietf-savi-framework].
3.3. Traffic Processing 3.3. Traffic Processing
In this section we describe how packets are processed by a SEND SAVI In this section we describe how packets are processed by a SEND SAVI
device. Behavior varies depending on if the packet belongs to local device. Behavior varies depending on if the packet belongs to local
or transit traffic. This is determined by checking if the prefix of or transit traffic. This is determined by checking if the prefix of
the source address is included in the SEND SAVI prefix list or the the source address is included in the SEND SAVI prefix list or the
unspecified address (local traffic), or not included in the SEND SAVI unspecified address (local traffic), or not included in the SEND SAVI
prefix list (transit traffic). prefix list (transit traffic).
3.3.1. Transit Traffic Processing 3.3.1. Transit Traffic Processing
Transit traffic processing occurs as follows: Transit traffic processing occurs as follows:
o If the transit traffic packet is received through a Trusted port, o If the SEND SAVI device receives a transit traffic packet through
the data packet is forwarded and no SAVI processing performed. a Trusted port, it forwards it without any SAVI processing.
o If the transit traffic packet is received through a Validating o If the SEND SAVI device receives a transit traffic packet through
port, the packet is only forwarded if the port through which the a Validating port, it discards the packet.
packet has been received is associated to the port of an IPv6
address for which an entry in the Router list exists. If transit
traffic is received from a Validating port which is not associated
to an entry in the SEND SAVI Router list, the SEND SAVI device
SHOULD discard the packets, and MAY send a RSOL message to the
all-routers multicast address to the port through which the packet
was received.
3.3.2. Local Traffic Processing 3.3.2. Local Traffic Processing
If the verification of the source address of a packet shows that it If the verification of the source address of a packet shows that it
belongs to local traffic, this packet is processed using the state belongs to local traffic, this packet is processed using the state
machine described in this section. SEND SAVI is designed to perform machine described in this section.
source address validation for both hosts and routers, so in the
following description we refer to nodes.
For the rest of the section, the following assumptions hold: 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 o When it is stated that a secured NUD_NSOL message is issued by a
SEND SAVI device through a port P, this means the following: the SEND SAVI device through a port P, this means the following: the
SEND SAVI device generates a NUD_NSOL message according to the SEND SAVI device generates a NUD_NSOL message according to the
Neighbor Unreachability Detection procedure described in Neighbor Unreachability Detection procedure described in
[RFC4861], addressed to the IPv6 target address, which is the [RFC4861], addressed to the IPv6 target address, which is the
source address of the packet triggering the procedure. This source address of the packet triggering the procedure. This
message is secured by SEND as defined in [RFC3971]. The source message is secured by SEND as defined in [RFC3971]. The source
address used for issuing the NUD_NSOL message is the source address used for issuing the NUD_NSOL message is the source
address of the SEND SAVI device. The message is sent only through address of the SEND SAVI device. The message is sent only through
port P. port P.
skipping to change at page 13, line 7 skipping to change at page 13, line 26
The SEND SAVI device MUST join the Solicited Node Multicast group for The SEND SAVI device MUST join the Solicited Node Multicast group for
all the addresses whose state is other than NO_BIND. This is needed all the addresses whose state is other than NO_BIND. This is needed
to make sure that the SEND SAVI device receives DAD_NSOL messages to make sure that the SEND SAVI device receives DAD_NSOL messages
issued for those addresses. Note that it may not be enough to relay issued for those addresses. Note that it may not be enough to relay
on the Multicast Listener Discovery (MLD) messages being sent by the on the Multicast Listener Discovery (MLD) messages being sent by the
node attached to a Validating port for which a binding for the node attached to a Validating port for which a binding for the
corresponding address exist, since the node may move and packets sent corresponding address exist, since the node may move and packets sent
to that particular Solicited Node Multicast group may no longer be to that particular Solicited Node Multicast group may no longer be
forwarded to the SEND SAVI device. forwarded to the SEND SAVI device.
SEND SAVI devices MUST support the processing of validated
Certification Path Advertisement (CPA) messages, sent in reply to CPS
messages, to acquire certificates used to validate ND messages. In
order to process a CPA message received from a Validating port, an
entry for the source address of the message MUST exist in the SEND
SAVI Data Base. CPA messages received from Trusted ports are always
checked and processed.
SEND SAVI devices MUST use validated RADV messages to update the SEND
SAVI Prefix list and the SEND SAVI Router list. SEND SAVI devices
MAY only consider for updating these structures RADV messages
addressed to either its own IPv6 address or to the all-nodes
multicast address. Validated RADV messages received from Trusted
ports MUST be used to update the SEND SAVI Prefix and Router lists in
the SEND SAVI device. RADV messages received from Validating ports
are only processed for updating the SEND SAVI Router and Prefix lists
if a binding for the source IPv6 address of the RADV message is in a
forwarding state.
In order to determine which traffic is on-link and off-link, the SEND In order to determine which traffic is on-link and off-link, the SEND
SAVI device MUST support discovery of this information from the SAVI device MUST support discovery of this information from the
Prefix Information option with the L set bit set of validated RADV Prefix Information option with the L set bit set of RADV messages.
messages. In this case, at least one router MUST be configured to In this case, at least one router SHOULD be configured to advertise
advertise RADV messages containing a Prefix Information option with RADV messages containing a Prefix Information option with the
the prefixes that the untrusted nodes can use as source addresses, prefixes that the untrusted nodes can use as source addresses, and
and the bit L set. An alternative to this is to configure manually the bit L set. An alternative to this is to configure manually the
the SEND SAVI prefix list. SEND SAVI prefix list, or restrict to the use of link-local
addresses.
SEND SAVI devices MUST discard RADV messages received from Validating
ports. RADV messages are only accepted and processed when received
through Trusted ports.
SEND SAVI devices SHOULD NOT validate RADV messages to update the
SEND SAVI Prefix list and forward them to other nodes. These
messages can only be received from Trusted ports, and we assume that
routers are trusted. Validating RADV messages would be required in
any SEND SAVI device the node is traversing. Besides, hosts will
validate this message before using the information it contains.
In case SEND SAVI devices are configured to validate RADV message,
SEND SAVI devices SHOULD support the processing of validated
Certification Path Advertisement (CPA) messages, sent in reply to CPS
messages, to acquire certificates used to validate router messages,
or alternatively SHOULD be configured with a certification path.
The state machine defined for SEND SAVI operation adheres to the The state machine defined for SEND SAVI operation adheres to the
following design guidelines: following design guidelines:
o The only events which trigger state changes from forwarding to o The only events which trigger state changes from forwarding to
non-forwarding states and vice versa are the reception of non-forwarding states and vice versa are the reception of
DAD_NSOL, DAD_NADV and NUD_NADV, or the expiration of a timer. DAD_NSOL, DAD_NADV and NUD_NADV, or the expiration of a timer.
The other possible input to consider is 'any other packet', which The other possible input to consider is 'any other packet', which
could generate changes to states belonging to the same forwarding could generate changes to states belonging to the same forwarding
or non-forwarding class as the original state. In other words, or non-forwarding class as the original state. In other words,
when 'any other packet' is received, the state cannot move from when 'any other packet' is received, the state cannot move from
being forwarding to non-forwarding and vice versa. A special case being forwarding to non-forwarding and vice versa. The reduced
of 'any other packet' is when validated RADV are received, which set of messages being able to trigger a change simplifies the
can result in the update of the SEND SAVI Prefix or Router lists. processing at SEND SAVI devices.
The reduced set of messages being able to trigger a change
simplifies the processing at SEND SAVI devices.
o DAD_NADV and NUD_NADV are only processed when they are a response o DAD_NADV and NUD_NADV are only processed when they are a response
to a DAD_NSOL or a NUD_NSOL message. to a DAD_NSOL or a NUD_NSOL message.
o SEND SAVI devices MUST only use ND messages received through
o ND messages are only used by SEND SAVI devices if they are valid. Validating ports if they are valid, otherwise they discard them.
If any of the ND messages used by SEND SAVI is not valid, it is SEND SAVI devices SHOULD assume that such messages received from
discarded. SEND SAVI devices SHOULD assume that such messages Trusted ports have been validated by other SEND SAVI devices, or
received from Trusted ports have been validated by other SEND SAVI come from a trusted device such a router, so they SHOULD NOT
devices, so they SHOULD NOT attempt to validate them in order to attempt to validate them in order to reduce processing load at the
reduce processing load at the SEND SAVI device. SEND SAVI device.
o The only messages the SEND SAVI device is required to generate o The only messages the SEND SAVI device is required to generate
specifically per each source IP address are MLD and NUD_NSOL specifically per each source IP address are MLD and NUD_NSOL
messages. This also keeps the state machine simple. messages. This also keeps the state machine simple.
o Well-behaved nodes are expected to initiate communication by o Well-behaved nodes are expected to initiate communication by
sending secured DAD_NSOL messages. The SEND SAVI state machine is sending secured DAD_NSOL messages. The SEND SAVI state machine is
tailored to efficiently process these events. The reception of tailored to efficiently process these events. The reception of
other packet types without receiving previously validated DAD_NSOL other packet types without receiving previously validated DAD_NSOL
messages is assumed to be consequence of bad-behaving nodes or messages is assumed to be consequence of bad-behaving nodes or
infrequent events (such as packet loss, a change in the topology infrequent events (such as packet loss, a change in the topology
connecting the switches, etc.) While a binding will ultimately be connecting the switches, etc.) While a binding will ultimately be
skipping to change at page 16, line 25 skipping to change at page 17, line 25
BINDING_ANCHOR is set to VP'. BINDING_ANCHOR is set to VP'.
The notation The notation
Timeout, TP_DAD_NSOL/VP_NUD_NSOL Timeout, TP_DAD_NSOL/VP_NUD_NSOL
means that the transition is triggered by either a timeout expiration means that the transition is triggered by either a timeout expiration
or the reception of a DAD_NSOL message from a Trusted Port, and in or the reception of a DAD_NSOL message from a Trusted Port, and in
addition to the transition, a NUD_NSOL message is sent through port addition to the transition, a NUD_NSOL message is sent through port
VP. VP.
For the rest of the description, it is assumed the following: For the rest of the description, we assume the following:
o When a validated message is required (i.e., a 'validated o When a validated message is required (i.e., a 'validated
DAD_NSOL'), messages are check for validity in the considered DAD_NSOL'), messages are check for validity in the considered
switch according to [RFC3971], and messages not fulfilling these switch according to [RFC3971], and messages not fulfilling these
conditions are discarded. conditions are discarded.
o When any SEND message is received from a validated port, the SEND o When any SEND message is received from a validated port, the SEND
SAVI SHOULD assume that the message has been validated by the SEND SAVI SHOULD assume that the message has been validated by the SEND
SAVI device through which the message accessed to the SEND SAVI SAVI device through which the message accessed to the SEND SAVI
protection perimeter (unless the SEND SAVI perimeter has been protection perimeter (unless the SEND SAVI perimeter has been
breached), or the device generating it is trusted. In this case, breached), or the device generating it is trusted. In this case,
the SAVI device does not perform any further validation. the SAVI device does not perform any further validation.
Performing validation for SEND messages received through a Trusted Performing validation for SEND messages received through a Trusted
port may affect performance negatively. port may affect performance negatively.
o When a RADV message is received through a Validating port, and the
SEND SAVI device is in a forwarding state (VALID, TENTATIVE_DAD,
TESTING_VP and TESTING_VP') for the source address of the RADV
message, the message is forwarded to the appropriate Trusted
ports. In addition, either an entry for this IPv6 source address
in the SEND SAVI Router List is created, or the LIFETIME of an
existing entry is updated with the information received in this
message. The SEND SAVI Prefix list MUST also be updated according
to the content of the RADV message. The SEND SAVI device MAY not
process (although it MUST forward them) RADV messages addressed to
destinations other than the all-nodes multicast address or to the
IPv6 address of the SEND SAVI device.
NO_BIND NO_BIND
When the node is in this state, there are no unresolved NUD_NSOL When the node is in this state, there are no unresolved NUD_NSOL
messages generated by SEND SAVI or DAD_NSOL propagated to any messages generated by SEND SAVI or DAD_NSOL propagated to any
Validating port, so the only relevant inputs are DAD_NSOL messages Validating port, so the only relevant inputs are DAD_NSOL messages
coming either from a Validating port (VP) or Trusted port (TP), or coming either from a Validating port (VP) or Trusted port (TP), or
any packet other than DAD_NSOL coming from VP or TP. There are no any packet other than DAD_NSOL coming from VP or TP. There are no
timers configured for this state. timers configured for this state.
Messages received from a validating port Messages received from a Validating port
o If a validated DAD_NSOL message is received from a Validating port o If a validated DAD_NSOL message is received from a Validating port
VP, the SEND SAVI device forwards this message to all appropriate VP, the SEND SAVI device forwards this message to all appropriate
Trusted ports (the subset of Trusted ports which belong to the Trusted ports (the subset of Trusted ports which belong to the
forwarding layer-2 topology, with the restrictions imposed by the forwarding layer-2 topology, with the restrictions imposed by the
MLD snooping mechanism, if applied). DAD_NSOL messages are not MLD snooping mechanism, if applied). DAD_NSOL messages are not
sent through any of the ports configured as Validating Ports. The sent through any of the ports configured as Validating Ports. The
SEND SAVI device sets the LIFETIME to TENT_LT, stores all the SEND SAVI device sets the LIFETIME to TENT_LT, stores all the
information required for future validation of the corresponding information required for future validation of the corresponding
DAD_NADV message (such as the nonce of the message), creates a new DAD_NADV message (such as the nonce of the message), creates a new
entry in the SEND SAVI Data Base for IPaddr, sets BINDING_ANCHOR entry in the SEND SAVI Data Base for IPaddr, sets BINDING_ANCHOR
skipping to change at page 17, line 42 skipping to change at page 18, line 31
Validating port VP, the SEND SAVI device issues a secured NUD_NSOL Validating port VP, the SEND SAVI device issues a secured NUD_NSOL
through port VP. The SEND SAVI device sets the LIFETIME to through port VP. The SEND SAVI device sets the LIFETIME to
TENT_LT. The SEND SAVI device creates a new entry in the SEND TENT_LT. The SEND SAVI device creates a new entry in the SEND
SAVI Data Base for IPaddr, sets BINDING_ANCHOR to VP, and the SAVI Data Base for IPaddr, sets BINDING_ANCHOR to VP, and the
state is changed to TENTATIVE_NUD. Creation time is set to the state is changed to TENTATIVE_NUD. Creation time is set to the
current value of the local clock. The SAVI device MAY discard the current value of the local clock. The SAVI device MAY discard the
packet while the NUD procedure is being executed, or MAY store it packet while the NUD procedure is being executed, or MAY store it
in order to send it if the next transitions are (strictly) in order to send it if the next transitions are (strictly)
TENTATIVE_NUD and then VALID. TENTATIVE_NUD and then VALID.
Messages received from a trusted port Messages received from a Trusted port
o If a DAD_NSOL message containing IPaddr as the target address is o If a DAD_NSOL message containing IPaddr as the target address is
received through a Trusted port, it MUST NOT be forwarded through received through a Trusted port, it MUST NOT be forwarded through
any of the Validating ports but it is sent through the proper any of the Validating ports but it is sent through the proper
Trusted ports. The state is not changed. Trusted ports. The state is not changed.
o Any packet other than a DAD_NSOL received from a Trusted port is o Any packet other than a DAD_NSOL received from a Trusted port is
forwarded to its destination. This packet is assumed to come from forwarded to its destination. This packet is assumed to come from
a SEND SAVI device that has securely validated the binding a SEND SAVI device that has securely validated the binding
according to SEND SAVI rules (unless the SEND SAVI perimeter has according to SEND SAVI rules (unless the SEND SAVI perimeter has
been breached). The state is not changed. been breached). The state is not changed.
skipping to change at page 19, line 23 skipping to change at page 20, line 14
LIFETIME expires LIFETIME expires
o If LIFETIME expires, it is assumed that no other node has o If LIFETIME expires, it is assumed that no other node has
configured this address. Therefore, the Validating port VP configured this address. Therefore, the Validating port VP
(currently stored in the BINDING_ANCHOR) could be bound to this (currently stored in the BINDING_ANCHOR) could be bound to this
IPv6 address. The LIFETIME is set to DEFAULT_LT, and the state is IPv6 address. The LIFETIME is set to DEFAULT_LT, and the state is
changed to VALID. changed to VALID.
VALID VALID
To arrive to this state, successful validation of address ownership To arrive to this state, the SEND SAVI device has successfully
has been completed and a binding for IPaddr has been created. validated address ownership, and has created a binding for IPaddr.
Relevant transitions for this state are triggered by the reception of Relevant transitions for this state are triggered by the reception of
DAD_NSOL from the BINDING_ANCHOR port, other Validating port or a TP, DAD_NSOL from the BINDING_ANCHOR port, other Validating port or a TP,
and any packet other than DAD_NSOL from other validating port than and any packet other than DAD_NSOL from other validating port than
the BINDING_ANCHOR or a TP. The expiration of LIFETIME is also the BINDING_ANCHOR or a TP. The expiration of LIFETIME is also
relevant to trigger a check for address ownership for the node at the relevant to trigger a check for address ownership for the node at the
BINDING_ANCHOR port. BINDING_ANCHOR port.
Messages received from the BINDING_ANCHOR port Messages received from the BINDING_ANCHOR port
o If a validated DAD_NSOL with IPaddr as source address is received o If a validated DAD_NSOL with IPaddr as source address is received
through the BINDING_ANCHOR port, it is forwarded to the through the BINDING_ANCHOR port, it is forwarded to the
skipping to change at page 22, line 4 skipping to change at page 22, line 39
node has moved but have not issued a DAD_NSOL or the DAD_NSOL node has moved but have not issued a DAD_NSOL or the DAD_NSOL
message has been lost. The state will eventually move to NO_BIND, message has been lost. The state will eventually move to NO_BIND,
and then the packets sent from VP' will trigger the creation of and then the packets sent from VP' will trigger the creation of
the binding for VP'. the binding for VP'.
LIFETIME expires LIFETIME expires
o If the LIFETIME expires, the LIFETIME is cleared and the state is o If the LIFETIME expires, the LIFETIME is cleared and the state is
changed to NO_BIND. changed to NO_BIND.
TESTING_VP' TESTING_VP'
To arrive to this state an indication that a node at VP' different
from the BINDING_ANCHOR port wants to send data with IPaddr as source To arrive to this state, the SEND SAVI device has received an
address occurred while a binding existed for VP. The port VP' which indication that a node at VP' different from the BINDING_ANCHOR port
triggered the change of the state to TESTING_VP' was stored at the wants to send data with IPaddr as source address occurred while a
binding existed for VP. The port VP' which triggered the change of
the state to TESTING_VP' was stored at the
ALTERNATIVE_BINDING_ANCHOR, so that it can be retrieved if the node ALTERNATIVE_BINDING_ANCHOR, so that it can be retrieved if the node
at VP' is determined as the legitimate owner of IPaddr. The SEND at VP' is determined as the legitimate owner of IPaddr. The SEND
SAVI device has issued a NUD_NSOL to IPaddr through the SAVI device has issued a NUD_NSOL to IPaddr through the
BINDING_ANCHOR port. The relevant events that may occur in this case BINDING_ANCHOR port. The relevant events that may occur in this case
are the reception of a NUD_NADV from port VP (the BINDING_ANCHOR are the reception of a NUD_NADV from port VP (the BINDING_ANCHOR
port), the reception of DAD_NSOL from VP, VP', TP and VP" (VP" port), the reception of DAD_NSOL from VP, VP', TP and VP" (VP"
different from VP and VP'), the reception of any other packet from different from VP and VP'), the reception of any other packet from
VP, VP', TP or VP", and the expiration of the timer. VP, VP', TP or VP", and the expiration of the timer.
Messages received from the BINDING_ANCHOR port Messages received from the BINDING_ANCHOR port
o A validated NUD_NADV is received from the BINDING_ANCHOR port. o A validated NUD_NADV is received from the BINDING_ANCHOR port.
The reception of a valid NUD_NADV indicates that the node at VP is The reception of a valid NUD_NADV indicates that the node at VP is
defending its address. The BINDING_ANCHOR in use is kept, the defending its address. The BINDING_ANCHOR in use is kept, the
LIFETIME is set to DEFAULT_LT, and the state is changed to VALID. LIFETIME is set to DEFAULT_LT, and the state is changed to VALID.
o If a valid DAD_NSOL is received from the BINDING_ANCHOR port, it o If a valid DAD_NSOL is received from the BINDING_ANCHOR port, it
is forwarded to VP' (the port stored in the is forwarded to VP' (the port stored in the
ALTERNATIVE_BINDING_ANCHOR). The BINDING_ANCHOR in use is kept, ALTERNATIVE_BINDING_ANCHOR). The BINDING_ANCHOR in use is kept,
the LIFETIME is set to TENT_LT and the state is changed to the LIFETIME is set to TENT_LT and the state is changed to
TENTATIVE_DAD. When the DAD_NSOL message is received by the node TENTATIVE_DAD. When the DAD_NSOL message is received by the node
at VP', this node is expected to unconfigure its address. at VP', this node is expected to unconfigure its address.
o If a valid RADV is received from the BINDING_ANCHOR port, the o Any packet other than a validated DAD_NSOL, or a validated
message is forwarded appropriately. Either an entry for this IPv6 NUD_NADV coming from the BINDING_ANCHOR port, is forwarded, and
source address in the SEND SAVI Router List is created, or the the state is not changed.
lifetime of an existing entry is updated with the information
received in this message. The SEND SAVI Prefix list MUST also be
updated according to the content of the RADV message. The SEND
SAVI device MAY ignore and discard RADV messages addressed to
destinations other than the all-nodes multicast address or to the
IPv6 address of the SEND SAVI device. The state remains in
TESTING_VP' and the LIFETIME is left unchanged. Note that if the
timeout expires later, while still in the TESTING_VP' state, the
entry of the SEND SAVI Router List will also be removed.
o Any packet other than a validated DAD_NSOL, a validated NUD_NADV
or a validated RADV coming from the BINDING_ANCHOR port, is
forwarded, and the state is not changed.
Messages received from the ALTERNATIVE_BINDING_ANCHOR validating port Messages received from the ALTERNATIVE_BINDING_ANCHOR validating port
o If a valid DAD_NSOL is received from the port stored in the o If a valid DAD_NSOL is received from the port stored in the
ALTERNATIVE_BINDING_ANCHOR, it is forwarded to the BINDING_ANCHOR ALTERNATIVE_BINDING_ANCHOR, it is forwarded to the BINDING_ANCHOR
port. The BINDING_ANCHOR and the ALTERNATIVE BINDING ANCHOR are port. The BINDING_ANCHOR and the ALTERNATIVE BINDING ANCHOR are
kept, the LIFETIME is set to DEFAULT_LT, and the state is not kept, the LIFETIME is set to DEFAULT_LT, and the state is not
changed. changed.
o Any packet other than a validated DAD_NSOL coming from the o Any packet other than a validated DAD_NSOL coming from the
ALTERNATIVE_BINDING_ANCHOR port is discarded, and the state is not ALTERNATIVE_BINDING_ANCHOR port is discarded, and the state is not
changed. changed.
Messages received from a validating port different from the Messages received from a validating port different from the
BINDING_ANCHOR and the ALTERNATIVE_BINDING_ANCHOR ports BINDING_ANCHOR and the ALTERNATIVE_BINDING_ANCHOR ports
o If a validated DAD_NSOL is received from port VP", different from o If a validated DAD_NSOL is received from port VP", different from
BINDING_ANCHOR and the ALTERNATIVE_BINDING_ANCHOR ports, it is BINDING_ANCHOR and the ALTERNATIVE_BINDING_ANCHOR ports, it is
forwarded to the BINDING_ANCHOR and the ALTERNATIVE_BINDING_ANCHOR forwarded to the BINDING_ANCHOR and the ALTERNATIVE_BINDING_ANCHOR
ports. The node at ALTERNATIVE BINDING ANCHOR port is expected to ports. The node at ALTERNATIVE BINDING ANCHOR port is expected to
skipping to change at page 25, line 4 skipping to change at page 25, line 29
unchanged. unchanged.
LIFETIME expires LIFETIME expires
o If LIFETIME expires, the LIFETIME is cleared and the state is o If LIFETIME expires, the LIFETIME is cleared and the state is
changed to NO_BIND. changed to NO_BIND.
3.4. SEND SAVI Port Configuration Guidelines 3.4. SEND SAVI Port Configuration Guidelines
The detailed guidelines for port configuration in SEND SAVI devices The detailed guidelines for port configuration in SEND SAVI devices
are: are:
o Ports connected to another SEND SAVI devices MUST be configured as
o Ports that are connected to another SEND SAVI devices SHOULD be Trusted ports. Not doing so will prevent off-link traffic from
configured as Trusted ports. Not doing so will increase being forwarded, along with the following effects for on-link
significantly the CPU time, memory consumption and signaling traffic: increase significantly the CPU time, memory consumption
traffic due to SEND SAVI validation, in both the SEND SAVI devices and signaling traffic due to SEND SAVI validation, in both the
and the node whose address is being validated. SEND SAVI devices and the node whose address is being validated.
o Ports connected to hosts SHOULD be configured as Validating ports. o Ports connected to hosts SHOULD be configured as Validating ports.
Not doing so will allow the host connected to that port to send Not doing so will allow the host connected to that port to send
packets with spoofed source address. packets with spoofed source address.
o No more than one host SHOULD be connected to each port. o No more than one host SHOULD be connected to each port.
Connecting more than one host to a port | will allow hosts to Connecting more than one host to a port will allow hosts to
generate packets with the same source address as the other hosts generate packets with the same source address as the other hosts
connected to the same port, and will allow performing replaying connected to the same port, and will allow performing replaying
attacks as described in Section 5.1. attacks as described in Section 5.1.
o Ports connected to routers SHOULD be configured as Validating o Ports connected to routers MUST be configured as Trusted ports.
ports. However, the SEND SAVI specification also allows the Not doing so results in SEND SAVI devices discarding off-link
routers to be connected to Trusted ports, as they are assumed to traffic. Note that this means that, since routers are connected
be part of the trusted infrastructure. When connected through a through Trusted ports, they can generate traffic with any source
Trusted port, a router can generate traffic with any source address, even those belonging to the link.
address, even those belonging to the link, while when connected
through a Validating port it can only send traffic using off-link
source addresses, or its own source addresses. When routers are
connected to Validating ports, authorization for the routing
function is bound to the binding anchor of the router itself,
instead of being bound to a port configured in a switch, so in
this case changing the port through which a router attaches to the
SAVI protection perimeter does not require SEND SAVI-specific
configuration.
o Ports connected to a chain of one or more legacy switches that o Ports connected to a chain of one or more legacy switches that
have other SEND SAVI devices but had no routers or hosts attached have other SEND SAVI devices but had no routers or hosts attached
to them SHOULD be configured as Trusted ports. Not doing so will to them SHOULD be configured as Trusted ports. Not doing so will
significantly increase the memory consumption in the SEND SAVI significantly increase the memory consumption in the SEND SAVI
devices and increase the signaling traffic due to SEND SAVI devices and increase the signaling traffic due to SEND SAVI
validation. validation.
3.5. VLAN Support 3.5. VLAN Support
In the case the SEND SAVI device is a switch that supports customer In the case the SEND SAVI device is a switch that supports customer
VLANs [IEEE.802-1Q.2005], the SEND SAVI implementation MUST behave as VLANs [IEEE.802-1Q.2005], the SEND SAVI specification MUST behave as
if there was one SEND SAVI process per customer VLAN. The SEND SAVI if there was one SEND SAVI process per customer VLAN. The SEND SAVI
process of each customer VLAN will store the binding information process of each customer VLAN will store the binding information
corresponding the nodes attached to that particular customer VLAN. corresponding the nodes attached to that particular customer VLAN.
3.6. Protocol Constants 3.6. Protocol Constants
TENT_LT is 500 milliseconds. TENT_LT is 500 milliseconds.
DEFAULT_LT is 5 minutes. DEFAULT_LT is 5 minutes.
4. Protocol Walkthrough 4. Protocol Walkthrough
In this section we include two cases which illustrate the behavior of In this section we include two cases which illustrate the behavior of
SEND SAVI, the change of the attachment port of a host, and the SEND SAVI, the change of the attachment port of a host, and the
attack of a malicious host. We use the topology depicted in the attack of a malicious host. We use the topology depicted in the
following figure. following figure.
+---+
| H |
+---+
|
|
+-1-----2-+ +-1-----2-+ +-1-----2-+ +-1-----2-+
| | | | | | | |
| SAVI1 | | SAVI2 | | SAVI1 | | SAVI2 |
| | | | | | | |
+-3-----4-+ +-3-----4-+ +-3-----4-+ +-3-----4-+
| | | |
------------------- -------------------
4.1. Change of the attachment point of a host 4.1. Change of the attachment point of a host
There are two cases, depending on if the switch to which H moves is There are two cases, depending on whether the host H moves to a
the same switch or a different one. different port on the same switch, or to a different switch.
4.1.1. Moving to a port of the same switch 4.1.1. Moving to a port of the same switch
Host H is connected to port 1 of SAVI1 and moves to port 2 of the Host H is connected to port 1 of SAVI1 and moves to port 2 of the
same switch. Before moving, the SEND SAVI state associated to IPH, same switch. Before moving, the SEND SAVI state associated to IPH,
the IP address of H is the IP address of H is
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND
In the general case, H issues a DAD_NSOL message for IPH when it is In the general case, H issues a DAD_NSOL message for IPH when it is
skipping to change at page 30, line 7 skipping to change at page 30, line 29
expires, the state is moved back to: expires, the state is moved back to:
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND
To prevent the drain of CPU resources in SAVI2, the processing of To prevent the drain of CPU resources in SAVI2, the processing of
further packets received from port 2 may be rate-limited, as further packets received from port 2 may be rate-limited, as
discussed in Section 5.2. discussed in Section 5.2.
5. Security Considerations 5. Security Considerations
SEND SAVI is defined to operate only with validated SEND messages. SEND SAVI operates only with validated SEND messages to create
The interaction in a mixed scenario comprising SEND and non-SEND bindings. Note that IPv6 packets generated by non-SEND nodes will be
devices should be addressed in other document. However, nodes MUST discarded by the first SEND SAVI device receiving it. Therefore,
NOT assume that all SEND messages received from a SEND SAVI device attackers cannot obtain any benefit by not using SEND. In order to
are validated, since these devices only validate the messages perform address validation in a mixed scenario comprising SEND and
strictly required for SEND SAVI operation. Among the number of non-SEND devices, a different solution is required, which should be
messages which are not validated, we can name NUD_NSOL messages addressed in other document.
generated by other nodes and its corresponding NUD_NADV responses, or
RSOL messages. Nodes MUST NOT assume that all SEND messages received from a SEND
SAVI device are validated, since these devices only validate the
messages strictly required for SEND SAVI operation. Among the number
of messages which are not validated by SEND SAVI, we can name
NUD_NSOL messages generated by other nodes and its corresponding
NUD_NADV responses, or RSOL messages.
SEND SAVI improves protection compared to conventional SAVI, as a SEND SAVI improves protection compared to conventional SAVI, as a
result of the increased ability of SEND nodes to prove address result of the increased ability of SEND nodes to prove address
ownership. ownership.
A critical security consideration regarding to SEND SAVI deals with A critical security consideration regarding to SEND SAVI deals with
the need of proper configuration of the roles of the ports in a SEND the need of proper configuration of the roles of the ports in a SEND
SAVI deployment scenario. Regarding to security, the main SAVI deployment scenario. Regarding to security, the main
requirement is that ports defining the protected perimeter SHOULD be requirement is that ports defining the protected perimeter SHOULD be
configured as Validating ports. Not doing so will allow an attacker configured as Validating ports. Not doing so will allow an attacker
skipping to change at page 30, line 39 skipping to change at page 31, line 18
5.1. Protection Against Replay Attacks 5.1. Protection Against Replay Attacks
One possible concern about SEND SAVI is its behavior when an attacker One possible concern about SEND SAVI is its behavior when an attacker
tries to forge the identity of a legitimate node by replaying SEND tries to forge the identity of a legitimate node by replaying SEND
messages used by the SEND SAVI specification. An attacker could messages used by the SEND SAVI specification. An attacker could
replay any of these messages to interfere with SEND SAVI operation. replay any of these messages to interfere with SEND SAVI operation.
For example, it could replay a DAD_NSOL message to abort the For example, it could replay a DAD_NSOL message to abort the
configuration of an address for a legitimate node and to gain the configuration of an address for a legitimate node and to gain the
right to use the address for DEFAULT_LT seconds. right to use the address for DEFAULT_LT seconds.
There are two different cases to analyse when considering SEND SAVI We can analyse two different cases when considering SEND SAVI replay
reply attacks: attacks:
o When the SEND message replayed is used to create or update binding o When the SEND message replayed is used to create or update binding
information for SEND SAVI, since the port through which this information for SEND SAVI, since the port through which this
message is received is key to SEND SAVI operation. SEND SAVI message is received is key to SEND SAVI operation. SEND SAVI
creates and maintains bindings as a result of the reception of creates and maintains bindings as a result of the reception of
DAD_NSOL messages and of the exchange of NUD_NSOL/NUD_NADV DAD_NSOL messages and of the exchange of NUD_NSOL/NUD_NADV
messages. messages.
o When the SEND message replayed does not result in the update of o When the SEND message replayed does not result in the update of
binding information for SEND SAVI, and thus it is not related to binding information for SEND SAVI, and thus it is not related to
the specific port through which it was received. Such situations the specific port through which it was received. Such situations
are the reception of CPA messages containing certificates, and the are the reception of CPA messages containing certificates, and the
processing of an RADV message coming from a Trusted port, which processing of an RADV message coming from a Trusted port, which
can be used in SEND SAVI to populate the SEND SAVI Prefix list. can be used in SEND SAVI to populate the SEND SAVI Prefix list.
In these two cases, the security risks are equivalent to those of
In this two cases, the security risks are equivalent to those of
SEND operation, i.e., we can consider that the information will SEND operation, i.e., we can consider that the information will
not be changed by its legitimate sender for the time during which not be changed by its legitimate sender for the time during which
the SEND specification allows replaying (which depends on the the SEND specification allows replaying (which depends on the
values of TIMESTAMP_FUZZ and TIMESTAMP_DRIFT, [RFC3971]). values of TIMESTAMP_FUZZ and TIMESTAMP_DRIFT, [RFC3971]).
A special case is the processing of a RADV message coming from a
Validating port. Although part of the information obtained (the
router condition of the node connecting to the port) is
(indirectly) associated to the binding, the replay of this RADV
message does not provide an advantage to an attacker. This is so
because SEND SAVI requires a binding to exist (between the IPv6
address and the port of the SEND SAVI device) prior to consider
the RADV message, so protecting the creation of the binding also
protects the ability of an attacker to become a router.
For replay of messages belonging to the second case, i.e., messages For replay of messages belonging to the second case, i.e., messages
which does not result in changes in the SEND SAVI binding which do not result in changes in the SEND SAVI binding information,
information, the security provided by SEND is sufficient. For the the security provided by SEND is sufficient. For the replay of
replay of messages belonging to the first case, DAD_NSOL and messages belonging to the first case, DAD_NSOL and NUD_NSOL/NUD_NADV
NUD_NSOL/NUD_NADV messages, protection results from the behavior of messages, protection results from the behavior of SEND SAVI,
SEND SAVI, specified in Section 3.3.2, which restricts the ports to specified in Section 3.3.2, which restricts the ports to which the
which the messages involved in SEND SAVI binding updates are messages involved in SEND SAVI binding updates are disseminated.
disseminated. SEND SAVI devices only forward these messages to ports SEND SAVI devices only forward these messages to ports for which a
for which a binding to the address being tested by the DAD_NSOL binding to the address being tested by the DAD_NSOL message existed.
message existed. Therefore, it is not enough for an attacker to Therefore, it is not enough for an attacker to subscribe to a
subscribe to a Solicited Node address to receive DAD_NSOL messages Solicited Node address to receive DAD_NSOL messages sent to that
sent to that address, but the attacker needs to generate a valid address, but the attacker needs to generate a valid DAD_NSOL message
DAD_NSOL message associated to the address for which the binding is associated to the address for which the binding is being tested,
being tested, which is deemed unfeasible [RFC3971]. which is deemed unfeasible [RFC3971].
5.2. Protection Against Denial of Service Attacks 5.2. Protection Against Denial of Service Attacks
The attacks against the SEND SAVI device basically consist of making The attacks against the SEND SAVI device basically consist of making
the SEND SAVI device consume its resources until it runs out of them. the SEND SAVI device consume its resources until it runs out of them.
For instance, a possible attack would be to send packets with For instance, a possible attack would be to send packets with
different source addresses, making the SEND SAVI device create state different source addresses, making the SEND SAVI device create state
for each of the addresses and waste memory. At some point, the SEND for each of the addresses and waste memory. At some point, the SEND
SAVI device runs out of memory and needs to decide how to react. The SAVI device runs out of memory and needs to decide how to react. The
result is that some form of garbage collection is needed to prune the result is that some form of garbage collection is needed to prune the
entries. When the SEND SAVI device runs out of the memory allocated entries. When the SEND SAVI device runs out of the memory allocated
for the SEND SAVI Data Base, it is RECOMMENDED that it create new for the SEND SAVI Data Base, it is RECOMMENDED that it create new
entries by deleting the entries with a higher Creation time. This entries by deleting the entries with a higher Creation time. This
implies that older entries are preserved and newer entries overwrite implies that older entries are preserved and newer entries overwrite
each other. In an attack scenario where the attacker sends a batch each other. In an attack scenario where the attacker sends a batch
of data packets with different source addresses, each new source of data packets with different source addresses, each new source
address is likely to rewrite another source address created by the address is likely to rewrite another source address created by the
attack itself. It should be noted that entries are also garbage attack itself. It should be noted that entries are also garbage
collected using the DEFAULT_LT, which is updated by NUD_NSOL/NUD_NADV collected using the DEFAULT_LT, which is updated by NUD_NSOL/NUD_NADV
exchange. The result is that in order for an attacker to actually exchange. The result is that in order for an attacker to actually
fill the FCFS SAVI Data Base with false source addresses, it needs to fill the SEND SAVI Data Base with false source addresses, it needs to
continuously answer to NUD_NSOL for all the different source continuously answer to NUD_NSOL for all the different source
addresses so that the entries grow old and compete with the addresses so that the entries grow old and compete with the
legitimate entries. The result is that the cost of the attack is legitimate entries. The result is that the cost of the attack is
highly increased for the attacker. highly increased for the attacker.
In addition, it is also RECOMMENDED that a SEND SAVI device reserves In addition, it is also RECOMMENDED that a SEND SAVI device reserves
a minimum amount of memory for each available port (in the case where a minimum amount of memory for each available port (in the case where
the port is used as part of the L2 anchor). The recommended minimum the port is used as part of the L2 anchor). The REQUIRED minimum is
is the memory needed to store 4 bindings associated to the port. The the memory needed to store four bindings associated to the port,
motivation for this recommendation is as follows. An attacker although it SHOULD be raised if the ratio between the maximum number
attached to a given port of a SEND SAVI device may attempt to launch of bindings allowed in the device and the number of ports is high.
a DoS attack towards the SEND SAVI device by creating many bindings The motivation for setting a minimum number of bindings per port is
for different addresses. It can do so, by sending DAD_NSOL for as follows. An attacker attached to a given port of a SEND SAVI
different addresses. The result is that the attack will consume all device may attempt to launch a DoS attack towards the SEND SAVI
the memory available in the SEND SAVI device. The above device by creating many bindings for different addresses. It can do
recommendation aims to reserve a minimum amount of memory per port, so, by sending DAD_NSOL for different addresses. The result is that
so that nodes located in different ports can make use of the reserved the attack will consume all the memory available in the SEND SAVI
memory for their port even if a DoS attack is occurring in a device. The above recommendation aims to reserve a minimum amount of
different port. memory per port, so that nodes located in different ports can make
use of the reserved memory for their port even if a DoS attack is
occurring in a different port.
As the SEND SAVI device may store data packets while the address is The SEND SAVI device may store data packets while the address is
being verified, the memory for data packet storage may also be a being verified, for example, when a DAD_NSOL was lost before arriving
target of DoS attacks. The effects of such attacks may be limited to to the SEND SAVI device to which the host attaches, and the host
the lack of capacity to store new data packets. The effect of such sends data packets, these data packets may be stored until the SEND
attack will be then that data packets will be dropped during the SAVI device verifies the binding by means of a NUD packet exchange.
verification period. A SEND SAVI device MUST limit the amount of In this case, the memory for data packet storage may also be a target
memory used to store data packets, allowing the other functions to of DoS attacks. A SEND SAVI device MUST limit the amount of memory
have available memory even in the case of an attacks such those used to store data packets, allowing the other functions (such as
described above. being able to store new bindings) to have available memory even in
the case of an attack such those described above.
It is worth to note that the potential of Denial of Service attacks It is worth to note that the potential of Denial of Service attacks
against the SEND SAVI network is increased due to the use of costly against the SEND SAVI network is increased due to the use of costly
cryptographic operations in order to validate the address of the cryptographic operations in order to validate the address of the
nodes. An attacker could generate packets using new source addresses nodes. An attacker could generate packets using new source addresses
in order to make the closest SEND SAVI device spend CPU time to in order to make the closest SEND SAVI device spend CPU time to
validate DAD_NSOL messages or to generate a secure NUD_NSOL. This validate DAD_NSOL messages or to generate a secure NUD_NSOL. This
attack can be used to drain CPU resources of SEND SAVI devices with a 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, very low cost for the attacker. In order to solve this problem,
rate-limiting the processing of packets which may trigger SEND SAVI rate-limiting the processing of packets which trigger SEND SAVI
events SHOULD be enforced in a per-port basis. events SHOULD be enforced in a per-port basis.
5.3. Residual threats 5.3. Considerations on the deployment model for trust anchors
The SEND specification [RFC3971] proposes two deployment models for
trust anchors, either a centralized model relaying on a globally
rooted public key infrastructure, or a more local, decentralized
deployment model, in which end hosts are configured with a collection
of public keys which are trusted only on a domain.
The appeal of a centralized model is the possibility for hosts to use
SEND to validate routers as they move through links belonging to
different organizations without additional configuration. However,
without any further protection, it also enables routers authorized
with a certificate path rooted on a global trust anchor to appear as
legitimate routers in a link in which they were not intended to act
as such. This threat already existed for SEND deployments, for which
links configured to accept centralized trust anchors may send
outgoing traffic and use prefix information from alien routers. In a
SEND SAVI deployment, such routers may be able to deliver off-link
traffic to any node of the link.
In order to cope with this threat, SEND SAVI specifies that nodes are
only allowed to behave as routers if they connect through Trusted
ports. In particular, RADV messages and traffic with off-link source
addresses are discarded when received through Validating ports, which
are the ports intended for non-trusted infrastructure, as moving
nodes. The protection provided by filtering RADV messages prevents
SEND nodes from identifying alien routers as legitimate routers, even
though the trust anchor of these routers is valid.
Besides, it is worth to say that SEND SAVI supports a decentralized
deployment model.
5.4. Residual threats
SEND SAVI assumes that a host will be able to defend its address when SEND SAVI assumes that a host will be able to defend its address when
the DAD procedure is executed for its addresses, and that it will the DAD procedure is executed for its addresses, and that it will
answer to a NUD_NSOL with a NUD_NADV when required. This is needed, answer to a NUD_NSOL with a NUD_NADV when required. This is needed,
among other things, to support mobility within a link (i.e., to allow among other things, to support mobility within a link (i.e., to allow
a host to detach and reconnect to a different Layer_2 anchor of the a host to detach and reconnect to a different Layer_2 anchor of the
same IP subnetwork, without changing its IP address). If the SEND same IP subnetwork, without changing its IP address). If the SEND
SAVI device does not see the DAD_NADV or the NUD_NADV, it may grant SAVI device does not see the DAD_NADV or the NUD_NADV, it may grant
the binding to a different binding anchor. This means that if an the binding to a different binding anchor. This means that if an
attacker manages to prevent a host from defending its source address, attacker manages to prevent a host from defending its source address,
it will be able to destroy the existing binding and create a new one, it will be able to destroy the existing binding and create a new one,
with a different binding anchor. An attacker may do so for example with a different binding anchor. An attacker may do so for example
by launching a DoS attack to the host that will prevent it to issue by launching a DoS attack to the host that will prevent it to issue
proper replies. proper replies.
5.4. Privacy considerations 5.5. Privacy considerations
A SEND SAVI MUST NOT log binding anchor information except where A SEND SAVI device MUST delete binding anchor information as soon as
there is an identified reason why that information is likely to be
involved in detection, prevention or tracing of actual source address
spoofing. Information that is not logged MUST be deleted as soon as
possible (i.e., as soon as the state for a given address is back to possible (i.e., as soon as the state for a given address is back to
NO_BIND). Information about the majority of hosts that never spoof NO_BIND), except where there is an identified reason why that
SHOULD NOT be logged. information is likely to be involved in detection, prevention or
tracing of actual source address spoofing. Information about the
majority of hosts that never spoof SHOULD NOT be logged.
6. IANA Considerations 6. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
7. Acknowledgments 7. Acknowledgments
Thanks to Jean-Michel Combes and Ana Kukec for their review and Thanks to Jean-Michel Combes, Ana Kukec, Ted Lemon, Adrian Farrel,
comments on this document. The text has also benefited from feedback Barry Leiba, Brian Haberman, Vicent Roca and Benoit Claise for their
provided by Tony Cheneau and Greg Daley. review and comments on this document. The text has also benefited
from feedback provided by Tony Cheneau and Greg Daley.
Marcelo Bagnulo is partly funded by Trilogy, a research project Marcelo Bagnulo is partly funded by Trilogy, a research project
supported by the European Commission under its Seventh Framework supported by the European Commission under its Seventh Framework
Program. Program.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
skipping to change at page 34, line 21 skipping to change at page 35, line 28
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
8.2. Informative References 8.2. Informative References
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[I-D.ietf-savi-framework]
Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt,
"Source Address Validation Improvement Framework",
draft-ietf-savi-framework-06 (work in progress),
January 2012.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
Requirements", RFC 6434, December 2011. Requirements", RFC 6434, December 2011.
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
SAVI: First-Come, First-Served Source Address Validation
Improvement for Locally Assigned IPv6 Addresses",
RFC 6620, May 2012.
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt,
"Source Address Validation Improvement (SAVI) Framework",
RFC 7039, October 2013.
[IEEE.802-1Q.2005] [IEEE.802-1Q.2005]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standard for Local and metropolitan area networks / Standard for Local and metropolitan area networks /
Virtual Bridged Local Area Networks", IEEE Standard Virtual Bridged Local Area Networks", IEEE Standard
802.1Q, May 2005. 802.1Q, May 2005.
Authors' Addresses Authors' Addresses
Marcelo Bagnulo Marcelo Bagnulo
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
 End of changes. 78 change blocks. 
373 lines changed or deleted 391 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/