rewrite NAT section #257
rewrite NAT section #257
Conversation
|
|
||
| Note that multiplexing connection IDs over a single port anyway violates the | ||
| best common practice to avoid "port overloading" as described in {{?RFC4787}}. | ||
|
|
||
| Furthermore, wide deployment of NATs with this behavior hinders the use of | ||
| QUIC's migration function, which relies on the ability to change the connection | ||
| ID any time during the lifetime of a QUIC connection. |
There was a problem hiding this comment.
Not sure I fully understand this point actually. If path changes are concealed, no migration is needed...
| exhausted, it should rather drop the initial packets of a connecton than | ||
| risking to break it later. As QUIC is based on UDP and there are known blockings of | ||
| UDP, QUIC deplyoments are recommended to implemenet a fallback to TCP | ||
| {{?I-D.ietf-quic-applicability}}. Therefore it is often preferable for QUIC |
There was a problem hiding this comment.
I also wonder is this actually entirely true. If you cannot get a binding for your QUIC connection, why would you get a binding for a TCP connection? Isn't some connectivity, even at the risk that it might break later in the connection better than no connectivity?
There was a problem hiding this comment.
If clients prefer QUIC over TCP, which is likely to happen real soon now, then I don't think that it is unreasonable to expect more free TCP capacity.
draft-ietf-quic-manageability.md
Outdated
| UDP, QUIC deplyoments are recommended to implemenet a fallback to TCP | ||
| {{?I-D.ietf-quic-applicability}}. Therefore it is often preferable for QUIC | ||
| to fail and fallback during connectiion establishment rather persisting with a | ||
| connection that might be unstable or expierencing |
There was a problem hiding this comment.
Not sure if NATs would make a connection unstable or just break it...? Complete breaking is actually better to detect than unstable connectivity. You still have to eat a time-out but then you will immediately be able to re-connect.
|
|
||
| An NAT that blleaches peer address changes, hinders the other end | ||
| to detect and mitigate these attacks and verify connectivity to the | ||
| new address based on QUIC PATH_CHALLENGE and PATH_RESPONSE frames. |
There was a problem hiding this comment.
This paragraph is probably redundant...
There was a problem hiding this comment.
Honestly, I prefer the original wording of this subsection. But you're the editor!
There was a problem hiding this comment.
I was trying to make it more clear what the recommendation actually is and remove some redundancy. I can give it another, less invasive try.
However, I think the main point about redundancy is actually that you basically say the same thing in this and the previous section (only that the motivation do use CID is different). So I would actually rather structure the text by "approach" than by use case but that would an even bigger rewrite.
I'll have another look with a fresh pair of eyes tomorrow!
|
|
||
| An NAT that blleaches peer address changes, hinders the other end | ||
| to detect and mitigate these attacks and verify connectivity to the | ||
| new address based on QUIC PATH_CHALLENGE and PATH_RESPONSE frames. |
There was a problem hiding this comment.
Honestly, I prefer the original wording of this subsection. But you're the editor!
Co-authored-by: martinduke <martin.h.duke@gmail.com>
| migration will cause packets to be delivered to the wrong server. {{QUIC_LB}} | ||
| addresses this problem proposing a QUIC extension to allow server-load balancer | ||
| coordination to routable CIDs. |
There was a problem hiding this comment.
| migration will cause packets to be delivered to the wrong server. {{QUIC_LB}} | |
| addresses this problem proposing a QUIC extension to allow server-load balancer | |
| coordination to routable CIDs. | |
| migration will cause packets to be delivered to the wrong server. {{QUIC_LB}} | |
| describes a system for coordinating selection and use of connection IDs between | |
| load-balancers and servers. |
I couldn't understand this sentence.
draft-ietf-quic-manageability.md
Outdated
| An alternative, potentially simpler approach would seem to be the use of NAT in front | ||
| of such an infrastructure setup. However, hiding information about the change | ||
| of the IP address or port conceals important, and security relevant information | ||
| from QUIC endpoints, and as such would facilitate amplification attacks (see | ||
| section 9 of {{QUIC-TRANSPORT}}). |
There was a problem hiding this comment.
Rather than phrase this as a viable alternative (as the lead-in text implies), make it clear that this is non-viable.
It might seem possible to use a NAT that uses connection IDs to provide a stable address 4-tuple. This might work if servers cooperate to inform the NAT of all connection IDs that might be used for each connection. However, hiding address changes from a server prevents the server from validating new addresses, which would facilitate amplification attacks (see {{Section 9 of QUIC-TRANSPORT}}).
| exhausted, it should rather drop the initial packets of a connecton than | ||
| risking to break it later. As QUIC is based on UDP and there are known blockings of | ||
| UDP, QUIC deplyoments are recommended to implemenet a fallback to TCP | ||
| {{?I-D.ietf-quic-applicability}}. Therefore it is often preferable for QUIC |
There was a problem hiding this comment.
If clients prefer QUIC over TCP, which is likely to happen real soon now, then I don't think that it is unreasonable to expect more free TCP capacity.
draft-ietf-quic-manageability.md
Outdated
| Not-yet-used connection IDs are unknown to in-network devices and cannot | ||
| be easily associated with a connection ID in use, as new connection IDs are | ||
| negotiated inside cryptographically protected packets between the endpoints | ||
| and as such are not observable in the network. Alternatively, sharing | ||
| configurations between the client and NAT might be logistically challenging | ||
| or impossible, especially when client migrates with an existing connection to | ||
| a point behind the NAT. {{QUIC_LB}} described mechanisms to encode the client's | ||
| identity in | ||
| a connection ID to be used for load balancing. However, the described approach | ||
| requires explicit coordination between the endpoint and network devices using the | ||
| connection ID under the assumption that servers and load balancers are deployed | ||
| by the same entity or cooperating entities. |
There was a problem hiding this comment.
This might be replaced by text that just says "Coordination with endpoints is necessary if connection IDs are to be used as QUIC provides confidentiality protection for the negotiation of connection IDs. A NAT might be able to coordinate with endpoints using the methods described in {{QUIC_LB}}."
| risking breakage later. As QUIC is based on UDP and some devices are known to block | ||
| UDP, QUIC deployments are recommended to implement a fallback to TCP | ||
| {{?I-D.ietf-quic-applicability}}. Therefore it is often preferable for QUIC | ||
| to fail and fallback during connection establishment rather than persist with a |
There was a problem hiding this comment.
| to fail and fallback during connection establishment rather than persist with a | |
| to fail and fallback when the flow is first used rather than persist with a |
| {{?I-D.ietf-quic-applicability}}. Therefore it is often preferable for QUIC | ||
| to fail and fallback during connection establishment rather than persist with a | ||
| connection that might be unstable or experiencing | ||
| sudden connection errors and time outs later during the connection. |
There was a problem hiding this comment.
| sudden connection errors and time outs later during the connection. | |
| sudden errors and time outs later. |
Co-authored-by: Martin Thomson <mt@lowentropy.net>
draft-ietf-quic-manageability.md
Outdated
| @@ -945,68 +945,72 @@ deliver packets between server and NAT. Reducing the timeout on UDP NATs might | |||
| be tempting in light of this property, but not all QUIC server deployments will | |||
| be robust to rebinding. | |||
|
|
|||
| Recommendations on time-outs for stateful network functions such as NATs is | |||
| providded in {#sec-stateful}. | |||
There was a problem hiding this comment.
| providded in {#sec-stateful}. | |
| provided in {#sec-stateful}. |
| and as such are not observable in the network. Alternatively, sharing | ||
| configurations between the client and NAT might be logistically challenging | ||
| or impossible, especially when client migrates with an existing connection to | ||
| a point behind the NAT. {{QUIC_LB}} described mechanisms to encode the client's |
There was a problem hiding this comment.
| a point behind the NAT. {{QUIC_LB}} described mechanisms to encode the client's | |
| a point behind the NAT. {{QUIC_LB}} describes mechanisms to encode the connection's |
| the connection ID under the assumption that servers and load balancers are | ||
| deployed by the same entity or cooperating entities. | ||
|
|
||
| Note that multiplexing connection IDs over a single port anyway violates the |
There was a problem hiding this comment.
| Note that multiplexing connection IDs over a single port anyway violates the | |
| Note that multiplexing connection IDs over a single port also violates the |
|
replaced by PR #272 |
No description provided.