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,
<ftp://ftp.openbsd.org/pub/OpenBSD/doc/pf-faq.pdf>.
[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]