One document matched: draft-paasch-mptcp-syncookies-02.ps
%!PS-Adobe-3.0
%%BoundingBox: 24 24 571 818
%%Title: Enscript Output
%%For: Christoph Paasch
%%Creator: GNU Enscript 1.6.6
%%CreationDate: Wed Oct 14 21:49:55 2015
%%Orientation: Portrait
%%Pages: (atend)
%%DocumentMedia: A4 595 842 0 () ()
%%DocumentNeededResources: (atend)
%%EndComments
%%BeginProlog
%%BeginResource: procset Enscript-Prolog 1.6 6
%
% Procedures.
%
/_S { % save current state
/_s save def
} def
/_R { % restore from saved state
_s restore
} def
/S { % showpage protecting gstate
gsave
showpage
grestore
} bind def
/MF { % fontname newfontname -> - make a new encoded font
/newfontname exch def
/fontname exch def
/fontdict fontname findfont def
/newfont fontdict maxlength dict def
fontdict {
exch
dup /FID eq {
% skip FID pair
pop pop
} {
% copy to the new font dictionary
exch newfont 3 1 roll put
} ifelse
} forall
newfont /FontName newfontname put
% insert only valid encoding vectors
encoding_vector length 256 eq {
newfont /Encoding encoding_vector put
} if
newfontname newfont definefont pop
} def
/MF_PS { % fontname newfontname -> - make a new font preserving its enc
/newfontname exch def
/fontname exch def
/fontdict fontname findfont def
/newfont fontdict maxlength dict def
fontdict {
exch
dup /FID eq {
% skip FID pair
pop pop
} {
% copy to the new font dictionary
exch newfont 3 1 roll put
} ifelse
} forall
newfont /FontName newfontname put
newfontname newfont definefont pop
} def
/SF { % fontname width height -> - set a new font
/height exch def
/width exch def
findfont
[width 0 0 height 0 0] makefont setfont
} def
/SUF { % fontname width height -> - set a new user font
/height exch def
/width exch def
/F-gs-user-font MF
/F-gs-user-font width height SF
} def
/SUF_PS { % fontname width height -> - set a new user font preserving its enc
/height exch def
/width exch def
/F-gs-user-font MF_PS
/F-gs-user-font width height SF
} def
/M {moveto} bind def
/s {show} bind def
/Box { % x y w h -> - define box path
/d_h exch def /d_w exch def /d_y exch def /d_x exch def
d_x d_y moveto
d_w 0 rlineto
0 d_h rlineto
d_w neg 0 rlineto
closepath
} def
/bgs { % x y height blskip gray str -> - show string with bg color
/str exch def
/gray exch def
/blskip exch def
/height exch def
/y exch def
/x exch def
gsave
x y blskip sub str stringwidth pop height Box
gray setgray
fill
grestore
x y M str s
} def
/bgcs { % x y height blskip red green blue str -> - show string with bg color
/str exch def
/blue exch def
/green exch def
/red exch def
/blskip exch def
/height exch def
/y exch def
/x exch def
gsave
x y blskip sub str stringwidth pop height Box
red green blue setrgbcolor
fill
grestore
x y M str s
} def
% Highlight bars.
/highlight_bars { % nlines lineheight output_y_margin gray -> -
gsave
setgray
/ymarg exch def
/lineheight exch def
/nlines exch def
% This 2 is just a magic number to sync highlight lines to text.
0 d_header_y ymarg sub 2 sub translate
/cw d_output_w cols div def
/nrows d_output_h ymarg 2 mul sub lineheight div cvi def
% for each column
0 1 cols 1 sub {
cw mul /xp exch def
% for each rows
0 1 nrows 1 sub {
/rn exch def
rn lineheight mul neg /yp exch def
rn nlines idiv 2 mod 0 eq {
% Draw highlight bar. 4 is just a magic indentation.
xp 4 add yp cw 8 sub lineheight neg Box fill
} if
} for
} for
grestore
} def
% Line highlight bar.
/line_highlight { % x y width height gray -> -
gsave
/gray exch def
Box gray setgray fill
grestore
} def
% Column separator lines.
/column_lines {
gsave
.1 setlinewidth
0 d_footer_h translate
/cw d_output_w cols div def
1 1 cols 1 sub {
cw mul 0 moveto
0 d_output_h rlineto stroke
} for
grestore
} def
% Column borders.
/column_borders {
gsave
.1 setlinewidth
0 d_footer_h moveto
0 d_output_h rlineto
d_output_w 0 rlineto
0 d_output_h neg rlineto
closepath stroke
grestore
} def
% Do the actual underlay drawing
/draw_underlay {
ul_style 0 eq {
ul_str true charpath stroke
} {
ul_str show
} ifelse
} def
% Underlay
/underlay { % - -> -
gsave
0 d_page_h translate
d_page_h neg d_page_w atan rotate
ul_gray setgray
ul_font setfont
/dw d_page_h dup mul d_page_w dup mul add sqrt def
ul_str stringwidth pop dw exch sub 2 div ul_h_ptsize -2 div moveto
draw_underlay
grestore
} def
/user_underlay { % - -> -
gsave
ul_x ul_y translate
ul_angle rotate
ul_gray setgray
ul_font setfont
0 0 ul_h_ptsize 2 div sub moveto
draw_underlay
grestore
} def
% Page prefeed
/page_prefeed { % bool -> -
statusdict /prefeed known {
statusdict exch /prefeed exch put
} {
pop
} ifelse
} def
% Wrapped line markers
/wrapped_line_mark { % x y charwith charheight type -> -
/type exch def
/h exch def
/w exch def
/y exch def
/x exch def
type 2 eq {
% Black boxes (like TeX does)
gsave
0 setlinewidth
x w 4 div add y M
0 h rlineto w 2 div 0 rlineto 0 h neg rlineto
closepath fill
grestore
} {
type 3 eq {
% Small arrows
gsave
.2 setlinewidth
x w 2 div add y h 2 div add M
w 4 div 0 rlineto
x w 4 div add y lineto stroke
x w 4 div add w 8 div add y h 4 div add M
x w 4 div add y lineto
w 4 div h 8 div rlineto stroke
grestore
} {
% do nothing
} ifelse
} ifelse
} def
% EPSF import.
/BeginEPSF {
/b4_Inc_state save def % Save state for cleanup
/dict_count countdictstack def % Count objects on dict stack
/op_count count 1 sub def % Count objects on operand stack
userdict begin
/showpage { } def
0 setgray 0 setlinecap
1 setlinewidth 0 setlinejoin
10 setmiterlimit [ ] 0 setdash newpath
/languagelevel where {
pop languagelevel
1 ne {
false setstrokeadjust false setoverprint
} if
} if
} bind def
/EndEPSF {
count op_count sub { pos } repeat % Clean up stacks
countdictstack dict_count sub { end } repeat
b4_Inc_state restore
} bind def
% Check PostScript language level.
/languagelevel where {
pop /gs_languagelevel languagelevel def
} {
/gs_languagelevel 1 def
} ifelse
%%EndResource
%%BeginResource: procset Enscript-Encoding-88591 1.6 6
/encoding_vector [
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/space /exclam /quotedbl /numbersign
/dollar /percent /ampersand /quoteright
/parenleft /parenright /asterisk /plus
/comma /hyphen /period /slash
/zero /one /two /three
/four /five /six /seven
/eight /nine /colon /semicolon
/less /equal /greater /question
/at /A /B /C
/D /E /F /G
/H /I /J /K
/L /M /N /O
/P /Q /R /S
/T /U /V /W
/X /Y /Z /bracketleft
/backslash /bracketright /asciicircum /underscore
/quoteleft /a /b /c
/d /e /f /g
/h /i /j /k
/l /m /n /o
/p /q /r /s
/t /u /v /w
/x /y /z /braceleft
/bar /braceright /tilde /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/space /exclamdown /cent /sterling
/currency /yen /brokenbar /section
/dieresis /copyright /ordfeminine /guillemotleft
/logicalnot /hyphen /registered /macron
/degree /plusminus /twosuperior /threesuperior
/acute /mu /paragraph /bullet
/cedilla /onesuperior /ordmasculine /guillemotright
/onequarter /onehalf /threequarters /questiondown
/Agrave /Aacute /Acircumflex /Atilde
/Adieresis /Aring /AE /Ccedilla
/Egrave /Eacute /Ecircumflex /Edieresis
/Igrave /Iacute /Icircumflex /Idieresis
/Eth /Ntilde /Ograve /Oacute
/Ocircumflex /Otilde /Odieresis /multiply
/Oslash /Ugrave /Uacute /Ucircumflex
/Udieresis /Yacute /Thorn /germandbls
/agrave /aacute /acircumflex /atilde
/adieresis /aring /ae /ccedilla
/egrave /eacute /ecircumflex /edieresis
/igrave /iacute /icircumflex /idieresis
/eth /ntilde /ograve /oacute
/ocircumflex /otilde /odieresis /divide
/oslash /ugrave /uacute /ucircumflex
/udieresis /yacute /thorn /ydieresis
] def
%%EndResource
%%EndProlog
%%BeginSetup
%%IncludeResource: font Courier-Bold
%%IncludeResource: font Courier
/HFpt_w 10 def
/HFpt_h 10 def
/Courier-Bold /HF-gs-font MF
/HF /HF-gs-font findfont [HFpt_w 0 0 HFpt_h 0 0] makefont def
/Courier /F-gs-font MF
/F-gs-font 10 10 SF
/#copies 1 def
% Pagedevice definitions:
gs_languagelevel 1 gt {
<<
/PageSize [595 842]
>> setpagedevice
} if
/d_page_w 547 def
/d_page_h 794 def
/d_header_x 0 def
/d_header_y 794 def
/d_header_w 547 def
/d_header_h 0 def
/d_footer_x 0 def
/d_footer_y 0 def
/d_footer_w 547 def
/d_footer_h 0 def
/d_output_w 547 def
/d_output_h 794 def
/cols 1 def
%%EndSetup
%%Page: (1) 1
%%BeginPageSetup
_S
24 24 translate
/pagenum 1 def
/fname (draft-paasch-mptcp-syncookies.txt) def
/fdir (.) def
/ftail (draft-paasch-mptcp-syncookies.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 737 M
(MPTCP Working Group C. Paasch) s
5 726 M
(Internet-Draft A. Biswas) s
5 715 M
(Intended status: Experimental D. Haas) s
5 704 M
(Expires: April 16, 2016 Apple, Inc.) s
5 693 M
( October 14, 2015) s
5 660 M
( Making Multipath TCP robust for stateless webservers) s
5 649 M
( draft-paasch-mptcp-syncookies-02) s
5 627 M
(Abstract) s
5 605 M
( This document proposes a modification of the MPTCP handshake that) s
5 594 M
( allows it to work efficiently with stateless servers. We first) s
5 583 M
( identify the issues around stateless connection establishment using) s
5 572 M
( SYN-cookies. Further, we suggest an extension to Multipath TCP to) s
5 561 M
( overcome these issues and discuss alternatives.) s
5 539 M
( As a side-effect, the proposed modification to the handshake opens) s
5 528 M
( the door to reduce the size of the MP_CAPABLE option in the SYN.) s
5 517 M
( This reduces the growing pressure on the TCP-option space in the SYN-) s
5 506 M
( segment, giving space for future extensions to TCP.) s
5 484 M
(Status of This Memo) s
5 462 M
( This Internet-Draft is submitted in full conformance with the) s
5 451 M
( provisions of BCP 78 and BCP 79.) s
5 429 M
( Internet-Drafts are working documents of the Internet Engineering) s
5 418 M
( Task Force \(IETF\). Note that other groups may also distribute) s
5 407 M
( working documents as Internet-Drafts. The list of current Internet-) s
5 396 M
( Drafts is at http://datatracker.ietf.org/drafts/current/.) s
5 374 M
( Internet-Drafts are draft documents valid for a maximum of six months) s
5 363 M
( and may be updated, replaced, or obsoleted by other documents at any) s
5 352 M
( time. It is inappropriate to use Internet-Drafts as reference) s
5 341 M
( material or to cite them other than as "work in progress.") s
5 319 M
( This Internet-Draft will expire on April 16, 2016.) s
5 297 M
(Copyright Notice) s
5 275 M
( Copyright \(c\) 2015 IETF Trust and the persons identified as the) s
5 264 M
( document authors. All rights reserved.) s
5 242 M
( This document is subject to BCP 78 and the IETF Trust's Legal) s
5 231 M
( Provisions Relating to IETF Documents) s
5 220 M
( \(http://trustee.ietf.org/license-info\) in effect on the date of) s
5 176 M
(Paasch, et al. Expires April 16, 2016 [Page 1]) s
_R
S
%%Page: (2) 2
%%BeginPageSetup
_S
24 24 translate
/pagenum 2 def
/fname (draft-paasch-mptcp-syncookies.txt) def
/fdir (.) def
/ftail (draft-paasch-mptcp-syncookies.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft Multipath TCP deployment October 2015) s
5 737 M
( publication of this document. Please review these documents) s
5 726 M
( carefully, as they describe your rights and restrictions with respect) s
5 715 M
( to this document. Code Components extracted from this document must) s
5 704 M
( include Simplified BSD License text as described in Section 4.e of) s
5 693 M
( the Trust Legal Provisions and are provided without warranty as) s
5 682 M
( described in the Simplified BSD License.) s
5 660 M
(Table of Contents) s
5 638 M
( 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2) s
5 627 M
( 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3) s
5 616 M
( 3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 4) s
5 605 M
( 3.1. Loss of the third ACK . . . . . . . . . . . . . . . . . . 4) s
5 594 M
( 3.1.1. MP_CAPABLE_ACK specification . . . . . . . . . . . . 5) s
5 583 M
( 3.1.2. TCP Fast Open . . . . . . . . . . . . . . . . . . . . 8) s
5 572 M
( 3.1.3. Negotiation . . . . . . . . . . . . . . . . . . . . . 8) s
5 561 M
( 3.1.4. DATA_FIN . . . . . . . . . . . . . . . . . . . . . . 8) s
5 550 M
( 3.1.5. Server sending data . . . . . . . . . . . . . . . . . 8) s
5 539 M
( 3.1.6. Middlebox considerations . . . . . . . . . . . . . . 9) s
5 528 M
( 3.2. Loss of the first data segment . . . . . . . . . . . . . 10) s
5 517 M
( 4. Alternative solutions . . . . . . . . . . . . . . . . . . . . 11) s
5 506 M
( 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11) s
5 495 M
( 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11) s
5 484 M
( 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12) s
5 473 M
( 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12) s
5 462 M
( 8.1. Normative References . . . . . . . . . . . . . . . . . . 12) s
5 451 M
( 8.2. Informative References . . . . . . . . . . . . . . . . . 12) s
5 440 M
( Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13) s
5 418 M
(1. Introduction) s
5 396 M
( During the establishment of a TCP connection, a server must create) s
5 385 M
( state upon the reception of the SYN [RFC0793]. Specifically, it) s
5 374 M
( needs to generate an initial sequence number, and reply to the) s
5 363 M
( options indicated in the SYN. The server typically maintains in-) s
5 352 M
( memory state for the embryonic connection, including state about what) s
5 341 M
( options were negotiated, such as window scale factor [RFC7323] and) s
5 330 M
( the maximum segment size. It also maintains state about whether SACK) s
5 319 M
( [RFC2018] and TCP Timestamps were negotiated during the 3-way) s
5 308 M
( handshake.) s
5 286 M
( Attackers exploit this state creation on the server through the SYN-) s
5 275 M
( flooding attack. Indeed, an attacker only needs to emit SYN segments) s
5 264 M
( with different 4-tuples \(source and destination IP addresses and port) s
5 253 M
( numbers\) in order to make the server create the state and thus) s
5 242 M
( consume its memory, while the attacker itself does not need to) s
5 231 M
( maintain any state for such an attack [RFC4987].) s
5 176 M
(Paasch, et al. Expires April 16, 2016 [Page 2]) s
_R
S
%%Page: (3) 3
%%BeginPageSetup
_S
24 24 translate
/pagenum 3 def
/fname (draft-paasch-mptcp-syncookies.txt) def
/fdir (.) def
/ftail (draft-paasch-mptcp-syncookies.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft Multipath TCP deployment October 2015) s
5 737 M
( A common mitigation of this attack is to use a mechanism called SYN-) s
5 726 M
( cookies. SYN-cookies rely on the fact that a TCP-connection echoes) s
5 715 M
( back certain information that the server puts in the SYN/ACK during) s
5 704 M
( the three-way handshake. Notably, the sequence-number is echoed back) s
5 693 M
( in the acknowledgment field as well as the TCP timestamp value inside) s
5 682 M
( the timestamp option. When generating the SYN/ACK, the server) s
5 671 M
( generates these fields in a verifiable fashion. Typically, servers) s
5 660 M
( use the 4-tuple, the client's sequence number plus a local secret) s
5 649 M
( \(which changes over time\) to generate the initial sequence number by) s
5 638 M
( applying a hashing function to the aforementioned fields. Further,) s
5 627 M
( setting certain bits either in the sequence number or the TCP) s
5 616 M
( timestamp value allows to encode for example whether SACK has been) s
5 605 M
( negotiated and what window-scaling has been received [M08]. Upon the) s
5 594 M
( reception of the third ACK, the server can thus verify whether the) s
5 583 M
( acknowledgment number is indeed the reply to a SYN/ACK it has) s
5 572 M
( generated \(using the 4-tuple and the local secret\). Further, it can) s
5 561 M
( decode from the timestamp echo reply the required information) s
5 550 M
( concerning SACK, window scaling and MSS-size.) s
5 528 M
( In case the third ACK is lost during the 3-way handshake of TCP,) s
5 517 M
( stateless servers only work if it's the client who initiates the) s
5 506 M
( communication by sending data to the server - which is commonly the) s
5 495 M
( case in today's application-layer protocols. As the data segment) s
5 484 M
( includes the acknowledgement number for the original SYN/ACK as well) s
5 473 M
( as the TCP timestamp value, the server is able to reconstruct the) s
5 462 M
( connection state even if the third ACK is lost in the network. If) s
5 451 M
( the very first data segment is also lost, then the server is unable) s
5 440 M
( to reconstruct the connection state and will respond to subsequent) s
5 429 M
( data sent by the client with a TCP Reset.) s
5 407 M
( Multipath TCP \(MPTCP [RFC6824]\) is unable to reconstruct the MPTCP) s
5 396 M
( level connection state if the third ack is lost in the network \(as) s
5 385 M
( explained in the following section\). If the first data segment from) s
5 374 M
( the client reaches the server, the server can reconstruct the TCP) s
5 363 M
( state but not the MPTCP state. Such a server can fallback to regular) s
5 352 M
( TCP upon the loss of the third ACK. MPTCP is also prone to the same) s
5 341 M
( problem as regular TCP if the first data segment is also lost.) s
5 319 M
( In the following section a more detailed assessment of the issues) s
5 308 M
( with MPTCP and TCP SYN-cookies is presented. Section 3 then shows) s
5 297 M
( how these issues might get solved.) s
5 275 M
(2. Problem statement) s
5 253 M
( Multipath TCP adds additional state to the 3-way handshake. Notably,) s
5 242 M
( the keys must be stored in the state so that later on new subflows) s
5 231 M
( can be established as well as the initial data sequence number is) s
5 220 M
( known to both hosts. In order to support stateless servers,) s
5 176 M
(Paasch, et al. Expires April 16, 2016 [Page 3]) s
_R
S
%%Page: (4) 4
%%BeginPageSetup
_S
24 24 translate
/pagenum 4 def
/fname (draft-paasch-mptcp-syncookies.txt) def
/fdir (.) def
/ftail (draft-paasch-mptcp-syncookies.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft Multipath TCP deployment October 2015) s
5 737 M
( Multipath TCP echoes the keys in the third ACK. A stateless server) s
5 726 M
( thus can generate its own key in a verifiable fashion \(similar to the) s
5 715 M
( initial sequence number\), and is able to learn the client's key) s
5 704 M
( through the echo in the third ACK. The generation of the key is) s
5 693 M
( implementation-specific. An example of such a key-generation would) s
5 682 M
( be: Key_Server = Hash\(5-tuple, server's subflow sequence number,) s
5 671 M
( local_secret\). The reliance on the third ACK however implies that if) s
5 660 M
( this segment gets lost, then the server cannot reconstruct the state) s
5 649 M
( associated to the MPTCP connection. Indeed, a Multipath TCP) s
5 638 M
( connection is forced to fallback to regular TCP in case the third ACK) s
5 627 M
( gets lost or has been reordered with the first data segment of the) s
5 616 M
( client, because it cannot infer the client's key from the connection) s
5 605 M
( and thus won't be able to generate a valid HMAC to establish new) s
5 594 M
( subflows nor does it know the initial data sequence number. In the) s
5 583 M
( remainder of this document we refer to the aforementioned issue as) s
5 572 M
( "Loss of the third ACK".) s
5 550 M
( Stateless servers also are unable to recover connection state when) s
5 539 M
( the third ack and the first data segment are lost. This issue,) s
5 528 M
( outlined hereafter, happens even when regular TCP is being used. In) s
5 517 M
( case the client is sending multiple segments when initiating the) s
5 506 M
( connection, it might be that the third ack as well as the first data) s
5 495 M
( segment get lost. Thus, the server only receives the second data) s
5 484 M
( segment and will try to reconstruct the state based on this segment's) s
5 473 M
( 4-tuple, sequence number and timestamp value. However, as this) s
5 462 M
( segment's sequence number has already gone beyond the client's) s
5 451 M
( initial sequence number, it will not be able to regenerate the) s
5 440 M
( appropriate SYN-cookie and thus the verification will fail. The) s
5 429 M
( server effectively cannot infer that the sequence number in the) s
5 418 M
( segment has gone beyond TCP's initial sequence number. This will) s
5 407 M
( make the server send a TCP reset as it appears to the server that it) s
5 396 M
( received a segment for which no SYN cookie was ever generated.) s
5 374 M
(3. Proposal) s
5 352 M
( This section shows how the above problems might be solved in) s
5 341 M
( Multipath TCP.) s
5 319 M
(3.1. Loss of the third ACK) s
5 297 M
( In order to make Multipath TCP robust against the loss of the third) s
5 286 M
( ACK when SYN-cookies are being deployed on servers, we must make sure) s
5 275 M
( that the state-information relevant to Multipath TCP reaches the) s
5 264 M
( server in a reliable way. If the client is initiating the data) s
5 253 M
( transfer to the server \(this data is being delivered reliably through) s
5 242 M
( TCP\) the state-information could be delivered together with this data) s
5 231 M
( and thus is implicitly reliably sent to the server - when the data) s
5 220 M
( reaches the server, the state-information reaches the server as well.) s
5 176 M
(Paasch, et al. Expires April 16, 2016 [Page 4]) s
_R
S
%%Page: (5) 5
%%BeginPageSetup
_S
24 24 translate
/pagenum 5 def
/fname (draft-paasch-mptcp-syncookies.txt) def
/fdir (.) def
/ftail (draft-paasch-mptcp-syncookies.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft Multipath TCP deployment October 2015) s
5 737 M
( We achieve this by adding another variant to the MP_CAPABLE option,) s
5 726 M
( differentiated by the length of it \(we call this option) s
5 715 M
( MP_CAPABLE_ACK in the remainder of this document\). It is solely sent) s
5 704 M
( on the very first data segment from the client to the server. This) s
5 693 M
( option serves the dual purpose of conveying the client's and server's) s
5 682 M
( key as well as the DSS mapping which would otherwise have been sent) s
5 671 M
( in a DSS option on the first data segment.) s
5 649 M
( Making the MP_CAPABLE in the third ACK reliable opens the door for) s
5 638 M
( another improvement in MPTCP. In fact, the client doesn't need to) s
5 627 M
( send its own key in the SYN anymore \(it will send it reliably in the) s
5 616 M
( MP_CAPABLE_ACK\). Thus, the MP_CAPABLE option in the SYN segment can) s
5 605 M
( avoid adding the key, reducing the option-space requirement of the) s
5 594 M
( MP_CAPABLE down to 4 bytes. This is a major improvement as the) s
5 583 M
( option-space in the SYN segment is very limited, and allows a TCP) s
5 572 M
( connection to negotiate future extensions in the SYN.) s
5 550 M
( As this change is a major extension to Multipath TCP, we require that) s
5 539 M
( the version number of the MP_CAPABLE is increased. Further details) s
5 528 M
( on the negotiation are presented in Section 3.1.3. The following is) s
5 517 M
( a detailled description of the option format and the suggested) s
5 506 M
( handshake.) s
5 484 M
(3.1.1. MP_CAPABLE_ACK specification) s
5 462 M
( We suggest to remove the key from the MP_CAPABLE in the SYN-segment.) s
5 451 M
( The format of the MP_CAPABLE remains the same \(with the bits A to H) s
5 440 M
( as well as the version number\), with the difference that the key is) s
5 429 M
( no more present. Hosts are able to differentiate between the) s
5 418 M
( different MP_CAPABLE options through the length-field of the TCP-) s
5 407 M
( option.) s
5 385 M
( The MP_CAPABLE option in the SYN/ACK as well as the third ACK \(which) s
5 374 M
( does not contain any data\) remain unmodified from RFC6824.) s
5 352 M
( The MP_CAPABLE_ACK option \(shown in Figure 1\) contains the same set) s
5 341 M
( of bits A to H as well as the version number, like the MP_CAPABLE) s
5 330 M
( option. Further, the option includes the data-level length as well) s
5 319 M
( as the checksum \(in case it has been negotiated during the 3-way) s
5 308 M
( handshake\). This allows the server to reconstruct the mapping and) s
5 297 M
( deliver the data to the application. It must be noted that the) s
5 286 M
( information inside the MP_CAPABLE_ACK is less explicit than a DSS) s
5 275 M
( option. Notably, the data-sequence number, data acknowledgment as) s
5 264 M
( well as the relative subflow-sequence number are not part of the) s
5 253 M
( MP_CAPABLE_ACK. Nevertheless, the server is able to reconstruct the) s
5 242 M
( mapping because the MP_CAPABLE_ACK is guaranteed to only be sent on) s
5 231 M
( the very first data segment. Thus, implicitly the relative subflow-) s
5 176 M
(Paasch, et al. Expires April 16, 2016 [Page 5]) s
_R
S
%%Page: (6) 6
%%BeginPageSetup
_S
24 24 translate
/pagenum 6 def
/fname (draft-paasch-mptcp-syncookies.txt) def
/fdir (.) def
/ftail (draft-paasch-mptcp-syncookies.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft Multipath TCP deployment October 2015) s
5 737 M
( sequence number equals 1 as well as the data-sequence number, which) s
5 726 M
( is equal to the initial data-sequence number.) s
5 704 M
( 1 2 3) s
5 693 M
( 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) s
5 682 M
( +---------------+---------------+-------+-----------------------+) s
5 671 M
( | Kind | Length=24 |Subtype|Version|A|B|C|D|E|F|G|H|) s
5 660 M
( +---------------+---------------+-------+-----------------------+) s
5 649 M
( | Sender's Key \(64 bits\) |) s
5 638 M
( | |) s
5 627 M
( +---------------+---------------+-------+-----------------------+) s
5 616 M
( | Receiver's Key \(64 bits\) |) s
5 605 M
( | |) s
5 594 M
( +---------------------------------------------------------------+) s
5 583 M
( | Data-Level Length \(2 octets\) | Checksum \(2 octets, optional\) |) s
5 572 M
( +---------------------------------------------------------------+) s
5 550 M
( Format of the MP_CAPABLE_ACK option.) s
5 528 M
( Figure 1) s
5 506 M
( The handshake \(depicted in Figure 2\) starts with the client sending) s
5 495 M
( the MP_CAPABLE option to the server inside the SYN. The client is) s
5 484 M
( not required to having generated its key already at this point.) s
5 462 M
( Upon reception of this SYN-segment, a stateful server generates a) s
5 451 M
( random key and replies with a SYN/ACK. If the server behaves in a) s
5 440 M
( stateless manner it has to generate it's own key in a verifiable) s
5 429 M
( fashion. This verifiable way of generating the key can be done by) s
5 418 M
( using a hash of the 4-tuple, sequence number and a local secret) s
5 407 M
( \(similar to what is done for the TCP-sequence number [RFC4987]\). It) s
5 396 M
( will thus be able to verify whether it is indeed the originator of) s
5 385 M
( the key echoed back in the MP_CAPABLE_ACK option. When generating) s
5 374 M
( this verifiable key, the server has to ensure that the token derived) s
5 363 M
( from this key is locally unique \(Section 3.1 of RFC6824\). If there) s
5 352 M
( is already an MPTCP-session with such a token, the server must) s
5 341 M
( fallback to regular TCP by not sending an MP_CAPABLE in the third) s
5 330 M
( ACK.) s
5 176 M
(Paasch, et al. Expires April 16, 2016 [Page 6]) s
_R
S
%%Page: (7) 7
%%BeginPageSetup
_S
24 24 translate
/pagenum 7 def
/fname (draft-paasch-mptcp-syncookies.txt) def
/fdir (.) def
/ftail (draft-paasch-mptcp-syncookies.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft Multipath TCP deployment October 2015) s
5 737 M
( Host A Host B) s
5 726 M
( ------ ------) s
5 715 M
( SYN + MP_CAPABLE \(4 bytes\)) s
5 704 M
( -------------------------------------------->) s
5 693 M
( SYN/ACK + MP_CAPABLE \(Key_B, 12 bytes\)) s
5 682 M
( <--------------------------------------------) s
5 671 M
( ACK + MP_CAPABLE \(Key_A, Key_B, 20 bytes\)) s
5 660 M
( -------------------------------------------->) s
5 638 M
( DATA + MP_CAPABLE_ACK \(Key_A, Key_B, Length, Csum, 24 bytes\)) s
5 627 M
( -------------------------------------------->) s
5 605 M
( The modified MPTCP-handshake only consumes 4 bytes in the SYN.) s
5 583 M
( Figure 2) s
5 561 M
( To complete the three-way handshake, the client has to reply with a) s
5 550 M
( third ACK and the MP_CAPABLE option \(with both keys as defined in) s
5 539 M
( RFC6824\). If the client has already data to send, it can even avoid) s
5 528 M
( sending the third ACK, and immediately send the data together with) s
5 517 M
( the MP_CAPABLE_ACK. Otherwise, the client sends the MP_CAPABLE_ACK) s
5 506 M
( as soon as the application writes data on the socket.) s
5 484 M
( The goal of the third ACK \(with the MP_CAPABLE\) as well as the) s
5 473 M
( MP_CAPABLE_ACK is to convey the client's key to the server. An) s
5 462 M
( indication for the client that the server received the key is when) s
5 451 M
( the server issues a DATA_ACK inside the DSS-option \(even if this) s
5 440 M
( DATA_ACK does not acknowledge any data\). Thus, as long as the client) s
5 429 M
( has not sent an MP_CAPABLE_ACK with data, it must add the MP_CAPABLE) s
5 418 M
( option in each \(non-data\) segment sent to the server. It must do) s
5 407 M
( this until it either did send an MP_CAPABLE_ACK or until it received) s
5 396 M
( a DATA_ACK from the server. The reason for this is explained in) s
5 385 M
( Section 3.1.2 and Section 3.1.5. Combining the MP_CAPABLE with the) s
5 374 M
( DATA_ACK will require 20 + 8 bytes, which still leaves 12 bytes for) s
5 363 M
( the TCP timestamp option.) s
5 341 M
( Finally, the server must send a duplicate acknowledgment to the) s
5 330 M
( client upon reception of the client's key. This, to convey to the) s
5 319 M
( client that it successfully received the MP_CAPABLE\(_ACK\) option. It) s
5 308 M
( must be noted that this 4-way handshake does not prevent the client) s
5 297 M
( to send data before the reception of this fourth acknowledgment.) s
5 275 M
( This mechanism of sending the MP_CAPABLE with a DATA_ACK until the) s
5 264 M
( server acknowledges it, introduces additional complexity to the) s
5 253 M
( handshake. However, we consider the gain of reducing the MP_CAPABLE) s
5 242 M
( option in the SYN-segment as significant enough, that it is worth to) s
5 231 M
( accept this added complexity.) s
5 176 M
(Paasch, et al. Expires April 16, 2016 [Page 7]) s
_R
S
%%Page: (8) 8
%%BeginPageSetup
_S
24 24 translate
/pagenum 8 def
/fname (draft-paasch-mptcp-syncookies.txt) def
/fdir (.) def
/ftail (draft-paasch-mptcp-syncookies.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft Multipath TCP deployment October 2015) s
5 737 M
(3.1.2. TCP Fast Open) s
5 715 M
( If TCP Fast Open [RFC7413] is being used in combination with) s
5 704 M
( Multipath TCP [I-D.barre-mptcp-tfo], the server is allowed to send) s
5 693 M
( data right after the SYN/ACK, without the need to wait for the third) s
5 682 M
( ACK. The server sending this data cannot include a DATA_ACK option) s
5 671 M
( inside the DSS option as it does not yet know the client's key. This) s
5 660 M
( is not an issue as the DATA_ACK is optional in the DSS option.) s
5 638 M
( However, the client receiving this data sent by the server will have) s
5 627 M
( to acknowledge it with a DATA_ACK. As specified above, the client) s
5 616 M
( must also send an MP_CAPABLE option on this acknowledgment as it) s
5 605 M
( didn't yet receive a DATA_ACK from the server.) s
5 583 M
(3.1.3. Negotiation) s
5 561 M
( We require a way for the hosts to negotiate support for the suggested) s
5 550 M
( handshake. As we modify the size of the MP_CAPABLE, our proposal) s
5 539 M
( relies on a new version of MPTCP. The client requests this new) s
5 528 M
( version of MPTCP during the MP_CAPABLE exchange \(it remains to be) s
5 517 M
( defined by the IETF which version of MPTCP includes the) s
5 506 M
( MP_CAPABLE_ACK option\). If the server supports this version, it) s
5 495 M
( replies with a SYN/ACK including the MP_CAPABLE and indicating this) s
5 484 M
( same version.) s
5 462 M
(3.1.4. DATA_FIN) s
5 440 M
( As the MP_CAPABLE_ACK option includes the same bitfields as the) s
5 429 M
( regular MP_CAPABLE, there is no space to indicate a DATA_FIN as is) s
5 418 M
( done in the DSS option. This implies that a client cannot send a) s
5 407 M
( DATA_FIN together with the first segment of data. Thus, if the) s
5 396 M
( server requests the usage of MP_CAPABLE_ACK through the C-bit, the) s
5 385 M
( client must send a separate segment with the DSS-option, setting the) s
5 374 M
( DATA_FIN-flag to 1, after it has sent the data-segment that includes) s
5 363 M
( the MP_CAPABLE_ACK option.) s
5 341 M
(3.1.5. Server sending data) s
5 319 M
( The MP_CAPABLE_ACK version can only be sent by the client if it) s
5 308 M
( actually has data to send. One question that this raises is how the) s
5 297 M
( proposal will work when the server is the first one to send data to) s
5 286 M
( the client. In the following we describe how the handshake will) s
5 275 M
( still work when servers behave in a stateless and stateful manner.) s
5 253 M
( For stateless servers the same issue arises as well for regular TCP.) s
5 242 M
( Upon loss of the third ACK, the server cannot complete the three-way) s
5 231 M
( handshake. Thus, stateless servers that begin the application level) s
5 220 M
( protocol by emitting data rely on the fact that the third ACK is) s
5 176 M
(Paasch, et al. Expires April 16, 2016 [Page 8]) s
_R
S
%%Page: (9) 9
%%BeginPageSetup
_S
24 24 translate
/pagenum 9 def
/fname (draft-paasch-mptcp-syncookies.txt) def
/fdir (.) def
/ftail (draft-paasch-mptcp-syncookies.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft Multipath TCP deployment October 2015) s
5 737 M
( received \(irregardless of whether MPTCP is used or not\). Thus, this) s
5 726 M
( implies that the server also will receive the MP_CAPABLE with this) s
5 715 M
( third ACK.) s
5 693 M
( Stateful servers will retransmit the SYN/ACK until the third ACK) s
5 682 M
( \(including the MP_CAPABLE\) has been received. This will thus provide) s
5 671 M
( to the server the client's key. When the client eventually sends its) s
5 660 M
( own first data segment to the server, it actually does not has to use) s
5 649 M
( the MP_CAPABLE_ACK option because the server already did send a) s
5 638 M
( DATA_ACK to the client.) s
5 616 M
(3.1.6. Middlebox considerations) s
5 594 M
( Multipath TCP has been designed with middleboxes in mind and so the) s
5 583 M
( MP_CAPABLE_ACK option must also be able to go through middleboxes.) s
5 572 M
( The following middlebox behaviors have been considered and) s
5 561 M
( MP_CAPABLE_ACK acts accordingly across these middleboxes:) s
5 539 M
( o Removing MP_CAPABLE_ACK-option: If a middlebox strips the) s
5 528 M
( MP_CAPABLE_ACK option out of the data segment, the server receives) s
5 517 M
( data without a corresponding mapping. As defined in Section 3.6) s
5 506 M
( of [RFC6824], the server must then do a seamless fallback to) s
5 495 M
( regular TCP.) s
5 473 M
( o Coalescing segments: A middlebox might coalesce the first and) s
5 462 M
( second data segment into one single segment. While doing so, it) s
5 451 M
( might remove one of the options \(either MP_CAPABLE_ACK or the DSS-) s
5 440 M
( option of the second segment because of the limited 40 bytes TCP) s
5 429 M
( option space\). There are two cases to consider:) s
5 407 M
( * If the DSS-option is not included in the segment, the second) s
5 396 M
( half of the payload is not covered by a mapping. Thus, the) s
5 385 M
( server will do a seamless fallback to regular TCP as defined by) s
5 374 M
( [RFC6824] in Section 3.6. This fallback will trigger because) s
5 363 M
( RFC6824 specifies that during the beginning of a connection \(as) s
5 352 M
( long as the path has not been proven to let the MPTCP-options) s
5 341 M
( unmodified in both directions\) a seamless fallback to regular) s
5 330 M
( TCP must be done by stopping to send DATA_ACKs to the client.) s
5 308 M
( * If the MP_CAPABLE_ACK option is not present, then the DSS-) s
5 297 M
( option provides an offset of the TCP sequence number. As the) s
5 286 M
( server behaves statelessly it can only assume that the present) s
5 275 M
( mapping belongs to the first byte of the payload \(similar to) s
5 264 M
( what is explained in detail in Section 3.2\). As this however) s
5 253 M
( is not true, it will calculate an incorrect initial TCP) s
5 242 M
( sequence number and thus reply with a TCP-reset as the SYN-) s
5 231 M
( cookie is invalid. As such kind of middleboxes are very rare) s
5 220 M
( we consider this behavior as acceptable.) s
5 176 M
(Paasch, et al. Expires April 16, 2016 [Page 9]) s
_R
S
%%Page: (10) 10
%%BeginPageSetup
_S
24 24 translate
/pagenum 10 def
/fname (draft-paasch-mptcp-syncookies.txt) def
/fdir (.) def
/ftail (draft-paasch-mptcp-syncookies.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft Multipath TCP deployment October 2015) s
5 737 M
( o Splitting segments: A TCP segmentation offload engine \(TSO\) might) s
5 726 M
( split the first segment in smaller segments and copy the) s
5 715 M
( MP_CAPABLE_ACK option on each of these segments. Thanks to the) s
5 704 M
( data-length value included in the MP_CAPABLE_ACK option, the) s
5 693 M
( server is able to detect this and correctly reconstructs the) s
5 682 M
( mapping. In case the first of these splitted segments gets lost,) s
5 671 M
( the server finds itself in a situation similar to the one) s
5 660 M
( described in Section 2. The TCP sequence number doesn't allow) s
5 649 M
( anymore to verify the SYN-cookie and thus a TCP reset is sent.) s
5 638 M
( This behavior is the same as for regular TCP.) s
5 616 M
( o Payload modifying middlebox: In case the middlebox modifies the) s
5 605 M
( payload, the DSS-checksum included in the MP_CAPABLE_ACK option) s
5 594 M
( allows to detect this and will trigger a fallback to regular TCP) s
5 583 M
( as defined in [RFC6824].) s
5 561 M
(3.2. Loss of the first data segment) s
5 539 M
( Section 2 described the issue of losing the first data segment of a) s
5 528 M
( connection while TCP SYN-cookies are in use. The following outlines) s
5 517 M
( how Multipath TCP actually allows to fix this particular issue.) s
5 495 M
( Consider the packet-flow of Figure 3. Upon reception of the second) s
5 484 M
( data segment, the included data sequence mapping allows the server to) s
5 473 M
( actually detect that this is not the first segment of a TCP) s
5 462 M
( connection. Indeed, the relative subflow sequence number inside the) s
5 451 M
( DSS-mapping is actually 100, indicating that this segment is already) s
5 440 M
( further ahead in the TCP stream. This allows the server to actually) s
5 429 M
( reconstruct the initial sequence number based on the sequence number) s
5 418 M
( in the TCP-header \(\(X+100\) - 100\) that has been provided by the) s
5 407 M
( client and verify whether its SYN-cookie is correct. Thus, no TCP-) s
5 396 M
( reset is being sent - in contrast to regular TCP, where the server) s
5 385 M
( cannot verify the SYN-cookie. The server knows that the received) s
5 374 M
( segment is not the first one of the data stream and thus it can store) s
5 363 M
( it temporarily in the out-of-order queue of the connection. It must) s
5 352 M
( be noted that the server is not yet able to fully reconstruct the) s
5 341 M
( MPTCP state. In order to do this it still must await the) s
5 330 M
( MP_CAPABLE_ACK option that is provided in the first data segment.) s
5 308 M
( The server responds to the out-of-order data with a duplicate ACK.) s
5 297 M
( The duplicate ACK may also have SACK data if SACK was negotiated.) s
5 286 M
( However, if this duplicate ACK does not have an MPTCP level Data ACK,) s
5 275 M
( the client may interpret this as a fallback to TCP. This is because) s
5 264 M
( the client cannot determine if an option stripping middlebox removed) s
5 253 M
( the MPTCP option on TCP segments after connection establishment. So) s
5 242 M
( even though the server has not fully recreated the MPTCP state at) s
5 231 M
( this point, it should respond with a Data ACK set to the Data) s
5 220 M
( Sequence Number Y-100. The client's TCP implementation may) s
5 176 M
(Paasch, et al. Expires April 16, 2016 [Page 10]) s
_R
S
%%Page: (11) 11
%%BeginPageSetup
_S
24 24 translate
/pagenum 11 def
/fname (draft-paasch-mptcp-syncookies.txt) def
/fdir (.) def
/ftail (draft-paasch-mptcp-syncookies.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft Multipath TCP deployment October 2015) s
5 737 M
( retransmit the first data segment after a TCP retransmit timeout or) s
5 726 M
( it may do so as part of an Early Retransmit that can be triggered by) s
5 715 M
( an ACK arriving from the server.) s
5 693 M
( Host A Host B) s
5 682 M
( ------ ------) s
5 671 M
( SYN + MP_CAPABLE) s
5 660 M
( -------------------------------------------->) s
5 649 M
( SYN/ACK + MP_CAPABLE) s
5 638 M
( <--------------------------------------------) s
5 627 M
( ACK + MP_CAPABLE) s
5 616 M
( -----------------------------------X) s
5 594 M
( DATA \(TCP-seq = X\) + MP_CAPABLE_ACK) s
5 583 M
( -----------------------------------X) s
5 572 M
( DATA \(TCP-seq = X+100\) + DSS \(DSN = Y, subseq = 100\)) s
5 561 M
( --------------------------------------------->) s
5 539 M
( DATA_ACK \(Y - 100\)) s
5 528 M
( <---------------------------------------------) s
5 506 M
( Multipath TCP's DSS option allows to handle the loss of the first) s
5 495 M
( data segment as the host can infer the initial sequence number.) s
5 473 M
( Figure 3) s
5 451 M
(4. Alternative solutions) s
5 429 M
( An alternative solution to creating the MP_CAPABLE_ACK option would) s
5 418 M
( have been to emit the MP_CAPABLE-option together with the DSS-option) s
5 407 M
( on the first data segment. However, as the MP_CAPABLE option is 20) s
5 396 M
( bytes long and the DSS-option \(using 4-byte sequence numbers\)) s
5 385 M
( consumes 16 bytes, a total of 36 bytes of the TCP option space would) s
5 374 M
( be consumed by this approach. This option has been dismissed as it) s
5 363 M
( would prevent any other TCP option in the first data segment, a) s
5 352 M
( constraint that would severely limit TCP's extensibility in the) s
5 341 M
( future.) s
5 319 M
(5. IANA Considerations) s
5 297 M
( Our proposal requires the change of the MPTCP-version number.) s
5 275 M
(6. Security Considerations) s
5 253 M
( Sending the keys in a reliable way after the three-way handshake) s
5 242 M
( implies that there is a larger window during which an on-path) s
5 231 M
( attacker might modify the keys that are being sent in the) s
5 220 M
( MP_CAPABLE_ACK. However, we do not think that this can actually be) s
5 176 M
(Paasch, et al. Expires April 16, 2016 [Page 11]) s
_R
S
%%Page: (12) 12
%%BeginPageSetup
_S
24 24 translate
/pagenum 12 def
/fname (draft-paasch-mptcp-syncookies.txt) def
/fdir (.) def
/ftail (draft-paasch-mptcp-syncookies.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft Multipath TCP deployment October 2015) s
5 737 M
( considered as a security issue. If an attacker modifies the keys,) s
5 726 M
( the outcome will be that the client and the server won't agree) s
5 715 M
( anymore on the data-sequence numbers. The data-flow will thus stall.) s
5 704 M
( Considering that the attacker has to be an active on-path attacker to) s
5 693 M
( launch this attack, he has already other means of interfering with) s
5 682 M
( the connection. Thus, this attack is considered as irrelevant.) s
5 660 M
( Further, if servers implement the proposal from Section 3.2, to) s
5 649 M
( handle the scenario where the first data-segment is lost, the) s
5 638 M
( incoming segments need to be stored in the out-of-order queue. The) s
5 627 M
( server will store these segments without having verified the key that) s
5 616 M
( the client provides in the MP_CAPABLE option. This might be) s
5 605 M
( considered as a security risk where an attacker could consume buffer) s
5 594 M
( space in the server. It must be noted however that in order to) s
5 583 M
( achieve this, the attacker needs to correctly guess the SYN-cookie so) s
5 572 M
( that the verification described in Section 3.2 is successful. As) s
5 561 M
( MPTCP does not try to be more secure than regular TCP, this thread) s
5 550 M
( can be considered acceptable, as it uses the same level of security) s
5 539 M
( as regular TCP's SYN-cookies. Nevertheless, servers are free to) s
5 528 M
( avoid storing those segments in the out-of-order queue if the thread) s
5 517 M
( is considered important enough.) s
5 495 M
(7. Acknowledgments) s
5 473 M
( We would like to thank Olivier Bonaventure, Yoshifumi Nishida and) s
5 462 M
( Alan Ford for their comments and suggestions on this draft.) s
5 440 M
(8. References) s
5 418 M
(8.1. Normative References) s
5 396 M
( [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common) s
5 385 M
( Mitigations", RFC 4987, August 2007.) s
5 363 M
( [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,) s
5 352 M
( "TCP Extensions for Multipath Operation with Multiple) s
5 341 M
( Addresses", RFC 6824, January 2013.) s
5 319 M
(8.2. Informative References) s
5 297 M
( [I-D.barre-mptcp-tfo]) s
5 286 M
( Barre, S., Detal, G., and O. Bonaventure, "TFO support for) s
5 275 M
( Multipath TCP", draft-barre-mptcp-tfo-01 \(work in) s
5 264 M
( progress\), January 2015.) s
5 242 M
( [M08] McManus, P., "Improving syncookies", 2008,) s
5 231 M
( <http://lwn.net/Articles/277146/>.) s
5 176 M
(Paasch, et al. Expires April 16, 2016 [Page 12]) s
_R
S
%%Page: (13) 13
%%BeginPageSetup
_S
24 24 translate
/pagenum 13 def
/fname (draft-paasch-mptcp-syncookies.txt) def
/fdir (.) def
/ftail (draft-paasch-mptcp-syncookies.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft Multipath TCP deployment October 2015) s
5 737 M
( [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC) s
5 726 M
( 793, September 1981.) s
5 704 M
( [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP) s
5 693 M
( Selective Acknowledgment Options", RFC 2018, October 1996.) s
5 671 M
( [RFC7323] Borman, D., Braden, B., Jacobson, V., and R.) s
5 660 M
( Scheffenegger, "TCP Extensions for High Performance", RFC) s
5 649 M
( 7323, September 2014.) s
5 627 M
( [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP) s
5 616 M
( Fast Open", RFC 7413, December 2014.) s
5 594 M
(Authors' Addresses) s
5 572 M
( Christoph Paasch) s
5 561 M
( Apple, Inc.) s
5 550 M
( Cupertino) s
5 539 M
( US) s
5 517 M
( Email: cpaasch@apple.com) s
5 484 M
( Anumita Biswas) s
5 473 M
( Apple, Inc.) s
5 462 M
( Cupertino) s
5 451 M
( US) s
5 429 M
( Email: anumita_biswas@apple.com) s
5 396 M
( Darren Haas) s
5 385 M
( Apple, Inc.) s
5 374 M
( Cupertino) s
5 363 M
( US) s
5 341 M
( Email: dhaas@apple.com) s
5 176 M
(Paasch, et al. Expires April 16, 2016 [Page 13]) s
_R
S
%%Trailer
%%Pages: 13
%%DocumentNeededResources: font Courier-Bold Courier
%%EOF
| PAFTECH AB 2003-2026 | 2026-04-24 03:19:00 |