Monami6 C. Larsson Internet-Draft H. Levkowetz Expires: December 21, 2006 H. Mahkonen T. Kauppinen Ericsson June 19, 2006 A Filter Rule Mechanism for Multi-access Mobile IPv6 draft-larsson-monami6-filter-rules-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 This document suggests a mechanism that could be used to direct flows from and to multi-homed nodes. A clear distinction is made between policies, filter rules and filters. In order to be able to use filter rules in a multi-access mobility context without excessive overhead, it is advantageous to be able to Larsson, et al. Expires December 21, 2006 [Page 1] Internet-Draft Monami6 Filter Rules June 2006 define match functions and bindings separately, as it is expected that it may be necessary to update the bindings much more often than the match functions. If the binding is expressed in terms of filter rule identifier and care-of address, the bindings must be updated on a handover to a new care-of address, while the match function will not. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . 3 2. Architecture Overview . . . . . . . . . . . . . . . . . . . . 4 2.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Filter rules and Filter . . . . . . . . . . . . . . . . 6 2.3. Updating the peer with binding information . . . . . . . 7 3. Protocol Outline . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Binding Filter Rules to Care-of Addresses . . . . . . . 8 3.2. Sending Binding Update . . . . . . . . . . . . . . . . . 8 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Informative References . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Larsson, et al. Expires December 21, 2006 [Page 2] Internet-Draft Monami6 Filter Rules June 2006 1. Introduction Mobile IPv6 [RFC3775] allows a mobile node to remain reachable while moving around in the IPv6 Internet. The mobile node is identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home network it is also associated with a care-of address, which provides information about its current location. By sending a Binding Update to its home agent the mobile node creates a binding between its home address and care-of address. Mobile IPv6 only allows one care-of address (the primary care-of address) at the time to be associated with each home address. The multiple care-of registration protocol [I-D.ietf-monami6-multiplecoa] extends the Mobile IPv6 protocol with an option allowing multiple care-of addresses to be associated with a single home address. When multiple care-of addresses are associated with one home address, effectively multiple paths are created between the mobile node and the home agent. Multiple paths between two nodes imply that, unless all traffic is sent over all links, there must exist rules which for each packet determine which path should be used to send the packet. These rules apply to all involved nodes, i.e. the mobile node, the home agent and the correspondent node. The purpose of this document is to analyze the problem scope that a mobile node and home agent are faced with when having several possible care-of addresses to chose between for sending data packets. We propose a mechanism, including filter rules, which may be used by monami6, by which a multi-homed node can instruct the home agent and the correspondent nodes about the preferred path to use depending on the type of traffic. The approach taken could also be applicable for other mobility management protocols, e.g. HIP [I-D.ietf-hip-base] and MOBIKE [RFC4555]. 1.1. Terminology In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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]. This document frequently uses the following terms: Larsson, et al. Expires December 21, 2006 [Page 3] Internet-Draft Monami6 Filter Rules June 2006 Policy In the context of Multi-Access for Mobile-IP nodes, Policy is a overall information which govern how packets are forwarded from home agent to mobile node, from mobile node to home agent, and from mobile node to correspondent node. Policy may cover such things as access network preferences, use and operator preferences, security restrictions, and more. Application of policy will in many cases result in definition of filter rules which implement the policy for specific traffic flows. Filter Rule A filter rule is a rule which specifies that traffic with certain characteristics is to be handled in a certain manner. As an example, a filter rule might specify that any traffic with destination port 80 should be sent out through a certain care-of address. A filter rule could be said to be composed of a match expression and a binding. The match expression defines which packets match the filter rule. The binding specifies where to route the packet if it matches the match expression. In order to be able to use filter rules in a multi-access mobility context without excessive overhead, it is advantageous to be able to define match functions and bindings separately, as it is expected that it may be necessary to update the bindings much more often than the match functions. If the binding is expressed in terms of filter rule ID and care-of address, the bindings must be updated on a handover to a new care-of address, while the match function will not. Filter A filter is a collection of filter rules which is associated with a certain decision point in the IP stack, such as the point where a multi-access capable Mobile-IP implementation have to decide through which care-of address a packet should be routed. 2. Architecture Overview When a mobile node has multiple care-of addresses, either assigned to one interface or to different interfaces, the mobile node must have some additional internal information enabling it to make a decision of which care-of address (i.e. network interface) to use for sending Larsson, et al. Expires December 21, 2006 [Page 4] Internet-Draft Monami6 Filter Rules June 2006 the data packet. Additionally, if the mobile node has registered multiple care-of addresses with its home agent or correspondent nodes, as proposed in [I-D.ietf-monami6-multiplecoa], there exist multiple paths between the mobile node and the home agent and correspondent nodes. For the home agent and correspondent nodes to know which path to use for packets destined to mobile node it would need additional internal information enabling it to choose a specific path. The term 'Policy' is often used to refer to the internal rules that would apply to the data packets. In this document we will use the term 'Filter rule' and 'Filter' to refer to the internal rules being applied to each data packet. When looking into the problem scope of setting up and exchanging policies and filters between nodes one realizes that that it is possible and desirable to make a clear separation between the following actions: * Definition and exchange of policies. * Definition and exchange of filter rules. * Binding of filter rule with care-of address. Figure 1 shows the suggested approach. There will be separate means for the exchange of policies and filter rules. This exchange may happen independently of a mobile nodes movement. When a mobile node changes its current point of attachment to the Internet it will send a Binding Update to inform its home agent about its current location. The Binding update will include the binding between the filter rule ID and the care-of address. Initiator Responder +--------------+ +--------------+ | | Exchange of Policies | | | |<------------------------->| | | | | | | | Exchange of Filter rules | | | |<------------------------->| | | | | | | | Mapping of FRID <-> CoA | | | |<------------------------->| | +--------------+ +--------------+ Larsson, et al. Expires December 21, 2006 [Page 5] Internet-Draft Monami6 Filter Rules June 2006 Figure 1: Information exchange between initiator and responder By applying this approach we would achieve a clear separation between the definition and the exchange of policies and filter rules, and the mapping of a filter rule to a care-of address. 2.1. Policy In the context of this document a policy is a high level information which governs how traffic is sent from/to a mobile node. Policies would typically be translated into a set of filter rules (see next section) which would be applied to each data packet sent from/to the mobile node. One could think of policies as describing the preferred actions that should be taken if certain conditions are fulfilled. E.g. a mobile node could have a policy that states that if WLAN is available then this interface is the preferred interface for sending http traffic. If WLAN is not available then the 3G interface is the preferred interface for sending http traffic. The filter rules are expected to be updated only if the policy is updated. A policy could be installed at a node prior to delivery and/or it could be dynamically updated in runtime. Typically a node would have a set of static policies installed while others are dynamically installed when needed. Both the host and the network have interest in how policies are defined and applied. Consequently the exchange of policies could be initiated by either the host or a node in the network. Policies must be available in every node that should do an intelligent filtering of a data packet. In case of a mobile node it would be used for defining which interface to use for outgoing traffic. In the case of a home agent or a correspondent node it would be used for defining which interface at the mobile node to send the traffic to. The specific means used for the exchange of policies is out of the scope of this document. 2.2. Filter rules and Filter Filter rules are generated from (a set of) policies. A filter rule would be realized as a Packet Filter (PF) and assigned a unique filter rule identifier (FRID). The FRID is a way of referencing a specific filter rule and it is used when associating a care-of address with a specific filter rule. Larsson, et al. Expires December 21, 2006 [Page 6] Internet-Draft Monami6 Filter Rules June 2006 A filter rule may only be associated with one care-of address, but a care-of address can be associated with multiple filter rules. Whenever a Policy is changed or an event occurs that causes new filter rules to be generated or existing filer rules to be updated these changes must be applied to outgoing packets. Additionally, peering nodes must be updated with the new filter rules. E.g., if the filter rules are modified in a mobile node it would have to inform the home agent and the correspondent nodes about the new filter rules that apply for packets being sent to it. The reason for defining filter rules, assigning each filter rule a FRID and associating them with a care of address is that we believe that the best way to exchange filter rules between nodes is by using separate means for this, not overloading the Mobile IPv6 protocol with tasks that it was not originally designed for. A more detailed discussion about the reasons for chosen this approach can be found in [I-D.mitsuya-monami6-flow-distribution-policy], section 1. The specific means used for exchanging filter rules is for the working group to decide. Example of protocols that could be used is IKEv2 and UDP, but other protocols may be used as well. 2.3. Updating the peer with binding information As stated in section 3.2 there exist a mapping between filter rules and care-of addresses. Whenever a filter rule is created or an existing filter rule is updated causing a new care-of address to be associated with the filter rule this must be propagated to the affected nodes. In the multiple care-of address registration protocol [I-D.ietf- monami6-multiplecoa] a Binding Unique Identifier (BID) is introduced and uniquely assigned with each care-of address. The previously introduced FRID could be seen as a BID since it is syntactically and semantically handled in the same way. However, in this draft we propose to extend the definition associate the FRID with a unique filter rule. The FRID would in this proposal be used as proposed in [I-D.ietf- monami6-multiplecoa] (replacing the BID) to create a binding between a care-of address and a (set of) filter rule(s). The multiple care-of registration protocol [I-D.ietf-monami6-multiplecoa] discusses how this can be done for Mobile IPv6. However, we see no reasons for why the approach described in this document could not be used for other mobility management protocols, such as HIP [I-D.ietf- hip-base] and MOBIKE [RFC4555]. Larsson, et al. Expires December 21, 2006 [Page 7] Internet-Draft Monami6 Filter Rules June 2006 3. Protocol Outline This specification allows a mobile node to update its home agent and other nodes about preferred network interfaces to be used while connecting to the mobile node. Each filter rule is associated with a FRID. The exact mechanism to achieve this is an internal node implementation and out of scope of this draft. However, the result of processing the policy for the mobile node is a set of filter rules, each of one associated with a FRID. The mobile node will typically be equipped with multiple network interfaces. Whenever a network interface is activated and connected to an access network it will have multiple addresses assigned to the interface. When multiple network interfaces are available simultaneously there must exist a mechanism to associate a filter rule with an available care-of address. The exact mechanism to decide which filter rule to associate with which network interface (and care-of address) is a node internal issue and out of scope for this draft. However, the result of this procedure is an association between a filter rule and a care-of address. 3.1. Binding Filter Rules to Care-of Addresses The current mobile node's internal binding between a filter rule and a care-of address must be propagated to the home agent and the correspondent nodes. In the multiple care-of address registration protocol draft [I-D.ietf-monami6-multiplecoa] a Binding Unique Identifier (BID) is introduced to refer to a path between the mobile node and the home agent. In this draft the FRID can syntactically and semantically be viewed as a BID but in this proposal it is instead used as a reference to a filter rule. 3.2. Sending Binding Update The mobile node would typically have to inform its home agent and correspondent nodes about a change of the care of addresses either when an existing care-of address is changed due to a change of point of attachment to the Internet, or if a new interface becomes available and the mobile node decides to take the interface in operational use. The Binding Update is sent according to [I-D.ietf-monami6- multiplecoa] informing the home agent that a specific filter rule (identified with a FRID) will be associated with the specified Larsson, et al. Expires December 21, 2006 [Page 8] Internet-Draft Monami6 Filter Rules June 2006 care-of address. It is possible to associate multiple filter rules with one care-of address. 4. IANA considerations This document does not require any new number assignments from IANA, and does not define any new numbering spaces to be administered by IANA. RFC-Editor: Please remove this section before publication. 5. Security Considerations The transport used to exchange the flow distribution policy MUST be secured to the same extent as the binding updates, and preferably using the same security association. 6. Informative References [I-D.ietf-hip-base] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-06 (work in progress), June 2006. [I-D.ietf-monami6-multiplecoa] Wakikawa, R., "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-00 (work in progress), June 2006. [I-D.mitsuya-monami6-flow-distribution-policy] Mitsuya, K., "A Schema Fragment for Flow Distribution", draft-mitsuya-monami6-flow-distribution-policy-00 (work in progress), February 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. Larsson, et al. Expires December 21, 2006 [Page 9] Internet-Draft Monami6 Filter Rules June 2006 Authors' Addresses Conny Larsson Ericsson AB Torshamnsgatan 23 Stockholm S-164 80 SWEDEN Phone: +46 8 404 8458 Email: conny.larsson@ericsson.com Henrik Levkowetz Ericsson AB Torsgatan 71 Stockholm S-113 37 SWEDEN Phone: +46 708 32 16 08 Email: henrik@levkowetz.com Heikki Mahkonen Oy L.M. Ericsson Hirsalantie 11 Jorvas FI-02420 Finland Phone: +358 9 299 3213 Email: heikki.mahkonen@ericsson.com Tero Kauppinen Oy L.M. Ericsson Hirsalantie 11 Jorvas FI-02420 Finland Phone: +358 9 299 3057 Email: tero.kauppinen@ericsson.com Larsson, et al. Expires December 21, 2006 [Page 10] Internet-Draft Monami6 Filter Rules 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. Larsson, et al. Expires December 21, 2006 [Page 11]