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