One document matched: draft-ietf-multi6-functional-dec-00.txt
Network Working Group M. Bagnulo
Internet-Draft UC3M
Expires: June 22, 2005 J. Arkko
Ericsson
December 22, 2004
Functional decomposition of the M6 protocol
draft-ietf-multi6-functional-dec-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any 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 become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 22, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
In this note we will present a functional decomposition of the M6
protocol i.e. the protocol for preserving established communications
in multihomed environments. We will do so by describing a protocol
walkthrough, presenting which functions have to be performed at each
stage and the messages required to accomplish them. The functional
decomposition presented in this draft is based on the general
Bagnulo & Arkko Expires June 22, 2005 [Page 1]
Internet-Draft Functional decomposition December 2004
functional analysis of multihoming approaches presented in [3].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Initial contact . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Initial contact . . . . . . . . . . . . . . . . . . . . . 4
2.2 Failure during startup . . . . . . . . . . . . . . . . . . 4
3. Capabilities detection and M6 host-pair context
establishment . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Capabilities detection . . . . . . . . . . . . . . . . . . 5
3.1.1 Node Configuration . . . . . . . . . . . . . . . . . . 5
3.1.2 DNS Configuration . . . . . . . . . . . . . . . . . . 5
3.1.3 Host-Based Dynamic Discovery . . . . . . . . . . . . . 6
3.1.4 Timing . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 M6 host-pair context establishment . . . . . . . . . . . . 7
3.2.1 Security Information . . . . . . . . . . . . . . . . . 8
3.2.2 DoS protection. . . . . . . . . . . . . . . . . . . . 8
3.2.3 Resulting M6 host-pair establishement exchange . . . . 9
4. Locator set management . . . . . . . . . . . . . . . . . . . . 10
4.1 Security of the exchange for adding locators . . . . . . . 10
4.2 Security of the exchange for deleting locators . . . . . . 10
5. Re-homing procedure . . . . . . . . . . . . . . . . . . . . . 12
5.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Removal of M6 session state . . . . . . . . . . . . . . . . . 14
6.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Security considerations . . . . . . . . . . . . . . . . . . . 15
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 17
9.2 Informative References . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 18
Bagnulo & Arkko Expires June 22, 2005 [Page 2]
Internet-Draft Functional decomposition December 2004
1. Introduction
In this note we will present a functional decomposition of the M6
protocol i.e. the protocol for preserving established communications
in multihomed environments. We will do so by describing a protocol
walkthrough, presenting which functions have to be performed at each
stage and the messages required to accomplish them. The functional
decomposition presented in this draft is based on the general
functional analysis of multihoming approaches presented in [3].
We will first present some possible procedures for the initial
contact and session state establishment. Next, we will consider the
management of the available locator set. Then, we will consider the
re-homing of an ongoing communication and finally we will deal with
session state removal.
This note is agnostic to the security mechanism used in protecting
the control messages related to multihoming. However, when it is
deemed necessary, a security analysis that attempts to understand the
security required for the message exchange will be included.
Bagnulo & Arkko Expires June 22, 2005 [Page 3]
Internet-Draft Functional decomposition December 2004
2. Initial contact
2.1 Initial contact
During the initial contact, the minimum information that has to be
exchanged by the two communicating nodes is: the identifiers that
have to be presented to the upper layers, and a reachable locator for
each node. In the case that the the identifier presented to the
upper layers is a valid reachable locator, then only this address
that will perform both roles has to be exchanged. If this is the
case, no special M6 features are required. This means that as long
as the identifier and the locator used are the same IPv6 address,
there is no need to perform any special M6 exchange for the initial
contact and regular IPv6 can be used. However, if an identifier that
is different from the locator used for exchanging the initial packet
is used, then the M6 protocol has to be used even to perform the
initial contact between the two nodes, starting by the capabilities
detection procedure described in section 2.1.2.
2.2 Failure during startup
In the case that the locator used for initial contact is unreachable,
there are two possible approaches that can be followed:
One approach is to simply retry the initial contact using a
different locator. This means that the initial contact procedure
is started all over again, using a different locator. This
approach is likely to be the one required when the M6-capable host
is establishing communications with legacy hosts that don't
support the M6 protocol. In this case, the address included in
the initial packet is both the locator and the identifier and if
it is not reachable, an alternative address has to be used. Such
retrying would by default occur at the application layer, which is
aware of the multiple addresses. It might be possible to optimize
this should the transport protocol be made aware of the multiple
addresses.
Another approach is to change locator while preserving the
identifier. This approach is not supported by legacy IPv6 nodes,
so the M6 protocol has to be used in this approach. However, this
scheme would allow to recover from failures on locators used for
initial contact in a upper layer transparent fashion. However, if
this is the case, the full M6 protocol has to be used for initial
contact, starting by the capabilities detection procedure
described next.
Bagnulo & Arkko Expires June 22, 2005 [Page 4]
Internet-Draft Functional decomposition December 2004
3. Capabilities detection and M6 host-pair context establishment
When a M6 capable host desires to obtain the enhanced features
provided by the M6 protocol in the communications established with a
given peer node, it has to first determine if M6 capabilities are
available in the peer node and second establish a M6 host-pair
context, as defined in [5].In this section we will analyze the
different mechanisms to perform both actions.
3.1 Capabilities detection
This section presents a number of possible approaches for the
capability detection, and analyzes their properties.
3.1.1 Node Configuration
A simplistic approach would be to require the M6 capability from
peers, if a node supports M6 and has been configured to use it.
However, this would severely limit the ability of the node to
communicate until the feature is widely supported.
3.1.2 DNS Configuration
A better configuration-based approach would be to add some
information to the DNS to tell the peers whether the target node
supports M6 or not. For instance, a new RR record could be used.
This way each node could dynamically decide whether it can run M6
with the peer or not. This could often be known before actually
attempting to communicate.
This approach requires that every node that wishes to use M6 must
have a DNS entry. In addition, the ability to use M6 and the
information stored to the DNS may not always be synchronized. For
instance, changing the operating system might remove M6 capability
from a particular user's machine, leading to a need for updating DNS.
This synchronization problem could be avoided by the use of Dynamic
DNS updates -- with the implied requirements for setting up a
security association between the DNS servers and client machines.
Similarly, the manually updated DNS approach requires support for
Dynamic DNS [2] where RFC 3041 [1] or other dynamically changing
addresses are used.
Finally, all DNS-based approaches suffer from an an administrative
split between the actual nodes and the ones storing data about them;
establishing Dynamic DNS or manual updates may be hard for a private
subscriber of a large operator, for instance.
Bagnulo & Arkko Expires June 22, 2005 [Page 5]
Internet-Draft Functional decomposition December 2004
On the other hand, a DNS-based mechanism may work well if the chosen
Multi6 protocol is based on the use of DNS, such as in NOID [4].
3.1.3 Host-Based Dynamic Discovery
A host-based mechanism discovers the M6-capability directly between
the communicating nodes. Two variants of this mechanism exist:
Independent
This mechanism adds a message pair for the discovery. If the peer
responds to the message that the initiator sends, then both nodes
know that they support M6.
Integrated
This mechanism uses the rest of the M6 signaling, doing both
actual M6 work and capability detection at the same time.
In the interest of reducing number of initial communications latency,
the second approach would be preferrable. We also argue that a M6
protocol MUST do an initial (or at least an early) signaling exchange
in any case. This is because the nodes need to discover alternate
locators PRIOR to a multihoming event disabling the current ones.
For instance, lets assume hosts A and B communicate over two separate
links without going through the Internet. Lets further assume the
nodes use plain IPv6 at the beginning without M6, and use one of the
links and its prefix P for communication, with addresses P::A and
P::B. If this link goes down, the obvious multihoming solution would
be to switch to Q::A and Q::B, the other link and its prefix.
However, neither side is aware that the other node is available under
the Q prefix, so communications can not continue.
On the other hand, the integrated approach makes the initial packets
larger which is a disadvantage when the peer does not support
multihoming. However, we do not expect the M6 part of the initial
packets to be large or contain many addresses on the average, so this
seems like a good engineering tradeoff.
3.1.4 Timing
Capability detection needs to occurr prior to or at the same time as
Multi6 state is created between peers. If the capabilities are
stored in DNS, a convenient time to look this information is at the
time a DNS query is made (even if it may not always lead to an actual
communication attempt later). If host-based discovery is used, the
Bagnulo & Arkko Expires June 22, 2005 [Page 6]
Internet-Draft Functional decomposition December 2004
best time to perform it is in the initial Multi6 exchange packets.
The capabilities of the peer must be remembered while the M6 state
exists; the state persistence is discussed in Section 5 of [4]. The
capabilities should preferrably be cached even beyond this, in order
to avoid discovering the capabilities and/or locators of peers when
they are contacted again within a small time frame.
Negative caching should be used to remember the peers which do not
support multihoming. Depending on the type of the chosen capability
detection mechanisms, this state is indexed either by an IP address
or by both IP addresses and identifiers. The latter becomes
necessary if DNS configuration indicates an identifier and Multi6
cabability, but the node refuses to communicate using M6.
3.2 M6 host-pair context establishment
Once that the the M6 protocol support is confirmed, the ULP
identifiers associated to the M6 host-pair context need to be
defined.
With respect to locator exchange, it is clear that at least one
locator (the one included in the source address field of the packet)
is exchanged in the initial contact. The question would be if
additional locators are needed to be exchanged during the M6
host-pair context establishment phase. Several considerations
should be taken into account at this point: On one hand, the
capability of recovering from an outage may depend on knowing
alternative locators of the other node. It is clear that a node is
aware of its own locators, so a possible approach would be that if a
failure is detected, the node simply tries to communicate using an
alternative source locator. Since both nodes behave this way, a
failure in any single locator used in the communication can be
recovered. However, in the case that both locators used in the
communication fail simultaneously, the approach of trying different
source addresses will not be enough to restore the communication.
This is basically because retrying with a different source address
assumes that at least on of the original locators is working. So, in
order to be able to provide fault tolerance support in the situations
when both locators fail simultaneously, it is required that at least
one of the nodes is aware of multiple locators of its correspondent
node. On the other hand, exchanging alternative locator information
imposes an additional overhead in the communication, which is only
useful if an outage occurs (which is supposed not to be so frequent).
In conclusion, adding additional locators in the M6 host-pair context
establishment exchange provides enhanced fault tolerance but it
imposes an additional cost. A reasonable approach would be that the
Bagnulo & Arkko Expires June 22, 2005 [Page 7]
Internet-Draft Functional decomposition December 2004
M6 host-pair context establishment exchange should support the
exchange of additional locators, but should not mandate it. In
addition, the M6 protocol should support the exchange additional
locators during the lifetime of the session.
Besides the identifiers and locators associated to the M6 session, it
may be required to negotiate Context Tags that allow to identify data
packets that belong to that M6 host-pair context. The need of such
Context Tags depends on the demultiplexing mechanism used, as
described in [5]
3.2.1 Security Information
In addition, it seems that security related information needs to be
exchanged during the M6 host-pair context establishment exchange.
Including a sort of cookie/key/hash chain anchor in the exchange,
limits the potential attackers to those present in the path during
this initial exchange. It also implies that in order to complete the
exchange, the other node must be receiving the reply packets. In
addition, such key would be useful to secure future exchanges. So,
it seems a good option to exchange a shared secret during the M6
host-pair context establishment exchange.
The exchange of additional security information may be required to
provide protection against future attacks, depending on the security
scheme used.
3.2.2 DoS protection.
Depending on the mechanism used to provide protection against future
attacks, the M6 host-pair context establishment exchange may more or
less susceptible to DoS attacks. If the security mechanism used
requires a considerable amount of processing, it may be used to
launch a DoS attack consuming the processing power of the receiver.
In addition, after the exchange is completed, a state is created in
each node, storing information about identifiers, multiple locators,
keys and so on. Such state requires memory, so it can be used by a
malicious node to generate a DoS attack based in memory consumption.
In order to provide some protection from these attacks, the receiver
node should not create any state until the initiating node has done
so. This can be achieved by using a 4 way exchange, where the
receiver does not create any state until the third packet and the
initiator has to prove that it has some state created after receiving
the second packet. This can be done by the initiator by showing some
information received in the second packet and that the receiver can
regenerate without requiring some specific information (like hashing
a key and the initiator address). The result is not a complete
Bagnulo & Arkko Expires June 22, 2005 [Page 8]
Internet-Draft Functional decomposition December 2004
protection from such attacks, since the resulting state in the
receiver is long lived, and the attacker can discard its state after
finishing the 4 way handshake. However, after the 4 way handshake,
the receiver will know a valid locator of the attacker, which can be
used to track the attacker.
3.2.3 Resulting M6 host-pair establishement exchange
Initiator Receiver
| P1 |
|-------------------------->|
| P2 |
|<--------------------------|
| P3 |
|-------------------------->|
| P4 |
|<--------------------------|
P1 is essentially a request to initiate an exchange. It will also be
used to detect the M6 capability of the receiver.
P2 will provide the information needed by the initiator to prove that
he has some state about this communication. So, P2 will contain
something like a Hash of a secret key of the receiver (common to all
initiators) and the initiator's address. The receiver will receive
P1 and generate P2 without creating any state specific to this
communication. It would be possible to also include the alternative
locators of the receiver in P2. The question about this if this
couldn't be used as an amplifier to launch other DoS attacks to third
parties.
P3 will contain the Hash obtained in P2. In addition, it will
contain the identifier used for this communication and it may contain
alternative locator information. In addition, information to
validate the locator set may be included. Finally, the
key/cookie/hash chain anchor related information is also included.
P4 serves as an acknowledgment of the information received in P3 and
it also includes information about alternative locators, identifier
and key/cookie/hash chain anchor related information that hasn't been
exchanged yet.
Bagnulo & Arkko Expires June 22, 2005 [Page 9]
Internet-Draft Functional decomposition December 2004
4. Locator set management
The management of the locator set involves adding new locators and
removing existing locators.
The reasons for adding a new locator are pretty straightforward:
there is an additional locator that the holder node wants to add to
the available set. The reasons for that may be that a new locator is
available in the node (e.g. a mobile node) or simply that the node
wants to obtain enhanced fault tolerance by adding additional
locators to the available set.
The reasons for deleting an existing locator are essentially local.
Nodes have local information about the status of their own locators.
In case that one of the locators becomes unavailable for some reason
(e.g. it is deprecated through Router Advertisement) it would make
sense to inform the other nodes that this locator should no longer be
used.
There are two possible approaches to the addition and removal of
locators: atomic and differential approaches. Atomic approaches
essentially send the complete locators set each time that a variation
in the locator set occurs. In this case, there is only one message
exchange defined i.e. a message that informs about the new locator
set and an acknowledgment message. Differential messages send the
differences between the existing locator set and the new one. In
this case, a message for adding a new locator and another message for
deleting locators have to be defined. Both messages can be
acknowledged. The atomic approach imposes additional overhead, since
all the locator set has to be exchanged each time while the
differential approach requires re-synchronization of both ends
through changes i.e. that both ends have the same idea about what
the current locator set is.
4.1 Security of the exchange for adding locators
The additional locators conveyed through this mechanism should belong
to the node that performed the initial exchange. Security
information must be included in this messages to prove that. One
possibility is to include information about the key/cookie/hash chain
defined in the initial exchange. This is not enough to prevent
future attacks. In order to provide future attack protection,
alternative schemes like HBA or CGAs has to be used.
4.2 Security of the exchange for deleting locators
The security required for the message for removing a locator may be
achieved using the key/cookie/hash chain information created during
Bagnulo & Arkko Expires June 22, 2005 [Page 10]
Internet-Draft Functional decomposition December 2004
the initial contact exchange.
Bagnulo & Arkko Expires June 22, 2005 [Page 11]
Internet-Draft Functional decomposition December 2004
5. Re-homing procedure
The re-homing procedure occurs when a new locator pair is to be used
for the communication. The reason for a re-homing is essentially
that the current locator pair is no longer working. The re-homing
procedure involves detecting that the locator pair currently in use
is no longer working, exploring alternative locator pairs and
re-homing the communication to the reachable locator pair.
In order to verify that a locator pair is working, a Reachability
Test exchange is needed. This can be used to check if the locator
pair that is being used is working properly or to explore if
potential locator pairs are working. In addition, in the last case,
the Reachability Test is also a mechanism to prevent thrid-party
flooding attacks.
The Reachability Test exchange includes the following packets:
Reachability Test (RT) packet: including the random nonce and
maybe information related to the initial key/cookie/hash chain
Reachability Test Reply (RTR) packet: include the nonce of the RT
packet and maybe information related to the initial
key/cookie/hash chain
In the case that a bidirectional path is available, the pair of
locators contained in the RT and RTR packets will be the same.
However, if only two disjoints unidirectional paths are available,
the locators contained in the RT will differ from the ones included
in the RTR. Additional discussion on this topic can be found in [6].
5.1 Security
In any case, it is required to know if there is a node replying at
the other end. The messages should include a nonce in order to match
the replies with original messages. In addition, the nonce should be
randomly selected, imposing the reception of the initial message to
be able to properly generate the reply. Finally, including
information related to the key/cookie/hash chain defined in the
initial exchange would guarantee that only the node involved in the
initial exchange can participate in the reachability exchange
(depending on the particular mechanism, this may be more or less
expensive) In the case that the mechanism is used to prevent
third-party flooding attacks additional security measures are needed,
since any M6 capable host would reply to a Reachability Test request,
precluding its usage as flooding attack prevention. So, in order to
use this mechanism to prevent flooding, additional checks are needed.
One option would be to include information related to the
Bagnulo & Arkko Expires June 22, 2005 [Page 12]
Internet-Draft Functional decomposition December 2004
key/cookie/hash chain defined in the initial exchange as described
above. Another option would be to require that nodes only reply
Reachability Test requests coming from nodes that they are already
communicating with.
Bagnulo & Arkko Expires June 22, 2005 [Page 13]
Internet-Draft Functional decomposition December 2004
6. Removal of M6 session state
There are essentially two approaches for discarding an existing state
about locators, keys and identifiers of a correspondent node: a
coordinated approach and an unilateral approach.
In the unilateral approach, each node discards the information about
the other node without coordination with the other node based on some
local timers and heuristics. No packet exchange is required for
this. In this case, it would be possible that one of the nodes has
discarded the state while the other node still hasn't. In this case,
an error message may be required to inform about the situation.
In the coordinated approach, there is a closing exchange that is
performed in order to coordinate the process, in order to make sure
that both nodes discard the state related to the previous
communication. This would require a pair of messages Close and
Close-ACK.
6.1 Security
The Close message has to be secured using the key/cookie/hash chain
information created during the initial contact exchange.
Bagnulo & Arkko Expires June 22, 2005 [Page 14]
Internet-Draft Functional decomposition December 2004
7. Security considerations
The security requirements of each message exchange considered in this
note are detailed in the same section where the message exchange is
analyzed.
Bagnulo & Arkko Expires June 22, 2005 [Page 15]
Internet-Draft Functional decomposition December 2004
8. Contributors
This document was originally produced of a MULTI6 design team
consisting of (in alphabetical order): Jari Arkko, Marcelo Bagnulo
Braun, Iljitsch van Beijnum, Geoff Huston, Erik Nordmark, Margaret
Wasserman, and Jukka Ylitalo.
Bagnulo & Arkko Expires June 22, 2005 [Page 16]
Internet-Draft Functional decomposition December 2004
9. References
9.1 Normative References
[1] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[2] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
9.2 Informative References
[3] Huston, G., "Architectural Approaches to Multi-Homing for IPv6",
draft-huston-multi6-architectures-01 (work in progress), June
2004.
[4] Nordmark, E., "Multihoming without IP Identifiers",
draft-nordmark-multi6-noid-02 (work in progress), July 2004.
[5] Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach",
draft-nordmark-multi6dt-shim-00.txt (work in progress), October
2004.
[6] Arkko, J., "Failure Detection and Locator Selection in Multi6",
draft-multi6dt-failure-detection-00 (work in progress), October
2004.
Authors' Addresses
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
SPAIN
Phone: 34 91 6249500
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es
Jari Arkko
Ericsson
Jorvas 02420
Finland
EMail: jari.arkko@ericsson.com
Bagnulo & Arkko Expires June 22, 2005 [Page 17]
Internet-Draft Functional decomposition December 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bagnulo & Arkko Expires June 22, 2005 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-21 00:28:23 |