Re: SOI QUESTION: 3.1 DoS protection

["David Faucher" <dfaucher@lucent.com>]

----- Original Message -----
From: "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.
|

I can see you point but, I'm still opposed to it being optional.

|
| > 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".
|

Now I understand. Thanks for the clarification.

| -------------------------------------------
| 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]
| > |
| >
| >
|