Network Working Group K. Mitsuya Internet-Draft Keio University Expires: April 19, 2007 K. Tasaka KDDI R&D Lab R. Wakikawa Keio University October 16, 2006 A Policy Data Set for Flow Distribution draft-mitsuya-monami6-flow-distribution-policy-02.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 April 19, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The multiple care-of addresses registration protocol [1] maintains at the same time multiple virtual paths with its home agent or correspondent nodes. This document provides a policy data set for flow distribution among the multiple paths. The flow distribution policy defines how packets are forwarded from and to the mobile node Mitsuya, et al. Expires April 19, 2007 [Page 1] Internet-Draft A Policy Data Set for Flow Distribution October 2006 by using the multiple paths. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 4 4. Policy Data Set . . . . . . . . . . . . . . . . . . . . . . . 5 5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Changes from Previous Revisions . . . . . . . . . . . . . . . 8 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Appendix A. Schema Fragment . . . . . . . . . . . . . . . . . . . 9 Appendix B. Policy Exchange using HTTP/SOAP . . . . . . . . . . . 10 B.1. Request to Install Policy . . . . . . . . . . . . . . . . 11 B.2. Update Policy . . . . . . . . . . . . . . . . . . . . . . 12 B.3. Flush Policy . . . . . . . . . . . . . . . . . . . . . . . 12 B.4. Response . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Mitsuya, et al. Expires April 19, 2007 [Page 2] Internet-Draft A Policy Data Set for Flow Distribution October 2006 1. Introduction A mobile node (mobile host or router) has several network accesses to the Internet and switches between or simultaneously uses these interfaces. Traffic from and to the mobile node are distributed to these interfaces based on user's and network's operator policies. This document is an informational draft to explain how to utilize multiple paths provided by the multiple care-of addresses registration protocol [1] to distribute traffic from and to a mobile node among the available paths. The multiple care-of addresses registration protocol (MCoA) provides an extension to Mobile IPv6 in order to maintain at the same time multiple virtual paths with its home agent or correspondent nodes. An unique identifier named BID (Binding Unique Identification number) is assigned on each path to distinguish each of them. By this way, it is possible to register multiple CoAs at the same time. This draft aims to provide a solution to define Flow Distribution Policy, how packets are forwarded from and to a mobile node by using its multiple CoAs, and to exchange the flow distribution policy between the endpoints of the multiple virtual paths. Our approach supports the separation of registering bindings and exchanging flow distribution policy unlike those proposed protocols [4] [5] [6] [7]. The proposed protocols carry the policies in the mobility messages. It is not always preferable to attach the policy to mobility messages because of its scalability and complexity. In the case that there are many policies, it is impossible to carry all of them within a single binding update signaling. The mobility header does not support the fragmentation. Furthermore, when the policy is wrong, because of e.g. duplication of policies, it could be required to exchange several mobility message to negotiate a solution to the problem. It is not the purpose of mobility signaling. First, this draft explains the overview of our proposed architecture to clarify the target of this draft. Second, this draft provides a policy data set for flow distribution. Additionally, this draft also provides an example a dynamic policy exchange method. 2. Requirements notation 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 [2]. Mitsuya, et al. Expires April 19, 2007 [Page 3] Internet-Draft A Policy Data Set for Flow Distribution October 2006 3. Architecture Overview The overview of our proposed architecture is shown in Figure 1. Multiple virtual paths maintained by the multiple care-of addresses registration protocol is shown as IF1, IF2, IF3, and IF4. IPF in the figure means OS-specific flow distribution feature like IPFilter on BSD and Netfilter on Linux. Flow-A is represented as "***" and Flow-B as "~~~". Other available but not used virtual paths are represented as "===". +---- Mobile Node ----+ +---- Home Agent -----+ | +--------+<--------------(B)--------------->+--------+ | | | Policy | | | | Policy | | | +---|----+ +---+ IF1==========IF1 +---+ +---|----+ | | +--(A)-->| I | | | | I |<--(A)-+ | | | | IF2**********IF2 | | | | Flow-A*******| P | | | | P |**************** to the | | | IF3==========IF3 | |~~~~~~~~~~~~~~~~ Internet | Flow-B~~~~~~~| F | | | | F | | | +---+ IF4~~~~~~~~~~IF4 +---+ | +---------------------+ +---------------------+ Figure 1: Flow Distribution Architecture Overview Any operating system should have the flow distribution feature. A virtual path between a mobile node and a home agent is achieved with the multiple care-of addresses registration protocol and it may be abstracted as one of the network interfaces. Flows are then being distributed among the available paths thanks to the polices installed on the system with the IPF tool. What we are missing here is how to synchronize the user's and network operator's policy between mobile node and home agent. (A): A policy data set, "Policy" in the figure, is an abstracted user policy and a text based data set. The policy data set has to be translated into the format of the IPF system to be able to install the policy on a host. The definition of policy is described in Section 4. The policy data set can be installed when the products are shipped or exchanged by using any transport protocol (B). Note that the installation of the policy data set can be ordered not only from MN to HA (or HA to MN) but also is ordered from MNN and CN to MN and HA by using a dynamic policy exchange method if security associations are established. Mitsuya, et al. Expires April 19, 2007 [Page 4] Internet-Draft A Policy Data Set for Flow Distribution October 2006 4. Policy Data Set The policy includes Home address, Condition, Flow, Action and Lifetime. A set of selectors (Home Address, Condition, and Flow) is associated to a target (Action). Home address is a IPv6 home address used as the mobile node identifier. Policies are defined for each condition of the mobile node. A Condition refers to the kind of available network accesses on the mobile node. With the multiple care-of addresses registration protocol, the BID identifies in an unique way of the multiple paths between the mobile node and the home agent. Therefore, Condition is a list of available BIDs. Flow is a flow identified with a particular syntax described later in this section. Action defines how the flow is forwarded from and to mobile nodes. Lifetime is the lifetime of the installed policy. Policies could be installed on both the mobile node and the home agent. But a mobile node only has the responsibility for out-going traffic from the mobile node, and a home agent has the responsibility about the traffic going to the mobile node. It is thus required to clarify to where a policy is addressed. This is the definition of Direction in this draft, respectively described as "in" or "out". A flow is identified by the source/destination pair, its direction (FROM mobile node "out" or TO mobile node "in"), address, source/ destination port, flow type, and protocol number. The destination interface of the flow is specified by the BID. These are the policy elements. The format for policy data set can be described using the following grammar in BNF: filter-rule = homeAddr condition flow action lifetime homeAddr = host-name . condition = decnumber . flow = direction [ "quick" ] match . action = "on" decnumber | "drop" . lifetime = decnumber direction = "in" | "out" . match = [ tos ] [ ttl ] [ proto ] [ ip ] . tos = "tos" decnumber | "tos" hexnumber . ttl = "ttl" decnumber . proto = "proto" protocol . ip = srcdst [ flags ] [ with withopt ] [ icmp ] [ keep ] . protocol = "tcp/udp" | "udp" | "tcp" | "icmp" | decnumber . srcdst = "all" | fromto . Mitsuya, et al. Expires April 19, 2007 [Page 5] Internet-Draft A Policy Data Set for Flow Distribution October 2006 fromto = "from" object "to" object . object = addr [ port-comp | port-range ] . addr = "any" | nummask | host-name [ "mask" ipaddr | "mask" hexnumber ] . port-comp = "port" compare port-num . port-range = "port" port-num range port-num flags = "flags" flag { flag } [ "/" flag { flag } ] . with = "with" | "and" . nummask = host-name [ "/" decnumber ] . Host-name = ipaddr | hostname | "any" . ipaddr = host-num ":" host-num ":" host-num ":" host-num ":" host-num ":" host-num ":" host-num ":" host-num . host-num = digit [ digit [ digit ] ] . port-num = service-name | decnumber . withopt = [ "not" | "no" ] opttype [ withopt ] . opttype = "ipopts" | "short" | "frag" | "opt" optname . optname = ipopts [ "," optname ] . ipopts = optlist | "sec-class" [ secname ] . secname = seclvl [ "," secname ] . seclvl = "unclass" | "confid" | "reserv-1" | "reserv-2" | "reserv-3" | "reserv-4" | "secret" | "topsecret" . decnumber = digit [ decnumber ] . hexnumber = "0" "x" hexstring . hexstring = hexdigit [ hexstring ] . compare = "=" | "!=" | "<" | ">" | "<=" | ">=" | "eq" | "ne"| "lt" | "gt" |"le" | "ge" . range = "<>" | "><" . hexdigit = digit | "a" | "b" | "c" | "d" | "e" | "f" . digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" . flag = "F" | "S" | "R" | "P" | "A" | "U" . For example, a mobile node has a home address, 2001:db8::328. The mobile node has two network accesses and BIDs (11 and 800) are assigned to each. When both interfaces are available, a flow from 2001:db8::dead:beef is delivered via BID 11. When only an interface which BID is 11 is available, a flow to 2001:db8::dead:beef and port = 25 is delivered via BID 800. In this case, the policy is described as below: 2001:db8::1000 11,800 in src=2001:db8::dead:beef on 11 0 2001:db8::1000 800 out quick dst=2001:db8::dead:beef port=25 drop 0 Mitsuya, et al. Expires April 19, 2007 [Page 6] Internet-Draft A Policy Data Set for Flow Distribution October 2006 This policy data set could be exchanged by using a transport protocol. There are possible scenarios: 1. Pre-installed: a policy is installed on mobile node and its home agent when it is manufactured. 2. Dynamic-exchange: a policy can be exchange by using any transport protocol such as SFTP, HTTPS or any other secured transport protocol. A dynamic exchange method using SOAP is introduced in Appendix A. 5. Error Codes When a policy data set is exchanged between two hosts, the response message needs to be exchanged. The response message indicates if an error is carried by using a transport protocol. A responder returns an error message as the response message to the initiator when a responder evaluates that there are some errors in policy data set. The error message may include a error code and its detailed message. The values are described as follow: +-------+------------------+----------------------------------------+ | Error | Message | Meaning | | code | | | +-------+------------------+----------------------------------------+ | 1001 | Administratively | A responder is not permitted to set | | | prohibited | Flow Distribution Policy by the | | | | administrator. | | 1002 | Initiator | Unauthorized initiator can't set Flow | | | Operation not | Distribution Policy. | | | permitted | | | 1003 | Invalid homeAddr | The homeAddr element in a request | | | | message is invalid. | | 1004 | Invalid | The condition element in a request | | | condition | message is invalid. | | 1005 | Necessary | The necessary elements are not founded | | | element not | in a request message. | | | founded | | | 1006 | Invalid policy | The policy set in a request message is | | | | invalid. | | 1007 | Duplicated | The policy set in a request message is | | | policy | duplicated. | | 1008 | Parameter not | The parameters in a request message | | | supported | are supported in a responder. | +-------+------------------+----------------------------------------+ Mitsuya, et al. Expires April 19, 2007 [Page 7] Internet-Draft A Policy Data Set for Flow Distribution October 2006 Table 1: Error code and message 6. Security Considerations The transport layer used to exchange the flow distribution policy should be secured by using secured transport protocol such as HTTPS. 7. Changes from Previous Revisions Version 02 change: o Change from the xml-based format to a BNF format. Version 01 change: o Clarify the meaning of "Direction". o Add how to specify a range of address or port. o Mention that any nodes can also be Initiator/Responder. 8. Acknowledgment The authors would like to thank Manabu Tsukada and Romain Kuntz for their comments. The authors would also like to thank Shigeyuki Akiba, Masatoshi Suzuki and Hiroki Horiuchi for their support and assistance. 9. References [1] Wakikawa, R., "Multiple Care-of Addresses Registration", draft-wakikawa-mobileip-multiplecoa-04 (work in progress), June 2005. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J., and H. Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", W3C Recommendation REC-soap12-part1-20030624, June 2003. [4] Montavont, N., "Home Agent Filtering for Mobile IPv6", draft-montavont-mobileip-ha-filtering-v6-00 (work in progress), December 2003. Mitsuya, et al. Expires April 19, 2007 [Page 8] Internet-Draft A Policy Data Set for Flow Distribution October 2006 [5] Soliman, H., "Flow Movement in Mobile IPv6", draft-soliman-mobileip-flow-move-03 (work in progress), June 2003. [6] Kuladinithi, K., "Filters for Mobile IPv6 Bindings", draft-nomadv6-mobileip-filters-03 (work in progress), October 2005. [7] Wakikawa, R., "Multiple Network Interfaces Support by Policy- Based Routing on Mobile IPv6", Proceedings the International Conference on Wireless Networks (ICWN), July 2002. Appendix A. Schema Fragment In this section, a xml based policy data set is described. The schema fragments of a xml based policy data set should be like Figure 4. A policy data set MUST incude homeAddr, condition, lifetime and one policy at least. Figure 4: Flow Distribution Policy Mitsuya, et al. Expires April 19, 2007 [Page 9] Internet-Draft A Policy Data Set for Flow Distribution October 2006 Figure 5 is an example configuration using the scheme fragment. In the present case, a mobile node has a home address, 2001:db8::328. The mobile node has two network accesses and a BID (11 and 800) is assigned to each. When both interfaces are available, flows from 2001:db8::dead:beef are delivered via BID 11, and flows to 2001:db8:: dead:beef and port = 25 are delivered via BID 800. A port number field and a protocol number field MUST include a Regular Expression. Network address can be included in a soruce address or a destination address field as "2001:db8::/64". 2001:db8::328 11,800 3600 in 2001:db8::dead:beef 11 out 1 2001:db8::dead:beef 25 800 Figure 5: Sample Configuration Appendix B. Policy Exchange using HTTP/SOAP In this section, a policy exchange method using HTTP/SOAP (Simple Object Access Protocol) [3] is explained. The SOAP request parameter to initiate the policy exchange is provided by HTTP required, and the SOAP response to handle error processing is provided by HTTP response. Here Initiator and Responder are introduced. Mobile node or home agent can be any type of node. Mobile node could be Initiator sometimes as well as the Home Agent. In the next sections, we assume that MN is the initiator and HA is the responder. Mitsuya, et al. Expires April 19, 2007 [Page 10] Internet-Draft A Policy Data Set for Flow Distribution October 2006 B.1. Request to Install Policy When mobile node boots up, it sends a request to install its policy to the home agent. An example HTTP request to install policy is shown in Figure 6. The timing to send a request is not limited to when it boots. Mobile node can send the request before it has expired or it has changed. POST /PolicyExchange HTTP/1.1 Host: router1.nemo.jp Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" 2001:db8::328 11,800 3600 in 2001:db8::dead:beef 11 out 1 2001:db8::dead:beef 25 800 Figure 6: Install Policy Once a home agent receives the request message, it evaluates the policy. Home agent MUST reply a response message as mentioned in Appendix B.4. By this message, mobile node can understand it the request was accepted or rejected, and it the latter case, the reason of the error. Mitsuya, et al. Expires April 19, 2007 [Page 11] Internet-Draft A Policy Data Set for Flow Distribution October 2006 B.2. Update Policy When the policy has changed, mobile node can send a update message. It is not mandatory to update all policies at one, only a small set of policy can be updated. An example HTTP request to update policies is shown in Figure 7. POST /PolicyExchange HTTP/1.1 Host: router1.nemo.jp Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" 2001:db8::328 11,800 3600 in 2001:db8::dead:beef 800 out 1 2001:db8::dead:beef 25 11 Figure 7: Update Policy Once a home agent received the request message, it evaluates the policy. Home agent MUST reply a response message as mentioned in Appendix B.4. By this message, mobile node can understand if the request was accepted or rejected, and in the latter case, the reason of the error. B.3. Flush Policy Figure 8 is a request message example to flush policies already Mitsuya, et al. Expires April 19, 2007 [Page 12] Internet-Draft A Policy Data Set for Flow Distribution October 2006 installed. POST /PolicyExchange HTTP/1.1 Host: router1.nemo.jp Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" 2001:db8::328 * Figure 8: De-registration Policy The asterisk in the condition tag means that this request MUST apply to all condition. And the policy tag without any policy inside requests to install null policy. This goes to flush all policies. B.4. Response A responder sets the body element to blank in the response message to indicate that it has successfully processed the request message. Figure 9 is a response message example when the policy in a request message is accepted by the responder. HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn Figure 9: Policy Accepted Mitsuya, et al. Expires April 19, 2007 [Page 13] Internet-Draft A Policy Data Set for Flow Distribution October 2006 The response message indicates that an error is carried inside a fault element. This fault element has a faultcode, a faultstring, a faultactor and a detail field. The faultcode element is used by software to provide an algorithmic mechanism to identify the fault. The faultstring element is intended to provide a human readable explanation of the fault and is not intended for algorithmic processing. The faultactor element is intended to provide information about the cause of the fault to happen within the message path. And The detail element is intended to carry application specific error information related to the body element. A responder returns error message as the response message to the initiator when a responder evaluates that error of some sort is in a body element. The error message may be included error code and message in the detail element. The values are described in Table Table 1. Figure 10 is an example response message when the policy in a request message was subject to errors on the responder. HTTP/1.1 500 Internal Server Error Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAP-ENV:Server Server Error 1001 Figure 10: Policy Not Accepted Mitsuya, et al. Expires April 19, 2007 [Page 14] Internet-Draft A Policy Data Set for Flow Distribution October 2006 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/ 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/ Mitsuya, et al. Expires April 19, 2007 [Page 15] Internet-Draft A Policy Data Set for Flow Distribution October 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Mitsuya, et al. Expires April 19, 2007 [Page 16]