On Fri, May 27, 2016 at 8:03 AM, Sowmini Varadhan <sowmini.varad...@oracle.com> wrote: > On (05/27/16 11:53), Hannes Frederic Sowa wrote: >> > Thinking about this some more, the per option white list is a better >> > approach. If we allow an open ended mechanism for applications to >> > signal the network with arbitrary data (like user specified hbp >> > options would be), then use of that mechanism will inevitably >> > exploited by some authorities to force user to hand over private data >> > about their communications. It's better to not build in back doors to >> > security... >> >> Sorry, Tom, can you try to explain again, I think I might not have >> understood you correctly. > Option whitelists are the right approach, applications should not be able to set random options in IP extension headers.
> yes, me too. Might help to discuss this by looking at an instance > of the type of option we are talking about. > > Usually hbh options are handled in the forwarding path (and thus > as unpopular as ip options, since they derail the packet to the > slow path). Are you suggesting some type of AAA to vet the hbh > option itself? > The issue that came up in IETF is that network operators (particularly radio networks) are concerned about the loss of visibility into the content since TLS became widely deployed. Unfortunately from the operators point of view at least, we are likely to see transport layer headers also being encrypted in the Internet (like Transports over UDP) which means they will have even less information. There is discussion now about rather applications can "give back" information that network operators previously deduced from inspecting clear text transport headers and payload. This would be accomplished with some sort of signaling to the network from applications. IP ext. headers are the standard mechanism for such signaling, although are a lot of people don't want to use them because they need to go through the kernel to set them-- because kernel takes too long deploy, bad interfaces, has too much control, etc. Hop by hop are open ended options defined as "The Hop-by-Hop Options header is used to carry optional information that must be examined by every node along a packet's delivery path.". If we allow applications to set arbitrary hbh options then the danger is that their network operator or local authority may require their own defined options. There's no reason to believe that this would be benevolent, such a mechanism could be used to force applications to leak private information about encrypted content which would diminish security or net neutrality. For instance a network provider could require its users to mark packets that are for cat videos, or want the URLs being accessed in http requests (described in a accord BOF @IETF), and there are even going to be authorities that demand they have access to crypto keys. Obviously there are always going to be attempts to force users to give up private information, but I don't think we (neither Linux nor IETF) should be building mechanisms that make it easy to do that. Tom > --Sowmini
