[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IP Tunnel for LAN-to-LAN with IPSEC


Steve,
 
> 	If an IP-tunnel is appropriate for a LAN-to-LAN VPN link, then
> 	
> http://search.ietf.org/internet-drafts/draft-gupta-ipsec-remot
> e-access-00.tx
> t
> 	suggests that GRE could be used (in preference to using 
> L2TP/Layer-2
> tunnels).
> 
> 	Some form of abstraction is needed to allowing dynamic 
> routing to
> multiple 
> 	remote security gateways over a single WAN interface 
> (for example). 
> 
> 	Can I get a poll on how folk intend to implement this support?
> Currently, we 
> 	are looking to offer a GRE tunnel (RFC1701) and L2TP in 
> support of
> dynamic
> 	routing over LAN-LAN VPN links.  I am concerned that 
> there should be
> a 
> 	recommended standard way of doing this - perhaps 
> championed by the
> IPSEC
> 	WG some how.  That would make things easier at bake-offs anyway.

I think this is an important point and would suggest that 
this is a suitable work item for ipsecond. I think that the 
current IPSEC model should be extended to include its use 
as a generic tunneling protocol, where the payload is opaque 
to the particular IP network over which the tunnel is used. 
There are a few examples

- multiprotocol: an IPSEC tunnel is used to carry non-IP 
  packets that are then routed at the tunnel end-point

- opaque: an IPSEC tunnel is used to carry opaque packets 
  that are then dropped onto another link or tunnel at the 
  tunnel end-point

- disjoint IP: an IPSEC tunnel is used to carry IP packets 
  that are from a different address space to that of the
  IP backbone over which the tunnel is instantiated 
  (e.g. private address space 10.0.0.0/8)

Using GRE is one solution perhaps, but there is quite a lot 
of overhead as much of the GRE functionality is replicated 
in IPSEC itself. For example the following GRE fields have 
IPSEC equivalents.

checksum: the authentication header checks for message 
          integrity
key:      the authentication header checks for data origin 
seq num:  there is already a sequence number in the IPSEC 
          header used for anti-replay. Given that it is there, 
          it could also be used for other purposes
routing:  source routing isn't really relevant with this use 
          of GRE

This leaves the "protocol type" as the only field that carries
useful information. One option would be to encapsulate the 
frame using LLC/SNAP rather than GRE. Another would be to
signal the protocol type in the Phase 2 ISAKMP exchange 
(e.g. VC-MUX in ATM terms) and this would avoid any extra 
overhead. We are currently working on a VPN framework draft, 
which will include such a use of IPSEC tunnels. In the 
meantime people might be interested in the draft

<draft-heinanen-generic-vpn-mpls-00.txt>

which disaggregates the various components of one type of
VPN, and discusses how the same VPN functionality can be 
implemented over MPLS, and also without MPLS by using a 
generic IP tunneling mechanism. An enhanced IPSEC would 
seem a prime candidate for such a mechanism, particularly 
given that the amount of work needed is not that great. 
If anyone else is interested in generalizing the use of 
IPSEC tunneling in this manner, either for use within a 
VPN context, or some other context, let me know. 

Bryan Gleeson
Shasta Networks.