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

[Yaron Sheffer <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec