Closed martinduke closed 4 years ago
kazuho
commented
4 years ago SGTM. It might be a good idea to have a note about the possibility, because IIRC a server is permitted to skip address validation when the client port changes but the IP address continues to be the same.
martinduke
commented
4 years ago I also filed https://github.com/quicwg/ops-drafts/issues/87 because this is a general problem for NATs that are getting too cute with CIDs. I might end up putting some text in the manageability draft and just pointing to that in QUIC-LB.
On Sat, Nov 16, 2019 at 10:50 AM Kazuho Oku notifications@github.com wrote:
SGTM. It might be a good idea to have a note about the possibility, because IIRC a server is permitted to skip address validation when the client port changes but the IP address continues to be the same.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/martinduke/draft-duke-quic-load-balancers/issues/55?email_source=notifications&email_token=AF2EYEN4VQOIRAUW2AQVLV3QT5NXZA5CNFSM4JOC7WMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEHHU2I#issuecomment-554596969, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF2EYEP4LWK2EXV3BYNQHNDQT5NXZANCNFSM4JOC7WMA .
martinduke
commented
4 years ago Addressed in both ops draft and draft-duke-quic-natsupp-00.
Via @dtikhonov: Some load balancers might also serve as NATs, in which case they have some per-connection state.
If this state is per-fourtuple, all the QUIC address change mechanisms will work fine. We should add some text to the security considerations that doing this on a connection ID basis (trying to be QUIC-aware) is actually worse -- it can lead to masking address changes from the server and prevent employment of path verification mechanisms.