Comments (5)
The QUIC DT on this subject has come up with a different design:
- you use a new connection ID when you observe a path change
- endpoints need to provide their peers enough connection IDs that they shouldn't run out
- when an endpoint stops using a connection ID, there is a new "retire connection ID" message that is used to signal that it is no longer needed
- endpoints that receive this "retire connection ID" are expected to replenish the supply of connection IDs at their peer
from dtls13-spec.
Point (1) is sort of implicit in the text, and I agree we should add it.
Points (2)-(4) are about ensuring that the other side has enough CIDs. In QUIC, this is the server's job and there's no real way for the client to say that it doesn't have enough CIDs or tell the server how many. It can just say that it is done using some set of CIDs and this tells the server to send more, but the server has no idea how many. By contrast, the DTLS design is for the client to tell the server when it wants more CIDs and the server gets to retire them. ISTM that this is a more flexible design in that the server can change CIDs whenever it wants (e.g., for rekeying of the CID encryption key).
IIRC much of the motivation for the design with QUIC was not to have to interlock with the ACK, and in this respect the situation here is the same as with the KeyUpdate, which is that the QUIC design has the advantage that it doesn't need to interlock with the ACK to know when things have change. But that doesn't apply here for the same reason as with #63.
So I think my proposed resolution is just to add that you should change CIDs whenever you change paths and should request enough CIDs that you have a hot spare. I could imagine a way for the server to say what specific keys it wants to invalidate, but I'm not sure that's necessary. I do think we should enhance RequestConnectionId to have a count.
from dtls13-spec.
from dtls13-spec.
from dtls13-spec.
(Just noting my earlier thoughts here so they're saved somewhere)
Overall, only concern is around the rate at which you can send additional connection IDs to the peer vs. the rate at which you retire them. My understanding is that they are all retired at once, but need to be provided independently.
It seems like there could be situations, especially for a sender that needs to migrate rapidly (say away from and then back to some specific interface), where this leaves the sender without a CID to switch to.
Allowing multiple CIDs in the messages as in #65 looks like it generally resolves this.
Also noting that infinite looping in response to peer changes is covered by the sequence number.
from dtls13-spec.
Related Issues (20)
- Erik Kline comments HOT 1
- Francesca Palombini Comments HOT 1
- Martin Duke Comments HOT 1
- Bernard Aboba Comments HOT 1
- AEAD Limits HOT 2
- Retransmissions HOT 4
- Remove ACK from flight table HOT 1
- It seems there a merge conflict. HOT 2
- message_hash construction is ambiguous in DTLS
- Should the protocol specify a mechanism to ensure that the link is disconnected if the peer is restarted or some reason? HOT 6
- DTLS 1.3 limits the number of packets that can be encrypted with AES-GCM to 2^40.5 HOT 11
- Establishing New Associations with Existing Parameters - SHOULD / please add description of the alternatives HOT 1
- Rekeying in (D)TLS 1.3 does not update the exporter_secret HOT 6
- Mention RFC 7457 in Security section HOT 6
- Consider rewording of handshake buffering requirement
- AEAD integrity limits for 0-RTT data HOT 9
- Rename TLS HandshakeTypes
- Peer Address Update HOT 4
- DTLS behavior on received closure alert HOT 9
- Whats the status of this? HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dtls13-spec.