Network Working Group K. Mitsuya Internet-Draft Keio University Expires: August 30, 2006 K. Tasaka KDDI R&D Lab R. Wakikawa Keio University February 26, 2006 A Schema Fragment for Flow Distribution draft-mitsuya-monami6-flow-distribution-policy-00.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 30, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The multiple care-of address registration protocol [1] provides a framework to maintain multiple virtual paths with its home agents. But there is no solution to synchronize a policy for flow distribution on the multiple paths. This document describes a schema fragment (a xml based data set) to define flow distribution policy. Mitsuya, et al. Expires August 30, 2006 [Page 1] Internet-Draft A Schema Fragment for Flow Distribution February 2006 A dynamic policy exchange method using SOAP is also introduced. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 4 4. Policy Data Set . . . . . . . . . . . . . . . . . . . . . . . 4 5. Policy Exchange using HTTP/SOAP . . . . . . . . . . . . . . . 6 5.1. Request to Install Policy . . . . . . . . . . . . . . . . 7 5.2. Update Policy . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Flush Policy . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Response . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Mitsuya, et al. Expires August 30, 2006 [Page 2] Internet-Draft A Schema Fragment for Flow Distribution February 2006 1. Introduction Mobile node has several network accesses to the Internet and switches between or simultaneously uses these interfaces. Traffic are distributed to the interfaces based on user or network operator's policies. The multiple care-of address registration protocol [1] provides a framework to maintain multiple virtual paths with its home agents or correspondent nodes at the same time. An unique identifier named BID (Binding Unique Identification number) is assigned on each path to distinguish between them. This document is an informational draft to explain how to utilize this architecture in order to distribute traffic based on user policies. The proposed protocols [4] [5] [6] [7] carry the policy by mobility signaling. It is not 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 the binding update signaling. The mobility header cannot have any fragmentation. Furthermore, when the policy is wrong, because of e.g. duplication of policies, it could be required to exchange several mobility signaling to negotiate that. It is not the purpose of mobility signaling. First, this draft explain the overview of our proposed architecture to clarify the target of this draft. Second, this draft provides a xml based data set, a schema fragment for flow distribution within mobile node, to describe an policy. A flow is identified by combining its direction (from mobile node or to mobile node), IPv6 source/destination address, source/destination port, flow id, and protocol number. The destination interface of the flow is specified by BID. Additionally, this draft also provides a dynamic policy exchange method. The policy data set can be exchanged by using any transport protocol such as SFTP, HTTPS or any other transport protocol. We introduce here an example method using Simple Object Access Protocol (SOAP) [3]. 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 August 30, 2006 [Page 3] Internet-Draft A Schema Fragment for Flow Distribution February 2006 3. Architecture Overview This document describes a schema fragment (a xml based data set) to define flow distribution policy with the multiple care-of address registration protocol. A dynamic policy exchange method using SOAP is also introduced. The overview of this proposal based on the multiple care-of address registration protocol is shown in Figure 1. Multiple virtual paths shown as IF1, IF2, IF3, and IF4 are maintained by the multiple care-of address registration protocol. 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 may have the flow distribution feature. A virtual path between mobile node and home agent may be abstracted as one of network interfaces. Flows are then being distributed by IPF as shown in the figure. This can be achieved with the multiple care-of address registration protocol. What we are missing here is how to synchronize the user policy between mobile node and home agent. (A): A xml based data set, "Policy" in the figure, is an abstracted user policy and it will be encoded when it is installed into a flow distribution feature. 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). An example method using Simple Object Access Protocol (SOAP) to exchange the policy is introduced in Section 5. 4. Policy Data Set Mitsuya, et al. Expires August 30, 2006 [Page 4] Internet-Draft A Schema Fragment for Flow Distribution February 2006 In this section, a xml based policy data set is described. The policy includes Home address, Condition, Direction and Policy. Home address is used as the mobile node identifier. Policies should be different according to the conditions of the mobile node, what kind of network accesses are available. With the multiple care-of address registration protocol, BID represents a path with home agent. Therefore, Condition is a list of available BID. Policies could be installed both the mobile node and the home agent. But a mobile node has only the responsibility of out-going traffic from the mobile node, and a home agent has the responsibility about the traffic going to the mobile node. So that, it is required to clarify to where a policy is addressed. A flow is identified by combination of source/ destination, its direction (FROM mobile node or TO mobile node), 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 schema fragments of a xml based policy data set should be like Figure 2. Figure 2: Flow Distribution Policy Mitsuya, et al. Expires August 30, 2006 [Page 5] Internet-Draft A Schema Fragment for Flow Distribution February 2006 Figure 3 is an example configuration using the scheme fragment. In the present case, a mobile node has a home address, 2001:200:0:100:: 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:200:0:100::dead:beef are delivered via BID 11, and flows to 2001:200:0:100::dead:beef and port = 25 are delivered via BID 800. 2001:200:0:100::328 11,800 in 2001:200:0:100::dead:beef 11 out 1 2001:200:0:100::dead:beef 25 800 Figure 3: Sample Configuration This policy 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 manufactured. 2. Dynamic-exchange: a policy can be exchange by using any transport protocol such as SFTP, HTTPS or any other secured transport protocol. 5. Policy Exchange using HTTP/SOAP In this section, a policy exchange method using HTTP/SOAP 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 Mitsuya, et al. Expires August 30, 2006 [Page 6] Internet-Draft A Schema Fragment for Flow Distribution February 2006 sometimes as well as the Home Agent. In the next sections, we assume that MN is the initiator and HA is the responder. 5.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 4. 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:200:0:100::328 11,800 3600 in 2001:200:0:100::dead:beef 11 out 1 2001:200:0:100::dead:beef 25 800 Figure 4: Install Policy Once a home agent receives the request message, it evaluates the policy. Home agent MUST reply a response message as mentioned in Section 5.4. By this message, mobile node can understand it the Mitsuya, et al. Expires August 30, 2006 [Page 7] Internet-Draft A Schema Fragment for Flow Distribution February 2006 request was accepted or rejected, and it the latter case, the reason of the error. 5.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 5. POST /PolicyExchange HTTP/1.1 Host: router1.nemo.jp Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" 2001:200:0:100::328 11,800 3600 in 2001:200:0:100::dead:beef 800 out 1 2001:200:0:100::dead:beef 25 11 Figure 5: Update Policy Once a home agent received the request message, it evaluates the policy. Home agent MUST reply a response message as mentioned in Section 5.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. Mitsuya, et al. Expires August 30, 2006 [Page 8] Internet-Draft A Schema Fragment for Flow Distribution February 2006 5.3. Flush Policy Figure 6 is a request message example to flush policies already installed. POST /PolicyExchange HTTP/1.1 Host: router1.nemo.jp Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" 2001:200:0:100::328 * Figure 6: 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. 5.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 7 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 Mitsuya, et al. Expires August 30, 2006 [Page 9] Internet-Draft A Schema Fragment for Flow Distribution February 2006 Figure 7: Policy Accepted 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. This document also introduces the following error code and message in the detail element. The values are described as followed: +-------+------------------+----------------------------------------+ | 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. | +-------+------------------+----------------------------------------+ Values of the status field less than 1001 indicate that name of fault codes is Server (home agent). Values equal to 1003 or greater than 1002 indicate that name of fault codes is Client (mobile node) Figure 8 is an example response message when the policy in a request message was subject to errors on the responder. Mitsuya, et al. Expires August 30, 2006 [Page 10] Internet-Draft A Schema Fragment for Flow Distribution February 2006 HTTP/1.1 500 Internal Server Error Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAP-ENV:Server Server Error 1001 Figure 8: Policy Not Accepted 6. Security Considerations The transport used to exchange the flow distribution policy SHOULD be secured. The transport used to exchange the flow distribution policy should be secured by using secured transport protocol such as HTTPS. 7. Acknowledgment The authors would like to thank Manabu Tsukada and Romain Kuntz for their comments. The authors would also like to thank Shigeyuki Akiba, Tohru Hasegawa and Hiroki Horiuchi for their support and assistance. 8. 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. Mitsuya, et al. Expires August 30, 2006 [Page 11] Internet-Draft A Schema Fragment for Flow Distribution February 2006 [4] Montavont, N., "Home Agent Filtering for Mobile IPv6", draft-montavont-mobileip-ha-filtering-v6-00 (work in progress), December 2003. [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. Mitsuya, et al. Expires August 30, 2006 [Page 12] Internet-Draft A Schema Fragment for Flow Distribution February 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 Oohara 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 August 30, 2006 [Page 13] Internet-Draft A Schema Fragment for Flow Distribution February 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 August 30, 2006 [Page 14]