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

[Christian Huitema <[e-mail]>]

On 11/5/2023 7:49 AM, Kazuho Oku wrote:
> 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.

There are at least three ways to remember past connections:

1) At the endpoint. The endpoint keeps track of the characteristics of 
past connections to a specific peer. QUIC clients are expected to do 
some of that, remembering tickets and tokens, and also remembering 
transport parameters negotiation for use in 0RTT. QUIC clients can 
easily add RTT and data rate to the set of data that they remember. QUIC 
servers could do that too, but that may not be practical in big server 
farms, and it does not scale well if the server serves a vast population 
of clients.

2) At the peer, exported in tickets or tokens. The server would include 
indications of RTT and data rate in the encrypted data. The client does 
not need any special code, it just remembers ticket or token and sends 
them. As Kazuho points out, using the tokens for this purpose is much 
more natural than using tickets.

3) At the peer, using the BDP frame. Similar to the token, with perhaps 
the advantage that the client can see the data, but with the downside 
that it requires standardization and new code in clients. 
Standardization has pitfalls, because we don't know well today what 
servers will need tomorrow. What about remembering jitter? Or the 
specific characteristics of LEO paths?

What about moving from "specifying the BDP frame" to "drafting an 
informational RFC explaining how the data can be embedded in QUIC tokens"?

-- Christian Huitema



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