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