Subject: Re: Overlays and encapsulations (was Re: Engineering discussions ) Date: Sun, Mar 09, 2014 at 06:32:29PM -0400 Quoting Alia Atlas (akatlas@xxxxxxxxx): > 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!!
Attachment:
signature.asc
Description: Digital signature