> On 15 Jan 2016, at 11:15 PM, Paul Wouters <[email protected]> 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
Section 2.6, top of page 33 in RFC 7296: 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. > >> 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. We will be making this even more murky with puzzles. A cookie should be seen again after about 1 RTT, but an initiator may take a while to return a solved puzzle. How long do we set the timer for a solved puzzle? Yoav _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
