Network Working Group S. Kiesel Internet-Draft University of Stuttgart Expires: April 15, 2006 October 12, 2005 SIMCO over SCTP draft-kiesel-midcom-simco-sctp-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 April 15, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document specifies how to use SCTP for the transport of the SIMCO (Version 3.0) protocol. SIMCO (SImple Middlebox COnfiguration) is a protocol that implements the MIDCOM semantics. It can be used for controlling middleboxes such as firewalls and network address translators. SCTP (Stream Control Transmission Protocol) is a transport layer protocol that is expected to have advantages for this type of application, compared to TCP, which is the default transport layer protocol for SIMCO. The specific requirements for SIMCO when using SCTP instead of TCP are specified in this document. Kiesel Expires April 15, 2006 [Page 1] Internet-Draft SIMCO over SCTP October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 3. Potential benefits . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Multiple streams for reduced head-of-line blocking . . . . 5 3.2. Multihoming Support . . . . . . . . . . . . . . . . . . . 5 4. Usage of SCTP as transport protocol for SIMCO . . . . . . . . 6 4.1. Leveraging SCPT's multiple streams feature . . . . . . . . 6 4.2. Establishment of SCTP association . . . . . . . . . . . . 6 4.3. Encapsulation of SIMCO messages into SCTP data chunks . . 7 4.4. Mapping of SIMCO Session Control Messages into SCTP streams . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.4.1. SIMCO Agent behavior requirements . . . . . . . . . . 7 4.4.2. SIMCO server (middlebox) requirements . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Kiesel Expires April 15, 2006 [Page 2] Internet-Draft SIMCO over SCTP October 2005 1. Introduction The SIMCO (SImple Middlebox COnfiguration) protocol [I-D.stiemerling- midcom-simco] is a signaling protocol that implements the MIDCOM protocol semantics [RFC3989]. In the context of the MIDCOM architecture [RFC3303], it can be used for controlling middleboxes [RFC3234] such as firewalls and network address translators (NATs). As outlined in [RFC3303], firewalls and NATs are potential obstacles to packet streams, for example if dynamically negotiated UDP or TCP port numbers are used, as in many peer-to-peer communication applications. SIMCO allows applications to communicate with middleboxes on the datagram path in order to request a dynamic configuration at the middlebox that enables datagram streams to pass the middlebox. Applications can request pinholes at firewalls and address bindings at NATs. The SIMCO specification [I-D.stiemerling-midcom-simco] mandates TCP (Transmission Control Protocol) [RFC0793] as the default transport for SIMCO. The Stream Control Transmission Protocol (SCTP) [RFC2960] has originally been designed as a part of the SIGTRAN architecture [RFC2719], for the transport of Signaling System No. 7 (SS7) messages over IP. However, this rather special purpose is achieved by adaptation layers on top of SCTP. SCTP itself has been designed as a generic transport protocol for IP networks, at the same layer in the protocol stack as TCP or UDP. SCTP offers several advantages compared to TCP for the transport of signaling protocols, especially in scenarios with high reliability requirements or high signaling traffic between two endpoints. This document supplements the SIMCO Version 3.0 specification [I-D.stiemerling-midcom-simco] by itemizing the requirements for transporting SIMCO over SCTP. Kiesel Expires April 15, 2006 [Page 3] Internet-Draft SIMCO over SCTP October 2005 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 [RFC2119]. Kiesel Expires April 15, 2006 [Page 4] Internet-Draft SIMCO over SCTP October 2005 3. Potential benefits A summary of SCTP's properties and advantages is given in [RFC3257]. Two of these properties are of special benefit, especially when SIMCO is used in large-scale deployments. 3.1. Multiple streams for reduced head-of-line blocking SCTP allows to send user messages over several streams within a single SCTP association. SCTP ensures in-order delivery only for those messages that are sent through the same stream. This limits the impact of the so-called head-of-line (HOL) blocking problem to one stream. HOL blocking occurs if a reliable transport layer protocol has to retransmit a message due to packet loss or bit errors. Subsequent messages that have already arrived at the receiving side cannot be delivered to the upper protocol layers until the retransmission is completed. Instead, they have to be buffered, in order to ensure in- order delivery. Unlike TCP, which has to buffer the whole connection, SCTP has to buffer only one stream, while messages from other streams still can be delivered to the upper layer protocol. SIMCO can profit from SCTP's multiple streams feature as a typical SIMCO session consists of several message threads, each of them requiring in-order delivery, but being independent of each others. 3.2. Multihoming Support SCTP transparently supports endpoints with several IP addresses. This allows for having several physical network interfaces connected to different networks. The availability of all paths between these interfaces is monitored with keepalive messages. If the primary path, which is normally used for message transmission, becomes unavailable an automatic changeover to one of the backup paths is performed. Kiesel Expires April 15, 2006 [Page 5] Internet-Draft SIMCO over SCTP October 2005 4. Usage of SCTP as transport protocol for SIMCO 4.1. Leveraging SCPT's multiple streams feature A central concept of SIMCO are the so-called policy rules. Policy rules correspond to pinholes on firewalls, and to address bindings on NATs. They are created, modified, and deleted by means of SIMCO transactions, i.e., a request sent from the SIMCO agent to the middlebox plus a positive or negative reply. All SIMCO messages bear a Transaction Identifier (TID) field that identifies to which transaction the message belongs to. The TID is uniquely assigned by the entity that sends the transaction's first message (usually the SIMCO agent, in case of asynchronous notifications the middlebox). Policy rules are identified by a numerical policy rule identifier (PID). When a request creates a new policy rule at the middlebox, the middlebox assigns a unique PID and returns it in the positive reply. All subsequent transactions that modify or delete the policy rule contain the respective PID. It is important that the transport layer protocol preserves the order of transactions that refer to the same policy rule, i.e., to the same PID. For example, it would be bad if a SIMCO agent requested a policy rule and immediately afterwards canceled it, but the delete message was delivered to the middlebox before the enable message. However, there is no requirement that prohibits reordering of SIMCO messages that refer to different policy rules. The basic idea is therefore to have several bidirectional pairs of streams within the SCTP association. All SIMCO messages belonging to one transaction, i.e., all messages that have the same TID value shall be sent over the same stream pair. Furthermore, all SIMCO transactions that refer to the same PID shall be transported over the same stream pair. Transactions that refer to other PIDs may be transported over other streams and are therefore not affected if one stream suffers from HOL blocking. 4.2. Establishment of SCTP association In order to setup a SIMCO session, an agent establishes one SCTP association to port 7626/SCTP at the middlebox. During establishment of the SCTP association, the agent and the middlebox will negotiate the number of streams to use, according to section 5.1.1 of [RFC2960]. After the negotiation the SCTP association has N1 streams from the agent to the middlebox and N2 streams from the middlebox to the agent. From these streams, only the first N = min(N1,N2) streams in each direction (i.e., streams Kiesel Expires April 15, 2006 [Page 6] Internet-Draft SIMCO over SCTP October 2005 with stream identifiers 0 to (N-1) ) will be used. A pair consisting of two streams with the same stream identifier but running in opposite directions is considered and used as one bi-directional stream pair. If the middlebox has accepted fewer streams as requested by the agent, the agent MAY decide to shutdown the SCTP association without sending any SIMCO messages. The N bidirectional stream pairs are used for the transmission of policy rule related transactions and policy rule related asynchronous notifications. SIMCO session related transactions and notifications are always transmitted over stream pair 0. 4.3. Encapsulation of SIMCO messages into SCTP data chunks Every single SIMCO message MUST be passed as exactly one user message to the SCTP layer. SCTP implementations used in conjunction with SIMCO MUST support fragmentation of user messages that exceed the MTU (see [RFC2960], section 6.9). The SCTP data chunk's Payload Protocol Identifier field is set to ??? (SIMCO) (TBD, see IANA considerations section). 4.4. Mapping of SIMCO Session Control Messages into SCTP streams The objective of the following requirements is to reduce the impact of HOL blocking by distributing transactions on several SCTP streams while retaining ordering where needed. 4.4.1. SIMCO Agent behavior requirements 4.4.1.1. Session Control Messages Session control messages (SE, SA, ST) MUST be sent over stream 0. 4.4.1.2. Policy Rule Control Messages that do not refer to a PID The SIMCO agent may use any implementation specific strategy to distribute policy rule control messages that do not include a PID attribute (PRR, PER, PRL, PDR) over the N streams. Possible strategies are, for example: o round robin o SIMCO transaction identifier (TID) modulo N Kiesel Expires April 15, 2006 [Page 7] Internet-Draft SIMCO over SCTP October 2005 o find status of all outbound streams and select the one with least unacknowledged data chunks If the SIMCO agent receives a PRR positive reply, PER positive reply, or PDR positive reply, the SIMCO agent MUST internally store the mapping between the PID contained in the reply and the number of the stream it was received on. 4.4.1.3. Policy Rule Control Messages that refer to a PID The SIMCO agent MUST send requests that include a PID attribute (PEA, PLC, PS) using the stream number that was saved for this PID, according to Section 4.4.1.2. An agent may want to send one of these requests (especially PS) referring to a policy rule that was not established by this agent, e.g., if the agent has learned the PID by means of a PRL transaction. In this case, the agent has no mapping from this PID to an SCTP stream number. The agent may send this request over any stream, according to a strategy as described in Section 4.4.1.2. 4.4.2. SIMCO server (middlebox) requirements 4.4.2.1. Replies to transactions initiated by Agent For sending (positive or negative) replies to requests issued by the MIDCOM agent, the middlebox MUST use the same outbound stream number as the number of the inbound stream on which the request was received on. 4.4.2.2. Asynchronous Rule Event notifications For sending ARE messages, the middlebox may use any implementation specific strategy to distribute the ARE notification messages over all N streams. Possible strategies are, for example: o round robin o find status of all outbound streams and select the one with least unacknowledged data chunks 4.4.2.3. Asynchronous Session Termination notifications AST messages MUST be sent over stream 0. Kiesel Expires April 15, 2006 [Page 8] Internet-Draft SIMCO over SCTP October 2005 5. Security Considerations SCTP has certain advantages over TCP with respect to the protection against denial of service (DoS) attacks (state cookie mechanism, verification tags) [RFC2960]. However, the main threats that are identified in [I-D.stiemerling-midcom-simco] apply for using SIMCO over SCTP as well. Therefore, the requirements given in the section "Security Considerations" of [I-D.stiemerling-midcom-simco] MUST be fulfilled when using SCTP instead of TCP, too. Information on known security threats and countermeasures specific to SCTP can be found in [I-D.stewart-tsvwg-sctpthreat]. Kiesel Expires April 15, 2006 [Page 9] Internet-Draft SIMCO over SCTP October 2005 6. IANA considerations According to [I-D.stiemerling-midcom-simco], the well-known port number 7626/TCP has been registered with IANA for SIMCO. The same port number should be registered for SCTP. An SCTP Payload Protocol Identifier should be registered for SIMCO, see http://www.iana.org/assignments/sctp-parameters 7. References [I-D.ietf-tsvwg-sctpsocket] Stewart, R., "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)", draft-ietf-tsvwg-sctpsocket-11 (work in progress), September 2005. [I-D.stewart-tsvwg-sctpthreat] Stewart, R., "Stream Control Transmission Protocol (SCTP) Security Threats", draft-stewart-tsvwg-sctpthreat-03 (work in progress), June 2005. [I-D.stiemerling-midcom-simco] Stiemerling, M., "Simple Middlebox Configuration (SIMCO) Protocol Version 3.0", draft-stiemerling-midcom-simco-07 (work in progress), May 2005. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, "Framework Architecture for Signaling Transport", RFC 2719, October 1999. [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002. [RFC3257] Coene, L., "Stream Control Transmission Protocol Applicability Statement", RFC 3257, April 2002. Kiesel Expires April 15, 2006 [Page 10] Internet-Draft SIMCO over SCTP October 2005 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002. [RFC3989] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox Communications (MIDCOM) Protocol Semantics", RFC 3989, February 2005. Kiesel Expires April 15, 2006 [Page 11] Internet-Draft SIMCO over SCTP October 2005 Author's Address Sebastian Kiesel University of Stuttgart Pfaffenwaldring 47 Stuttgart 70569 Germany Phone: +49 711 685 7992 Email: kiesel@ikr.uni-stuttgart.de URI: http://www.ikr.uni-stuttgart.de/en/~kiesel Kiesel Expires April 15, 2006 [Page 12] Internet-Draft SIMCO over SCTP October 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. Kiesel Expires April 15, 2006 [Page 13]