Monami6 C. Larsson Internet-Draft H. Levkowetz Intended status: Standards Track H. Mahkonen Expires: September 6, 2007 T. Kauppinen Ericsson March 5, 2007 A Filter Rule Mechanism for Multi-access Mobile IPv6 draft-larsson-monami6-filter-rules-02 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 September 6, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This draft introduces filter rules as a means for a multi-homed node to perform per flow interface selection. Per flow interface selection is typically needed when there exist multiple network interfaces, each with different network characteristics, and an application has specific performance requirements for a data flow that makes one network interface more suitable than another. The use Larsson, et al. Expires September 6, 2007 [Page 1] Internet-Draft Monami6 Filter Rules March 2007 of OpenBSD Packet Filter (PF) syntax is proposed to describe the filter rules. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 4 2. Architecture Overview . . . . . . . . . . . . . . . . . . . . 6 3. Packet Filter and Bindings . . . . . . . . . . . . . . . . . . 8 3.1. Conceptual Model . . . . . . . . . . . . . . . . . . . . 8 3.2. Packet Filter . . . . . . . . . . . . . . . . . . . . . 9 3.3. Changes to the PF Filter Rule . . . . . . . . . . . . . 9 3.4. How to generate a FIID . . . . . . . . . . . . . . . . . 10 3.5. Relation between FIID, BID and IP Address . . . . . . . 11 3.6. Storing Filter Rules . . . . . . . . . . . . . . . . . . 12 3.7. Sending Filter Rule updates to the Filtering Peer . . . 12 4. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 12 4.1. Packet Format . . . . . . . . . . . . . . . . . . . . . 13 4.2. Protocol Security . . . . . . . . . . . . . . . . . . . 14 5. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 14 5.1. When to send a Packet Filter to a Filtering Peer . . . . 15 5.2. Packet Filter Content . . . . . . . . . . . . . . . . . 15 5.3. Sending Packet Filter Protocol Messages . . . . . . . . 16 5.4. Receiving Packet Filter Protocol Messages . . . . . . . 17 6. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 18 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 19 Appendix A. Usage Scenarios . . . . . . . . . . . . . . . . . . . 20 A.1. New Interface Available . . . . . . . . . . . . . . . . 20 A.2. New Filter Rule using existing Transmission Requirement . . . . . . . . . . . . . . . . . . . . . . 20 A.3. New Filter Rule with new Transmission Requirement . . . 21 A.4. Interface Out of Range . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 24 Larsson, et al. Expires September 6, 2007 [Page 2] Internet-Draft Monami6 Filter Rules March 2007 1. Introduction When a node is equipped with multiple network interfaces or has multiple addresses assigned to one network interface the node is said to be multi-homed. When a multi-homed node establishes a session with a peer there exist several potential communication paths between the nodes. Multiple communication paths between two nodes imply that unless all traffic is sent over all links, there must exist rules in the multi-homed node that for each packet determine which network interface should be used to send the packet. This draft introduces filter rules as a mean for a multi-homed node to perform per flow interface selection. Per flow interface selection is typically needed when there exist multiple network interfaces, each with different network characteristics, and an application has specific performance requirements for a data flow that makes one network interface more suitable than another. The use of OpenBSD Packet Filter [PF] syntax is proposed to describe the filtering rules used for per flow interface selection. The mechanism described in this document will be used by the multi-homed node to communicate preferred communication paths for IP data flows to its filtering peers. 1.1. Applicability The protocol proposed in this draft could be applied to either a multi-homed stationary or mobile node. However, the primary usage for the filter rules, and the focus of this draft, is how to use filter rules for mobile nodes. The proposed mechanism is agnostic with respect to the particular mobility management mechanism used, and could therefor be used for any mobility management protocols, e.g., Mobile IPv4 [RFC3344], HIP [I-D.ietf-hip-base] and MOBIKE [RFC4555]. It is also IP version agnostic and works equally well for IPv4 and IPv6. This draft draws examples on how to use filter rules from Mobile IPv6 [RFC3775]. The specific details of how the filter rule mechanism could be used for Mobile IPv6 is further detailed in the multiple care-of registration protocol [I-D.ietf-monami6-multiplecoa] together with [I-D.draft-kauppinen-monami6-binding-filter-rule]. Other mobility management protocols would need to write separate documents to outline how the filter rules are used with that specific mobility management protocol. The primary use of flow filtering rules, as described in this document, is to specify to a peer node the separate communication Larsson, et al. Expires September 6, 2007 [Page 3] Internet-Draft Monami6 Filter Rules March 2007 paths to be used for multiple flows which pass through or originate at the peer (such as for instance the HA in a Mobile-IP context) where the different flows have different requirements for bandwidth, latency, and QoS (quality of service). We will call the node which applies filtering to select the appropriate path for IP packets the 'Filtering Peer'. Another example where using flow filtering rules may be useful is between a moving multi-homed HIP-enabled node, when it has many sessions with different QoS requirements towards the same server. The name 'Filtering Peer' would refer to the server in this context. To identify a mobile node some kind of identity is used. One example of an identity would be the home address in Mobile IPv6 [RFC3775] and the Host Identity Tag (HIT) in HIP [I-D.ietf-hip-base]. Let us use the expression 'Identity Tag' as a name for this node identity. Additionally, the multi-homed node would have local interface addresses associated with each network interface. The binding between the identity tag and the local interface addresses is handled by mechanisms specific to each mobility management protocol (e.g. Mobile IPv6, Mobile IPv4, HIP). 1.2. 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: Policy In the context of multi-access for mobile nodes, Policy is overall information which express preferences and constraints on how packets should be forwarded from the mobile node to the intermediate node and the reverse path and from the mobile node to the destination node and the reverse path. Policy may cover such things as access network preferences, user 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 Larsson, et al. Expires September 6, 2007 [Page 4] Internet-Draft Monami6 Filter Rules March 2007 any TCP traffic with destination port 80 should be sent out through a certain interface. A filter rule can be a match expression and a virtual interface identifier. The match expression defines which packets match the filter rule. The virtual interface identifier specifies the access at a specific point in time, which should be used for the matching packets. 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. Filter Interface Identifier (FIID) A Filter Interface Identifier (FIID) identifies a virtual interface which is a possible exit point from a filter rule. A FIID is constructed by concatenating a name and a 16-bit unsigned integer value. The FIID is created by the mobile node and its uniqueness is guaranteed by associating it with the mobile node's identity tag. This procedure will ensure that two FIIDs sent to a filtering peer of the mobile node will not collide. Filtering Peer A filtering peer could be any node in the Internet that the mobile node decides to exchange filter rules with. In case of Mobile IPv6 the filtering peer is the intermediate node, i.e. the home agent, and it may also be the correspondent node. Binding A binding is generally expressed in terms of a relation between a FIID and a local address. In the specific case of Mobile IPv6 the binding is defined as the relation between the FIID, BID (as defined in [I-D.ietf-monami6-multiplecoa]) and the current care-of address. In the context of multi-access for mobile nodes, it is advantageous to define match functions and bindings separately to avoid excessive overhead, as it is expected that it may be necessary to update the bindings much more often than the match functions. Bindings can be updated on a handover to a new local address, while the match function does not need to change. Larsson, et al. Expires September 6, 2007 [Page 5] Internet-Draft Monami6 Filter Rules March 2007 Identity Tag The identity tag is the identity at which the mobile node is addressable. One example of an identity tag would be the home address in Mobile IPv6 [RFC3775] and the Host Identity Tag (HIT) in HIP [I-D.ietf-hip-base]. 2. Architecture Overview The term policy (or policies), in the context of multi-access for mobile nodes, refers to the overall settings and preferences that govern the desired path selection between mobile node and destination nodes. The policies would typically include things such as the user's and operator's preferences regarding access network technologies based on certain characteristics, such as delay, bit error rate, cost of usage, reliability, security, available bandwidth, etc. Both the mobile node and the network side have interest in how policies are defined and applied. Consequently the policy exchange could be initiated by either the mobile node or the network side. The specific means used for the exchange of policies is out of the scope of this document. The filter rules, in the context of multi-access for mobile nodes, consists of a match expression and the interface to use when a packet matches the match expression. This document suggests using syntax from PF ('Packet Filter') [PF], which is OpenBSD's system for filtering TCP/IP traffic, to describe the match expression. Example: Here is a filter rule which filters out http traffic to any destination node and sends it to the virtual interface "fiid1": #HTTP traffic pass out on fiid1 proto tcp to any port 80 A filtering peer would typically be a node in the Internet that the mobile node decides to exchange filter rules with. In case of Mobile IPv6 the filtering peer is normally the intermediate node, i.e. the home agent, but the concept may be applied to and by the correspondent node too. When a packet matches a filter rule, the result is to send it out the specified interface; but this interface is not necessarily a physical interface, it can also be a virtual interface. Larsson, et al. Expires September 6, 2007 [Page 6] Internet-Draft Monami6 Filter Rules March 2007 In the context of this document, virtual interfaces are used in the filter rules, and each virtual interface corresponds to an virtual interface identifier which can be associated with a BID (Binding Unique Identifier) as specified in [I-D.ietf-monami6-multiplecoa]. The virtual interface identifier we name a "Filter Interface IDentifier" (FIID). When a FIID has been associated with a BID, and the BID is associated with a current CoA (Care-of Address), and the CoA is bound to a physical interface, we have a complete specification of which physical interface should be used to transmit a specific type of package. Figure 1 illustrates the actual separation for sending policies, filter rules and binding information. Initiator Responder +-------------+ +-------------+ | | Exchange of Policies | | | |<----------------------------->| | | | | | | | Exchange of Filter rules | | | |<----------------------------->| | | | | | | | Binding FIID <-> IP Address | | | |<----------------------------->| | +-------------+ +-------------+ Figure 1: Architecture overview The proposed architecture of separating the exchange of policies, filter rules and binding information is motivated by the fact that: * The timing of events, which causes changes to the filter rules, does not necessarily corresponds to a handover event and vice versa. * The filter rule exchange protocol can be used with any mobility management protocol, e.g., MIPv6 [RFC3775], MIPv4 [RFC3344], HIP [I-D.ietf-hip-base] and MOBIKE [RFC4555]. * The filter rule exchange protocol is IP version agnostic and works equally well for IPv4 and IPv6. Larsson, et al. Expires September 6, 2007 [Page 7] Internet-Draft Monami6 Filter Rules March 2007 3. Packet Filter and Bindings 3.1. Conceptual Model Figure 2 is a conceptual model of how filter rules and bindings may be generated. The Filter and Binding Generator MAY be implemented in any manner consistent with the external behavior described in this document. +-------------+ Policies ---------> | | | | Events -----------> | | | Filter & | ---> Filter Rules User/Operator ----> | Binding | preferences | Generator | ---> Bindings | | Access Network --> | | Characteristics | | +-------------+ Figure 2: Conceptual model of how filter rules and bindings are generated. In the context of this document a policy (or policies) is a high level information which governs how traffic is sent from/to a 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. 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. Events could be anything that impact the current view of how available resources should be used. For instance when a new access network becomes available this may cause new bindings to be created for the existing set of filter rules. Events could also utilize the current view to create filter rules and bindings. An example of this would be when an application opens a socket, which would typically generate new filter rules and bindings. Larsson, et al. Expires September 6, 2007 [Page 8] Internet-Draft Monami6 Filter Rules March 2007 Preferences would be the user's and operator's way of impacting how different access technologies are used. One way of controlling this could be by the user's subscription. Subscriptions could be in the range of "operator decide everything" to "user decide everything". Each access network has certain characteristics, such as loss rate, jitter, latency, bandwidth, QoS support, power consumptions etc., which impact the choice of access technology for a service. Some access characteristics are static while other are dynamic and could be viewed as events. Policy, events, preferences and access network characteristics are input to the Filter and Binding Generator (or shorter just Filter Generator). The Filter Generator could be seen as an which generates filter rules and bindings. The specification of the application is outside the scope of this document. The filter rules consists of a match expression and the interface to use when a packet matches the match expression. This document suggests using syntax from PF ('Packet Filter') [PF] to describe the match expression. The interface in the filter rule is not necessarily a physical interface but can also be a virtual interface. This document uses virtual interfaces, which we name FIID, in the filter rules. The association between a FIID and the actual IP address is called a Binding. The Filter Generator is responsible for the creation of bindings. 3.2. Packet Filter PF ('Packet Filter') [PF] is OpenBSD's system for filtering TCP/IP traffic. Packet filters are widely used in the Internet and the OpenBSD PF specification exist as open source and has been used for deployment of packet filter implementations on several different platforms. The OpenBSD specification includes a rich set of functionality and offers great flexibility in the way packet filters are created. By using OpenBSD's PF syntax to define filter rules, all features already defined by OpenBSD can be utilized when defining filter rules for handling of simultaneous multi-access. 3.3. Changes to the PF Filter Rule The Packet Filter syntax includes the 'interface' parameter used for identification of the interface that the IP data packet is being transmitted over. The interface name is specified as the name of the Larsson, et al. Expires September 6, 2007 [Page 9] Internet-Draft Monami6 Filter Rules March 2007 interface appended with an integer number, for instance 'fxp1'. By using virtual interfaces in the filter rule, a dynamic binding between the interface in the filter rule and the actual physical interface may be achieved. The Filter Interface Identifier (FIID) identifies a virtual interface, which is the exit point from a filter rule, and is in turn associated with a local physical interface and IP address, such as a MIP care-of address. The FIID follows the same syntax as the 'interface' parameter in the filter rule syntax, i.e., the interface name consists of the name of the interface appended with a 16-bit unsigned integer number. Accordingly, the proposed FIID syntax is as follows: fiid# where "fiid" is the name of the virtual interface and '#' is an integer number. The integer number is an unsigned integer generated by the mobile node. It MUST be unique within the mobile node and its uniqueness is preserved at the Filter Peer by being tied to the identity tag of the mobile node. Below is an example of how the use of FIID would change a filter rule used for capturing outgoing HTTP traffic: #Filter rule using a physical interface pass out on fxp1 proto tcp to any port 80 #Filter rule using a virtual interface pass out on fiid1 proto tcp to any port 80 3.4. How to generate a FIID How the Filter Generator generates the "fiid#' is outside the scope of this document. For example, one possible way of doing it would be for the Filter Generator to assign a unique fiid number for all traffic requesting the same (or similar) type of service (e.g., bandwidth, bit error rate, latency, etc.). If the access conditions changes, i.e. the Filter Generator receives new input data, new bindings would be generated which could change the physical interface that an existing fiid number is associated with. The FIID is created by the mobile node and its uniqueness is guaranteed by associating it with the mobile node's identity tag. Since the FIID is constructed by concatenating the 'fiid' with a 16- bit unsigned integer value there is an upper limit to how many FIIDs that can be generated. However, in practice this would most likely not cause any problems. Depending on how the Filter Generator Larsson, et al. Expires September 6, 2007 [Page 10] Internet-Draft Monami6 Filter Rules March 2007 decides to assign fiid numbers the actual number could be quite low (in the order of 10 or even less). 3.5. Relation between FIID, BID and IP Address This section describes how this draft works together with Mobile IPv6 and the extensions proposed by [I-D.ietf-monami6-multiplecoa] and [I-D.draft-kauppinen-monami6-binding-filter-rule]. The Filter Generator creates filter rules with the associated FIID and the binding between the FIID, BID and care-of address as illustrated below. Filter Rule: fiid -----> BID -----> CoA Once the filter rules and bindings have been created they must be sent to the filtering peer. The filter rules with associated fiid numbers are sent as described in this draft. The binding information between the FIID, BID and care-of address are sent according to [I-D.draft-kauppinen-monami6-binding-filter-rule] and [I-D.ietf-monami6-multiplecoa] One thing that may seem a bit strange is the need for both a FIID and and a BID. The reason for introducing the FIID instead of re-using the BID in the filter rule is that updates to the filter rules are independent of the bindings between a FIID and a BID. For instance, if there exist a set of filter rules and an event occurs in the mobile node that causes a new filter rule to be created this filter rule could specify that output will go to an existing FIID number. This FIID number would then already have a binding with a BID. As a result of creating this new filter rule the modified filter rule set must be sent to the filtering peer, but the binding information does not need to be updated. Another example is when a physical interface is either added or removed. In this case the filter rules and the associated FIIDs are not updated. However, the binding between the FIIDs and the BID may need to be updated. If other mobility management protocols than Mobile IPv6 is preferred, e.g., HIP, a specific document would have to be written detailing how the FIID is bound to the specific mechanisms used in the mobility protocol to achieve simultaneous multi-access. Larsson, et al. Expires September 6, 2007 [Page 11] Internet-Draft Monami6 Filter Rules March 2007 3.6. Storing Filter Rules All filter rules needed by the mobile node to handle simultaneous multi-access are stored as ASCII text. The collection of all filter rules constitute a Packet Filter specification. There is one filter specification generated for the mobile node and one filter specification generated for each filtering peer (e.g. in case of Mobile IPv6 it would be separate files for the home agent and the correspondent node(s)). The content of the filter specification for the filtering peer will often be a "mirrored" version of the file used by the mobile node. 3.7. Sending Filter Rule updates to the Filtering Peer Each time a new filter rule is created, due to some event in the mobile node, the filtering peers MUST be updated. Section 4 outlines a filter rule transfer mechanism based on on the User Datagram Protocol (UDP). The UDP protocol is used to carry plain ASCII text Packet Filter rules with some meta information. The proposal is to send over the entire file when a filter rule is updated. It is assumed that the PF-file is limited in size and that the required update frequency is low. If these assumptions do not hold it would be possible to send only the modified parts of the file to the filtering peers. 4. Protocol Definition This specification defines the protocol used for sending filter rules between the mobile node and its filtering peers. The filter rules are defined using the PF format, as defined in [PF]. The filter rules are stored in an ASCII file and sent to the filtering peer as payload to the User Datagram Protocol (UDP), as defined in [RFC0768]. The motivation for using the UDP protocol is that the application responsible for mapping of the fiid# to the actual physical network interface normally resides in user space. Another reason for using the UDP is that it's an IP version independent protocol. Although this draft is targeting simultaneous multi-access for IPv6 mobility management protocols there is no technical reason for limiting the transfer of filter rules to a specific IP version. Larsson, et al. Expires September 6, 2007 [Page 12] Internet-Draft Monami6 Filter Rules March 2007 4.1. Packet Format Packet format (including UDP header) for sending filter rules is illustrated below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Status | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Packet Format The UDP Fields are as specified in the UDP specification [RFC0768] Filter specification fields: Option Type 8-bit unsigned integer. Indicates the packet content type (and implicitly, format). 0 Protocol version number 1 Packet Filter Update 2 Packet Filter Acknowledgement Option Length 16-bit unsigned integer. Indicates length in octets of the Payload field. Does not include the Option Type, Reserved and Length fields. Status 8-bit unsigned integer. For response messages, this indicates the disposition of the Packet Filter Update. For request messages, this field can be used for other purposes. Values of the Status field less than 128 indicate that the Packet Filter Update was accepted by the receiving node. Values greater than or equal to 128 indicate that the Packet Filter Update was rejected by the Larsson, et al. Expires September 6, 2007 [Page 13] Internet-Draft Monami6 Filter Rules March 2007 receiving node. The following Status values are currently defined: 0 Packet Filter Update accepted 128 Rejected, reason unspecified 129 Administratively prohibited 130 Packet Filter included syntax error 131 Mobile node not allowed to update Packet Filter PF Payload ASCII text containing filter rules. The syntax is described in [PF]. 4.2. Protocol Security The filter rule exchange mechanism MUST be secured to prevent traffic redirection, DoS, or other possible attacks. To prevent possible attacks from malicious hosts the filter rule exchange mechanism is secured with Datagram Transport Layer Security (DTLS) [RFC4347]. The DTLS protocol provides authentication, confidentiality, and message integrity for datagram protocols. The DTLS protocol has been designed to work with client and server applications. According to the DTLS specification [RFC4347], the host that sends filter rule updates is defined as a client and the host that receives filter updates, i.e. the filtering peer, is defined as a server. If the host needs to both send and receive filter rule updates, it MUST implement both the client and the server side of the DTLS protocol. It should be noted that the usage of DTLS is not mandatory. The underlying protocol, for example HIP [I-D.ietf-hip-base], MAY also choose not use DTLS if the protocol itself provides sufficient security for filter rule exchange. 5. Protocol Operations This section describes when and how filter rules are sent from the mobile node to the filtering peers. Larsson, et al. Expires September 6, 2007 [Page 14] Internet-Draft Monami6 Filter Rules March 2007 5.1. When to send a Packet Filter to a Filtering Peer There are several events that may trigger the creation of a new filter rule. For example when an application requests to open a socket the Filter Generator application would create a new filter rule with an associated FIID number. Additionally, if no binding between the FIID number, BID and CoA already exist, such a binding is created. When a new filter rule has been created this information MUST be sent to the filtering peers to make sure that these nodes knows which destination address to use if there exist multiple local addresses associated with the mobile node's identity tag. The timing of events that causes changes to the filter rules and the transmission of new filter rules to the filtering peers does not necessarily corresponds to a handover event and vice versa. As an example; let us assume that a mobile node has both a WLAN and a 3G interface activated and uses Mobile IPv6 with support for multiple simultaneous home registrations according to [I-D.ietf-monami6-multiplecoa]: * When an event occurs that causes a new filter to be created the new filter rule must be sent to to the filtering peer. If binding information must be sent or not depends on whether existing bindings are sufficient for the new filter rule or if new bindings have been created. If new bindings have been created then updated binding information must be sent to the filtering peer. * In case of changes to the connectivity, e.g. an existing interface disappears or a new interface becomes active this will not cause any modifications to existing filter rules. However, it may impact which interface to send traffic to for certain filter rules, i.e. the bindings have to be updated for the filtering peers. * A handover event will require an update of a binding but it will not require any updates of the filter rules. 5.2. Packet Filter Content When sending the Packet Filter specification to the filtering peers there are two options. Either the entire file or a delta could be sent. In the case when a delta is sent only the filter rules that have been created or deleted since the last update needs to be sent. This specification suggests that the entire Packet Filter file is sent each time an update is required. By sending the entire Packet Larsson, et al. Expires September 6, 2007 [Page 15] Internet-Draft Monami6 Filter Rules March 2007 Filter file to the filtering peers there is no need to specify specific protocol behavior for how to add, modify and refresh filter rules. The approach taken in this specification could be further optimized in later revisions if needed. The suggested proposal would be simple but in case of frequent filter updates it would also generate extra traffic. At this stage it is not assumed that sending frequent updates of the packet filter would be needed. However, if this assumptions turns out to be wrong there is always the opportunity to optimize the Packet Filter updates. This optimization could consist of sending the delta in relation to a previous Packet Filter update. This optimization would lead to a more complex protocol, with state and synchronization requirements, but would on the other hand generate less traffic. 5.3. Sending Packet Filter Protocol Messages There MAY be multiple options present in one packet filter protocol message. If several options are present, each option will indicate its length in the 'Option Length' field. The total length of the packet is indicated in the UDP 'Length' field. The 'Protocol version number' ('Option Type' set to '0') is optional information and only needed in future revisions of this protocol. To add a new or update an existing Packet Filter specification at a filtering peer the multi-homed node sets the Option Type to 1 (Packet Filter Update), the Status field is cleared and the Payload field includes the entire Packet Filter specification. The Option Length field is set to the actual length (in octets) of the PF payload field including the Option Type and Option Length fields. To remove an existing Packet Filter at a filtering peer the multi- homed node sets the Option Type to 1 (Packet Filter Update), the Status field is cleared and the Payload field is empty. The Option Length is set to four. 5.3.1. Retransmission If the multi-homed node fails to receive a valid matching response within the selected initial retransmission interval (INITIAL_PFU_TIMER), the multi-homed node SHOULD retransmit the message until a response is received. The retransmissions by the multi-homed node MUST use an exponential back-off process in which the timeout period is doubled upon each retransmission, until either the node receives a response or the Larsson, et al. Expires September 6, 2007 [Page 16] Internet-Draft Monami6 Filter Rules March 2007 timeout period reaches the value MAX_PFUACK_TIMEOUT. The multi-homed node MAY continue to send these messages at this slower rate indefinitely. If the status code indicates that a 'Packet Filter Update' was rejected it may be possible to resend the 'Packet Filter Update' after appropriate modifications of the specification. The decision on whether a Packet Filter should be modified and resent or if no further actions are taken is a node internal issue and not specified in this draft. 5.3.2. Filtering Peer node types Depending on the filtering peer node type either the entire Packet Filter specification or relevant parts of the specification is sent to the node. An example is Mobile IPv6 where the Home Agent needs the full set of filter rules even though route optimization is used between the mobile node and some or all of its Correspondent Nodes. The reason for sending the entire set of filter rules to the home agent is that the return routability procedure may fail and then the traffic would by default be routed through the Home Agent. The Correspondent Node would not require all filter rules from the mobile node. Instead, the relevant filter rules which apply to the specific Correspondent Node, would be enough. As long as a mobile node only has traffic with the same bandwidth, latency and QoS requirements, there is no need for filters at the Correspondent Node at all. 5.4. Receiving Packet Filter Protocol Messages Upon receiving a packet carrying a 'Packet Filter Update' the packet MUST be validated according to the following tests: If the 'Length' field is equal 12 then the any existing filter specifications for the mobile node MUST be removed. When no filter rule specifications are available normal processing of the packets will be performed, i.e. there will be no support for simultaneous multi-access * If the 'Option Length' field is greater than 4 then the content of the 'PF Payload' field is added as Packet Filter information for the multi-homed node. * If the 'Length' field is equal 4 then the any existing filter specifications for the mobile node MUST be removed. When no filter rule specifications are available normal processing of the packets will be performed, i.e. there will be no support for Larsson, et al. Expires September 6, 2007 [Page 17] Internet-Draft Monami6 Filter Rules March 2007 simultaneous multi-access. 5.4.1. Packet Filter Lifetime There is no timer associated with the Packet Filter specification defining how long time the specification is valid. Instead, it's assumed that the specification is stored at the destination node as long as this node has ongoing communications with the multi-homed node. 6. Protocol Constants INITIAL_PFU_TIMER 3 seconds MAX_PFUACK_TIMEOUT 48 seconds 7. IANA considerations This document requires the following new number assignments from IANA: UDP Destination Port number This document also defines two message types: 0 Protocol version number 1 Packet Filter Update 2 Packet Filter Acknowledgement Finally, this document creates a third new name space "Status Code" for the Status field in the Packet Filter Acknowledgement message. The following values have been defined: 0 Packet Filter Update accepted 128 Rejected, reason unspecified 129 Administratively prohibited 130 Packet Filter included syntax error 131 Mobile node not allowed to update Packet Filter Larsson, et al. Expires September 6, 2007 [Page 18] Internet-Draft Monami6 Filter Rules March 2007 8. Security Considerations The transport used to exchange the flow distribution policy MUST be secured to the same extent as the Mobile IPv6 Binding Updates. 9. References 9.1. Normative References [I-D.draft-kauppinen-monami6-binding-filter-rule] Kauppinen, T., "Filter Rule Identifier Binding in Mobile IPv6", draft-kauppinen-monami6-binding-filter-rule (work in progress), June 2006. [I-D.ietf-monami6-multiplecoa] Wakikawa, R., "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-01 (work in progress), November 2006. [PF] "PF: The OpenBSD Packet Filter", May 2006, . [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. 9.2. Informative References [I-D.ietf-hip-base] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-07 (work in progress), February 2007. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol Larsson, et al. Expires September 6, 2007 [Page 19] Internet-Draft Monami6 Filter Rules March 2007 (MOBIKE)", RFC 4555, June 2006. Appendix A. Usage Scenarios This section exemplifies how filter rules and bindings are created and sent to the filtering peer. Assume a multi-homed mobile node with three interfaces; if1, if2 and if3 configured with CoA1, CoA2 and CoA3 respectively. The mobile node has 1 global identity tag, HoA, configured. At a certain time the mobile node has the following configuration: Filter Rule 1: fiid1 -----> BID-1 -----> CoA-1 Filter Rule 2: fiid2 -----> BID-1 -----> CoA-1 Filter Rule 3: fiid3 -----> BID-2 -----> CoA-2 Three filter rules have been created and relations between fiid number, BID and CoA have been established. Two interfaces, i.e. 'if1' and 'if2' are available. A.1. New Interface Available As the mobile node moves around a new access network, for which the user is authorized access to, becomes available. The new interface, 'if3', is activated and assigned care-of address 'CoA-3'. The new access network has improved characteristics for one of the filter rules, 'Filter Rule 2', and the mobile node decides to move the traffic flow for 'Filter Rule 2' to 'CoA-3' as shown below. Filter Rule 1: fiid1 -----> BID-1 -----> CoA-1 Filter Rule 2: fiid2 -----> BID-3 -----> CoA-3 Filter Rule 3: fiid3 -----> BID-2 -----> CoA-2 As a result of this event (new interface available) new binding information must be sent to the filtering peers. However, there is no need to send any updates of the filter rules to the filtering peers. A.2. New Filter Rule using existing Transmission Requirement The mobile node's user decides to start a new application. As a result of this, a new filter rule, 'Filter Rule 4', is created. The new filter rule has the same transmission requirements as an existing Larsson, et al. Expires September 6, 2007 [Page 20] Internet-Draft Monami6 Filter Rules March 2007 filter rule, 'Filter Rule 1', and is therefor assigned the same fiid number as 'Filter Rule 1' as shown below. Filter Rule 1: fiid1 -----> BID-1 -----> CoA-1 Filter Rule 2: fiid2 -----> BID-3 -----> CoA-3 Filter Rule 3: fiid3 -----> BID-2 -----> CoA-2 Filter Rule 4: fiid1 -----> BID-1 -----> CoA-1 As a result of this event (new filter rule using existing transmission requirement) the updated set of filter rules must be sent to the filtering peers. There is no need to send any new binding information since existing bindings are used. A.3. New Filter Rule with new Transmission Requirement The mobile node's user decides to start a new application. As a result of this, a new filter rule, 'Filter Rule 5', is created. The new filter rule has new transmission requirements and is therefor assigned a new fiid number, 'fiid 4'. New bindings between the newly created fiid number and an existing BID and CoA are also established as shown below. Filter Rule 1: fiid1 -----> BID-1 -----> CoA-1 Filter Rule 2: fiid2 -----> BID-3 -----> CoA-3 Filter Rule 3: fiid3 -----> BID-2 -----> CoA-2 Filter Rule 4: fiid1 -----> BID-1 -----> CoA-1 Filter Rule 5: fiid4 -----> BID-2 -----> CoA-2 As a result of this event (new filter rule with new transmission requirement) the updated set of filter rules and bindings must be sent to the filtering peers. A.4. Interface Out of Range As the mobile node's user moves around he gets out of range from one of the radio accesses, 'if3'. This event causes the mobile node to rearrange the data flow for 'Filter Rule 2' to use 'if2' instead as shown below. Filter Rule 1: fiid1 -----> BID-1 -----> CoA-1 Filter Rule 2: fiid2 -----> BID-2 -----> CoA-2 Filter Rule 3: fiid3 -----> BID-2 -----> CoA-2 Filter Rule 4: fiid1 -----> BID-1 -----> CoA-1 Larsson, et al. Expires September 6, 2007 [Page 21] Internet-Draft Monami6 Filter Rules March 2007 Filter Rule 5: fiid4 -----> BID-2 -----> CoA-2 As a result of this event (interface out of range) new binding information must be sent to the filtering peers. However, there is no need to send any filter rule updates since they are the same even after this event. A similar scenario as the above would be if the radio transmission for an existing radio interface deteriorate below a certain pre- configured threshold. In this case the radio interface would still be available but the mobile node could decide to move certain traffic flows with higher performance requirements to another interface that could better meet the transmission requirements. 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 Larsson, et al. Expires September 6, 2007 [Page 22] Internet-Draft Monami6 Filter Rules March 2007 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 September 6, 2007 [Page 23] Internet-Draft Monami6 Filter Rules March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Larsson, et al. Expires September 6, 2007 [Page 24]