Increase resilience to spoofed Version Negotiation packets #524
Conversation
martinthomson
added
design
draft-ietf-quic-transport.md
Outdated
|
|
||
| Note: | ||
|
|
||
| : The client cannot rely on the version list from the transport parameters. |
There was a problem hiding this comment.
I'd rephrase this -- the client certainly can rely on that list -- once the handshake has completed.
There was a problem hiding this comment.
The client has to rely on the list; it just cannot validate the list until the end of the handshake.
There was a problem hiding this comment.
Ack, I'll correct that.
draft-ietf-quic-transport.md
Outdated
|
|
||
| If the server does not list an acceptable version, the client MAY ignore the | ||
| Version Negotiation packet. This might reduce the likelihood that a spoofed | ||
| Version Negotiation packet can be used to disrupt connection establishment. |
There was a problem hiding this comment.
This seems very painful if there is a real mismatch. We've already blocked out injected packets, and I suspect that legitimate failures will be more common.
There was a problem hiding this comment.
+1. I would expect the common case to be mismatch, since an attacker can easily generate a VN packet that supports a large number of known versions (minus the client's chosen).
There was a problem hiding this comment.
I'll cut this paragraph.
draft-ietf-quic-transport.md
Outdated
| @@ -1228,6 +1235,18 @@ client MUST terminate with a QUIC_VERSION_NEGOTIATION_MISMATCH error code if | |||
| version negotiation occurred but it would have selected a different version | |||
| based on the value of the supported_versions list. | |||
|
|
|||
| If the client receives a Version Negotiation packet and these validation checks | |||
| subsequently fail, it is likely that the client received a spoofed Version | |||
| Negotiation packet. A client MAY attempt to create a new connection and ignore | |||
There was a problem hiding this comment.
I don't think we know this to be likely a result of spoofing, so I wouldn't say it yet.
There was a problem hiding this comment.
If there is a disagreement between transport parameters and version negotiation, then something is broken. I don't think that it matters if it is due to spoofing or a bug.
There was a problem hiding this comment.
I completely agree that something is broken in this case, but the text doesn't say that. It says "it is likely that the client received a spoofed Version Negotiation packet."
There's two layers of defense here: 1. Version Negotiation echoes 31-bits of entropy (maybe more if you consider the version to be at all unpredictable, or the client's source address to contain any entropy). 2. If validation fails and version negotiation happened, encourage the client to try again ignoring any Version Negotiation packets that match the failed profile. Closes #523.
martinthomson
force-pushed
the
validate_vn
branch
from
de69df9
to
1a94065
Compare
|
I ended up dropping this for some reason, but I've updated it now. |
|
What makes version negotiation special compared to all other first packets from a server? |
|
OBE: we decided not to worry about spoofed version negotiation too much. #724 covers the bit we want to keep here. |
There's two layers of defense here:
Version Negotiation echoes 31-bits of entropy (maybe more if you consider the version to be at all unpredictable, or the client's source address to contain any entropy).
If validation fails and version negotiation happened, encourage the client to try again ignoring any Version Negotiation packets that match the failed profile.
Closes #523.