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

RE: IPSEC tunnels for LAN-to-LAN interop issue


Well, 1) still seems more 'natural'.  IPIP tunnel device does its job of
adding a tunnel header, and then forwards the new packet.  IPSEC intercepts
the packet and applies transport mode because it is now an originating
packet. 


2) is a hack because I no longer have an interface. IPSEC intercepts packet
leaving the system, and, due to the fact that the contents is completely
scrambled has to add a new header. 

The IPSEC-tunnel approach is a good model for client access, where no
interface (interface MIB entry) is required, but when to want to run routing
over an interface, it is not so useful:

LAN-LAN routing model:

Virtual IP Interface (with Intranet address, RIP enabled)
  |
Tunnel 'device' - any IP-capable tunnel you like (L2TP, GRE, IPIP, others)
  |
Real IP Interface with SPD applied
  |
Internet Interface


The virtual IP interface appears in the Interface MIB table. The Tunnel
device appears in the Interface MIB table, with an associated Tunnel MIB
entry.

A packet arrives on some 'private' interface. It is forwarded by a routing
look-up to the Virtual IP interface, from there to the lower data-link - the
tunnel device - which does whatever that tunnel device does. The resulting
IP packet is then put through the forwarding route engine again to be queued
to a 'real' IP interface, where an IPSEC SPD policy matches the packet and
applies transport-mode to protect originating traffic. The packet then
proceeds to the PPP datalink, and out into the Internet.

This is the model required to protect L2TP tunnels, and, I think, should be
a supported way to protect all IP-capable tunnels.

The question is - does anyone else support it?  Can I hear from folk that
can support routing over multiple tunnels (including L2TP and IPIP tunnels)
with some indication on which model is used - so we can interop at some
future bake-off that may cover this?

Thanks, Steve.





-----Original Message-----
From: Richard Draves [mailto:richdr@microsoft.com]
Sent: Thursday, August 26, 1999 7:25 PM
To: 'Waters, Stephen'; ipsec@lists.tislabs.com
Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue


> 1) IP tunnel device tunnels packets, IPSEC then applies transport-mode
> protection to the IP-in-IP packets as they leave.
>  
> 2) IPSEC tunnel is modeled as an interface, and just 
> negotiates tunnel mode
> and exposes the resulting tunnel as an interface. This is 
> akin to marrying
> an SDP policy with an Interface.
>  
> 3) IP tunnel device tunnels packets, IPSEC then applies tunnel mode
> protection.

What matters is how this looks to the other end of the tunnel. Your
implementation can achieve that result however it wants.

To the other end of the tunnel, shouldn't it look like / be negotiated as
tunnel-mode IPSEC? Thus if I understand your options correctly,
option 1 is ruled out because the packets look right on the wire but it's
negotiating transport-mode instead of tunnel-mode.
option 2 is OK - the packets look like IP-IPsec-IP-Transport, and it's
negotiated as tunnel-mode.
option 3 is ruled out because there is an extra IP header.

Rich
Follow-Ups: