Re: The 802.15.4 Security Layer

[Alexander Aring <alex.aring@gmail.com>]

On Fri, Jun 26, 2015 at 11:45:32AM +0200, Stefan Schmidt wrote:
> Hello.
> 
> On 26/06/15 11:32, Alexander Aring wrote:
> >On Fri, Jun 26, 2015 at 09:56:36AM +0100, Simon Vincent wrote:
> >>Ok yes this makes sense.
> >>
> >>Let me know if there is any bits I can help on.
> >>
> >I added more stuff into the branch [0], fix some embarrassingly mistakes.
> >
> >Yesterday I talked with Phoebe about "very simple to use" usecase for
> >the userspace application.
> >
> >In the discussion we end with the idea to have an userspace application
> >for load/store the security mib.
> >
> >Phoebe said it should be something like what iptables do:
> >
> >Like "ip6tables-save" and "ip6tables-restore".
> >
> >This will simple save the actual mib in a file and restore them from file,
> >these files should contain the same file format for representing the mib.
> >Later there should be also the possibility to change the mib during
> >runtime while a mib is already loaded, but at first the save/restore
> >sounds the most use case. You can still manipulate the mib security
> >structure in the configuration file which represents the mib, but need
> >to run a completely restore afterwards.
> >
> >
> >Maybe we can start a discussion about the "file format" which represents
> >the mib. This should be some simple format. Not xml/json which
> >adds library dependencies.
> >
> I'm still not 100% sold on the idea that we only want to allow the whole sec
> mib to be loaded and saved and not single properties. Having the option to
> set/get single mib sec properties would be useful and in line with all the
> other properties we handle in iwpan right now.
> 

That's what I trying to explain at sentence:

"Later there should be also the possibility to change the mib during
runtime while a mib is already loaded..."

of course that should be possible, but for now the first use case would
only to store/restore the security mib.

Nevertheless store/restore security should be use some small netlink
cmd's which use already the interface to implement such manipulation
over e.g. iwpan command line.

> What I capture from your and Phoebe's mails is that you want to have one
> policy file with all options in them to avoid broken configurations and
> problems to debug this, right?
> We still would need logic inside iwpan to detect and ignore these invalid
> configs. We could use the same logic when setting single properties.
> 

What I get was, everytime when you doing a reboot you need to
store/restore them like in iptables.

(Single properties), yes this is of course available then. I mean it
depends, the current interface doesn't allow to make small changes like
in a key structure. We allow to del a key and then add a new key
afterwards. All these things are possible to making a fine granularity
setting, but the first use case a store/restore would be fine to have
something that is working and solve the most use case.

> Don't get me wrong I'm fine having one file with all options in it I just
> think that having the possibility to set them individually might aloy be a
> benefit.Maybe I over engineer it. Don't know.
> 
> Coming back to the file format. I like the plain ini format for such cases.
> Its' plain text but still has some strcutre and key value pairs. A realy
> benefit imho is that it is also easy to read and modified by humans.
> 

Does ini files also handling list and hierarchy strutures? What I did
previously was to wrote something with flex/bison. I am not an expert in
flex/bison, but parsing config files should be "hopefully" simple
enough. List handling we need for e.g. seclevels and the hierarchy
functionality we need e.g. not to write everytime the key_id for
identify the key.

- Alex