Internet DRAFT - draft-pierrel-hip-sima
draft-pierrel-hip-sima
Network Working Group S. Pierrel
Internet-Draft P. Jokela
Expires: December 21, 2006 J. Melen
Ericsson Research NomadicLab
June 19, 2006
Simultaneous Multi-Access extension to the Host Identity Protocol
draft-pierrel-hip-sima-00
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 December 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
A Host Identity Protocol supporting host is able to use multiple
interfaces simultaneously when it implements the Mobility and
Multihoming HIP extensions. The protocol defines currently
simultaneous usage via multiple interfaces only towards different
peer hosts. Simultaneously using multiple interfaces towards one
peer node was not defined due to e.g. potential problems with upper
layer congestion control algorithms. The limitation of that protocol
Pierrel, et al. Expires December 21, 2006 [Page 1]
Internet-Draft HIP-SIMA June 2006
is that it allows only one interface to be used at a time between the
multi-homed host and the peer host. There is no mechanism to
separate the flows between two hosts and to allow them to use
different interfaces independent from each other. This memo presents
a method where two HIP hosts, of which at least one is multi-homed,
can separate different upper layer data flows such as TCP and UDP
between the hosts and allow them to use different interfaces at the
multi-homed host.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 5
2.1. Requirements Terminology . . . . . . . . . . . . . . . . . 5
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3. Multiaccess and Flow Bindings . . . . . . . . . . . . . . . . 6
3.1. Overview of the Message Exchange . . . . . . . . . . . . . 6
3.2. Identifying data flows . . . . . . . . . . . . . . . . . . 7
3.3. Defining Flow Bindings . . . . . . . . . . . . . . . . . . 7
3.4. Using Flow Bindings . . . . . . . . . . . . . . . . . . . 8
3.4.1. Mechanism to be used for sending and receiving
Flow Bindings . . . . . . . . . . . . . . . . . . . . 8
3.4.2. Flow Bindings usage . . . . . . . . . . . . . . . . . 8
3.4.3. Modifying existing Flow Bindings . . . . . . . . . . . 8
3.5. Applications and API . . . . . . . . . . . . . . . . . . . 8
3.6. Sample Flow Binding . . . . . . . . . . . . . . . . . . . 8
4. Flow Binding transfer . . . . . . . . . . . . . . . . . . . . 10
4.1. SIMA_FLOW_BINDING: a new parameter to the UPDATE
message . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Flow id option . . . . . . . . . . . . . . . . . . . . 11
4.1.2. Single TCP flow identifier . . . . . . . . . . . . . . 11
4.1.3. Single UDP flow identifier . . . . . . . . . . . . . . 12
4.1.4. Port ranges for UDP and TCP . . . . . . . . . . . . . 12
4.2. Flow Binding lifetime . . . . . . . . . . . . . . . . . . 13
4.3. SIMA_ACK . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4. SIMA_NACK . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Creating an UPDATE packet with a Flow Binding Option . . . 15
5.2. Receiving an UPDATE Packet with Flow Binding option . . . 15
5.3. Handling Outgoing Data in a Multi-homed Host . . . . . . . 16
5.4. Incoming Data From a Multi-homed Host . . . . . . . . . . 16
5.5. Outgoing Data Towards a Multi-homed Host . . . . . . . . . 16
5.6. Incoming Data at a Multi-homed Host . . . . . . . . . . . 17
6. Implementation issues . . . . . . . . . . . . . . . . . . . . 18
7. Limitations and future work . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
Pierrel, et al. Expires December 21, 2006 [Page 2]
Internet-Draft HIP-SIMA June 2006
10. Normative References . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Pierrel, et al. Expires December 21, 2006 [Page 3]
Internet-Draft HIP-SIMA June 2006
1. Introduction
This memo defines a HIP protocol extension that allows the transfer
of flow binding information between hosts. This allows a multi-homed
host to communicate required flow binding information to the peer
host for separating different flows towards a multi-homed host. In
this specification, UDP and TCP ports are used to separate the flows.
The described procedure allows flexible usage of multiple interfaces
on a multi-homed host between it and a peer HIP node. This
specification does not describe the effect of different access
technology characteristics on the decision making nor it does define
any procedure for such decision making. These issues are out of the
scope of this document.
When a multi-homed host is willing to use simultaneously more than
one interfaces when communicating towards one Correspondent Node
(CN), it must create a set of rules about the usage of the available
network connections. This specification defines a SIMA_FLOW_BINDING
HIP parameter together with TCP and UDP options. By defining new
options, also other information than port numbers can be used for
separating flows at the end-hosts.
Using the described HIP extension, the multi-homed host can
communicate the needed subsection of the rule set to the CN. The CN
uses this information for making decision of the correct ESP Security
Association (and destination IP address) to which the packet is to be
delivered.
This HIP extension utilizes the UPDATE message defined in the Host
Identity Protocol [7] document and relies on the location update
procedure defined in the End-Host Mobility and Multihoming with the
Host Identity Protocol [6] for updating locator information on the
peer host, including reachability verification of new IP addresses.
Pierrel, et al. Expires December 21, 2006 [Page 4]
Internet-Draft HIP-SIMA June 2006
2. Terms and Definitions
2.1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [3].
2.2. Definitions
SIMA: SImultaneous Multi-Access
Flow Binding: The rule that describes the preference of the usage of
different interfaces on a multi-homed host.
Link: A communication facility or physical medium that can sustain
data communications between multiple network nodes, such as an
Ethernet (simple or bridged). A link is the layer immediately
below IP. In a layered network stack model, the Link Layer (Layer
2) is normally below the Network (IP) Layer (Layer 3), and above
the Physical Layer (Layer 1) as defined in RFC3753 [5].
Network interface: The point of attachment to a link as defined in
RFC3753 [5].
Receiver: HIP host whom the packet is addressed to.
Sender: HIP host who sends a HIP packet to a receiver
Pierrel, et al. Expires December 21, 2006 [Page 5]
Internet-Draft HIP-SIMA June 2006
3. Multiaccess and Flow Bindings
The Mobility and Multihoming specification [6] describes how a
multihomed HIP host can use its different interfaces when
communicating with peer HIP nodes. The multi-homed host can use
different interfaces simultaneously, but the limitation is that all
connections between the multi-homed host and one peer HIP host must
use always the same interface. It is possible to change the used
interface, but all connections must be transferred to use the new
interface. The reason for this is that different network conditions
can cause unpredictable problems for upper layers, and such
operations have been intentionally left out of the Mobility and
Multihoming specification.
In some cases it is beneficial to allow different flows to use
different interfaces. A multi-homed HIP host can use this to plan
its connection usage based on access related information, such as
cost, speed, and reliability. It can decide to route the control
connection via a slow-speed but reliable network and, at the same
time, letting the data flow to use a high-speed but maybe more
unreliable channel.
The multihoming specification leaves open the selection of the
LOCATOR amongst several and advanced flow bindings of multiaccess.
In this specification we address this issue and define an extension
to the Host Identity Protocol, allowing the transfer of interface
usage rules between hosts. These rules define how data packets are
delivered between two hosts using different paths. In this document,
rules are based on the TCP and UDP port information.
A new Application Programming Interface (API) is defined for
applications so that they can take advantage of the underlying SIMA
system.
3.1. Overview of the Message Exchange
Multi-homed host HIP CN
UPDATE (SIMA_FLOW_BINDING)
-------------------------->
create database entries
UPDATE (SIMA_ACK)
<-------------------------
The picture above describes a basic UPDATE message exchange when the
multi-homed host is sending the rule set information to the peer
host. The UPDATE message handling is done according to the Host
Identity Protocol [7] specification, and corresponding UPDATE
Pierrel, et al. Expires December 21, 2006 [Page 6]
Internet-Draft HIP-SIMA June 2006
acknowledgement messages are not shown in the picture.
It is assumed in this specification that the location update
procedure is performed prior to the Flow Binding information
exchange. It is, however, possible to optimize the message exchange
by allowing the location update message already to contain Flow
Binding information, but it is currently TBD.
3.2. Identifying data flows
The flow bindings consider the data flow on the transport layer.
Every protocol on the transport layer identifies their flow
independently.
Protocols supported in this memo are TCP [2] and UDP [1]. When using
HIP, the data flows of those protocols are identified using hosts'
HIT, protocol and port numbers. For outgoing packets, the host
verifies the destination HIT of the data packet, used protocol and
port numbers. Based on this information, the outgoing Security
Association is selected, after which the data is encrypted and
delivered to the network using the correct interface.
Support for other protocols requires additional specifications.
3.3. Defining Flow Bindings
The multi-homed host uses Flow Binding rules to define the usage of
the local interfaces. These preferences are stored in a flow binding
database. Each entry of this database gives the network interfaces
priorities in binding a flow identity.
A flow is to be bound to a Security Association and each security
association has source and destination address, thus by selecting the
correct security association one is also selecting the interface to
be used.
The peer host must have information about the currently used flow
bindings rules that are in use in the multi-homed host side. This is
required for selecting correct flow to SPI binding for a specific
flow at the peer host. The multi-homed host can have different rules
for different situations, but it transfers to the peer node only
those rules that currently are active. When the network situation
changes at the multi-homed host, requiring flows to be handed over to
use another connection, the multi-homed host creates an UPDATE packet
including a SIMA_FLOW_BINDING option with the changed flow binding
preferences.
Pierrel, et al. Expires December 21, 2006 [Page 7]
Internet-Draft HIP-SIMA June 2006
3.4. Using Flow Bindings
3.4.1. Mechanism to be used for sending and receiving Flow Bindings
When the HIP multi-homed host is willing to use the flow based
separation in communication, it must communicate the set of rules to
the peer host. It creates an UPDATE message with a new
SIMA_FLOW_BINDING parameter, containing information about the
interfaces and locators that it has.
The UPDATE message processing follows the one described in the Host
Identity Protocol [7] specification.
3.4.2. Flow Bindings usage
When the peer HIP host receives the set of rules that the peer host
is willing to use, it stores this information. The information is
used when the host is sending data towards the multihomed host. Each
packet is matched to the rules to find the correct outgoing Security
Association and put to the IPsec processing.
3.4.3. Modifying existing Flow Bindings
During an ongoing communication, the network environment may change
so that new interfaces become available, old interfaces are removed,
or the rule sets are changed by applications. The HIP host generates
a new UPDATE message with the corresponding rule set parameter (and
so on).
Here we must describe how the actual change in the Flow Binding set
is done. So, either we send a whole set every time replacing the old
set, or we send modifications. If we send modifications, we have to
be careful so that things are kept in sync (what if UPDATE packets
are lost etc.).
3.5. Applications and API
TBD.
3.6. Sample Flow Binding
A multi-homed host having two active interfaces (iface1, iface2) and
one inactive (iface3), has defined a set of rules how flows should
use these interfaces. The multi-homed host has sent the UPDATE
message as defined in the mobility management specification [6]. The
peer host is aware about the two interfaces (1 and 2) and the peer
host has Security Associations towards both of these interfaces.
Pierrel, et al. Expires December 21, 2006 [Page 8]
Internet-Draft HIP-SIMA June 2006
The flow binding rule set at the multi-homed host:
+-----------------------------+------------------------+
| Flow (local to remote port) | Preferred Interface |
+-----------------------------+------------------------+
| TCP any to 143 | iface3, iface1, iface2 |
| | |
| TCP any to 22 | iface2, iface1, iface3 |
+-----------------------------+------------------------+
The multi-homed host creates now an UPDATE packet with two
SIMA_FLOW_BINDING parameters. The first of the parameters contains
the incoming SPI value for the interface iface1, and an TCP flow
identifier option with 143 as the Remote Port Number and zero as the
Local Port Number (zero being expended to the range 0-65535 as
described in Section 4.1.4). The second of the SIMA_FLOW_BINDING
parameters contains the incoming SPI value for the SA on interface
iface2, and TCP 22 as the Remote Port. These presented rules match
for outgoing connections from the multi-homed host.
When the peer host receives this set of flow binding rules, it
creates a table that it uses for selecting the proper Security
Association for outgoing data packets towards the multi-homed host.
+----------------------+--------------------+---------------+
| Destination HIT | Flow (local port) | Outgoing SPI |
+----------------------+--------------------+---------------+
| HIT multi-homed host | TCP any to 143 | SPI to iface1 |
| | | |
| HIT multi-homed host | TCP any to 22 | SPI to iface2 |
+----------------------+--------------------+---------------+
When the interface iface3 becomes active, the flow binding rule
defines that the port 143 must use that new interface. First, the
new locator is communicated to the peer host using the mechanism
described in [6] and a new Security Association is created. The
multi-homed host sends an UPDATE with a new SIMA_FLOW_BINDING
parameter. The SPI value in the parameter is the new incoming SPI
for interface iface3. The protocol, local and remote port number are
TCP, 0 and 143 respectively.
The peer host updates the rule for TCP 143 with the new SPI value.
Pierrel, et al. Expires December 21, 2006 [Page 9]
Internet-Draft HIP-SIMA June 2006
4. Flow Binding transfer
4.1. SIMA_FLOW_BINDING: a new parameter to the UPDATE message
The SIMA_FLOW_BINDING parameter contains the SPI and the
corresponding flow identifier(s) to bind to. An UPDATE message MAY
contain multiple SIMA_FLOW_BINDING parameters and multiple flows
bound to the same SPI MAY be included in the same parameter.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Flow Identifier(s) /
/ +-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 664
Length length in octets excluding Type and Length
SPI SPI value of the SA to bind the flow(s) to
Reserved zero when sent, ignored when received
Flow identifier Flow(s) to bind to the given SPI as described
below
Since the SIMA_FLOW_BINDING parameter is not critical, the receiver
can safely ignore the parameter if it does not support SIMA. The
abscence of ACK to the sender indicates that the peer doesn't support
SIMA.
Pierrel, et al. Expires December 21, 2006 [Page 10]
Internet-Draft HIP-SIMA June 2006
4.1.1. Flow id option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol number| Option_Length | Seq_num |Reserved |R|D|O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol number Protocol number of the flow
Option_Length length in octects of the options, excluding
the option header
Seq_num Sequence Number to identify the Flow Binding
during the update.
Reserved zero when sent, ignored when received
R Range. Used for multiple flows
D Discard. All Flow Bindings existing before
receiving this message MUST be discarded.
O Operation. Ignored if D is set to one.
One if the flow MUST be added to the
Flow Binding system or zero if the flow
MUST be removed from the system
4.1.2. Single TCP flow identifier
The UPDATE mesage already contains HITs of hosts, thus are
disregarded in the flow binding transfer.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol number| Option_Length | Seq_num |Reserved |R|D|O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Port number | Remote Port number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol number 6
Length 4
Reserved zero when sent, ignored when received
R zero
D Discard. See Flow option header description
O Operation. See Flow option header description
Local port number local port number of the flow
Remote port number remote port number of the flow
Pierrel, et al. Expires December 21, 2006 [Page 11]
Internet-Draft HIP-SIMA June 2006
4.1.3. Single UDP flow identifier
The UPDATE mesage already contains HITs of hosts, thus are
disregarded in the Flow Binding transfer.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol number| Option_Length | Seq_num |Reserved |R|D|O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Port number | Remote Port number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol number 17
Option_Length 4
Reserved zero when sent, ignored when received
R zero
D Discard. See Flow option header description
O Operation. See Flow option header description
Local port number local port number of the flow
Remote port number remote port number of the flow
4.1.4. Port ranges for UDP and TCP
If the flag R is set to one, the flows are identified as in Figure 6.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol number| Option_Length | Seq_num |Reserved |R|D|O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Port range begin | Local Port Range end |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Port range begin | Remote Port Range end |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol number 6 (TCP) or 17 (UDP)
Option_Length 8
Reserved zero when sent, ignored when received
R one
D Discard. See Flow option header description
O Operation. See Flow option header description
Local port range begin \ range of the local port numbers
Local port range end /
Remote port range begin \ range of the remote port numbers
Remote port range end /
Pierrel, et al. Expires December 21, 2006 [Page 12]
Internet-Draft HIP-SIMA June 2006
Figure 6: Flow port range
If the flag R is zero, local or remote port number being zero should
be understood as the range 0-65535. This allows to make rules for
flows that are not yet given local or remote port number, thus
defining default rules for certain protocols (See Section 3.6).
4.2. Flow Binding lifetime
The Flow Bindings MUST have the same lifetime as the SA to which they
are bound to and SHOULD be renewed when the SA is updated.
4.3. SIMA_ACK
If the Receiver does not support SIMA, it will ignore the parameter.
In order to inform the sender that the Receiver support SIMA, the
receiver MUST ack the Flow Bindings by sending a SIMA_ACK paramter
including the sequence number of the binding that were accepted.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq_num | ... | Seq_num | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 660
Length length in octets excluding Type and Length
Seq_num sequence numbers of ACKed Flow Bindings,
values corresponding to the ones received in
the SIMA_FLOW_BINDING parameter.
The size of the field Seq_num is the same as on Section 4.1.1
Pierrel, et al. Expires December 21, 2006 [Page 13]
Internet-Draft HIP-SIMA June 2006
4.4. SIMA_NACK
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq_num ... Seq_num | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 662
Length length in octets excluding Type and Length
Seq_num sequence numbers of NACKed Flow Bindings,
values corresponding to the ones received in
the SIMA_FLOW_BINDING parameter.
If the receiver is multi-homed and receives a Flow Binding that is
against its own ruleset, it MAY NACK the proposed Flow Bindings and
propose a new Flow Binding matching better SAs. Note, that this may
lead to a conflicting situation between two multi-homed hosts.
Pierrel, et al. Expires December 21, 2006 [Page 14]
Internet-Draft HIP-SIMA June 2006
5. Packet Processing
5.1. Creating an UPDATE packet with a Flow Binding Option
When a multihomed host creates a new SA with the peer node due to
mobility or other changes in the interface configuration, it needs to
send the Flow Binding Option to the peer host. The peer needs to
know on which interface the multi-homed host is willing to receive
data using certain flow parameters, e.g. port numbers.
It could be possible to allow the CN to select automatically the used
Security Association for different traffic, but due to possibility
that the network environment change at the multi-homed host and it is
not currently sending any data to the peer node, the peer may end up
with sending data using an undesired destination address. Updating
the rules at the peer node when changes occur, minimizes this
possibility
1. The interface usage rules are defined using application input,
user input, or pre-defined rules.
2. The host creates the UPDATE packet with a SIMA_FLOW_BINDING
parameter. The host sets the sequence number counter value to
the Seq_num field and increases its value by one.
3. If the host needs to send more flow bindings, it can set multiple
SIMA_FLOW_BINDING parameters in the UPDATE message; step 2 is
repeated as many times as needed.
4. Send the packet to the peer host.
5.2. Receiving an UPDATE Packet with Flow Binding option
When a peer host receives an UPDATE packet containing one or more
Flow Binding parameters, it creates a local rule set for the peer
multihomed host.
1. If the incoming UPDATE packet contains a SIMA_FLOW_BINDING
parameter the host verifies that it has all the required
information related to the Security Association referenced using
the SPI value in the SIMA_FLOW_BINDING parameter. (TBD: In
optimized version, it is possible that the UPDATE packet contains
the LOCATOR and ESP_INFO parameters as defined in [6])
2. If the SIMA_FLOW_BINDING parameter was not correctly formed, the
host creates a SIMA_NACK parameter, inserts the sequence
number(s) of the failed SIMA_FLOW_BINDING parameters in the
SIMA_NACK parameter, and sends it to the peer in an UPDATE
Pierrel, et al. Expires December 21, 2006 [Page 15]
Internet-Draft HIP-SIMA June 2006
message. TBD: Delete or maintain existing rules.
3. If the SIMA_FLOW_BINDING parameter was a proper one, the host
checks if a binding for this flow already exists in its table.
If a binding is already present, it MUST be replaced by the new
one, otherwise the host creates a local rule set, containing the
information that was included in the SIMA_FLOW_BINDING parameter;
the SPI value of the outgoing Security Association and port
number(s).
4. The host creates an UPDATE packet with a SIMA_ACK parameter
including the sequence number(s) of each of the SIMA_FLOW_BINDING
parameters that were received in the UPDATE message, and were
correctly formed, and sends it to the multi-homed host as a
response.
5.3. Handling Outgoing Data in a Multi-homed Host
A multihomed host maintains the information table that contains
information about flows towards a peer HIP host.
1. The outgoing data packet arrives at the IPsec handling
2. The host makes a lookup from the table, giving the correct
outgoing interface for that data packet (i.e. the Security
Association)
3. Data packet is handed over to the IPsec handling, and the packet
is handled as defined in the Base and ESP drafts.
5.4. Incoming Data From a Multi-homed Host
When a data packet arrives from a multihomed host, it is an ESP
protected data packet. The data packet is handled at the host like
any other data packet arriving at a HIP host, as specified in [8].
Even if the host sees that the data is coming using a different path
that is specified in the latest received SIMA_FLOW_BINDING, it MUST
NOT change the local set of rules based on that. It MUST continue to
send data according to the received SIMA_FLOW_BINDING.
5.5. Outgoing Data Towards a Multi-homed Host
When the CN is sending data to the multi-homed host, it must look
from the stored rule set the correct Security Association based on
the information in the data packet. In this document this
information is the used TCP or UDP port numbering.
Pierrel, et al. Expires December 21, 2006 [Page 16]
Internet-Draft HIP-SIMA June 2006
Once the host knows the correct outgoing Security Association, the
data packet is handed to the IPsec ESP packet handling, which handles
the packet as specified in [8].
5.6. Incoming Data at a Multi-homed Host
Incoming ESP data is handled as specified in [8] The multi-homed host
MAY verify that the incoming packet came using the correct SA. If it
did not, there may be some problems with the rule information at the
peer host. The multi-homed host MAY send a new UPDATE packet with a
SIMA_FLOW_BINDING parameter. This is, however, an implementation
issue.
Pierrel, et al. Expires December 21, 2006 [Page 17]
Internet-Draft HIP-SIMA June 2006
6. Implementation issues
Pierrel, et al. Expires December 21, 2006 [Page 18]
Internet-Draft HIP-SIMA June 2006
7. Limitations and future work
If both hosts are multi-homed, there may be conflicts in the flow
binding rules. The behaviour of a host in this kind of situation has
to be defined.
Pierrel, et al. Expires December 21, 2006 [Page 19]
Internet-Draft HIP-SIMA June 2006
8. Security Considerations
TBD.
Pierrel, et al. Expires December 21, 2006 [Page 20]
Internet-Draft HIP-SIMA June 2006
9. IANA Considerations
In this specification, a new HIP parameter is introduced. A new
parameter type number is required for the parameter.
+---------------------+-------------+
| New parameter | Type number |
+---------------------+-------------+
| SIMA_ACK | 660 |
| | |
| SIMA_NACK | 662 |
| | |
| SIMA_FLOW_BINDING | 664 |
+---------------------+-------------+
10. Normative References
[1] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
[5] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[6] Nikander, P., "End-Host Mobility and Multihoming with the Host
Identity Protocol", draft-ietf-hip-mm-03 (work in progress),
March 2006.
[7] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-05
(work in progress), March 2006.
[8] Jokela, P., "Using ESP transport format with HIP",
draft-ietf-hip-esp-02 (work in progress), March 2006.
Pierrel, et al. Expires December 21, 2006 [Page 21]
Internet-Draft HIP-SIMA June 2006
Authors' Addresses
Sebastien Pierrel
Ericsson Research NomadicLab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1
Email: sebastien.pierrel@nomadiclab.com
Petri Jokela
Ericsson Research NomadicLab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1
Email: petri.jokela@nomadiclab.com
Jan M. Melen
Ericsson Research NomadicLab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1
Email: jan.melen@nomadiclab.com
Pierrel, et al. Expires December 21, 2006 [Page 22]
Internet-Draft HIP-SIMA June 2006
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 (2006). 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.
Pierrel, et al. Expires December 21, 2006 [Page 23]
