2023年11月5日(日) 16:41 Marten Seemann <[email protected]>:
> On different CC's: the set of parameters exchanged are fairly
generic, and I think it's very likely a client will use the same
CC to talk to the same server when it next resumes a session, so I
am unsure i share the concern about different CCs.
Gorry, I might be misreading the draft, but in my understanding
the BDP_FRAME frame is used by servers to offload state to the
client, not the other way around, so your argument should be that
the server will use the same CC on the original and the resumed
connection. The client might also remember CC parameters, but they
wouldn't be sent on the wire.
My argument here is twofold: If this frame is supposed to be read
and acted upon by the client, you now have to deal with the
situation where client and server use different CCs, which will
lead to problems if server and client don't use the same CC. On
the other hand, if the frame is not supposed to be acted upon by
the client, there's no reason to use a frame in the first place,
as servers can just unilaterally decide to put the information
into the token.
FWIW, in case of quicly I'm not sure we'd want to use CWND and current
RTT to calculate the jump CWND.
That is because quicly has a delivery rate estimate based on ACK clock
that gives us a better estimation of the available bandwidth; we'd
prefer using that and the min RTT.
On Sun, 5 Nov 2023 at 15:32, Gorry Fairhurst
<[email protected]> wrote:
On 05/11/2023 10:04, Marten Seemann wrote:
In the design of RFC 9000, frames are used to communicate
information between two endpoints. This is not what the
BDP_FRAME frame does: It's only saved by the client and
echoed back to the server on a later connection. It is
questionable to me if the client’s ability to inspect (but
not modify) the contents of the frame provides a lot of
value: Congestion controllers are inherently
endpoint-specific, and (for example) reusing the parameters
of an L4S CC with a Cubic CC, and vice versa, doesn't sound
like a good idea.
That's not what the ID says.
On different CC's: the set of parameters exchanged are fairly
generic, and I think it's very likely a client will use the
same CC to talk to the same server when it next resumes a
session, so I am unsure i share the concern about different CCs.
Section 1.2 of the ID speaks about the possibility to share
the infromation with the application... which might be
important to tuning the use of the token (choosing which
connection ought to use the Careful-Resume), and ensuring
appropriate polices are used for flow-credit, choosing content
encoding appropriate to rate, etc.
As Kazuho pointed out, RFC 9000 already contains the concept
of a resumption token.
I'd like to understand more what that is.
Tokens are opaque, so servers can encode whatever information
they want into the token. Resumption tokens are used to
validate the client’s IP address, so they’re inherently bound
to the path. This is pretty much exactly the property that
you’d want for resuming CC parameters. Apart from that, using
tokens has multiple other advantages as well:
1. We don’t need interoperability between implementations
here. The client is resuming the connection with the same
server (or a different server in the same deployment), so it
doesn’t matter how the information is encoded.
I like that.
2. Depending on their CC, servers might want to encode a
different set of parameters. This is possible when using a
token, whereas the BDP_FRAME frame limits us to the few
fields defined in the draft.
Good - but I do expect that a BDP_FRAME could be made extensible.
3. The BDP_FRAME frame can only be sent in 0-RTT packets (if
I understand correctly, I'm very confused by the phrasing of
section 4), so it can’t be used for non-0-RTT session resumption.
I think that depends a little on how we decide to finally
transport the parms - we're open to changing this.
4. Obviously, using the token doesn’t require clients to be
aware that this is going on, so it will work with every QUIC
stack without any modification.
Yes, that's nice also.
Best wishes,
Gorry
On Sun, 5 Nov 2023 at 11:14, Kazuho Oku <[email protected]>
wrote:
2023年11月4日(土) 15:44 <[email protected]>:
BDP frame is about QUIC transport (RFC9000)
resumption. IMO, it does not have dependencies on
RFC9001.
I think I tend to agree with Lucas modulo the point that
it would make more sense to store BDP information in
tokens issued by the QUIC servers[1] than the TLS session
ticket.
Tokens are defined in RFC 9000. The only use case being
mandated at the moment is address validation but it is
designed so that it can hold arbitrary data. Tokens can
hold BDP information as well.
1:
https://datatracker.ietf.org/doc/html/rfc9000#frame-new-token
Orange Restricted
*De :* Gorry Fairhurst <[email protected]>
*Envoyé :* samedi 4 novembre 2023 14:45
*À :* STEPHAN Emile INNOV/NET
<[email protected]>; Nicolas Kuhn
<[email protected]>; [email protected]
*Objet :* Re: Authentication in
draft-kuhn-quic-bdpframe-extension
On 04/11/2023 13:28, [email protected] wrote:
Hi
IMO, we are speaking of QUIC resumption not TLS.
Regards
Emile
I think QUIC CC resumption could be a part of TLS
resumption. Are there also cases where these could be
different things?
Gorry
*De :* QUIC <[email protected]>
<mailto:[email protected]> *De la part de*
Nicolas Kuhn
*Envoyé :* samedi 4 novembre 2023 12:43
*À :* [email protected]
*Objet :* Re: Authentication in
draft-kuhn-quic-bdpframe-extension
Dear all,
Thank you for your interest in this work !
I would tend to agree with Lucas and think we
should consider scenarios where BDP frames would
be used with TLS resumption and I do not see the
need for proposing another trust mechanism; But
there may be scenarios I do not see ?
More comments inline.
Kind regards,
Nico
On 11/3/23 16:44, Lucas Pardue wrote:
Hi folks,
I'm still trying to come up to speed on this
spec. But when I've thought about it a
little, its seemed very natural to associate
the BDP frame (contents) with the TLS
session. We already have a lot of text about
TLS session resumption in QUIC. It feels like
there is already a template design with
HTTP/3 - a server sends SETTINGS to tell a
client something unique about the active QUIC
connection. RFC 9114 section 7.2.4.2 [1]states
> When a 0-RTT QUIC connection is being used,
the initial value of each server setting is
the value used in the previous session.
Clients *SHOULD* store the settings the
server provided in the HTTP/3 connection
where resumption information was provided,
but they *MAY* opt not to store settings in
certain cases (e.g., if the session ticket is
received before the SETTINGS frame). A client
*MUST* comply with stored settings -- or
default values if no values are stored --
when attempting 0-RTT. Once a server has
provided new settings, clients *MUST* comply
with those values.¶
<https://www.rfc-editor.org/rfc/rfc9114.html#section-7.2.4.2-6>
So with a bit of massaging, if we can link
BDP frame to session resumption. we know that
it is based on a previous trust relationship.
Is there any scenario where BDP frame would
want to be used without TLS resumption?
[NK] I agree.
Cheers
Lucas
[1] -
https://www.rfc-editor.org/rfc/rfc9114.html#section-7.2.4.2-6
On Thu, Nov 2, 2023 at 6:17 PM Gorry
Fairhurst <[email protected]> wrote:
On 02/11/2023 16:43, Q Misell wrote:
Hi all,
I've been working with Gorry (and
others) on actually implementing the
BDP frame extension, and further
refining the draft based on
experience from implementation.
Q, I think I can help a little, see
below, but I think there are good
questions here.
[NK] If the draft is not clear enough on these
relevant questions, we ought to make things clearer.
One thing that came up that I'd like
to ask the WG's opinion on is that of
authentication of the BDP frame, and
when it should be sent in the
exchange. I've had a few thoughts on
this, it'd be great to hear what
others think of them, or what other
suggestions people might have.
First, my thoughts on authentication.
Do the CC parameters need to be
authenticated at all? I would say
"yes" as a client sending some
unauthenticated CC parameters could
cause a DoS of the server (or any
other node along the path) by trying
to send far too much data at once.
The reason for the secure hash around the
contents of the BDP Frame is to allow a
server to know the CC params had not been
modified. Of course you caould ask what
sort of information contributes to that
hash, to make the server confident that
it can accept CC params from the client
and believe that these have not been
modifed? That could be important?
[NK] The client should not be able to transmit
unauthenticated CC parameters that are not
checked / known by the server. In the current
spec, the client can only send data previously
received by the server. Malicious clients could
try to cause a DoS on the server but that would
not be specific to BDP Frame but to 0-RTT in
general.
Should the CC parameters be
encrypted? Probably not, as a client
which is aware of a major decrease in
available capacity could compare the
new link capacity to its stored CC
parameters and decide not to send
them. If they're encrypted the client
can't inspect what CC parameters the
server thinks the link will have.
Perhaps the ID ought to be clearer. The
QUIC Session is of course encrypted and
authenticated, so, in this respect, the
BDP Frame is protected in transit along
the path using TLS.
The current proposal is not to
additionally encrypt the CC params
*within* the BDP, so that a client could
read these and utlise as it sees fit.
This still needs to authenticate the
entire set of params, so that the server
could trust them.
The params include an endpoint token used
by a server to represent the remote
endpoint - we could have used the client
IP source address for this if the client
had an invariant public IP source
address. That's not so common with IPv6
or the use of IPv4 NAPT - so the server
has to find a way to represent it's view
of the client as the endpoint token.
There could be possibilities to do this
quite differently.
How should they be authenticated?
There are a few options I can see
here, and I'm unsure which is best:
(1) Authenticated with the TLS
certificate
(2) Authenticated with some other
asymmetric key
(3) Authenticated using some
symmetric key known only to the server
(4) Same as 3 but with a key identifier
Options 1 and 2 allow the client to
verify the authentication over the CC
parameters, but this doesn't seem to
be of much use to me. Option 1
additionally sets a time limit on use
of stored CC parameters, as the TLS
certificate will eventually expire.
This doesn't seem to me to be much of
an issue. A new connection far into
the future (say 1-2 months) would
almost certainly have different CC
parameters anyway.
Option 3 seems the best to me. It
would allow one key to be shared
across an array of anycast servers,
without sharing other keying material
that might be used to protect more
sensitive parts of the connection.
Option 4 additionally expands on this
by allowing key rotation without
immediately invalidating all current
stored CC parameters.
So, if this is about how to construct the
secure hash, irt seems like an
interesting topic to find out more, I'd
agree.
[NK] We may not specify how to compute the secure
hash but that could be interesting discussions if
you think the draft needs to be more specific on
this. IMHO the client does not need to know how
the secure hash is compute and thus not sure we
need interoperability.
When should the BDP frame be sent?
There are two places I can see BDP
frames being useful to send:
(1) After initial frames but before
crypto frames
(2) After crypto frames and before
application data
Option 1 allows for the previously
calculated CC parameters to be used
for the sometimes quite large TLS
handshake, but also precludes options
1 and 2 for authentication. Option 2
allows for greater flexibility in
authentication, and also makes the
BDP frame encrypted in transit. I'm
unsure what the privacy implications
of an unencrypted BDP frame are, so
if anyone can come up with a reason
CC data shouldn't be observable to an
intermediary that would be greatly
appreciated.
:-)
[NK] Do we need to specify this in the draft or
should this be let to implementers to define the
most relevant approach (w.r.t. frame scheduling
to format QUIC packets).
Looking forward to hearing your thoughts.
[NK] Thank you for your comments !
Cheers,
Q Misell
Gorry
------------------------------------------------------------------------
Any statements contained in this
email are personal to the author and
are not necessarily the statements of
the company unless specifically
stated. AS207960 Cyfyngedig, having a
registered office at 13 Pen-y-lan
Terrace, Caerdydd, Cymru, CF23 9EU,
trading as Glauca Digital, is a
company registered in Wales under №
12417574
<https://find-and-update.company-information.service.gov.uk/company/12417574>,
LEI 875500FXNCJPAPF3PD10. ICO
register №: ZA782876
<https://ico.org.uk/ESDWebPages/Entry/ZA782876>.
UK VAT №: GB378323867. EU VAT №:
EU372013983. Turkish VAT №:
0861333524. South Korean VAT №:
522-80-03080. AS207960 Ewrop OÜ,
having a registered office at
Lääne-Viru maakond, Tapa vald,
Porkuni küla, Lossi tn 1, 46001,
trading as Glauca Digital, is a
company registered in Estonia under №
16755226. Estonian VAT №:
EE102625532. Glauca Digital and the
Glauca logo are registered trademarks
in the UK, under № UK00003718474 and
№ UK00003718468, respectively.
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des
informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation.
Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes.
Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete
altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential
or privileged information that may be protected by law;
they should not be distributed, used or copied without
authorisation.
If you have received this email in error, please notify the
sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages
that have been modified, changed or falsified.
Thank you.
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des
informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si
vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere,
deforme ou falsifie. Merci.
This message and its attachments may contain confidential or
privileged information that may be protected by law;
they should not be distributed, used or copied without
authorisation.
If you have received this email in error, please notify the
sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages
that have been modified, changed or falsified.
Thank you.
--
Kazuho Oku
--
Kazuho Oku
