One document matched: draft-bonaventure-mptcp-rst-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-bonaventure-mptcp-rst-00" category="exp">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<front>
<title abbrev="MPTCP RST">Processing of RST segments by Multipath TCP</title>
<author initials="O." surname="Bonaventure" fullname="Olivier Bonaventure">
<organization>UCLouvain</organization>
<address>
<email>Olivier.Bonaventure@uclouvain.be</email>
</address>
</author>
<author initials="C." surname="Paasch" fullname="Christoph Paasch">
<organization>UCLouvain</organization>
<address>
<email>Christoph.Paasch@uclouvain.be</email>
</address>
</author>
<author initials="G." surname="Detal" fullname="Gregory Detal">
<organization>UCLouvain</organization>
<address>
<email>Gregory.Detal@uclouvain.be</email>
</address>
</author>
<date year="2014" month="July" day="03"/>
<area>Transport</area>
<workgroup>MPTCP</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document discusses how a Multipath TCP implementation should generate and process RST segments.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>The Transmission Control Protocol (TCP) <xref target="RFC0793"/> was designed to provide a
reliable data transfer between hosts attached to a single IP address.
Multipath TCP <xref target="RFC6824"/> is a recent extension that enables a single TCP
connection to use multiple paths. For Multipath TCP, each path
corresponds to a TCP connection established between the communicating
hosts. Each of these connections is identified by the classical
four-tuple (source and destination IP addresses and source and
destination port numbers). Multipath TCP allows to group several of
these TCP connections, called subflows in <xref target="RFC6824"/> inside a single
Multipath TCP connection. It should be noted that the number of
subflows that are used for a given Multipath TCP connection is not
fixed and can change during the lifetime of a Multipath TCP
connection.</t>
<t>In regular TCP, the RST flag is used to abruptly terminate a TCP
connection. When a host receives a valid TCP segment with the RST
flag, it immediately terminates the connection. This causes the loss
of all in-flight data that has not yet been acknowledged. In the
original TCP specification, a host could generate a segment with the
RST flag in the following cases:</t>
<t><list style="symbols">
<t>A host receives a non-SYN segment that corresponds to a TCP
connection that does not exist (anymore).</t>
<t>A host receives a SYN segment and does not want to establish the
requested connection for any reason.</t>
<t>A host has tried to retransmit the same data too many times
without having received an acknowledgment.</t>
<t>The corresponding connection has been idle for a long time and no
answer has been received to the keepalive segments that the host
has sent over this TCP connection <xref target="RFC1122"/></t>
<t>A host does not have enough resources anymore (e.g. memory) to
support the established connection.</t>
</list></t>
<t>Over the years, other reasons to use the RST flag have been added to
TCP implementations. The most important one is the possibility for
an application, typically a server, to abruptly terminate a TCP
connection by forcing the stack to send a segment with the RST flag
instead of waiting for the normal FIN exchange and being forced to
maintain state.</t>
<t>Despite the fact that TCP is a transport protocol that is used only
on endhosts, various types of middleboxes are known to spoof TCP
segments that contain the RST flag to abruptly terminate TCP
connections <xref target="IMC11"/>. Some of these middleboxes terminate TCP connections to
block some applications such as P2P file transfers, others provide
security services such as DPI and terminate TCP connections once they
have identified suspicious data in the payload. This behavior of
middleboxes has been considered as harmful in <xref target="RFC3360"/>.</t>
<t>Multipath TCP cannot simply behave like regular TCP when transmitting
and receiving TCP segments with the RST flag. Since a Multipath TCP
connection is composed of several TCP subflows, the transmission or
reception of a TCP RST on a subflow only terminates the
corresponding subflow. This does not necessarily terminate the
Multipath TCP connection.</t>
<t>This document is organized as follows. We discuss in section
Section 2 the reasons why a Multipath TCP host could decide to
transmit a RST segment. In section Section 3, we propose a new
Multipath TCP option that can be used inside RST segments to convey
additional information about the reason for this RST segment and
explain how a Multipath TCP host should react to such segments.</t>
<section anchor="notational-conventions" title="Notational Conventions">
<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 <xref target="RFC2119"/>.</t>
</section>
</section>
<section anchor="generation-of-rst-segments" title="Generation of RST segments">
<t>This section documents the various reasons why a Multipath TCP host
could generate a segment with the RST flag.</t>
<section anchor="lack-of-ressources" title="Lack of ressources">
<t>A Multipath TCP implementation cannot usually support an unlimited
number of TCP subflows associated to a single Multipath TCP
connection. A Multipath TCP implementation may face a lack of
ressources when :</t>
<t><list style="symbols">
<t>It receives a SYN segment and accepting this subflow would exhaust
the subflow table of the host. </t>
<t>It experiences memory pressure and needs to recover additional
ressources. Under these circumstances, it could decide to
terminate some subflows for existing Multipath TCP connections. </t>
</list></t>
</section>
<section anchor="administratively-prohibited" title="Administratively prohibited">
<t>A Multipath TCP implementation can be configured with policies that
determine which subflows can be associated to a given Multipath TCP
connection. These policies could be specified on a per application
basis, a per host basis or via other means that are outside the scope
of this document. Based on this configuration, a Multipath TCP host could
generate a RST segment to refuse the establishment of a subflow when
:</t>
<t><list style="symbols">
<t>It receives a SYN segment from a source address that conflicts
with its policies. For example, an enterprise server could be
configured to only accept subflows that originate from the
enterprise subnet and not from the global Internet. </t>
<t>It receives a SYN segment with a destination address that
conflicts with its policies. For example, a server may be
configured to only expose some of its addresses to a subset of its
clients. </t>
<t>It receives a SYN segment destined to a destination port that
conflicts with its policies. For example, a web server may be
configured to only accept subflows targeted to port 80 even if the
Multipath TCP specification allows to group together subflows on
different destination ports. </t>
</list></t>
<t>Both ICMPv4 and ICMPv6 contain error codes that can be used to
indicate similar error conditions. However, ICMP messages are more
likely to be dropped by network equipment than TCP segments.
Multipath TCP’s reaction to these ICMP messages and the TCP RST
segments should be similar.</t>
</section>
<section anchor="too-many-already-acknowledged-data" title="Too many already acknowledged data">
<t>Multipath TCP allows data that was transmitted over one subflow to be
retransmitted over another subflow. This situation can happen during
a handover when a mobile host moves from one access network to
another. In this case, the same data can be transmitted twice over
different subflows. This is mandated by Multipath TCP to ensure that
any middlebox on the path of the first subflow will see in-sequence
segments. However, retransmitting already acknowledged data over a
subflow is not the best utilisation of the network ressources as
reported in <xref target="INFOCOM14"/>. It should be possible for a Multipath TCP host that
has too many data that has already been acknowledged over one subflow
but still needs to be retransmitted over another subflow to preserve
the subflow ordering by terminating the subflow with too many
outstanding but already acknowledged data. Measurements or
simulations are required to evaluate the best threshold to be used by
a Multipath TCP implementation to decide when to terminate such a
subflow. In this document, we propose to terminate a subflow once
there are more than one initial congestion window’s worth of data
that are outstanding on this subflow but have already been
acknowledged over another subflow or there is no other data on this
subflow.</t>
<t>The situation described above is obviously transient. The
termination of such a subflow does not indicate that the path should
not be used anymore. Instead, the reception of a RST segment
indicating such a cause should trigger the reestablishment of a
subflow over this path. The host that sends such a RST segment could
also send a SYN segment at the same time. However, it should be
noted that there are situations such as a server sending the RST
segment to a client connected behind a NAT where only the host that
receives the RST segment is able to reestablish the subflow.</t>
</section>
<section anchor="unacceptable-performance" title="Unacceptable performance">
<t>A Multipath TCP host can send data over several subflows. Some of
these subflows may perform well while the performance of others could
be affected by various performance problems :</t>
<t><list style="symbols">
<t>Excessive delay compared to the other subflows. If the receive
window used by Multipath TCP is too small, sending data over a
long delay subflow would reduce the overall performance of the
Multipath TCP connection. </t>
<t>Excessive losses. The Multipath TCP congestion control scheme
tries to move traffic away from congested paths. If one of the
subflows is more heavily congested than the others, this can
severely impact the performance of the Multipath TCP connection.</t>
<t>Excessive reordering. Excessive reordering at the subflow level
may lower performance by making TCP’s retransmission techniques
less reactive. This error condition is typically transient.</t>
</list></t>
<t>A Multipath TCP host that detects that the performance of a Multipath
TCP connection is severely affected by one of the underlying
subflows, could decide to terminate the offending subflow.
Depending on the number of remaining active subflows, it may be
needed to reestablish another subflow to replace the terminated one.</t>
</section>
<section anchor="lifetime-expired" title="Lifetime expired">
<t>A Multipath TCP connection is composed of several subflows. However,
maintaining a large number of subflows can be costly from an
implementation viewpoint. A Multipath TCP host should monitor the
usage of the underlying subflows and could terminate one subflow when
:</t>
<t><list style="symbols">
<t>No reply has been received to keepalive probes. The keepalive
probes <xref target="RFC1122"/> can be used over each subflow to verify that their
paths and the remote host are still active. If no answer is
received to these probes, the corresponding subflow should be
terminated. The Multipath TCP connection could be terminated once
the last subflow is terminated. Note that sending a regular RST
over each subflow will only terminate the subflow but not the
Multipath TCP connection <xref target="RFC6824"/>.</t>
</list></t>
</section>
<section anchor="removed-address" title="Removed address">
<t>When a host receives a REMOVE_ADDR option, it should send a TCP
keepalive over each of the subflows using the removed address. If a
response to the keepalive is received, the subflow should not be
terminated. Otherwise, the lack of response to the keepalives will
trigger a termination of the subflow as explained in section
Section 2.5.</t>
<t>When a host sends a REMOVE_ADDR option, it SHOULD send a RST segment
over each of the subflows that were using the removed address.</t>
</section>
<section anchor="middlebox-interference-has-been-detected" title="Middlebox interference has been detected">
<t>As explained in <xref target="RFC6824"/>, Multipath TCP includes several mechanisms to
detect and possibly cope with middlebox interference. There are
unfortunately cases where Multipath TCP needs to terminate a subflow
once it has detected middlebox interference. The following cases are
listed in <xref target="RFC6824"/> :</t>
<t>o As explained on page 42 of <xref target="RFC6824"/>, a host MUST close a subflow with a
RST if the first ACK that it receives over this subflow does not
contain the DSS option.</t>
<t>o As explained on page 43 of <xref target="RFC6824"/> a host MUST close a subflow by
sending a RST segment with the MP_FAIL option if it receives a
segment with an invalid DSS checksum. The MP_FAIL option includes
the data sequence number of the first byte of the payload of the
affected segment.</t>
</section>
<section anchor="multipath-tcp-specific-errors" title="Multipath TCP specific errors">
<t><xref target="RFC6824"/> lists several error conditions that are specific to Multipath TCP
and may lead to the termination of a subflow by transmitting a RST
segment. These error conditions are :</t>
<t><list style="symbols">
<t>A SYN segment with the MP_JOIN option was received with an invalid
HMAC or an unknown token. In this case, the host may reply with a
RST or silently ignore the error (<xref target="RFC6824"/> pages 22, 23 and 45).</t>
<t>A TCP segment is received without a DSS checksum on a Multipath
TCP connection where the usage of the checksum has been negotiated
(<xref target="RFC6824"/> page 24).</t>
<t>No DSS mapping has been received within a window of data (<xref target="RFC6824"/> page
27).</t>
</list></t>
</section>
<section anchor="fast-close" title="Fast Close">
<t>The MP_FASTCLOSE option is defined in <xref target="RFC6824"/> allows to quickly terminate
a Multipath TCP connection. This operation is described in section
3.5 of <xref target="RFC6824"/>.</t>
</section>
<section anchor="unspecified-tcp-error" title="Unspecified TCP error">
<t>A TCP implementation may send a RST segment for reasons that are
unrelated to Multipath TCP.</t>
</section>
</section>
<section anchor="the-mptcp-rst-option" title="The MPTCP RST option">
<t>The Multipath TCP specification <xref target="RFC6824"/> defines several Multipath TCP
options. Each option is encoded by using the Type-Length-Value
format shown in the figure below.</t>
<figure title="The Multipath TCP option format" anchor="figmptcpoption"><artwork><![CDATA[
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+-----------------------+
| Kind | Length |Subtype| |
+---------------+---------------+-------+ |
| Subtype-specific data |
| (variable length) |
+---------------------------------------------------------------+
]]></artwork></figure>
<t>The proposed format for the Multipath TCP RST option is defined in
the figure below.</t>
<figure title="The proposed Multipath TCP RST option format" anchor="figmptcprstoption"><artwork><![CDATA[
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+-----------------------+
| Kind | Length |Subtype|U V W T| Reason |
+---------------+---------------+-------+-----------------------+
]]></artwork></figure>
<t>The Multipath TCP RST option contains a reason code that allows the
sender of the option to provide more information about the reason for
the termination of the subflow. <xref target="RFC0793"/> allowed the utilisation of the
segment payload to provide additional information about the reason
for the termination of a TCP connection and some middleboxes have
used this facility <xref target="NDSS09"/>. However, without a precise format for the
reason code, the only thing that TCP implementations could do with
this payload was to log the received data. With a specific reason
field, it becomes possible for a Multipath TCP implementation to
intelligently and correctly react to the termination of a subflow.</t>
<t>The <spanx style="verb">T</spanx> flag is used by the sender to indicate whether the error
condition that is reported is Transient (T bit set to 1) or Permanent
(T bit set to 0). If the error condition is considered to be
Transient by the sender of the RST segment, the recipient of this
segment MAY try to reestablish a subflow over the failed path. If
the error condition is considered to be permanent, the receiver of
the RST segment SHOULD NOT try to reestablish a subflow over this
path. The <spanx style="verb">U</spanx>, <spanx style="verb">V</spanx> and <spanx style="verb">W</spanx> flags are not defined by this specification.</t>
<t>The <spanx style="verb">Reason</spanx> code is an 8 bits field that indicates the reason for
the termination of the subflow. The following codes are defined in
this document :</t>
<t><list style="symbols">
<t>Lack of ressources (code TBD1). This code indicates that the
sending host does not have enough ressources to support the
terminated subflow. </t>
<t>Administratively prohibited (code TBD2). This code indicates that
the requested subflow is prohibited by the policies of the sending
host. </t>
<t>Too many already acknowledged data (code TBD3). This code
indicates that there are too many data that need to be transmitted
over the terminated subflow while having already been acknowledged
over one or more other subflows. </t>
<t>Unacceptable performance (code TBD4). This code indicates that
the performance of this subflow was too low compared to the other
subflows of this Multipath TCP connection. </t>
<t>Lifetime expired (code TBD5). This code indicates that the
lifetime of the subflow has expired. </t>
<t>Removed address (code TBD6). This code indicates that the address
associated to this subflow has been removed by the sender. </t>
<t>Middlebox interference (code TBD7). Middlebox interference has
been detected over this subflow. </t>
<t>Multipath TCP specific error (code TBD8). An error has been
detected in the processing of Multipath TCP options. </t>
<t>Fast Close (code TBD9). This RST segment has been sent in
response to a segment with the MP_FASTCLOSE option. </t>
<t>Unspecified TCP error (code TBD10). An unspecified TCP error has
been detected on the affected subflow. </t>
</list></t>
<t><list style="numbers">
<t>IANA Considerations</t>
</list></t>
<t>This document request the allocation of a new MPTCP option sub-type
from IANA. Furthermore, it defines a set of error conditions that
can be encoded inside the MPTCP RST option. This list of error
conditions should be maintained by IANA.</t>
<texttable>
<ttcol align='left'>Codepoint #</ttcol>
<ttcol align='left'>Reason</ttcol>
<c>TBD1</c>
<c>Lack of ressources</c>
<c>TBD2</c>
<c>Administratively prohibited</c>
<c>TBD3</c>
<c>Too many unacknowledged data</c>
<c>TBD4</c>
<c>Unacceptable performance</c>
<c>TBD5</c>
<c>Lifetime expired</c>
<c>TBD6</c>
<c>Removed address</c>
<c>TBD7</c>
<c>Middlebox interference detected</c>
<c>TBD8</c>
<c>Multipath TCP specific error</c>
<c>TBD9</c>
<c>Response to Fast Close</c>
<c>TBD10</c>
<c>Unspecified TCP error</c>
</texttable>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>Single TCP is vulnerable to various forms of attacks that use RST segments. An off-path attacker could send spoofed RST segments to terminate existing TCP connections. Several techniques have been proposed to deal with such attacks <xref target="RFC6528"/> <xref target="RFC5961"/>. These techniques can also be used with Multipath TCP. The utilization of the proposed MPTCP RST option does not change anything to the applicability of these attack mitigation techniques. Since Multipath TCP supports break before make, it is important to note that a successful RST attack does not result in a release of the Multipath TCP connection. A host can decide to initiate a new subflow, over the same or another path, upon reception of a RST segment.</t>
<t>An on-path middlebox may generate RST segments to terminate some unwanted TCP connections <xref target="NDSS09"/> <xref target="RFC3360"/>. The attack mitigation techniques proposed in <xref target="RFC6528"/> and <xref target="RFC5961"/> are not suitable to defend against on-path attackers like middleboxes. As noted above, a host that receive a valid RST segment could still react by establishing another subflow, possibly over another path. The presence of the proposed RST option in the RST segment does not change these security considerations. </t>
</section>
<section anchor="conclusion" title="Conclusion">
<t>This document has analyzed the various reasons that may cause a Multipath TCP implementation to generate a RST segment. Since a Multipath TCP connection can combine several TCP subflows, the termination of one subflow does not necessarily lead to the termination of the entire Multipath TCP connection. We propose the Multipath TCP RST option to convey additional information about the reason that motivated the transmission of the RST segment.</t>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>This work was partially supported by the FP7 Trilogy2 project.</t>
</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='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='RFC6824'>
<front>
<title>TCP Extensions for Multipath Operation with Multiple Addresses</title>
<author initials='A.' surname='Ford' fullname='A. Ford'>
<organization /></author>
<author initials='C.' surname='Raiciu' fullname='C. Raiciu'>
<organization /></author>
<author initials='M.' surname='Handley' fullname='M. Handley'>
<organization /></author>
<author initials='O.' surname='Bonaventure' fullname='O. Bonaventure'>
<organization /></author>
<date year='2013' month='January' />
<abstract>
<t>TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure.</t><t> Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document defines an Experimental Protocol for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='6824' />
<format type='TXT' octets='164866' target='http://www.rfc-editor.org/rfc/rfc6824.txt' />
</reference>
<reference anchor='RFC3360'>
<front>
<title>Inappropriate TCP Resets Considered Harmful</title>
<author initials='S.' surname='Floyd' fullname='S. Floyd'>
<organization /></author>
<date year='2002' month='August' /></front>
<seriesInfo name='BCP' value='60' />
<seriesInfo name='RFC' value='3360' />
<format type='TXT' octets='46748' target='http://www.rfc-editor.org/rfc/rfc3360.txt' />
</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='RFC5961'>
<front>
<title>Improving TCP's Robustness to Blind In-Window Attacks</title>
<author initials='A.' surname='Ramaiah' fullname='A. Ramaiah'>
<organization /></author>
<author initials='R.' surname='Stewart' fullname='R. Stewart'>
<organization /></author>
<author initials='M.' surname='Dalal' fullname='M. Dalal'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>TCP has historically been considered to be protected against spoofed off-path packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32-bit sequence number(s). A combination of increasing window sizes and applications using longer-term connections (e.g., H-323 or Border Gateway Protocol (BGP) [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5961' />
<format type='TXT' octets='44717' target='http://www.rfc-editor.org/rfc/rfc5961.txt' />
</reference>
<reference anchor='RFC6528'>
<front>
<title>Defending against Sequence Number Attacks</title>
<author initials='F.' surname='Gont' fullname='F. Gont'>
<organization /></author>
<author initials='S.' surname='Bellovin' fullname='S. Bellovin'>
<organization /></author>
<date year='2012' month='February' />
<abstract>
<t>This document specifies an algorithm for the generation of TCP Initial Sequence Numbers (ISNs), such that the chances of an off-path attacker guessing the sequence numbers in use by a target connection are reduced. This document revises (and formally obsoletes) RFC 1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track, formally updating RFC 793. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6528' />
<format type='TXT' octets='26917' target='http://www.rfc-editor.org/rfc/rfc6528.txt' />
</reference>
</references>
<references title='Informative References'>
<reference anchor="IMC11" target="http://doi.acm.org/10.1145/2068816.2068834">
<front>
<title>Is it still possible to extend TCP ?</title>
<author initials="M." surname="Honda">
<organization></organization>
</author>
<author initials="Y." surname="Nishida">
<organization></organization>
</author>
<author initials="C." surname="Raiciu">
<organization></organization>
</author>
<author initials="A." surname="Greenhalgh">
<organization></organization>
</author>
<author initials="M." surname="Handley">
<organization></organization>
</author>
<author initials="H." surname="Tokuda">
<organization></organization>
</author>
<date year="2011"/>
</front>
<seriesInfo name="Proceedings of the 2011 ACM SIGCOMM conference on Internet measurement conference (IMC '11)" value=""/>
</reference>
<reference anchor="NDSS09" >
<front>
<title>Detecting Forged TCP Reset Packets</title>
<author initials="N." surname="Weaver">
<organization></organization>
</author>
<author initials="R." surname="Sommer">
<organization></organization>
</author>
<author initials="V." surname="Paxson">
<organization></organization>
</author>
<date year="2009"/>
</front>
<seriesInfo name="NDSS2009" value=""/>
</reference>
<reference anchor="INFOCOM14" >
<front>
<title>Cross-Layer Path Management in Multi-path Transport Protocol for Mobile Devices</title>
<author initials="Y." surname="Lim">
<organization></organization>
</author>
<author initials="Y." surname="Chen">
<organization></organization>
</author>
<author initials="E." surname="Nahum">
<organization></organization>
</author>
<author initials="D." surname="Towsley">
<organization></organization>
</author>
<author initials="K." surname="Lee">
<organization></organization>
</author>
<date year="2014"/>
</front>
<seriesInfo name="IEEE INFOCOM'14" value=""/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 21:58:39 |