draft-ietf-v6ops-addr-select-req-02.txt   draft-ietf-v6ops-addr-select-req-03.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: November 16, 2007 R. Hiromi Expires: April 14, 2008 R. Hiromi
K. Kanayama K. Kanayama
Intec Netcore Intec Netcore
May 15, 2007 October 12, 2007
Requirements for address selection mechanisms Requirements for address selection mechanisms
draft-ietf-v6ops-addr-select-req-02.txt draft-ietf-v6ops-addr-select-req-03.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 November 16, 2007. This Internet-Draft will expire on April 14, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
In a multi-prefix environment, nodes could have multiple addresses on In a multi-prefix environment, nodes could have multiple addresses on
one network interface. RFC 3484 defines source and destination one network interface. RFC 3484 defines a source and destination
address-selection algorithm, which is commonly deployed in current address-selection algorithm, which is commonly deployed in current
popular OSs. However, nodes could encounter some difficulties in popular OSs. However, nodes could encounter some difficulties in
network communication when they use default address selection rules network communication when they use default address selection rules
defined in RFC 3484. Some mechanisms for solving address selection defined in RFC 3484. Some mechanisms for solving address-selection
problems are proposed including the RFC 3484 policy table problems are proposed including the RFC 3484 policy table
distribution and ICMP error-based mechanisms. This document distribution and ICMP error-based mechanisms. This document
describes the requirements for these address selection mechanisms. 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 . . . . . . . . . . . . . . . . . . 4
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
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 3.1. List of threats introduced by new address-selection
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 mechanism . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative References . . . . . . . . . . . . . . . . . . . 5 3.2. List of recommendations in which security mechanism
5.2. Informative References . . . . . . . . . . . . . . . . . . 5 should be applied . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 7 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 8
1. Introduction 1. Introduction
One physical network can have multiple logical networks. In that One physical network can have multiple logical networks. In that
case, an end-host has multiple IP addresses. ( e.g. In the IPv4-IPv6 case, an end-host has multiple IP addresses. (e.g., in the IPv4-IPv6
dual-stack environment, in a site that uses both ULA [RFC4193] and dual-stack environment, in a site that uses both ULA [RFC4193] and
global scope addresses or in a site connected to multiple upstream global scope addresses or in a site connected to multiple upstream
IPv6 networks) For such a host, RFC 3484 [RFC3484] defines default IPv6 networks) For such a host, RFC 3484 [RFC3484] defines default
address-selection rules for the source and destination addresses. address-selection rules for the source and destination addresses.
Today, the RFC 3484 mechanism is widely implemented in major OSs. Today, the RFC 3484 mechanism is widely implemented in major OSs.
However, we and others have found that in many sites the default However, we and others have found that in many sites the default
address-selection rules are not appropriate for the network address-selection rules are not appropriate for the network
structure. PS [I-D.ietf-v6ops-addr-select-ps] lists problematic structure. PS [I-D.ietf-v6ops-addr-select-ps] lists problematic
cases that resulted from incorrect address selection. cases that resulted from incorrect address selection.
skipping to change at page 3, line 41 skipping to change at page 3, line 41
2. Requirements of Address Selection 2. Requirements of Address Selection
Address-selection mechanisms have to fulfill the following seven Address-selection mechanisms have to fulfill the following seven
requirements. requirements.
2.1. Effectiveness 2.1. Effectiveness
The mechanism can modify RFC 3484 default address-selection behavior The mechanism can modify RFC 3484 default address-selection behavior
at nodes. As documented in PS [I-D.ietf-v6ops-addr-select-ps], the at nodes. As documented in PS [I-D.ietf-v6ops-addr-select-ps], the
default rules defined in RFC 3484 do not work properly in some default rules defined in RFC 3484 do not work properly in some
environment. Therefore, the mechanism has to be able to modify environments. Therefore, the mechanism has to be able to modify
address-selection behavior of a host. address-selection behavior of a host.
2.2. Timing 2.2. Timing
Nodes can obtain address selection information when necessary. If Nodes can obtain address selection information when necessary. If
nodes need to have address-selection information before performing nodes need to have address-selection information before performing
address selection, then the mechanism has to provide a way for nodes address selection, then the mechanism has to provide a function for
to obtain necessary information beforehand. The mechanism should not nodes to obtain necessary information beforehand. The mechanism
degrade userbility. The mechanism should not enforce long address- should not degrade usability. The mechanism should not enforce long
selection processing time upon users. address-selection processing time upon users.
2.3. Dynamic Behavior Update 2.3. Dynamic Behavior Update
Address-selection behavior of nodes can be dynamically updated. When Address-selection behavior of nodes can be dynamically updated. When
the network structure changes and address-selection behavior has to the network structure changes and address-selection behavior has to
be changed accordingly, a network administrator can modify the be changed accordingly, a network administrator can modify the
address-selection behavior of nodes. address-selection behavior of nodes.
2.4. Node-Specific Behavior 2.4. Node-Specific Behavior
skipping to change at page 4, line 37 skipping to change at page 4, line 37
2.6. Multiple Interface 2.6. Multiple Interface
The mechanism can support those nodes equipped with multiple The mechanism can support those nodes equipped with multiple
interfaces. The mechanism has to assume that nodes have multiple interfaces. The mechanism has to assume that nodes have multiple
interfaces and makes address selection of those nodes work interfaces and makes address selection of those nodes work
appropriately. appropriately.
2.7. Central Control 2.7. Central Control
The address selection behavior of nodes can be centrally controlled. The address selection behavior of nodes can be centrally controlled.
A site administrator or a service provider can determine or have A site administrator or a service provider could determine or could
effect on address-selection behavior at their users' hosts. have effect on address-selection behavior at their users' hosts.
2.8. Next-hop Selection 2.8. Next-hop Selection
The mechanism can control next-hop-selection behavior at hosts or The mechanism can control next-hop-selection behavior at hosts or
cooperate with other routing mechanisms, such as routing protocols cooperate with other routing mechanisms, such as routing protocols
and RFC 4191 [RFC4191]. If the address-selection mechanism is used and RFC 4191 [RFC4191]. If the address-selection mechanism is used
with a routing mechanism, the two mechanisms has to be able to work with a routing mechanism, the two mechanisms have to be able to work
synchronousely. synchronously.
3. Security Considerations 3. Security Considerations
Incorrect address-selection can lead to serious security problems, 3.1. List of threats introduced by new address-selection mechanism
such as session hijack. However, we should note that address-
selection is ultimately decided by nodes and their users. There are There are some security incidents when combining these requirements
no means to enforce a specific address-selection behavior upon every described in Section 2 into a protocol. In particular, here are six
end-host from outside of the host. Therefore, a network possible threats.
administrator has to take countermeasures for unexpected address
selection. 1. Hijacking or tapping from malicious nodes connecting from beyond
unapproved network boundaries.
2. Malicious changing of policy data by nonapproved nodes.
3. Denial of Service Attack due to higher traffic volume, and
blocked communication, for example, at both node and network
caused by sending unsafe and tampered data from unbidden
controller.
4. Attempt to stop service on node/computer resources caused by
unnecessary communication between the controller and nodes.
5. Intrusion into security boundary caused by malicious use of
multiprefix environment.
6. Leakage of network policy information from central controller.
3.2. List of recommendations in which security mechanism should be
applied
All the methods listed below should be well-considered for protecting
against security threats. There is no necessity to comply with all
items at same time, if one or more spec(s) could apply to other
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
at domain boundaries.
6. Consideration of the necessity of data independency at every node
or every interface for avoidance of mixing multiple policy data.
7. Consideration of the necessity of having a mechanism for
controlling policy and all related network information on the
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]
skipping to change at page 6, line 11 skipping to change at page 7, line 11
Phone: +81 422 59 3334 Phone: +81 422 59 3334
Email: arifumi@nttv6.net Email: arifumi@nttv6.net
Tomohiro Fujisaki Tomohiro Fujisaki
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
Phone: +81 422 59 7351 Phone: +81 422 59 7351
Email: fujisaki@syce.net Email: fujisaki@nttv6.net
Ruri Hiromi Ruri Hiromi
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: hiromi@inetcore.com Email: hiromi@inetcore.com
 End of changes. 15 change blocks. 
31 lines changed or deleted 78 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/