draft-ietf-savi-mix-08.txt   draft-ietf-savi-mix-09.txt 
SAVI J. Bi SAVI J. Bi
Internet-Draft G. Yao Internet-Draft Tsinghua Univ.
Intended status: Standards Track Tsinghua Univ. Intended status: Standards Track G. Yao
Expires: November 14, 2015 J. Halpern Expires: January 20, 2016 Baidu
J. Halpern
Newbridge Newbridge
E. Levy-Abegnoli, Ed. E. Levy-Abegnoli, Ed.
Cisco Cisco
May 13, 2015 July 19, 2015
SAVI for Mixed Address Assignment Methods Scenario SAVI for Mixed Address Assignment Methods Scenario
draft-ietf-savi-mix-08 draft-ietf-savi-mix-09
Abstract Abstract
In case that multiple IP address assignment methods are allowed in a In case that multiple IP address assignment methods are allowed in a
network, the corresponding SAVI methods should be enabled to prevent network, the corresponding SAVI methods should be enabled to prevent
spoofing in the network. This document reviews how multiple SAVI spoofing in the network. This document reviews how multiple SAVI
methods can coexist in a single SAVI device and collisions are methods can coexist in a single SAVI device and collisions are
resolved when the same binding entry is discovered by two or more resolved when the same binding entry is discovered by two or more
methods. methods.
skipping to change at page 1, line 38 skipping to change at page 1, line 40
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 November 14, 2015. This Internet-Draft will expire on January 20, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 28 skipping to change at page 2, line 29
6.1. Same Address on Different Binding Anchors . . . . . . . . 5 6.1. Same Address on Different Binding Anchors . . . . . . . . 5
6.1.1. Basic preference . . . . . . . . . . . . . . . . . . 6 6.1.1. Basic preference . . . . . . . . . . . . . . . . . . 6
6.1.2. Overwritten preference . . . . . . . . . . . . . . . 6 6.1.2. Overwritten preference . . . . . . . . . . . . . . . 6
6.1.3. Multiple SAVI Device Scenario . . . . . . . . . . . . 7 6.1.3. Multiple SAVI Device Scenario . . . . . . . . . . . . 7
6.2. Same Address on the Same Binding Anchor . . . . . . . . . 7 6.2. Same Address on the Same Binding Anchor . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
There are currently several SAVI documents ([RFC6620], [savi-dhcp] There are currently several SAVI documents ([RFC6620], [RFC7513] and
and [RFC7219]) that describe the different methods by which a switch [RFC7219]) that describe the different methods by which a switch can
can discover and record bindings between a node's IP address and a discover and record bindings between a node's IP address and a
binding anchor and use that binding to perform source address binding anchor and use that binding to perform source address
validation. Each of these documents specifies how to learn on-link validation. Each of these documents specifies how to learn on-link
addresses, based on the method used for their assignment, addresses, based on the method used for their assignment,
respectively: StateLess Autoconfiguration (SLAAC), Dynamic Host respectively: StateLess Autoconfiguration (SLAAC), Dynamic Host
Control Protocol (DHCP) and Secure Neighbor Discovery (SeND). Each Control Protocol (DHCP) and Secure Neighbor Discovery (SeND). Each
of these documents describes separately how one particular method of these documents describes separately how one particular method
deals with address collisions (same address, different binding deals with address collisions (same address, different binding
anchor). anchor).
While multiple IP assignment methods can be used in the same layer-2 While multiple IP assignment methods can be used in the same layer-2
skipping to change at page 3, line 13 skipping to change at page 3, line 13
methods come up with competing bindings. methods come up with competing bindings.
2. Requirements Language 2. Requirements Language
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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Problem Scope 3. Problem Scope
There are three IP address assignment methods identified and reviewed Three different IP address assignment methods have been analyzed for
in one of the SAVI document: SAVI:
1. StateLess Address AutoConfiguration (SLAAC) - reviewed in SAVI- 1. StateLess Address AutoConfiguration (SLAAC) - analyzed in SAVI-
FCFS[RFC6620] FCFS[RFC6620]
2. Dynamic Host Control Protocol address assignment (DHCP) - 2. Dynamic Host Control Protocol address assignment (DHCP) -
reviewed in SAVI-DHCP[savi-dhcp] analyzed in SAVI-DHCP[RFC7513]
3. Secure Neighbor Discovery (SeND) address assignment, reviewed in 3. Secure Neighbor Discovery (SeND) address assignment, analyzed in
SAVI-SEND[RFC7219] SAVI-SEND[RFC7219]
In addition, there is a fourth method for installing a bindings on In addition, there is a fourth method for managing (i.e., creation,
the switch, referred to as "manual". It is based on manual (address management, deletion) a binding on the switch, referred to as
or prefix) binding configuration and is reviewed in [RFC6620] and "manual". It is based on manual binding configuration and is
[RFC7039]. analyzed in [RFC6620] and [RFC7039].
All combinations of address assignment methods can coexist within a All combinations of address assignment methods can coexist within a
layer-2 domain. A SAVI device will have to implement the layer-2 domain. A SAVI device MUST implement the corresponding
corresponding binding setup methods (referred to as a "SAVI method") binding setup methods (referred to as a "SAVI method") to enable
to enable Source Address Validation. If more than one SAVI method is Source Address Validation. If more than one SAVI method is enabled
enabled on a SAVI device, the method is referred to as "mix address on a SAVI device, the method is referred to as "mix address
assignment method" in this document. assignment method" in this document.
SAVI methods are independent from each other, each one handling its SAVI methods are independent from each other, each one handling its
own entries. In the absence of reconciliation, each method will own entries. In the absence of reconciliation, each method will
reject packets sourced with an address it did not discovered. To reject packets sourced with an address it did not discovered. To
prevent addresses discovered by one method to be filtered out by prevent addresses discovered by one method to be filtered out by
another, the binding table should be shared by all the solutions. another, the binding table should be shared by all the solutions.
However this could create some conflict when the same entry is However this could create some conflict when the same entry is
discovered by two different methods: the purpose of this document is discovered by two different methods. The purpose of this document is
of two folds: provide recommendations and method to avoid conflicts, of two folds: provide recommendations and methods to avoid conflicts,
and resolve conflicts if and when they happen. Collisions happening and resolve conflicts if and when they happen. Collisions happening
within a given method are outside the scope of this document. within a given method are outside the scope of this document.
4. Architecture 4. Architecture
A SAVI device may enable multiple SAVI methods. This mechanism, A SAVI device may enable multiple SAVI methods. This mechanism,
called SAVI-MIX, is proposed as a arbiter of the binding generation called SAVI-MIX, is proposed as a arbiter of the binding generation
algorithms, generating the final working binding entries Figure 1. algorithms, generating the final binding entries as illustrated in
Figure 1. Once a SAVI method generates a candidate binding, it will
Once a SAVI method generates a candidate binding, it will request request SAVI-MIX to set up a corresponding entry in the binding
SAVI-MIX to set up a corresponding entry in the binding table. Then table. Then SAVI-MIX will check if there is any conflict in the
SAVI-MIX will check if there is any conflict in the binding table. A binding table. A new binding will be generated if there is no
new binding will be generated if there is no conflict. If there is a conflict. If there is a conflict, SAVI-MIX will determine whether to
conflict, SAVI-MIX will determine whether to replace the existing replace the existing binding or reject the candidate binding based on
binding or reject the candidate binding based on the policies the policies specified in Section 6.
specified in Section 6.
The packet filtering will not be performed by each SAVI method The packet filtering will not be performed by each SAVI method
separately. Instead, SAVI-MIX will perform filtering based on the separately. Instead, SAVI-MIX will perform filtering based on the
entries in the binding table. entries in the binding table.
+--------------------------------------------------------+ +--------------------------------------------------------+
| | | |
| SAVI Device | | SAVI Device |
| | | |
| | | |
skipping to change at page 5, line 28 skipping to change at page 5, line 28
1. DHCP/SLAAC: use non-overlapping prefix for DHCP and SLAAC. Set 1. DHCP/SLAAC: use non-overlapping prefix for DHCP and SLAAC. Set
the A bit in Prefix information option of Router Advertisement the A bit in Prefix information option of Router Advertisement
for SLAAC prefix, and set the M bit in Router Advertisement for for SLAAC prefix, and set the M bit in Router Advertisement for
DHCP prefix. For detail explanations on these bits, refer to DHCP prefix. For detail explanations on these bits, refer to
[RFC4861][RFC4862]. [RFC4861][RFC4862].
2. SeND/non-SeND: avoid mixed environment (where SeND and non-SeND 2. SeND/non-SeND: avoid mixed environment (where SeND and non-SeND
nodes are deployed) or separate the prefixes announced to SeND nodes are deployed) or separate the prefixes announced to SeND
and non-SenD nodes. One way to separate the prefixes is to have and non-SenD nodes. One way to separate the prefixes is to have
the router(s) announcing different (non-overlapping) prefixes to the router(s) announcing different (non-overlapping) prefixes to
SeND and to non-SeND nodes, using unicast Router Advertisements, SeND and to non-SeND nodes, using unicast Router
in response to SeND/non-SeND Router Solicit. Advertisements[RFC6085], in response to SeND/non-SeND Router
Solicit.
6. Resolving binding collisions 6. Resolving binding collisions
In situations where collisions could not be avoided, two cases should In situations where collisions could not be avoided, two cases should
be considered: be considered:
1. The same address is bound on two different binding anchors by 1. The same address is bound on two different binding anchors by
different SAVI methods. different SAVI methods.
2. The same address is bound on the same binding anchor by different 2. The same address is bound on the same binding anchor by different
skipping to change at page 6, line 10 skipping to change at page 6, line 10
node X, installed in the binding table using SAVI-FCFS, anchored to node X, installed in the binding table using SAVI-FCFS, anchored to
"anchor-X". Later, the same address is assigned by DHCP to node Y, "anchor-X". Later, the same address is assigned by DHCP to node Y,
and SAVI-DHCP will generate a candidate binding entry, anchored to and SAVI-DHCP will generate a candidate binding entry, anchored to
"anchor-Y". "anchor-Y".
6.1.1. Basic preference 6.1.1. Basic preference
The SAVI device must decide whom the address should be bound with The SAVI device must decide whom the address should be bound with
(anchor-X or anchor-Y in this example). Current standard documents (anchor-X or anchor-Y in this example). Current standard documents
of address assignment methods have implied the prioritization of address assignment methods have implied the prioritization
relationship (first-come). In the absence of any configuration or relationship, i.e., first-come.
protocol hint (see Section 6.1.2) the SAVI device should choose the
first-come binding anchor, whether it was learnt from SLACC, SeND or 1. SLAAC: s5.4.5 of [RFC4862]
DHCP.
2. DHCPv4: s3.1-p5 of [RFC2131]
3. DHCPv6: s18.1.8 of [RFC3315]
4. SeND: s8 of [RFC3971]
In the absence of any configuration or protocol hint (see
Section 6.1.2) the SAVI device should choose the first-come binding
anchor, whether it was learnt from SLAAC, SeND or DHCP.
6.1.2. Overwritten preference 6.1.2. Overwritten preference
There are two identified exceptions to the general prioritization There are two identified exceptions to the general prioritization
model, one of them being CGA addresses, another one controlled by the model, one of them being CGA addresses, another one controlled by the
configuration of the switch. configuration of the switch.
6.1.2.1. CGA preference 6.1.2.1. CGA preference
When CGA addresses are used, and a collision is detected, preference When CGA addresses are used, and a collision is detected, preference
should be given to the anchor that carries the CGA credentials once should be given to the anchor that carries the CGA credentials once
they are verified, in particular the CGA parameters and the RSA they are verified, in particular the CGA parameters and the RSA
options. Note that if an attacker was trying to replay CGA options. Note that if an attacker was trying to replay CGA
credentials, he would then compete on the base of fcfs (first-come, credentials, he would then compete on the base of "First-Come, First-
first-serve). Served" (FCFS) principle.
6.1.2.2. configuration preference 6.1.2.2. configuration preference
For configuration driven exceptions, the SAVI device may allow the For configuration driven exceptions, the SAVI device may allow the
configuration of a triplet ("prefix", "anchor", "method") or configuration of a triplet ("prefix", "anchor", "method") or
("address", "anchor", "method"), where at least one of ("anchor", ("address", "anchor", "method"), where at least one of ("anchor",
"method") should be specified. Later, if a DAD message is received "method") should be specified. Later, if a DAD message is received
with the following conditions verified: with the following conditions verified:
1. The target in the DAD message does not exist in the binding table 1. The target in the DAD message does not exist in the binding table
2. The target is within configured "prefix" (or equal to "address") 2. The target is within configured "prefix" (or equal to "address")
3. The anchor bound to target is different from the configured 3. The anchor bound to target is different from the configured
anchor, when specified anchor, when specified
4. The configured method, if any, is different from SAVI-FCFS 4. The configured method, if any, is different from SAVI-FCFS
the switch should defend the address by responding to the DAD the switch should defend the address by responding to the DAD
message. It should not at this point install the entry into the message, with a NA message or an ARP response, on behalf of the
binding table. It will simply prevent the node to assign the target node. Plain NA will be replied to SeND DAD. SeND accepts
address, and will de-facto prioritize the configured anchor. This is plain NA for the first time (see s8 of [RFC3971]). The probability
especially useful to protect well known bindings such as a static for a SeND node to generate a colliding address more than one time is
address of a server over anybody, even when the server is down. It trivial in practice, thus the response can effectively protect an
is also a way to give priority to a binding learnt from SAVI-DHCP existing binding.
over a binding for the same address, learnt from SAVI-FCFS.
It should not at this point install the entry into the binding table.
It will simply prevent the node to assign the address, and will de-
facto prioritize the configured anchor. This is especially useful to
protect well known bindings such as a static address of a server over
anybody, even when the server is down. It is also a way to give
priority to a binding learnt from SAVI-DHCP over a binding for the
same address, learnt from SAVI-FCFS.
6.1.3. Multiple SAVI Device Scenario 6.1.3. Multiple SAVI Device Scenario
A single SAVI device doesn't have the information of all bound A single SAVI device doesn't have the information of all bound
addresses on the perimeter. Therefore it is not enough to lookup addresses on the perimeter. Therefore it is not enough to lookup
local bindings to identify a collision. However, assuming DAD is local bindings to identify a collision. However, assuming DAD is
performed throughout the security perimeter for all addresses performed throughout the security perimeter for all addresses
regardless of the assignment method, then DAD response will inform regardless of the assignment method, then DAD response will inform
all SAVI devices about any collision. In that case, FCFS will apply all SAVI devices about any collision. In that case, FCFS will apply
the same way as in a single switch scenario. If the admin configured the same way as in a single switch scenario. If the admin configured
skipping to change at page 8, line 21 skipping to change at page 8, line 32
Thanks to Christian Vogt, Eric Nordmark, Marcelo Bagnulo Braun and Thanks to Christian Vogt, Eric Nordmark, Marcelo Bagnulo Braun and
Jari Arkko for their valuable contributions. Jari Arkko for their valuable contributions.
10. References 10. References
10.1. Normative References 10.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.
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
"Source Address Validation Improvement (SAVI) Framework", RFC 2131, DOI 10.17487/RFC2131, March 1997,
RFC 7039, October 2013. <http://www.rfc-editor.org/info/rfc2131>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005,
<http://www.rfc-editor.org/info/rfc3971>.
[RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec,
"Address Mapping of IPv6 Multicast Packets on Ethernet",
RFC 6085, DOI 10.17487/RFC6085, January 2011,
<http://www.rfc-editor.org/info/rfc6085>.
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
SAVI: First-Come, First-Served Source Address Validation SAVI: First-Come, First-Served Source Address Validation
Improvement for Locally Assigned IPv6 Addresses", RFC Improvement for Locally Assigned IPv6 Addresses",
6620, May 2012. RFC 6620, DOI 10.17487/RFC6620, May 2012,
<http://www.rfc-editor.org/info/rfc6620>.
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed.,
"Source Address Validation Improvement (SAVI) Framework",
RFC 7039, DOI 10.17487/RFC7039, October 2013,
<http://www.rfc-editor.org/info/rfc7039>.
[RFC7219] Bagnulo, M. and A. Garcia-Martinez, "SEcure Neighbor [RFC7219] Bagnulo, M. and A. Garcia-Martinez, "SEcure Neighbor
Discovery (SEND) Source Address Validation Improvement Discovery (SEND) Source Address Validation Improvement
(SAVI)", RFC 7219, May 2014. (SAVI)", RFC 7219, DOI 10.17487/RFC7219, May 2014,
<http://www.rfc-editor.org/info/rfc7219>.
[savi-dhcp] [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address
Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for Validation Improvement (SAVI) Solution for DHCP",
DHCP", draft-ietf-savi-dhcp-34 (work in progress), Feb RFC 7513, DOI 10.17487/RFC7513, May 2015,
2015. <http://www.rfc-editor.org/info/rfc7513>.
10.2. Informative References 10.2. Informative References
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>.
[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,
DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>.
Authors' Addresses Authors' Addresses
Jun Bi Jun Bi
Tsinghua University Tsinghua University
Network Research Center, Tsinghua University Network Research Center, Tsinghua University
Beijing 100084 Beijing 100084
China China
EMail: junbi@tsinghua.edu.cn EMail: junbi@tsinghua.edu.cn
Guang Yao Guang Yao
Tsinghua University Baidu
Network Research Center, Tsinghua University Baidu Science and Technology Park, Building 1
Beijing 100084 Beijing 100193
China China
EMail: yaoguang.china@gmail.com EMail: yaoguang.china@gmail.com
Joel M. Halpern Joel M. Halpern
Newbridge Networks Inc Newbridge Networks Inc
EMail: jmh@joelhalpern.com EMail: jmh@joelhalpern.com
Eric Levy-Abegnoli (editor) Eric Levy-Abegnoli (editor)
 End of changes. 28 change blocks. 
66 lines changed or deleted 109 lines changed or added

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