On Wed, Jan 27, 2016 at 02:19:32PM +0000, Salz, Rich via RT wrote:
>
> > This suggests that you have on-path capabilities between each of the
> > reflectors and the victim, right?
>
> I don't think so: you need the first attacker to get the cookie, then you
> spread it out.
Cheng, et al. Experimental [Page 8]
RFC 7413 TCP Fast Open December 2014
The server is in charge of cookie generation and authentication. The
cookie SHOULD be a MAC tag with the following properties. We use
"SHOULD" because, in some cases, the cookie may be trivially
generated as discussed in Section 7.3.
1. The cookie authenticates the client's (source) IP address of the
SYN packet. The IP address may be an IPv4 or IPv6 address.
2. The cookie can only be generated by the server and cannot be
fabricated by any other parties, including the client.
3. The generation and verification are fast relative to the rest of
SYN and SYN-ACK processing.
4. A server may encode other information in the cookie and accept
more than one valid cookie per client at any given time. But this
is server-implementation dependent and transparent to the client.
5. The cookie expires after a certain amount of time. The reason for
cookie expiration is detailed in the "Security Considerations"
section (Section 5). This can be done by either periodically
changing the server key used to generate cookies or including a
timestamp when generating the cookie.
To gradually invalidate cookies over time, the server can
implement key rotation to generate and verify cookies using
multiple keys. This approach is useful for large-scale servers to
retain Fast Open rolling key updates. We do not specify a
particular mechanism because the implementation is server
specific.
What attack do you have in mind via spreading a cookie good for
just one source IP address? Sure the botnet can source TFO
from that same IP address that got the original cookie. Why is
that useful?
--
Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
