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
