Subject: [multipathtcp] Implementation of content-changing middleboxes

From: "Ford, Alan" <[email-masked]>
Date: Tue, 3 Aug 2010 10:22:38 +0100

Hi all,

Does anybody have first-hand experience of what content-altering
middleboxes actually do to packets on the wire?

This question comes from a conversation I had with Iljitsch at the end
of the IETF... If the behaviour of such boxes is predictable, we may be
able to make use of that. I mean, we have a tendency to always think of
the worst case, i.e. data is changed in the TCP stream and the whole
stream from then on is different to what was sent (in terms of sequence
numbering, packet boundaries, etc).

But, as Iljitsch said, if you were implementing such a box, the easiest
way would be:
* If a packet get shorter, just shorten it.
* If a packet gets longer, send two packets, but don't try to coalesce
with following packets.
* Just keep track of a sequence number offset to change the sequence
number on every following packet.

In which case, we would still maintain packet boundaries, which could be
useful to us (maybe to help with the extended sequence space, too).

How such boxes would handle detection and re-writing over packet
boundaries, however, is less clear.

So, can anybody confirm this kind of behaviour, with packet captures?

Cheers,
Alan

---

From: Scott W Brim <[email-masked]>
Date: Tue, 3 Aug 2010 12:56:59 -0400

Alan, I couldn't really understand what you have in mind. Are you going to
write this up in more detail?

Scott

On Aug 3, 2010 5:22 AM, "Ford, Alan" <[email-masked]> wrote:

Hi all,

Cheers,
Alan

_______________________________________________
multipathtcp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 3 Aug 2010 20:31:08 +0100

HI Scott,
 
I believe the question is around some of the more elaborate middleboxes,
doing http / html parsing in-stream, ie to do AD-redirection. Some of
those will probably terminate TCP sessions anyway (even though the tcp
session will appear to the public internet to still originate from the
original user), but some may be so kind and still pass on additional
options (which would signal MPTCP stuff).
 
Also, content filtering firewalls may be interesting, if they
remove/replace certain content from a within a stream.
 
Therefore I think I brought up the idea of allowing such middleboxes to
become MP-aware, and do some signalling of their own to allow successful
MPTCP flows and subflows to be established.
 
However, I don't know how prevalent those boxes are, and how they react
to (currently) unknown options. As mentioned above, the boxes I once
dealt with could be viewed from an L4 perspective as end-points, thus
they would run two independent tcp sessions, even though much of the
original session would be preserved (IP header, flags, options; sequence
numbers, congestion control and sometimes frames not so).
 
However, I don't think I still have a tcpdump of those.
 
Regards,
   Richard

________________________________

	From: Scott W Brim [mailto:[email-masked]] 
	Sent: Dienstag, 3. August 2010 18:57
	To: Ford, Alan
	Cc: multipathtcp List
	Subject: Re: [multipathtcp] Implementation of content-changing
middleboxes

	Alan, I couldn't really understand what you have in mind. Are
you going to write this up in more detail?

	Scott

		On Aug 3, 2010 5:22 AM, "Ford, Alan"
<[email-masked]> wrote:
		
		Hi all,
		
		Does anybody have first-hand experience of what
content-altering
		middleboxes actually do to packets on the wire?
		
		This question comes from a conversation I had with
Iljitsch at the end
		of the IETF... If the behaviour of such boxes is
predictable, we may be
		able to make use of that. I mean, we have a tendency to
always think of
		the worst case, i.e. data is changed in the TCP stream
and the whole
		stream from then on is different to what was sent (in
terms of sequence
		numbering, packet boundaries, etc).
		
		But, as Iljitsch said, if you were implementing such a
box, the easiest
		way would be:
		* If a packet get shorter, just shorten it.
		* If a packet gets longer, send two packets, but don't
try to coalesce
		with following packets.
		* Just keep track of a sequence number offset to change
the sequence
		number on every following packet.
		
		In which case, we would still maintain packet
boundaries, which could be
		useful to us (maybe to help with the extended sequence
space, too).
		
		How such boxes would handle detection and re-writing
over packet
		boundaries, however, is less clear.
		
		So, can anybody confirm this kind of behaviour, with
packet captures?
		
		Cheers,
		Alan

---

From: "Ford, Alan" <[email-masked]>
Date: Wed, 4 Aug 2010 10:17:17 +0100

Hi Richard, Scott,

There are indeed a number of middleboxes that do alterations to content,
in a number of different ways. Those that terminate a TCP session and
create a new one to the client, such as web proxies, will not support
MPTCP end-to-end, but may support MPTCP on both sides of the middlebox.

The ones we are particularly concerned about, and that I refer to in my
mail, are those content-filtering firewalls that remove/replace content
within a TCP stream. These will alter the size and thus sequence
numbering of the data, and are the prime motivation for the
checksum/fallback mechanisms discussed in the latest version of the
draft.

We have been designing mechanisms to cope with the worst case stream
adjustment, however I think it would be useful to understand (both for
this, and for the long options discussion), how such boxes actually
work. If anybody has access to such a box, or are a vendor of such
boxes, it would be very interesting to understand this behaviour,
ideally with packet captures.

To re-iterate, the simple implementation may be:

*         Pattern-matching detects data that should be replace (e.g.
malicious code, replace with "HelpfulMiddlebox1.0 has removed dodgy code
for you")

*         If the packet has become shorter, just re-send the shortened
packet, and the next packet remains the same as the sender sent it

*         If the packet has become longer, send two packets, but the
following packet remains the same as when the sender sent it

*         The only state needed per-connection is therefore a sequence
number offset for the adjusted stream

So packet boundaries are retained. Although, how such an implementation
would work with detecting patterns across a packet boundary is less
clear, and cases such as those are even more interesting - how much data
would be reassembled and resegmented before packet boundaries are
aligned again?

Regards,

Alan

From: Scheffenegger, Richard [mailto:[email-masked]] 
Sent: 03 August 2010 20:31
To: Scott W Brim; Ford, Alan
Cc: multipathtcp List
Subject: RE: [multipathtcp] Implementation of content-changing
middleboxes

HI Scott,

Regards,

   Richard

	Scott

		Hi all,

		

		
		
		Cheers,
		Alan