draft-ietf-savi-mix-12.txt   draft-ietf-savi-mix-13.txt 
SAVI J. Bi SAVI J. Bi
Internet-Draft THU Internet-Draft THU
Intended status: Standards Track G. Yao Intended status: Standards Track G. Yao
Expires: April 21, 2017 Baidu/THU Expires: June 1, 2017 Baidu/THU
J. Halpern J. Halpern
Newbridge Newbridge
E. Levy-Abegnoli, Ed. E. Levy-Abegnoli, Ed.
Cisco Cisco
October 18, 2016 November 28, 2016
SAVI for Mixed Address Assignment Methods Scenario SAVI for Mixed Address Assignment Methods Scenario
draft-ietf-savi-mix-12 draft-ietf-savi-mix-13
Abstract Abstract
In networks that use multiple techniques for address assignment, the In networks that use multiple techniques for address assignment, the
appropriate Source Address Validation Improvement (SAVI) methods must appropriate Source Address Validation Improvement (SAVI) methods must
be used to prevent spoofing of addresses assigned by each such be used to prevent spoofing of addresses assigned by each such
technique. This document reviews how multiple SAVI methods can technique. This document reviews how multiple SAVI methods can
coexist in a single SAVI device and collisions are resolved when the coexist in a single SAVI device and collisions are resolved when the
same binding entry is discovered by two or more methods. same binding entry is discovered by two or more methods.
skipping to change at page 1, line 40 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 April 21, 2017. This Internet-Draft will expire on June 1, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 8, line 30 skipping to change at page 8, line 30
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
on one the switches a prefix (or a single static binding) to defend, on one the switches a prefix (or a single static binding) to defend,
the DAD response generated by this switch will also prevent the the DAD response generated by this switch will also prevent the
binding to be installed on other switches of the perimeter. binding to be installed on other switches of the perimeter. The SAVI
MIX preferences of all the SAVI devices in the same layer-2 domain
should be consistent. Inconsistent configurations may cause network
breaks.
6.2. Same Address on the Same Binding Anchor 6.2. Same Address on the Same Binding Anchor
A binding may be set up on the same binding anchor by multiple A binding may be set up on the same binding anchor by multiple
methods, typically SAVI-FCFS and SAVI-DHCP. If the binding lifetimes methods, typically SAVI-FCFS and SAVI-DHCP. If the binding lifetimes
obtained from the two methods are different, priority should be given obtained from the two methods are different, priority should be given
to 1) Manual configuration 2) SAVI-DHCP 3) SAVI-FCFS as the least to 1) Manual configuration 2) SAVI-DHCP 3) SAVI-FCFS as the least
authoritative. The binding will be removed when the prioritized authoritative. The binding will be removed when the prioritized
lifetime expires, even if a less authoritative method had a longer lifetime expires, even if a less authoritative method had a longer
lifetime. lifetime.
7. Security Considerations 7. Security Considerations
SAVI MIX does not eliminate the security problems of each SAVI Combining SAVI methods (as in SAVI MIX) does not improve on or
method. Thus, the potential attacks, e.g., the DoS attack against eliminate the security considerations associated with each individual
the SAVI device resource, can still happen. In deployment, the SAVI method. Therefore, security considerations for each enabled
security threats from each enabled SAVI methods should be prevented SAVI method should be addressed as described in that method's
by the corresponding proposed solutions in each document. associated RFC. Moreover, combining methods (as in SAVI MIX) has two
additional implications for security. First, it may increase
SAVI MIX is only a binding setup/removal arbitration mechanism. It susceptibility to DoS attacks, because the SAVI binding setup rate
does not introduce additional security threats if the arbitration is will be the sum of the rates of all enabled SAVI methods.
reasonable. However, there is a slight problem. SAVI MIX is more Implementers must take these added resource requirements into
tolerant about binding establishment than each SAVI method alone. As account. Second, because SAVI MIX supports multiple binding
long as one of the enabled SAVI methods generates a binding, the mechanisms, it potentially reduces the security level to that of the
binding will be applied. As a result, the allowed number of SAVI weakest supported method, unless additional steps (e.g. requiring
bindings or allowed SAVI binding setup rate will be the sum of that non-overlapping address spaces for different methods) are taken.
of all the enabled SAVI methods. In deployment, whether a SAVI
device is capable of supporting the resulting resource requirements
should be evaluated.
The SAVI MIX preferences of all the SAVI devices in the same layer-2
domain should be consistent. Inconsistent configurations may cause
network breaks.
8. Privacy Considerations 8. Privacy Considerations
When implementing multiple SAVI methods, privacy considerations of When implementing multiple SAVI methods, privacy considerations of
all methods apply cumulatively. In addition, there is a minor all methods apply cumulatively. In addition, there is a minor
additional loss of privacy in that the SAVI device can correlate additional loss of privacy in that the SAVI device can correlate
information from different SAVI methods. information from different SAVI methods.
9. IANA Considerations 9. IANA Considerations
This memo asks the IANA for no new parameters. This memo asks the IANA for no new parameters.
10. Acknowledgment 10. Acknowledgment
Thanks to Christian Vogt, Eric Nordmark, Marcelo Bagnulo Braun, David Thanks to Christian Vogt, Eric Nordmark, Marcelo Bagnulo Braun, David
Lamparter and Jari Arkko for their valuable contributions. Lamparter, Scott G. Kelly and Jari Arkko for their valuable
contributions.
11. References 11. References
11.1. Normative References 11.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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
 End of changes. 7 change blocks. 
26 lines changed or deleted 23 lines changed or added

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