[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Regarding pre-round trip for stateless cookie (Jan's issue)
My opinion of the "always 4 message" technique is that it is just a case of
JFK being unnecessarily innovative. Getting DoS protection in 4 messages may
be technically cool, but it doesn't really mean much. Under heavy load you
have to expect increased latency, and the small message size and streamlined
code path of IKEv2 should actually help throughput relative to JFK.
I use the term "under load" rather than "under attack" since I figure that
implementers would use a simple algorithm based on CPU+memory usage to
decide when to enter 6 mode, as Paul pointed out earlier.
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Radia Perlman -
> Boston Center for Networking
> Sent: Tuesday, September 17, 2002 3:38 PM
> To: ipsec@lists.tislabs.com; vilhuber@cisco.com
> Subject: Regarding pre-round trip for stateless cookie (Jan's issue)
>
>
> Re:
> From: Jan Vilhuber <vilhuber@cisco.com>
>
> I'm wondering about the wisdom of merging IKEv2 with
> JFK'isms. Seeing
> that I haven't read the revised IKEv2+JFK proposal
> (because it's not
> out yet), this is mostly based on my thoughts of what
> *I* would do,
> were I to merge the two. I expect there's not that many
> ways to skin
> this cat.
>
> First a nontechnical point...I've changed the subject line
> because I think
> it's always better to focus on a particular technical detail
> rather than
> which spec something might have come from. At this point there are not
> n candidate proposals with n sets of authors, but instead a single
> draft that all the authors of all the drafts, and actually, everyone
> in the WG, is collaborating on. Everyone wants something that
> is correct,
> reasonably simple, and reflects as close as can be measured,
> the feelings
> of the WG.
>
> Back to the technical issue Jan raised, which I'll call "4/6
> vs 4", where
> "4/6" means letting Bob, if he wants to do stateless cookies, request
> an optional round trip before the 4-message exchange.
> In the greater scheme of things, I don't think this issue
> matters all that much,
> but I've changed my mind about this recently and it would be
> good if the
> WG could weigh in, if people (especially implementers) have strong
> opinions. The summary is that I originally believed
> in "4", but now that I've helped work out the details of "4",
> at this point I agree with you, Jan, that "4/6" seems simpler, but
> I also don't think it's all that important and can live with
> either way.
>
> I'd been arguing about this very point with my original coauthors
> Dan Harkins and Charlie Kaufman since before our first draft. I wanted
> 4, they wanted 4/6.
> They were not able to explain to me very eloquently at the time
> why they wanted to
> do 4/6. It seemed to me that the WG would think a 4 message exchange
> would be preferable to a (4, sometimes 6) message exchange.
> At first Dan and
> Charlie
> just told me that it would be "a pain in the neck". And when I pressed
> for more details they used some of your arguments,
> like "half the message encrypted,
> half unencrypted", which didn't seem to me like it should be all that
> much of a hassle. Then Charlie brought up the fragmentation attack,
> and I was convinced that the 4/6 method was better, because it keeps
> all messages small until the stateless cookie has been returned, so
> that one could build an implementation that saved reassembly resources
> for IP addresses that have returned stateless cookies.
>
> It was probably me that suggested, though, in order to look more like
> a "merged" proposal, that we make the modification to always
> be 4 messages.
> It was only after we were working out the details that I
> understood what
> Charlie and Dan meant by "pain in the neck". It's doable, but
> the protocol
> is a lot more complicated.
>
> I don't think it's necessary for any "political" reasons that
> we do anything
> any particular way. I think at this point it's clear everyone
> is collaborating
> on one proposal, and wants to do something correct, as simple
> as possible,
> and reflective of the WG's wishes. If we're not choosing
> "proposal A from
> this set of authors" vs "proposal B from this set of authors"
> and instead
> focusing on a well-defined technical point, and the WG has
> sound arguments
> for a particular opinion, we'll all support that way of doing
> things ("sound"
> means that the result would be correct, not overly complex, etc.)
>
> So let's focus on this one technical issue.
>
> The 4/6 protocol can be summarized as follows:
> messages 1 and 2 are D-H exchange (and nonces, and crypto
> negotiation)
> messages 3 and 4 are encrypted and integrity protected with
> a function
> of the D-H key, and consist of the identities, and proofs
> of knowledge
> of the secret, using some function of messages 1 and 2.
> The simplest
> and easiest, implementation-wise, is to sign all of
> messages 1 and 2,
> exactly as transmitted. We modified that to "sign your own message
> concatenated with the other side's nonce", at Sara
> Bitan's suggestion,
> which seemed like it wouldn't be harder, and certainly all fields
> would be still protected in one or the other side's signature. We
> were trying to avoid the issue Jan brought up of wrangling over
> which fields should be covered, and what the canonical
> order would be,
> and having implementations have to move all the fields around to
> create the canonical hash.
> if Bob wants to use a stateless cookie before doing the handshake,
> he replies to a message 1 without a cookie by saying "try again,
> using this cookie"
>
> The 4-always protocol is more conceptually complicated, since
> Bob, when
> he receives message 3, cannot be assumed to have any
> state. Since there
> are parts of messages 1 and 2 that need to be integrity
> protected (like
> the crypto negotiation), Alice has to repeat all of message 1, and
> Bob has to be able to reproduce, bit for bit, what he would have
> generated as message 2, so that he can sign that. There are the
> issues you brought up, Jan, about which fields need to be in the
> signature, which need to be
> repeated, etc. There are many strategies for how Bob might want
> to use the fields of cookie and nonce to encode state for himself.
> We don't want to constrain an implementation, and yet we need to
> define at least one way that works.
>
> Radia
>
>