Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth

Hi Yaron,

there is already Section 3.2, which discusses possible
impact of NULL Auth on DOS resistance, and
the ddos/puzzles document is already referenced there.
Do you think more words need to be added to this section?

Regards,
Valery.

----- Original Message ----- 
From: "Yaron Sheffer" <yaronf.ietf@gmail.com>
To: "Paul Wouters" <paul@nohats.ca>; "Paul Koning" <paul_koning@dell.com>
Cc: <ipsec@ietf.org>; "Graham Bartlett (grbartle)" <grbartle@cisco.com>
Sent: Sunday, January 25, 2015 11:09 PM
Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in 
IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth

I would suggest to mention DDOS in this document briefly, but to move
the discussion (maybe add an entire section) to our dedicated
DDOS/puzzles document. For the simple reason that we want to publish the
NULL Auth document sooner.

Since Valery is co-author on both, I guess he gets to write it :-)

Thanks,
Yaron

On 01/23/2015 07:21 PM, Paul Wouters wrote:
> On Fri, 23 Jan 2015, Paul Koning wrote:
>
>>> Sorry for the late reply. Hopefully the following is more clear?
>>>
>>> When designing systems which will provide connectivity for
>>> non-authenticated users, the system SHOULD be designed with the capacity
>>> to support not only the maximum intended number of peers, but also
>>> include
>>> an additional number of sessions which are created due to malicious or
>>> erroneous behaviour. This safety margin will allow a system to still
>>> operate safely under load until it is exceeded.
>>
>> I understand the sentiment, but this seems like a recommendation that
>> can’t be tested and can’t really be implemented either.  The trouble
>> is that the number of malicious sessions is unbounded (and may be
>> quite large in a DOS scenario).
>>
>> It might be better simply to point out the limitations of the
>> machinery: because authentication is not provided in this case, the
>> receiving system has no way to distinguish legitimate peers from
>> malicious ones.  As a result, a denial of service attack may prevent
>> the intended number of legitimate peers from communicating.
>> Additional session (SA?) capacity may help in such cases.
>>
>> My point is that this is definitely going to be a case of throwing
>> some more resources at the problem in the hopes it’s enough, but no
>> way to predict whether it’s good enough.  Because of that, “SHOULD”
>> seems inappropriate, and a simple statement of the issue and the
>> limitations of this new protocol is better.
>
> There are two cases of overload. A "legitimate" overload by simply having
> too many (anonymous) clients, and an overload by malicious clients. It
> is hard to tell the difference without authentication.
>
> We could introduce a new notification payload for IKE_INIT that
> pre-announces the desire for unauthenticated IKE. A server could then
> reject/drop those connections when the load of legitimate clients gets
> too high without needing to create more state. If later in the exchange
> an attempt for authenticated IKE is made, the connection can be dropped
> as malicious. I'm not sure if this will turn out to be a needed feature
> to help with the legitimate client overload problem, so I'm tempted to
> postpone adding this until we have field reports that it could be
> useful.
>
> Currently what we (libreswan) are implementing is counting both halfopen
> SAs as well as states associated with unauthenticated IKE SA's. The
> halfopen SA's include _our_ outgoing IKE_INIT requests, as a spoofed
> source ip packet could have caused our end to initiate an IKE_INIT.
>
> Paul
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec 