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

Re: a simple question, I hope. Why do we need tunnel mode?

Stephen Waters <Stephen.Waters@digital.com> writes:
> 
> I have read most of the IPSEC drafts now, and I am still not sure why
> there is this distinction between 'tunnel mode' and 'transport mode'.
> 
> If you consider life before IPSEC,  to connect two routers over a
> foreign network requires some 'encapsulation'.  If that foreign network
> is the Internet,  the encapsulation required is an IP header.  If you
> are connecting sections of your Intranet together,  this IP
> encapsulation constitutes and IP-IP 'tunnel'.
> 
> Assuming your IP tunnel is in place,  the IP forwarding function in a
> router perceives these IP-in-IP packets as sourced datagrams and then
> applies 'transport mode' security to protect the packet (if required by
> the SPD).
> 
> Is there room for breaking-out the tunnel requirement here?  If I want a
> router to support L2TP-over-IP and IP-IP tunnels, and I want both to be
> secure,  why can't I just use 'transport mode' security to do that?
> 
> So, could IPSEC always be node-to-node/transport-mode - even if the node
> is a router.  
> 
> I could see no protocol difference in the AH draft for not doing this.  
> 
> On this topic,  I'd like to use ESP and AH on the exchanges between my
> routers and the architecture does not support that for 'tunnel mode' (in
> the version I looked at any way).  If I treat everything as
> transport-mode as a true IPSEC BITS/BITL, I could do that.

It doesn't explicitly support it, because the case you describe is not
using the precise language.  You would apply ESP in tunnel mode, then
looking at the packet, you no longer have an object which begins with
two IP headers, so you could only apply AH in transport mode:

IP Data 
IP ESP IP Data (apply ESP in tunnel mode)
IP AH ESP IP Data (apply AH in transport mode)

This is what I do in my implementation.  ISAKMP can be used to
negotiate this by negotiating a pair of SA's in a single Quick Mode
exchange: the first an AH with an Encapsulation Mode attribute of
transport, the second an ESP with an Encapsulation Mode attribute of
tunnel.  I suggested this to the list a while ago and didn't meet any
criticism, but didn't seem to have elicited changes to the documents.

Since language describing such a situation doesn't exist in the DOI,
I'd suggest that anyone interested in implementing this encapsulation
technique use the ISAKMP negotiation I've outlined above.

> One vote for untangling tunneling from IPSEC. What is probably missing
> is a decent IP tunnel draft, to cover multi-protocol for in a standard
> way!

I'd like to see the same.  I really don't see any necessity to
re-define IP-in-IP encapsulation (a reason I still prefer RFC1825).


ben
References: