Internet Draft W. Ivancic Document: draft-ivancic-layer3-encryptors-00.txt NASA Expires: February 2004 D. Stewart Verizon August 2003 Use And Implementation of Layer-3 Encryption Devices 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 describes some issues related to performing encryption at layer-3. In particular, routing protocol problems may result if the time-to-live (TTL) field in IPv4 or the Hop Limit field in IPv6 is decremented once before encapsulation [1][2]. Also, special provisions may be necessary within the encryptor devices if broadcast messages are to transition the encryptor pairs. Maximum Transmission Unit (MTU) issues are also presented. Ivancic Expires û January 2004 [Page 1] Use And Implementation of Layer-3 Encryption Devices August 2003 Table of Contents 1. Overview......................................................2 2. Terminology...................................................2 3. Limit field Time-to-Live and Hop Limit........................3 3.1 Known problems............................................3 4. Broadcast Messages............................................4 5. Path Maximum Transmission Unit Discovery......................4 6. Recommendations to Encryptor Designers........................4 7. Recommendations to Encryptor Users (Deployment)...............5 8. Security Considerations.......................................5 References.......................................................6 Author's Addresses...............................................6 1. Overview This document is information and intended for two audiences: encryptor developers and encryptor users. Layer-3 encryption developers need to be aware of potential problems that may arise when attempting to encrypt routing and mobile-ip protocols. Layer-3 encryptor users need to be aware of potential problems that my result when deploying layer-3 encryption for routing and mobile- ip protocols. Those who implement secure networks often have to compromise standard and recommended practices in order to obtain the desired security. Often, layer-3 encryption devices are mandated, but a layer-2 ôbump in the wireö encryption that performs bridging is the desired consequence. Thus, great care must be taken when deploying layer-3 encryption devices to ensure that the network operates in the desired manner. The United States National Security Agency(NSA)is currently developing a High Assurance Internet Protocol Encryptor System (HAIPES) specification. HAIPE is the government's version of IPSec and thus, has the same problems and issues as IPSec when performing IP-in-IP tunneling. HAIPE will work across wireless and wired networks, handling key exchange, authentication and encryption. It will be designed to work with secret algorithms written by the government, but might be flexible enough to swap in published, unclassified ones. 2. Terminology IPSEC describes two packet formats for ESP mode [3]: Ivancic Expires - February 2004 [Page 2] Use And Implementation of Layer-3 Encryption Devices August 2003 1) Transport Mode - the data portion of the IP packet is encrypted and the IP header is left intact. 2) Tunnel Mode - the entire IP packet is encrypted and encapsulated inside another IP packet. The HAIPE Specification describes two packet formats: 1) Tactical Mode - the data portion of the IP packet is encrypted and the IP header is left intact. 2) Strategic Mode - the entire IP packet is encrypted and encapsulated inside another IP packet. Thus, the HAIPE term "Tactical mode" is equivalent to IPSec ôTransport Mode.ö And the HAIPE term "Strategic mode" is equivalent to IPSec ôTunnel Mode.ö Two new terms are introduced to describe the placement of the encryptors: Encrypted LAN and Encrypted WAN. There are legitimate instances where users wish to encapsulate routing protocols or any communication off of a local area network (LAN) into a secure packet for transmission through the open Internet. We shall refer to this topology as ôEncrypted LANö [Figure 1]. Here, the ôWANö may be a radio link, a link through and Intranet, or a link over the Internet. LAN<-->encryptor<-->Router<-->(WAN)<-->Router<-->encryptor<-->LAN [Figure 1] One may need to ensure all router interfaces are protected. We shall refer to this as ôEncrypted WANö [Figure 2]. Router<-->encryptor<-->(WAN)<-->encryptor<-->Router [Figure 2] 3. Limit field Time-to-Live and Hop Limit Many routing protocols specify that the TTL field in IPv4 or Hop Limit field in IPv6 be set to one. Since each router decrements the TTL field, this ensures that routing protocols will not be passed beyond the directly attached router. 3.1 Known problems IPSec states that a device acting as a secure gateway (as the encryptors are in both topologies illustrated in figures 1 and 2) Ivancic Expires - February 2004 [Page 3] Use And Implementation of Layer-3 Encryption Devices August 2003 should always use tunnel mode for traffic that does not originate from the secure gateway. Transport mode should only be used for communication between secure gateways(traffic that originates from the secure gateway, like management, maintenance, etc.) Encapsulation as specified by RFC 1853 states ôThe inner TTL is decremented once before encapsulation, and is not affected by decapsulation.ö Thus, when a layer-3 encryption device strictly adheres to the IP Tunneling specification, all protocols that utilize a TTL or Hop Limit of 1 will not pass through the encryptor pair. The following is a list of some known protocols that may have problems passing through layer-3 encryption devices: RFC 1058 Routing Information Protocol RFC 1732 RIP Version 2 RFC 2328 OSPF Version 2 RFC 2740 OSPF for IPv6 RFC 2236 Internet Group Management Protocol RFC 3220 IP Mobility Support for IPv4 RFC 1256 ICMP Router Discovery Messages 4. Broadcast Messages Broadcast messages are not designed to be transmitted off of the local network, the broadcast network. If one wishes to extend the network via encryption devices, the broadcast messages must be passed through the encryptors. Layer-3 encryptors are often implemented as pseudo-routers; thereby requiring special provision to be made to pass broadcast messages. 5. Path Maximum Transmission Unit Discovery Mobile LANs that are protected by an encryption unit (figure 1) will not interact with routers on the encrypted portion of the network. This precludes path Maximum Transmission Unit(MTU)discovery [4] from operating properly and may result in improper operation of applications on the protected LAN. When using mobile-ip and mobile networks, the problem can get worse due to multiple layers of tunnels. 6. Recommendations to Encryptor Designers For protocols that have the TTL or Hop Limit fields set to 1, these fields SHOULD NOT be decremented for routing protocols if one desires to pass that protocol through the encryptor. Ivancic Expires - February 2004 [Page 4] Use And Implementation of Layer-3 Encryption Devices August 2003 It is desirable to be able to select which protocols are passed through the encryptor as a configuration parameter. If one wishes to pass broadcast messages between encryptors, some type of static source routing may be necessary in order for broadcasts to be directed out the proper interface otherwise routing loops may occur. It is desirable to implement proxy Address Resolution Protocol on the Clear Text (Red or Unencrypted) interface when passing routing protocols through encryptors û particularly if hosts as well as routers reside on each portion of the network [Figure 3]. Network 10.1.1.0/24 Red (Unencrypted) Black (Encrypted) Red (Unencrypted) Router <-+-> encryptor <-> Internet <-> encryptor <-+-> Router 10.1.1.1 | | 10.1.1.129 Host <-| |-> Host 10.1.1.2 | | 10.1.1.130 Host <-| |-> Host 10.1.1.3 10.1.1.131 [Figure 3] In order to avoid problems related to path MTU discovery the capability to setting the MTU on the Red (Unencrypted) interface of the encryption unit SHOULD be provided. 7. Recommendations to Encryptor Users (Deployment) Use of multicast addressing versus broadcast addressing may simplify configuration of the encryptor pair. Caution should be exercised when passing routing protocols through encryptors û particularly if hosts as well as routers reside on each portion of the same network. 8. Security Considerations Caution is advised when configuring any encryption device. Encryption devices are usually defaulted to fail-safe such that only information that is purposefully configured to pass through the encryptor will be transmitted or received. This document is informational in nature and does not require changes to protocols. Therefore, it does not introduce any additional security requirements. Ivancic Expires - February 2004 [Page 5] Use And Implementation of Layer-3 Encryption Devices August 2003 References [1] RFC 1853 W. Simpson, ôIP in IP Tunnelingö, RFC 1853, October 1995 [2] RFC 2473 A. Conta, ôGeneric Packet Tunneling in IPv6ö, December 1998 [3] RFC 2406 S. Kent, R. Atkinson, ôIP Encapsulating Security Payload (ESP), November 1998 [4] RFC 1191 J. Mogul, S. Deering, ôPath MTU Discoveryö, November 1990 Author's Addresses Will Ivancic NASA Glenn Research Center 21000 Brookpark Road MS 54-5 Cleveland, OH. USA Phone: 1-216-433-3494 Email: wivancic@grc.nasa.gov Dave Stewart Verizon Federal Systems 21000 Brookpark Road Cleveland, OH. USA Phone: 1-216-433-9644 Email: dstewart@grc.nasa.gov Ivancic Expires - February 2004 [Page 6]