One document matched: draft-thomson-tcpinc-dtls-00.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<rfc ipr="trust200902" docName="draft-thomson-tcpinc-dtls-00" category="std">

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

  <front>
    <title abbrev="DTLS for TCP">A DTLS Extension for TCP</title>

    <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization>Mozilla</organization>
      <address>
        <email>martin.thomson@gmail.com</email>
      </address>
    </author>

    <date year="2014"/>

    <area>TSV</area>
    <workgroup>TCPINC</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>Opportunistic security is provided for TCP using a modified DTLS.</t>



    </abstract>


  </front>

  <middle>


<section anchor="intro" title="Introduction">

<t>TCP <xref target="RFC0793"/> is a widely used protocol.</t>

<t>As part of a general “secure all the things” effort, the IETF is defining
opportunistic security options for all the protocols it maintains.
Opportunistic security ensures that we accelerate the eventual heat death of the
universe, and discourages certain classes of attack <xref target="RFC7258"/>.</t>

<t>Opportunistic approaches are the most practical way to ensure wider deployment
of security because they don’t immediately depend on solving hard problems like
authentication.</t>

<t>In that spirit, reusing existing security protocols reduces the cost to
implement, deploy and analyse new protocol modifications.  TLS <xref target="RFC5246"/> and
DTLS <xref target="RFC6347"/> represent the current best in class security protocols.</t>

<t>This specification defines how DTLS can be used to protect TCP.  This addresses
the requirements outlined in <xref target="I-D.bellovin-tcpsec"/>.  A small modification to
the TCP record layer allows for the protection of the TCP pseudo header, with an
allowance for NAPT (editor: why does Bellovin even suggest that protection of
IP/port is even feasible?) and per-option opt-out.</t>

<t>In addition, all the features of DTLS are made available:</t>

<t><list style="symbols">
  <t>Cipher suite negotiation and agility</t>
  <t>Years of security analysis</t>
  <t>Downgrade protection in the handshake</t>
  <t>Session bindings</t>
  <t>Optional peer authentication</t>
  <t>A range of available extensions</t>
</list></t>

<t>In addition to this, new upgrades to DTLS can be trivially added.  Thus,
improvements to algorithms or the DTLS handshake are entirely portable.</t>

<section anchor="terminology" title="Terminology">

<t>The usual. <xref target="RFC2119"/> explains what those are.</t>

</section>
</section>
<section anchor="overview" title="DTLS Layering">

<t>This extension to TCP places a continuous sequence of DTLS records as the
payload of TCP.  These records provide confidentiality and integrity protection
for their content, plus integrity protection for the TCP header and
pseudoheader.</t>

<t>An option negotiates the use of this extension.  This option is added to the SYN
message to indicate support, and to the ACK message to indicate acceptance.</t>

<t>Once enabled, all DTLS records, including handshake messages, are carried as TCP
data.  The data for the protected TCP stream is the concatenated content of DTLS
messages.</t>

<t>TCP clients are automatically entered into the DTLS client role; and TCP servers
automatically enter the DTLS server role.  Where TCP simultaneous open is used,
a lottery determines the roles <xref target="simultaneous-open"/>.</t>

</section>
<section anchor="option" title="DTLS Record Protection Option">

<t>This option is used to negotiate the use of DTLS.  It is assigned a TCP option
kind of 0xTBD <xref target="iana"/>.</t>

<t>The format of the DTLS record protection option is a single octet flags field,
followed by a list of protected option kinds.</t>

<section anchor="flags" title="DTLS Record Protection Flags">

<t>The content of the flags field is a bit pattern of features.  The following features
are defined in this document:</t>

<t><list style="symbols">
  <t>FORBID_NAPT: Bit 0 (the first and most significant bit of the first octet)
being set indicates that DTLS protection is to be extended to addressing
elements, see <xref target="forbid-napt"/>.</t>
</list></t>

<t>A client can set these bits to request the defined alterations to the protocol.
A server can accept these alterations by including these in its ACK message, or
it can reject the alterations by clearing the bit.</t>

<t>All bits in this option MUST be set to zero unless they are explicitly
understood.  A sender MUST remove trailing octets that have all zero values from
the option.</t>

<t>An IANA registry is established to maintain these bits <xref target="iana-flags"/>.</t>

</section>
<section anchor="protected-options" title="Protection Option Kinds">

<t>The DTLS record protection option includes a list of the TCP options that are
covered by DTLS integrity protection, each occupying a single octet.  Just as
TCP options are terminated by a zero octet, this list is terminated by a zero
value.</t>

<t>Any data following this list is reserved for extension and MUST be ignored.</t>

</section>
</section>
<section anchor="modified-dtls-aead-operation" title="Modified DTLS AEAD Operation">

<t>This mechanism MUST be used with an Authenticated Encryption with Additional
Data (AEAD) mode.  The DTLS record layer is modified to provide integrity
protection for the TCP pseudoheader and header by including this as part of the
additional data.</t>

<t>An important characteristic of this is that records are protected as though each
individual DTLS record is part of a unique TCP segment.  This ensures that
repacketization by middleboxes does not result in records being marked as
invalid.</t>

<t>TCP middleboxes can, and sometimes do, split or coalesce TCP segments.  This
affects the calculation of the authenticated data that is input to the AEAD
protection.</t>

<t>To prevent this from invalidating integrity checks unnecessarily, the associated
data passed to the AEAD algorithm contains a modified value of the TCP header
and pseudoheader.</t>

<t>For a sender that transmits a single DTLS record in each TCP segment with only
protected TCP options, this demands no additional calculation.  However, a
receiver needs to construct the TCP header and pseudoheader.  The length of this
packet is based on the length of the DTLS record, with the value of protected
TCP options being extracted from the TCP header of the segment that carries the
first byte of the DTLS record.</t>

<t>In TLS and DTLS, the additional data that is protected by the AEAD function
is <xref target="RFC5246"/>:</t>

<figure><artwork><![CDATA[
additional_data = seq_num + TLSCompressed.type +
                  TLSCompressed.version + TLSCompressed.length;
]]></artwork></figure>

<t>where “+” denotes concatenation.</t>

<t>This specification expands the fields that are protected to include a
constructed TCP pseudoheader and header as follows:</t>

<figure><artwork><![CDATA[
tcp_additional_data = pseudoheader + tcp_header +
                      additional_data;
]]></artwork></figure>

<t>Construction of the <spanx style="verb">pseudoheader</spanx> and <spanx style="verb">tcp_header</spanx> portions of the
authenticated data are described in the following sections.</t>

<section anchor="pseudoheader" title="TCP Pseudoheader Construction">

<t>The pseudoheader that is used for AEAD input depends on the IP version in use,
for IPv4 <xref target="RFC0793"/>, with length of fields in bits shown in parentheses:</t>

<figure><artwork><![CDATA[
pseudoheader_v4 = source_address(32) + destination_address(32) +
                   zero(8) + protocol(8) + tcp_length(16)
]]></artwork></figure>

<t>Or for IPv6 <xref target="RFC2460"/>:</t>

<figure><artwork><![CDATA[
pseudoheader_v6 = source_address(128) + destination_address(128) +
                  tcp_length(32) + zero(24) + protocol(8)
]]></artwork></figure>

<t>In both cases, the value for <spanx style="verb">tcp_length</spanx> is derived by constructing a TCP
header as described in <xref target="tcp-header"/>.</t>

<t>The values for <spanx style="verb">source_address</spanx> and <spanx style="verb">destination_address</spanx> are replaced with zero
bits, unless the FORBID_NAPT flag is enabled.  Setting these values to zero
permits the use of NAPT devices.</t>

</section>
<section anchor="tcp-header" title="TCP Header Construction">

<t>In order to ensure that the protocol is robust in the presence of middleboxes,
unprotected TCP options are removed from the TCP header before applying protection.</t>

<figure><artwork><![CDATA[
tcp_header = source_port(16) + destination_port(16) +
             sequence_number(32) + acknowledgement_number(32) +
             data_offset(4) + flags(12) + window(16) +
             checksum(16) + urgent_pointer(16) + options(?)
]]></artwork></figure>

<t>The following construction rules apply:</t>

<t><list style="hanging">
  <t hangText='source_port and destination_port:'>
  These fields MUST be replaced with zero bits unless the FORBID_NAPT flag is
enabled for the session.  Setting these values to zero permits the use of port
translation.</t>
  <t hangText='sequence_number:'>
  This field MUST be set to the sequence number corresponding to the first octet
of the DTLS record.  If multiple segments are combined into a single packet,
this will be different to the sequence number that appears in the TCP header.</t>
  <t hangText='acknowledgement_number and window:'>
  These fields MUST be replaced with zero bits.  Removing the acknowledgement
and congestion window from integrity protection does provide some
opportunities to an on-path attacker <xref target="security-ack-window"/>.</t>
  <t hangText='data_offset:'>
  The data offset MUST be set to the size of the modified TCP header.</t>
  <t hangText='flags:'>
  The reserved and flags part of the TCP header is protected.</t>
  <t hangText='checksum:'>
  This field MUST be replaced with zero bits, just as it is when the TCP
checksum is calculated.</t>
  <t hangText='urgent_pointer:'>
  The urgent pointer is protected.</t>
  <t hangText='options:'>
  The set of options that are included under protection are included.  Options
that are not protected are removed.  <xref target="protected-options"/> described how
options are selected for protection.  The list of options is terminated with
an option of kind 0x0 and padding to a multiple of 32 bits with zero octets.</t>
</list></t>

<t>This construction permits the addition and removal of options by middleboxes, as
long as they are not in the list of options that are protected.  It also permits
repacketization and acknowledgment.</t>

</section>
<section anchor="forbid-napt" title="Forbid NAPT">

<t>The DTLS record protection option <xref target="option"/> contains a FORBID_NAPT bit that can
be used to signal that network address and port translation (NAPT) is forbidden.</t>

<t>If the FORBID_NAPT option is not set, addressing information is replaced with
zero values.  This is the IP (v4 or v6) address fields in the pseudoheader, and
the source and destination port numbers.</t>

<t>Why anyone in their right mind would do this is beyond me, but it’s in the
requirements and this would seem to be sufficient to address those, albeit by
making the whole mechanism more complex.</t>

</section>
</section>
<section anchor="simultaneous-open" title="DTLS Role Selection">

<t>Ordinarily, the role of DTLS client is assumed by the peer that sends the first
TCP SYN packet (the TCP client), and the role of DTLS server is assumed by the
peer that responds (the TCP server).</t>

<t>Peers that perform a TCP simultaneous open - that is, where both peers
simultaneously send SYN packets to open a connection, often to work around
middlebox limitations - are assigned client and server roles in DTLS based on
the following rules.</t>

<t>If only one peer provides a DTLS handshake in TCP fast open data
<xref target="I-D.ietf-tcpm-fastopen"/>, then that peer becomes the client.  Note that
including the DTLS handshake message in the initial SYN packet is only safe if
there is a previous confirmation from a server that it supports this protocol
(see <xref target="fastopen"/>).</t>

<t>If neither or both peers provide the DTLS handshake option, then the peer that
selects the numerically highest value for their ClientRandom assumes the client
role.  In the absence of the DTLS handshake option, role allocations are not
determined until a ClientHello message is exchanged.</t>

</section>
<section anchor="design-characteristics" title="Design Characteristics">

<t>This section outlines a number of considerations that allow this protocol to
actually be implemented.</t>

<section anchor="fastopen" title="Interaction with TCP Fast Open">

<t>TCP fast open <xref target="I-D.ietf-tcpm-fastopen"/> can be used to mitigate the additional
latency cost imposed by the DTLS handshake.  However, this represents a risk,
since the payload of the initial packet is directly passed to an application if
the opportunistic security option is not negotiated.</t>

<t>Adding data to an initial SYN is therefore only possible if there is a previous
indication that a server supports the combination of TCP fast open and
opportunistic security in combination.</t>

<t>A server that provides a TCP fast open cookie for an encrypted connection MUST
accept encryption on future connections with that cookie, or reject the
connection.  This ensures that clients are able to send a DTLS handshake message
in the initial SYN packet.</t>

</section>
<section anchor="zero-length-dtls-data" title="Zero Length DTLS Data">

<t><xref target="RFC5246"/>, Section 6.2 notes that the TLS record layer protects non-zero
length blocks.  This use of DTLS requires that frames be permitted to be empty,
relying solely on integrity protection of the associated data.</t>

<t><list style='empty'>
  <t>This does not mean that the TCP segment contains no data, since it will
  contain the DTLS record header (including the explicit nonce, if any, and any
  bits produced by the AEAD cipher to ensure integrity).</t>
</list></t>

</section>
<section anchor="unauthenticated-acknowledgments" title="Unauthenticated Acknowledgments">

<t>TCP segments that only acknowledge receipt of data, or update the receive window
do not require authentication, since the corresponding fields are not protected.
These frames can be accepted and processed, as long as only the receive window
is updated.</t>

<t>By the same logic, protection of the TCP window scaling option <xref target="RFC1323"/> and
the selective acknowledgment (SACK) option <xref target="RFC2018"/> are not made
mandatory.  These SHOULD NOT be added to the list of protected options
<xref target="protected-options"/>.</t>

</section>
<section anchor="interaction-with-dtls-replay-protection" title="Interaction with DTLS Replay Protection">

<t>TCP segment retransmission and reassembly requires that a sender be able to
retransmit.  These frames will be retransmitted with the same data, including
the DTLS serial number.  To avoid having retransmissions erroneously discarded,
any DTLS replay protection needs to allow for replay of records that appear in
unacknowledged segments.</t>

</section>
<section anchor="tcp-keep-alive" title="TCP Keep-Alive">

<t>This protocol does not protect TCP keep-alive segments <xref target="RFC1122"/>; that is,
segments that are sent purely to ensure that the connection is maintained
through middleboxes.  These can contain a single junk byte from just prior to
the start of the congestion window.  These segments are discarded without being
validated.</t>

<t>This differs from <xref target="I-D.bittau-tcp-crypt"/>, which protects keep-alive segments.
Protection ensures that an attacker is unable to prolong the lifetime of a
connection that is otherwise unwanted.</t>

<t>Since an unwanted connection can be terminated with an authenticated segment
that bears a FIN or RST bit, this concern is unwarranted.</t>

</section>
<section anchor="unprotected-rst-segments" title="Unprotected RST Segments">

<t>Existing TCP implementations, particularly middleboxes, rely TCP RST to
terminate connections.  If RST authentication is required, then it becomes
impossible for a node which is not part of the association (either because it is
a middlebox or because it is a legitimate endpoint which has lost state) to
terminate the connection.  An implementation MAY choose to respect an
unauthenticated RST to permit these uses.</t>

<t>(Note: we may want to provide an option that the middlebox can include in a RST
to prove that it is on-path to make this a little easier to accept.)</t>

</section>
<section anchor="cipher-suite-selection" title="Cipher Suite Selection">

<t>Implementations MUST support the TLS_BLAH_WITH_BLAH_BLAH cipher suite.</t>

<t>Implementations MUST NOT offer non-AEAD modes and MUST terminate the connection
if a non-AEAD mode if one is erroneously offered.</t>

</section>
</section>
<section anchor="security" title="Security Considerations">

<t>None of this document mandates any level of authentication for peers, which
opens up all sorts of active attacks.</t>

<section anchor="napt" title="NAPT">

<t>The choice to protect a TCP connection from addressing modification prevents
network address and port translation from altering the addressing information on
a connection.  Unfortunately, this is a procedure that much of the Internet
relies on.  Enabling this feature is likely to break a lot of uses, but failure
to use it exposes the connection to trivial re-routing attacks.</t>

<t>In the absence of peer authentication, and where there is a high level of
assurance that no NAPT is being used for a communications path, this protection
might be used.  Of course, any protection this provides is trivially
circumvented by an on-path attacker.</t>

</section>
<section anchor="security-ack-window" title="Acknowledgments and Congestion Window Protection">

<t>This design permits a middlebox to generate acknowledgments and to perform
repacketization.  This opens a number of denial of service avenues for malicious
middleboxes.  Falsifying window advertisements can cause a sender to send more
packets than might otherwise be sent.  Similarly, sending a reduced
acknowledgment sequence number can cause excessive retransmission.  In a similar
fashion, retransmissions can be suppressed by sending inflated acknowledgment
sequence numbers.</t>

<t>These are options that are already available to an on-path attacker.</t>

</section>
<section anchor="traffic-redirection" title="Traffic Redirection">

<t>Without the FORBID_NAPT flag enabled, it’s possible for a middlebox to rewrite
addressing information so that this flow.  If only authenticated RST and FIN
segments are accepted by the TCP stack, the target of this flow - who doesn’t
have access to the traffic keys - is unable to do anything to end the flow of
data.</t>

<t>This isn’t particularly interesting as an attack, since we have to assume that
any middlebox capable of this is also capable of just generating the same volume
of packets toward the victim.</t>

</section>
<section anchor="peer-authentication" title="Peer Authentication">

<t>In order to have this deployed, peers will have to avoid relying on
authentication.  That means that this is open to active attacks.</t>

<t>Implementations might consider using some form of key continuity.  Clients
SHOULD avoid key continuity for different servers to avoid tracking by
correlating keying material.  Full continuity might be more applicable for
servers, where key continuity does not create any special tracking ability.</t>

<t>(This probably needs work.)</t>

</section>
</section>
<section anchor="iana" title="IANA Considerations">

<t>This document registers a new TCP option kind, and establishes a registry to
maintain its contents.</t>

<section anchor="registration-of-dtls-record-protection-option-kind" title="Registration of DTLS Record Protection Option Kind">

<t>This document registers the DTLS record protection option with a TCP option kind
of 0xTBD.</t>

<t>The format of this option is described in <xref target="option"/></t>

</section>
<section anchor="iana-flags" title="Registry for DTLS Record Protection Flags">

<t>IANA will maintain a registry of “TCP DTLS Record Protection Flags” under the
“Service Names and Transport Protocol Port Numbers” group of registries.</t>

<t>This registry controls a contiguous space starting from bit 0 to 2023
(inclusive).  New registrations in this registry require IETF review
<xref target="RFC5226"/>, with the following information:</t>

<t><list style="hanging">
  <t hangText='Bit Number:'>
  The bit number being assigned</t>
  <t hangText='Purpose:'>
  A brief description of the feature.</t>
  <t hangText='Specification:'>
  A reference to the specification that defines the feature.</t>
</list></t>

<t>The initial contents of this registry are:</t>

<t><list style="hanging">
  <t hangText='Bit Number:'>
  0</t>
  <t hangText='Purpose:'>
  Enables protection of addressing information.</t>
  <t hangText='Specification:'>
  This document.</t>
</list></t>

</section>
</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference anchor='RFC2119'>

<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.  Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

<list>
<t>
      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.
</t></list></t>
<t>
   Note that the force of these words is modified by the requirement
   level of the document in which they are used.
</t></abstract></front>

<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17970' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>



<reference anchor='RFC1122'>

<front>
<title>Requirements for Internet Hosts - Communication Layers</title>
<author initials='R.' surname='Braden' fullname='Robert Braden'>
<organization>University of Southern California (USC)/ Information Sciences Institute (ISI)</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country></postal>
<phone>+1 213 822 1511</phone>
<email>Braden@ISI.EDU</email></address></author>
<date year='1989' month='October' /></front>

<seriesInfo name='STD' value='3' />
<seriesInfo name='RFC' value='1122' />
<format type='TXT' octets='295992' target='http://www.rfc-editor.org/rfc/rfc1122.txt' />
</reference>



<reference anchor='RFC0793'>

<front>
<title abbrev='Transmission Control Protocol'>Transmission Control Protocol</title>
<author initials='J.' surname='Postel' fullname='Jon Postel'>
<organization>University of Southern California (USC)/Information Sciences Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country></postal></address></author>
<date year='1981' day='1' month='September' /></front>

<seriesInfo name='STD' value='7' />
<seriesInfo name='RFC' value='793' />
<format type='TXT' octets='172710' target='http://www.rfc-editor.org/rfc/rfc793.txt' />
</reference>



<reference anchor='RFC2460'>

<front>
<title abbrev='IPv6 Specification'>Internet Protocol, Version 6 (IPv6) Specification</title>
<author initials='S.E.' surname='Deering' fullname='Stephen E. Deering'>
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<region>CA</region>
<code>95134-1706</code>
<country>USA</country></postal>
<phone>+1 408 527 8213</phone>
<facsimile>+1 408 527 8254</facsimile>
<email>deering@cisco.com</email></address></author>
<author initials='R.M.' surname='Hinden' fullname='Robert M. Hinden'>
<organization>Nokia</organization>
<address>
<postal>
<street>232 Java Drive</street>
<street>Sunnyvale</street>
<region>CA</region>
<code>94089</code>
<country>USA</country></postal>
<phone>+1 408 990 2004</phone>
<facsimile>+1 408 743 5677</facsimile>
<email>hinden@iprg.nokia.com</email></address></author>
<date year='1998' month='December' />
<area>Internet</area>
<keyword>internet protocol version 6</keyword>
<keyword>IPv6</keyword>
<abstract>
<t>
   This document specifies version 6 of the Internet Protocol (IPv6),
   also sometimes referred to as IP Next Generation or IPng.
</t></abstract></front>

<seriesInfo name='RFC' value='2460' />
<format type='TXT' octets='85490' target='http://www.rfc-editor.org/rfc/rfc2460.txt' />
<format type='HTML' octets='107357' target='http://xml.resource.org/public/rfc/html/rfc2460.html' />
<format type='XML' octets='94163' target='http://xml.resource.org/public/rfc/xml/rfc2460.xml' />
</reference>



<reference anchor='RFC5246'>

<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author initials='T.' surname='Dierks' fullname='T. Dierks'>
<organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<date year='2008' month='August' />
<abstract>
<t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='5246' />
<format type='TXT' octets='222395' target='http://www.rfc-editor.org/rfc/rfc5246.txt' />
</reference>



<reference anchor='RFC6347'>

<front>
<title>Datagram Transport Layer Security Version 1.2</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<author initials='N.' surname='Modadugu' fullname='N. Modadugu'>
<organization /></author>
<date year='2012' month='January' />
<abstract>
<t>This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol.  The DTLS protocol provides communications privacy for datagram protocols.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees.  Datagram semantics of the underlying transport are preserved by the DTLS protocol.  This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='6347' />
<format type='TXT' octets='73546' target='http://www.rfc-editor.org/rfc/rfc6347.txt' />
</reference>



<reference anchor='RFC5226'>

<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials='T.' surname='Narten' fullname='T. Narten'>
<organization /></author>
<author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'>
<organization /></author>
<date year='2008' month='May' />
<abstract>
<t>Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</t><t> In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</t><t> This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract></front>

<seriesInfo name='BCP' value='26' />
<seriesInfo name='RFC' value='5226' />
<format type='TXT' octets='66160' target='http://www.rfc-editor.org/rfc/rfc5226.txt' />
</reference>




    </references>

    <references title='Informative References'>





<reference anchor='RFC1323'>

<front>
<title>TCP Extensions for High Performance</title>
<author initials='V.' surname='Jacobson' fullname='Van Jacobson'>
<organization>University of California Berkeley, Lawrence Berkeley Laboratory</organization>
<address>
<postal>
<street>Mail Stop 46A</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720</code>
<country>US</country></postal>
<phone>+1 415 486 6411</phone>
<email>van@CSAM.LBL.GOV</email></address></author>
<author initials='B.' surname='Braden' fullname='Bob Braden'>
<organization>University of Southern California (USC), Information Sciences Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country></postal>
<phone>+1 310 822 1511</phone>
<email>Braden@ISI.EDU</email></address></author>
<author initials='D.' surname='Borman' fullname='Dave Borman'>
<organization>Cray Research</organization>
<address>
<postal>
<street>655-E Lone Oak Drive</street>
<city>Eagan</city>
<region>MN</region>
<code>55121</code>
<country>US</country></postal>
<phone>+1 612 683 5571</phone>
<email>dab@cray.com</email></address></author>
<date year='1992' month='May' />
<abstract>
<t>This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths.  It defines new TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions.  The timestamps are used for two distinct mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped Sequences).  Selective acknowledgments are not included in this memo.</t>
<t>This memo combines and supersedes RFC-1072 and RFC-1185, adding additional clarification and more detailed specification.  Appendix C summarizes the changes from the earlier RFCs.</t></abstract></front>

<seriesInfo name='RFC' value='1323' />
<format type='TXT' octets='84558' target='http://www.rfc-editor.org/rfc/rfc1323.txt' />
</reference>



<reference anchor='RFC2018'>

<front>
<title abbrev='TCP Selective Acknowledgement Options'>TCP Selective Acknowledgment Options</title>
<author initials='M.' surname='Mathis' fullname='Matt Mathis'>
<organization>Pittsburgh Supercomputing Center</organization>
<address>
<postal>
<street>4400 Fifth Ave</street>
<street>Pittsburgh</street>
<street>PA 15213</street></postal>
<email>mathis@psc.edu</email></address></author>
<author initials='J.' surname='Mahdavi' fullname='Jamshid Mahdavi'>
<organization>Pittsburgh Supercomputing Center</organization>
<address>
<postal>
<street>4400 Fifth Ave</street>
<street>Pittsburgh</street>
<street>PA 15213</street></postal>
<email>mahdavi@psc.edu</email></address></author>
<author initials='S.' surname='Floyd' fullname='Sally Floyd'>
<organization>Lawrence Berkeley National Laboratory</organization>
<address>
<postal>
<street>One Cyclotron Road</street>
<street>Berkeley</street>
<street>CA 94720</street></postal>
<email>floyd@ee.lbl.gov</email></address></author>
<author initials='A.' surname='Romanow' fullname='Allyn Romanow'>
<organization>Sun Microsystems, Inc.</organization>
<address>
<postal>
<street>2550 Garcia Ave.</street>
<street>MPK17-202</street>
<street>Mountain View</street>
<street>CA 94043</street></postal>
<email>allyn@eng.sun.com</email></address></author>
<date year='1996' month='October' />
<area>Transport</area>
<keyword>TCP</keyword>
<keyword>acknowledgement</keyword>
<keyword>transmission control protocol</keyword>
<abstract>
<t>
   TCP may experience poor performance when multiple packets are lost
   from one window of data.   With the limited information available
   from cumulative acknowledgments, a TCP sender can only learn about a
   single lost packet per round trip time.  An aggressive sender could
   choose to retransmit packets early, but such retransmitted segments
   may have already been successfully received.
</t>
<t>
   A Selective Acknowledgment (SACK) mechanism, combined with a
   selective repeat retransmission policy, can help to overcome these
   limitations.  The receiving TCP sends back SACK packets to the sender
   informing the sender of data that has been received. The sender can
   then retransmit only the missing data segments.
</t>
<t>
   This memo proposes an implementation of SACK and discusses its
   performance and related issues.
</t></abstract></front>

<seriesInfo name='RFC' value='2018' />
<format type='TXT' octets='25671' target='http://www.rfc-editor.org/rfc/rfc2018.txt' />
<format type='XML' octets='30268' target='http://xml.resource.org/public/rfc/xml/rfc2018.xml' />
</reference>



<reference anchor='RFC7258'>

<front>
<title>Pervasive Monitoring Is an Attack</title>
<author initials='S.' surname='Farrell' fullname='S. Farrell'>
<organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'>
<organization /></author>
<date year='2014' month='May' />
<abstract>
<t>Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.</t></abstract></front>

<seriesInfo name='BCP' value='188' />
<seriesInfo name='RFC' value='7258' />
<format type='TXT' octets='13396' target='http://www.rfc-editor.org/rfc/rfc7258.txt' />
</reference>



<reference anchor='I-D.bittau-tcp-crypt'>
<front>
<title>Cryptographic protection of TCP Streams (tcpcrypt)</title>

<author initials='A' surname='Bittau' fullname='Andrea Bittau'>
    <organization />
</author>

<author initials='D' surname='Boneh' fullname='Dan Boneh'>
    <organization />
</author>

<author initials='M' surname='Hamburg' fullname='Mike Hamburg'>
    <organization />
</author>

<author initials='M' surname='Handley' fullname='Mark Handley'>
    <organization />
</author>

<author initials='D' surname='Mazieres' fullname='David Mazieres'>
    <organization />
</author>

<author initials='Q' surname='Slack' fullname='Quinn Slack'>
    <organization />
</author>

<date month='February' day='14' year='2014' />

<abstract><t>This document presents tcpcrypt, a TCP extension for cryptographically protecting TCP segments.  Tcpcrypt maintains the confidentiality of data transmitted in TCP segments against a passive eavesdropper.  It protects connections against denial-of-service attacks involving desynchronizing of sequence numbers, and when enabled, against forged RST segments.  Finally, applications that perform authentication can obtain end-to-end confidentiality and integrity guarantees by tying authentication to tcpcrypt Session ID values.  The extension defines two new TCP options, CRYPT and MAC, which are designed to provide compatible interworking with TCPs that do not implement tcpcrypt.  The CRYPT option allows hosts to negotiate the use of tcpcrypt and establish shared secret encryption keys.  The MAC option carries a message authentication code with which hosts can verify the integrity of transmitted TCP segments.  Tcpcrypt is designed to require relatively low overhead, particularly at servers, so as to be useful even in the case of servers accepting many TCP connections per second.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-bittau-tcp-crypt-04' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-bittau-tcp-crypt-04.txt' />
</reference>



<reference anchor='I-D.ietf-tcpm-fastopen'>
<front>
<title>TCP Fast Open</title>

<author initials='Y' surname='Cheng' fullname='Yuchung Cheng'>
    <organization />
</author>

<author initials='J' surname='Chu' fullname='Jerry Chu'>
    <organization />
</author>

<author initials='S' surname='Radhakrishnan' fullname='Sivasankar Radhakrishnan'>
    <organization />
</author>

<author initials='A' surname='Jain' fullname='Arvind Jain'>
    <organization />
</author>

<date month='July' day='1' year='2014' />

<abstract><t>This document describes an experimental TCP mechanism TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, thus saving up to one full round trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However TFO deviates from the standard TCP semantics since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue detailed in the Applicability section.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tcpm-fastopen-09' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tcpm-fastopen-09.txt' />
</reference>



<reference anchor='I-D.bellovin-tcpsec'>
<front>
<title>Problem Statement and Requirements for a TCP Authentication Option</title>

<author initials='S' surname='Bellovin' fullname='Steven  Bellovin'>
    <organization />
</author>

<date month='July' day='12' year='2007' />

<abstract><t>The TCP-MD5 option is commonly used to secure BGP sessions between routers, although it is known to have many serious deficiencies. This memo presents requirements for a TCP segment authentication mechanism that is intended to replace TCP-MD5. While TCP-MD5 was designed to protect TCP sessions whose payload is BGP, the applicability of the mechanism described herein is broader. This mechanism can be applied to any TCP connection, regardless of payload.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-bellovin-tcpsec-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-bellovin-tcpsec-01.txt' />
</reference>




    </references>



  </back>
</rfc>