Message-ID: <20160522115605.GA30516@oracle.com>
Date:	Sun, 22 May 2016 07:56:05 -0400
From:	Sowmini Varadhan <sowmini.varadhan@...cle.com>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	Tom Herbert <tom@...bertland.com>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>
Subject: Re: IPv6 extension header privileges


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

Powered by blists - more mailing lists