Re: Overlays and encapsulations (was Re: Engineering discussions )

Subject: Re: Overlays and encapsulations (was Re: Engineering discussions ) 
Date: Sun, Mar 09, 2014 at 06:32:29PM -0400 Quoting Alia Atlas 
(akatlas(_at_)gmail(_dot_)com):
 
> So - to your point about middleboxes (minus the unkind things), would it be
> fair to say:
>    a) middleboxes serve to restrict what kind of traffic is perceived to
> flow freely to TCP/UDP?
>    b) middleboxes impact security by acting as an unknown MITM
For 'a' I'd argue that the bar is at "can it be squeezed into
HTTP/1.1?" -- UDP is not to be trusted.

Having said that, yes, both a and b are true. 
 
> we also need to add:
>    In most modern networks, it is important to have microflow diversity.
>  When IPv6 and flow-labels aren't an option, this frequently defaults to
> UDP or TCP 5-tuples (src/dest IP, protocol, src/dest port)
>
> For instance, how many issues would be solved if there were a well-known
> meta-data header that an application could use to describe itself to the
> network and middle boxes?
None. Yeah, I'm naïve. More to the point is that we should not tamper with the 
success factors in IP. Not knowing what the packets are doing is good in a 
big picture sense. Not all in-transit optimisations are beneficial to
your packets, especially if throwing them on the to-do pile would free
up resources for routing better paying packets.

The nature of coöperating (albeit barely) networks sooner or later leads
to your packets traversing a network with which you have no relations.


-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
While my BRAINPAN is being refused service in BURGER KING, Jesuit
priests are DATING CAREER DIPLOMATS!!

signature.asc
Description: Digital signature