Summary:
This introduces a new frame type for acks (ACK_EXTENDED) that can carry optional fields depending on the features supported by the peer. The currently supported features set will include ECN count fields, and Receive Timstamp fields. This enables a quic connection to report both ECN counts and receive timestamps, which is not possible otherwise because they use different frame types.
Support for the extended ack as well as the set of features that can be included in it is negotiated through a new transport parameter (extended_ack_supported = 0xff0a004). Its value indicates which features are supported by the local transport. The value is an integer which is evaluated against the following bitmasks:
```
ECN_COUNTS = 0x01,
RECEIVE_TIMESTAMPS = 0x02,
```
This diff introduces the transport parameter and negotiates the supported features between the peers of the connection. The parameter is cached in the psk cache so the client can remember the server config. It is also encoded inside the 0-rtt ticket so the server can reject it if its local config has changed.
The following diffs add reading and writing the frame itself.
The ACK_EXTENDED frame itself will have the following format
```
ACK_EXTENDED Frame {
Type (i) = 0xB1
// Fields of the existing ACK (type=0x02) frame:
Largest Acknowledged (i),
ACK Delay (i),
ACK Range Count (i),
First ACK Range (i),
ACK Range (..) ...,
Extended Ack Features (i),
// Optional ECN counts (if bit 0 is set in Features)
[ECN Counts (..)],
// Optional Receive Timestamps (if bit 1 is set in Features)
[Receive Timestamps (..)]
}
// Fields from the existing ACK_ECN frame
ECN Counts {
ECT0 Count (i),
ECT1 Count (i),
ECN-CE Count (i),
}
// Fields from the existing ACK_RECEIVE_TIMESTAMPS frame
Receive Timestamps {
Timestamp Range Count (i),
Timestamp Ranges (..) ...,
}
Timestamp Range {
Gap (i),
Timestamp Delta Count (i),
Timestamp Delta (i) ...,
}
```
Reviewed By: sharmafb
Differential Revision: D68931151
fbshipit-source-id: 44c8c83d2f434abca97c4e85f0fa7502736cddc1
Summary: This diff adds the reliable_stream_reset transport parameter to mvfst.
Reviewed By: hanidamlaj
Differential Revision: D65383676
fbshipit-source-id: cb2f6a1a90004ea489447b67ed3cfc12ca90b804
Summary:
Ack Rx timestamps are currently disabled on 0-rtt connections, which is enabled on mvfst for all non-video connections.
This is because the timestamp config is negotiated with transport settings during handshake which doesn't happen on a new 0-rtt connection (resumption).
Solution:
Store the peer's rx timestamp config in PSKCache on the client. On 0-rtt resumption of the connection, this peer config is restored and used to send Rx timestamps (if enabled).
Note that if the server had changed its timestamp config during this period (through configerator) then the server needs to reject this 0-rtt connection and start anew. Server code changes to support this will be in a followup diff. With this client diff though, server will drop the Rx timestamps if its own config is suddenly disabled (this is a waste of network resource).
Reviewed By: jbeshay
Differential Revision: D58572572
fbshipit-source-id: d95720c177ac4bc8dcbe40362f19b279b3f8e708
Summary:
The idea here is to make it so we can swap out the type we are using for optionality. In the near term we are going to try swapping towards one that more aggressively tries to save size.
For now there is no functional change and this is just a big aliasing diff.
Reviewed By: sharmafb
Differential Revision: D57633896
fbshipit-source-id: 6eae5953d47395b390016e59cf9d639f3b6c8cfe
Summary:
If early data is rejected and the tls parameters that we used from the 0-rtt ticket do not match the ones in the current handshake, the connection cannot continue.
Previously, the connection would fail but the psk still stayed in the client cache. This meant that subsequent retries could still attempt zero rtt and hit the same error repeatedly.
This change moves the decision to close the connection to the QuicClientTransport instead of the FizzClientHandshake so it can remove the "bad" psk from the pskCache.
Reviewed By: kvtsoy
Differential Revision: D57398519
fbshipit-source-id: b1c076794b9b16954ec23474bffc5a0be7e11090
Summary: This implements the necessary functions for key update in the ClientHandshake, and adds the logic for updating the write cipher in the client transfer whenever a successful key update is detected by the read codec.
Reviewed By: mjoras
Differential Revision: D53016558
fbshipit-source-id: 59123cddec97ee5eb204b8816e7c844b22055008
Summary:
change signature of both `ClientHandshake::getServerTransportParams` & `ClientTransportParametersExtension::getServerTransportParams`
from:
```
folly::Optional<ServerTransportParameters> getServerTransportParams()
```
to:
```
const folly::Optional<ServerTransportParameters>& getServerTransportParams()
```
previously this would `std::move(serverTransportParameters_)` after reading it, effectively making it possible to only read the value once.
Reviewed By: kvtsoy
Differential Revision: D48356933
fbshipit-source-id: deddd9101979c1ef30d540b67216dc9611ced713
Summary:
This removes the older method of deciding whether knob frames should be sent using the QuicVersion. With this change, the client can only send knobs when the server has signaled support using the `knob_frames_supported` transport parameter.
To make sure that knobs can be sent in 0-rtt connections, the transport parameter is now included in the client's cache of server transport parameters.
Reviewed By: mjoras
Differential Revision: D43014893
fbshipit-source-id: 204dd43b4551cd1c943153a3716e882fc80e6136
Summary: As in title, this doesn't need to be in the base state.
Reviewed By: JunqiWang
Differential Revision: D29855140
fbshipit-source-id: 8d3a4b12fd6b93b2277020d56862915e084f1c05
Summary: Keep on server for now but disallow it in code for the client.
Reviewed By: yangchi
Differential Revision: D27726584
fbshipit-source-id: c567d9db82c36b6e60d438d839709f0330b8db50
Summary:
This can happen when we don't get the server handshake data in time, but it is especially bad with 0RTT when it is potentially a full flight of 1RTT data that is dropped while we wait for the handshake PTO.
Note this leverages the existing CipherUnavailable mechanism, but processes them in a much more simple way than the server side. Additionally, only 1-RTT packets need to be buffered.
Reviewed By: yangchi, lnicco
Differential Revision: D27634184
fbshipit-source-id: db5ba0b9f07176d106f709c7a11d83d0fc8281b7
Summary: This was just totally wrong. It's expected that we'll get multiple confirmations for the client sometimes, since either a HandshakeDone or 1-rtt ACK can confirm.
Reviewed By: lnicco
Differential Revision: D26321808
fbshipit-source-id: c7477ce727392e71b78f046be4b49170098d04af
Summary: This switches the client to use the FizzRetryIntegrityTagGenerator and the PseudoRetryPacketBuilder, to avoid duplication of a lot of the work.
Reviewed By: mjoras
Differential Revision: D21489881
fbshipit-source-id: 8aa3af26f1090eeb9f2f04eb4defd785ad555df1
Summary: in draft-24, we do not drop handshake key, which means we keep triggering this warning log over and over
Reviewed By: mjoras
Differential Revision: D24070227
fbshipit-source-id: 25a3e5c479c3f3c958d59ccc9d8453fc35ca2d26
Summary:
There is a pretty tight coupling between ClientHandshake and FizzClientHandshake . The later can mess up pretty bad with the former's state, especially since th code has quite a lot of temporal dependencies and is very stateful.
This constraint he API through which the subclass can interact with the parent class and prevent some obviously bad misuses. It also make it clear when something is to made available for testing exclusively.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/182
Test Plan:
Imported from GitHub, without a `Test Plan:` line.
---
## Traffic Canary
https://our.intern.facebook.com/intern/traffic/canary?fbid=119893296332660
* elb.prod.hel3c01 - binary - 2020-09-24 23:01 - https://fburl.com/dyndash/q948xh5b
* flb.prod.fgdl1c03 - binary - 2020-09-24 23:01 - https://fburl.com/dyndash/1p582qcv
* olb.prod.rftw0c01.p2 - binary - 2020-09-24 23:01 - https://fburl.com/dyndash/h23ldteg
* slb.prod_regional.rash0c00 - binary - 2020-09-24 23:01 - https://fburl.com/dyndash/6cjn5fxn
* slb.regional.rash0c01.p2 - binary - 2020-09-24 23:01 - https://fburl.com/dyndash/kadbkkdf
---
Reviewed By: mjoras
Differential Revision: D23816801
Pulled By: bschlinker
fbshipit-source-id: 52c7fa3e3f436d3317f2a13bef8ae4d596f6a25b
Summary:
Now we won't have a zero PTO and we will properly clear out the outstanding packets.
Note that this cipher dropping is not what the draft prescribes, instead dropping both the initial and handshake ciphers when we know 1-rtt communication is functioning.
Reviewed By: yangchi
Differential Revision: D20388737
fbshipit-source-id: 0b89eb80c8faa796ab09eda3eaa10a00dcf7bae9
Summary: This is useful when you want to ensure that the IOBuf you pass in is encrypted inplace, as opposed to potentially creating a new one.
Reviewed By: yangchi
Differential Revision: D21135253
fbshipit-source-id: 89b6e718fc8da1324685c390c721a564bb77d01d
Summary: This adds the ability to verify the integrity token present in a retry packet, as per section 5.8 of the QUIC-TLS draft (https://fburl.com/kw9l8dvu). This doesn't change any existing functionality.
Reviewed By: mjoras
Differential Revision: D19631864
fbshipit-source-id: 2ff8288986b3e27c85fe885b132ab6753fed3be8
Summary:
The cache entry contains the key itself, which is fizz dependent and crypto agnostic infos. We are moving the crypto agnostic infos to the Handshake. Next step is to move the crypto specific infos to the proper handshake subclass.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/113
Reviewed By: mjoras
Differential Revision: D20469126
Pulled By: yangchi
fbshipit-source-id: 25db463ef8d0e982ef5e47ef147e7e9b6c859cb5
Summary:
This ensures we have a place to plug things into the connect method that do not depend on the actual handshake implementation.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/110
Reviewed By: mjoras
Differential Revision: D20463305
Pulled By: yangchi
fbshipit-source-id: a46c23871ec1021712641fbef98399cd5036001a
Summary: This implements the handshake done signal and also cipher dropping.
Reviewed By: yangchi
Differential Revision: D19584922
fbshipit-source-id: a98bec8f1076393b051ff65a2d8aae7d572b42f5
Summary:
This is a first step in a series of refactoring moving the fizz specific parts of the psk cache management in FizzCientHandshake.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/92
Reviewed By: mjoras
Differential Revision: D19699174
Pulled By: yangchi
fbshipit-source-id: 99c11da4c97e2f19874c1cedb23751c2392296cb
Summary:
The reduce unnecessary exposure of common code to fizz and hopefully gets us one step closer to complete separation.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/83
Reviewed By: sharma95
Differential Revision: D19386615
Pulled By: udippant
fbshipit-source-id: fc00dfb06630be54a42bc51ea4ee2c1d64270229
Summary:
This moves the fizz specific part of the handshake into its own folder and library.
There is a bit of smurf naming going on as a result, not sure it is worth fixing or not at this stage. Maybe this code should be a in namespace named quic::fizz .
This should be doable with the client as well as soon as the key cache situation is figured out.
---
## Proxygen Canary
Reviewed By: yangchi
Differential Revision: D19290919
fbshipit-source-id: 48d7f7c70db42c65f7dffe3256805c268a481198
Summary:
Replace them with home cooked union based variant type to remove boost
dependencies.
Reviewed By: siyengar
Differential Revision: D18445458
fbshipit-source-id: a1804bb2dc316128e36c90e7cb575b690c906409
Summary:
Starting to migrate fizz specific features to the fizz specific handshake class.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/65
Reviewed By: siyengar
Differential Revision: D18575268
Pulled By: mjoras
fbshipit-source-id: dc1a2f1705e28e1a7f857d9b026c8f15d735c455
Summary:
This separate the cipher management - which is generic - from the cipher construction - that is fizz specific.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/58
Reviewed By: sharma95
Differential Revision: D18044353
Pulled By: mjoras
fbshipit-source-id: eb498fa3dac1b1cd1678edbb6e1d250bc875fd2c
Summary:
This is done in order to keep make sure they can be refactored into some fizz specific code, and that fizz independent code can be shared.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/54
Reviewed By: mjoras
Differential Revision: D17898100
Pulled By: lnicco
fbshipit-source-id: e5ee1b0ae6d241bb04763aac3688338d70aaeb0b
Summary:
This is one more step toward isolating fizz specific code from the API. The elements that cannot be moved away can then be extracted into a pluggable component, at least that's the goal.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/47
Reviewed By: mjoras
Differential Revision: D17592394
Pulled By: yangchi
fbshipit-source-id: 7998a6cebea81221942ee9ee1cf49d89da3ebce0
Summary:
They are strongly coupled, which indicate this is probably better to do it as one class.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/44
Reviewed By: mjoras
Differential Revision: D17590918
Pulled By: yangchi
fbshipit-source-id: 2eaca079fd760107eefd2b74fa612d7a0c8b3001
Summary:
It is part of the public API and rely on fizz. Moreover, it is not used and therefore can be removed.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/48
Reviewed By: mjoras
Differential Revision: D17668100
Pulled By: yangchi
fbshipit-source-id: 6dc170ea6de5c0e333ce1c627bc3a272f3fbc2bf
Summary:
The CryptoFactory is extended with makePacketNumberCipher . In order to support that feature, FizzCryptoFactory now explicitly takes a QuicFizzFactory as argument instead of a generic fizz::Factory, which is the only type that is used in practice anyways.
The cypher argument was removed because:
1/ Only one cypher is used at all. Fizz also supports ChaCha20, but using it in mvfst will throw an exception.
2/ it seems like the factory should know what cypher it is dealing with.
If a choice of cypher needs to be supported going forward, it can be done by adding state to FizzCryptoFactory.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/40
Reviewed By: mjoras
Differential Revision: D16785274
Pulled By: yangchi
fbshipit-source-id: a1c490e34c5ddd107e8e068d8b127c1ed00a59ec
