draft-ietf-savi-framework-03.txt   draft-ietf-savi-framework-04.txt 
Network Working Group J. Wu Network Working Group J. Wu
Internet-Draft J. Bi Internet-Draft J. Bi
Intended status: Informational Tsinghua Univ. Intended status: Informational Tsinghua Univ.
Expires: September 13, 2011 M. Bagnulo Expires: September 29, 2011 M. Bagnulo
UC3M UC3M
F. Baker F. Baker
Cisco Cisco
C. Vogt, Ed. C. Vogt, Ed.
Ericsson Ericsson
March 12, 2011 March 28, 2011
Source Address Validation Improvement Framework Source Address Validation Improvement Framework
draft-ietf-savi-framework-03 draft-ietf-savi-framework-04
Abstract Abstract
The Source Address Validation Improvement method was developed to The Source Address Validation Improvement method was developed to
complement ingress filtering with finer-grained, standardized IP complement ingress filtering with finer-grained, standardized IP
source address validation. This document describes and motivates the source address validation. This document describes and motivates the
design of the SAVI method. design of the SAVI method.
Status of this Memo Status of this Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 13, 2011. This Internet-Draft will expire on September 29, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 3, line 13 skipping to change at page 3, line 13
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Deployment Options . . . . . . . . . . . . . . . . . . . . . . 6 3. Deployment Options . . . . . . . . . . . . . . . . . . . . . . 6
4. Scalability Optimizations . . . . . . . . . . . . . . . . . . 8 4. Scalability Optimizations . . . . . . . . . . . . . . . . . . 8
5. Reliability Optimizations . . . . . . . . . . . . . . . . . . 10 5. Reliability Optimizations . . . . . . . . . . . . . . . . . . 10
6. Mix Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Mix Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Prefix Configuration . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10.1. Informative References . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.2. Normative References . . . . . . . . . . . . . . . . . . 12 11.1. Informative References . . . . . . . . . . . . . . . . . 12
11.2. Normative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Since IP source addresses are used by hosts and network entities to Since IP source addresses are used by hosts and network entities to
determine the origin of a packet and as a destination for return determine the origin of a packet and as a destination for return
data, spoofing of IP source addresses can enable impersonation, data, spoofing of IP source addresses can enable impersonation,
concealment, and malicious traffic redirection. Unfortunately, the concealment, and malicious traffic redirection. Unfortunately, the
Internet architecture does not prevent IP source address spoofing Internet architecture does not prevent IP source address spoofing
[draft-ietf-savi-threat-scope]. Since the IP source address of a [draft-ietf-savi-threat-scope]. Since the IP source address of a
skipping to change at page 11, line 22 skipping to change at page 11, line 22
used to assign addresses from the same prefix. used to assign addresses from the same prefix.
Prioritization relationship between different address assignment Prioritization relationship between different address assignment
methods is used as the basis to solve possible collisions. Current methods is used as the basis to solve possible collisions. Current
standard documents of address assignment methods have implied the standard documents of address assignment methods have implied the
prioritization relationship in general cases. However, considering prioritization relationship in general cases. However, considering
in some scenarios, default prioritization level may not be quite in some scenarios, default prioritization level may not be quite
suitable. Configurable prioritization level should be supported in a suitable. Configurable prioritization level should be supported in a
document of SAVI solution for the mix scenario. document of SAVI solution for the mix scenario.
7. Acknowledgment 7. Prefix Configuration
Before setting up a host-level granularity binding, it is important
to configure correct prefixes on the SAVI device. This document
suggests set 3 prefix configuration mechanisms at SAVI device:
o Manually Prefix Configuration: The allowed prefix scope of IPv4
Addresses, IPv6 static addresses, IPv6 addresses assigned by
SLAAC, and IPv6 addresses assigned by DHCPv6 can be set manually
at SAVI device. FE80::/64 is always a feasible prefix in IPv6.
o Prefix Configuration by RA Snooping: The allowed prefix scope of
IPv6 static addresses and IPv6 addresses assigned by SLAAC can be
set at SAVI device through snooping RA message at SAVI device.
FE80::/64 is always a feasible prefix in IPv6.
o Prefix Configuration by DHCP-PD Snooping: The allowed prefix
scope of IPv6 static addresses, IPv6 addresses assigned by SLAAC,
and IPv6 addresses assigned by DHCPv6 can be set through snooping
DHCP-PD message at SAVI device. FE80::/64 is always a feasible
prefix in IPv6.
If some of the prefix scopes is set to have non prefix, it implies
corresponding address assignment method is not allowed in the
network.
There is no need to explicitly present these prefix scopes, but these
restrictions should be used as premier check in binding set up.
8. Acknowledgment
The author would like to thank the SAVI working group for a thorough The author would like to thank the SAVI working group for a thorough
technical discussion on the design and the framework of the SAVI technical discussion on the design and the framework of the SAVI
method, as captured in this document, in particular Erik Nordmark, method, as captured in this document, in particular Erik Nordmark,
Guang Yao, Eric Levy-Abegnoli, and Alberto Garcia. Thanks also to Guang Yao, Eric Levy-Abegnoli, and Alberto Garcia. Thanks also to
Torben Melsen for reviewing this document. Torben Melsen for reviewing this document.
This document was generated using the xml2rfc tool. This document was generated using the xml2rfc tool.
8. IANA Considerations 9. IANA Considerations
This memo asks the IANA for no new parameters. This memo asks the IANA for no new parameters.
Note to RFC Editor: This section will have served its purpose if it Note to RFC Editor: This section will have served its purpose if it
correctly tells IANA that no new assignments or registries are correctly tells IANA that no new assignments or registries are
required, or if those assignments or registries are created during required, or if those assignments or registries are created during
the RFC publication process. From the authors' perspective, it may the RFC publication process. From the authors' perspective, it may
therefore be removed upon publication as an RFC at the RFC Editor's therefore be removed upon publication as an RFC at the RFC Editor's
discretion. discretion.
9. Security Considerations 10. Security Considerations
This document only discusses the possible methods to mitigrate the This document only discusses the possible methods to mitigrate the
usage of forged IP address, but doesn't propose a mechanism that usage of forged IP address, but doesn't propose a mechanism that
provides strong security for IP address. If binding anchor is not provides strong security for IP address. If binding anchor is not
exclusive for each user, or is without strong security, addresses can exclusive for each user, or is without strong security, addresses can
still be forged. Besides, the binding may not accord with the still be forged. Besides, the binding may not accord with the
address management requirement, which can be more specified for each address management requirement, which can be more specified for each
client. However, given no new protocol is introduced, the client. However, given no new protocol is introduced, the
improvements are still acceptable. If there is requirement the usage improvements are still acceptable. If there is requirement the usage
of IP address must be of strong security, the only way is using of IP address must be of strong security, the only way is using
cryptographic based authentication. cryptographic based authentication.
10. References 11. References
10.1. Informative References 11.1. Informative References
[BA2007] Baker, F., "Cisco IP Version 4 Source Guard", IETF [BA2007] Baker, F., "Cisco IP Version 4 Source Guard", IETF
Internet draft (work in progress), November 2007. Internet draft (work in progress), November 2007.
[BCP38] Paul, P. and D. Senie, "Network Ingress Filtering: [BCP38] Paul, 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", RFC 2827, BCP 38, May 2000. Address Spoofing", RFC 2827, BCP 38, May 2000.
10.2. Normative References 11.2. Normative References
[draft-ietf-savi-threat-scope] [draft-ietf-savi-threat-scope]
McPherson, D., Baker, F., and J. Halpern, "SAVI Threat McPherson, D., Baker, F., and J. Halpern, "SAVI Threat
Scope", draft-ietf-savi-threat-scope-04 (work in Scope", draft-ietf-savi-threat-scope-04 (work in
progress), March 2011. progress), March 2011.
[rfc2131] Droms, R., "Dynamic Host Configuration Protocol", [rfc2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. RFC 2131, March 1997.
[rfc3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [rfc3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
 End of changes. 11 change blocks. 
16 lines changed or deleted 46 lines changed or added

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