On Sun, May 28, 2023 at 10:13 AM Andrew Campling <[email protected]> wrote: > > On Sat, May 27, 2023 at 11:05 PM Tom Herbert <[email protected]> wrote: > > > Application developers and stack developers are also players in this > > game. And while each network provider might have the luxury of only > > focusing on their customer set, developers have to potentially > > address the needs of all users across the Internet. This is why > > network providers' attempts to protect the user are irrelevant to > > application developers-- without consistency across the Internet > > this level of security may as well not exist from their perspective. > > Obviously this situation didn't materialize overnight and it shouldn't > > be surprising that we've had to implement work-arounds to this > > problem. For instance, encryption goes a long way in limiting the > > network's visibility in the packet, but that does have its limits. > > Tom > > Let's not forget that some of those same developers are responsible for > implementing surveillance capitalism, one of the most egregious invasions of > user privacy and surely contrary to RFC 7258 - I know that people generally > seem to focus on network-based monitoring, however application-based > monitoring is potentially far more invasive. Some of the application-based > "work-arounds" to network security measures you reference could be helpful in > allowing those applications to exfiltrate user data; if applications behave > increasingly like malware then it should not come as a surprise if they are > treated as such by networks in an effort to protect users.
Andrew, That's a very general statement. Can you give a specific example? Maybe one possibility is STT (draft-davie-stt) which was designed to repurpose TCP protocol number 6 as a tunneling protocol to circumvent some networks that filter UDP. But that proposal was rejected by IETF and never accepted into Linux. But even if a network assumes responsibility to protect the user from malware, its ability to offer any reasonable protection to users is extremely limited and becoming more limited. Network devices don't have the E2E visibility or context to properly filter application malware-- this is both true architecturally and in practice given the prevalence of TLS deployment. > > As noted elsewhere, I believe that it would be beneficial to the IETF > community if greater efforts were made to engage with enterprise and public > network CISOs, as well as more network operators. This would help inject > more understanding of current operational security practices and > considerations into protocol development activity, which might help to avoid > puzzlement when new developments are unleashed, only to find them blocked or > only greeted with luke-warm enthusiasm by those that have operational > responsibility for security, customer service etc. "those that have operational responsibility for security, customer service etc." is not limited to network operators, application developers, server operators, and OS providers also assume that operational responsibility-- so if there is a conversation it should include all the players. Also, I'm not sure that "understanding of current operational security practices" would be of use here. As far as I can tell, there are no uniform security practices amongst network providers on the Internet. For instance, with respect to extension headers, some providers allow all of them, some allow none, and some seem to allow a subset. Besides that there's already RFC9098 that highlights some reasons why packets with extension headers might be discarded, but doesn't quantify the practices (exactly who is dropping packets and why). Tom Tom > > Andrew > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
