netdev - Re: IPv6 extension header privileges

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 27 May 2016 09:59:11 -0700
From:	Tom Herbert <tom@...bertland.com>
To:	Sowmini Varadhan <sowmini.varadhan@...cle.com>
Cc:	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>
Subject: Re: IPv6 extension header privileges

On Fri, May 27, 2016 at 8:03 AM, Sowmini Varadhan
<sowmini.varadhan@...cle.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