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