Next Steps in Signaling (nsis) H. Cheng Internet-Draft Q. Huang Expires: November 14, 2005 T. Sanda T. Ue Panasonic May 13, 2005 NSIS Flow ID and packet classification issues draft-cheng-nsis-flowid-issues-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 November 14, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract In NSIS signaling the Flow ID is used for identifying the traffic flows of an application session. Usually, it is derived from the communication addresses information used in traffic classification and filtering. Since the Flow ID is used for both signaling message routing and signaling state management, its dependency on the address information creates advert effects in certain scenarios. It also Cheng, et al. Expires November 14, 2005 [Page 1] Internet-Draft NSIS Flow ID issues May 2005 limits the applicability of the NSIS signaling for handover optimization in certain environment because of the lack of address information. Therefore, Flow ID derivation and the packet classification information should be separated in the NSIS design. This document presented some detailed analysis of the problems faced by the current Flow ID generation practice. Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Flow ID usage issue in NSIS . . . . . . . . . . . . . . . . . 6 4.1 Current usage of the Flow ID in NSIS . . . . . . . . . . . 6 4.2 Multiple addresses involved session . . . . . . . . . . . 7 4.3 Path pre-establishment . . . . . . . . . . . . . . . . . . 8 4.4 Address information variation . . . . . . . . . . . . . . 9 5. Issue impact Analysis . . . . . . . . . . . . . . . . . . . . 10 5.1 Impact on the framework/NTLP . . . . . . . . . . . . . . . 10 5.2 Impact on the NSLP . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1 Normative Reference . . . . . . . . . . . . . . . . . . . 14 9.2 Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 16 Cheng, et al. Expires November 14, 2005 [Page 2] Internet-Draft NSIS Flow ID issues May 2005 1. Conventions used in this document 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 [1]. Cheng, et al. Expires November 14, 2005 [Page 3] Internet-Draft NSIS Flow ID issues May 2005 2. Introduction Session Identifier (Session ID) and Flow Identifier (Flow ID) are two important and overloaded Identity Elements introduced by the NSIS Framework [2]. Among these two identifiers, the Flow ID is used for uniquely identifying the flow a packet associated with. In the design of the NTLP protocol [3], the Flow ID is also used for signaling message routing. According to the suggestion, the Flow ID is to be derived from information such as source and destination IP addresses, protocol identifiers and port numbers, DSCP/TOS field, and etc. In the NSLP level applications, e.g. QoS NSLP [4], the Flow ID is also utilized in state management. For example, the QNE will decide if a state of an old branch should be torn down based on the Flow ID of a newly received RESERVE message. In certain design aspects, the Flow ID is even proposed to be used for traffic classifying. The use of Flow ID in the above manner is proved working for scenarios depicted in those drafts. However, for some other scenarios Flow ID cannot meet the requirements of such functions. The main issue of using Flow ID in those scenarios is its dependency on the data traffic address information. In certain cases the address information cannot be represented by a simple Flow ID, e.g. the multihoming case, or multi-thread cases. This will make the Flow ID incapable of carrying the full information for packet classification. In certain scenarios, the NSIS signaling needs to be carried before the actual data traffic flow starts. It is possible that at this point of time some address information is not yet available, and thus the Flow ID could not be generated according to the current specified method. This would happen most likely in cases when proxy is involved for the fast handover assistance. In other case, the address information involved in the Flow ID generation may change in the cause of the session, e.g. the port number of the DSCP/ TOS fields. This does not necessary mean the flow changed, and should not trigger the state change along the data path. Therefore, the Flow ID and the traffic classification information do not synchronize. In a summary, the current Flow ID is overloaded with different functionalities that should be provided with separate information elements. This draft provides a detailed analysis of the scenarios and the problems for using Flow IDs. Cheng, et al. Expires November 14, 2005 [Page 4] Internet-Draft NSIS Flow ID issues May 2005 3. Terminology The Terminology defined in [2], [3] and [4] applies to this draft. In addition, the following terms are used: Multihoming Node: A node making use of multiple IP addresses for a communication session. Proxy: An NE which initiates and/or terminates NSIS signaling on behalf of the end hosts. Flow ID and MRI are used interchangeably in this draft. Cheng, et al. Expires November 14, 2005 [Page 5] Internet-Draft NSIS Flow ID issues May 2005 4. Flow ID usage issue in NSIS 4.1 Current usage of the Flow ID in NSIS In the existing NSIS Working Group drafts, the Flow ID is defined as an identifier that provide enough information such that the signaling flow receives the same treatment along the data path as the actual data itself[2]. It is also identified that information to be used for the identifier includes Source IP address, Destination IP address, protocol identifier and higher layer (port) addressing, flow label, SPI filed of IPsec data, and DSCP/TOS filed. The reason for placing the Flow Identifier in the NTLP layer was to allow visibility and modification at the address boundaries. In the GIMPS document [3], the Flow Identifier is further utilized as the Message-Routing-Information (MRI). The MRI is then required to be set at message sender and is read only to the GIMPS. A formation of the Flow Identifier is provided as: Flow-Identifier = Network-layer-version Source-address prefix-length Destination-address prefix-length IP-protocol Traffic-class [flow-label] [ipsec-SPI/L4-ports] In the signaling applications, it is usually necessary to have information about the flow classification for the enforcement. Based on the description of the drafts, the flow should be identified solely by the MRI. For example, in the QoS-NSLP draft [4], only information about the flow is the Flow ID passed from the GIMPS. Even in the QSPEC defined in [5], there is no information about the packet classification. Therefore, it is assumed that the QNE would only be able to set the Packet Classifier in its Traffic Control module based on the Flow ID. In the QoS-NSLP draft [4], it is also mentioned that the Flow ID is used for the signaling state management. For example, it will help the QNE to detect a mobility event. It is obvious from the above that the Flow ID is heavily depended on Cheng, et al. Expires November 14, 2005 [Page 6] Internet-Draft NSIS Flow ID issues May 2005 in the NSIS signaling, and therefore has multiple functions associated. This kind of overloading of the Flow ID works fine with a simplified static network environment. However, with scales of the network growing and complexities increasing, the Flow ID would not be able to meet the requirements all the functionalities it performs. Following sections provide detail analysis of some examples where Flow ID of current NSIS design failed to deliver its designed functions. 4.2 Multiple addresses involved session In nowadays network, communication session usually involves multiple addresses at the end nodes. The multiple addresses could be different IP address, e.g. in a multihoming case. With the new development trend, more terminal devices are equipped with multiple communication technology or interfaces. When these different interfaces are used for the same session, for various reasons [6], multiple addresses would be employed for the session, and thus should be supported by the NSIS signaling. The multiple addresses could be also the different higher protocol address, e.g. several port numbers used in a multiple thread session. This type of multi-thread method is widely used in the popular FTP clients. Usually, a download session would be limited by the server resource allocation and network condition. The throughput achieved is thus also limited. To boost the downloading speed, some FTP clients establish multiple connections with the server, and download the file simultaneously. This would achieve much higher throughput. In this process, the terminal device will use multiple port number in the communication for the multiple connections. Since all these concurrent connections belong to the same session, NSIS should also be able to signal all the port numbers in the same signaling message. Taking the current Flow ID design, it is obvious that the above scenarios could not be properly supported. Due to its simple format, a Flow ID is not able to represent the complex multiple addresses involved in a session. For example, in the NSIS Framework draft [2], it is mentioned that the only limited wildcarding is provided for the Flow ID. However, wildcarding is not able to accurately represent the IP addresses or port numbers that are different on several bits. For example, port number 10001 and 10002 cannot be signaled with simple wildcarding. In the GIMPS draft [3], the MRI object format is provided. In this format, it is clear that only one set of address information could be incorporated. This is acceptable if the MRI is only used for the routing of the signaling message, because most likely the packets for the same flow with the different addresses should be routed through Cheng, et al. Expires November 14, 2005 [Page 7] Internet-Draft NSIS Flow ID issues May 2005 the same data path. On the other hand, if this object is also used for the data packet classification, it would create problem. For example, if only one of the addresses is included in the MRI, packets with other addresses will not be correct classified, and thus could not enjoy the proper QoS treatment. Or, if a mask is used, it may allow a wider address range than actually desired. This could result in lose to the user, both on accounting and QoS level. Although some quick remedy to this could be tweaking the Message- Routing-Method definition, and allow some special bit to indicate multiple address objects. However, this may also creates overhead in the NTLP layer processing. Since the NTLP layer does not need to care about the packet classifier details, the multiple addresses in MRI affect the overall signaling speed. Another possible way to carry the multiple address information is to signal multiple times, each with a Flow ID that accurately represents the address information. Obviously, this creates signaling overhead. Besides that, it may also cause difficulties in state management on the different NSIS nodes. For example, a QNE receiving several messages with different Flow IDs will not be able to decide the proper action. The REPLACE flag introduced in QoS-NSLP [4] provides a way to indicate the action to the QNEs. Nevertheless, it requires explicit signaling for the management of these different Flow IDs. For instance, if a mobility event happened, the state with the old Flow IDs should be replaced with a new set with new Flow IDs. Therefore, the signaling message needs to indicate state with which particular Flow IDs should be replaced, and which should be kept. This requires extra state management logic at the QNEs. 4.3 Path pre-establishment Proxy support in NSIS is mentioned in [2] [7]. Proxy node is an NE initiating and/or terminating NSIS signaling on behalf of the end hosts. The use of proxy is crucial for seamless handover, especially for the single interface terminal devices. However, in some scenarios, full information necessary for generating Flow ID may not be available when the proxy starts the signaling. This means no proper Flow ID could be used for the initial signaling, which renders either the proxy solution unworkable or extra signaling carried out afterwards. As mentioned above, one possible use case of proxy is for mobility scenario, which requires minimum QoS interruption at the time of handover [8]. Performing NSIS signaling after the MN's actual handover causes service interruption due to the delay in signaling path establishment. Therefore, provision of new path by proxy on the predictive new path is required. This is especially useful in Cheng, et al. Expires November 14, 2005 [Page 8] Internet-Draft NSIS Flow ID issues May 2005 networks that support the mobility optimizations. For example When the MN intends to handover, it may obtain the information of new subnetwork and suitable proxy by using some mobility protocols such as CARD [9], and then ask the proxy to prepare establishment of the new QoS path. However, according to current NSIS definiton, since the proxy does not know MN's nCoA before MN handover, it cannot generate the Flow ID. This means the proxy cannot send any signal for the predictive path, and therefore cannot be used for seamless handover purpose. 4.4 Address information variation In certain cases, the address information, e.g. port number, may change during the process of a flow. According to the current definition of Flow ID and MRI, it may result in the change of the Flow ID (which may trigger further NSIS signaling procedures). An example of the address varying application process is the establishment of a H.323 session [11]. Protocol like H.323 establishes the session progressively with the help of different auxiliary protocols. In H.323 establishment process, the actual RTP session will only be initiated at stage 3, which means the port address may change several time before the first RTP data packet is sent out. However, the NSIS messaging needs to start in Stage 1, e.g. to open the firewall pinholes. The problem created from this is that when the address information changes, the Flow ID needs to be changed accordingly, so that NSIS aware nodes along the path can obtain the correct packet classification information. Otherwise, the local enforcer, e.g. the RMF, could not perform its function correctly. However, the change in the Flow ID means another round of path establishment. And, in the process mentioned above, there could be multiple ports opened at the same time, and different transport protocol utilized. All these call for a simple way of changing the packet classification information along the signaling path without affecting the signaling state information. Cheng, et al. Expires November 14, 2005 [Page 9] Internet-Draft NSIS Flow ID issues May 2005 5. Issue impact Analysis This section provides a detail analysis of the impact of Flow ID issue on the design of NSIS protocols. 5.1 Impact on the framework/NTLP CUrrent NTLP design makes use of the MRI/FLow ID for the message routing in a path coupled manner. Therefore, it needs to guarantee that the MRI reflects the message routing information. For example, if the message routing is based on the source address, only the source address is actually needed for the MRI. The other information would be redundant. The unnecessary information in the MRI would become overhead for the signaling. However, since the FLow ID is also used for the packet classification, those fileds have to be included in the MRI/FLow ID. 5.2 Impact on the NSLP In the NSLP, the MRI/FLow ID will be used for the packet classification, and state mangement. Therefore, the MRI needs to include all the informaiton about every possible address combination for the packets associated with the same flow. This information also needs to be fed to the lcoal enforcer entity, e.g. the RMF in QoS applciations. It means the NSLP layer should be able to extract hte exact packet address information from the MRI/FLow ID for the different address combiantions. This renders any one-way compression or simplication unsuitable, e.g. a wildcarding may result in lose of infomarton, and in turn create in accuracy in the enforcement. Also for the state management, the FLow ID is used for the indexing of the states. However, due to differnt routing mechanism, there could be different format of the MRI/FLow ID. For example, the address for IPv4 and IPv6 would be different. THis would be difficult for the NSLP layer to design an efficient way of managing the state. Cheng, et al. Expires November 14, 2005 [Page 10] Internet-Draft NSIS Flow ID issues May 2005 6. Security Considerations Major security issues for NSIS are addressed in [10] and the Section 4.4 mentions use of a Flow ID without source and destination IP addresses. If a Flow ID is used for classification of data packets as well, then identity spoofing and injecting traffic is much easier since a packet only needs to be marked and an adversary can use a nearly arbitrary endpoint identifier to achieve the desired result. Cheng, et al. Expires November 14, 2005 [Page 11] Internet-Draft NSIS Flow ID issues May 2005 7. Conclusion This draft discussed some issues faced by the NSIS design regarding its use of the Flow ID for carrying data packet classification information. For example, in the multihoming or multi-thread case, pre-establishment case, etc, the Flow ID would not be able to efficiently or accurately represent the addressing information. Several examples are studied in detail to reveal the problem. Detail analysis of the impact to different components of the NSIS framework is also provided. Cheng, et al. Expires November 14, 2005 [Page 12] Internet-Draft NSIS Flow ID issues May 2005 8. Acknowledgements This section contains the acknowledgements. Cheng, et al. Expires November 14, 2005 [Page 13] Internet-Draft NSIS Flow ID issues May 2005 9. References 9.1 Normative Reference [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Hancock, R., "Next Steps in Signaling: Framework", Internet Draft draft-ietf-nsis-fw-07, Work in progress , November 2004. [3] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet Messaging Protocol for Signaling", Internet Draft draft-ietf-nsis-ntlp-05, Work in progress , February 2005. [4] Bosch, S., "NSLP for Quality-of-Service Signaling", Internet Draft draft-ietf-nsis-qos-nslp-06, Work in progress , February 2005. [5] Ash, J., Bader, A., and C. Kappler, "QoS-NSLP QSpec Template", Internet Darf draft-ietf-nsis-qspec-03, Work in Progress , February 2005. [6] Ernst, T., "Goals and Benefits of Multihoming", Internet Darf draft-ernst-generic-goals-and-benefits-01, Work in Progress , February 2005. [7] Brunner, M., "Requirement for Signaling Protocols", RFC 3726, April 2004. [8] Chaskar, H., "Requirements of a Quality of Service (QoS) Solution for Mobile IP", RFC 3383, September 2003. [9] Liebsch, M., "Candidate Access Router Discovery", Internet Darf draft-ietf-seamoby-card-protocol-08, Work in Progress , September 2004. [10] Tschofenig, H., "Security Threats for NSIS", Internet Darf draft-ietf-nsis-threats-06, Work in Progress , October 2004. 9.2 Informative References [11] International Telecommunication Union (ITU) Telecommunication Standardization Sector (ITU-T), "Packet-based multimedia communications systems", ITU-T H. 323, July 2003. Cheng, et al. Expires November 14, 2005 [Page 14] Internet-Draft NSIS Flow ID issues May 2005 Authors' Addresses Hong Cheng Panasonic Singapore Laboratories Block 1022, Tai Seng Industrial Estate #06-3530, Tai Seng Avenue Singapore 534415 Singapore Phone: +65 6550 5477 Email: hcheng@psl.com.sg Qijie Huang Panasonic Singapore Laboratories Block 1022, Tai Seng Industrial Estate #06-3530, Tai Seng Avenue Singapore 534415 Singapore Phone: +65 6550 5414 Email: qjhuang@psl.com.sg Takako Sanda Matsushita Electric Industrial Co., Ltd. (Panasonic) 5-3, Hikarino-oka, Yokosuka City Kanagawa 239-0847 Japan Phone: +81 46 840 5764 Email: sanda.takako@jp.panasonic.com Toyoki Ue Matsushita Electric Industrial Co., Ltd. (Panasonic) 5-3, Hikarino-oka, Yokosuka City Kanagawa 239-0847 Japan Phone: +81 46 840 5816 Email: ue.toyoki@jp.panasonic.com Cheng, et al. Expires November 14, 2005 [Page 15] Internet-Draft NSIS Flow ID issues May 2005 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 (2005). 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. Cheng, et al. Expires November 14, 2005 [Page 16]