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]