Subject: [tcpm] 1323bis Security section - Middleboxes

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 18 Apr 2013 09:59:52 +0000

I have re-ordered the (new) text passage in section 6, including Olivier's comments.

Also, I changed the text around removal of options slightly, to properly apply to the options discussed in 1323bis... Including modifications (twigging TSval/Tsecr is fine if done symmetrically, but changing WS is not).

Comments on this updated section?

Regards,
  Richard 

6.  Security Considerations

   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
   segments.  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 segments to be dropped due to PAWS checks.
   Hence, implementers should take care to not open the TCP window
   drastically beyond the requirements of the connection.

   A naive implementation that derives the timestamp clock value
   directly from a system uptime clock may unintentionally leak this
   information to an attacker.  This does not directly compromise any of
   the mechanisms described in this document.  However, this may be
   valuable information to a potential attacker.  An implementer should
   evaluate the potential impact and mitigate this accordingly (i.e. by
   using a random offset for the timestamp clock on each connection, or
   using an external, real-time derived timestamp clock source).

   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.

   Mechanisms to protect the TCP header from modification should also
   protect the TCP options.

   Middleboxes and TCP options:

      A middlebox may remove TCP options described in this document from
      the <SYN> segment, but it must not delete any of these options in
      a <SYN,ACK> segment.

      A middlebox should never remove or modify the Window Scale option
      in the <SYN,ACK> segment.  Otherwise, the endhost will not
      negotiate the window scaling factor correctly.

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

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

      If a middlebox removes TCP options from the <SYN> segment, such
      as the Timestamp option, 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.

---

From: John Leslie <[email-masked]>
Date: Thu, 18 Apr 2013 10:18:52 -0400

Scheffenegger, Richard <[email-masked]> wrote:
>... 

   This whole issue is such a kludge that I fear to tread...

   Though rare, it is possible for TCP SYNs to overlap. If one end's
middlebox removes the Window Scale option and the other doesn't,
there is the opportunity for one side to believe Window Scale is
enabled while the other side doesn't.

   Thus, IMHO, a middlebox should _never_ remove the Window Scale
option: if it can't manage a Window-Scaled connection, it should
refuse to establish one by dropping the SYN rather than by just
dropping the option.

   (I don't think either way of rejecting Window Scale is reasonable:
by now any middlebox that cares in the least about Window Scaling
should have learned how to do it right.)

--
John Leslie <[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Thu, 18 Apr 2013 10:37:04 -0700

Hi, all,

On 4/18/2013 2:59 AM, Scheffenegger, Richard wrote:
...
>        the <SYN> segment, but it must not delete any of these options in

I disagree with any recommendation in any IETF standard that suggests 
that it is *ever* appropriate for a middlebox to add, delete, or modify 
a TCP header in any way.

...
>        Window Scale option from the <SYN> segment.

For the same reason, I disagree with the above. At best, the firewall 
should drop that SYN segment.

>        the connection if that protection doesn't exist.

Options are not "pick and choose" for transits; they are "all or none". 
They need to stay out of the way of the endpoints.

Joe

---

From: Yuchung Cheng <[email-masked]>
Date: Thu, 18 Apr 2013 13:29:49 -0700

On Thu, Apr 18, 2013 at 10:37 AM, Joe Touch <[email-masked]> wrote:
> I disagree with any recommendation in any IETF standard that suggests that
> it is *ever* appropriate for a middlebox to add, delete, or modify a TCP
> header in any way.
I can not agree more what Joe said. Let's not advice or accommodate
these mis-behaviors.

> For the same reason, I disagree with the above. At best, the firewall should
> drop that SYN segment.
>
>
> Options are not "pick and choose" for transits; they are "all or none". They
> need to stay out of the way of the endpoints.
>
> Joe
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: [email-masked]
Date: Fri, 19 Apr 2013 07:55:56 +0100

+1

Gorry Fairhurst

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 19 Apr 2013 09:26:34 +0200

Joe,
> that it is *ever* appropriate for a middlebox to add, delete, or modify

We have two options.

We remain strong believer of the end-to-end model and apply the ostrich 
principle and consider that middleboxes should not exist and thus we 
never mention middleboxes anywhere.

We understand that the Internet has evolved and whether we like it or 
not, there are middleboxes. Since these boxes are likely to stay, we 
document the problems that they may cause and try to ensure that 
middlebox implementers do not mess more with TCP and its evolvability in 
the future.

I think that the IETF should be pragmatic.

> For the same reason, I disagree with the above. At best, the firewall should drop that SYN segment.

In this case, I'd prefer to have on a path a firewall that removes a TCP 
option than a firewall that drops SYN with a given option. We already 
suffer too much from devices that drop packets that contain "unknown" 
protocols for the deployment of SCTP for example to suggest to do this 
for TCP options.

Olivier

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

---

From: Costin Raiciu <[email-masked]>
Date: Fri, 19 Apr 2013 11:24:00 +0300

I like the end-to-end principle as much as the next guy. It's nice and clean and it allows endpoints to easily reason about what happens to their packets in the network, fostering inovation.

However, I share Olivier's view with regards to middleboxes: they are here to stay because they are needed. Scorn from the IETF will not make them go away.

Middleboxes are living proof that:
- the end-to-end Internet architecture is inadequate for most of its users (think operators, corporations) that MUST ensure some level of security and (to a lesser extent) performance optimization
- quick, easy to deploy, local patches (i.e. middleboxes) are preferred by operators to undeployable principled solutions.

Instead of trying to leave middleboxes out of the Internet architecture as we have done so far, we need to make them an explicit part of the architecture. At the very least, at the IETF we should understand how existing and new TCP extensions interact will middleboxes, and try to steer these middleboxes to do the "right" thing. The design of MPTCP took 5 long years because of middleboxes, and our efforts to understand what they do in practice, and to work with them rather than against them. 

I imagine any non-trivial change to TCP faces the same hurdles.

Cheers,
Costin

On 19 Apr 2013, at 10:26, Olivier Bonaventure wrote:

> We remain strong believer of the end-to-end model and apply the ostrich principle and consider that middleboxes should not exist and thus we never mention middleboxes anywhere.
> 
> We understand that the Internet has evolved and whether we like it or not, there are middleboxes. Since these boxes are likely to stay, we document the problems that they may cause and try to ensure that middlebox implementers do not mess more with TCP and its evolvability in the future.
> 
> 
> In this case, I'd prefer to have on a path a firewall that removes a TCP option than a firewall that drops SYN with a given option. We already suffer too much from devices that drop packets that contain "unknown" protocols for the deployment of SCTP for example to suggest to do this for TCP options.
> 
> 
> Olivier
> 
> 
> 
> --

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 19 Apr 2013 11:26:46 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Joe Touch
> Sent: Thursday, April 18, 2013 7:37 PM
> To: Scheffenegger, Richard
> Cc: tcpm ([email-masked])
> Subject: Re: [tcpm] 1323bis Security section - Middleboxes
> 
> Hi, all,
> 
> I disagree with any recommendation in any IETF standard that 
> suggests that it is *ever* appropriate for a middlebox to 
> add, delete, or modify a TCP header in any way.

I personally find it very useful to document what will go wrong if middleboxes remove those options.

But the phrasing "A middlebox may remove..." is certainly problematic. IMHO, we should clearly state that middleboxes MUST NOT remove RFC 1313 options, and we should specifically document the issues of removing options in <SYN,ACK> to explain why.

Unfortunately, it is likely that some middleboxes will violate that MUST NOT, but then we have at least documented the issues with the <SYN,ACK>. [Apparently, RFC 6919 has a bug since "REALLY REALLY MUST NOT" is missing).

Michael (random IETF contributor)

---

From: Pasi Sarolahti <[email-masked]>
Date: Fri, 19 Apr 2013 17:28:43 +0300

>      the <SYN> segment, but it must not delete any of these options in

Like others, I don't like the "may remove..." part of this text, but I think it would be good to shortly describe the known problems with middleboxes related to window scaling. I'm not sure if Security Considerations is the right section for this text, though.

The page Olivier mentioned (http://kb.pert.geant.net/PERTKB/WindowScalingProblems) describes also another problem: some firewalls do in-window checks and drop out-of-window packets, but ignore the window scale option. This does not break the connection, but damages performance. The nasty thing is that there are no obvious ways to detect this problem.

- Pasi

---

From: Pasi Sarolahti <[email-masked]>
Date: Fri, 19 Apr 2013 17:37:16 +0300

> But the phrasing "A middlebox may remove..." is certainly problematic. IMHO, we should clearly state that middleboxes MUST NOT remove RFC 1313 options, and we should specifically document the issue…

Isn't there any dedicated RFC on middlebox requirements for TCP saying that middleboxes MUST NOT touch any TCP option? My feeling is that we shouldn't give normative middlebox requirements in this document. The midbox developers are unlikely to find them here in any case.

But as said, it doesn't hurt to describe the known problems.

- Pasi

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 19 Apr 2013 16:45:25 +0200

Pasi,
> The page Olivier mentioned (http://kb.pert.geant.net/PERTKB/WindowScalingProblems) describes also another problem: some firewalls do in-window checks and drop out-of-window packets, but ignore the…

There is a long list of problems related to TCP extensions that are not 
well supported by middleboxes.

Another example is SACK. One would expect SACK to always work if 
negotiated by the endhosts. Unfortunately, some firewalls break this by 
randomizing the TCP sequence numbers.

See e.g. (extract from https://supportforums.cisco.com/docs/DOC-12668 )

Even when TCP SACK is permitted through the FWSM, there is a problem 
introduced by TCP Sequence Number Randomization feature that is enabled 
by default.  The feature hides the sequence numbers generated by the 
endpoints behind the higher security interface by shifting them by a 
certain value (determined in a random fashion for each TCP connection). 
However, the feature does not rewrite the right and left edge values 
embedded into TCP SACK option. As a result, a TCP ACK requesting 
selective retransmission that traverses from a lower- to higher-security 
interface makes no sense to the inside endpoint (since the TCP sequence 
numbers embedded into the SACK option represent the “randomized” values 
known only on the outside of the FWSM).

This post dates from 2010. SACK only appeared in 1996. I guess that we 
can easily find stories like this one from many middlebox vendors.

Olivier

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 19 Apr 2013 16:49:22 +0200

Pasi,

> Isn't there any dedicated RFC on middlebox requirements for TCP saying that middleboxes MUST NOT touch any TCP option?

I'm afraid that most vendors have deployed boxes that allow to do that 
based on requests from customers. Consider e.g.

http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/conns_tcpnorm.html

> My feeling is that we shouldn't give normative middlebox requirements in this document. The midbox developers are unlikely to find them here in any case.

It might be worth having a "middlebox" section in each TCP specification 
to discuss the possible interactions between a TCP extension and 
middleboxes.

If the WG believes that such a document could be useful, we could 
contribute based on the lessons learned from Multipath TCP.

Olivier

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 19 Apr 2013 16:49:43 +0200

> > But the phrasing "A middlebox may remove..." is certainly 
> problematic. IMHO, we should clearly state that middleboxes 
> MUST NOT remove RFC 1313 options, and we should specifically 
> document the issues of removing options in <SYN,ACK> to explain why.
> 
> Isn't there any dedicated RFC on middlebox requirements for 
> TCP saying that middleboxes MUST NOT touch any TCP option? My 
> feeling is that we shouldn't give normative middlebox 
> requirements in this document. The midbox developers are 
> unlikely to find them here in any case.

Yes, I agree that normative statements on middleboxes are probably not in-scope of TCPM. My e-mail was probably written a bit too fast...
 
> But as said, it doesn't hurt to describe the known problems.

That is my main point as well.

Michael

---

From: David Borman <[email-masked]>
Date: Fri, 19 Apr 2013 09:54:08 -0500

On Apr 18, 2013, at 4:59 AM, "Scheffenegger, Richard" <[email-masked]> wrote:

...
>    the connection if that protection doesn't exist.

This whole section needs to be reworked, many valid points have been
brought up.  I agree with Joe, middleboxes shouldn't be removing TCP
options.  We should discourage that, pointing out examples of how
things can go wrong.

Here's my proposal for rewriting the middlebox section:

Middle boxes and TCP options:

  Some middle boxes have been known to remove the TCP options
  described in this document from the <SYN> segment.  Middle boxes
  should not remove TCP options from <SYN> segments, and must
  not remove TCP options from <SYN,ACK> segments.  Examples of
  issues that can arise when middle boxes remove these TCP options
  include:

  o  If a Window Scale option is removed from a <SYN,ACK> segment,
     the end hosts will not negotiate the window scaling factor correctly.
     Middle boxes must not remove the Window Scale option from
     <SYN,ACK> segments.

  o  If a stateful firewall uses the window field to detect whether
     a received segment is inside the current window, and does not
     support the Window Scale option, it will not be able to correctly
     determine whether or not a packet is in the window.  These
     middle boxes must also support the Window Scale option and apply
     that scaling when processing segments.  If the window scale cannot
     be determined, it must not do window based processing.

  o  If the Timestamp option is removed from the <SYN> segment, high
     speed connections that need PAWS would not have that protection.
     Middle boxes should not remove the Timestamp option.

  Implementations that depend on PAWS could provide a mechanism for
  the application to determine whether or not PAWS is in use on
  the connection, and choose to terminate the connection if that
  protection doesn't exist.  This is not just to protect the connection
  against middle boxes that might remove the Timestamp option, but
  also against remote hosts that do not have Timestamp support.

Rewriting it this way puts up front that middle boxes should not
be mucking with TCP options, and support for this position is
provided by the examples that point out ways that things can break
when middle boxes do muck with TCP options.

			-David Borman

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 19 Apr 2013 17:07:02 +0200

> TCP saying that middleboxes MUST NOT touch any TCP option?

So far, I haven't found that RFC, at least RFC 3234 and RFC 5382 doesn't address TCP options.

> I'm afraid that most vendors have deployed boxes that allow 
> to do that based on requests from customers. Consider e.g.
> 
> > My feeling is that we shouldn't give normative middlebox 
> It might be worth having a "middlebox" section in each TCP 
> specification to discuss the possible interactions between a 
> TCP extension and middleboxes.

I don't think that every TCP specification has to discuss middleboxes. For instance, some TCPM documents don't affect the header at all, and thus give middleboxes few opportunities to mess up stuff... 

> If the WG believes that such a document could be useful, we 
> could contribute based on the lessons learned from Multipath TCP.

The core question would be whether TCPM is actually the right place for that, given that TCPM focuses on the endpoints. But a document that describes the currently known issues and its impact on endpoints could be interesting. A lot of that would be independent of MPTCP.

Michael (chair hat off)

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Apr 2013 08:19:26 -0700

> Yes, I agree that normative statements on middleboxes are probably not in-scope of TCPM. My e-mail was probably written a bit too fast...

I disagree; normative statements about TCP are precisely our scope.

I agree that a general statement about middlebox behavior is out of 
scope for this doc, but I felt the current proposal - which focused on 
these options - was reasonable and appropriate, and definitely in scope 
both for this WG and this doc.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Apr 2013 08:25:55 -0700

This text is fine too, but IMO the only "NOT"s have to be "MUST NOT".

SHOULD NOT should only ever be used when there is a known specific 
reason for an exception, and when that exception is given. Using that 
term in this context is saying it's OK for middleboxes to remove 
options, and I don't think this WG should EVER say that.

So...

On 4/19/2013 7:54 AM, David Borman wrote:
...
>    should not remove TCP options from <SYN> segments, and must
MUST NOT... and MUST NOT

> Rewriting it this way puts up front that middle boxes should not

must not, IMO.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 19 Apr 2013 18:45:54 +0200

> MUST NOT... and MUST NOT

Yeah, we really need a 6919bis with "MUST NOT (BUT WE KNOW YOU WILL)".
On the other hand, for now a "REALLY SHOULD NOT" is probably close enough.

Grüße, Carsten

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Apr 2013 09:49:52 -0700

> On the other hand, for now a "REALLY SHOULD NOT" is probably close enough.

Are you arguing for SHOULD NOT or MUST NOT in that case?

IMO, MUST NOT already accounts for those who don't. Things break or do 
things that are not intended, and we don't understand the ways in which 
it might be safe to do otherwise.

Short of a longer discussion on all the combination of alternatives, IMO 
we should stay with the "party line" of MUST NOT on these.

Joe

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 19 Apr 2013 19:01:44 +0200

> Are you arguing for SHOULD NOT or MUST NOT in that case?

No, I'm arguing for not using any RFC 2119 language in the security considerations.
The security considerations should document what the security considerations of a protocol are.
If there are RFC 2119 level requirements, they should be in the definition of the protocol.

Grüße, Carsten

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Apr 2013 10:40:57 -0700

> If there are RFC 2119 level requirements, they should be in the definition of the protocol.

Oh - I'm not sure I agree. 2119-words seem appropriate in security 
considerations when they are specific to security.

That's not the case for this doc; this isn't a "security" issue. IMO, 
that language is important, but I agree it's probably better placed 
elsewhere in this doc.

Joe

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 19 Apr 2013 18:23:21 +0000

How about moving the relevant sections of text forward to the normative text about window scale / timestamps, as an additional section (e.g. "2.5. Middlebox considerations for the Window Scale Option"; "3.5 Middlebox considerations for the Timestamp Option")

Would that work to have normative text with MUST NOTs?

Regards,

Richard Scheffenegger

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Joe Touch
> Sent: Freitag, 19. April 2013 19:41
> To: Carsten Bormann
> Cc: David Borman; tcpm ([email-masked])
> That's not the case for this doc; this isn't a "security" issue. IMO, that
> language is important, but I agree it's probably better placed elsewhere
> in this doc.
> 
> Joe

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 19 Apr 2013 20:56:14 +0200

Actually, I think there is simply some confusion about the meaning of some existing text.

The current text in draft-ietf-tcpm-1323bis-10.txt is descriptive.
It is like "In a storm, a roof tile may fall on your head.  In this case, call a doctor."

Changing it into "In a storm, a roof tile MUST NOT fall on your head.  In this case, call a doctor." doesn't accomplish much.

But then "In a storm, a roof tile may fall on your head.  In this case, call a doctor." could be read as
"In a storm, a roof tile MAY fall on your head.  In this case, call a doctor." which certainly is not the intention.

So maybe sticking with the descriptive text, leaving it in the security considerations (because it is about the damage that is done in the name of security, hmm), but adding
"TCP works best if people won't drop roof tiles on your head" may be the right thing.

Grüße, Carsten

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Apr 2013 13:14:45 -0700

> "TCP works best if people won't drop roof tiles on your head" may be the right thing.

Omitting the requirement seems fine - there's nothing about these 
options that specific to midboxes, so it does seem unnecessary to make 
specific recommendations about these options and midboxes *either way*.

Joe