Route Target Constrained Distribution of Routes with no Route Targets
draft-ietf-idr-rtc-no-rt-12

Request for posting confirmation emailed to previous authors: idr-chairs@ietf.org, Keyur Patel , Jeffrey Haas , Eric Rosen , Robert Raszuk quot; in this
  document are to be interpreted as described in RFC 2119 [REQ].

2.  Usage Model

  The DTLS protocol is designed to secure data between communicating
  applications.  It is designed to run in application space, without
  requiring any kernel modifications.

  Datagram transport does not require or provide reliable or in-order
  delivery of data.  The DTLS protocol preserves this property for
  payload data.  Applications such as media streaming, Internet
  telephony, and online gaming use datagram transport for communication
  due to the delay-sensitive nature of transported data.  The behavior
  of such applications is unchanged when the DTLS protocol is used to
  secure communication, since the DTLS protocol does not compensate for
  lost or re-ordered data traffic.

3.  Overview of DTLS

  The basic design philosophy of DTLS is to construct "TLS over
  datagram transport".  The reason that TLS cannot be used directly in
  datagram environments is simply that packets may be lost or
  reordered.  TLS has no internal facilities to handle this kind of
  unreliability; therefore, TLS implementations break when rehosted on
  datagram transport.  The purpose of DTLS is to make only the minimal
  changes to TLS required to fix this problem.  To the greatest extent
  possible, DTLS is identical to TLS.  Whenever we need to invent new
  mechanisms, we attempt to do so in such a way that preserves the
  style of TLS.

  Unreliability creates problems for TLS at two levels:

      1. TLS does not allow independent decryption of individual
        records.  Because the integrity check depends on the sequence
        number, if record N is not received, then the integrity check
        on record N+1 will be based on the wrong sequence number and
        thus will fail.  (Note that prior to TLS 1.1, there was no
        explicit IV and so decryption would also fail.)

      2. The TLS handshake layer assumes that handshake messages are
        delivered reliably and breaks if those messages are lost.

  The rest of this section describes the approach that DTLS uses to
  solve these problems.

Rescorla & Modadugu          Standards Track                    [Page 5]
RFC 6347                          DTLS                      January 2012

3.1.  Loss-Insensitive Messaging

  In TLS's traffic encryption layer (called the TLS Record Layer),
  records are not independent.  There are two kinds of inter-record
  dependency:

      1. Cryptographic context (stream cipher key stream) is retained
        between records.

      2. Anti-replay and message reordering protection are provided by a
        MAC that includes a sequence number, but the sequence numbers
        are implicit in the records.

  DTLS solves the first problem by banning stream ciphers.  DTLS solves
  the second problem by adding explicit sequence numbers.

3.2.  Providing Reliability for Handshake

  The TLS handshake is a lockstep cryptographic handshake.  Messages
  must be transmitted and received in a defined order; any other order
  is an error.  Clearly, this is incompatible with reordering and
  message loss.  In addition, TLS handshake messages are potentially
  larger than any given datagram, thus creating the problem of IP
  fragmentation.  DTLS must provide fixes for both of these problems.

3.2.1.  Packet Loss

  DTLS uses a simple retransmission timer to handle packet loss.  The
  following figure demonstrates the basic concept, using the first
  phase of the DTLS handshake:

        Client                                  Server
        ------                                  ------
        ClientHello          ------>

                                X<-- HelloVerifyRequest
                                                  (lost)

        [Timer Expires]

        ClientHello          ------>
        (retransmit)

  Once the client has transmitted the ClientHello message, it expects
  to see a HelloVerifyRequest from the server.  However, if the
  server's message is lost, the client knows that either the
  ClientHello or the HelloVerifyRequest has been lost and retransmits.
  When the server receives the retransmission, it knows to retransmit.

Rescorla & Modadugu          Standards Track                    [Page 6]
RFC 6347                          DTLS                      January 2012

  The server also maintains a retransmission timer and retransmits when
  that timer expires.

  Note that timeout and retransmission do not apply to the
  HelloVerifyRequest, because this would require creating state on the
  server.  The HelloVerifyRequest is designed to be small enough that
  it will not itself be fragmented, thus avoiding concerns about
  interleaving multiple HelloVerifyRequests.

3.2.2.  Reordering

  In DTLS, each handshake message is assigned a specific sequence
  number within that handshake.  When a peer receives a handshake
  message, it can quickly determine whether that message is the next
  message it expects.  If it is, then it processes it.  If not, it
  queues it for future handling once all previous messages have been
  received.

3.2.3.  Message Size

  TLS and DTLS handshake messages can be quite large (in theory up to
  2^24-1 bytes, in practice many kilobytes).  By contrast, UDP
  datagrams are often limited to <1500 bytes if IP fragmentation is not
  desired.  In order to compensate for this limitation, each DTLS
  handshake message may be fragmented over several DTLS records, each
  of which is intended to fit in a single IP datagram.  Each DTLS
  handshake message contains both a fragment offset and a fragment
  length.  Thus, a recipient in possession of all bytes of a handshake
  message can reassemble the original unfragmented message.

3.3.  Replay Detection

  DTLS optionally supports record replay detection.  The technique used
  is the same as in IPsec AH/ESP, by maintaining a bitmap window of
  received records.  Records that are too old to fit in the window and
  records that have previously been received are silently discarded.
  The replay detection feature is optional, since packet duplication is
  not always malicious, but can also occur due to routing errors.
  Applications may conceivably detect duplicate packets and accordingly
  modify their data transmission strategy.

4.  Differences from TLS

  As mentioned in Section 3, DTLS is intentionally very similar to TLS.
  Therefore, instead of presenting DTLS as a new protocol, we present
  it as a series of deltas from TLS 1.2 [TLS12].  Where we do not
  explicitly call out differences, DTLS is the same as in [TLS12].

Rescorla & Modadugu          Standards Track                    [Page 7]
RFC 6347                          DTLS                      January 2012

4.1.  Record Layer

  The DTLS record layer is extremely similar to that of TLS 1.2.  The
  only change is the inclusion of an explicit sequence number in the
  record.  This sequence number allows the recipient to correctly
  verify the TLS MAC.  The DTLS record format is shown below:

      struct {
          ContentType type;
          ProtocolVersion version;
          uint16 epoch;                                    // New field
          uint48 sequence_number;                          // New field
          uint16 length;
          opaque fragment[DTLSPlaintext.length];
        } DTLSPlaintext;

  type
      Equivalent to the type field in a TLS 1.2 record.

  version
      The version of the protocol being employed.  This document
      describes DTLS version 1.2, which uses the version { 254, 253 }.
      The version value of 254.253 is the 1's complement of DTLS version
      1.2.  This maximal spacing between TLS and DTLS version numbers
      ensures that records from the two protocols can be easily
      distinguished.  It should be noted that future on-the-wire version
      numbers of DTLS are decreasing in value (while the true version
      number is increasing in value.)

  epoch
      A counter value that is incremented on every cipher state change.

  sequence_number
      The sequence number for this record.

  length
      Identical to the length field in a TLS 1.2 record.  As in TLS 1.2,
      the length should not exceed 2^14.

  fragment
      Identical to the fragment field of a TLS 1.2 record.

  DTLS uses an explicit sequence number, rather than an implicit one,
  carried in the sequence_number field of the record.  Sequence numbers
  are maintained separately for each epoch, with each sequence_number
  initially being 0 for each epoch.  For instance, if a handshake
  message from epoch 0 is retransmitted, it might have a sequence
  number after a message from epoch 1, even if the message from epoch 1

Rescorla & Modadugu          Standards Track                    [Page 8]
RFC 6347                          DTLS                      January 2012

  was transmitted first.  Note that some care needs to be taken during
  the handshake to ensure that retransmitted messages use the right
  epoch and keying material.

  If several handshakes are performed in close succession, there might
  be multiple records on the wire with the same sequence number but
  from different cipher states.  The epoch field allows recipients to
  distinguish such packets.  The epoch number is initially zero and is
  incremented each time a ChangeCipherSpec message is sent.  In order
  to ensure that any given sequence/epoch pair is unique,
  implementations MUST NOT allow the same epoch value to be reused
  within two times the TCP maximum segment lifetime.  In practice, TLS
  implementations rarely rehandshake; therefore, we do not expect this
  to be a problem.

  Note that because DTLS records may be reordered, a record from epoch
  1 may be received after epoch 2 has begun.  In general,
  implementations SHOULD discard packets from earlier epochs, but if
  packet loss causes noticeable problems they MAY choose to retain
  keying material from previous epochs for up to the default MSL
  specified for TCP [TCP] to allow for packet reordering.  (Note that
  the intention here is that implementors use the current guidance from
  the IETF for MSL, not that they attempt to interrogate the MSL that
  the system TCP stack is using.)  Until the handshake has completed,
  implementations MUST accept packets from the old epoch.

  Conversely, it is possible for records that are protected by the
  newly negotiated context to be received prior to the completion of a
  handshake.  For instance, the server may send its Finished message
  and then start transmitting data.  Implementations MAY either buffer
  or discard such packets, though when DTLS is used over reliable
  transports (e.g., SCTP), they SHOULD be buffered and processed once
  the handshake completes.  Note that TLS's restrictions on when
  packets may be sent still apply, and the receiver treats the packets
  as if they were sent in the right order.  In particular, it is still
  impermissible to send data prior to completion of the first
  handshake.

  Note that in the special case of a rehandshake on an existing
  association, it is safe to process a data packet immediately, even if
  the ChangeCipherSpec or Finished messages have not yet been received
  provided that either the rehandshake resumes the existing session or
  that it uses exactly the same security parameters as the existing
  association.  In any other case, the implementation MUST wait for the
  receipt of the Finished message to prevent downgrade attack.

  As in TLS, implementations MUST either abandon an association or
  rehandshake prior to allowing the sequence number to wrap.

Rescorla & Modadugu          Standards Track                    [Page 9]
RFC 6347                          DTLS                      January 2012

  Similarly, implementations MUST NOT allow the epoch to wrap, but
  instead MUST establish a new association, terminating the old
  association as described in Section 4.2.8.  In practice,
  implementations rarely rehandshake repeatedly on the same channel, so
  this is not likely to be an issue.

4.1.1.  Transport Layer Mapping

  Each DTLS record MUST fit within a single datagram.  In order to
  avoid IP fragmentation, clients of the DTLS record layer SHOULD
  attempt to size records so that they fit within any PMTU estimates
  obtained from the record layer.

  Note that unlike IPsec, DTLS records do not contain any association
  identifiers.  Applications must arrange to multiplex between
  associations.  With UDP, this is presumably done with the host/port
  number.

  Multiple DTLS records may be placed in a single datagram.  They are
  simply encoded consecutively.  The DTLS record framing is sufficient
  to determine the boundaries.  Note, however, that the first byte of
  the datagram payload must be the beginning of a record.  Records may
  not span datagrams.

  Some transports, such as DCCP [DCCP] provide their own sequence
  numbers.  When carried over those transports, both the DTLS and the
  transport sequence numbers will be present.  Although this introduces
  a small amount of inefficiency, the transport layer and DTLS sequence
  numbers serve different purposes; therefore, for conceptual
  simplicity, it is superior to use both sequence numbers.  In the
  future, extensions to DTLS may be specified that allow the use of
  only one set of sequence numbers for deployment in constrained
  environments.

  Some transports, such as DCCP, provide congestion control for traffic
  carried over them.  If the congestion window is sufficiently narrow,
  DTLS handshake retransmissions may be held rather than transmitted
  immediately, potentially leading to timeouts and spurious
  retransmission.  When DTLS is used over such transports, care should
  be taken not to overrun the likely congestion window. [DCCPDTLS]
  defines a mapping of DTLS to DCCP that takes these issues into
  account.

4.1.1.1.  PMTU Issues

  In general, DTLS's philosophy is to leave PMTU discovery to the
  application.  However, DTLS cannot completely ignore PMTU for three
  reasons:

Rescorla & Modadugu          Standards Track                  [Page 10]
RFC 6347                          DTLS                      January 2012

  -  The DTLS record framing expands the datagram size, thus lowering
      the effective PMTU from the application's perspective.

  -  In some implementations, the application may not directly talk to
      the network, in which case the DTLS stack may absorb ICMP
      [RFC1191] "Datagram Too Big" indications or ICMPv6 [RFC4443]
      "Packet Too Big" indications.

  -  The DTLS handshake messages can exceed the PMTU.

  In order to deal with the first two issues, the DTLS record layer
  SHOULD behave as described below.

  If PMTU estimates are available from the underlying transport
  protocol, they should be made available to upper layer protocols.  In
  particular:

  -  For DTLS over UDP, the upper layer protocol SHOULD be allowed to
      obtain the PMTU estimate maintained in the IP layer.

  -  For DTLS over DCCP, the upper layer protocol SHOULD be allowed to
      obtain the current estimate of the PMTU.

  -  For DTLS over TCP or SCTP, which automatically fragment and
      reassemble datagrams, there is no PMTU limitation.  However, the
      upper layer protocol MUST NOT write any record that exceeds the
      maximum record size of 2^14 bytes.

  The DTLS record layer SHOULD allow the upper layer protocol to
  discover the amount of record expansion expected by the DTLS
  processing.  Note that this number is only an estimate because of
  block padding and the potential use of DTLS compression.

  If there is a transport protocol indication (either via ICMP or via a
  refusal to send the datagram as in Section 14 of [DCCP]), then the
  DTLS record layer MUST inform the upper layer protocol of the error.

  The DTLS record layer SHOULD NOT interfere with upper layer protocols
  performing PMTU discovery, whether via [RFC1191] or [RFC4821]
  mechanisms.  In particular:

  -  Where allowed by the underlying transport protocol, the upper
      layer protocol SHOULD be allowed to set the state of the DF bit
      (in IPv4) or prohibit local fragmentation (in IPv6).

  -  If the underlying transport protocol allows the application to
      request PMTU probing (e.g., DCCP), the DTLS record layer should
      honor this request.

Rescorla & Modadugu          Standards Track                  [Page 11]
RFC 6347                          DTLS                      January 2012

  The final issue is the DTLS handshake protocol.  From the perspective
  of the DTLS record layer, this is merely another upper layer
  protocol.  However, DTLS handshakes occur infrequently and involve
  only a few round trips; therefore, the handshake protocol PMTU
  handling places a premium on rapid completion over accurate PMTU
  discovery.  In order to allow connections under these circumstances,
  DTLS implementations SHOULD follow the following rules:

  -  If the DTLS record layer informs the DTLS handshake layer that a
      message is too big, it SHOULD immediately attempt to fragment it,
      using any existing information about the PMTU.

  -  If repeated retransmissions do not result in a response, and the
      PMTU is unknown, subsequent retransmissions SHOULD back off to a
      smaller record size, fragmenting the handshake message as
      appropriate.  This standard does not specify an exact number of
      retransmits to attempt before backing off, but 2-3 seems
      appropriate.

4.1.2.  Record Payload Protection

  Like TLS, DTLS transmits data as a series of protected records.  The
  rest of this section describes the details of that format.

4.1.2.1.  MAC

  The DTLS MAC is the same as that of TLS 1.2. However, rather than
  using TLS's implicit sequence number, the sequence number used to
  compute the MAC is the 64-bit value formed by concatenating the epoch
  and the sequence number in the order they appear on the wire.  Note
  that the DTLS epoch + sequence number is the same length as the TLS
  sequence number.

  TLS MAC calculation is parameterized on the protocol version number,
  which, in the case of DTLS, is the on-the-wire version, i.e., {254,
  253} for DTLS 1.2.

  Note that one important difference between DTLS and TLS MAC handling
  is that in TLS, MAC errors must result in connection termination.  In
  DTLS, the receiving implementation MAY simply discard the offending
  record and continue with the connection.  This change is possible
  because DTLS records are not dependent on each other in the way that
  TLS records are.

  In general, DTLS implementations SHOULD silently discard records with
  bad MACs or that are otherwise invalid.  They MAY log an error.  If a
  DTLS implementation chooses to generate an alert when it receives a
  message with an invalid MAC, it MUST generate a bad_record_mac alert

Rescorla & Modadugu          Standards Track                  [Page 12]
RFC 6347                          DTLS                      January 2012

  with level fatal and terminate its connection state.  Note that
  because errors do not cause connection termination, DTLS stacks are
  more efficient error type oracles than TLS stacks.  Thus, it is
  especially important that the advice in Section 6.2.3.2 of [TLS12] be
  followed.

4.1.2.2.  Null or Standard Stream Cipher

  The DTLS NULL cipher is performed exactly as the TLS 1.2 NULL cipher.

  The only stream cipher described in TLS 1.2 is RC4, which cannot be
  randomly accessed.  RC4 MUST NOT be used with DTLS.

4.1.2.3.  Block Cipher

  DTLS block cipher encryption and decryption are performed exactly as
  with TLS 1.2.

4.1.2.4.  AEAD Ciphers

  TLS 1.2 introduced authenticated encryption with additional data
  (AEAD) cipher suites.  The existing AEAD cipher suites, defined in
  [ECCGCM] and [RSAGCM], can be used with DTLS exactly as with TLS 1.2.

4.1.2.5.  New Cipher Suites

  Upon registration, new TLS cipher suites MUST indicate whether they
  are suitable for DTLS usage and what, if any, adaptations must be
  made (see Section 7 for IANA considerations).

4.1.2.6.  Anti-Replay

  DTLS records contain a sequence number to provide replay protection.
  Sequence number verification SHOULD be performed using the following
  sliding window procedure, borrowed from Section 3.4.3 of [ESP].

  The receiver packet counter for this session MUST be initialized to
  zero when the session is established.  For each received record, the
  receiver MUST verify that the record contains a sequence number that
  does not duplicate the sequence number of any other record received
  during the life of this session.  This SHOULD be the first check
  applied to a packet after it has been matched to a session, to speed
  rejection of duplicate records.

  Duplicates are rejected through the use of a sliding receive window.
  (How the window is implemented is a local matter, but the following
  text describes the functionality that the implementation must
  exhibit.)  A minimum window size of 32 MUST be supported, but a

Rescorla & Modadugu          Standards Track                  [Page 13]
RFC 6347                          DTLS                      January 2012

  window size of 64 is preferred and SHOULD be employed as the default.
  Another window size (larger than the minimum) MAY be chosen by the
  receiver.  (The receiver does not notify the sender of the window
  size.)

  The "right" edge of the window represents the highest validated
  sequence number value received on this session.  Records that contain
  sequence numbers lower than the "left" edge of the window are
  rejected.  Packets falling within the window are checked against a
  list of received packets within the window.  An efficient means for
  performing this check, based on the use of a bit mask, is described
  in Section 3.4.3 of [ESP].

  If the received record falls within the window and is new, or if the
  packet is to the right of the window, then the receiver proceeds to
  MAC verification.  If the MAC validation fails, the receiver MUST
  discard the received record as invalid.  The receive window is
  updated only if the MAC verification succeeds.

4.1.2.7.  Handling Invalid Records

  Unlike TLS, DTLS is resilient in the face of invalid records (e.g.,
  invalid formatting, length, MAC, etc.).  In general, invalid records
  SHOULD be silently discarded, thus preserving the association;
  however, an error MAY be logged for diagnostic purposes.
  Implementations which choose to generate an alert instead, MUST
  generate fatal level alerts to avoid attacks where the attacker
  repeatedly probes the implementation to see how it responds to
  various types of error.  Note that if DTLS is run over UDP, then any
  implementation which does this will be extremely susceptible to
  denial-of-service (DoS) attacks because UDP forgery is so easy.
  Thus, this practice is NOT RECOMMENDED for such transports.

  If DTLS is being carried over a transport that is resistant to
  forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts
  because an attacker will have difficulty forging a datagram that will
  not be rejected by the transport layer.

4.2.  The DTLS Handshake Protocol

  DTLS uses all of the same handshake messages and flows as TLS, with
  three principal changes:

      1. A stateless cookie exchange has been added to prevent denial-
        of-service attacks.

Rescorla & Modadugu          Standards Track                  [Page 14]
RFC 6347                          DTLS                      January 2012

      2. Modifications to the handshake header to handle message loss,
        reordering, and DTLS message fragmentation (in order to avoid
        IP fragmentation).

      3. Retransmission timers to handle message loss.

  With these exceptions, the DTLS message formats, flows, and logic are
  the same as those of TLS 1.2.

4.2.1.  Denial-of-Service Countermeasures

  Datagram security protocols are extremely susceptible to a variety of
  DoS attacks.  Two attacks are of particular concern:

      1. An attacker can consume excessive resources on the server by
        transmitting a series of handshake initiation requests, causing
        the server to allocate state and potentially to perform
        expensive cryptographic operations.

      2. An attacker can use the server as an amplifier by sending
        connection initiation messages with a forged source of the
        victim.  The server then sends its next message (in DTLS, a
        Certificate message, which can be quite large) to the victim
        machine, thus flooding it.

  In order to counter both of these attacks, DTLS borrows the stateless
  cookie technique used by Photuris [PHOTURIS] and IKE [IKEv2].  When
  the client sends its ClientHello message to the server, the server
  MAY respond with a HelloVerifyRequest message.  This message contains
  a stateless cookie generated using the technique of [PHOTURIS].  The
  client MUST retransmit the ClientHello with the cookie added.  The
  server then verifies the cookie and proceeds with the handshake only
  if it is valid.  This mechanism forces the attacker/client to be able
  to receive the cookie, which makes DoS attacks with spoofed IP
  addresses difficult.  This mechanism does not provide any defense
  against DoS attacks mounted from valid IP addresses.

Rescorla & Modadugu          Standards Track                  [Page 15]
RFC 6347                          DTLS                      January 2012

  The exchange is shown below:

      Client                                  Server
      ------                                  ------
      ClientHello          ------>

                            <----- HelloVerifyRequest
                                  (contains cookie)

      ClientHello          ------>
      (with cookie)

      [Rest of handshake]

  DTLS therefore modifies the ClientHello message to add the cookie
  value.

  struct {
    ProtocolVersion client_version;
    Random random;
    SessionID session_id;
    opaque cookie<0..2^8-1>;                            // New field
    CipherSuite cipher_suites<2..2^16-1>;
          CompressionMethod compression_methods<1..2^8-1>;
  } ClientHello;

  When sending the first ClientHello, the client does not have a cookie
  yet; in this case, the Cookie field is left empty (zero length).

  The definition of HelloVerifyRequest is as follows:

  struct {
    ProtocolVersion server_version;
    opaque cookie<0..2^8-1>;
  } HelloVerifyRequest;

  The HelloVerifyRequest message type is hello_verify_request(3).

  The server_version field has the same syntax as in TLS.  However, in
  order to avoid the requirement to do version negotiation in the
  initial handshake, DTLS 1.2 server implementations SHOULD use DTLS
  version 1.0 regardless of the version of TLS that is expected to be
  negotiated.  DTLS 1.2 and 1.0 clients MUST use the version solely to
  indicate packet formatting (which is the same in both DTLS 1.2 and
  1.0) and not as part of version negotiation.  In particular, DTLS 1.2
  clients MUST NOT assume that because the server uses version 1.0 in
  the HelloVerifyRequest that the server is not DTLS 1.2 or that it
  will eventually negotiate DTLS 1.0 rather than DTLS 1.2.

Rescorla & Modadugu          Standards Track                  [Page 16]
RFC 6347                          DTLS                      January 2012

  When responding to a HelloVerifyRequest, the client MUST use the same
  parameter values (version, random, session_id, cipher_suites,
  compression_method) as it did in the original ClientHello.  The
  server SHOULD use those values to generate its cookie and verify that
  they are correct upon cookie receipt.  The server MUST use the same
  version number in the HelloVerifyRequest that it would use when
  sending a ServerHello.  Upon receipt of the ServerHello, the client
  MUST verify that the server version values match.  In order to avoid
  sequence number duplication in case of multiple HelloVerifyRequests,
  the server MUST use the record sequence number in the ClientHello as
  the record sequence number in the HelloVerifyRequest.

  Note: This specification increases the cookie size limit to 255 bytes
  for greater future flexibility.  The limit remains 32 for previous
  versions of DTLS.

  The DTLS server SHOULD generate cookies in such a way that they can
  be verified without retaining any per-client state on the server.
  One technique is to have a randomly generated secret and generate
  cookies as:

      Cookie = HMAC(Secret, Client-IP, Client-Parameters)

  When the second ClientHello is received, the server can verify that
  the Cookie is valid and that the client can receive packets at the
  given IP address.  In order to avoid sequence number duplication in
  case of multiple cookie exchanges, the server MUST use the record
  sequence number in the ClientHello as the record sequence number in
  its initial ServerHello.  Subsequent ServerHellos will only be sent
  after the server has created state and MUST increment normally.

  One potential attack on this scheme is for the attacker to collect a
  number of cookies from different addresses and then reuse them to
  attack the server.  The server can defend against this attack by
  changing the Secret value frequently, thus invalidating those
  cookies.  If the server wishes that legitimate clients be able to
  handshake through the transition (e.g., they received a cookie with
  Secret 1 and then sent the second ClientHello after the server has
  changed to Secret 2), the server can have a limited window during
  which it accepts both secrets.  [IKEv2] suggests adding a version
  number to cookies to detect this case.  An alternative approach is
  simply to try verifying with both secrets.

  DTLS servers SHOULD perform a cookie exchange whenever a new
  handshake is being performed.  If the server is being operated in an
  environment where amplification is not a problem, the server MAY be
  configured not to perform a cookie exchange.  The default SHOULD be
  that the exchange is performed, however.  In addition, the server MAY

Rescorla & Modadugu          Standards Track                  [Page 17]
RFC 6347                          DTLS                      January 2012

  choose not to do a cookie exchange when a session is resumed.
  Clients MUST be prepared to do a cookie exchange with every
  handshake.

  If HelloVerifyRequest is used, the initial ClientHello and
  HelloVerifyRequest are not included in the calculation of the
  handshake_messages (for the CertificateVerify message) and
  verify_data (for the Finished message).

  If a server receives a ClientHello with an invalid cookie, it SHOULD
  treat it the same as a ClientHello with no cookie.  This avoids
  race/deadlock conditions if the client somehow gets a bad cookie
  (e.g., because the server changes its cookie signing key).

  Note to implementors: This may result in clients receiving multiple
  HelloVerifyRequest messages with different cookies.  Clients SHOULD
  handle this by sending a new ClientHello with a cookie in response to
  the new HelloVerifyRequest.

4.2.2.  Handshake Message Format

  In order to support message loss, reordering, and message
  fragmentation, DTLS modifies the TLS 1.2 handshake header:

  struct {
    HandshakeType msg_type;
    uint24 length;
    uint16 message_seq;                              // New field
    uint24 fragment_offset;                          // New field
    uint24 fragment_length;                          // New field
    select (HandshakeType) {
      case hello_request: HelloRequest;
      case client_hello:  ClientHello;
      case hello_verify_request: HelloVerifyRequest;  // New type
      case server_hello:  ServerHello;
      case certificate:Certificate;
      case server_key_exchange: ServerKeyExchange;
      case certificate_request: CertificateRequest;
      case server_hello_done:ServerHelloDone;
      case certificate_verify:  CertificateVerify;
      case client_key_exchange: ClientKeyExchange;
      case finished: Finished;
    } body;
  } Handshake;

  The first message each side transmits in each handshake always has
  message_seq = 0.  Whenever each new message is generated, the
  message_seq value is incremented by one.  Note that in the case of a

Rescorla & Modadugu          Standards Track                  [Page 18]
RFC 6347                          DTLS                      January 2012

  rehandshake, this implies that the HelloRequest will have message_seq
  = 0 and the ServerHello will have message_seq = 1.  When a message is
  retransmitted, the same message_seq value is used.  For example:

        Client                            Server
        ------                            ------
        ClientHello (seq=0)  ------>

                                X<-- HelloVerifyRequest (seq=0)
                                                (lost)

        [Timer Expires]

        ClientHello (seq=0)  ------>
        (retransmit)

                              <------ HelloVerifyRequest (seq=0)

        ClientHello (seq=1)  ------>
        (with cookie)

                              <------        ServerHello (seq=1)
                              <------        Certificate (seq=2)
                              <------    ServerHelloDone (seq=3)

        [Rest of handshake]

  Note, however, that from the perspective of the DTLS record layer,
  the retransmission is a new record.  This record will have a new
  DTLSPlaintext.sequence_number value.

  DTLS implementations maintain (at least notionally) a
  next_receive_seq counter.  This counter is initially set to zero.
  When a message is received, if its sequence number matches
  next_receive_seq, next_receive_seq is incremented and the message is
  processed.  If the sequence number is less than next_receive_seq, the
  message MUST be discarded.  If the sequence number is greater than
  next_receive_seq, the implementation SHOULD queue the message but MAY
  discard it.  (This is a simple space/bandwidth tradeoff).

4.2.3.  Handshake Message Fragmentation and Reassembly

  As noted in Section 4.1.1, each DTLS message MUST fit within a single
  transport layer datagram.  However, handshake messages are
  potentially bigger than the maximum record size.  Therefore, DTLS
  provides a mechanism for fragmenting a handshake message over a
  number of records, each of which can be transmitted separately, thus
  avoiding IP fragmentation.

Rescorla & Modadugu          Standards Track                  [Page 19]
RFC 6347                          DTLS                      January 2012

  When transmitting the handshake message, the sender divides the
  message into a series of N contiguous data ranges.  These ranges MUST
  NOT be larger than the maximum handshake fragment size and MUST
  jointly contain the entire handshake message.  The ranges SHOULD NOT
  overlap.  The sender then creates N handshake messages, all with the
  same message_seq value as the original handshake message.  Each new
  message is labeled with the fragment_offset (the number of bytes
  contained in previous fragments) and the fragment_length (the length
  of this fragment).  The length field in all messages is the same as
  the length field of the original message.  An unfragmented message is
  a degenerate case with fragment_offset=0 and fragment_length=length.

  When a DTLS implementation receives a handshake message fragment, it
  MUST buffer it until it has the entire handshake message.  DTLS
  implementations MUST be able to handle overlapping fragment ranges.
  This allows senders to retransmit handshake messages with smaller
  fragment sizes if the PMTU estimate changes.

  Note that as with TLS, multiple handshake messages may be placed in
  the same DTLS record, provided that there is room and that they are
  part of the same flight.  Thus, there are two acceptable ways to pack
  two DTLS messages into the same datagram: in the same record or in
  separate records.

4.2.4.  Timeout and Retransmission

  DTLS messages are grouped into a series of message flights, according
  to the diagrams below.  Although each flight of messages may consist
  of a number of messages, they should be viewed as monolithic for the
  purpose of timeout and retransmission.

Rescorla & Modadugu          Standards Track                  [Page 20]
RFC 6347                          DTLS                      January 2012

  Client                                          Server
  ------                                          ------

  ClientHello            -------->                          Flight 1

                          <-------    HelloVerifyRequest      Flight 2

  ClientHello            -------->                          Flight 3

                                              ServerHello    \
                                            Certificate*    \
                                      ServerKeyExchange*      Flight 4
                                      CertificateRequest*    /
                          <--------      ServerHelloDone    /

  Certificate*                                              \
  ClientKeyExchange                                          \
  CertificateVerify*                                          Flight 5
  [ChangeCipherSpec]                                        /
  Finished                -------->                        /

                                      [ChangeCipherSpec]    \ Flight 6
                          <--------            Finished    /

              Figure 1. Message Flights for Full Handshake

  Client                                          Server
  ------                                          ------

  ClientHello            -------->                          Flight 1

                                              ServerHello    \
                                      [ChangeCipherSpec]    Flight 2
                            <--------            Finished    /

  [ChangeCipherSpec]                                        \Flight 3
  Finished                -------->                        /

        Figure 2. Message Flights for Session-Resuming Handshake
                          (No Cookie Exchange)

  DTLS uses a simple timeout and retransmission scheme with the
  following state machine.  Because DTLS clients send the first message
  (ClientHello), they start in the PREPARING state.  DTLS servers start
  in the WAITING state, but with empty buffers and no retransmit timer.

Rescorla & Modadugu          Standards Track                  [Page 21]
RFC 6347                          DTLS                      January 2012

                      +-----------+
                      | PREPARING |
                +---> |          | &