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.
As Kazuho pointed out, RFC 9000 already contains the concept of a
resumption token. 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.
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.
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.
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.
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
