Subject: [Int-area] testing concern about IPv4 ID (Joe and Bob et al)

From: Scott Brim <[email-masked]>
Date: Tue, 29 Mar 2011 17:38:08 +0200

I have a question about reusing the IPv4 ID field.  In theory it all
looks good, but how sure are we that middleboxes are doing the right
thing now?  A particular concern is TCP "accelerators".  I'm most
familiar with them in cellular networks, where they often come with
client and server pairs and proprietary communications between them.
They compete on tricks to enhance TCP behavior while reducing
bandwidth use.  What tests have been done particularly across cellular
networks?  Can arbitrary ID values get across?  How about the reserved
bit flag?  If you don't think we need testing please reassure me.

Scott

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 29 Mar 2011 19:27:03 +0100

Hi Scott,

wouldn't such accelerators in effect implement a full TCP stack (on the tcp end)? I doubt that they "tunnel" TCP encapsulated data (or any arbitraty tcp / ip header bits) from site to site, but terminate the TCP session locally, unpack the data, send it via their proprietary transport protocol over, and then set up a different tcp session (albeit which looks at casual inspection identical, as the 4-tuple would be the same) there...

Depending on the ID-Reuse field use, I think these bits would need to be consumed also locally (for the tcp session terminating with those boxes), so that you'd deal with a legacy tcp stack, in effect.

Regards,

Richard Scheffenegger

> -----Original Message-----
> From: Scott Brim [mailto:[email-masked]]
> Sent: Dienstag, 29. März 2011 17:38
> To: [email-masked]
> Subject: [Int-area] testing concern about IPv4 ID (Joe and Bob et al)
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Joe Touch <[email-masked]>
Date: Tue, 29 Mar 2011 14:46:57 -0700

Hi, Scott,

Currently some cell systems have the small devices set ID=0 for all packets.

Certainly there are systems that claim to support Internet access that 
really run "Internet access behind an application gateway" only.

In all cases, the ID signalling clearly ends where the IP packet is 
consumed, but that's true for all IP header bits.

I.e., all IP signalling dies where there's an ALG unless the ALG 
transits the signal - but nothing's new here in that regard, AFAICT.

I'm not sure what testing you'd do when we don't even have IPv4 
compliance suites.

Joe

---

From: Scott Brim <[email-masked]>
Date: Wed, 30 Mar 2011 13:26:12 +0200

> consumed, but that's true for all IP header bits.

I'm not talking about ALGs, which of course terminate IP.  I'm trying
not to name names, but typically there is a source end box that
massages streams going through it, including compression and buffering
and state machine acceleration.  Packets also pass through a sink
before being handed to the app -- either in the client stack or the
radio access network.  There's plenty of competition here, to increase
throughput and enhance customer experience.  Algorithms are often
proprietary.  I have no idea what parts of the packet header they
might massage, between source and sink, but they don't terminate and
regenerate packets, they just watch closely, change TCP parameters at
least, and may alter parts of the IP header as well.

> I'm not sure what testing you'd do when we don't even have IPv4 compliance
> suites.

Just to see if arbitrary bit settings get through intact, for example
send packets in and echo them back.

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Mar 2011 04:32:25 -0700

Hi, Scott,

On 3/30/2011 4:26 AM, Scott Brim wrote:
> On Tue, Mar 29, 2011 at 23:46, Joe Touch<[email-masked]>  wrote:
>> Hi, Scott,
>>
> and state machine acceleration.

IMO, it's an ALG if it acts on info inside the TCP payload.

> Packets also pass through a sink

All bets are off for such boxes. People using those boxes need to 
monitor whether they break when things change, and complain to their vendor.

> send packets in and echo them back.

That's hard to do here; we'd need to know such boxes exist, and then 
test paths through them.

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 30 Mar 2011 09:24:37 -0400

> I'm not sure what testing you'd do when we don't even have IPv4

Well, this was what I was worrying about in my similar question.  If
we don't have IPv4 compliance suites, and we have a bit that we are
planning to change, what evidence do we have that we're not going to
damage currently-conformant interoperability?

Like I said, the details of the IP header are way outside my
expertise, but it seems to me that changing something of this nature
requires a higher bar than, "We don't know of anything that will
break."  (This is not to say that I'm unsympathetic to the proposal.
I just worry about its implications.)

A

-- 
Andrew Sullivan
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Mar 2011 08:39:15 -0700

Hi, Andrew,

> I just worry about its implications.)

My proposal breaks only

a) things that ignore the DF bit and fragment anyway

b) things that rely on the ID field for non-fragmentation reasons, such 
as duplicate discard - which breaks one variant of an experiment we have 
just been notified of in MANET; we're recommending they use other variants

Note that IDs are already reused for new packets earlier than 2MSL; some 
cellphones use ID=0 for all packets, and many systems send packets 
faster than 2MSL lifetimes would allow for a given protocol and 
connection. I.e., those are already broken.

I hope that clarifies things; this is already in the doc (except for the 
MANET issue, which was just brought to our attention).

Joe