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

Hi Valery,

The DoS/puzzles document presents a "plan" for DDoS defense. I believe 
that unauthenticated clients need to be considered as part of this plan. 
I'm OK with the general guidelines in Sec. 3.2, but suggest that the 
DDoS document needs to be beefed up to account for this use case.

Thanks,
	Yaron

On 01/26/2015 01:37 PM, Valery Smyslov wrote:
> 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