Internet DRAFT - draft-ivancic-layer3-encryptors
draft-ivancic-layer3-encryptors
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]
