<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC6347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!ENTITY RFC7250 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7250.xml">
<!ENTITY RFC7918 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7918.xml">
<!ENTITY RFC7924 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7924.xml">
<!ENTITY RFC8094 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8094.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="no" ?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     category="std"
     obsoletes=""
     number="8968"
     docName="draft-ietf-babel-dtls-10"
    ipr="trust200902">
     ipr="trust200902"
     updates=""
     submissionType="IETF"
     consensus="true"
     xml:lang="en"
     tocInclude="true"
     tocDepth="2"
     symRefs="true"
     sortRefs="true"
     version="3">
  <!-- xml2rfc v2v3 conversion 3.0.0 -->
  <front>
    <title abbrev="Babel over DTLS">Babel Routing Protocol over Datagram
Transport Layer Security</title>
    <seriesInfo name="RFC" value="8968"/>
    <author fullname="Antonin Decimo" Décimo" initials="A." surname="Decimo"> surname="Décimo">
      <organization>IRIF, University of Paris-Diderot</organization>
      <address>
        <postal>
<street></street>
          <city>Paris</city>
<region></region>
<code></code>
          <country>France</country>
        </postal>
        <email>antonin.decimo@gmail.com</email>
      </address>
    </author>
    <author fullname='David Schinazi' surname='Schinazi' initials='D.'> fullname="David Schinazi" surname="Schinazi" initials="D.">
      <organization>Google LLC</organization>
      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>
          <city>Mountain View</city>
<region>California</region>
          <region>CA</region>
          <code>94043</code>
<country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>dschinazi.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek">
      <organization>IRIF, University of Paris-Diderot</organization>
      <address>
        <postal>
          <street>Case 7014</street>
<city>75205 Paris Cedex
          <city>Paris CEDEX 13</city>
<region></region>
<code></code>
          <code>75205</code>
          <country>France</country>
        </postal>
        <email>jch@irif.fr</email>
      </address>
    </author>

<date/>
    <date month="January" year="2021"/>

    <abstract>
      <t>The Babel Routing Protocol does not contain any means to authenticate
neighbours or provide integrity or confidentiality for messages sent between
them.  This document specifies a mechanism to ensure these properties, properties using
Datagram Transport Layer Security (DTLS).</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Babel Routing Protocol routing protocol <xref target="RFC6126bis"/> target="RFC8966" format="default"/> does not contain
any means to authenticate neighbours or protect messages sent between them.
Because of this, an attacker is able to send maliciously crafted Babel
messages which that could lead a network to route traffic to an attacker or
to an under-resourced target target, causing denial of service.
This document specifies a mechanism to prevent such attacks, attacks using
Datagram Transport Layer Security (DTLS) <xref target="RFC6347"/>.</t> target="RFC6347" format="default"/>.</t>
      <section title="Specification numbered="true" toc="default">

        <name>Specification of Requirements">

<t>The Requirements</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
"OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP
14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>

      <section title="Applicability"> numbered="true" toc="default">
        <name>Applicability</name>
        <t>The protocol described in this document protects Babel packets with
DTLS.  As such, it inherits the features offered by DTLS, notably
authentication, integrity, optional replay protection, confidentiality confidentiality, and
asymmetric keying.  It is therefore expected to be applicable in a wide
range of environments.</t>
        <t>There exists another mechanism for securing Babel, namely Babel HMAC Message Authentication Code (MAC)
authentication for Babel (Babel-MAC) <xref target="BABEL-HMAC"/>.  HMAC target="RFC8967" format="default"/>.  Babel-MAC only offers basic
features, namely authentication, integrity integrity, and replay protection with
a small number of symmetric keys.  A comparison of Babel security mechanisms
and their applicability can be found in <xref target="RFC6126bis"/>.</t> target="RFC8966" format="default"/>.</t>
        <t>Note that Babel over DTLS provides a single authentication domain, meaning
that all nodes that have the right credentials can convey any and all routing
information.</t>
        <t>DTLS supports several mechanisms by which nodes can identify themselves
and prove possession of secrets tied to these identities.  This document
does not prescribe which of these mechanisms to use; details of identity
management are left to deployment profiles of Babel over DTLS.</t>
      </section>
    </section>
    <section title="Operation numbered="true" toc="default">
      <name>Operation of the Protocol"> Protocol</name>
      <t>Babel over DTLS requires some changes to how Babel operates.
First, DTLS is a client-server protocol, while Babel is a peer-to-peer
protocol.  Second, DTLS can only protect unicast communication, while
Babel packets can be sent to both unicast and multicast destinations.</t>
      <section title="DTLS numbered="true" toc="default">
        <name>DTLS Connection Initiation"> Initiation</name>
        <t>Babel over DTLS operates on a different port than unencrypted Babel.
All Babel over DTLS nodes MUST <bcp14>MUST</bcp14> act as DTLS servers on a given UDP port, port
and MUST <bcp14>MUST</bcp14> listen for unencrypted Babel traffic on another UDP port, which
MUST
<bcp14>MUST</bcp14> be distinct from the first one.  The default port for Babel over DTLS is
registered with IANA as the "babel-dtls" port (UDP port TBD, 6699, see
<xref target="iana_considerations"/>), target="iana_considerations" format="default"/>), and the port exchanging unencrypted
Babel traffic is registered as the "babel" port (UDP port 6696,
see Section 5 of <xref target="RFC6126bis"/>).</t> target="RFC8966" sectionFormat="of" section="5"/>).</t>
        <t>When a Babel node discovers a new neighbour (generally by
receiving an unencrypted multicast Babel packet), it compares the neighbour's
IP address with its own, using network byte ordering.  If a node's
address is lower than the recently discovered neighbour's address, it acts
as a client and connects to the neighbour.  In other words, the node with
the lowest address is the DTLS client for this pairwise relationship.
As an example, fe80::1:2 is considered lower than fe80::2:1.</t>
        <t>The node acting as DTLS client initiates its DTLS connection from an
ephemeral UDP port.  Nodes SHOULD <bcp14>SHOULD</bcp14> ensure that new client DTLS connections
use different ephemeral ports from recently used connections to allow
servers to differentiate between the new and old DTLS connections.
Alternatively, nodes could use DTLS connection identifiers
<xref target="DTLS-CID"/> target="I-D.ietf-tls-dtls-connection-id" format="default"/> as a higher-entropy mechanism to distinguish between
connections.</t>
        <t>When a node receives a new DTLS connection, it MUST <bcp14>MUST</bcp14> verify that the source
IP address is either an IPv6 link-local address or an IPv4 address belonging
to the local network; if it is neither, it MUST <bcp14>MUST</bcp14> reject the
connection.  Nodes use mutual authentication (authenticating
both client and server); clients MUST <bcp14>MUST</bcp14> authenticate servers and servers MUST <bcp14>MUST</bcp14>
authenticate clients.  Implementations MUST <bcp14>MUST</bcp14> support
authenticating peers against a local store of credentials.  If either node
fails to authenticate its peer against its local policy, it MUST <bcp14>MUST</bcp14> abort the DTLS
handshake.  The guidance given in <xref target="BCP195"/> MUST target="BCP195" format="default"/> <bcp14>MUST</bcp14> be followed to
avoid attacks on DTLS.  Additionally, nodes MUST <bcp14>MUST</bcp14> only negotiate DTLS version
1.2 or higher.  Nodes MUST <bcp14>MUST</bcp14>
use DTLS replay protection to prevent attackers from replaying stale
information.  Nodes SHOULD <bcp14>SHOULD</bcp14> drop packets that have been reordered by more than
two IHU (I Heard You) intervals, to avoid letting attackers make stale
information last longer.  If a node receives a new DTLS connection from a
neighbour to whom it already has a connection, the node MUST NOT <bcp14>MUST NOT</bcp14> discard the
older connection until it has completed the handshake of the new one and
validated the identity of the peer.</t>
      </section>
      <section title="Protocol Encoding"> numbered="true" toc="default">
        <name>Protocol Encoding</name>
        <t>Babel over DTLS sends all unicast Babel packets protected by DTLS.  The
entire Babel packet, from the Magic byte at the start of the Babel header
to the last byte of the Babel packet trailer, is sent protected by DTLS.</t>
      </section>
      <section title="Transmission"> numbered="true" toc="default">
        <name>Transmission</name>
        <t>When sending packets, Babel over DTLS nodes MUST NOT <bcp14>MUST NOT</bcp14> send any TLVs over
the unprotected "babel" port, with the exception of Hello TLVs without the
Unicast flag set.  Babel over DTLS nodes MUST NOT <bcp14>MUST NOT</bcp14> send any unprotected unicast
packets.  This ensures the confidentiality of the information sent in Babel
packets (e.g., the network topology) by only sending it encrypted by DTLS.
Unless some out-of-band neighbour discovery mechanism is available,
nodes SHOULD <bcp14>SHOULD</bcp14> periodically send unprotected multicast Multicast Hellos to ensure
discovery of new neighbours.  In order to maintain bidirectional reachability,
nodes can either rely entirely on unprotected multicast Multicast Hellos, or send
protected unicast Unicast Hellos in addition to the multicast Multicast Hellos.</t>
        <t>Since Babel over DTLS only protects unicast packets, implementors may
implement Babel over DTLS by modifying an implementation of Babel without DTLS
support,
support and replacing any TLV previously sent over multicast with a separate
TLV sent over unicast for each neighbour.  TLVs previously sent over multicast
can be replaced with the same contents over unicast, with the exception of
Hellos as described above.  Some implementations could also change the contents
of IHU TLVs when converting to unicast in order to remove redundant
information.</t>
      </section>
      <section title="Reception"> numbered="true" toc="default">
        <name>Reception</name>
        <t>Babel over DTLS nodes can receive Babel packets either protected over a
DTLS connection, connection or unprotected directly over the "babel" port.  To ensure the
security properties of this mechanism, unprotected packets are treated
differently.  Nodes MUST <bcp14>MUST</bcp14> silently ignore any unprotected packet sent over
unicast.  When parsing an unprotected packet, a node MUST <bcp14>MUST</bcp14> silently
ignore all TLVs that are not of type Hello.  Nodes MUST <bcp14>MUST</bcp14> also silently ignore
any unprotected Hello with the Unicast flag set.  Note that receiving an
unprotected packet can still be used to discover new neighbours, even when
all TLVs in that packet are silently ignored.</t>
      </section>
      <section title="Neighbour table entry"> numbered="true" toc="default">
        <name>Neighbour Table Entry</name>
        <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> for nodes to associate the state of their DTLS connection
with their neighbour table.  When a neighbour entry is flushed from the
neighbour table (Appendix A of <xref target="RFC6126bis"/>), (<xref target="RFC8966" section="A" sectionFormat="of" format="default"/>), its associated
DTLS state SHOULD <bcp14>SHOULD</bcp14> be discarded.  The node SHOULD <bcp14>SHOULD</bcp14> send a DTLS close_notify alert
to the neighbour if it believes the link is still viable.</t>
      </section>
      <section title="Simultaneous operation numbered="true" toc="default">
        <name>Simultaneous Operation of both Babel over DTLS and unprotected Unprotected Babel on a Node"> Node</name>
        <t>Implementations MAY <bcp14>MAY</bcp14> implement both Babel over DTLS and unprotected Babel.
Additionally, a node MAY <bcp14>MAY</bcp14> simultaneously run both Babel over DTLS and
unprotected Babel. However, a node running both MUST <bcp14>MUST</bcp14> ensure that it runs
them on separate interfaces, as the security properties of Babel over DTLS
rely on not accepting ignoring unprotected Babel packets (other than multicast Multicast Hellos).
An implementation MAY <bcp14>MAY</bcp14> offer configuration options to allow unprotected Babel on
some interfaces but not others; this others, which effectively gives nodes on that interface
the same access as authenticated nodes, and SHOULD NOT nodes; however, this <bcp14>SHOULD NOT</bcp14> be done unless that
interface has a mechanism to authenticate nodes at a lower
layer (e.g., IPsec).</t>
      </section>
      <section title="Simultaneous operation numbered="true" toc="default">
        <name>Simultaneous Operation of both Babel over DTLS and unprotected Unprotected Babel on a Network"> Network</name>
        <t>If Babel over DTLS and unprotected Babel are both operated on the same
network, the Babel over DTLS implementation will receive unprotected multicast Multicast
Hellos and attempt to initiate a DTLS connection.  These connection attempts
can be sent to nodes that only run unprotected Babel, who will not
respond.  Babel over DTLS implementations SHOULD <bcp14>SHOULD</bcp14> therefore rate-limit their
DTLS connection attempts to avoid causing undue load on the network.</t>
      </section>
    </section>
    <section title="Interface numbered="true" toc="default">
      <name>Interface Maximum Transmission Unit Issues"> Issues</name>
      <t>Compared to unprotected Babel, DTLS adds header, authentication tag tag, and
possibly block-size padding overhead to every packet.  This reduces the size of
the Babel payload that can be carried.  This document does not relax the
packet size requirements in Section 4 of <xref target="RFC6126bis"/>, target="RFC8966" sectionFormat="of" section="4"/> but
recommends that DTLS overhead be taken into account when computing maximum
packet size.</t>
      <t> More precisely, nodes SHOULD <bcp14>SHOULD</bcp14> compute the overhead of DTLS depending on
the ciphersuites in use, use and SHOULD NOT <bcp14>SHOULD NOT</bcp14> send Babel packets larger than the
interface maximum transmission unit (MTU) minus the overhead of IP, UDP UDP,
and DTLS.  Nodes MUST NOT <bcp14>MUST NOT</bcp14> send Babel packets larger than the attached
interface's MTU adjusted for known lower-layer headers (at least UDP and
IP) or 512 octets, whichever is larger, but not exceeding 2^16 2<sup>16</sup> -
1 adjusted for lower-layer headers.  Every Babel speaker MUST <bcp14>MUST</bcp14> be able to
receive packets that are as large as any attached interface's MTU adjusted
for UDP and IP headers or 512 octets, whichever is larger.  Note that this
requirement on reception does not take into account the overhead of DTLS
because the peer may not have the ability to compute the overhead of DTLS DTLS,
and the packet may be fragmented by lower layers.</t>
      <t>Note that distinct DTLS connections can use different ciphers, which can
have different amounts of per-packet overhead.  Therefore, the MTU to one
neighbour can be different from the MTU to another neighbour on the same
link.</t>
    </section>
    <section title="IANA Considerations" anchor="iana_considerations">

<t>If this document is approved, IANA is requested to register anchor="iana_considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA has registered a UDP port
number, called "babel-dtls", for use by Babel over DTLS.  Details of the
request to IANA are as follows:
<list style="symbols">
<t>Assignee: IESG, iesg@ietf.org</t>
<t>Contact Person: IETF Chair, chair@ietf.org</t>
<t>Transport Protocols: DTLS:
</t>
      <ul empty="true"><li>
      <dl spacing="normal">
        <dt>Service Name:</dt><dd> babel-dtls</dd>
        <dt>Port Number:</dt><dd> 6699</dd>
        <dt>Transport Protocols:</dt><dd> UDP only</t>
<t>Service Code: None</t>
<t>Service Name: babel-dtls</t>
<t>Desired Port Number: 6699</t>
<t>Description: only</dd>
        <dt>Description:</dt><dd> Babel Routing Protocol over DTLS</t>
<t>Reference: This document</t>
<t>Defined TXT Keys: None</t>
</list>
</t> DTLS</dd>
        <dt>Assignee:</dt><dd> IESG, iesg@ietf.org</dd>
        <dt>Contact:</dt><dd> IETF Chair, chair@ietf.org</dd>
        <dt>Reference:</dt><dd> RFC 8968</dd>
        <dt>Service Code:</dt><dd> None</dd>
      </dl>
      </li>
      </ul>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>A malicious client might attempt to perform a high number of DTLS
handshakes with a server.  As the clients are not uniquely identified
by the protocol until the handshake completes and can be obfuscated with IPv6
temporary addresses, a server needs to mitigate the impact of such an attack.
Note that attackers might attempt to keep in-progress handshakes open for as
long as possible by using variants on the attack commonly known as
Slowloris <xref target="SLOWLORIS"/>. target="SLOWLORIS" format="default"/>.  Mitigating these attacks might involve
rate
limiting the rate of handshakes from a given subnet or more advanced denial of
service avoidance techniques beyond the scope of this document.</t>
      <t>Babel over DTLS allows sending multicast Multicast Hellos unprotected; attackers can
therefore tamper with them.  For example, an attacker could send erroneous
values for the Seqno and Interval fields, causing bidirectional
reachability detection to fail.  While implementations MAY <bcp14>MAY</bcp14> use multicast Multicast Hellos
for link quality estimation, they SHOULD <bcp14>SHOULD</bcp14> also emit protected unicast Unicast Hellos to
prevent this class of denial-of-service attack.</t>
      <t>While DTLS provides protection against an attacker that replays valid
packets, DTLS is not able to detect when an active on-path attacker intercepts
valid packets and resends them at a later time.  This attack could be used to
make a node believe it has bidirectional reachability to a neighbour even
though that neighbour has disconnected from the network.  To prevent this
attack, nodes MUST <bcp14>MUST</bcp14> discard the DTLS state associated with a neighbour after a
finite time of not receiving valid DTLS packets.  This can be implemented by,
for example, discarding a neighbour's DTLS state when its associated IHU timer
fires. Note that relying solely on the receipt of Hellos is not sufficient as
multicast
Multicast Hellos are sent unprotected.  Additionally, an attacker could save
some packets and replay them later in hopes of propagating stale routing
information at a later time.  This can be mitigated by discarding received
packets that have been reordered by more than two IHU intervals.</t>
    </section>
  </middle>
  <back>

<references title="Normative References">

&RFC2119;
&RFC6347;

<displayreference target="I-D.ietf-tls-dtls-connection-id" to="DTLS-CID"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/>

<reference anchor="BCP195" target="https://www.rfc-editor.org/info/bcp195"> anchor='BCP195' target='https://www.rfc-editor.org/info/bcp195'>
<front>
<title>
Recommendations
<title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
</title> (DTLS)</title>
<author initials="Y." surname="Sheffer" fullname="Y. Sheffer">
<organization/>
</author> initials='Y.' surname='Sheffer' fullname='Y. Sheffer'><organization /></author>
<author initials="R." surname="Holz" fullname="R. Holz">
<organization/>
</author> initials='R.' surname='Holz' fullname='R. Holz'><organization /></author>
<author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre">
<organization/>
</author> initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'><organization /></author>
<date year="2015" month="May"/>
<abstract>
<t>
Transport year='2015' month='May' />
<abstract><t>Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP.  Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation.  This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases.
</t>
</abstract> cases.</t></abstract>
</front>
<seriesInfo name="BCP" value="195"/> name='BCP' value='195'/>
<seriesInfo name="RFC" value="7525"/>
<seriesInfo name="DOI" value="10.17487/RFC7525"/> name='RFC' value='7525'/>
</reference>

&RFC8174;

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

        <reference anchor="RFC6126bis"><front> anchor="RFC8966" target='https://www.rfc-editor.org/info/rfc8966'>
          <front>
            <title>The Babel Routing Protocol</title>
            <author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>
            <author fullname="David Schinazi" initials="D." surname="Schinazi"/>
            <date month="February" year="2020"/></front> month="January" year="2021"/>
          </front>
          <seriesInfo name="Internet Draft" value="draft-ietf-babel-rfc6126bis-17"/>
</reference>

</references>

<references title="Informative References">

&RFC7250;
&RFC7918;
&RFC7924;
&RFC8094;

<reference anchor="BABEL-HMAC"><front>
<title>Babel Cryptographic Authentication</title>
<author fullname="Clara Do" initials="C." surname="Do"/>
<author fullname="Weronika Kolodziejak" initials="W." surname="Kolodziejak"/>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>
<date month="August" year="2019"/></front> name="RFC" value="8966"/>
          <seriesInfo name="Internet Draft" value="draft-ietf-babel-hmac-10"/> name="DOI" value="10.17487/RFC8966"/>
        </reference>
      </references>
      <references>

        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7250.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7918.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7924.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8094.xml"/>

<reference anchor="DTLS-CID"><front>
<title>Connection Identifiers anchor='RFC8967' target='https://www.rfc-editor.org/info/rfc8967'>
<front>
<title>MAC Authentication for DTLS 1.2</title>
<author fullname="Eric Rescorla" initials="E." surname="Rescorla"/> the Babel Routing Protocol</title>
<author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig"/> initials='C' surname='Dô' fullname='Clara Dô'>
    <organization />
</author>
<author fullname="Thomas Fossati" initials="T." surname="Fossati"/> initials='W' surname='Kolodziejak' fullname='Weronika Kolodziejak'>
    <organization />
</author>
<author fullname="Tobias Gondrom" initials="T." surname="Gondrom"/> initials='J' surname='Chroboczek' fullname='Juliusz Chroboczek'>
    <organization />
</author>
<date month="October" year="2019"/></front> month='January' year='2021' />
</front>
<seriesInfo name="Internet Draft" value="draft-ietf-tls-dtls-connection-id-07"/> name="RFC" value="8967"/>
<seriesInfo name="DOI" value="10.17487/RFC8967"/>
</reference>

       <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tls-dtls-connection-id.xml"/>

        <reference anchor="SLOWLORIS" target="https://web.archive.org/web/20150315054838/http://ha.ckers.org/slowloris/"><front>
<title>Welcome to Slowloris...</title> target="https://web.archive.org/web/20150315054838/http://ha.ckers.org/slowloris/">
          <front>
            <title>Slowloris HTTP DoS</title>
            <author fullname="RSnake Hansen" initials="R." surname="Hansen"/>
            <date month="June" year="2009"/></front> year="2009"/>
          </front>
        </reference>
      </references>
    </references>

    <section title="Performance Considerations"> numbered="true" toc="default">
      <name>Performance Considerations</name>
      <t>To reduce the number of octets taken by the DTLS handshake,
especially the size of the certificate in the ServerHello (which can
be several kilobytes), Babel peers can use raw public keys <xref
target="RFC7250"/> target="RFC7250" format="default"/> or the Cached Information Extension <xref
target="RFC7924"/>. target="RFC7924" format="default"/>.  The Cached Information Extension avoids
transmitting the server's certificate and certificate chain if the
client has cached that information from a previous TLS handshake.  TLS
False Start <xref target="RFC7918"/> target="RFC7918" format="default"/> can reduce round trips by
allowing the TLS second flight of messages (ChangeCipherSpec) to also
contain the (encrypted) Babel packet.</t>
    </section>
    <section title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors would like to thank
Roman Danyliw,
Donald Eastlake,
Thomas Fossati,
Benjamin Kaduk,
Gabriel Kerneis,
Mirja Kuehlewind,
Antoni Przygienda,
Henning Rogge,
Dan Romascanu,
Barbara Stark,
Markus Stenberg,
Dave Taht,
Martin Thomson,
Sean Turner
and Martin Vigoureux
<contact fullname="Roman Danyliw"/>,
<contact fullname="Donald Eastlake"/>,
<contact fullname="Thomas Fossati"/>,
<contact fullname="Benjamin Kaduk"/>,
<contact fullname="Gabriel Kerneis"/>,
<contact fullname="Mirja Kühlewind"/>,
<contact fullname="Antoni Przygienda"/>,
<contact fullname="Henning Rogge"/>,
<contact fullname="Dan Romascanu"/>,
<contact fullname="Barbara Stark"/>,
<contact fullname="Markus Stenberg"/>,
<contact fullname="Dave Taht"/>,
<contact fullname="Martin Thomson"/>,
<contact fullname="Sean Turner"/>,
and <contact fullname="Martin Vigoureux"/>
for their input and contributions.
The performance considerations in this document were inspired from the ones for
DNS over DTLS <xref target="RFC8094"/>.</t> target="RFC8094" format="default"/>.</t>
    </section>
  </back>
</rfc>