oops, missed your observation re SACK. Yes, that firewall would get pretty well screwed by an encrypted SACK option.
> On Apr 29, 2016, at 11:29 AM, Scharf, Michael (Nokia - DE) > <[email protected]> wrote: > >>> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
