Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-10.txt

From: [email-masked]
Date: Tue, 16 Apr 2013 06:45:25 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF.

	Title           : TCP Extensions for High Performance
	Author(s)       : David Borman
                          Bob Braden
                          Van Jacobson
                          Richard Scheffenegger
	Filename        : draft-ietf-tcpm-1323bis-10.txt
	Pages           : 44
	Date            : 2013-04-16

Abstract:
   This document specifies a set of TCP extensions to improve
   performance over paths with a large bandwidth * delay product and to
   provide reliable operation over very high-speed paths.  It defines
   TCP options for scaled windows and timestamps.  The timestamps are
   used for two distinct mechanisms, RTTM (Round Trip Time Measurement)
   and PAWS (Protection Against Wrapped Sequences).

   This document updates and obsoletes RFC 1323.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-1323bis-10

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 16 Apr 2013 13:54:22 +0000

Hi group,

This is the version that I believe is ready for WGLC. 

Since -09, only a few editorial nits have been raised (thanks Yuchung). 

Unless someone objects, I'd like to ask the WG Chairs to formally perform the last call.

Again, to help reviewers of this document, the main changes have been marked in color here, with the exception of the nits below:

https://docs.google.com/file/d/0B7EMOyVNNe1_aklIZXhMME9ESGc/edit?usp=sharing

Best regards,
   Richard

Using proper SI units:

- used is 2^16 = 65K bytes.
+ used is 2^16 = 64 KiB.

- MUST be limited to 14 (which allows windows of 2^30 = 1 Gbyte). If a		
+ MUST be limited to 14 (which allows windows of 2^30 = 1 GiB). If a	

- Expanding the TCP window beyond 64K for IPv6 allows Jumbograms		
- [RFC2675] to be used when the local network supports packets larger		
- than 64K. When larger TCP segments are used, the TCP checksum becomes		
- weaker.		
+ Expanding the TCP window beyond 64 KiB for IPv6 allows Jumbograms	 
+ [RFC2675] to be used when the local network supports packets larger	
+ than 64 KiB. When larger TCP segments are used, the TCP checksum	
+ becomes weaker.	
	
- sent in a single packet is 65495 bytes (64K - 1 -- size of		
+ sent in a single packet is 65495 bytes (64 KiB - 1 -- size of	

Nits (eg vs ie):
			
-	RTTM Rule: A TSecr value received in a segment MAY be used to		
-	update the averaged RTT measurement only if the segment advances		
-	the left edge of the send window (e.g. SND.UNA is increased).		
				
+     RTTM Rule: A TSecr value received in a segment MAY be used to update		
+                the averaged RTT measurement only if the segment advances	
+                the left edge of the send window, i.e. SND.UNA is	
+                increased.	

Non RFC2119 UPPERCASES removed:

- suppose delivery of some of C.1, ... Z.1 is delayed until AFTER		
+ suppose delivery of some of C.1, ... Z.1 is delayed until *after*	

- perform the header prediction step H2 FIRST, and perform H1 and H3		
+ perform the header prediction step H2 *first*, and perform H1 and H3	

(Note: The uppercase FIRST appears in RFC1323, not in draft 1323bis-09)

---

From: Pasi Sarolahti <[email-masked]>
Date: Tue, 16 Apr 2013 22:31:41 +0300

Thanks, Richard, and everyone for the recent active discussion.

To summarize the chairs' understanding of the current status:

* The issue with RTTM (and its use with SACK) is now resolved in a way that seems acceptable to everyone.

* The current text on timestamp option negotiation and its usage is something that most people can live with. It is understood that there is no uniform agreement in the group about the late timestamp negotiation issue, but the current approach of mandatory early negotiation seems to have the support of the majority who spoke up, in addition to being compatible with RFC 1323 (and the current implementation base).

There was also some discussion of the appropriateness of the whole timestamp mechanism, e.g. for PAWS, and possibly doing this in a new, simpler way. This is all interesting, as are the other discussed enhancements on timestamps, but now that there finally is momentum going on finalizing our (long overdue) charter item on maintenance/clarification update of RFC 1323, we should try to get this document done. This should not prevent further work on advanced mechanisms in this space.

Is the above an appropriate summary of the current status? If so, and there are no other immediate issues, the document seems to be ready for WGLC.

- Pasi, Yoshifumi and Michael

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 17 Apr 2013 13:42:23 +0200

Pasi,

> Is the above an appropriate summary of the current status? If so, and there are no other immediate issues, the document seems to be ready for WGLC.

There is one issue that is not discussed in the draft and could be 
worthwhile documenting (or maybe it needs an entire document that covers 
all TCP extensions). The security section contains the following about 
middleboxes :

    Middle boxes and options: If a middle box removes TCP options from
    the <SYN> segment, such as TSopt, a high speed connection that needs
    PAWS would not have that protection.  In this situation, an
    implementer 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.

There are unfortunately several problems with middleboxes beyond this 
(minor) one that would be worth being discussed concerning the WSCALE 
option.

The WSCALE option modifies the semantics of the window field in the TCP 
header. This modificiation has implications for the endpoints of the 
connection, but also for all middleboxes that process the TCP segments 
on the path.

A middlebox can remove the WSCALE option in the SYN segment but it 
should never remove the WSCALE option in the SYN/ACK segment. Otherwise, 
the endhost will not negotiate correctly the window scaling factor.

A stateful firewall, that uses the window field to detect whether a 
received segment is inside the current window should also support the 
WSCALE option and apply the scaling when processing segments. Otherwise, 
the firewall should remove the WSCALE option from both SYN and SYN/ACK 
segments.

Olivier

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 17 Apr 2013 14:18:47 +0000

Hi Olivier,

> connection, but also for all middleboxes that process the TCP segments on
> the path.
> 
> A middlebox can remove the WSCALE option in the SYN segment but it should
> never remove the WSCALE option in the SYN/ACK segment. Otherwise, the
> endhost will not negotiate correctly the window scaling factor.
>

True, this is an issue for the receiver and middleboxes more close to the receiver than the misbehaving middlebox:

Sndr --------> MB1 --------> MB2 --------> Rcvr   
     <SYN,WS>      <SYN,WS>      <SYN,WS>
 
     <-------- MB3 <--------     <--------
      <S,A>         <S,A,WS>      <S,A,WS>

In such a scenario you are correct, the Receiver and Middlebox MB2 will assume that Window Scale was successfully negotiated between end host, when in fact it was not (due to stripping of WS in MB3).

For the session and integrity, this is not that much of an issue (the Sndr will simply drop segments beyond the unscaled window), and such sessions are likely to suffer bad performance because of that.

Does such a performance issue (self-inflicted, if the misbehaving middlebox is in the same administrative domain as either host) need to be considered a security risk?

There is one risk, coming from non-compliant use of timestamps, though, as demonstrated with early implementations of Cubic. As TSopt is not required to have integrity checks (e.g. cryptographic hash in low order bits), but usually is a 1:1 mapping of a 32 bit clock counter, a receiver can potentially influence a sender in unintended ways (in the case of Cubic, a unfair large share of bandwidth).

However, this RFC does not endorse any receiver side use of the TSval field other than for PAWS, thus that aspect is also not mentioned in 1323bis.

Best regards,

Richard Scheffenegger

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 17 Apr 2013 19:59:18 +0200

Richard,

> In such a scenario you are correct, the Receiver and Middlebox MB2 will assume that Window Scale was successfully negotiated between end host, when in fact it was not (due to stripping of WS in MB3…

A middlebox that removes WS from SYN/ACK is rely annoying because the 
Sender and the Receiver do not agree on the Window Scale. Assume that 
they both use a window scale of 14 bits. The sender will not scale its 
window since it did not receive a WScale option. On the other hand, the 
receiver will consider that a scaling of 14 is used. It will scale its 
window and consider the window to be scaled when receiving segments.

> For the session and integrity, this is not that much of an issue (the Sndr will simply drop segments beyond the unscaled window), and such sessions are likely to suffer bad performance because of t…

The performance will be very weak and it will be difficult to detect the 
problem on the TCP stack (except maybe by sending some kind of probe 
packets).

> Does such a performance issue (self-inflicted, if the misbehaving middlebox is in the same administrative domain as either host) need to be considered a security risk?

This is not as such a security risk, but middleboxes only appear in the 
security section of the draft. It might be worth putting a middlebox 
section in the draft so that middlebox developpers pay attention. 
RFC1323 is pretty old, but a few years ago some firewalls had problems 
dealing with RFC1323 and these are still deployed 
http://kb.pert.geant.net/PERTKB/WindowScalingProblems

Olivier

---

From: Pasi Sarolahti <[email-masked]>
Date: Wed, 17 Apr 2013 22:10:40 +0300

On Apr 17, 2013, at 8:59 PM, Olivier Bonaventure wrote:

> This is not as such a security risk, but middleboxes only appear in the security section of the draft. It might be worth putting a middlebox section in the draft so that middlebox developpers pay attention. RFC1323 is pretty old, but a few years ago some firewalls had problems dealing with RFC1323 and these are still deployed http://kb.pert.geant.net/PERTKB/WindowScalingProblems

Thanks, Olivier, for pointing out this. I agree that the problem seems worthwhile to be documented. There are probably no easy solutions to detect and go around this, but at least it would be good to make the readers aware of the possible problems with middleboxes. I hope this is a rare problem by now, but as you point out, this might be a hiding issue, because it does not break connections.

- Pasi