draft-ietf-savi-mix-07.txt   draft-ietf-savi-mix-08.txt 
SAVI J. Bi SAVI J. Bi
Internet-Draft G. Yao Internet-Draft G. Yao
Intended status: Standards Track Tsinghua Univ. Intended status: Standards Track Tsinghua Univ.
Expires: September 9, 2015 J. Halpern Expires: November 14, 2015 J. Halpern
Newbridge Newbridge
E. Levy-Abegnoli, Ed. E. Levy-Abegnoli, Ed.
Cisco Cisco
March 8, 2015 May 13, 2015
SAVI for Mixed Address Assignment Methods Scenario SAVI for Mixed Address Assignment Methods Scenario
draft-ietf-savi-mix-07 draft-ietf-savi-mix-08
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 39 skipping to change at page 1, line 38
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 September 9, 2015. This Internet-Draft will expire on November 14, 2015.
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 23 skipping to change at page 2, line 23
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Recommendations for preventing collisions . . . . . . . . . . 5 5. Recommendations for preventing collisions . . . . . . . . . . 5
6. Resolving binding collisions . . . . . . . . . . . . . . . . 5 6. Resolving binding collisions . . . . . . . . . . . . . . . . 5
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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
There are currently several SAVI documents ([RFC6620], [savi-dhcp] There are currently several SAVI documents ([RFC6620], [savi-dhcp]
and [RFC7219]) that describe the different methods by which a switch and [RFC7219]) that describe the different methods by which a switch
can discover and record bindings between a node's IP address and a can 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,
skipping to change at page 7, line 30 skipping to change at page 7, line 30
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. IANA Considerations 7. Security Considerations
SAVI MIX does not eliminate the security problems of each SAVI
method. Thus, the potential attacks, e.g., the DoS attack against
the SAVI device resource, can still happen. In deployment, the
security threats from each enabled SAVI methods should be prevented
by the corresponding proposed solutions in each document.
SAVI MIX is only a binding setup/removal arbitration mechanism. It
does not introduce additional security threats only if the principle
of decision is reasonable. However, there is a slight problem. SAVI
MIX is more tolerant about binding establish than each SAVI method
alone. As long as one of the enabled SAVI method generates a
binding, the binding will be applied. As a result, the allowed
binding number limitation or allowed binding setup rate limitation
will be the sum of all the enabled SAVI methods. In deployment,
whether a SAVI device is capable to support that resource requirement
should be evaluated.
8. IANA Considerations
This memo asks the IANA for no new parameters. This memo asks the IANA for no new parameters.
8. Acknowledgment 9. Acknowledgment
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.
This document was generated using the xml2rfc tool. 10. References
9. References
9.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, [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt,
"Source Address Validation Improvement (SAVI) Framework", "Source Address Validation Improvement (SAVI) Framework",
RFC 7039, October 2013. RFC 7039, October 2013.
[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
skipping to change at page 8, line 19 skipping to change at page 8, line 39
[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, May 2014.
[savi-dhcp] [savi-dhcp]
Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for
DHCP", draft-ietf-savi-dhcp-34 (work in progress), Feb DHCP", draft-ietf-savi-dhcp-34 (work in progress), Feb
2015. 2015.
9.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. September 2007.
[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.
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 Tsinghua University
 End of changes. 12 change blocks. 
18 lines changed or deleted 34 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/