Re: Authentication in draft-kuhn-quic-bdpframe-extension

[Kazuho Oku <[e-mail]>]

2023年11月5日(日) 16:41 Marten Seemann <[e-mail]>:

> > 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.

As such, I'm not sure if having a standard definition of a BDP frame would
help server implementers.

To paraphrase, I think the question is if there is an appetite for the WG
to define a frame solely for communicating the estimate of the unvalidated
phase *to the client,* and if sending that at the end of the previous
connection is the best way to do so.


>
> On Sun, 5 Nov 2023 at 15:32, Gorry Fairhurst <[e-mail]> 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 <[e-mail]> wrote:
>>
>>>
>>>
>>> 2023年11月4日(土) 15:44 <[e-mail]>:
>>>
>>>> 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 <[e-mail]>
>>>> *Envoyé :* samedi 4 novembre 2023 14:45
>>>> *À :* STEPHAN Emile INNOV/NET <[e-mail]>; Nicolas Kuhn
>>>> <[e-mail]>; [e-mail]
>>>> *Objet :* Re: Authentication in draft-kuhn-quic-bdpframe-extension
>>>>
>>>>
>>>>
>>>> On 04/11/2023 13:28, [e-mail] 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 <[e-mail]> <[e-mail]> *De la
>>>> part de* Nicolas Kuhn
>>>> *Envoyé :* samedi 4 novembre 2023 12:43
>>>> *À :* [e-mail]
>>>> *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 <[e-mail]>
>>>> 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