Network Working Group K. Mitsuya
Internet-Draft Keio University
Intended status: Standards Track K. Tasaka
Expires: August 5, 2007 KDDI R&D Lab
R. Wakikawa
Keio University
R. Kuntz
University of Tokyo
February 2007
A Policy Data Set for Flow Distribution
draft-mitsuya-monami6-flow-distribution-policy-03.txt
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 August 5, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The multiple care-of addresses registration protocol [1] allows a
mobile node to maintain, at the same time, multiple virtual paths
with its home agent or correspondent nodes. This document presents a
Mitsuya, et al. Expires August 5, 2007 [Page 1]
Internet-Draft A Policy Data Set for Flow Distribution February 2007
policy data set for flow distribution to be used with the multiple
care-of addresses registration protocol. This policy data set
defines policies, in an OS-independant manner, for a mobile node and
its home agent or correspondent node, from the point of view of one
of these nodes. This data set is aimed to be processed by this node
and the output is a set of filter rules to be used and exchanged with
its correspondents.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Flow Distribution with MCoA . . . . . . . . . . . . . . . . . 4
3.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Architecture Overview . . . . . . . . . . . . . . . . . . 5
4. Policy Data Set . . . . . . . . . . . . . . . . . . . . . . . 6
5. Changes from Previous Revisions . . . . . . . . . . . . . . . 9
6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Mitsuya, et al. Expires August 5, 2007 [Page 2]
Internet-Draft A Policy Data Set for Flow Distribution February 2007
1. Introduction
A mobile node (mobile host or router) has several network accesses to
the Internet and switches between or simultaneously uses these
accesses. Traffic from and to the mobile node are distributed to
these accesses based on user's and network's operator policies.
The multiple care-of addresses registration protocol (MCoA) [1]
provides an extension to Mobile IPv6 [2] to maintain multiple virtual
paths between a mobile node and its home agent or correspondant
nodes. An unique identifier named BID (Binding Unique Identification
number) is assigned on each path to distinguish each of them. A
binding is identified by a pair of a home address and a BID, so it is
possible for a mobile node to register multiple CoAs on its peers.
The MCoA protocol only defines a way to maintain multiple paths
between two nodes. However, both node have to use filtering rules to
know how to distribute the traffic among these multiple paths. As
the filtering decision is taken on multiple nodes (the end points of
the multiple paths), it is important that the overall rules are
consistent with the user's or operator's will.
We first present in this draft a policy data set that aims at
defining in an OS-independent manner a way to describe filtering
rules. We then explain how this data set can be used by a node to
decide the filtering rules information for itself and all its peers,
for to the traffic coming from or to this node.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [3].
The key words "Policy", "Filter Rules", "Filter", "Filtering Peer" in
this document are to be interpreted as described in [4]. In
addition, this document defines the following terms:
Target node: A set of filter rules can be associated to several
nodes. The target node refers to the node on which the associated
rules MUST be installed: a Filtering Peer or the mobile node
itself.
Condition: A condition is a set of characteristics of available
access networks, associated to a set of target nodes. If the
condition matches, the set of filter rules for each target nodes
is selected.
Mitsuya, et al. Expires August 5, 2007 [Page 3]
Internet-Draft A Policy Data Set for Flow Distribution February 2007
Policy Data Set: A policy data set is a set of conditions, target
nodes, and filter rules from the point of view of the node where
the conditions are tested.
3. Flow Distribution with MCoA
3.1. Scenario
The overview of our targeted flow distribution scenario is shown in
Figure 1. Multiple virtual paths are maintained between two nodes
(eg. a mobile node and its home agent) thanks to the multiple care-of
addresses registration protocol: TUN1, TUN2, TUN3 and TUN4. Each
node has its own IP filtering framework (for example IPFilter on BSD
or Netfilter on Linux), described as "IPF" in the figure. Two bi-
directional flows (Flow-A and Flow-B) between the Mobile node and a
correspondent in the Internet are represented respectively with "***"
and "~~~". Other available but not used virtual paths are
represented with "===".
+----------------+
| Policy Data Set|
+-------|--------+
|
+---- Mobile Node ----+ | +---- Home Agent -----+
| +--------+<--------------(A)--------------->+--------+ |
| | Rules | | TUN1 | | Rules | |
| +---|----+ +---+ IF1==========IF1 +---+ +---|----+ |
| +--(B)-->| I | | TUN2 | | I |<--(B)-+ |
| | | IF2**********IF2 | | |
| Flow-A*******| P | | TUN3 | | P |**************** to the
| | | IF3==========IF3 | |~~~~~~~~~~~~~~~~ Internet
| Flow-B~~~~~~~| F | | TUN4 | | F | |
| +---+ IF4~~~~~~~~~~IF4 +---+ |
+---------------------+ +---------------------+
Figure 1: Flow Distribution Architecture Overview
Flows can be distributed among the available paths if proper policies
are installed on the system with the IP filtering framework. The box
referred to as "Policy Data Set" is a policy encoded as defined in
this document Section 4. Such data set can be shipped with the
product or received by using a secured transport protocol (step A)
(such exchange protocol not being covered by this draft). This
policy data set is then processed by the system on the host (step B)
according to its available conditions. The output is a set of filter
Mitsuya, et al. Expires August 5, 2007 [Page 4]
Internet-Draft A Policy Data Set for Flow Distribution February 2007
rules for each target hosts: the rules for the local hosts can be
translated and installed with the OS-specific IP filtering framework,
and rules for the remote hosts can be sent using a policy enforcement
mechanism, for example [5].
3.2. Architecture Overview
We assume that an IP filtering framework implemented in the operating
system (such as IPFilter for BSD or Netfilter for Linux) is used to
distribute the traffic among the multiple available paths maintained
by MCoA. Such framework is usually tightly integrated to the system,
thus no generic tool nor syntax exists to describe and install
filtering rules on different operating systems. We first aim at
defining a generic (ie OS-independent) grammar to define a policy
data set that could be exchanged and understood by heterogeneous
hosts. Such policy data set would describe filter rules based on
user's or network operator's policy. We also aim at defining a
framework that processes this policy data set.
We also assume that this policy data set can originally be stored
either on a mobile node or its home agent (eg. when the policy data
set is shipped with the product), but also on an authorized third-
part node that may not have any Mobile IPv6 functionnalities. This
policy data set can then be dynamically sent to the node willing to
install filtering policies (as this draft focuses on the definition
of the policy data set itself and its processing, such exchange
protocol will not be defined here). We thus separate binding
registrations and flow distribution policy exchange, in opposition to
the proposed protocols [6], [7], [8] and [9]. This allows to have a
very flexible mechanism, where, for example, mobile nodes could get
their policy data set from a policy database.
A policy data set includes filter rules for several hosts, classified
in a set of conditions from the point of view of one node. This node
processes its policy data set as follow:
o it firsts look in the list of conditions to see which one matches
with its current state. In the MCoA protocol, the BID identifies
in an unique manner the multiple paths between a mobile node and
its peers. Therefore, this document defines the conditions as a
list of the available BIDs on the node that processes the policy
data set.
o Each condition being associated to a list of target hosts and
rules, when a condition match we obtain a list of rules to apply
on several target hosts.
Mitsuya, et al. Expires August 5, 2007 [Page 5]
Internet-Draft A Policy Data Set for Flow Distribution February 2007
o If one of the target is the local host itself, it can translate
the associated filter rules for its own IP filtering framework,
and install them. Filter rules associated to other targets can be
sent using a filter rules exchange mechanism (in the case of a
Mobile Node, it could be for example [5]).
o Each time the condition changes on the host (for example, one BID
is not available anymore), the host processes again the policy
data set in order to select and install the most suitable filter
rules for him and its peers.
4. Policy Data Set
This section defines the format used to describe a policy data set.
It respects the ABNF (Augmented BNF) defined in [10] and is defined
as below.
A policy data set can include policies for a set of several hosts.
Each host is identified by its permanent IPv6 address (for a Mobile
Node, it would be its Home Address). Each defined node has a set of
available condifions, that refers to the characteristics of its
available access networks. Here, the BID is used as such
characteristics. For each set of conditions, a set of rules can be
defined for several target hosts. Each target host is identified
with its permanent IPv6 address, or refered as "local" (that refers
to the host that processes the policy data set) or "any" (any hosts
the local host is binded with).
A set of rules is then defined for each host. Each rule associates
some selectors (for example the source and destination address, the
source and destination ports, the protocol number, etc.) with an
action (the output path to choose, or drop the packets) and a
lifetime.
Mitsuya, et al. Expires August 5, 2007 [Page 6]
Internet-Draft A Policy Data Set for Flow Distribution February 2007
policy-set = 1*(idaddr conditions-sets ";")
idaddr = ADDR
conditions-sets = 1*(conditions target-set)
conditions = condition *("," condition)
condition = NUMBER
target-set = 1*(target rules)
target = "local" / "any" / ADDR
rules = 1*(flow action [lifetime])
flow = ["proto" protocol] [srcaddr] [dstaddr] [match]
protocol = [no] icmpv6 / [no] tcp / [no] udp / [no] NUMBER
icmpv6 = "icmpv6" icmptype
icmptype = [no] type ["/" code]
type = NUMBER
code = NUMBER
tcp = "tcp" [srcport] [dstport] [tcpflags]
udp = "udp" [srcport] [dstport]
srcport = "sport" [no] ports
dstport = "dport" [no] ports
ports = port / port ":" port / ":" port / port ":"
port = QSTRING / NUMBER
tcpflags = "flags" flags ["/" flags]
flags = FLAG / flags "," FLAG
srcaddr = "from" [no] addr
dstaddr = "to" [no] addr
addr = "any" / host [mask]
host = ADDR
mask = "/" NUMBER / "/" HEXNUM
match = "match" 1*(matchitem)
matchitem = "hoplimit" [no] hoplimit / "tclass" [no] tclass
/ "ip6h" [no] ip6headers
hoplimit = NUMBER / ":" NUMBER / NUMBER ":"
tclass = NUMBER / HEXNUM
ip6headers = ip6header *("," ip6header)
ip6header = NUMBER
action = "bid" NUMBER / "drop"
lifetime = "lft" NUMBER
no = "!" / "not" / "no"
addr1 = 1*4HEXDIG ":" *(1*4HEXDIG":") 1*(":" 1*4HEXDIG)
addr2 = 1*4HEXDIG *6(":" 1*4HEXDIG) "::"
addr3 = 7*7(1*4HEXDIG ":") 1*4HEXDIG
ADDR = addr1 / addr2 / addr3 / "::" / "::1"
QSTRING = ALPHA *(ALPHA / DIGIT / "-")
NUMBER = 1*DIGIT
HEXNUM = "0x" 1*HEXDIG
FLAG = "F" / "S" / "R" / "P" / "A" / "U"
For example, a Mobile Node has the 2001:db8::1000 Home Address and is
Mitsuya, et al. Expires August 5, 2007 [Page 7]
Internet-Draft A Policy Data Set for Flow Distribution February 2007
registered to its Home Agent whose address is 2001:db8::2000. One
policy data set defines the policies for both the MN and its HA, from
the MN point of view: the first field ("2001:db8::1000") defines the
destination of the policy data set (here, the MN).
2001:db8::1000
11,800
local
proto tcp sport 80 to any bid 800
from 2001:db8::1000 to any bid 11
2001:db8::2000
proto tcp dport 80 to any bid 800
from any to 2001:db8::1000 bid 11
11
local
proto tcp sport 80 to any drop
from 2001:db8::1000 to any bid 11
2001:db8::200
proto tcp dport 80 to any drop
from any to 2001:db8::1000 bid 11
This mobile node can register two Care-of Addresses whose BIDs are 11
and 800. When both CoAs are available (ie. when conditions "11,800"
matches), the policies are defined as follow:
For the MN ("local") the http traffic ("proto tcp sport 80 to
any") is sent via the path binded to the BID 800 ("bid 800") and
all other traffic ("from 2001:db8::1000 to any") is sent via the
path binded to the BID 11 ("bid 11").
For the HA ("2001:db8::2000"), symetric policies are defined
("proto tcp dport 80 to any bid 800" and "from any to 2001:db8::
1000 bid 11").
If only the CoA whose BID is 11 is available (condition "11"
matches), the policies are defined as follow:
For the MN ("local") the http traffic ("proto tcp sport 80 to
any") is dropped ("drop") and all other traffic ("from 2001:db8::
1000 to any") is sent via the path binded to the BID 11 ("bid
11").
For the HA ("2001:db8::2000"), symetric policies are defined
("proto tcp dport 80 to any drop" and "from any to 2001:db8::1000
bid 11").
The host 2001:db8::1000 may have received this policy data set
dynamically using a secured transport protocol (such as SFTP, HTTPS,
Mitsuya, et al. Expires August 5, 2007 [Page 8]
Internet-Draft A Policy Data Set for Flow Distribution February 2007
etc.), or it may have been shipped with it. The host processes this
data set according to its available BIDs. It then installs the
"local" rules on its own system, and send the rules specific to its
home agent using a policy exchange mechanism (e.g [5]).
5. Changes from Previous Revisions
Version 03 change:
o Clarified our architecture
o Removed the example of the dynamic policy exchange
o Improved the Policy Data Set
o Added the new author!
Version 02 change:
o Changed from the xml-based format to a BNF format.
Version 01 change:
o Clarified the meaning of "Direction".
o Added how to specify a range of address or port.
o Mentioned that any nodes can also be Initiator/Responder.
6. Acknowledgment
The authors would like to thank Manabu Tsukada for his comments. The
authors would also like to thank Shigeyuki Akiba, Masatoshi Suzuki
and Hiroki Horiuchi for their support and assistance.
7. References
[1] Wakikawa, R., "Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-01 (work in progress),
October 2006.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Mitsuya, et al. Expires August 5, 2007 [Page 9]
Internet-Draft A Policy Data Set for Flow Distribution February 2007
Levels", BCP 14, RFC 2119, March 1997.
[4] Larsson, C., "A Filter Rule Mechanism for Multi-access Mobile
IPv6", draft-larsson-monami6-filter-rules-01 (work in
progress), October 2006.
[5] Soliman, H., "Flow Bindings in Mobile IPv6",
draft-soliman-monami6-flow-binding-03 (work in progress),
October 2006.
[6] Montavont, N., "Home Agent Filtering for Mobile IPv6",
draft-montavont-mobileip-ha-filtering-v6-00 (work in progress),
December 2003.
[7] Soliman, H., "Flow Movement in Mobile IPv6",
draft-soliman-mobileip-flow-move-03 (work in progress),
June 2003.
[8] Kuladinithi, K., "Filters for Mobile IPv6 Bindings",
draft-nomadv6-mobileip-filters-03 (work in progress),
October 2005.
[9] Wakikawa, R., "Multiple Network Interfaces Support by Policy-
Based Routing on Mobile IPv6", Proceedings the International
Conference on Wireless Networks (ICWN), July 2002.
[10] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
Authors' Addresses
Koshiro Mitsuya
Keio University
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan
Phone: +81 466 49 1100
Email: mitsuya@sfc.wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~mitsuya/
Mitsuya, et al. Expires August 5, 2007 [Page 10]
Internet-Draft A Policy Data Set for Flow Distribution February 2007
Kazuyuki Tasaka
KDDI R&D Laboratories Inc.
2-1-15 Ohara
Fujimino, Saitama 356-8502
Japan
Phone: +81 49 278 7574
Email: ka-tasaka@kddilabs.jp
Ryuji Wakikawa
Keio University
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan
Phone: +81 466 49 1100
Email: ryuji@sfc.wide.ad.jp
URI: http://www.wakikawa.org/
Romain Kuntz
The University of Tokyo
Japan
Phone: +81 445 80 1600
Email: kuntz@sfc.wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~kuntz/
Mitsuya, et al. Expires August 5, 2007 [Page 11]
Internet-Draft A Policy Data Set for Flow Distribution February 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Mitsuya, et al. Expires August 5, 2007 [Page 12]