Internet Engineering Task Force MidCom WG Internet Draft P. Cordell draft-cordell-midcom-span-alt-00.txt Ridgeway Systems & Software 9 October, 2002 Expires: 9 April, 2003 Alternative Solutions for a SPAN Deliverable 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 presents and discusses alternatives to developing a custom solution for the pre-midcom SPAN deliverable (SPAN = Simple Protocol for Augmenting NATs). Such alternatives consist of protocols or techniques that have already been standardised or will soon be standardised. 1. Introduction Before embarking on a custom development for the pre-MIDCOM SPAN deliverable (SPAN = Simple Protocol for Augmenting NATs), it is worth considering what other existing (or soon to be existing) protocols might be able to provide an off the shelf solution to the problem. Cordell [Page 1] Internet Draft SPAN Alternatives September 2002 This document discusses the pros and cons of a number of candidate protocols. Currently the document draws no conclusions as it is in an early state of development. 2. L2TP - Dial in VPN L2TP [L2TP] is typically used to allow remote workers to access an enterprise network via a local dial-in POP. It effectively extends IP connectivity out from the enterprise network to the remote worker so that they have a logical presence on the enterprise network. In a SPAN scenario, a client inside an enterprise would effectively 'dial-out' to an L2TP network server (LNS) in the shared network by acting as a Client LAC. The L2TP PPP connection would acquire a public address, which the client would use to communicate with devices outside the NAT. 2.1. Pros - L2TP is already widely deployed. 2.2. Cons - Large overhead. A typical access link might involve the following layers for a media connection: PPP/IP/UDP/RTP. In the case of L2TP, this would be extended to be: PPP/IP/(UDP/L2TP/PPP/IP)/UDP/RTP. This corresponds to roughly 36 bytes of overhead per packet (UDP-8, L2TP-6/8, PPP-2, IP-20). - Allocates an entire IP address to a client rather than allocating specific ports. This is inefficient from an address allocation point of view. If addresses were abundant enough to allow for such a solution, chances are a NAT would not be required in the first place! - L2TP control channel needs to implement its own reliability mechanism complicating implementation within an application. - Would need additions to the L2TP implementation to handle NAT binding keep alive. 3. IPsec - VPN IPsec [IPSEC] can be used as a VPN solution to connect two enterprise networks together over a public network such as the Internet. The information exchanged over the IPsec connection is encrypted, but other than that it emulates a physical wire connecting the two networks. Hence, the two ends need to share the same address space, and the connection will include all traffic including such things as Cordell [Page 2] Internet Draft SPAN Alternatives September 2002 router adverts and so on. In principle an IPsec solution could be used to extend an enterprise connection out to a relay in a public network. This would be acting like a bridge out to an island in a shared space. IPsec would be used in tunnel mode and the relay would act in part like a security gateway. The IPsec tunnel would probably tunnel out a private address and the relay would NAT this to a shared address. 3.1. Pros - IPsec VPNs are already standardised and widely deployed. 3.2. Cons - IPsec has a number of problems getting through NATs [IPSECNAT] in part due to including the packet's source address (either directly, or indirectly via pseudo-header checksums) in the calculation of the AH & ESP headers. - IPsec operates below the TCP and UDP layer where ports are defined (e.g. the layering is PPP/IP/ESP/IP/UDP). This makes NAPT operation impossible. - Without additional extensive security efforts, IPsec provides IP level access, which would allow 'access all areas' type operation (including exporting of router adverts between realms). This is undesirable in this case. - Needs to be implemented in the OS (or at least below the application layer). This means that application providers do not have control of the deployment of the technology. - Will still need additional protocol mechanisms to be defined in order to acquire public addresses on the relay. - Would need additional mechanisms to handle NAT binding keep alive. 4. IP Over IP IP over IP represents a simple way to tunnel IP through an IP network. 4.1. Pros - Conceptually simple. 4.2. Cons - Would have to define an additional authentication method if the Relay needed to control who could access its services. Cordell [Page 3] Internet Draft SPAN Alternatives September 2002 - Problems working with NAPT as neither UDP nor TCP ports would be available at the right layer. - Will still need additional protocol mechanisms to be defined in order to acquire public addresses on the relay. - Would need additional mechanisms to handle NAT binding keep alive. - Would not be able to do port multiplexing. Each client would have to be allocated a separate IP address, which is inefficient. - Requires 'raw' access to the IP stack, which is not available to applications on some OSes. Even if the OS supported raw socket access, if TCP was required, this would have to be implemented in the application layer, which is undesirable. - Despite its simplicity, it still requires 20 bytes of overhead. 5. RSIP RSIP [RSIP] allows a host to acquire an IP address (and optionally ports) from a relay located in another realm. The extra address is used by an extension of the OSes IP stack to communicate with the remote realm via to tunnel to a gateway located where a NAT device is usually located. Typically the host will operate as if it is multi-homed. 5.1. Pros - Already defined as an RFC. - Can allocate a complete address to a device or just a range of ports. 5.2. Cons - Needs to be implemented in the OS. This means that application providers do not have control of the deployment of the technology. - An RSIP Gateway normally replaces a NAT rather than working through one. - Doesn't offer much in the way of authentication. - Applications need to be multi-home aware, and thus applications need to be aware of the solution even though it is principally an OS based solution. - Has no knowledge of the RTP/RTCP port pair relationship. Cordell [Page 4] Internet Draft SPAN Alternatives September 2002 6. IPv4 Version of Teredo Teredo [TEREDO] is a proposed IPv6 transition technology. It allows a host to obtain connectivity to an IPv6 network via an IPv4 network. The technique requires special Teredo IPv6 addresses, which include the IPv4 address at which the host can be contacted on the IPv4 network. 6.1. Pros - Synergy with a proposed IPv6 transition technology. 6.2. Cons - IPv6 scheme still under development. - Not clear how an IPv4 version would work as the IPv6 version depends on an IPv4 address being part of the (larger) IPv6 address. - Firewall issues are much the same as for SPAN-A [SPAN-A]. 7. Security Considerations As most of these solutions will need to traverse a firewall in addition to a NAT, security is obviously a major issue. Most of the solutions presented above provide a tunnelling mechanism through which just about any traffic may flow. This obviously makes the job of a firewall harder. More than likely a NAT traversal implementation incorporating any of the above techniques will also have to include its own firewalling functions in addition to any existing firewall. Additionally, many of the tunnelling techniques above are not associated with any particular well-known ports, which could make the job of the firewall harder (and maybe impossible). Alternatively, using an existing well-known port of one of the above techniques for a SPAN type implementation may prevent an administrator being able to block SPAN use while still enabling the functionality that the technique was originally intended for. 8. Conclusions This document is in an early stage of development and it is too early to present conclusions at this pointà 9. References [IPSEC]S. Kent & R. Atkinson, "Security Architecture for the Internet Protocol," RFC 2401, November 1998. [IPSECNAT]Bernard Aboba, William Dixon, "IPsec-NAT Compatibility Cordell [Page 5] Internet Draft SPAN Alternatives September 2002 Requirements," draft-ietf-ipsec-nat-reqts-02.txt, 18 August 2002. [L2TP]Townsley et al., "Layer Two Tunneling Protocol," RFC 2661, August 1999. [RSIP]Borella et al., "Realm Specific IP: Protocol Specification," RFC3103, October 2001. [SPAN-A]P. Cordell, "SPAN-A - Candidate A for the Pre-Midcom SPAN Protocol," draft-cordell-midcom-span-a-00, June 2002. [TEREDO]C. Huitema, "Teredo: Tunneling IPv6 over UDP through NATs," draft-ietf-ngtrans-shipworm-06, February 2002. 10. Authors' Addresses Pete Cordell Ridgeway Systems & Software 66 Suttons Business Park Reading RG6 1AZ England pcordell@ridgewaysystems.com Cordell [Page 6]