Internet DRAFT - draft-cordell-midcom-span-alt
draft-cordell-midcom-span-alt
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]
