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

RE: Simplifying IKE



> At 7:59 AM +0100 8/8/01, Chris Trobridge wrote:
> >I have to admit I started in the "keep tunnelling - los
> transport" camp, but
> >with more experience I would definitely prefer transport mode +
IP-in-IP.
> >This makes gateways and end-to-end cases identical.  It also separates
> >routing issues associated with tunnelling from IPSEC.
>
> remember that a major difference between tunnel and transport modes
> is what headers are examined for access control purposes. if one
> changes to IP-in-IP tunneling above IPsec, it would be important to
> retain this security facility, which means we still need to know
> where to look in the stack, ...

Yes, transport mode over IPIP tunnels (IIPtran) must conform to RFC2401,
section 5.2.1. And we think it can/does - from
draft-touch-ipsec-vpn-01.txt:

   The primary difference is in the subsequent processing of the
   incoming packet. IPsec tunnel mode does not require a separate rule
   for accepting packets with the inner header; once they are accepted
   during the unwrap phase, they are accepted. IIPtran requires that
   unwrapped packets be further processed by an additional round, which
   requires that incoming packets with these headers be accepted. As
   noted in [1], IPsec processing should retain SA use for subsequent
   IPsec or firewall processing. It should be possible for these
   incoming packets to be IPIP decapsulated _only_ where the appropriate
   SA has been used, but as a separate step.

The main difference between the two approaches is during outbound
processing: With IPsec tunnel mode, the SA determines routing (the inner
header determines the SA which prepends the outer header), while with
transport mode over IPIP, routing determines the SA (encapsulation comes
first, the SA is then determined by the outer header).

This seems like a small enough difference; however, the implications reach
far. One example is that unmodified routing algorithms work inside IIPtran
overlay networks. Another is that IIPtran decouples overlay topology from
security: Deploying IPIP tunnels without IPsec yields an insecure overlay;
IPsec can simply be turned on for existing overlay topologies by
establishing SAs.

In a nutshell, IIPtran constructs a "virtual Internet" using IPIP tunnels
(and supports most protocols/applications inside it without
modifications); and secures links in the "virtual Internet" with
transport-mode IPsec.

We are preparing an update to draft-touch-ipsec-vpn-01.txt to address
further implications of IIPtran that have been encountered recently (such
as IKE interactions, found during the KAME implementation of the ID by
Itojun-san).

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

smime.p7s


Follow-Ups: References: