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

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

Many thanks for the reply Lars, very interesting (your original below
still).

The problem I have is that I think model 2) does not deliver LAN-LAN
routing. If I have per-protocol/port policy that can create multiple IPSEC
tunnels to the same remote LAN, which of these tunnels is an 'Interface'?
The one that carries RIP traffic? All of them?
 
This has consequences on routing updates, and re-routing of traffic. I am
looking for a single entity like an IPIP tunnel device that can perform
polling, QOS/SLA monitoring and routing to a remote router, while getting
IPSEC protection on a per-packet basis.

I think perhaps a new model is needed to cope:

	Virtual IP interface (RIP enabled)
		| 
	IPIP Tunnel 'device' - with captive SPD

This works as before, except that the SPD is tied to the IPIP tunnel device.

The IPSEC peer is defined in the IPIP tunnel configuration, and all policies
in the captive SPD relate to that peer.

As IP packets are delivered to the IP tunnel device, it is passed through
the captive SPD to determine what (if any) IPSEC protection is required. 

If none, the IP tunnel is added, and the packet sent.

If transport, the IP tunnel is added, transport-mode IKE negotiated and
applied, packet sent.

If tunnel mode, the IP tunnel is added, tunnel mode IKE negotiated,
'transport mode' applied, packet sent.

As well as forwarded traffic, the IPIP tunnel device can generate private
polling messages (formatted pings say) to the peer tunnel device, and either
have some default IPSEC protection applied, or put them through the captive
SPD as well. 

RIP messages on the Virtual IP interface go the same way, and if the IPIP
tunnel device detects the peer is dead, can communicate to the Virtual IP
interface that the datalink is down.

I think that gets us all possible combinations in the same model, with a
true routing interface to play with.

This is basically close interaction between the SPD and the tunnel device,
and restricting the SPD to refer to the same peer for all policies, because
it is subservient to the IPIP tunnel device.

Thoughts?
Cheers, Steve.


-----Original Message-----
From: Lars Eggert [mailto:larse@isi.edu]
Sent: Thursday, August 26, 1999 7:06 PM
To: ipsec@lists.tislabs.com
Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue


-----BEGIN PGP SIGNED MESSAGE-----

  stephen> 1) IP tunnel device tunnels packets, IPSEC then applies
  stephen> transport-mode protection to the IP-in-IP packets as they leave.

This is the option we choose for the X-Bone (http://www.isi.edu/x-bone), as
the KAME and CAIRN stacks do not (yet?) support option 2. The only problem
with this approach is of course that your IPsec selectors match on the outer
header, i.e. there is no way to have different SAs based on the inner
(virtual) addresses. For now, we circumvent this problem by encapsulating
twice.
 
  stephen> 2) IPSEC tunnel is modeled as an interface, and just negotiates
  stephen> tunnel mode and exposes the resulting tunnel as an interface.
This
  stephen> is akin to marrying an SDP policy with an Interface.

We believe this would be the cleanest option, and we'd very much like to see
it implemented. There was a discussion about this recently on the KAME
snap-users mailing list (thread subject "RIP over IPsec tunnels?")
accessible
at http://www.kame.net/snap-users/.

Lars
____________________________________________________________________________
__
Lars Eggert <larse@isi.edu>                     Information Sciences
Institute
http://www.isi.edu/~larse/                   University of Southern
California

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBN8WB/NZcnpRveo1xAQHjegP/ZXivPv0OgBVPTb/FHPikxpy2Cp5MiTRo
X8aRYO8Gm3t3tht2RSbVwhMfhh42HBhNdNyDO5DzLRHtLslMG6M7R2yt+EIvMVMx
U4cMHiIpi4NPAUOhARbe+DnI3NOcOh2XREuwiiRf1RT9Hg+SbgxDYCFuRMbYz3kh
p6bf2MKFY1c=
=NAdw
-----END PGP SIGNATURE-----
Follow-Ups: