Re: [quicwg/base-drafts] Remove DoS vector for spoofed connection migration (#2893)

[Eric Kinnear <[e-mail]>]

@pravb I think we got to the point where either (a) the packets miraculously get to the right place and then the endpoint can choose to either honor them or drop them or (b) they don't, in which case that's sad, but that's what happens when your infrastructure doesn't handle NAT rebinding or any other changes to the 4-tuple.

In neither case do you want to close the connection with an error, in case someone else has injected a packet with a different source address.

Note https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.21.8
>21.8. Stateless Reset Oracle
>Stateless resets create a possible denial of service attack analogous to a TCP reset injection. This attack is possible if an attacker is able to cause a stateless reset token to be generated for a connection with a selected connection ID. An attacker that can cause this token to be generated can reset an active connection with the same connection ID.
>
>If a packet can be routed to different instances that share a static key, for example by changing an IP address or port, then an attacker can cause the server to send a stateless reset. To defend against this style of denial service, endpoints that share a static key for stateless reset (see Section 10.4.2) MUST be arranged so that packets with a given connection ID always arrive at an instance that has connection state, unless that connection is no longer active.

Should you be in a situation where the client will accept your stateless reset for a connection that's active if someone spoofs a source address and the packet ends up on a server that has no state? If that can happen, that seems like we should open a new issue, since that's something that can happen at any time (although seems to me to be pretty much covered by the text in 21.8).

The point of this change is to be clear that the purpose of the TP is to instruct the endpoint sending the packets to not intentionally change its address or port, but that the server receiving the packets (if for whatever reason they still get there) needs to not close the connection if it sees that happening. It can drop the offending packets, or process them, but it's a problem if it does the previous behavior which was to close the connection.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2893#issuecomment-518893780