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

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

I can appreciate how 'ACL-routing' can provide traffic selection with IPSEC,
but I can't model an routing interface (RIP instance) onto IPSEC without
separating the IPIP tunnel part into a device, and then protecting that with
transport-mode (or tunnel mode - but that adds too many headers).

Yes, the traffic protected across this LAN-LAN tunnels covers all traffic
that the IP tunnel was willing to encapsulate - it make negotiating the
IPSEC selectors nice and easy :) If you want to exclude traffic inbound or
outbound, you can use standard packet filtering on the Virtual IP/routing
interface 'above' the IPIP tunnel - these packet filters are capable of
expressing far more sophisticated filters than can be expressed by an IPSEC
tunnel anyway.

If the alternative is to specify an IPSEC policy/tunnel that uses 'Intranet
selectors', what will those selectors say?  I am running routing because I
want to discover what is there, not have to define it up front. To discover
and use, the IPSEC-tunnel policy would need to be wide-open, and then we are
back to the same place of having a single 'pipe' to a remote router.

The [IPIP tunnel+tranposrt-mode IPSEC] model could be used to remove the
need to negotiate payload description in IKE at all, and could also remove
the need to define an SPD. If the peer address on the IPIP tunnel is unique
(for most cases, this is true), you can run with no configured SPD, and, IKE
permitting, you arrange a transport-mode pipe between a unique src/dest
defaulting to the addresses specified on the IKE packets.

For sites that you do not want to exchange routing with (SOHO, extranet) and
for client access (don't even want an interface for these), then
'ACL-routing' is fine. 

I'm open minded (I hope) on this, I just want LAN-LAN routing to interop. If
someone can model an IPSEC-tunnel policy approach that works as a routing
interface, I'm happy to go along.

Cheers, Steve.


-----Original Message-----
From: Dan Harkins [mailto:dharkins@network-alchemy.com]
Sent: Thursday, August 26, 1999 10:01 PM
To: Lars Eggert
Cc: ipsec@lists.tislabs.com
Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue 


On Thu, 26 Aug 1999 13:11:24 PDT you wrote
> 
>   >> Can the remote end distinguish if a tunneled IPsec packet was created
by
>   >> IPIP encapsulation + IPsec transport mode or IPsec tunnel mode? In
eithe
>r
>   >> case, the incoming SA will have to match on the outer header.
> 
>   stephen> Yes, the outer header will be the same in either case, but
>   stephen> transport mode calls for matching SA selectors aginst the outer
IP
>   stephen> header and the immdeiately following transport header (if port
>   stephen> selectors are employed), whereas tunnel mode calls for matching
th
>e
>   stephen> selectors against the inner IP and transport headers.  Thus the
>   stephen> processing si different for each case.
> 
> That was my understanding for the sending side when an outgoing packet is
> tunneled. However, on the incoming side, the SA selectors must match
against
> the outer header, because inner header and transport layer may be
> encrypted. Or am I missing something? If this is correct, I still think
there
> is an ambiguity as to who is responsible for decapsulation.

The selectors don't apply at that stage on the inbound side. The SA is 
looked up against the SPI, protocol (which would be 4), and destination
address in the outer header. After decryption/decapsulation the receiver
would make sure that the selector which was used in creation of the SA
matches the decapsulated packet. 

There is no ambiguity for the receiver because the SAs are negotiated
differently. After decapsulation of a tunnel mode protected packet or 
reconstruction of a transport mode protected packet the particular selector
is applied. If it's a transport mode SA then that packet better be protocol
4 or you're supposed to drop it. If it's a tunnel mode SA then that packet
better match the selector or you're supposed to drop it.

Which brings up a problem in doing transport mode protected IPinIP. The 
selector would be for protocol 4 between the two boxes which means that 
_anything_ could be put into those tunnels. In tunnel mode the selector 
would be for whatever protocol in contained in the inner packet-- say, 
UDP port 520-- and then only that could be extracted from the tunnel.

  Dan.
Follow-Ups: