[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Simplifying IKE
Sandy Harris wrote:
>
> The Leech, Schiller and Bellovin (LSB?) document mentions:
>
> > the goal: to produce a more secure, simpler, and more robust version of IKE.
>
> I thought it might be useful to inventory some proposed simplifications. Of
> course I'll toss in my own opinions while I'm at it, but my goal is less to
> get them accepted than to provoke discussion.
>
> >From the Schneier and Ferguson analysis we get:
>
> > 1: eliminate transport mode
>
> It would be possible to eliminate tunnel mode instead, and just use IP-in-IP
> over transport where required, but it seems simpler to treat transport as a
> degenerate tunnel instead. Either mode can do everything we need, so we need
> only one mode. My vote is for tunnel.
We address this issue in (the currently recently-expired, but in update)
draft-touch-ipsec-vpn-01.txt
There is one difference between the two ways of doing tunnel:
1) tunnel mode keys before routing occurs,
requiring sychronization between key databases and
routing databases when dynamic routing is used to
determine keyed path, e.g., for VPNs that use
dynamic routing with IPsec'd virtual links
2) transport mode + IPIP encapsulation routes before keying
this allows VPNs with dynamic routing using
existing routing software
---
Tunnel-mode everywhere means an additional 20-40 bytes of overhead
everywhere as well, as Dan indicates in his later post. Finally,
tunnel mode requires replication of tunneling capability, already
part of multicast and mobile IP.
While we aren't advocating the removal of tunnel mode per se,
our draft describes how transport mode is the more complete and less
costly subset.
Though, as others have indicated, these are wire-protocol issues
rather than IKE (or simpler-IKE) issues.
Joe
References: