draft-ietf-v6ops-addr-select-req-04.txt   draft-ietf-v6ops-addr-select-req-05.txt 
IPv6 Operations Working Group A. Matsumoto IPv6 Operations Working Group A. Matsumoto
Internet-Draft T. Fujisaki Internet-Draft T. Fujisaki
Intended status: Informational NTT Intended status: Informational NTT
Expires: May 9, 2008 R. Hiromi Expires: September 7, 2008 R. Hiromi
K. Kanayama K. Kanayama
Intec Netcore Intec Netcore
November 6, 2007 March 6, 2008
Requirements for address selection mechanisms Requirements for address selection mechanisms
draft-ietf-v6ops-addr-select-req-04.txt draft-ietf-v6ops-addr-select-req-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 9, 2008. This Internet-Draft will expire on September 7, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
In a multi-prefix environment, nodes could have multiple addresses on There are some problematic cases when using default address selection
one network interface. RFC 3484 defines a source and destination mechanism which RFC 3484 defines. This document describes additional
address-selection algorithm, which is commonly deployed in current requirements co-working with RFC3484 to solve the problems.
popular OSs. However, nodes could encounter some difficulties in
network communication when they use default address selection rules
defined in RFC 3484. Some mechanisms for solving address-selection
problems are proposed including the RFC 3484 policy table
distribution and ICMP error-based mechanisms. This document
describes requirements for these address-selection mechanisms.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements of Address Selection . . . . . . . . . . . . . . . 3 2. Requirements of Address Selection . . . . . . . . . . . . . . . 3
2.1. Effectiveness . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Effectiveness . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Dynamic Behavior Update . . . . . . . . . . . . . . . . . . 4 2.3. Dynamic Behavior Update . . . . . . . . . . . . . . . . . . 3
2.4. Node-Specific Behavior . . . . . . . . . . . . . . . . . . 4 2.4. Node-Specific Behavior . . . . . . . . . . . . . . . . . . 4
2.5. Application-Specific Behavior . . . . . . . . . . . . . . . 4 2.5. Application-Specific Behavior . . . . . . . . . . . . . . . 4
2.6. Multiple Interface . . . . . . . . . . . . . . . . . . . . 4 2.6. Multiple Interface . . . . . . . . . . . . . . . . . . . . 4
2.7. Central Control . . . . . . . . . . . . . . . . . . . . . . 4 2.7. Central Control . . . . . . . . . . . . . . . . . . . . . . 4
2.8. Next-hop Selection . . . . . . . . . . . . . . . . . . . . 4 2.8. Next-hop Selection . . . . . . . . . . . . . . . . . . . . 4
2.9. Compatibility with RFC 3493 . . . . . . . . . . . . . . . . 4 2.9. Compatibility with RFC 3493 . . . . . . . . . . . . . . . . 4
2.10. Security . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
3.1. List of threats introduced by new address-selection 3.1. List of threats introduced by new address-selection
mechanism . . . . . . . . . . . . . . . . . . . . . . . . . 5 mechanism . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. List of recommendations in which security mechanism 3.2. List of recommendations in which security mechanism
should be applied . . . . . . . . . . . . . . . . . . . . . 5 should be applied . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . . 6 5.2. Informative References . . . . . . . . . . . . . . . . . . 6
Appendix A. Appendix. Revision History . . . . . . . . . . . . . . 6 Appendix A. Appendix. Revision History . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 8
1. Introduction 1. Introduction
One physical network can have multiple logical networks. In that Today, the RFC 3484 [RFC3484] mechanism is widely implemented in
case, an end-host has multiple IP addresses. (e.g., in the IPv4-IPv6 major OSs. However, in many sites, the default address-selection
dual-stack environment, in a site that uses both ULA [RFC4193] and rules are not appropriate, and cause a communication failure. PS
global scope addresses or in a site connected to multiple upstream [I-D.ietf-v6ops-addr-select-ps] lists problematic cases that resulted
IPv6 networks) For such a host, RFC 3484 [RFC3484] defines default from incorrect address selection.
address-selection rules for the source and destination addresses.
Today, the RFC 3484 mechanism is widely implemented in major OSs.
However, we and others have found that in many sites the default
address-selection rules are not appropriate for the network
structure. PS [I-D.ietf-v6ops-addr-select-ps] lists problematic
cases that resulted from incorrect address selection.
Though RFC 3484 made the address-selection behavior of a host Though RFC 3484 made the address-selection behavior of a host
configurable, typical users cannot make use of that because of the configurable, typical users cannot make use of that because of the
complexity of the mechanism and lack of knowledge about their network complexity of the mechanism and lack of knowledge about their network
topologies. Therefore, an address-selection autoconfiguration topologies. Therefore, an address-selection autoconfiguration
mechanism is necessary, especially for unmanaged hosts of typical mechanism is necessary, especially for unmanaged hosts of typical
users. users.
This document contains requirements for address-selection mechanisms This document contains requirements for address-selection mechanisms
that enable hosts to perform appropriate address selection that enable hosts to perform appropriate address selection
skipping to change at page 5, line 8 skipping to change at page 5, line 5
2.9. Compatibility with RFC 3493 2.9. Compatibility with RFC 3493
The mechanism can allow an application that uses the basic socket The mechanism can allow an application that uses the basic socket
interface defined in RFC 3493 [RFC3493] to work correctly. That is, interface defined in RFC 3493 [RFC3493] to work correctly. That is,
with the basic socket interface the application can select an with the basic socket interface the application can select an
appropriate source and destination addresses and can communicate with appropriate source and destination addresses and can communicate with
the destination host. This requirement does not necessarily mean the destination host. This requirement does not necessarily mean
that OS protocol stack and socket libraries should not be changed. that OS protocol stack and socket libraries should not be changed.
2.10. Security
The mechanism works without any security problems. Possible security
threats are described in Security Considerations section.
3. Security Considerations 3. Security Considerations
3.1. List of threats introduced by new address-selection mechanism 3.1. List of threats introduced by new address-selection mechanism
There are some security incidents when combining these requirements There will be some security incidents when combining these
described in Section 2 into a protocol. In particular, here are six requirements described in Section 2 into a protocol. In particular,
possible threats. there are 3 types of threats, "Leakage","Hijacking", and "Denial of
Services".
1. Hijacking or tapping from malicious nodes connecting from beyond 1. Tapping from malicious nodes to collect the network policy
unapproved network boundaries. information and leak them to unauthorized parties.
2. Malicious changing of policy data by nonapproved nodes. 2. Hijacking of nodes made possible by malicious injection of
3. Denial of Service Attack due to higher traffic volume, and illegitimate policy information: RFC3484 defines both of source
blocked communication, for example, at both node and network and destination selection algorithm. An attacker able to inject
caused by sending unsafe and tampered data from unbidden malicious policy information could redirect packets sent by a
controller. victim node to an intentionally chosen server that would scan the
4. Attempt to stop service on node/computer resources caused by victim node activities to find out exploit code. Once exploit
unnecessary communication between the controller and nodes. code is found the attacker can take control of the victim node.
5. Intrusion into security boundary caused by malicious use of 3. Denial of Service Attack on the ability of nodes to communicate
multiprefix environment. in the absence of the address selection policy: An attacker could
6. Leakage of network policy information from central controller. launch a flooding attack on the controller to prevent it to
deliver the address selection policy information to nodes, thus
preventing these nodes to appropriately communicate in the
absence of that information.
3.2. List of recommendations in which security mechanism should be 3.2. List of recommendations in which security mechanism should be
applied applied
All the methods listed below should be well-considered for protecting The source address selection protocol should be afforded security
against security threats. There is no necessity to comply with all services listed below. It is preferable that these security services
items at same time, if one or more spec(s) could apply to other are afforded via use of existing protocols(e.g. IPsec).
security requirements. Secure network operation will also be
considered, and describing network operation for network security
will be better. Referring to and using existing technologies is also
preferable.
1. Consideration of the necessity to use digitally signed or
cryptographic messages.
2. Consideration of the necessity to maintain confidentiality of
source of policy data.
3. Consideration of the necessity of authentication and validation
of both entity and message integrity.
4. Consideration of the necessity of having a mechanism for the
avoidance of data conflicts if the policy data comes from
multiple controllers.
5. Consideration of the necessity of an appropriate filtering method 1. Integrity of the network policy information itself and the
at domain boundaries. messages exchanging in the protocol. This is countermeasure
6. Consideration of the necessity of data independency at every node against "Leakage", "Hijacking", and "Denial of Services".
or every interface for avoidance of mixing multiple policy data. 2. Authentication and authorization of parties involved in the
7. Consideration of the necessity of having a mechanism for protocol. This is countermeasure against "Leakage" and
controlling policy and all related network information on the "Hijacking".
server if the server stores policy and all related neetowrk
information on the outside of its network domain.
8. Consideration of the necessity to log and collect related system
data.
4. IANA Considerations 4. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
5. References 5. References
5.1. Normative References 5.1. Normative References
[I-D.ietf-v6ops-addr-select-ps] [I-D.ietf-v6ops-addr-select-ps]
Matsumoto, A., "Problem Statement of Default Address Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
Selection in Multi-prefix Environment: Operational Issues "Problem Statement of Default Address Selection in Multi-
of RFC3484 Default Rules", prefix Environment: Operational Issues of RFC3484 Default
draft-ietf-v6ops-addr-select-ps-02 (work in progress), Rules", draft-ietf-v6ops-addr-select-ps-04 (work in
October 2007. progress), February 2008.
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, February 2003. RFC 3493, February 2003.
5.2. Informative References
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005. More-Specific Routes", RFC 4191, November 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 5.2. Informative References
Addresses", RFC 4193, October 2005.
Appendix A. Appendix. Revision History Appendix A. Appendix. Revision History
05:
A new requirement item "Security" was added. Security
Considerations section was rewritten according to comments from
SECDIR.
04: 04:
A new requirement item "Compatibility with RFC 3493" was added, A new requirement item "Compatibility with RFC 3493" was added,
which reflected a comment from Remi Denis-Courmont at the v6ops which reflected a comment from Remi Denis-Courmont at the v6ops
mailing list. mailing list.
03: 03:
Security Consideration section was rewritten according to comments Security Considerations section was rewritten according to
from SECDIR. comments from SECDIR.
02: 02:
The description and evaluation of solution approaches were The description and evaluation of solution approaches were
separated into a new document called separated into a new document called
draft-arifumi-v6ops-addr-select-sol-00. draft-arifumi-v6ops-addr-select-sol-00.
01: 01:
Other than policy table distribution approach, the solution Other than policy table distribution approach, the solution
section included several solutions discussed at 67th IETF meeting. section included several solutions discussed at 67th IETF meeting.
Authors' Addresses Authors' Addresses
Arifumi Matsumoto Arifumi Matsumoto
NTT PF Lab NTT PF Lab
Midori-Cho 3-9-11 Midori-Cho 3-9-11
Musashino-shi, Tokyo 180-8585 Musashino-shi, Tokyo 180-8585
Japan Japan
skipping to change at page 9, line 7 skipping to change at page 8, line 7
Intec Netcore, Inc. Intec Netcore, Inc.
Shinsuna 1-3-3 Shinsuna 1-3-3
Koto-ku, Tokyo 136-0075 Koto-ku, Tokyo 136-0075
Japan Japan
Phone: +81 3 5665 5069 Phone: +81 3 5665 5069
Email: kanayama@inetcore.com Email: kanayama@inetcore.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 23 change blocks. 
83 lines changed or deleted 63 lines changed or added

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