On Mon, 6 Jun 2016, Valery Smyslov wrote:
> When it has good reasons :-)
>
> Seriously, consider the situation when the responder finds itself
> under attack and switches to only respond to IKE_SA_RESUME
> requests. In this case it will leave legitimate clients without
> resumption tickets (e.g. ticket expired) out of scope. I think there is
> no reasom to put MUST here, since in any case
> it is a local policy which dictates the responder's behaviour,
> and ther are no interoperability issues whether is is MAY, SHOULD or
> MUST, it is just the responder's local policy matter.
> So SHOULD is just good advise.
Actually, what you are describing is something else:
When the Responder is under attack, it MUST NOT prefer previously
authenticated peers who present a Session Resumption ticket [RFC5723]
as that could cause a complete lock-out of legitimate clients that
have no session to resume.
Although that is probably better rewritten a bit:
When the Responder is under attack, it SHOULD prefer previously
authenticated peers who present a Session Resumption ticket [RFC5723]
unless the attack itself consists of sending bogus resumption requests,
in which case it SHOULD treat resumption and new session requests
equally to avoid locking out a class of legitimate clients.
I'd rather change it a bit:
When the Responder is under attack, it SHOULD prefer previously
authenticated peers who present a Session Resumption ticket [RFC5723].
However, the Responder SHOULD NOT swich to resumed clients
completely (and thus refuse every IKE_SA_INIT request),
so that legitimate initiators without resumption tickets still have
chances to connect.
Ok, minor change:
When the Responder is under attack, it SHOULD prefer previously
authenticated peers who present a Session Resumption ticket [RFC5723].
However, the Responder SHOULD NOT serve resumed Initiators exclusively
because dropping all IKE_SA_INIT requests would lock out legitimate
Initiators that have no resumption ticket.
> Well, I think the proper approach is to measure the rate of such
> exchanges (per SA or course). So, just reset the counter every second
> and measure how many exchanges happened within
> the second. If the number looks abusive, take measures.
From our implementation point of view "per SA" is difficult, because we
delete failed SA states, and then lose the count of those. So in that
sense, using global counters makes more sense. For us, a rekey means
that the old state is replaced with a new state.
I don't see any problem here. We are talking not about failed exchanges
(after which the SA must be deleted), but about an abusive number of
unnecessary exchanges, which are successful from IKEv2 point of view.
You can very well count their number per SA and it is not a big deal
to reset counters when IKE SA is rekeyed.
I don't think you would want to reset the counters, but I know that our
implementation, which creates a new state object for the rekeyed state,
would lose information unless we specifically added code to copy those.
so perhaps it is useful to elaborate a little more?
Isn't all this a local matter of implementation?
I don't think we need to mandate how implementations
decide whether they are under attack.
I agree, this discussion does not need to be in the document.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
