Internet Draft Jim Renkel Document: draft-renkel-rsip-midcom-eval-00.txt The CommWorks Corp. Expires: October 2002 a 3Com company April 2002 Evaluation of RSIP against MIDCOM requirements Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document provides an evaluation of the RSIP (Realm Specific IP) framework and protocol against the evaluation criteria provided by the MIDCOM working group for the evaluation of middle box control protocols. RSIP is defined in experimental RFCs 3102 (Realm Specific IP: Framework) [3] and 3103 (Realm Specific IP: Protocol Specification) [4]; see also RFCs 3104 (RSIP Support for End-to-end IPsec) [5] and 3105 (Finding an RSIP Server with SLP) [6] for more information on RSIP. Renkel Internet draft [Page 1] Evaluation of RSIP against MIDCOM requirements April, 2002 Table of Contents 1. RSIP Framework compared to the MIDCOM Framework...............3 1.1 Framework elements in common to MIDCOM and RSIP ............3 1.2 Framework elements unique to MIDCOM ........................3 1.3 Framework elements unique to RSIP ..........................3 1.4 Comparison of MIDCOM and RSIP frameworks ...................4 2. Evaluation of RSIP against MIDCOM requirements................5 2.1 MIDCOM requirements met by RSIP. ...........................5 2.2 MIDCOM requirements partially met by RSIP. .................7 2.3 MIDCOM requirements NOT met by RSIP. .......................8 3. Security Considerations......................................10 4. References...................................................11 5. Author's Address.............................................11 6. Full Copyright Statement.....................................12 Renkel Internet draft [Page 2] Evaluation of RSIP against MIDCOM requirements April, 2002 1. RSIP Framework compared to the MIDCOM Framework 1.1 Framework elements in common to MIDCOM and RSIP The following framework elements are common to MIDCOM and RSIP, listed by their MIDCOM names, with their RSIP names, if different, given parenthetically. o hosts o applications o middleboxes (RSIP gateways) o private domain (private realm) o external domain (public realm) o middlebox communication protocol (RSIP!) o MIDCOM agent registration (host registration) o MIDCOM session (RSIP session) o filter (local / remote address and port number(s) pairs) 1.2 Framework elements unique to MIDCOM The following elements are unique to MIDCOM framework. If RSIP were adopted as the basis for the MODCOM protocol, they could be added to the RSIP framework, as explained below. o policy actions and rules. RSIP always implicitly assumes a _permit_ action. A more general and explicit action parameter would have to be defined. RSIP requests specifying local / remote address and port number(s) pairs (a MIDCOM filter) would have to be extended to include an action parameter (This would result in MIDCOM rules.). o application agents. RSIP makes no distinction between applications and agents; address assignment operations can be performed equally by applications and agents. o policy decision points. RSIP assumes that middleboxes grant or deny requests with reference to a policy known to them; the policy could be determined jointly by the middlebox and a policy decision point; such joint determination is not addressed by the RSIP framework but not precluded by it. 1.3 Framework elements unique to RSIP The following elements are unique to the RSIP framework. If RSIP were adopted as the basis for the MODCOM protocol, they could be added to the MIDCOM framework. o RSIP client: that portion of the application (or agent) that talks to the RSIP gateway using RSIP. Renkel Internet draft [Page 3] Evaluation of RSIP against MIDCOM requirements April, 2002 o RSIP server: that portion of an RSIP gateway that talks to applications using RSIP. o RSA-IP (Realm Specific Address IP) and RSAP-IP (Realm Specific Address and Port IP): RSIP distinguishes between filters that include all ports on an IP address and those that do not. o Demultiplexing Fields: Any set of packet header or payload fields that an RSIP gateway uses to route an incoming packet to an RSIP host (RSIP allows a gateway to perform, and an application to control, packet routing to hosts in the private domain based on more than just IP header fields.). o host-to-middlebox tunnels: RSIP assumes that data communicated between a private realm host and a public realm host is transferred through the private realm by a tunnel between the inner host and the middle box, where it is converted to and from native IP based communications to the public realm host. 1.4 Comparison of MIDCOM and RSIP frameworks RSIP, with tunneling, has the advantage that the public realm IP addresses and port numbers are know to the private realm host application, and therefore no translation of protocols such as SDP, the FTP control protocol, RTSP, SMIL, etc., is needed. It does however require that an RSIP server and a tunneling protocol be implemented in the middlebox and an RSIP client and the same tunneling protocol be implemented in the private realm host. The host modifications can generally be made without modification to the host application or requiring the implementation of a host application agent. This is viewed as a significant advantage over NAT (Network Address Translation). NAT requires ALGs (Application Layer Gateways) in middleboxes without MIDCOM, and application modifications or agents for middleboxes with MIDCOM. Support for NAT without tunneling could easily be added to the RSIP control protocol (NAT would be defined as a new, _null_ tunnel type.). This has the advantage over tunnels of not requiring modification to hosts, but would require the modification of host applications or the implementation of application agents, both of which would include an RSIP client, and the implementation of an RSIP server in the middlebox. Tunneled or not, ya need an RSIP / MIDCOM server in the middlebox. Tunneled, ya need to modify the host, but not the application. Untunneled, ya need to add an agent or modify the application, but not the host. Pick your poison. Renkel Internet draft [Page 4] Evaluation of RSIP against MIDCOM requirements April, 2002 2. Evaluation of RSIP against MIDCOM requirements 2.1 MIDCOM requirements met by RSIP. The following MODCOM requirements are met by RSIP. For each a short explanation is given as to how the requirement is met by RSIP. MIDCOM requirement 2.1.2: The Midcom protocol must allow a Midcom agent to communicate with more than one middlebox simultaneously. MIDCOM requirement 2.1.3: The Midcom protocol must allow a middlebox to communicate with more than one Midcom agent simultaneously. RSIP sessions are identified by their IP source and destination addresses and their TCP / UDP port numbers. Thus each RSIP client can communicate with multiple servers, and each server can communicate with multiple clients. MIDCOM requirement 2.1.4: Where a multiplicity of Midcom Agents are interacting with a given middlebox, the Midcom protocol must provide mechanisms ensuring that the overall behavior is deterministic. All RSIP requests are defined to be atomic. (Near) simultaneous requests are executed as is they were sequential. MIDCOM requirement 2.1.5: The Midcom protocol must enable the middlebox and any associated Midcom agents to establish known and stable state. This must include the case of power failure, or other failure, where the protocol must ensure that any resources used by a failed element can be released. RSIP assumes that on middlebox start-up no sessions are defined, and thus no allocations have been made. In effect, all resources are released upon restart after failure. MIDCOM requirement 2.1.6: The middlebox must be able to report its status to a Midcom agent with which it is associated. All RSIP client requests have explicit server responses. Additionally, a client may explicitly request server status using a QUERY request. MIDCOM requirement 2.1.7: The protocol must support unsolicited messages from middlebox to agent, for reporting conditions detected asynchronously at the middlebox. Renkel Internet draft [Page 5] Evaluation of RSIP against MIDCOM requirements April, 2002 An RSIP server will send an unsolicited DE_REGISTER_RESPONSE to force an RSIP host to relinquish all of its bindings and terminate its relationship with the RSIP gateway. An RSIP server can send an asynchronous ERROR_RESPONSE to indicate less severe conditions. MIDCOM requirement 2.1.9: The Midcom protocol must allow either the Midcom agent or the middlebox to terminate the Midcom session between a Midcom Agent and a middlebox. This allows either entity to close the session for maintenance, security or other reasons. An RSIP client may terminate a session with a DE-REGISTER_REQUEST. An RSIP server may terminate a session with an unsolicited DE_REGISTER_RESPONSE, and then respond to subsequent requests on the session with a REGISTER_FIRST error. MIDCOM requirement 2.1.10: A Midcom agent must be able to determine whether or not a request was successful. All RSIP requests result in a paired RSIP response if the request was successful or an ERROR_RESPONSE if the request was not successful. MIDCOM requirement 2.1.11: The Midcom protocol must contain version interworking capabilities to enable subsequent extensions to support different types of middlebox and future requirements of applications not considered at this stage. Each RSIP message contains a version parameter. MIDCOM requirement 2.1.12: It must be possible to deterministically predict the behavior of the middlebox in the presence of overlapping rules. All requests for allocation of IP addresses or ports or both that would result in rule overlap are rejected by an RSIP server with a LOCAL_ADDR_INUSE error. While this is perhaps not the desirable, intended result that the requirements authors had in mind, it is deterministic. MIDCOM requirement 2.2.1: The syntax and semantics of the Midcom protocol must be extensible to allow the requirements of future applications to be adopted. All RSIP messages consist of three mandatory fields (protocol version, message type, and message length) and a sequence of parameterType / length / value 3-tuples. New messages may be defined by defining new values for the message type field. New parameter types may be defined, and existing messages may be Renkel Internet draft [Page 6] Evaluation of RSIP against MIDCOM requirements April, 2002 extended, by defining new parameterType values. If new messages or parameters or both are added in a non-backward compatible way, a new value of the protocol version field may be defined (This may be desirable even of the additions are backward compatible.). MIDCOM requirement 2.2.4: The protocol must allow the midcom agent to extend the lifetime of an existing ruleset that otherwise would be deleted by the middlebox. A client may request an explicit lease time when a request is made to assign one or more IP addresses or ports or both. The server may grant the requested lease time, or assign one if none was requested. Subsequently, the lease time may be extended if a client's EXTEND_REQUEST is granted by the server. MIDCOM requirement 2.2.5: If a peer does not understand an option it must be clear whether the action required is to proceed without the unknown attribute being taken into account or the request is to be rejected. Where attributes may be ignored if not understood, a means may be provided to inform the client about what has been ignored. All options of all requests are fully specified. Not understood parameters must be reported by an ERROR_RESPONSE with an EXTRA_PARM error value, with the entire request otherwise ignored. MIDCOM requirement 2.2.10: When the middlebox performs a port mapping function, the protocol should allow the Midcom agent to request that a consecutive range of external port numbers be mapped to consecutive internal ports. The ports parameter of the RSIP ASSIGN_REQUESTs specifically allows multiple, consecutive port numbers to be specified. 2.2 MIDCOM requirements partially met by RSIP. The following MIDCOM requirements are partially met by RSIP. For each a short explanation is given of additions that would have to be made to RSIP to fully meet the MIDCOM requirements. MIDCOM requirement 2.1.1: The Midcom protocol must enable a Midcom agent requiring the services of a middlebox to establish an authorized association between itself and the middlebox. RSIP allows sessions to be established between middleboxes and applications and application agents. Authorization credentials would have to be added to the session establishment request to allow the middlebox to authorize the session requestor. Renkel Internet draft [Page 7] Evaluation of RSIP against MIDCOM requirements April, 2002 MIDCOM requirement 2.2.2: The Midcom protocol must support the ability of an agent to install a ruleset that governs multiple types of middlebox actions (e.g. firewall and NAT). All types of middleboxes are supported so long as the ruleset action is _permit_. Other actions would require the definition of a new RSIP message parameter with values for _permit_ and the other desired actions. MIDCOM requirement 2.2.6: To enable management systems to interact with the Midcom environment, the protocol must include failure reasons that allow the Midcom Agent behavior to be modified as a result of the information contained in the reason. Failure reasons need to be chosen such that they do not make an attack on security easier. RSIP defines a fairly large number of very specific error values. But as this requirement is not specific as to the desired agent behavior modifications, it is not possible to tell if the RSIP defined error values are sufficient or not. If for no other reason than RSIP will need new messages and parameters to be defined to be fully compliant with the MIDCOM requirements, we assume additional error values will also have to be defined. Determining in general that a particular set of failure reason makes an attack on security easier is probably unsolvable. We know of no such specific case with the RSIP error values. But please report any that you know of or discover to the authors. MIDCOM requirement 2.2.8: The Midcom protocol must be able to carry filtering rules, including but not limited to the 5-tuple, from the midcom agent to the middlebox. RSIP only supports a 4-tuple consisting of local and remote IP addresses and port numbers. The addition of a transport protocol identification is straightforward. 2.3 MIDCOM requirements NOT met by RSIP. The following MIDCOM requirements are not met by RSIP. For each a short explanation is given of additions that would have to be made to RSIP to meet the MIDCOM requirements. MIDCOM requirement 2.1.8: The Midcom protocol must provide for the mutual authentication of Midcom agent and middlebox to one another. [See MIDCOM requirement 2.3.4, below.] Renkel Internet draft [Page 8] Evaluation of RSIP against MIDCOM requirements April, 2002 MIDCOM requirement 2.2.3: The protocol must support the concept of a ruleset group comprising a multiple of individual rulesets to be treated as an aggregate. RSIP currently only allows one IP address or address and port range to be assigned to a so-called _bind-ID_. RSIP could implement rulesets as required by adding an optional bind-ID parameter to ASSIGN_REQUESTs, which would then extend an existing ruleset rather creating a new one. Similarly the FREE_REQUESTs would have to be extended by adding optional local and remote address and port parameters. MIDCOM requirement 2.2.7: The Midcom protocol must not preclude multiple authorized agents from working on the same ruleset. To simultaneously satisfy this requirement and the MIDCOM security and deterministic behavior requirements may be impossible. The splitting of a ruleset and the passing of ownership of a ruleset from one client to another should be possible consistent with security and deterministic behavior. Sans a definition of simultaneous authorization, it is not possible to qualify the effort involved in adding either of these capabilities to RSIP at this time. MIDCOM requirement 2.2.9: When the middlebox performs a port mapping function, the protocol should allow the Midcom agent to request that the external port number have the same oddity as the internal port. This would be a very easy addition to RSIP. MIDCOM requirement 2.2.11: It should be possible to define rulesets that contain a more specific filter spec than an overlapping ruleset. This should allow agents to request actions for the subset that contradict those of the overlapping set. This capability can be added to RSIP, but the authors are not convinced at this time of its desirability, especially if the rulesets do not belong to the same RSIP client. MIDCOM requirement 2.3.1: The Midcom protocol must provide for message authentication, confidentiality, and integrity. [See MIDCOM requirement 2.3.4, below.] MIDCOM requirement 2.3.2: The Midcom protocol must allow for optional confidentiality protection of control messages. If provided the mechanism should allow a choice in the algorithm to be used. Renkel Internet draft [Page 9] Evaluation of RSIP against MIDCOM requirements April, 2002 [See MIDCOM requirement 2.3.4, below.] MIDCOM requirement 2.3.3: The Midcom protocol must operate across un- trusted domains between the Midcom agent and middlebox in a secure fashion. [See MIDCOM requirement 2.3.4, below.] MIDCOM requirement 2.3.4: The Midcom protocol must define mechanisms to mitigate replay attacks on the control messages. The RSIP framework [3] says that _It is recommended that all communication between an RSIP host and gateway be authenticated. Authentication, in the form of a message hash appended to the end of each RSIP protocol packet, can serve to authenticate the RSIP host and gateway to one another, provide message integrity, and (with an anti-replay counter) avoid replay attacks_. However, the RSIP protocol does not define message hash and replay counter parameters. They would have to be added. 3. Security Considerations Security considerations for RSIP use as the basis for the MIDCOM protocol are covered by the above comparison against the specific Security requirements in the MIDCOM requirements document [1]. Renkel Internet draft [Page 10] Evaluation of RSIP against MIDCOM requirements April, 2002 4. References [1] R. Swale, P. Mart, P. Sijben, S. Brim, M. Shore, _Middlebox Communications (MIDCOM) Protocol Requirements," draft-ietf-midcom- requirements-05.txt, November, 2001. [2] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan, _Middlebox Communications Architecture and Framework,_ draft-ietf- midcom-framework-07.txt, February, 2002. [3] M. Borella, J. Lo, D. Grabelsky, G. Montenegro, _Realm Specific IP: Framework,_ IETF RFC 3102, October, 2001. [4] M. Borella, D. Grabelsky, J. Lo, K. Taniguchi, _Realm Specific IP: Protocol Specification,_ IETF RFC 3103, October, 2001. [5] G. Montenegro, M. Borella, _RSIP Support for End-to-end IPsec,_ IETF RFC 3104, October, 2001. [6] J. Kempf, G. Montenegro, _Finding an RSIP Server with SLP,_ IETF RFC 3105, October, 2001. 5. Author's Address Jim Renkel The CommWorks Corp., a 3Com company 3800 Golf Rd. Rolling Meadows, IL, USA Phone: +1.847.262.2539 Email: james_renkel@commworks.com Renkel Internet draft [Page 11] Evaluation of RSIP against MIDCOM requirements April, 2002 6. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." Renkel Internet draft [Page 12]