(commenting on two of the points from this exchange)
On 3/9/14, 6:32 PM, Alia Atlas wrote (in response to Brian Trammell:
...
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
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)
Agreed. I would be very happy if we could even get as far as reliably
being able to use the Ipv6 flow label for this. It would allow us to
finesse a lot of the current disagreement between routing and transport.
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?
It's hard to say anything in general about what "overlay x on y"
solves in detail (I'll consider encapsulation an implementation
detail of overlay for now) for all x and y, other than (1) somebody
thought that it would provide a service that y doesn't on its own
that (2) they locally thought they needed at the time, and (3) they
might actually have been right about (1) and (2).
Ah - I don't think that encapsulation is an implementation detail of
overlay. But I'm willing to be persuaded - I think it is more about
carrying additional information; frequently that is done as an overlay
because it isn't possible to carry it otherwise.
While their are encapsulations whose primary purpose is adding
additional information, most of the cases I can think of (MPLS, LISP,
GRE, Mobile-IP) are cases where the primary purpose of the encapsualtion
is to direct the traffic over a path that it might not otherwise chose
or otherwise be able to traverse.
Yours,
Joel