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

Re: Simplifying IKE



This might go to Cheryl Madsons point that this protocol (SOI, IKEv2,
whatever)  may not be for everyone. KINK seems to have gone to great lengths
to address the transmission issues. I would prefer a 2 or 4 number exchange.
I would like the initiator to know when to send traffic that can be usefully
used by both parties as opposed to being dropped. That may be worse that one
extra message. That seemed to be the motivation of the dreaded COMMIT bit,
but I would not recommend making it optional.


>From Dan
<snip>

The only reason the Responder doesn't instantiate the SAs after sending
the 2nd message today is because of concerns about a resource consumption
attack. I feel those concerns are small due to the small time in which
the bogus SAs would be in the SADB, the inability of an attacker to use
them (due to the inability of a 3rd party to know SKEYID state), and the
small (and quantifiable) number of messages that can possibly be exchanged.
Instantiate them and delete them if the 3rd message is never received!
<snip>

To Dans point about 3 messages would only allow an SA to consume memory for
a short period of time, I am more concerned with tunnels per second
consuming memory. There may be cases where you could use too much memory as
a result of that, then just establishing one SA at a time. In that case,
especially in memory constrained devices, I would want to remove a much
resources usage as possible.


Scott
----- Original Message -----
From: "Jari Arkko" <jari.arkko@kolumbus.fi>
To: "Jan Vilhuber" <vilhuber@cisco.com>
Cc: "sankar ramamoorthi" <sankar@nexsi.com>; "Dan Harkins"
<dharkins@lounge.org>; "Ari Huttunen" <Ari.Huttunen@F-Secure.com>;
<ipsec@lists.tislabs.com>
Sent: Thursday, August 09, 2001 5:39 AM
Subject: Re: Simplifying IKE


>
>
> Jan Vilhuber wrote:
>
> >
> > making a 2 message exchange. I favor an even number of messages. Whether
> > that's 2 or 4 I don't MUCH care (2 would be preferable if we can figure
out
> > how).
>
> I'd just like to repeat my preference for the minimal number of messages
> even in this context. When these things are used over cellular links with
> relatively long delays, additional messages really affect the delays
before
> you can start work.
>
> Jari
>



References: