[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re draft-kaufman-ipsec-improveike-00.txt
I see this argument a lot, and I've also used it in the past. My current
thinking is: There's several routing protocols, not just one. They are sort
of tailored to an certain network-topology, and one routing-protocol doesn't
necessarily work in all topologies. We should look at a keying protocol in
the same way.
I suggest we work on more than one keying mechanism. Each one should be
simple and should be tailored to one type of environment (the VPN space is
afterall very different from the core-network environment). Different people
will have different requirements, too. The answer to 'which keying protocol
should I use' is no longer simple then, and requires one to think about the
situation we're using it in, and what we want from it. So be it. It's not
like users have to think about this stuff: It's what network admins do. They
already have to deal with 'which routing protocol should I use'.
We can then generate more than one rather simple keying mechanisms, that may
or may not overlap slightly, but have strengths in different areas.
Flames to /dev/null, constructive criticism encouraged. I am, of course, not
a network admin, so those that have this job may well tell me this is a
non-starter.
Of course you should realize that we are already doing this: KINK is a keying
protocol tailored to certain requirements. It doesn't try to be everything to
all people. We probably need only one or two more to cover the other current
requirements people have of a keying protocol.
jan
On Mon, 6 Aug 2001, borderlt wrote:
>
> Re getting rid of aggressive mode... Sigh! I can see the reasoning
> behind wanting to simplify down to only one mode. But, not offering the
> option for fewer messages will affect deployment of IPsec for links with high
> latency. We are starting to see a lot demand for the use of IPsec over
> satellite links with the usual corresponding optimization questions. And,
> identity hiding is not important for the cases where this has come up...
>
>
> John
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
Follow-Ups:
References: