RE: SOI QUESTION: 3.1 DoS protection

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

> Optionally adding an additional round trip creates another
> path through
> the negotiation that is similar to providing different modes
> (e.g. main
> and aggressive). I'm not opposed to the additional round
> trip, just the
> fact that it is optional.

Actually, it is more akin to the "abort and retry with new parameters"
condition that is already present in both protocols.


> Not sure I understand how they provide protection. With IKEv2
> as soon as
> an attacker witnesses an exchange it can then begin to flood
> the node with
> fragments that look as if they came from one of the nodes in
> the exchange.

Just like cookies, this feature is aimed at the class of DoS attacks where
the attacker cannot sniff along the data path. Therefore, the attacker
cannot "witness an exchange".

-------------------------------------------
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 David Faucher
> Sent: Thursday, June 27, 2002 2:10 PM
> To: ipsec@lists.tislabs.com
> Subject: Re: SOI QUESTION: 3.1 DoS protection
>
>
> |
> | Notes from the chair:
> |
> | This next set of questions address the issues listed in
> section 3 of the
> | soi-features I-D, "Protocol Mechanics".
> |
> |
> | Please discuss and answer:
> |
> | 3.1 DoS protection
> |
> | 3.1.A) WRT DOS attacks that exhaust memory or CPU
> resources, is it more
> | important to always keep the message count at 4, or is it
> acceptable to
> add
> | an additional roundtrip of messages when the responder
> thinks he's under
> | attack?
> |
>
> Optionally adding an additional round trip creates another
> path through
> the negotiation that is similar to providing different modes
> (e.g. main
> and aggressive). I'm not opposed to the additional round
> trip, just the
> fact that it is optional.
>
> | 3.1.B) WRT UDP fragmentation attack protection, both IKEv2
> and JFK provide
> | basically equivalent protection. Does anyone care about the
> details of how
> | JFK or IKEv2 provide this functionality.
> |
>
> Not sure I understand how they provide protection. With IKEv2
> as soon as
> an attacker witnesses an exchange it can then begin to flood
> the node with
> fragments that look as if they came from one of the nodes in
> the exchange.
> With JFK once a valid fragment has been seen, the id field
> can then be used
> to send invalid fragments. Am I missing something here?
>
> | 3.1.C) Is it important to have precomputation of
> exponentials available
> for
> | use as a mechanism for protecting against cpu consumption attacks?
> |
>
> Implementation detail.
>
> | Implications from the scenarios:
> |
> | [none]
> |
>
>