Sec. 2.6: When a responder detects a large number of half-open IKE SAs,
it SHOULD reply to IKE_SA_INIT requests with a response containing the
COOKIE notification. The data associated with this notification MUST be
between 1 and 64 octets in length (inclusive), and its generation is
described later in this section.
On 01/15/2016 11:15 PM, Paul Wouters wrote:
On Fri, 15 Jan 2016, Yoav Nir wrote:
The initiator cannot validate the cookie - it is an opaque blob for
him. Should he reject
the cookie if its length is more than 64 bytes? Possibly. I don't know.
It's a bit strange to check an opaque object…
It’s an opaque object that the RFC says should be up to 64 bytes.
I tried to find a reference that the cookie is max 64 bytes and coul not
find it. So I concluded the valid max is a regular Notify payload length
specified in two octets, so 65535 bytes. I'm happy to be proven wrong :P
The responder accepts a cookie that it never sent. It doesn’t check
the cookie because there is, in fact, no DoS attack. That seems wrong.
As I also explain, it is probably motivated by supporting the server
switching to "no longer need cookies" and clients coming with a cookie
not getting denied. I agree that the server should still check any
cookie it receives, or after a timer reject all connections with
a (guaranteed false) cookie. But that would need to be an update to
RFC 7296.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
