IPSec Working Group J. Shukla Internet Draft Trlokom, Inc. Document: draft-shukla-ipsec-nat-qos-compatible- November 2000 security-00.txt Category: Experimental NGISec-NAT and QoS compatible End-to-End Secure Communication Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft 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. 1. Abstract This document outlines a new approach, called NGISec, for end-to-end secure communication system that is compatible with other networking protocols. Such a solution is needed because IPSec is incompatible with network address translation (NAT), ICMP, and QoS protocols such as differentiated services, RSVP, RED, and ECN. Most of the proposed solutions to mitigate or remove the incompatibility problems of IPSec only address a small sub-section of the problems, and proposed solutions have severe drawbacks. By using our proposed approach, one can achieve end-to-end secure communication in LANs, VPNs, and network-to-network connections. This approach can be viewed as an alternative to IPSec that solves the severe problems faced by IPSec and paves the way for simultaneous use of security and QoS services. While it is aimed to be an alternative to IPSec, it re-uses critical components of the IPSec infrastructure such as the Internet key exchange (IKE). An interesting aspect of the proposed protocol is that it also allows the use of SSL/TLS to build VPNs. Shukla Experimental - June 2001 1 NAT & QoS Compatible End-to-End Security Nov. 2000 2. Conventions Used In This Document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 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 RFC-2119 [1]. 3. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [2]. 4. Introduction Protocols such as IPSec [3] and SSL/TLS [4] can be used to provide secure communication. SSL/TLS operates at transport layer and is typically incorporated into individual applications. However, it does not support VPN functionality. IPSec, on the other hand, operates at the network layer and can provide data security without any modifications to the applications. IPSec can also be used to build VPNs. Moreover, IPSec key exchange and management system, IKE [12], is more sophisticated and is arguably the best one available. In spite of these advantages, IPSec has some very significant drawbacks such as the incompatibility with network address translation (NAT), ICMP, FTP, IKE, IP fragmentation etc. [5] [6]. There is ongoing effort in IETF to develop solutions that resolve the NAT and IPSec compatibility issues, but so far there is no solution that is completely satisfactory. Moreover, most quality of service (QoS) protocols also do not function properly with IPSec, e.g. RSVP, MPLS, RED, ECN, and differentiated services. If the incompatibility between security and QoS protocols are not resolved, it may pose a very big hindrance to adoption of IP based QoS. This document outlines a new protocol, called NGISec, that can reuse the IPSec infrastructure and solve the incompatibility problem with NAT, ICMP, and QoS protocols. The proposed protocol can be used for security in LANs, VPNs, and network-to-network connections. The resistance to packet tempering provided by this protocol is better than SSL/TLS and comparable to IPSec. This protocol enables the end hosts to assume the majority of encryption related tasks, thereby reducing the load on the gateways/routers. While the proposed protocol is aimed to be a replacement for IPSec, it can also enable Shukla Experimental - June 2001 2 NAT & QoS Compatible End-to-End Security Nov. 2000 the use of SSL/TLS in building VPNs and make it a viable alternative to IPSec. 5. Existing Solutions There are several approaches that have been proposed to establish compatibility between IPSec and other protocols. Most of these solutions only focus on the IPSec and NAT incompatibility problem. These solutions have drawbacks such as conflicts with other protocols and increased complexity. Solutions to ensure IPSec and QoS compatibility are also being proposed, but even those are limited to a particular QoS protocol, RSVP [RSVP IPSec extensions]. As of now there is no single solution that solves the incompatibility of IPSec with QoS protocols and NAT. In the following sections, we describe the existing solutions that attempt to make IPSec compatible with other protocols. The aim of this section is to demonstrate that in order to achieve compatibility with networking and QoS protocols IPSec needs multiple fixes that are complex. Even then these fixes are not able to solve the problems completely. 5.1 Real-Specific IP (RSIP) for IPSec and NAT Compatibility RSIP approach to solve the NAT and IPSec incompatibility problem is based on the concept that two hosts, in two different private domains, can obtain temporary IP addresses to tunnel the IP packets to their proper destination [7]. While using RSIP, the end hosts have to keep track of local and non- local hosts in order not to use RSIP when communicating with the local hosts. Scalability of RSIP is not very well understood and is not expected to be very good as many end hosts share limited resources. The extreme compute and resource intensive nature of this protocol is another serious concern that will hinder its scalability. Since many different hosts may share the available public IP address, it creates an ambiguity for ICMP messages. Similarly IP packets fragments by intermediate routers may face an ambiguity in assembly. 5.2 UDP Encapsulation for IPSec and NAT Compatibility The IPSec encapsulated security payload (ESP) is encapsulated by a UDP header [8]. This allows the ESP traffic to pass through NAT, without being affected by it. This approach has the potential to work fine in a network-to-network connection, but there are problems in this solution. In a client to gateway connection (a special case Shukla Experimental - June 2001 3 NAT & QoS Compatible End-to-End Security Nov. 2000 of network-to-network connection), the gateway must provide the client with a suitable address so that it does not have to perform NAT on the contained packets (incoming packet is ESPUDP tunnel packet). This is extra overhead. As pointed out by the authors, there is a possibility that two clients may negotiate entries that overlap and that would create confusion for outgoing packets at the gateway. Same problem appears in VPNs as well where the two gateways must work together to give the client a suitable address. This is similar to RSIP approach, but a bit more complicated and has extra overhead of an IP header and a UDP header. 5.3 Built-In NAT for IPSec and NAT Compatibility Built-In host NAT implementation is necessary for some tunnel mode and all transport mode IPSec. If NAT functionality is built-in and IPSec is implemented after NAT is done then we can have end-to-end secure communication system that is NAT compatible [9]. In this approach there is a need for protecting IPSec SA traffic from NAT. This is achieved by using an IKE probe to detect NAT presence, and then encapsulating the IPSec SA traffic to protect it from NAT. NAT translation keepalive heartbeat are used to maintain NAT mappings. The drawbacks of this approach are that it will require modifications to existing NAT implementations, and will have overhead in book-keeping to ensure that no two hosts use the same port number. Additional overhead comes in the form of keepalive heartbeat. If the IP packet is fragmented, there is ambiguity about the end-host it should be sent to. Even though we achieve NAT compatibility, this solution does not solve the IPSec incompatibility with ICMP and other QoS protocols. 5.4 Layer Two Tunneling for IPSec and NAT Compatibility Layer two tunneling builds an L2TP tunnel between itself and the NAT box. The NAT then sends a dynamically allocated global IP address through the tunnel. The host uses the globally valid IP address to achieve end-to-end IPSec, bypassing the NAT function. This approach has increased overhead of establishing tunnel between end-host and gateway, dynamic IP address management, and need for layer-2 tunneling capability. This adds a significant amount of overhead to the NAT box. Moreover, the NAT box becomes the single source of access and hot standbys may be problematic because the tunnel configuration may be difficult to transfer. Shukla Experimental - June 2001 4 NAT & QoS Compatible End-to-End Security Nov. 2000 5.5 RSVP IPSec Extensions for IPSec and RSVP Compatibility The RSVP protocols can be extended to use the IPSec AH or ESP header to support the individual data flow, instead of using the port numbers [10]. This approach works wells if each flow has a unique security association, but does not work when many flows share SAs, e.g. VPNs. 5.6 IIPtran for IPSec and Dynamic Routing Compatibility Tunnel mode of IPSec is used for VPNs, which complicates the dynamic routing in VPNs by linking security association selection with route selection. This problem can be solved by separating the tunnel encapsulation of the IP packet from IPSec processing [11]. The tunnel header is determined by the source header, and the security association is determined by the tunnel header. This we have a solution that is consistent with dynamic routing. While IIPtran is a way to solve the dynamic routing problem in VPNs, it does nothing to solve the IPSec incompatibility problem with NAT and QoS protocols. 6. Our Solution Our solution is geared towards achieving two goals. First, ensuring compatibility of the security protocol with other protocols such as NAT, ICMP, and QoS protocols. Second, make it possible for the end- host to perform the bulk of encryption related tasks. The solutions for the two problems are very closely related. In our proposed protocol, a transport and the IP layer header of an IP packet are visible in the clear, which is a minimum requirement for compatibility with NAT. The encrypted payload is the transport layer data, with or without the transport layer header. If the transport layer header is part of the encrypted payload, then a new transport layer header is added. Since in applications like FTP, even the body of certain control messages is affected by NAT and must be visible in the clear. We treat all control messages or packets differently from the data packets. Control packets are the TCP (SYN = 1) or UDP (first packet) packets that signify the beginning of a connection, or the control packets of an FTP connection. The control packets are decrypted at the gateways and re-encrypted after NAT to achieve complete compatibility with NAT. Since control packets are few compared to the data packets, this does not put too much burden on the gateway. The data packets are encrypted at the end hosts and are not decrypted at the gateways. Because the IP and transport layer Shukla Experimental - June 2001 5 NAT & QoS Compatible End-to-End Security Nov. 2000 headers are visible in data packets also, they maintain compatibility with NAT, ICMP and QoS protocols. In addition to making all/part of the IP packet visible in the clear so that NAT can function properly, there are situations that require complete or partial reversal of the effect of NAT on an IP packet. For example, NAT uses IP masquerading to hide the local source IP address by changing the source IP address and the port number, but a VPN connection requires that the end host are able to see each others internal IP address. Internet key exchange (IKE)[12] requires that node identifiers (which can be IP address or port numbers) must not be changed as they are protected by a secure hash. Therefore, a mechanism to counter full/part of the effect of NAT on the packet is required. We solve this problem by duplicating the information affected by NAT in the control IP packets. The information can be duplicated by encapsulating the original IP packet with extra headers (IP, transport, and other higher networking layers) or by appending the headers to the IP packet. Generalization of this concept includes appending or including the information in the IP packet in any format. By comparing the modified and original information, the receiving host/gateway can learn about the effect of NAT on IP packets. Subsequently, they can reverse the effect of NAT on packets that do not contain that information in duplicate. Unlike TCP, which is connection oriented, UDP does not have control packets for establishing a connection. Therefore, the first packet in a UDP connection is treated similar to the control packets in a TCP connection. Typically separate secure channels are used for communicating the control and data packets because the control packets are decrypted at the gateways. This creates extra overhead of establishing security associations and key exchange for the control packets, but is necessary for end-to-end secure communication over the public networks. Since the control packets are few compared to data packets, using a single secure channel for all control packets communication between two hosts can mitigate the extra overhead. In LANs it is possible to use the same secure channel for both because the gateways do not affect these packets. There are three possible cases that can be envisioned in end-to-end secure communication systems: 1) The end-hosts are on the same LAN. This is the "LAN security" case. Shukla Experimental - June 2001 6 NAT & QoS Compatible End-to-End Security Nov. 2000 2) The end-hosts are on different LANs, but should be able to see the private IP address of each other. This is the "VPN" case. 3) The end-hosts are on different LANs and must not be able to see the private IP address of each other. This is the "network-to- network" case. Our solution is designed to work for all three possible cases. 6.1 LAN Security Case In the first case, when the two hosts are on the same LAN there will not be a NAT between the two hosts. If a secure channel to communicate the control packets does not exist between the two end hosts, the initiator end host will initiate a key exchange upon encountering a control packet. Another key exchange, for the data packets of that connection may be initiated at that time or after the connection is established, i.e., a control packet is received in response to the one that was sent. After establishing the security associations and cryptographic keys, the end hosts can encrypt all data packets before transmitting it. The packet gets decrypted when it reaches the destination, thus we have established an end-to-end secure communication in a LAN. 6.2 VPN Case In the second case, the two end hosts are on different LANs, but must be able to see each other's private IP addresses. We add extra transport and IP layer header to the packet so that one set of headers is not affected by NAT. The duplicate headers either encapsulate the old packet or are appended to it (Figure 1). NAT performs the IP address and port number translation on the outer IP and transport layer headers while leaving the original or duplicate header untouched. In case of applications like FTP, we would have to duplicate the transport layer data as well if the extra headers encapsulate the original packet. After NAT is performed, the packet is encrypted and sent to the destination gateway. When this packet reaches the destination gateway, the destination gateway decrypts the packet and generates the two 4-tuples of source/destination IP/port numbers from the outer and inner headers. Subsequent data packets need not have extra IP and transport layer headers like the control packets. These data packets are encrypted at the source host and NATed at the source gateway. The destination gateway performs the reverse NAT by comparing the stored 4-tuple pairs with the 4-tuple obtained from the header of the incoming packet. In this scheme, for every connection, the gateway is involved only in the encryption and decryption of the first/control Shukla Experimental - June 2001 7 NAT & QoS Compatible End-to-End Security Nov. 2000 packets. After that all the encryption and decryption is done by the end-hosts and the gateway only performs NAT or reverse NAT. Original IP packet +---------------------------------+ | IP | Transport | Transport | | header | header | data | +---------------------------------+ Encapsulated IP packet with extra headers +-------------------------------------------------------+ | IP | Transport | IP | Transport | Transport | | header | header | header | header | data | +-------------------------------------------------------+ After encryption +------------------------------------------------------------------+ | IP | Transport | AH | ESP | IP | Transport | Transport| | header | header | | header | header | header | data | +------------------------------------------------------------------+ IP packet with appended headers +-------------------------------------------------------+ | IP | Transport | Transport | IP | Transport | | header | data | header | header | header | +-------------------------------------------------------+ After encryption +------------------------------------------------------------------+ | IP | Transport | AH | ESP | Transport | IP | Transport| | header | data | | header | header | header | header | +------------------------------------------------------------------+ Figure 1: Duplication of the information altered by NAT in an IP packet. This method works even when the gateways have non-static port mapping, i.e., the source port number in the data packet may be suddenly changed by the gateway. This could be a problem for connectionless transport layer protocols like the UDP. The gateway cannot change the source port number in a TCP connection and non- static port mapping is not a problem for end-to-end secure TCP connection. This however, has no adverse affect in my method. If the gateway decides to remove the mapping for a particular secure connection or stream, then the next packet from that stream will automatically trigger the response that gateway has for the first or control packet of any connection. The packet will have extra IP and Shukla Experimental - June 2001 8 NAT & QoS Compatible End-to-End Security Nov. 2000 transport layer headers added to it, NATed, encrypted, and sent over the receiving gateway. The receiving gateway will decrypt the packet, update the 4-tuple pair, and send it to end host. This way we do not have to include a separate mechanism to keep alive the NAT entries. While IPSec tunnel mode has overhead of an extra IP header to achieve VPN functionality, we do not add extra IP header to data packets. This results into bandwidth saving that could be important for IPv6. In IPv6 the IP header is 320 bits long and adding an extra IP header could potentially waste a lot of bandwidth. Most of the packets on the Internet today (~50%) are less than 128 bytes in length and an extra IP header (320 bits or 40 bytes) is an overhead that cannot be dismissed easily. 6.3 Network-to-Network case In the third case, the two hosts are on different LANs and each LAN has a NAT equipped gateway that the IP packets must traverse. The gateways modify the IP addresses and port numbers of the incoming/outgoing IP packets. For NAT compatible end-to-end secure communication, the control packets sent by the end hosts to their local gateways are decrypted, NATed, and re-encrypted with the security associations and keys shared by the gateways. At the receiving gateways the control packets are decrypted, NATed, and encrypted with the SAs and keys that the receiving gateway and end host share. For the data packets, the gateways only perform the NAT operation and we have achieved end-to-end secure network-to-network connection that is NAT compatible. The key exchange, for the data stream, between the two end hosts is more complex. For example, if we use IKE, the end hosts cannot pass their IP addresses or port numbers as node identifiers because NAT traversal will require modifications to the body of the message, which is protected by a hash. A possible solution is that the gateways perform the key exchange and then share them with the end host. This is cumbersome and has a potential of significantly increasing the load on the gateways. It also requires that part of the packet affected by NAT must not be included in the AH and may not work in case of non-static port mapping. In our method, we can use the port numbers as node identifiers and the end hosts can perform the key exchange. In the first approach, we duplicate the port number information in the control packets by adding extra transport layer header. The end Shukla Experimental - June 2001 9 NAT & QoS Compatible End-to-End Security Nov. 2000 host can learn about the effect of NAT on the connection and can reverse it for subsequent packets where the information is not duplicated. This is similar to the VPN approach (Figure 1), except only the transport layer header is duplicated and not the IP layer header. An alternative approach is to encapsulate the transport layer data and header with another transport layer header in order to protect it from NAT. This type of packet format is called "TCPSec" or "UDPSec" (Figure 2).Now only the outer transport layer header will get modified while the internal transport layer data and packet will be left intact. The receiving host uses the port numbers from the inner transport layer header, which are static and known, as the node identifiers in IKE based key exchange. The receiving end host maintains a 3-tuple pair of source IP address and source/destination port numbers from the two transport layer headers. This 3-tuple is used to correct the port numbers of the outgoing packets. After the key exchange in done, the data packets are encrypted using the SAs and keys shared by the end hosts. The two gateways only perform NAT on these packets. The data packets are decrypted at the receiving end host and we have end-to-end security for control and data packets. Original IP packet +---------------------------------+ | IP | Transport | Transport | | header | header | data | +---------------------------------+ TCPSec packet with extra transport layer header +---------------------------------------------+ | IP | Transport | Transport | Transport | | header | header | header | data | +---------------------------------------------+ TCPSec packet after encryption +-----------------------------------------------------------+ | IP | Transport | AH | ESP | Transport | Transport | | header | header | | header | header | data | +-----------------------------------------------------------+ Figure 2:TCPSec packet crafted by adding an extra transport layer header. The extra header can be used to either protect the original transport layer header from NAT or to protect the tempering with the transport layer header. Shukla Experimental - June 2001 10 NAT & QoS Compatible End-to-End Security Nov. 2000 7. SSL/TLS Based VPNs SSL/TLS have not been used to build VPNs because they do not have a mechanism where the IP packets can traverse the Internet and reach their destination while keeping the private IP addresses. IPSec solves this problem by using a tunnel where the original IP packet (which cannot traverse the Internet) is encapsulated by a new IP header to traverse on the Internet. Our protocols can enable the use of SSL/TLS in building VPNs and make it a viable alternative to IPSec. In our approach, the IP packets will go through the NAT which will replace their private IP address with a public IP address. In the first packet of the connection, we will duplicate the information that gets modified by the NAT. The duplicate information remains unaffected by the NAT. When this packet reaches the destination, the gateway or the end host there can learn about the effect of NAT on the connection. For subsequent packets, the receiving gateway/host can reverse the effect of NAT. Hence we have achieved VPN functionality in SSL/TLS. 8. Intellectual Property Statement Trlokom Corp has a patent application that covers this technology. If this technology is accepted in the IETF standards track, Trlokom is willing to seek a licensing agreement form the top large volume vendors that allows widespread use of this technology. For non- commercial use, we are willing to give this technology free of royalty. 9. Security Considerations Since the proposed protocol can use IKE for key exchange, the resistance to DoS attacks during the key exchange is identical to IPSec. For, the data packets, the resistance to DoS attacks is also good since the protocol helps prevent any tempering to the packet. The port numbers in the transport layer headers are protected by the AH. Even the source and destination IP addresses are protected indirectly as the TCP checksum includes them and is part of the AH. Additional processing to re-craft the data packet is not a possible venue for a DoS attack because the overhead for it is low and the packet is authenticated before it is re-crafted. In moving the encryption tasks to the end-host we are faced with additional complexity in enforcing the security policies. The gateways are only involved in the secure exchange of the control Shukla Experimental - June 2001 11 NAT & QoS Compatible End-to-End Security Nov. 2000 packets and may not necessarily have all the information about the security policies followed in securing the data packets. However, this is not unique to our solution, but is a common characteristic of solutions where the end host, and not the gateway, is responsible for data security. Content filtering programs installed at the gateways may not function properly as the data packets are not decrypted there. For proper functioning, these programs must be installed on the end hosts. The gateways will be able to determine the type of connection and the destination, and that in itself may be sufficient for a rudimentary packet monitoring program. "Intrusion detection" mechanisms will work better with this protocol than with IPSec. For example, a simple intrusion detection for DoS attacks may monitor the frequency of TCP control packets. Such a tool would fail if IPSec is used. 10 References 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 2 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997 3 Security Architecture for Internet Protocol (IPSec) - RFC 2401 4 The Transport Layer Security (TLS) Protocol Version 1.0 - RFC 2246 5 Holdrege, M., "Protocol Complications with the IP Network Address Translator", INTERNET DRAFT, , July 2000. 6 Aboba, B., "NAT and IPSec", INTERNET DRAFT, , July 2000. 7 Borella, M., Lo, J., Grabelsky, D., Montenegro, G., "Real Specific IP: Framework", INTERNET DRAFT, , July 2000. 8 Huttunen, A., Sierwald, J., "ESP Encapsulation in UDP Packets", INTERNET DRAFT, September 2000. Shukla Experimental - June 2001 12 NAT & QoS Compatible End-to-End Security Nov. 2000 9 Stenberg, M., Paavolainen, S., Ylonen, T., Kivinen, T., "IPSec NAT-Traversal", INTERNET DRAFT, , July 2000. 10 Berger, L., "RSVP Extensions for IPSec Data Flows", RFC2207, September 1997. 11 Touch, J., Eggert, L., "User of IPSec Transport Mode for Virtual Private Networks", INTERNET DRAFT, March 2000. 12 The Internet Key Exchange (IKE). D. Harkins, D. Carrel. November 1998: RFC2409. Shukla Experimental - June 2001 13 11 Acknowledgements This work was partially supported by the DARPA contract DAAH-01-00- C-R153. Author's Address Jayant Shukla Trlokom, Inc. 124 Vista Circle Drive Sierra Madre, CA 91024 USA Phone: 626-836-5545 Email: jshukla@trlokom.com Shukla Experimental - June 2001 14 NAT & QoS Compatible End-to-End Security Nov. 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). 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. Shukla Experimental - June 2001 15