> > On Apr 28, 2016, at 9:26 AM, [email protected] wrote: > > > > I guarantee someone will show us a middlebox that NEEDS to modify > every > > option we currently have and every option we will ever create. > > I'd put it the other way around. The fact that middleware *can* get to > something lets someone find a use for doing so. That's not an argument > for it, it's an observation of fact. > > Frankly, the only option I'm aware of people actively modifying is the > MSS. In a world in which ICMP is filtered and RFC 4821 isn't widely > implemented, having a VPN Tunnel Endpoint or other middleware reduce > the MSS to some value is a PMTU solution that mostly works. My > preference would be RFC 4821 or something like it. But that's not where > we are.
In TCPM there have been reports about sequence-number randomizing firewalls: https://www.ietf.org/proceedings/87/slides/slides-87-tcpm-11.pdf >From slide 2: 'Firewalls "fixed" it by randomizing TCP sequence numbers - But >some of them forgot SACK' Encryption the SACK option would result in the same issues like this entirely broken firewall. Yet, this shows that there may be cases in which *not* modifying the SACK option creates problems. (I'll obviously not argue in favor of this sort of firewall, as a modern high-end TCP stack should have sufficient sequence number randomization.) Michael _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
