Mobile IP Working Group N. A. Fikouras INTERNET-DRAFT A. J. Koensgen Expires: July 2002 C. Goerg ComNets, IKOM University of Bremen W. Zirwas M. Lott Siemens AG January 2002 Filters for Mobile IP Bindings (NOMAD) draft-nomad-mobileip-filters-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 document is an individual submission to the IETF. Comments should be directed to the authors. Abstract In Mobile IP, a mobile node that maintains simultaneous bindings will receive at each registered care-of address a duplicate copy of every datagram from every active flow. However, a mobile node with multiple points of attachment may wish to receive different flows at each one. The purpose of this document is to enable mobile nodes to associate a list of filters with a binding during its establishment (registration, binding update). In this manner, a mobile node may select for each flow the most appropriate point of attachment. In order not to violate layer independence, the filtering of individual flows or groups of them is managed through flow description components made available by existing approaches to QoS support. Page 2 Table of Contents 1 Introduction ............................................. 3 2 Terminology .............................................. 4 3 NOMAD Extensions Protocol Overview ....................... 5 3.1 Protocol Description ..................................... 5 3.2 Model of Operation ....................................... 6 4 Associating Filters with Bindings ........................ 9 4.1 Mobile Node Considerations ............................... 9 4.2 Binding Agent Considerations ............................. 9 5 NOMAD Extensions to RFC2002 Registration Messages ........ 10 5.1 Behavior Aggregate Filter Extension (BAF) ................ 11 5.2 Protocol Extension ....................................... 11 5.3 Source Address Extension ................................. 12 5.4 Source Network Extension ................................. 12 5.5 Source Port Extension .................................... 12 5.6 Soruce Port Range Extension .............................. 13 5.7 Routing Optimization Extension for Simultaneous Bindings . 13 5.8 Control Extension ........................................ 14 6 Intellectual Property Considerations ..................... 14 References ................................................... 15 Authors' Addresses ........................................... 16 Page 3 1 Introduction This document extends the Mobile IP [1] protocol by providing the means for mobile nodes with simultaneous bindings to notify Binding Agents (Mobile IP entities that can maintain simultaneous bindings) of an association between filters and specific bindings. As such, traffic intercepted by, or originating from a Binding Agent will be filtered and individual flows will be redirected to the care-of address indicated by the respective binding. This enables mobile nodes to distribute active flows amongst their available points of attachment. Mobility Agents are unable to distinguish between individual flows and therefore redirect all intercepted traffic for a mobile node to the care-of address indicated by its binding. Consequently, as the binding is updated with every hand-off, the total of a mobile node's active flows are redirected to the most recently registered care-of address. Furthermore, if a mobile node requests for simultaneous bindings, it will receive at each registered care-of address a duplicate copy of every active flow. However, a mobile node that maintains multiple access interfaces and hence multiple points of attachment may wish to associate certain flows with specific access interfaces. As these access interfaces vary their care-of address a mobile node should be able to perform a Mobile IP (IP-layer) hand-off for only a subset of its active flows. A functionality similar to the one described earlier can be provided through the routing optimization extension [3] whereby the mobile node is enabled to communicate directly with a correspondent node (CN), bypassing all mobility agents. In that case, it is possible for the mobile node to register a different care-of address with each CN, therefore associating all of a CN's communications with one of its points of attachment. However, with this approach it is not possible to distribute the communications of a given CN between multiple points of attachment. The reason for this is because, in routing optimization, CNs may not maintain multiple bindings for a mobile node. Moreover, CNs, just like mobility agents, are equally unable to distinguish between individual flows in spite of being their origin. Filters for bindings require that a mobile node includes in its registration requests or binding updates a list of filters. Flows that match the conditions listed in the filters are associated with the registered care-of address. In this manner the Binding Agent (CN, Home or Hierarchical Agents) becomes aware of the relationship between certain flows and specific bindings. However, the existence of those filters does not affect in any way the mobile node's choice on the point of attachment to be utilized for the return path. In order to provide simultaneous bindings to CNs with routing optimization support, the 'S' bit is introduced in the binding update message. In order not to violate layer independence, the filtering of flows occurs through components made available by protocols for QoS support. The consideration presented in this document are collectively referred to as the NOMAD Extension. Page 4 2 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 RFC-2119 [2]. This document uses the following terms: Domain A collection of networks sharing a common network administration. Home domain As defined in [5]. Visited domain The domain where the mobile node has one or more points of attachment. Gateway Foreign Agent (GFA) As defined in [5]. Regional Foreign Agent (RFA) As defined in [5]. Home Agent (HA) As defined in [1]. Home Network As defined in [1]. Correspondent Node (CN) As defined in [1]. Mobile Node (MN) As defined in [1]. Mobility Binding As defined in [1]. Binding Agent (BA) Any Mobile IP entity (HA, GFA, RFA, CN) that can maintain Simultaneous mobility bindings. Binding Request Mobile IP signaling (registration request, binding update) with the purpose of establishing or updating a mobility binding. Binding Reply Mobile IP signaling (registration reply, binding acknowledgment) for acknowledging the successful updating or establishment of a mobility binding. Page 5 3 NOMAD Extensions Protocol Overview This section provides an overview of how filters for Mobile IP bindings can be realized. 3.1 Protocol Description Every time that a mobile node acquires a care-of address through one of its points of attachment it is required to issue a registration request or binding update (collectively termed as binding requests) to the respective Binding Agent. A Binding Agent can be any Mobile IP entity that can maintain bindings, like a HA, GFA, RFA even a CN when routing optimization is supported. In any case, the mobile node is required to include in its binding request a list of filters that indicate which flows are associated with the registered care-of address. The rules by which a mobile node decides on the set of filters is considered beyond the scope of this document. A Binding Agent that receives a binding request that includes a list of filters is required to establish a tunnel as per [1]. However, this tunnel is only applicable for flows that match the criteria present in any of the filters associated with the binding. If a Binding Agent receives simultaneous registrations (bindings) it is required to establish different tunnels, each associated with different filters. It is noted that, filters of simultaneous bindings need not be mutually exclusive. In the case of overlapping filters, the Binding Agent is required to duplicate flows that match the overlapping criteria and direct them to the corresponding care-of addresses. A mobile node may issue filters that correspond to flows that do not yet exist. In that case, when such a flow is initiated it will be handled by the Binding Agents as indicated by the filter. A binding without any filters is considered as the default binding. The default binding is used for all flows for which no filters have been defined. In the absence of filter-less bindings, the default binding is considered the one with the longest outstanding lifetime. It is possible for a mobile node to maintain multiple filter-less as well as other bindings at the same time. In that case, all flows for which a matching filter exists will be directed to the corresponding care-of address while the rest will be duplicated and directed to the care-of addresses indicated by all the filter-less bindings. If a specific filter is not accepted by a Binding Agent then it is required to include this filter in its registration reply/binding acknowledgement (termed collectively as binding reply). Otherwise no other indication is required. When returning traffic the mobile node is not bound in any way by the extensions presented as to which point of attachment should be used. Page 6 A filter remains valid for the lifetime of the corresponding binding. When the lifetime of a binding expires then all associated filters are cancelled. In order for a mobile node to modify a filter (add/remove predicates) it is required to issue a new Binding Request for the care-of address associated with the filter, including a new filter entry or the part of the filter that needs to be changed. The filter extensions presented later in this document include special fields for filter management. In order to protect layer independence the structure of filters that may be added to a Binding Request is based on existing filter specification for QoS support. 3.2 Model of Operation The general model of operation is illustrated in figure 1. It shows a mobile node that maintains multiple access interfaces. Each interface provides a point of attachment through a visited domain. The extensions presented do not provide any restriction as to how many points of attachment a mobile node may maintain within a domain. For example, the mobile node in figure 1 has two separate points of attachment in the Mobile IP hierarchy of visited domain A. In addition, the mobile node maintains two more points of attachment through visited domains B and C. The extensions presented operate independently of whether the point of attachment provides a normal or collocated care-of address. In figure 1, the mobile node maintains four communications with correspondent nodes CN1 and CN2. Flows associated with CN1 are denoted with 'a' and 'b' while the respective flows for CN2 are denoted with 'c' and 'd'. When routing optimization is used in conjunction with hierarchical Mobile IP the Binding Agent can be the HA or any of hierarchy Mobility Agents such as the GFA and RFA as well as the CN itself. The level at which filtering may occur is determined by the mobile node depending on the micro/macro mobility character of every hand-off as well as internal rules. In general, the Binding Agent that issues the registration reply or binding acknowledgement (collectively termed as binding reply) is also required to deploy the filters. For communications with CN1, routing optimization has been assumed but the GFA has been selected as the filtering Binding Agent. Communications with CN2 do not assume routing optimization and therefore all flows are first directed to the mobile node's HA. Page 7 In the example presented in figure 1, the mobile node has issued a separate binding request for each care-of address acquired by its points of attachment. Every binding request contained a set of filters that forces the respective Binding Agents to redirect different flows to different care-of addresses. As such, even though the GFA intercepts the total of CN1's traffic destined for the mobile node, separate flows are directed to different points of attachment. The same is observed at the HA, which intercepts incoming traffic from the CN2 and after filtering it redirects them to different locations. To return traffic a mobile node may choose any of the available points of attachment. Page 8 +---------------------+ +-------+ | Visited Domain A | | CN1 | | | +-------+ | | |a a a a a a a +------+ a a a | |b -----------| FA |----- | +------|a-----+ a| | +------+ |a | |b | | | +-------+ | |a | a| | | GFA |------------ b | | | +-------+ babababababa | a| | +------+ |b | | | | --------| FA |----- | | | a| |b b b b +------+b b b b | | | | | | | | | a| |b +---------------------+ | Public | +-----------+ +------+ | Network | | | | MN | +---------------------+ | | | Home | +------+ | Visited Domain B | | | | Network | |d |c | | | | | | | | c c c +------+ c c c c c c c c c c c c c c c c c c c c c | |d --------| FA |----------------------------------------- | | | +------+ | | d d d d d d d d d d |c | |d | | | d ------------------ | | | | | | | | | |d |c | |d | | | d| dcdcdcdcdcdc +------+ | | +---------------------+ | | c ------------| HA | | |d | d| d| | | +------+ | | +---------------------+ +-- |--c|-----+ | | |d | | d| d| | | | d d d d d d d d d d d d d d d d d d | c| +-----------+ -------------------------------------- d| | | c| | Visited Domain C | +-------+ | | | CN2 | +---------------------+ +-------+ Figure 1: A mobile node with multiple points of attachment in different visited domains. Incoming flows are redirected by the respective Binding Agents to a different care-of address. Page 9 4 Associating Filters with Bindings This section gives a detailed description of the steps taken by a mobile node that wishes to associate filters with its bindings. Furthermore, it is presented how a Binding Agent reacts to the receipt of a binding request containing a list of filters. 4.1 Mobile Node Considerations A mobile node that acquires a care-of address within a domain (home or visited) may issue a binding request containing a list of filters. All included filters will be associated with the registered care-of address at the Binding Agent that issues the Binding Reply. A mobile node that can maintain multiple points of attachment may request for simultaneous bindings by setting the 'S' bit on in its Bindings Requests. However, each of the Binding Requests must contain its own list of filters. Consequently, flows that match any of the filters will be received at the corresponding point of attachment. Similarly, flows that match overlapping filters will be received at multiple points of attachment. Finally, flows that do not match any of the declared filters will be received at the point of attachment indicated by the default binding. Should a Binding Agent fail to apply one of the filters or individual predicates of a filter then it is required to include them in the Binding Reply. If routing optimization is supported then in the case of a declined filter a Binding Acknowledgment with the failed filter must be generated independently of whether the 'A' bit was set in the Binding Update or not. 4.2 Binding Agent Considerations Binding Agents that receive a Binding Request containing a list of filters are required to make a record of the filters regardless of whether they must issue a Binding Reply or not. If the Binding Agent is required to issue a Binding Reply then it is also required to apply the filters, else no further action is required. Should the Binding Agent fail to apply any of the filters then the failed filter (or predicate) must be included with the Binding Reply. If authentication of the Binding Request fails then none of the filters must be applied nor is it necessary to copy them in the Binding Reply. When a Binding Agent intercepts a packet for a mobile node for which it maintains simultaneous bindings it is required to identify whether the packet matches any of the filters. If so, the packet is redirected to the care-of address indicated by the respective binding. If no matching filter is found then the packet is redirected to the care-of address indicated by the default binding. Page 10 5 NOMAD Extensions to RFC2002 Registration Messages In this section the new Mobile IP registration extensions required for the support of filters for bindings are specified. Furthermore, the lack of support for simultaneous bindings in CNs with routing optimization requires the introduction of the 'S' bit to binding update messages. In Differentiated Services (DS) [7] the DS header field is defined as a replacement for the IPv4 TOS [6] and IPv6 Traffic Class [8] octets. Six bits of the DS field are used as a codepoint (DSCP) to select the per-hop-behavior that a packet receives at each node. For the purposes of NOMAD the DSCP along with other header fields is used to construct filters that identify a specific flow or groups of them. In NOMAD, seven types of filter extensions are defined. To form a valid rule, at least one of the extensions 1 to 6 must be included. Any type of extensions 1 to 6 must not be included more than once. A data packet matches the rule if it matches all of the extensions 1 to 6 which have been included. The extension 7 is optional. The extension 8 is mandatory. 1. Behavior Aggregate Filter Extension (BAF) Specifies to filter data packets dependent of the content of the DSCP field. 2. Protocol Extension Specifies one or more protocols to be filtered. 3. Source Address Extension Specifies one or more source adresses to be filtered. 4. Source Network Extension Specifies one or more source networks (i.e. a interval of IP addresses) to be filtered. 5. Source Port Extension Specifies one or more source ports to be filtered. 6. Source Port Range Extension Specifies one or more ranges of source ports to be filtered. 7. Routing Optimization Extension for Simultaneous Bindings The Binding Update message is defined in [3]. With this message it is possible for the mobile node to establish a binding with a CN with routing optimization support. However, with every subsequent Binding Update the CN is required to update the binding. In order to enable simultaneous binding support the 'S' bit is introduced in the Binding Update message. It occupies one of previously reserved bits. Page 11 8. Control Extension The Control Extension contains information about where to insert a rule into the rule table and what rule to insert. The filters presented do not in any way alter or affect the DSCP value of intercepted packets. They only enable a Binding Agent to determine for each packet the most appropriate binding when a mobile node maintains a range of them. 5.1 Behavior Aggregate Filters (BAF) Extension 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | DSCP |RSV| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To Be Defined Length (N), where N is the number of DSCP entries DSCP Differentiated Services Codepoint 5.2 Protocol Filter Extension 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To Be Defined Length (N), where N is the number of Protocol fields Protocol Identifies the next level protocol used in the data portion of the internet datagram. The values for various protocols are specified in [4]. Page 12 5.3 Source Address Extension 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 | Source IP Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source IP Address (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To Be Defined Length (4*N), where N is the number of source IP address fields 5.4 Source Network Extension 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 | Source IP Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source IP Address (cont.) | Source IP Address Mask +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source IP Address Mask (cont.)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To Be Defined Length (8*N), where N is the number of pairs of a source IP address and a corresponding source IP address mask entry 5.5 Source Port Extension 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 | Source Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To Be Defined Length (2*N), where N is the number of port entries Page 13 5.6 Source Port Range Extension 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 | Source Port Number Min | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Number Max | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To Be Defined Length (4*N), where N is the number of port range entries Port Number Min Defines the start point of a range of port numbers Port Number Max Defines the end point of a range of source port numbers 5.7 Routing Optimization Extension for Simultaneous Bindings 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 |A|I|M|G|S| Rsv | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- S Simultaneous bindings. If the 'S' bit is set on, the mobile node is requesting that the correspondent node retains its prior mobility bindings. All other fields are defined in [3]. Page 14 5.8 Control Extension 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | ACT | TG |IDX| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ACT Action to be undertaken for this filter TG Target of the filter IDX Filter index number Admissible values for the ACT field are as follows: Value Filter Management 0 Insert at the beginning of existing filters for the registered address 1 append at the end of existing filters for the registered address 2 Delete from an exiting filter 3 Replace entry in an existing filter 4 Flush all filter entries for address Admissible values for the TG field are as follows: Value Filter Target 0 Drop incoming packets without notification 1 Reject incoming packets with notification 2 Accept incoming packets 3 Accept incoming packets but avoid route optimization 4 Masquerade 6 Intellectual Property Considerations This proposal is in full conformity with [9]. Siemens may have patent rights on technology described in this document which employees of Siemens contribute for use in IETF standard discussions. In relation to any IETF standard incorporating any such technology, Siemens hereby agrees to license on fair, reasonable and non-discriminatory terms, based on reciprocity, any patent claims it owns covering such technology, to the extent such technology is essential to comply with such standard. Page 15 References [1] C. Perkins. IP Mobility Support. RFC (Proposed Standard) 2002, IETF, October 1996. [2] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, IETF, March 1997. [3] C. Perkins and D. Johnson. Route Optimization in Mobile IP. (work in progress). draft-ietf-mobileip-optim-11.txt, IETF, September 2001. [4] J. Reynolds and J. Postel. Assigned Numbers. Request for Comments 1700, STD 2, IETF, October 1994. [5] E. Gustafsson, A. Jonsson and C. Perkins. Mobile IP Regional Registration. (work in progress). draft-ietf-mobileip-reg-tunnel-05.txt, IETF, September 2001. [6] Postel, J. Internet Protocol. STD 5, RFC 791, IETF, September 1981. [7] K. Nichols, S. Blake, F. Baker, and D. Black. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. RFC 2474, IETF, December 1998. [8] S. Deering and R. Hinden, Internet Protocol, Version 6 (IPv6) Specification. RFC 2460, IETF, December 1998. [9] S. Brander. The Internet Standards Process -- Revision 3. RFC 2026, IETF, October 1996 Page 16 Authors' Addresses Niko A. Fikouras Department of Communication Networks (ComNets) Center for Information and Communication Technology (ikom) University of Bremen Phone: +49-421-218-3339 D-28219 Bremen, Germany Email: niko@comnets.uni-bremen.de Andreas J. Koensgen Department of Communication Networks (ComNets) Center for Information and Communication Technology (ikom) University of Bremen Phone: +49-421-218-3339 D-28219 Bremen, Germany Email: ajk@comnets.uni-bremen.de Carmelita Goerg Department of Communication Networks (ComNets) Center for Information and Communication Technology (ikom) University of Bremen Phone: +49-421-218-2277 28219, Bremen, Germany Email: cg@comnets.uni-bremen.de Wolfgang Zirwas Siemens AG ICM N MR-ST 8 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49-89-722-34369 Germany Email: wolfgang.zirwas@icn.siemens.de Matthias Lott Siemens AG ICM N MR-ST 8 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49-89-722-28097 Germany Email: matthias.lott@icn.siemens.de Expires: July 2002