Re: [tcpm] I-D Action:draft-ietf-tcpm-1323bis-01.txt

[David Borman <[e-mail]>]

Hi,

I've just posted a new revision of 1323bis.  I've tried to incorporate  
all the things from the Philadelphia meeting, including adding a real  
Security Considerations section.  Some of my notes were a bit cryptic,  
as were the TCPM Meeting Minutes, so I've probably missed some things  
there.

I'm attaching diffs from -00 to -01, that I've edited down to  
eliminate the trivial changes (like changing "RFC-XXXX" to "RFC XXXX",  
boilerplate changes, page alignment, etc.)

Note that I've pulled out the TCP MSS discussion, and have posted that  
in a separate ID.

I know there are more changes that will need to be done to this  
document, for example I there are changes that should be made due to  
Fernando's Timestamps document.  But I wanted to get a new version of  
this out.

A couple other things I've added:
o) The shrinking window issue Matt Mathis brought up, due to the  
granularity of using the window scale option
o) More comments on the need to adjust the RTO calculator when you are  
taking more RTTM samples per RTT.

I'd also like to thank Alfred Hines for an off-list review of -00 that  
he sent me, many of his suggestions are incorporated in this document.


So, please look over the new document, and please point out on the  
mailing list any additional changes that need to be made to this  
document.  It's getting closer to something that we can publish, so  
the more feedback the better.  This will be added to the agenda in the  
TCPM WG in San Francisco, and it'd be nice if we could bring up any  
new issues on the mailing list, prior to the meeting. :-)

			-David Borman



98,100c124,127
<    1 ms to 100 seconds.  Work on TCP performance has shown that TCP  
can
<    work well over a variety of Internet paths, ranging from 800 Mbit/ 
sec
<    I/O channels to 300 bit/sec dial-up modems [Jacobson88a].
---
 >    1 ms to 100 seconds.  Work on TCP performance has shown that TCP
 >    without the extensions described in this memo can work well over a
 >    variety of Internet paths, ranging from 800 Mbit/sec I/O  
channels to
 >    300 bit/sec dial-up modems [Jacobson88a].
137,143c156,161
<       High-capacity packet satellite channels (e.g., DARPA's Wideband
<       Net) are LFN's.  For example, a DS1-speed satellite channel  
has a
<       bandwidth*delay product of 10**6 bits or more; this  
corresponds to
<       100 outstanding TCP segments of 1200 bytes each.  Terrestrial
<       fiber-optical paths will also fall into the LFN class; for
<       example, a cross-country delay of 30 ms at a DS3 bandwidth
<       (45Mbps) also exceeds 10**6 bits.
---
 >       High-capacity packet satellite channels are LFN's.  For  
example, a
 >       DS1-speed satellite channel has a bandwidth*delay product of  
10**6
 >       bits or more; this corresponds to 100 outstanding TCP  
segments of
 >       1200 bytes each.  Terrestrial fiber-optical paths will also  
fall
 >       into the LFN class; for example, a cross-country delay of 30  
ms at
 >       a DS3 bandwidth (45Mbps) also exceeds 10**6 bits.
185,189c203,207
<            LFN.  In addition, if a congestion control mechanism based
<            upon some form of random dropping were introduced into
<            gateways, randomly spaced packet drops would become common,
<            possible increasing the probability of dropping more than  
one
<            packet per window.
---
 >            LFN.  In addition, since the publication of RFC 1323,
 >            congestion control mechanism based upon some form of  
random
 >            dropping have been introduced into gateways, and randomly
 >            spaced packet drops have become common; this increases the
 >            probability of dropping more than one packet per window.
313c356
<            ARPANET       56kbps       7KBps    3*10**5 (~3.6 days)
---
 >            Dialup        56kbps       7KBps    3*10**5 (~3.6 days)
316a360
 >            10mbit
321c365,366
<            FDDI         100Mbps    12.5MBps    170
---
 >            100mbit
 >            Ethernet     100Mbps    12.5MBps    170
323c368,369
<            Gigabit        1Gbps     125MBps    17
---
 >            Gigabit
 >            Ethernet       1Gbps     125MBps    17
329,332c375,378
<       the other hand, at DS3 and FDDI speeds, Twrap is comparable to  
the
---
 >       the other hand, at DS3 and 100mbit speeds, Twrap is  
comparable to
613a659,669
 >       When a non-zero scale factor is in use, there are instances  
when a
 >       retracted window can be offered [Mathis08].  The end of the  
window
 >       will be on a boundary based on the granularity of the scale  
factor
 >       being used.  If the sequence number is then updated by a  
number of
 >       bytes smaller than that granularity, the TCP will have to  
either
 >       advertise a new window that beyond what it previously  
advertised
 >       (and perhaps beyond the buffer), or will have to advertise a
 >       smaller window, which will cause the TCP window to shrink.
 >       Implementations should ensure that they handle a shrinking  
window,
 >       as specified in section 4.2.2.16 of RFC 1122 [Braden89].
 >
724,725c780,785
<          without a TSopt may be ACKed and dropped without further
<          processing.
---
 >          without a TSopt may dropped without further processing,  
and an
 >          ACK of the current SND.UNA generated.
 >
 >          In the case of crossing SYN packets where one SYN contains a
 >          TSopt and the other doesn't, both sides should put a TSopt  
in
 >          the <SYN,ACK> segment.
747,748c807
<       received in a TSval field; these echoed values. labelled
<       "TS.Recent", are shown in parentheses.
---
 >       received in a TSval field.
755,780c813
<
<          TCP  A                                            TCP B
<
<        (TS.Recent)                                        (TS.Recent)
<
<       1.  (120)             <A,TSval=1,TSecr=120> --->       (1)
<
<       2.  (125)  <--- <ACK(A),TSval=125,TSecr=1>             (1)
<
<       3.  (125)             <B,TSval=6,TSecr=125> --->       (6)
<
<       4.  (130)  <--- <ACK(B),TSval=130,TSecr=6>             (6)
<
<              . . . ( Pause for 60 timestamp clock ticks ) . . . .
<
<
<       5.  (130)             <C,TSval=1,TSecr=120> --->       (1)
<
<       6.  (125)  <--- <ACK(A),TSval=125,TSecr=1>             (1)
<
<       4.  (127)  <b,ACK(x),TSval=65,TSecr=127> --->  ...
<
<       5.            ... <--- <y,ACK(A),TSval=191,TSecr=5>    (5)
<
830c855,863
<       into account the more frequent RTTMs.  For example,
---
 >       into account the more frequent RTTMs.  For example, an
 >       implementation could choose to just use one sample per RTT to
 >       update the RTO estimator, or or vary the gain based on the
 >       congestion window, or take an average of all the RTTM  
measurements
 >       received over one RTT, and then use that value to update the  
RTO
 >       estimator.  This document does not prescribe any particular  
method
 >       for modifying the RTO estimator, the important point is that  
the
 >       implementation should do something more than just feeding
 >       additional RTTM samples from one RTT into the RTO estimator.
977c1016
< 4.  PAWS: PROTECT AGAINST WRAPPED SEQUENCE NUMBERS
---
 > 4.  PAWS: PROTECTION AGAINST WRAPPED SEQUENCE NUMBERS
991,993c1022,1024
<       mechanism PAWS (Protect Against Wrapped Sequence numbers).  PAWS
---
 >       mechanism PAWS (Protection Against Wrapped Sequence numbers).
1002,1004c1033,1035
<       whose values are monotone non-decreasing in time.  The basic  
idea
---
 >       whose values are monotonically non-decreasing in time.  The  
basic
1015,1024c1054,1064
<       must guarantee a value that is monotone increasing.  For  
example,
---
 >       must guarantee a value that is monotonically increasing.  For
1031c1071
<       (An alternative un-symmetric algorithm would protect against old
---
 >       (An alternative non-symmetric algorithm would protect against  
old
1053,1054c1085,1086
<       RFC-1323 recommended that RST segments NOT carry timestamps, and
<       that they be accetable regardless of their timestamp.  At that
---
 >       RFC 1323 recommended that RST segments NOT carry timestamps,  
and
 >       that they be acceptable regardless of their timestamp.  At that
1070,1072c1110,1112
<       and information from Timestamps option must not be use to update
---
 >       and information from the Timestamps option must not be use to
1187c1230
<          the receiver treats the timestamp as simply a monotone-
---
 >          the receiver treats the timestamp as simply a monotonically
1201,1202c1244,1245
<               worth of data, and even with the RFC-1072 window
<               extension, 2**31 bytes must be at least two windows.
---
 >               worth of data, and even with the window extension  
defined
 >               in Section 2.2, 2**31 bytes must be at least two  
windows.
1350,1355c1384,1397
<          in step H1 is very unlikely to fail, and it requires interval
<          arithmetic on a finite field, a relatively expensive  
operation.
<          To perform this check on every single segment is contrary to
<          the philosophy of header prediction.  We believe that this
<          change might reduce CPU time for TCP protocol processing by  
up
<          to 5-10% on high-speed networks.
---
 >          in step H1 is very unlikely to fail, and it requires  
unsigned
 >          modulo arithmetic, a relatively expensive operation.  To
 >          perform this check on every single segment is contrary to  
the
 >          philosophy of header prediction.  We believe that this  
change
 >          might produce a measurable reduction in CPU time for TCP
 >          protocol processing on high-speed networks.
1403,1406c1438,1441
<          bit in the IP header.  Setting the DF bit implies that Path  
MTU
<          Discovery as described in RFC-1191 [Mogul90].  Thus any TCP
<          implementation that implements PAWS must also implement Path
<          MTU Discovery.
---
 >          bit in the IP header.  Setting the DF bit implies the use of
 >          Path MTU Discovery as described in RFC 1191 [Mogul90],  
thus any
 >          TCP implementation that implements PAWS must also implement
 >          Path MTU Discovery.
1466,1468c1501,1511
<    publication of RFC-1323 originally occurred in the IETF TCP Large
<    Windows Working Group, later on in the End-to-End Taks Force, and
<    most recently in the IETF TCP Maintance Working Group.  The authors
---
 >    publication of RFC 1323 originally occurred in the IETF TCP Large
 >    Windows Working Group, later on in the End-to-End Task Force, and
 >    most recently in the IETF TCP Maintenance Working Group.  The  
authors
1473c1516,1541
<    Security issues are not discussed in this memo.
---
 >    The TCP sequence space is a fixed size, and as the window becomes
 >    larger it becomes easier for an attacker to generate forged  
packets
 >    that can fall within the TCP window, and be accepted as valid
 >    packets.  While use of Timestamps and PAWS can help to mitigate  
this,
 >    when using PAWS, if an attacker is able to forge a packet that is
 >    acceptable to the TCP connection, a timestamp that is in the  
future
 >    would cause valid packets to be dropped due to PAWS checks.   
Hence,
 >    implementors should take care to not open the TCP window  
drastically
 >    beyond the requirements of the connection.
 >
 >    Middle boxes and options If a middle box removes TCP options  
from the
 >    SYN, such as TSopt, a high speed connection that needs PAWS  
would not
 >    have that protection.  In this situation, an implementor could
 >    provide a mechanism for the application to determine whether or  
not
 >    PAWS is in use on the connection, and chose to terminate the
 >    connection if that protection doesn't exist.
 >
 >    Mechanisms to protect the TCP header from modification should also
 >    protect the TCP options.
 >
 >    Expanding the TCP window beyond 64K for IPv6 allows Jumbograms
 >    [Borman99] to be used when the local network supports packets  
larger
 >    than 64K.  When larger TCP packets are used, the TCP checksum  
becomes
 >    weaker.
 >
 > 7.  IANA CONSIDERATIONS
 >
 >    This document has no actions for IANA.
1568a1642,1644
 >       [Mathis08] Mathis, M., "[tcpm] Example of 1323 window  
retraction
 >       problemPer my comments at the microphone at TCPM...", Message  
to
 >       the tcpm mailing list, March 2008.
1574,1577c1650
<       [Postel83]  Postel, J., "The TCP Maximum Segment Size and  
Related
<       Topics", RFC-879, ISI, November 1983.
1681,1729c1739,1742
<
<    TCP Options and MSS
<
<         There has been some confusion as to what value should be  
filled
<         in the TCP MSS option when using TCP options.  RFC-879
<         [Postel83] stated:
<
<              The MSS counts only data octets in the segment, it does  
not
<              count the TCP header or the IP header.
<
<         which is unclear about what to do about TCP options.  RFC-1122
<         [Braden89] attempted to clarify this in section 4.2.2.6, but
<         there still seems to be confusion.
<
<         So, the MSS value to be sent in an MSS option should be  
equal to
<         the effective MTU minus the fixed IP and TCP headers.  Since
<         both IP and TCP options are ignored when calculating the value
<         for the MSS option, if there are any IP or TCP options to be
<         sent in a packet, then the sender must decrease the size of  
the
<         TCP data accordingly.  The reason for this can be seen in the
<         following table:
<
<                          +--------------------+--------------------+
<                          | MSS is adjusted    | MSS isn't adjusted |
<                          | to include options | to include options |
<         +----------------+--------------------+--------------------+
<         | Sender adjusts | Packets are too    | Packets are the    |
<         | length for     | short              | correct length     |
<         | options        |                    |                    |
<         +----------------+--------------------+--------------------+
<         | Sender doesn't | Packets are the    | Packets are too    |
<         | adjust length  | correct length     | long.              |
<         | for options    |                    |                    |
<         +----------------+--------------------+--------------------+
<
<         Since the goal is to not send IP datagrams that have to be
<         fragmented, and packets sent with the constraints in the lower
<         right of this grid will cause IP fragmentation, the only way  
to
<         guarantee that this doesn't happen is for the data sender to
<         decrease the TCP data length by the size of the IP and TCP
<         options.  And since the sender will be adjusting the TCP data
<         length when sending IP and TCP options, there is no need to
<         include the IP and TCP option lengths in the MSS value.
---
<
1827,1828c1832,1833
<            strictly within a single connection; the last timestamp is
<            TS.Recent is kept in the connection control block, and
---
 >            strictly within a single connection; the last timestamp
 >            (TS.Recent) is kept in the connection control block, and
1922c1980
<         which ever data packet made it to the destination.
---
 >         whichever data packet made it to the destination.
1944c2002
<    (f)  It is now recommended that Timestamps options be included RST
---
 >    (f)  It is now recommended that Timestamps options be included  
in RST
1999c2057
<        my.TSclock:      System Wide Local source of 32-bit timestamp  
values
---
 >        my.TSclock:      System wide source of 32-bit timestamp values
2500c2616
<    While the rules layed out for when to calculate RTTM produce the
---
 >    While the rules laid out for when to calculate RTTM produce the