Hello all, The linked document [1] provides data around the deployment of middleboxes in enterprise networks. Its does not provide a complete picture of the internet at large but for a population of tcp users both inside the enterprise and originating inside the enterprise and terminating outside it may provide some quantitate data to use in the "middle box traversal support" discussion.
Kevin [1] A Survey of Enterprise Middlebox Deployments Justine Sherry and Sylvia Ratnasamy EECS Department University of California, Berkeley http://www.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-24.html On 7/29/14 9:44 AM, "Joe Touch" <[email protected]> wrote: >Hi, all, > >I raised this issue during the meeting, notably that we need to decide >to what extent we will support middlebox participation. > >It's clear we need to support simple NATs. However, there are other >behaviors that are less clearly warranting support, both because they so >extremely violate TCP semantics it would be difficult to do so or >because the middlebox behavior is what we are trying to protect against. > >I.e., there are three categories. Here is my view for what MUST, SHOULD, >MAY, and MUST NOT be supported: > >MUST - simple NAT > AFAICT, we all assume support for client source port > and address translation (simple NAT) > >-------------------------------------------------- > >SHOULD > - option content modification > this might be allowed to support some performance > middleboxes that modify MTU announcements or timestamps, e.g. > > (I didn't list this as a MUST because some connections might > want to protect the TCP options, and that should be allowed > as a per-connection or per-host configuration default) > >--------------------------------------------------- > >MUST NOT > - RST injection > IMO, there is no valid reason for a middlebox to issue a RST > to "help" a connection > > - deleting TCPINC > IMO, we have no obligation to succeed in the presence of > a middlebox that rejects the option, because that should be > interpreted the same as the endpoint doing so > > - segment rewriting > once a middlebox goes so far as to rewrite the contents, IMO > it *is* the endpoint, and would need to act like an endpoint > (i.e., to terminate TCPINC on the client side and initiate it > on the server side) > >------------------- > >- > >_______________________________________________ >Tcpinc mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/tcpinc _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
