Lines Matching refs:record
4 This document covers the design of an abstract record layer for use in (D)TLS.
5 The QUIC record layer is handled separately.
7 A record within this document refers to a packet of data. It will typically
9 cryptographically protected. A record may or may not have a one-to-one
11 an individual record layer.
13 The term record comes directly from the TLS and DTLS specifications.
15 Libssl supports a number of different types of record layer, and record layer
18 - Standard TLS record layer
19 - Standard DTLS record layer
20 - Kernel TLS record layer
22 Within the TLS record layer there are options to handle "multiblock" and
24 writing of multiple records at the same time. All record layer variants also
27 These different record layer implementations, variants and protocol versions
33 The introduction of QUIC support will see the implementation of a new record
34 layer, i.e. the QUIC-TLS record layer. This refers to the "inner" TLS
43 lists these requirements that are relevant to the record layer:
45 * The current libssl record layer includes support for TLS, DTLS and KTLS. QUIC
47 requires a pluggable record layer interface to be implemented to enable this
48 to be less intrusive, more maintainable, and to harmonize the existing record
50 pluggable record layer interface will be internal only for MVP and be public
53 * The minimum viable product (MVP) for the next release is a pluggable record
60 record layer interface and it should offer a stable ABI (via a provider).
64 * a pluggable record layer (not public for MVP)
70 the abstract record layer
80 types of record layer that we support, i.e. there would be one for the standard
81 TLS record layer, one for the standard DTLS record layer, one for kernel TLS and
100 effort involved in making the record layer fetchable can be deferred to a
113 main difference is that the record layer implementations would be held in
148 A proposed internal record method API is given in
149 [Appendix A](#appendix-a-the-internal-record-method-api).
152 record layer. It contains a set of function pointers to represent the various
153 actions that can be performed by a record layer.
164 standard TLS record layer during the handshake, and later transition to using
165 the kernel TLS record layer once the handshake is complete.
171 the record layer. The internal structure details of an `OSSL_RECORD_LAYER` are
177 All of the header and payload data for a single record will be represented by an
179 templates for records to be written out and pass them to the "write" record
180 layer. In most cases only a single record is ever written out at one time,
184 It is the record layer's responsibility to know whether it can support multiple
186 data into `OSSL_RECORD_TEMPLATE` objects. Libssl will call the record layer's
190 record layer's `write_records()` function.
211 `read_record` function only ever returns one record at a time. The
212 `OSSL_RECORD_LAYER` object owns the buffers for the record that has been read
214 well as other information about the record such as its length and the type of
215 data contained in it. Each record has an associated opaque handle `rechandle`.
216 The record data must remain buffered by the `OSSL_RECORD_LAYER` until it has
219 A record layer implementation supplies various functions to enable libssl to
236 record layer.
239 currently being used by the record layer.
241 `get_max_record_overhead()`: to obtain the maximum amount of bytes the record
246 In addition, libssl will tell the record layer about various events that might
247 occur that are relevant to the record layer's operation:
249 `set1_bio()`: called if the underlying BIO being used by the record layer has
263 data that the record layer should process in one go. By default this is 1.
265 `set_in_init()`: called by libssl to tell the record layer whether we are
275 `increment_sequence_ctr()`: force the record layer to increment its sequence
276 counter. In most cases the record layer will entirely manage its own sequence
278 the record layer with an incremented sequence counter.
280 `alloc_buffers()`: called by libssl to request that the record layer allocate
281 its buffers. This is a hint only and the record layer is expected to manage its
284 `free_buffers()`: called by libssl to request that the record layer free its
285 buffers. This is a hint only and the record layer is expected to manage its own
288 Appendix A: The internal record method API
291 The internal recordmethod.h header file for the record method API:
295 * We use the term "record" here to refer to a packet of data. Records are
297 * always). This usage of the term record is consistent with the TLS concept.
298 * In QUIC the term "record" is not used but it is analogous to the QUIC term
300 * records/packets of data, i.e. (D)TLS and QUIC. The term record is used to
339 * Template for creating a record. A record consists of the |type| of data it
354 * There could be some complexity in finding suitable record layer implementations
391 * the record layer has failed because it is unsuitable, but an alternative
392 * record layer can be tried instead.
446 * Find out the maximum number of records that the record layer is prepared
455 * exit the record layer may update this to an alternative fragment size to
462 * Write |numtempl| records from the array of record templates pointed to
463 * by |templates|. Each record should be no longer than the value returned
467 * same length, except the last record. This may not always be possible so
468 * the record method implementation should not rely on this being the case.
472 * Buffers allocated for the record templates can be freed immediately after
474 * The record templates represent the plaintext payload. The encrypted
496 * Read a record and return the record layer version and record type in
498 * record layer buffer containing the record payload data and |*datalen|
501 * filled in with the epoch and sequence number from the record.
502 * An opaque record layer handle for the record is returned in |*rechandle|
513 * Release a buffer associated with a record previously read with
543 * Called immediately after creation of the record layer if we are in a
549 * Set the maximum number of pipelines that the record layer should process.
555 * Called to tell the record layer whether we are currently "in init" or
556 * not. Default at creation of the record layer is "yes".
561 * Get a short or long human readable description of the record layer state
575 * Set the maximum fragment length to be used for the record layer. This
577 * setting during construction of the record layer.
582 * The maximum expansion in bytes that the record layer might add while
583 * writing a record
588 * Increment the record sequence number
