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

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

On the receiving side, when transport mode is used to protect IP-in-IP or
L2TP traffic, IPSEC is responsible for extracting the IPSEC headers, and the
remaining packet is delivered to a local protocol listener on the SG - an
L2TP or IPIP tunnel demultiplexor, and from there to the Virtual IP
interface 'above' with full routing interface status.

If IPSEC packets arrive at the SG, IPSEC's job is to take of an IP header
and the IPSEC headers.  For Intranet packets that are being routed between
to LANs, what remains is a pure Intranet packet, with no convenient
mechanism to count against a virtual IP interface, e.g. increment counters
in an Interface MIB entry.

If you think of an IP-IP tunnel with transport-mode protection as 'PPP with
ECP', that is the effect I am after:

	IP Interface - RIP on
	   |
        PPP - ECP DES

IP packets have PPP header added by the PPP device, and are then ECP
protected.

Replace the PPP/ECP with IP-in-IP tunnel+transport mode, and you have the
same result. IPSEC decrypts, IP-in-IP tunnel takes off the 'data-link' (just
happens to be an IP header), and the datalink send the encapsulated IP
packet 'up' to the IP/routing interface.

If you are contented to protect all traffic between VPN LAN-LAN in with the
same level of security (all 3DES+SHA+IPCOMP), then this model works fine,
fits well with traditional router architecture, provides a common approach
for all tunnel protocols, and offers the possibility of an empty SPD and no
outbound policy lookups to do!

The empty SPD thing:
Consider a host that opens a TCP connection to a remote peer. There is no
reason why it should not request an IPSEC policy to be created dynamically
for each unique 'flow'. For example, TCP request a transport-mode policy to
be protected to protect
src:1.2.3.4/dst:4.3.2.1,prot:TCP,src-port:10,dst-port:20.  IPSEC sets up the
policy, returns a handle to it that TCP quotes for each packet sent, and
there you have it - no predefined SPD, just a dynamic one.

This model could be used in the same way by 'originating' tunnel
(IPIP,L2TP,GRE) traffic on a Security Gateway.

Steve.


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


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

  >> Can the remote end distinguish if a tunneled IPsec packet was created
by
  >> IPIP encapsulation + IPsec transport mode or IPsec tunnel mode? In
either
  >> 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
the
  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.

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

iQCVAwUBN8WfbNZcnpRveo1xAQEJRgP/Rwyc3PoSpTtZ12UyGi6oSDFzsy/7BUm2
nvXgiFDs+mjQ+7DnCvV0UPWXSEYyURPjtfVV5VfmJNl2OGUR+ktxCoOQmPA2qU/L
HaHmItcyqTKpNC5e/yCSgwskfD55sBYmjCIAIBeWR7wFMNtr5kE6XtkzYwIYBvOu
grZF9IY490M=
=ty6q
-----END PGP SIGNATURE-----