Subject: Bringing back Internet transparency

From: Roland Bless <[email-masked]>
Date: Tue, 30 Jul 2013 14:17:20 +0200

Hi,

my impression from several presentations seen this week at the IETF
as well as at the ISOC Panel on "Improving Internet Experience"
is that we probably need to do something on reducing the number
of _broken_ middleboxes (or their implementations respectively)
- I'm not focusing on NAT boxes here.

We all know that it's actually hard to engineer new innovative
protocols around those broken boxes in the path. I think it's
clear that we will not get rid of them, but if I hear about
boxes that try to do "clever optimization" or "security" by
rewriting TCP sequence numbers (w/o considering them in SACK),
bundling segments and so on, I'm wondering who actually engineered
those boxes; aren't the vendors/engineers participating in the IETF?
Who buys and deploys such boxes, esp. if you consider that todays short-
sighted optimization may prevent usage of a newer transport protocol
that actually may provide a much larger performance improvement than
this middlebox?

It's really sad that we still have many problems due to such
broken implementations that break the Internet transparency
and hinder innovations like SCTP, ECN, various TCP enhancements,
and many others.
What could be IETF efforts to get a better situation for the deployment
of future innovations or do we simply accept that (a few) broken
middleboxes dictate the future level of innovation in the Internet?

Regards,
 Roland

Some prior related work:
https://tools.ietf.org/html/rfc2775 Internet Transparency
https://tools.ietf.org/html/rfc3724 The Rise of the Middle and the
Future of End-to-End: Reflections on the Evolution of the Internet
Architecture
https://tools.ietf.org/html/rfc4924 Reflections on Internet Transparency

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 30 Jul 2013 14:35:02 +0200

I raised the need for this transparency in this writeup: 
http://tools.ietf.org/html/draft-tschofenig-hourglass-00

The document also points to some projects / paper I am aware of that are relevant. There may be more. 

Ciao
Hannes

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Jul 2013 15:35:50 -0700

> - I'm not focusing on NAT boxes here.

Hmm. I don't know what a non-broken middlebox is then ;-)

Joe

---

From: Roland Bless <[email-masked]>
Date: Wed, 31 Jul 2013 16:27:02 +0200

Hi Hannes,

> that are relevant. There may be more.

Thanks for the pointer. However, the tone of the
draft seems to suggest accepting that we now have
to stick to TCP/HTTP(S) only...

Section 5 (Will IPv6 reverse the shift?) is interesting,
but I disagree with the conclusion:

   Another reason is that the IPv6 Internet will certainly be filled
   with firewalls, and if history is any guide for the future, only TCP
   and UDP are likely to work through such firewalls.

That shows exactly the point that we need to work on. I see no reason
why IPv6 firewalls should be constrained to let only UDP/TCP through.
We should rather provide some guidance so that we still leave open
the way for deploying innovations in the network. I clearly see the
need for deploying security solutions like firewalls, IDSs and so on.
But IMHO that doesn't mean to block every future useful development, too.

Regards,
 Roland