Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update identification of packet number space identifier #29

Closed
wants to merge 1 commit into from
Closed

Update identification of packet number space identifier #29

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 5 additions & 3 deletions draft-lmbdhk-quic-multipath.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -132,9 +132,11 @@ In addition, we define the following terms:
The difference between Path Identifier and Packet Number Space Identifier, is that Path Identifier
is used in multi-path control frames to identify a path, and Packet Number Space Identifier is used
in 1-RTT packets and ACK_MP frames to distinguish packet number spaces for different paths.
Both identifiers have the sam value, which is the sequence number of the connection ID, if a
non-zero connection ID is used. If the connection ID is zero length, the Packet Number Space
Identifier is 0, while the Path Identifier is selected on path establishment.
When an endhost uses a non-zero-length Connection ID on a path, the Packet Number Space Identifier
corresponds to the sequence number of the CID used. In the case one of the hosts uses
zero-length connection IDs, the packet number space identifier of its path corresponds to the
sequence number of the Connection ID used by its peer over the same 5-tuple. When both hosts
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
sequence number of the Connection ID used by its peer over the same 5-tuple. When both hosts
sequence number of the Connection ID used by its peer over the same 5-tuple.
This implies that if a connection ID is used by either host, only packets that carry
a connection ID can be used to open a new path. When both hosts

uses zero-length connection IDs, the packet number space identifier is 0.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not agree that this works.

For starter, it does not work if the server uses a zero length CID. It that case, in order to create a new path, a client sends a probe with a zero length CID. It arrives at the server on a five tuple that the server has not yet seen. How can the server know which encryption context it should use? The same issue would also happen in the case of NAT rebinding. The server sees a new five tuple, does not know what encryption to apply.

So, the first request is to specialize this text to the case in which the client uses zero length CID but the server does not.

Even in that case, using the five tuple is going to make client-side encryption offload significantly more complex. The offload engines will have to remember all the five tuples used in the connection, and the corresponding keys. This is a new requirement, and it may be difficult to meet by many implementations.

I think it would be much simpler to accept the limitation: using multiple number spaces requires that both sides use non-null connection IDs.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I definitely agree with your first point or to say it more generally, the host opening a new path needs to carry a CID.

Not entirely sure about the second point: Why do you think it is more complicated to path to a 5-tuple instead of matching the CID? Or do you mean that current offload engines only use the CID and this would simply be a change? Are these kind of offload engines already deployed?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current API only uses the packet itself: look at the packet, find the number context, expand the number to 64 bits, attempt decryption. Using IP addresses makes this a bit more complicated, and introduces new failure modes such as variation of NAT. Using the peer's CID is also error prone. For example, in case of probes, the receiver has no idea of the value of the peer's CID.

See issue #96 for a discussion of options.

# Handshake Negotiation and Transport Parameter {#nego}

Expand Down