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
