Struct trust_dns_proto::rr::rdata::svcb::Alpn

source · [−]

#[repr(transparent)]
pub struct Alpn(pub Vec<String>);

Expand description

draft-ietf-dnsop-svcb-https-03 SVCB and HTTPS RRs for DNS, February 2021

6.1.  "alpn" and "no-default-alpn"

  The "alpn" and "no-default-alpn" SvcParamKeys together indicate the
  set of Application Layer Protocol Negotiation (ALPN) protocol
  identifiers [ALPN] and associated transport protocols supported by
  this service endpoint.

  As with Alt-Svc [AltSvc], the ALPN protocol identifier is used to
  identify the application protocol and associated suite of protocols
  supported by the endpoint (the "protocol suite").  Clients filter the
  set of ALPN identifiers to match the protocol suites they support,
  and this informs the underlying transport protocol used (such as
  QUIC-over-UDP or TLS-over-TCP).

  ALPNs are identified by their registered "Identification Sequence"
  ("alpn-id"), which is a sequence of 1-255 octets.

  alpn-id = 1*255OCTET

  The presentation "value" SHALL be a comma-separated list
  (Appendix A.1) of one or more "alpn-id"s.

  The wire format value for "alpn" consists of at least one "alpn-id"
  prefixed by its length as a single octet, and these length-value
  pairs are concatenated to form the SvcParamValue.  These pairs MUST
  exactly fill the SvcParamValue; otherwise, the SvcParamValue is
  malformed.

  For "no-default-alpn", the presentation and wire format values MUST
  be empty.  When "no-default-alpn" is specified in an RR, "alpn" must
  also be specified in order for the RR to be "self-consistent"
  (Section 2.4.3).

  Each scheme that uses this SvcParamKey defines a "default set" of
  supported ALPNs, which SHOULD NOT be empty.  To determine the set of
  protocol suites supported by an endpoint (the "SVCB ALPN set"), the
  client adds the default set to the list of "alpn-id"s unless the "no-
  default-alpn" SvcParamKey is present.  The presence of an ALPN
  protocol in the SVCB ALPN set indicates that this service endpoint,
  described by TargetName and the other parameters (e.g. "port") offers
  service with the protocol suite associated with this ALPN protocol.

  ALPN protocol names that do not uniquely identify a protocol suite
  (e.g. an Identification Sequence that can be used with both TLS and
  DTLS) are not compatible with this SvcParamKey and MUST NOT be
  included in the SVCB ALPN set.

  To establish a connection to the endpoint, clients MUST

  1.  Let SVCB-ALPN-Intersection be the set of protocols in the SVCB
      ALPN set that the client supports.

  2.  Let Intersection-Transports be the set of transports (e.g.  TLS,
      DTLS, QUIC) implied by the protocols in SVCB-ALPN-Intersection.

  3.  For each transport in Intersection-Transports, construct a
      ProtocolNameList containing the Identification Sequences of all
      the client's supported ALPN protocols for that transport, without
      regard to the SVCB ALPN set.

  For example, if the SVCB ALPN set is ["http/1.1", "h3"], and the
  client supports HTTP/1.1, HTTP/2, and HTTP/3, the client could
  attempt to connect using TLS over TCP with a ProtocolNameList of
  ["http/1.1", "h2"], and could also attempt a connection using QUIC,
  with a ProtocolNameList of ["h3"].

  Once the client has constructed a ClientHello, protocol negotiation
  in that handshake proceeds as specified in [ALPN], without regard to
  the SVCB ALPN set.

  With this procedure in place, an attacker who can modify DNS and
  network traffic can prevent a successful transport connection, but
  cannot otherwise interfere with ALPN protocol selection.  This
  procedure also ensures that each ProtocolNameList includes at least
  one protocol from the SVCB ALPN set.

  Clients SHOULD NOT attempt connection to a service endpoint whose
  SVCB ALPN set does not contain any supported protocols.  To ensure
  consistency of behavior, clients MAY reject the entire SVCB RRSet and
  fall back to basic connection establishment if all of the RRs
  indicate "no-default-alpn", even if connection could have succeeded
  using a non-default alpn.

  For compatibility with clients that require default transports, zone
  operators SHOULD ensure that at least one RR in each RRSet supports
  the default transports.

Tuple Fields

0: Vec<String>

Trait Implementations

source

impl<'r> BinDecodable<'r> for Alpn

source

fn read(decoder: &mut BinDecoder<'r>) -> ProtoResult<Self>

This expects the decoder to be limited to only this field, i.e. the end of input for the decoder is the end of input for the fields

  The wire format value for "alpn" consists of at least one "alpn-id"
  prefixed by its length as a single octet, and these length-value
  pairs are concatenated to form the SvcParamValue.  These pairs MUST
  exactly fill the SvcParamValue; otherwise, the SvcParamValue is
  malformed.

source

fn from_bytes(bytes: &'r [u8 ]) -> ProtoResult<Self>

Returns the object in binary form

source

impl BinEncodable for Alpn

source

fn emit(&self, encoder: &mut BinEncoder<'_>) -> ProtoResult<()>

The wire format value for “alpn” consists of at least one “alpn-id” prefixed by its length as a single octet, and these length-value pairs are concatenated to form the SvcParamValue. These pairs MUST exactly fill the SvcParamValue; otherwise, the SvcParamValue is malformed.

source