RE: SOI QUESTION: 3.1 DoS protection

["Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>]

>    The fact that JFK only requires 4 round trips
>    ever is certainly an advantage because you
>    don't need to figure out when you're under
>    attack (you always are :-), and it simplifies
>    the state machine.

Does it? The extra check on the responder is very unobtrusive, so I wouldn't
say that the state machine is complicated. For both protocols, the initiator
already has to have a meta-negotiator which handles "retry with this
additional parameter" messages, of which this is just a specific instance.


>    The real question is what advantage the IKEv2
>    4/6 message exchange confers. As far as I
>    remember -- correct me if I'm wrong -- is that
>    the advantage was only that cipher suite
>    negotiation was deferred until after you have a
>    key.

No. (And why would that be an advantage -- See Radia's reply)

a) it makes message 3 always longer (so if most of the time you can
run without needing to ask for a stateless cookie, there will be fewer
bits on the wire)

[b and c omitted]

To which I would also add:

d) if you repeat every payload from message 1 in message 3 then you also
have to parse each payload twice. I can only speak for my implementation,
but I find this burdensome.


>    However, if you're willing to reveal
>    the cipher transforms in the clear (like JFK),
>    you can still have a 4 message exchange with
>    JFK-like DOS resistance.

I think this is a red herring. Simple logic tells you that you have to
reveal which encryption algorithm and DH group you are using before you can
send an encrypted message. Therefore, the cipher transforms *MUST* be sent
in the clear. I suppose you could try to be sneaky by using AES in SOI and
3DES in ESP, but let's try to be realistic. This is NOT the point of the 4/6
message exchange.


>    One of my suggestions to the JFK authors was to
>    relax the no-negotiation stance and adopt
>    an offer/answer model. That is, with JFK Bob
>    states which unilateral decision it has made
>    and Alice either lives with that decision, or
>    gives up. With an offer/answer mechanism Alice
>    would enumerate a list of transforms it's willing
>    to do, and Bob chooses one.

Forgive me for being blunt, but have you read the drafts/RFCs? What you
describe below is almost the exact opposite of the situation as it exists
today.

>    The advantage here is that offer/answer greatly
>    mitigates the need for the meta-negotiator.

Offer/answer is what IKEv1's Main Mode already does. Main Mode has no
explicit requirement for a meta-negotiator, since all parameters are
negotiated.

>    This is
>    obviously not much different than IKE's QM, of

Or any of the IKE modes. Main mode would have been a better example, since
both Aggressive mode and Quick mode have the DH group negotiation problem
which necessitates the meta-negotiator in JFK and IKEv2.

>    course, but I think the biggest mistake in
>    IKE's current scheme is trying to negotiate each
>    individual transform rather than aggregating them
>    into a single offer.

Sorry, but IKE does aggregate all the transforms into a single offer. It's
not a numbered ciphersuite, but it's still a single offer.

>    In reality, there's only a
>    few interesting transform combinations (eg
>    AES-128-CBC-SHA1) so I think any worries of
>    combinatorial explosion are overblown.

Dream on. You may think that agreeing on a ciphersuite is easy, but the fun
starts right off the bat when half the vendors want PFS off by default and
half want it on. Now add payload compression, which needs to be optional
(another factor of two). Some IPsec clients with restricted GUIs will send
up to 20 proposals by default. Ciphersuites in TLS worked out no better;
they had so many requests for permutations that IANA refused to manage the
registry.

I'm an advocate of named ciphersuites, as specified in Paul's draft. It
allows full flexibilty on the wire while allowing some consistency across
every vendor's GUI.

>    To my
>    mind, this strikes a more sensible balance
>    (didn't Dan et al do this in ikev2?).

No. IKEv2 actually does it both ways, but the preferred method is to
negotiate each transform separately. I like this idea. I can propose:

AES+SHA1+LZS // preferred ciphersuite, for which I have an optimized code
path
or {AES|3DES}+{SHA1|MD5}+{LZS|none} // any permutation of these

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.