IPv6 extension header privileges

IPv6 extension header privileges

[Tom Herbert]

Hi,

In ipv6_sockglue.c I noticed:

/* hop-by-hop / destination options are privileged option */
retv = -EPERM;
if (optname != IPV6_RTHDR && !ns_capable(net->user_ns, CAP_NET_RAW))
           break;

Can anyone provide that rationale as to why these are privileged ops?

Thanks,
Tom

Re: IPv6 extension header privileges

[Hannes Frederic Sowa]

On 21.05.2016 00:37, Tom Herbert wrote:
> Hi,
> 
> In ipv6_sockglue.c I noticed:
> 
> /* hop-by-hop / destination options are privileged option */
> retv = -EPERM;
> if (optname != IPV6_RTHDR && !ns_capable(net->user_ns, CAP_NET_RAW))
>            break;
> 
> Can anyone provide that rationale as to why these are privileged ops?

There are some options inherently protocol depending like the jumbo
payload option, which should be under control of the kernel, or the
router alert option for igmp, which causes packets to be steered towards
the slow/software path of routers, which can be used for DoS attacks.

Setting CALIPSO options in IPv6 on packets as users would defeat the
whole CALIPSO model, etc.

The RFC3542 requires at least some of the options in dst/hop-by-hop
extensions to be only be settable by privileged users. More fine-grained
parsing and setting of those options has never been implemented.

AFAIK people worried about the parsing overhead and thus decided to
block it for ordinary users.

Bye,
Hannes

Re: IPv6 extension header privileges

[Sowmini Varadhan]

On (05/21/16 02:20), Hannes Frederic Sowa wrote:
> 
> There are some options inherently protocol depending like the jumbo
> payload option, which should be under control of the kernel, or the
> router alert option for igmp, which causes packets to be steered towards
> the slow/software path of routers, which can be used for DoS attacks.
> 
> Setting CALIPSO options in IPv6 on packets as users would defeat the
> whole CALIPSO model, etc.
> 
> The RFC3542 requires at least some of the options in dst/hop-by-hop

"requires" is a strong word. 3542 declares it as a  "may" (lower case).
The only thing required strongly is IPV6_NEXTHOP itself.

I suspect 3542 was written at a time when hbh and dst opt were loosely
defined and the "may" is just a place-holder (i.e., it's not even a MAY)

> 
> AFAIK people worried about the parsing overhead and thus decided to
> block it for ordinary users.

That's probably more likely, esp for hbh options. It may also be 
interesting to find out what BSD does in these cases. 

--Sowmini 

Re: IPv6 extension header privileges

[Hannes Frederic Sowa]

On Sat, May 21, 2016, at 03:56, Sowmini Varadhan wrote:
> On (05/21/16 02:20), Hannes Frederic Sowa wrote:
> > 
> > There are some options inherently protocol depending like the jumbo
> > payload option, which should be under control of the kernel, or the
> > router alert option for igmp, which causes packets to be steered towards
> > the slow/software path of routers, which can be used for DoS attacks.
> > 
> > Setting CALIPSO options in IPv6 on packets as users would defeat the
> > whole CALIPSO model, etc.
> > 
> > The RFC3542 requires at least some of the options in dst/hop-by-hop
> 
> "requires" is a strong word. 3542 declares it as a  "may" (lower case).
> The only thing required strongly is IPV6_NEXTHOP itself.
> 
> I suspect 3542 was written at a time when hbh and dst opt were loosely
> defined and the "may" is just a place-holder (i.e., it's not even a MAY)

My wording directly from the RFC was too strong, true, but given that
there is a CALIPSO patch already floating around for the kernel and
those options are strictly controlled by selinux policy and build the
foundation for the networking separation we can't make it simply
non-priv.

Bye,
Hannes

Re: IPv6 extension header privileges

[Sowmini Varadhan]

On (05/21/16 11:34), Hannes Frederic Sowa wrote:
> 
> My wording directly from the RFC was too strong, true, but given that
> there is a CALIPSO patch already floating around for the kernel and
> those options are strictly controlled by selinux policy and build the
> foundation for the networking separation we can't make it simply
> non-priv.

sure, I agree with that point.

--Sowmini

Re: IPv6 extension header privileges

[Tom Herbert]

On Sat, May 21, 2016 at 2:34 AM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On Sat, May 21, 2016, at 03:56, Sowmini Varadhan wrote:
>> On (05/21/16 02:20), Hannes Frederic Sowa wrote:
>> >
>> > There are some options inherently protocol depending like the jumbo
>> > payload option, which should be under control of the kernel, or the
>> > router alert option for igmp, which causes packets to be steered towards
>> > the slow/software path of routers, which can be used for DoS attacks.
>> >
>> > Setting CALIPSO options in IPv6 on packets as users would defeat the
>> > whole CALIPSO model, etc.
>> >
>> > The RFC3542 requires at least some of the options in dst/hop-by-hop
>>
>> "requires" is a strong word. 3542 declares it as a  "may" (lower case).
>> The only thing required strongly is IPV6_NEXTHOP itself.
>>
>> I suspect 3542 was written at a time when hbh and dst opt were loosely
>> defined and the "may" is just a place-holder (i.e., it's not even a MAY)
>
> My wording directly from the RFC was too strong, true, but given that
> there is a CALIPSO patch already floating around for the kernel and
> those options are strictly controlled by selinux policy and build the
> foundation for the networking separation we can't make it simply
> non-priv.
>
If you don't mind I'll change this to make specific options are
privileged and not all hbh and destopt. There is talk in IETF about
reinventing IP extensibility within UDP since the kernel APIs don't
allow setting EH. I would like to avoid that :-)

> Bye,
> Hannes

Re: IPv6 extension header privileges

[Hannes Frederic Sowa]

On 21.05.2016 17:19, Tom Herbert wrote:
> On Sat, May 21, 2016 at 2:34 AM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
>> On Sat, May 21, 2016, at 03:56, Sowmini Varadhan wrote:
>>> On (05/21/16 02:20), Hannes Frederic Sowa wrote:
>>>>
>>>> There are some options inherently protocol depending like the jumbo
>>>> payload option, which should be under control of the kernel, or the
>>>> router alert option for igmp, which causes packets to be steered towards
>>>> the slow/software path of routers, which can be used for DoS attacks.
>>>>
>>>> Setting CALIPSO options in IPv6 on packets as users would defeat the
>>>> whole CALIPSO model, etc.
>>>>
>>>> The RFC3542 requires at least some of the options in dst/hop-by-hop
>>>
>>> "requires" is a strong word. 3542 declares it as a  "may" (lower case).
>>> The only thing required strongly is IPV6_NEXTHOP itself.
>>>
>>> I suspect 3542 was written at a time when hbh and dst opt were loosely
>>> defined and the "may" is just a place-holder (i.e., it's not even a MAY)
>>
>> My wording directly from the RFC was too strong, true, but given that
>> there is a CALIPSO patch already floating around for the kernel and
>> those options are strictly controlled by selinux policy and build the
>> foundation for the networking separation we can't make it simply
>> non-priv.
>>
> If you don't mind I'll change this to make specific options are
> privileged and not all hbh and destopt. There is talk in IETF about
> reinventing IP extensibility within UDP since the kernel APIs don't
> allow setting EH. I would like to avoid that :-)

Hehe, certainly.

A white list of certain registered IPv6 IANA-options for non-priv whould
certainly fly in my opinion. That is what I meant with "More
fine-grained parsing and setting of those options has never been
implemented." from my first mail.

I am not that certain about a blacklist though, but haven't thought
about that enough. I didn't yet get around to review other options, but
basically people could use private options in some proprietary settings
and we could break their assumptions by such a change.

Would a white list be sufficient?

Bye,
Hannes

Re: IPv6 extension header privileges

[Tom Herbert]

On Sat, May 21, 2016 at 8:33 AM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On 21.05.2016 17:19, Tom Herbert wrote:
>> On Sat, May 21, 2016 at 2:34 AM, Hannes Frederic Sowa
>> <hannes@stressinduktion.org> wrote:
>>> On Sat, May 21, 2016, at 03:56, Sowmini Varadhan wrote:
>>>> On (05/21/16 02:20), Hannes Frederic Sowa wrote:
>>>>>
>>>>> There are some options inherently protocol depending like the jumbo
>>>>> payload option, which should be under control of the kernel, or the
>>>>> router alert option for igmp, which causes packets to be steered towards
>>>>> the slow/software path of routers, which can be used for DoS attacks.
>>>>>
>>>>> Setting CALIPSO options in IPv6 on packets as users would defeat the
>>>>> whole CALIPSO model, etc.
>>>>>
>>>>> The RFC3542 requires at least some of the options in dst/hop-by-hop
>>>>
>>>> "requires" is a strong word. 3542 declares it as a  "may" (lower case).
>>>> The only thing required strongly is IPV6_NEXTHOP itself.
>>>>
>>>> I suspect 3542 was written at a time when hbh and dst opt were loosely
>>>> defined and the "may" is just a place-holder (i.e., it's not even a MAY)
>>>
>>> My wording directly from the RFC was too strong, true, but given that
>>> there is a CALIPSO patch already floating around for the kernel and
>>> those options are strictly controlled by selinux policy and build the
>>> foundation for the networking separation we can't make it simply
>>> non-priv.
>>>
>> If you don't mind I'll change this to make specific options are
>> privileged and not all hbh and destopt. There is talk in IETF about
>> reinventing IP extensibility within UDP since the kernel APIs don't
>> allow setting EH. I would like to avoid that :-)
>
> Hehe, certainly.
>
> A white list of certain registered IPv6 IANA-options for non-priv whould
> certainly fly in my opinion. That is what I meant with "More
> fine-grained parsing and setting of those options has never been
> implemented." from my first mail.
>
> I am not that certain about a blacklist though, but haven't thought
> about that enough. I didn't yet get around to review other options, but
> basically people could use private options in some proprietary settings
> and we could break their assumptions by such a change.
>
> Would a white list be sufficient?
>
Probably not. The "kernel is the problem" community always seem to be
looking for even the slightest API or implementation deficiency to
justify bypassing the kernel entirely. :-(

Tom

> Bye,
> Hannes
>

Re: IPv6 extension header privileges

[Hannes Frederic Sowa]

On 21.05.2016 18:00, Tom Herbert wrote:
> On Sat, May 21, 2016 at 8:33 AM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
>> On 21.05.2016 17:19, Tom Herbert wrote:
>>> On Sat, May 21, 2016 at 2:34 AM, Hannes Frederic Sowa
>>> <hannes@stressinduktion.org> wrote:
>>>> On Sat, May 21, 2016, at 03:56, Sowmini Varadhan wrote:
>>>>> On (05/21/16 02:20), Hannes Frederic Sowa wrote:
>>>>>>
>>>>>> There are some options inherently protocol depending like the jumbo
>>>>>> payload option, which should be under control of the kernel, or the
>>>>>> router alert option for igmp, which causes packets to be steered towards
>>>>>> the slow/software path of routers, which can be used for DoS attacks.
>>>>>>
>>>>>> Setting CALIPSO options in IPv6 on packets as users would defeat the
>>>>>> whole CALIPSO model, etc.
>>>>>>
>>>>>> The RFC3542 requires at least some of the options in dst/hop-by-hop
>>>>>
>>>>> "requires" is a strong word. 3542 declares it as a  "may" (lower case).
>>>>> The only thing required strongly is IPV6_NEXTHOP itself.
>>>>>
>>>>> I suspect 3542 was written at a time when hbh and dst opt were loosely
>>>>> defined and the "may" is just a place-holder (i.e., it's not even a MAY)
>>>>
>>>> My wording directly from the RFC was too strong, true, but given that
>>>> there is a CALIPSO patch already floating around for the kernel and
>>>> those options are strictly controlled by selinux policy and build the
>>>> foundation for the networking separation we can't make it simply
>>>> non-priv.
>>>>
>>> If you don't mind I'll change this to make specific options are
>>> privileged and not all hbh and destopt. There is talk in IETF about
>>> reinventing IP extensibility within UDP since the kernel APIs don't
>>> allow setting EH. I would like to avoid that :-)
>>
>> Hehe, certainly.
>>
>> A white list of certain registered IPv6 IANA-options for non-priv whould
>> certainly fly in my opinion. That is what I meant with "More
>> fine-grained parsing and setting of those options has never been
>> implemented." from my first mail.
>>
>> I am not that certain about a blacklist though, but haven't thought
>> about that enough. I didn't yet get around to review other options, but
>> basically people could use private options in some proprietary settings
>> and we could break their assumptions by such a change.
>>
>> Would a white list be sufficient?
>>
> Probably not. The "kernel is the problem" community always seem to be
> looking for even the slightest API or implementation deficiency to
> justify bypassing the kernel entirely. :-(

Hmm, I see...

Can you give some more details about the planned new options? I think we
can also open the API up for all options where the fourth bit is set,
which AFAIK denotes the experimental option space. And only have a
blacklist for the fourth bit == 0 case. Otherwise this is something IETF
people probably know more about what an impact this change could have.

Bye,
Hannes

Re: IPv6 extension header privileges

[Hannes Frederic Sowa]

On 21.05.2016 18:00, Tom Herbert wrote:
> On Sat, May 21, 2016 at 8:33 AM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
>> On 21.05.2016 17:19, Tom Herbert wrote:
>>> On Sat, May 21, 2016 at 2:34 AM, Hannes Frederic Sowa
>>> <hannes@stressinduktion.org> wrote:
>>>> On Sat, May 21, 2016, at 03:56, Sowmini Varadhan wrote:
>>>>> On (05/21/16 02:20), Hannes Frederic Sowa wrote:
>>>>>>
>>>>>> There are some options inherently protocol depending like the jumbo
>>>>>> payload option, which should be under control of the kernel, or the
>>>>>> router alert option for igmp, which causes packets to be steered towards
>>>>>> the slow/software path of routers, which can be used for DoS attacks.
>>>>>>
>>>>>> Setting CALIPSO options in IPv6 on packets as users would defeat the
>>>>>> whole CALIPSO model, etc.
>>>>>>
>>>>>> The RFC3542 requires at least some of the options in dst/hop-by-hop
>>>>>
>>>>> "requires" is a strong word. 3542 declares it as a  "may" (lower case).
>>>>> The only thing required strongly is IPV6_NEXTHOP itself.
>>>>>
>>>>> I suspect 3542 was written at a time when hbh and dst opt were loosely
>>>>> defined and the "may" is just a place-holder (i.e., it's not even a MAY)
>>>>
>>>> My wording directly from the RFC was too strong, true, but given that
>>>> there is a CALIPSO patch already floating around for the kernel and
>>>> those options are strictly controlled by selinux policy and build the
>>>> foundation for the networking separation we can't make it simply
>>>> non-priv.
>>>>
>>> If you don't mind I'll change this to make specific options are
>>> privileged and not all hbh and destopt. There is talk in IETF about
>>> reinventing IP extensibility within UDP since the kernel APIs don't
>>> allow setting EH. I would like to avoid that :-)
>>
>> Hehe, certainly.
>>
>> A white list of certain registered IPv6 IANA-options for non-priv whould
>> certainly fly in my opinion. That is what I meant with "More
>> fine-grained parsing and setting of those options has never been
>> implemented." from my first mail.
>>
>> I am not that certain about a blacklist though, but haven't thought
>> about that enough. I didn't yet get around to review other options, but
>> basically people could use private options in some proprietary settings
>> and we could break their assumptions by such a change.
>>
>> Would a white list be sufficient?
>>
> Probably not. The "kernel is the problem" community always seem to be
> looking for even the slightest API or implementation deficiency to
> justify bypassing the kernel entirely. :-(

Another issue, which could come up also is the ordering options during
the merge of kernel policy and user space provided options, hmpf...

Maybe a way out of it is to use some kind of sysctl, capability, or
whatever, depending on the use cases?

Bye,
Hannes

Re: IPv6 extension header privileges

[Sowmini Varadhan]

Tom Herbert wrote:
> >>> If you don't mind I'll change this to make specific options are
> >>> privileged and not all hbh and destopt. There is talk in IETF about
> >>> reinventing IP extensibility within UDP since the kernel APIs don't
> >>> allow setting EH. I would like to avoid that :-)

Do you mean this
  http://www.ietf.org/mail-archive/web/spud/current/msg00365.html

Maybe I misunderstood that rather long thread, but the author of that
draft seems to be arguing for reinventing tcp congavoid and windowing 
on top of udp to bypass kernel? ;-)

Hannes Frederic Sowa wrote:
> >> A white list of certain registered IPv6 IANA-options for non-priv whould

Problem is that APIs are not IANA'ed. 
Even RFC 3542 is just Informationaal. 

And even the classic socket API's that come down from BSD are not 
ietf'ed or iana'ed.

Hannes Frederic Sowa wrote:
> Can you give some more details about the planned new options? I think we
> can also open the API up for all options where the fourth bit is set,
> which AFAIK denotes the experimental option space. And only have a
> blacklist for the fourth bit == 0 case. Otherwise this is something IETF
> people probably know more about what an impact this change could have.

I think it would be ok for some options to be privileged, others to not.
We certainly have precedent for that from the classic socket APIs..
and man pages etc can document any restrictions, as we do with other
ioctls/sockopts etc.

--Sowmini

Re: IPv6 extension header privileges

[Hannes Frederic Sowa]

On 21.05.2016 19:46, Sowmini Varadhan wrote:
> Tom Herbert wrote:
>>>>> If you don't mind I'll change this to make specific options are
>>>>> privileged and not all hbh and destopt. There is talk in IETF about
>>>>> reinventing IP extensibility within UDP since the kernel APIs don't
>>>>> allow setting EH. I would like to avoid that :-)
> 
> Do you mean this
>   http://www.ietf.org/mail-archive/web/spud/current/msg00365.html
> 
> Maybe I misunderstood that rather long thread, but the author of that
> draft seems to be arguing for reinventing tcp congavoid and windowing 
> on top of udp to bypass kernel? ;-)

Hmm, haven't read carefully but isn't that just plain TCP in UDP? I saw
extension headers mentioned but haven't grasped why they deem necessary.

> Hannes Frederic Sowa wrote:
>>>> A white list of certain registered IPv6 IANA-options for non-priv whould
> 
> Problem is that APIs are not IANA'ed. 
> Even RFC 3542 is just Informationaal. 
> 
> And even the classic socket API's that come down from BSD are not 
> ietf'ed or iana'ed.

I think I don't completely understand this. IANA is numbering registry
and if we have the proper option number allocated we can make sensible
decisions and put options on the white list or provide a more complete
sensible implementation of the specification in the kernel.

E.g. if an option for encapsulation is going to be specified, normal
users should not be able to set those, like with CALIPSO or some VNI
inside hop-by-hop options. That should probably be controlled by a
routing table or a flow matching subsystem, in the kernel.

Congestion and windowing information need to be settable and receivable
from user space.

Unassigned option, we don't know anything about them so far and should
probably being blocked for the time being, as we don't know which spec
would use the number.

I think it is also in favor of the IETF to get those numbers specified
and allocated in a proper way, otherwise security won't be manageable at
all any more.

> Hannes Frederic Sowa wrote:
>> Can you give some more details about the planned new options? I think we
>> can also open the API up for all options where the fourth bit is set,
>> which AFAIK denotes the experimental option space. And only have a
>> blacklist for the fourth bit == 0 case. Otherwise this is something IETF
>> people probably know more about what an impact this change could have.
> 
> I think it would be ok for some options to be privileged, others to not.
> We certainly have precedent for that from the classic socket APIs..
> and man pages etc can document any restrictions, as we do with other
> ioctls/sockopts etc.

Sure, we can make options unprivileged, we just need to know which one
and find out the details how they mix with each other. Also user space
should only be allowed to query the options it is allowed to set, too,
and not the whole option blocks.

Bye,
Hannes

Re: IPv6 extension header privileges

[Sowmini Varadhan]

> > Tom Herbert wrote:
> >>>>> If you don't mind I'll change this to make specific options are
> >>>>> privileged and not all hbh and destopt. There is talk in IETF about
> >>>>> reinventing IP extensibility within UDP since the kernel APIs don't
> >>>>> allow setting EH. I would like to avoid that :-)

> On 21.05.2016 19:46, Sowmini Varadhan wrote:
> > Do you mean this
> >   http://www.ietf.org/mail-archive/web/spud/current/msg00365.html

On (05/22/16 03:08), Hannes Frederic Sowa wrote:
> Hmm, haven't read carefully but isn't that just plain TCP in UDP? I saw
> extension headers mentioned but haven't grasped why they deem necessary.

Tom should clarify what he meant, but perhaps he was referring to other
threads discussing v6 EH. In any case, I dont think the way least-privileges
for EH are implemented in an OS is directly relevant or causational for
whether or not the kernel should be bypassed - looks like there are a lot 
of other drafts floating around, arguing for implementing various tcp/ip
protocols in uspace and beyond, motivated by various reasons.

Moving back to the topic here:

> > Hannes Frederic Sowa wrote:
> >>>> A white list of certain registered IPv6 IANA-options for non-priv whould

> On 21.05.2016 19:46, Sowmini Varadhan wrote:
> > Problem is that APIs are not IANA'ed. 
> > Even RFC 3542 is just Informationaal. 
> > 
> > And even the classic socket API's that come down from BSD are not 
> > ietf'ed or iana'ed.

On (05/22/16 03:08), Hannes Frederic Sowa wrote:
> Hmm, haven't read carefully but isn't that just plain TCP in UDP? I saw
> I think I don't completely understand this. IANA is numbering registry
> and if we have the proper option number allocated we can make sensible
> decisions and put options on the white list or provide a more complete
> sensible implementation of the specification in the kernel.

IANA registers internet protocol (and related) numbers. so, e.g., 
So, for example, IP_TOS value is not really documented in iana,
and it ends up being 1 on linux, 3 on freebsd.  Or, to take another example,
IP_PKTINFO is "8" on linux, 0x1a on solaris and 25 in netbsd.  

But TOS, and the various code-points (which actually go out 
in the packet, and are needed for proper interop in the network)
are documented in iana/ietf etc.

> E.g. if an option for encapsulation is going to be specified, normal
> users should not be able to set those, like with CALIPSO or some VNI
> inside hop-by-hop options. That should probably be controlled by a
> routing table or a flow matching subsystem, in the kernel.

sure, I completely agree with that. And I strongly suspect that's why
rfc3542 puts down a wildcard "may" - so that some options may be privileged,
others not. Which options are "privileged" (and even the definition 
of "privileged") are entirely up to the OS implementation. (and even *how*
least priviliges/RBAC are implemented, can vary from OS to OS).

> I think it is also in favor of the IETF to get those numbers specified
> and allocated in a proper way, otherwise security won't be manageable at
> all any more.

see above.. Even rfc793 actually does not talk about POSIX APIs
but speaks in generalities, since the focus is on what goes on the wire.
In theory an implementation of a tcp/ip stack does not even have
to use the POSIX socket api, thus how can iana/ietf manadate
specific socket options and numbers, or the rbac model that they
should use? 

but that should not stop the linux kernel (or other OS) from trying 
to figure out the granularity of the rbac for these options and documenting 
them in some helpful way for apps.

--Sowmini

Re: IPv6 extension header privileges

[Hannes Frederic Sowa]

On 22.05.2016 13:56, Sowmini Varadhan wrote:
> 
>>> Tom Herbert wrote:
>>>>>>> If you don't mind I'll change this to make specific options are
>>>>>>> privileged and not all hbh and destopt. There is talk in IETF about
>>>>>>> reinventing IP extensibility within UDP since the kernel APIs don't
>>>>>>> allow setting EH. I would like to avoid that :-)
> 
>> On 21.05.2016 19:46, Sowmini Varadhan wrote:
>>> Do you mean this
>>>   http://www.ietf.org/mail-archive/web/spud/current/msg00365.html
> 
> On (05/22/16 03:08), Hannes Frederic Sowa wrote:
>> Hmm, haven't read carefully but isn't that just plain TCP in UDP? I saw
>> extension headers mentioned but haven't grasped why they deem necessary.
> 
> Tom should clarify what he meant, but perhaps he was referring to other
> threads discussing v6 EH. In any case, I dont think the way least-privileges
> for EH are implemented in an OS is directly relevant or causational for
> whether or not the kernel should be bypassed - looks like there are a lot 
> of other drafts floating around, arguing for implementing various tcp/ip
> protocols in uspace and beyond, motivated by various reasons.
> 
> Moving back to the topic here:
> 
>>> Hannes Frederic Sowa wrote:
>>>>>> A white list of certain registered IPv6 IANA-options for non-priv whould
> 
>> On 21.05.2016 19:46, Sowmini Varadhan wrote:
>>> Problem is that APIs are not IANA'ed. 
>>> Even RFC 3542 is just Informationaal. 
>>>
>>> And even the classic socket API's that come down from BSD are not 
>>> ietf'ed or iana'ed.
> 
> On (05/22/16 03:08), Hannes Frederic Sowa wrote:
>> Hmm, haven't read carefully but isn't that just plain TCP in UDP? I saw
>> I think I don't completely understand this. IANA is numbering registry
>> and if we have the proper option number allocated we can make sensible
>> decisions and put options on the white list or provide a more complete
>> sensible implementation of the specification in the kernel.
> 
> IANA registers internet protocol (and related) numbers. so, e.g., 
> So, for example, IP_TOS value is not really documented in iana,
> and it ends up being 1 on linux, 3 on freebsd.  Or, to take another example,
> IP_PKTINFO is "8" on linux, 0x1a on solaris and 25 in netbsd.  

Our setsockopts take the option numbers verbatim as they appear on the
wire (struct ipv6_opt_hdr). Thus we only need the numbers like
registered in the ipv6 parameter registry. API doesn't need to change
besides the privilege check. This is enough for Linux.

> but that should not stop the linux kernel (or other OS) from trying 
> to figure out the granularity of the rbac for these options and documenting 
> them in some helpful way for apps.

Just by knowing which option is interpreted in which way, we can do the
decision. I don't want to standardize APIs at all.

Bye,
Hannes

Re: IPv6 extension header privileges

[Tom Herbert]

On Sun, May 22, 2016 at 4:56 AM, Sowmini Varadhan
<sowmini.varadhan@oracle.com> wrote:
>
>> > Tom Herbert wrote:
>> >>>>> If you don't mind I'll change this to make specific options are
>> >>>>> privileged and not all hbh and destopt. There is talk in IETF about
>> >>>>> reinventing IP extensibility within UDP since the kernel APIs don't
>> >>>>> allow setting EH. I would like to avoid that :-)
>
>> On 21.05.2016 19:46, Sowmini Varadhan wrote:
>> > Do you mean this
>> >   http://www.ietf.org/mail-archive/web/spud/current/msg00365.html
>
> On (05/22/16 03:08), Hannes Frederic Sowa wrote:
>> Hmm, haven't read carefully but isn't that just plain TCP in UDP? I saw
>> extension headers mentioned but haven't grasped why they deem necessary.
>
> Tom should clarify what he meant, but perhaps he was referring to other
> threads discussing v6 EH. In any case, I dont think the way least-privileges
> for EH are implemented in an OS is directly relevant or causational for
> whether or not the kernel should be bypassed - looks like there are a lot
> of other drafts floating around, arguing for implementing various tcp/ip
> protocols in uspace and beyond, motivated by various reasons.
>
It's a deployment conundrum. Suppose tomorrow that IANA registers some
new hpb option that would be useful to the network, but is of no
interest to the kernel other than it needs to be set in packets when
the user requests it. In the white list model, there is no problem
getting support for such a thing into the upstream kernel, the time
frame for that is one release cycle. Neither is there any problem
updating the apps to set the option, for instance we can update FB app
to do this within a week. The problem is that getting something into
the kernel does not make it useful, the kernel needs to actually be
deployed which is mostly out of our control (for those of us who don't
own the client platform). So get the options deployed on clients
(particularly Android), this takes much, much longer. And if the
feature requires explicit action do be enabled, like turning a sysctl,
it is going to take even longer possibly an indeterminate amount of
time to ever get enabled.

Tom

> Moving back to the topic here:
>
>> > Hannes Frederic Sowa wrote:
>> >>>> A white list of certain registered IPv6 IANA-options for non-priv whould
>
>> On 21.05.2016 19:46, Sowmini Varadhan wrote:
>> > Problem is that APIs are not IANA'ed.
>> > Even RFC 3542 is just Informationaal.
>> >
>> > And even the classic socket API's that come down from BSD are not
>> > ietf'ed or iana'ed.
>
> On (05/22/16 03:08), Hannes Frederic Sowa wrote:
>> Hmm, haven't read carefully but isn't that just plain TCP in UDP? I saw
>> I think I don't completely understand this. IANA is numbering registry
>> and if we have the proper option number allocated we can make sensible
>> decisions and put options on the white list or provide a more complete
>> sensible implementation of the specification in the kernel.
>
> IANA registers internet protocol (and related) numbers. so, e.g.,
> So, for example, IP_TOS value is not really documented in iana,
> and it ends up being 1 on linux, 3 on freebsd.  Or, to take another example,
> IP_PKTINFO is "8" on linux, 0x1a on solaris and 25 in netbsd.
>
> But TOS, and the various code-points (which actually go out
> in the packet, and are needed for proper interop in the network)
> are documented in iana/ietf etc.
>
>> E.g. if an option for encapsulation is going to be specified, normal
>> users should not be able to set those, like with CALIPSO or some VNI
>> inside hop-by-hop options. That should probably be controlled by a
>> routing table or a flow matching subsystem, in the kernel.
>
> sure, I completely agree with that. And I strongly suspect that's why
> rfc3542 puts down a wildcard "may" - so that some options may be privileged,
> others not. Which options are "privileged" (and even the definition
> of "privileged") are entirely up to the OS implementation. (and even *how*
> least priviliges/RBAC are implemented, can vary from OS to OS).
>
>> I think it is also in favor of the IETF to get those numbers specified
>> and allocated in a proper way, otherwise security won't be manageable at
>> all any more.
>
> see above.. Even rfc793 actually does not talk about POSIX APIs
> but speaks in generalities, since the focus is on what goes on the wire.
> In theory an implementation of a tcp/ip stack does not even have
> to use the POSIX socket api, thus how can iana/ietf manadate
> specific socket options and numbers, or the rbac model that they
> should use?
>
> but that should not stop the linux kernel (or other OS) from trying
> to figure out the granularity of the rbac for these options and documenting
> them in some helpful way for apps.
>
> --Sowmini

Re: IPv6 extension header privileges

[Tom Herbert]

On Mon, May 23, 2016 at 11:11 AM, Tom Herbert <tom@herbertland.com> wrote:
> On Sun, May 22, 2016 at 4:56 AM, Sowmini Varadhan
> <sowmini.varadhan@oracle.com> wrote:
>>
>>> > Tom Herbert wrote:
>>> >>>>> If you don't mind I'll change this to make specific options are
>>> >>>>> privileged and not all hbh and destopt. There is talk in IETF about
>>> >>>>> reinventing IP extensibility within UDP since the kernel APIs don't
>>> >>>>> allow setting EH. I would like to avoid that :-)
>>
>>> On 21.05.2016 19:46, Sowmini Varadhan wrote:
>>> > Do you mean this
>>> >   http://www.ietf.org/mail-archive/web/spud/current/msg00365.html
>>
>> On (05/22/16 03:08), Hannes Frederic Sowa wrote:
>>> Hmm, haven't read carefully but isn't that just plain TCP in UDP? I saw
>>> extension headers mentioned but haven't grasped why they deem necessary.
>>
>> Tom should clarify what he meant, but perhaps he was referring to other
>> threads discussing v6 EH. In any case, I dont think the way least-privileges
>> for EH are implemented in an OS is directly relevant or causational for
>> whether or not the kernel should be bypassed - looks like there are a lot
>> of other drafts floating around, arguing for implementing various tcp/ip
>> protocols in uspace and beyond, motivated by various reasons.
>>
> It's a deployment conundrum. Suppose tomorrow that IANA registers some
> new hpb option that would be useful to the network, but is of no
> interest to the kernel other than it needs to be set in packets when
> the user requests it. In the white list model, there is no problem
> getting support for such a thing into the upstream kernel, the time
> frame for that is one release cycle. Neither is there any problem
> updating the apps to set the option, for instance we can update FB app
> to do this within a week. The problem is that getting something into
> the kernel does not make it useful, the kernel needs to actually be
> deployed which is mostly out of our control (for those of us who don't
> own the client platform). So get the options deployed on clients
> (particularly Android), this takes much, much longer. And if the
> feature requires explicit action do be enabled, like turning a sysctl,
> it is going to take even longer possibly an indeterminate amount of
> time to ever get enabled.
>
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...

Tom

> Tom
>
>> Moving back to the topic here:
>>
>>> > Hannes Frederic Sowa wrote:
>>> >>>> A white list of certain registered IPv6 IANA-options for non-priv whould
>>
>>> On 21.05.2016 19:46, Sowmini Varadhan wrote:
>>> > Problem is that APIs are not IANA'ed.
>>> > Even RFC 3542 is just Informationaal.
>>> >
>>> > And even the classic socket API's that come down from BSD are not
>>> > ietf'ed or iana'ed.
>>
>> On (05/22/16 03:08), Hannes Frederic Sowa wrote:
>>> Hmm, haven't read carefully but isn't that just plain TCP in UDP? I saw
>>> I think I don't completely understand this. IANA is numbering registry
>>> and if we have the proper option number allocated we can make sensible
>>> decisions and put options on the white list or provide a more complete
>>> sensible implementation of the specification in the kernel.
>>
>> IANA registers internet protocol (and related) numbers. so, e.g.,
>> So, for example, IP_TOS value is not really documented in iana,
>> and it ends up being 1 on linux, 3 on freebsd.  Or, to take another example,
>> IP_PKTINFO is "8" on linux, 0x1a on solaris and 25 in netbsd.
>>
>> But TOS, and the various code-points (which actually go out
>> in the packet, and are needed for proper interop in the network)
>> are documented in iana/ietf etc.
>>
>>> E.g. if an option for encapsulation is going to be specified, normal
>>> users should not be able to set those, like with CALIPSO or some VNI
>>> inside hop-by-hop options. That should probably be controlled by a
>>> routing table or a flow matching subsystem, in the kernel.
>>
>> sure, I completely agree with that. And I strongly suspect that's why
>> rfc3542 puts down a wildcard "may" - so that some options may be privileged,
>> others not. Which options are "privileged" (and even the definition
>> of "privileged") are entirely up to the OS implementation. (and even *how*
>> least priviliges/RBAC are implemented, can vary from OS to OS).
>>
>>> I think it is also in favor of the IETF to get those numbers specified
>>> and allocated in a proper way, otherwise security won't be manageable at
>>> all any more.
>>
>> see above.. Even rfc793 actually does not talk about POSIX APIs
>> but speaks in generalities, since the focus is on what goes on the wire.
>> In theory an implementation of a tcp/ip stack does not even have
>> to use the POSIX socket api, thus how can iana/ietf manadate
>> specific socket options and numbers, or the rbac model that they
>> should use?
>>
>> but that should not stop the linux kernel (or other OS) from trying
>> to figure out the granularity of the rbac for these options and documenting
>> them in some helpful way for apps.
>>
>> --Sowmini

Re: IPv6 extension header privileges

[YOSHIFUJI Hideaki]

Hi,

Tom Herbert wrote:
> Hi,
> 
> In ipv6_sockglue.c I noticed:
> 
> /* hop-by-hop / destination options are privileged option */
> retv = -EPERM;
> if (optname != IPV6_RTHDR && !ns_capable(net->user_ns, CAP_NET_RAW))
>            break;
> 
> Can anyone provide that rationale as to why these are privileged ops?

It is better to disallow by default for security.
FreeBSD does this in the same way.
We may have sysctl bitmaps, of course.

--yoshfuji

> 
> Thanks,
> Tom
> 

-- 
Hideaki Yoshifuji <hideaki.yoshifuji@miraclelinux.com>
Technical Division, MIRACLE LINUX CORPORATION

Re: IPv6 extension header privileges

[Hannes Frederic Sowa]

On 26.05.2016 20:42, Tom Herbert wrote:
> On Mon, May 23, 2016 at 11:11 AM, Tom Herbert <tom@herbertland.com> wrote:
>> On Sun, May 22, 2016 at 4:56 AM, Sowmini Varadhan
>> <sowmini.varadhan@oracle.com> wrote:
>>>
>>>>> Tom Herbert wrote:
>>>>>>>>> If you don't mind I'll change this to make specific options are
>>>>>>>>> privileged and not all hbh and destopt. There is talk in IETF about
>>>>>>>>> reinventing IP extensibility within UDP since the kernel APIs don't
>>>>>>>>> allow setting EH. I would like to avoid that :-)
>>>
>>>> On 21.05.2016 19:46, Sowmini Varadhan wrote:
>>>>> Do you mean this
>>>>>   http://www.ietf.org/mail-archive/web/spud/current/msg00365.html
>>>
>>> On (05/22/16 03:08), Hannes Frederic Sowa wrote:
>>>> Hmm, haven't read carefully but isn't that just plain TCP in UDP? I saw
>>>> extension headers mentioned but haven't grasped why they deem necessary.
>>>
>>> Tom should clarify what he meant, but perhaps he was referring to other
>>> threads discussing v6 EH. In any case, I dont think the way least-privileges
>>> for EH are implemented in an OS is directly relevant or causational for
>>> whether or not the kernel should be bypassed - looks like there are a lot
>>> of other drafts floating around, arguing for implementing various tcp/ip
>>> protocols in uspace and beyond, motivated by various reasons.
>>>
>> It's a deployment conundrum. Suppose tomorrow that IANA registers some
>> new hpb option that would be useful to the network, but is of no
>> interest to the kernel other than it needs to be set in packets when
>> the user requests it. In the white list model, there is no problem
>> getting support for such a thing into the upstream kernel, the time
>> frame for that is one release cycle. Neither is there any problem
>> updating the apps to set the option, for instance we can update FB app
>> to do this within a week. The problem is that getting something into
>> the kernel does not make it useful, the kernel needs to actually be
>> deployed which is mostly out of our control (for those of us who don't
>> own the client platform). So get the options deployed on clients
>> (particularly Android), this takes much, much longer. And if the
>> feature requires explicit action do be enabled, like turning a sysctl,
>> it is going to take even longer possibly an indeterminate amount of
>> time to ever get enabled.
>>
> 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.

Thanks,
Hannes

Re: IPv6 extension header privileges

[Sowmini Varadhan]

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.

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?

--Sowmini

Re: IPv6 extension header privileges

[Hannes Frederic Sowa]

On Thu, May 26, 2016, at 20:42, Tom Herbert 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...

Also I don't think that HbH options form some kind of hidden covert
channel. They mostly appear by unused fields which cannot be verified by
the other (receiving) side in any way.

Re: IPv6 extension header privileges

[Tom Herbert]

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

Re: IPv6 extension header privileges

[Tom Herbert]

On Fri, May 27, 2016 at 9:46 AM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On Thu, May 26, 2016, at 20:42, Tom Herbert 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...
>
> Also I don't think that HbH options form some kind of hidden covert
> channel. They mostly appear by unused fields which cannot be verified by
> the other (receiving) side in any way.

It would be pretty easy to make it that. All a network operator would
need to do is strip their proprietary options on egress from their
network. So a receiver, say our servers at FB, would have no way to
determine that our clients are being manipulated.

Tom

Re: IPv6 extension header privileges

[Hannes Frederic Sowa]

Hi,

On 27.05.2016 18:59, Tom Herbert wrote:
> On Fri, May 27, 2016 at 8:03 AM, Sowmini Varadhan
> <sowmini.varadhan@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.

I also wonder how helpful TCP middleboxes are nowadays. I haven't done
any kind of tests for example over satellite connections with TCP. A TCP
frame cache probably helps a lot getting a faster connection but at the
same time messes with the RTT. I could imagine network operators wanting
control over the data stream.

Your proposal with DTLS also leaks a lot of information. E.g. I remember
that certificates are always send in clear text and I currently don't
know if TLS 1.3 solves this (DTLS is basically TLS split on record
boundaries to UDP frames). Sequence numbers ensure that e.g. no reply
attack can happen. The DTLS "connection establishment" and "teardown"
also provides the necessary information to handle the UDP flow stateful,
thus connection tracking is not completely circumvented. (D)TLS also
provides extensions which could be used for signaling and keeping state
in the network.

Otherwise my problem with DTLS is that it is much less deployed. E.g. I
remember from the mosh paper [1] that no current implementation of DTLS
actually supports roaming of "DTLS connections".

[1] https://mosh.mit.edu/mosh-paper-draft.pdf

> 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.

Sounds like solving social problems with technology. :)

In general I agree, but it seems to me that the provider edges are
already capable of doing so, adding headers at the edge and transporting
them over the backbone and removing them add the edge again. They could
as well also be tunneled in geneve completely to provide arbitrary TLV
options.

Another questions about your approach:

Do you expect e.g. Facebook deploying TLS inside DTLS or is the DTLS
connection in the long run a way to defeat end-to-end crypto, as only
the tunnel themselves will be encrypted? Adding encryption in encryption
might be a huge performance loss?

And another addendum: did you look into using ALPN (RFC 7301) instead of
using payload transformers in GUE?

All in all, I agree, maybe not because of the same reasons but it would
be hard to come up with a blacklist of possible options.

Bye,
Hannes

Re: IPv6 extension header privileges

[Tom Herbert]

On Fri, May 27, 2016 at 10:14 AM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> Hi,
>
> On 27.05.2016 18:59, Tom Herbert wrote:
>> On Fri, May 27, 2016 at 8:03 AM, Sowmini Varadhan
>> <sowmini.varadhan@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.
>
> I also wonder how helpful TCP middleboxes are nowadays. I haven't done
> any kind of tests for example over satellite connections with TCP. A TCP
> frame cache probably helps a lot getting a faster connection but at the
> same time messes with the RTT. I could imagine network operators wanting
> control over the data stream.
>
No doubt. Things like in-network TCP optimizers have existed for a long time.

> Your proposal with DTLS also leaks a lot of information. E.g. I remember
> that certificates are always send in clear text and I currently don't
> know if TLS 1.3 solves this (DTLS is basically TLS split on record
> boundaries to UDP frames). Sequence numbers ensure that e.g. no reply
> attack can happen. The DTLS "connection establishment" and "teardown"
> also provides the necessary information to handle the UDP flow stateful,
> thus connection tracking is not completely circumvented. (D)TLS also
> provides extensions which could be used for signaling and keeping state
> in the network.
>
Yes, in a perfect world the network would only look at IP headers and
have no incentive or even ability to look beyond that. AFAIK, we
always need some cleartext to provide the security context, but at
least that would be authenticated.

> Otherwise my problem with DTLS is that it is much less deployed. E.g. I
> remember from the mosh paper [1] that no current implementation of DTLS
> actually supports roaming of "DTLS connections".
>
It's an end to end issue. To deploy DTLS I should only need to update
my client and server application, not the kernel are any intermediate
device. This is essential to getting us back to the E2E principle.
Probably the more operative question is rather UDP can be widely
deployed in the Internet.

> [1] https://mosh.mit.edu/mosh-paper-draft.pdf
>
>> 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.
>
> Sounds like solving social problems with technology. :)
>
That surprises you? You've been working on the Internet for a while right... ;-)

> In general I agree, but it seems to me that the provider edges are
> already capable of doing so, adding headers at the edge and transporting
> them over the backbone and removing them add the edge again. They could
> as well also be tunneled in geneve completely to provide arbitrary TLV
> options.
>
> Another questions about your approach:
>
> Do you expect e.g. Facebook deploying TLS inside DTLS or is the DTLS
> connection in the long run a way to defeat end-to-end crypto, as only
> the tunnel themselves will be encrypted? Adding encryption in encryption
> might be a huge performance loss?
>
DTLS replaces TLS because it allows us to include TCP headers in the
crypto, so TLS would be redundant.

> And another addendum: did you look into using ALPN (RFC 7301) instead of
> using payload transformers in GUE?
>
The payload transform just provides the type of payload (for
interpretation). ALPN could certainly be used within that.

> All in all, I agree, maybe not because of the same reasons but it would
> be hard to come up with a blacklist of possible options.
>
Right, blacklist == bad idea!

Tom

> Bye,
> Hannes
>