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]