INTERNET-DRAFT Joel Tran Category: Standard Track Soumaya Cherkaoui Expires: August 2004 Universite de Sherbrooke Febuary 2004 DHCPv4 Option for Midcom Middlebox 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 Distribution of this document is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The Dynamic Host Configuration Protocol [RFC2131] provides a framework for passing configuration information to hosts on a TCP/IP network. Entities using the Midcom Protocol need to know the presence of Midcom middleboxes, such as firewalls and network address translators, in order to enable communication across theses devices. A DHCPv4 option provides a means for the entities to determine the Midcom middleboxes IPv4 address or domain name. Tran [Page 1] INTERNET-DRAFT Febuary 2004 1 Terminology Midcom agent: As defined in [RFC3303], MIDCOM agents are entities performing ALG functions, logically external to a middlebox. MIDCOM agents possess a combination of application awareness and knowledge of the middlebox function. This combination enables the agents to facilitate traversal of the middlebox by the applicationどﾖs packets. Midcom middlebox: A Midcom middlebox is a middlebox capable of performing Midcom functionnality as in [RFC3304]. Middlebox: As defined in [RFC3303], a middlebox is a network intermediate device that implements one or more of the middlebox services. A network address translation middlebox (NAT) is a middlebox implementing a NAT service. A firewall middlebox is a middlebox implementing a firewall service. In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119]. 2 Introduction Midcom as described in the RFC XXXX [MDCSEM], is a technique for dynamically configuring a middlebox. These are devices located in the path of two end-points which provide services such as firewall and network address translation. Midcom provides connectivity through Midcom middleboxes for protocols like a Session Initiation Protocol [RFC3261] which are normally broken when middleboxes are present in a network. In order to provide this connectivity, SIP entities can integrate a Midcom agent. A Midcom agent needs to know the IPv4 addresses or the domain name of the Midcom middleboxes present in the network in order to dynamically configure them. This document describes a DHCPv4 option intended for IPv4 networks which provides a means for Midcom agents to known the IPv4 addresses or the domain name of Midcom middleboxes. 3 Midcom Middlebox IP Address Midcom middlebox may have many IP addresses located in different Tran [Page 2] INTERNET-DRAFT Febuary 2004 domains as illustrated in figure 1. These addresses are defined in the Midcom semantics document [MDCSEM]. +----------+ +----------+ | internal | A0 A1 +-----------+ A2 A3 | external | | endpoint +----------+ middlebox +----------+ endpoint | +----------+ +-----------+ +----------+ Figure 1: Address tuples A0 - A3 - A0 - internal endpoint: address tuple A0 specifies a communication endpoint of a device within the internal network with respect to the middlebox. - A1 - middlebox inside address: address tuple A1 specifies a virtual communication endpoint at the middlebox within the internal network. A1 is the destination address for packets passing from the internal endpoint to the middlebox, and is the source for packets passing from the middlebox to the internal endpoint. - A2 - middlebox outside address: address tuple A2 specifies a virtual communication endpoint at the middlebox within the external network. A2 is the destination address for packets passing from the external endpoint to the middlebox, and is the source for packets passing from the middlebox to the external endpoint. - A3 - external endpoint: address tuple A3 specifies a communication endpoint of a devices within the external network with respect to the middlebox. 4 Midcom Middlebox DHCPv4 Option Code Len Enc +-----+-----+-----+--- | TBD | Len | enc | ... +-----+-----+-----+--- Figure 2: Midcom DHCPv4 option The Midcom middlebox DHCPv4 option specifies either a 32-bit (binary) IPv4 address or, preferably, a DNS, as described in [RFC1035], domain name of the Midcom middleboxes that are present in a network. This list Tran [Page 3] INTERNET-DRAFT Febuary 2004 sets the Midcom middlebox to use in order of preference. The length (Len) of the option specifies the number of octet following the Len field including the "enc" byte. If the length of the list exceeds 254 bytes, this list MUST be transmitted as specified in [RFC3396]. The code of Midcom middlebox DHCPv4 option is TBD. The Midcom middlebox DHCPv4 option has two encoding type defined by the encoding byte (どﾖencどﾖ) as illustrated in the figure 2. When enc has the value of 0, it is followed by one or more domain names of Midcom middlebox. When the enc has the value of 1, it is followed by one or more IPv4 address of Midcom middlebox. All implementations MUST support the two encodings. As describe in [RFC3361],"a DHCPv4 server MUST NOT mix the two encodings in the same DHCPv4 message, even if it sends two different instances of the same option. Attempts to do so would result in incorrect client behavior as DHCPv4 processing rules call for the concatenation of multiple instances of an option into a single option prior to processing the option [RFC3396]." 4.1 Midcom Middlebox Domain Name List Code Len enc DNS name of Midcom middlebox server +-----+-----+-----+-----+-----+-----+-----+-----+-- | 120 | n | 0 | s1 | s2 | s3 | s4 | s5 | ... +-----+-----+-----+-----+-----+-----+-----+-----+-- Figure 3: Midcom DHCPv4 option using Domain Name When the encoding used specifies Domain Name (enc byte equals to 0), the enc byte is followed by one or more Domain Name of the Midcom middleboxes as illustrated in figure 3. The Domain Name MUST be encoded following the section 3.1 of [RFC1035]: Domain names in messages are expressed in terms of a sequence of labels. Each label is represented as a one octet length field followed by that number of octets. Since every domain name ends with the null label of the root, a domain name is terminated by a length byte of zero. The high order two bits of every length octet must be zero, and the remaining six bits of the length field limit the label to 63 octets or less. To simplify implementations, the total length of a domain name (i.e., label octets and label length octets) is restricted to 255 octets or less. Tran [Page 4] INTERNET-DRAFT Febuary 2004 +---+---+---+---+---+---+---+---+---+---+---+---+ |120|46 | 0 | 8 |どﾖgどﾖ|どﾖaどﾖ|どﾖtどﾖ|どﾖeどﾖ|どﾖwどﾖ|どﾖaどﾖ|どﾖyどﾖ|どﾖ1どﾖ| +---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+ | 7 |どﾖeどﾖ|どﾖxどﾖ|どﾖaどﾖ|どﾖmどﾖ|どﾖpどﾖ|どﾖlどﾖ|どﾖeどﾖ| 3 |どﾖcどﾖ|どﾖoどﾖ|どﾖmどﾖ| 0 | +---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+ | 9 |どﾖgどﾖ|どﾖaどﾖ|どﾖtどﾖ|どﾖeどﾖ|どﾖwどﾖ|どﾖaどﾖ|どﾖyどﾖ|どﾖ2どﾖ|どﾖ2どﾖ| +---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+ | 7 |どﾖeどﾖ|どﾖxどﾖ|どﾖaどﾖ|どﾖmどﾖ|どﾖpどﾖ|どﾖlどﾖ|どﾖeどﾖ| 3 |どﾖcどﾖ|どﾖoどﾖ|どﾖmどﾖ| 0 | +---+---+---+---+---+---+---+---+---+---+---+---+---+ Figure 4: Midcom DHCPv4 option example using Domain Name As an example, the figure 4 illustrates the case where an administrator wants to offer two Midcom middleboxes ("gateway1.example.com" and "gateway22.example.com") domain name to the Midcom agent. 4.2 Midcom Middlebox IPv4 Address List Code Len Enc Address 1 Address 2 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-- | TBD | n | 1 | a1 | a2 | a3 | a4 | a1 | a2 | ... +-----+-----+-----+-----+-----+-----+-----+-----+-----+-- Figure 5: Midcom DHCPv4 option When the encoding used specifies IPv4 addresses (enc byte equals to 1), the enc byte is followed by one or more IPv4 addresses of the Midcom middleboxes as illustrated in figure 5. This option MUST have a minimum Length of 5 octets (enc byte plus IPv4 address) and it MUST always be a multiple of 4 plus one. 5 Security Considerations The security considerations in the Dynamic Host Configuration Protocol [RFC2131] apply. There is the possibility of an attack of the type "man in the middle" which can modify the response from the DHCPv4 server in order to change the Midcom middlebox address. This could lead a Midcom agent to contact a dumb middlebox and create a Denial of Service for the Midcom agent. This situation can then lead to a potential opening of a pinhole from the dumb middlebox using the information sent from the Midcom agent. Tran [Page 5] INTERNET-DRAFT Febuary 2004 6 IANA Considerations IANA has assigned the number TBD for the Midcom middlebox DHCPv4 option. 7 Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Bucknell University, March 1997. [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002. [RFC3304] Swale, R.P., Mart, P.A., Sijben, P., Brimm, S. and M. Shore, "Middlebox Communications (midcom) Protocol Requirements", RFC 3304, August 2002. [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options", RFC 3396, November 2002. [MDCSEM] Stiemerling, M., Quittek, J., Taylor, T., "MIDCOM Protocol Semantics", draft-ietf-midcom-semantics-07.txt, January, 2004. 8 Informative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3361] Schulzrinne H.. "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Tran [Page 6] INTERNET-DRAFT Febuary 2004 Servers", RFC 3361, August 2002. 9 Acknowledgments This document was based on [RFC3361] written by H. Schulzrinne. 10 Contributors Pascal Dorﾈｨ M5T Centre d'excellence en Telecom inc. Sherbrooke,Qc Canada e-mail: pdore@m5t.com http://www.m5t.com 11 Authors' Addresses Joel Tran Dept. Genie Elect. & Genie Inf./Dep. Elect. & Comp. Engineering Universite de Sherbrooke Sherbrooke,Qc Canada e-mail: Joel.Tran@USherbrooke.ca Soumaya Cherkaoui Dept. Genie Elect. & Genie Inf./Dep. Elect. & Comp. Engineering Universite de Sherbrooke Sherbrooke,Qc Canada e-mail: Soumaya.Cherkaoui@USherbrooke.ca 12 Full Copyright Statement Copyright (C) The Internet Society (2004). 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 Tran [Page 7] INTERNET-DRAFT Febuary 2004 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. Tran [Page 8]