The 802.15.4 Security Layer

The 802.15.4 Security Layer

[Alexander Aring]

Hi all,

I saw the latest discussion about the security layer and wants to open a
new thread about discussion for access this layer over nl802154 and
putting a "very easy to use" functionality into iwpan.

I need to admit, I never tested myself this layer, also I told many
times that the step to put security layer functionality into nl802154 is
a necessary step. For that reason I declare the security layer as broken.

Several months ago I started to put these functionality into wpan-tools
and nl802154. It's just parsing a file at the moment and putting the all
relevant entries for key, device, seclevel tables in cfg802154. Nothing
more. These tables are handled like an ACL in 802.15.4 (so far I know)
and necessary to do the "key lookup" procedure, on receiving decrypted
frames.

At weekend I will try to provide my stuff which I already have done and
will try to explain what the idea for the next necessary steps are. It's
just to start a discussion "How do deal with accessing llsec over 
nl802154/cfg802154".

After we can accessing the sec layer over nl802154, we can hopefully remove
the old interface stuff.

Does this sounds like a plan?

Thanks.

- Alex

Re: The 802.15.4 Security Layer

[Stefan Schmidt]

Hello.

On 18/06/15 14:31, Alexander Aring wrote:
> Hi all,
>
> I saw the latest discussion about the security layer and wants to open a
> new thread about discussion for access this layer over nl802154 and
> putting a "very easy to use" functionality into iwpan.
>
> I need to admit, I never tested myself this layer, also I told many
> times that the step to put security layer functionality into nl802154 is
> a necessary step. For that reason I declare the security layer as broken.
>
> Several months ago I started to put these functionality into wpan-tools
> and nl802154. It's just parsing a file at the moment and putting the all
> relevant entries for key, device, seclevel tables in cfg802154. Nothing
> more. These tables are handled like an ACL in 802.15.4 (so far I know)
> and necessary to do the "key lookup" procedure, on receiving decrypted
> frames.
>
> At weekend I will try to provide my stuff which I already have done and
> will try to explain what the idea for the next necessary steps are. It's
> just to start a discussion "How do deal with accessing llsec over
> nl802154/cfg802154".
>
> After we can accessing the sec layer over nl802154, we can hopefully remove
> the old interface stuff.
>
> Does this sounds like a plan?

I think this is a good idea and I would gladly gve this some testing 
next week. I bet Simon would do as well as he is currently looking into it.

regards
Stefan Schmidt

Re: The 802.15.4 Security Layer

[Simon Vincent]

Hi,

On 18/06/15 16:42, Stefan Schmidt wrote:
> Hello.
>
> On 18/06/15 14:31, Alexander Aring wrote:
>> Hi all,
>>
>> I saw the latest discussion about the security layer and wants to open a
>> new thread about discussion for access this layer over nl802154 and
>> putting a "very easy to use" functionality into iwpan.
>>
>> I need to admit, I never tested myself this layer, also I told many
>> times that the step to put security layer functionality into nl802154 is
>> a necessary step. For that reason I declare the security layer as 
>> broken.
>>
>> Several months ago I started to put these functionality into wpan-tools
>> and nl802154. It's just parsing a file at the moment and putting the all
>> relevant entries for key, device, seclevel tables in cfg802154. Nothing
>> more. These tables are handled like an ACL in 802.15.4 (so far I know)
>> and necessary to do the "key lookup" procedure, on receiving decrypted
>> frames.
>>
>> At weekend I will try to provide my stuff which I already have done and
>> will try to explain what the idea for the next necessary steps are. It's
>> just to start a discussion "How do deal with accessing llsec over
>> nl802154/cfg802154".
>>
>> After we can accessing the sec layer over nl802154, we can hopefully 
>> remove
>> the old interface stuff.
>>
>> Does this sounds like a plan?
>
> I think this is a good idea and I would gladly gve this some testing 
> next week. I bet Simon would do as well as he is currently looking 
> into it.
Yes it would nice to tidy this all up and get a stable interface. I 
currently have some time to look at this and do some testing.

- Simon

Re: The 802.15.4 Security Layer

[Stefan Schmidt]

Hello.

On 18/06/15 17:58, Simon Vincent wrote:
> Hi,
>
> On 18/06/15 16:42, Stefan Schmidt wrote:
>> Hello.
>>
>> On 18/06/15 14:31, Alexander Aring wrote:
>>> Hi all,
>>>
>>> I saw the latest discussion about the security layer and wants to 
>>> open a
>>> new thread about discussion for access this layer over nl802154 and
>>> putting a "very easy to use" functionality into iwpan.
>>>
>>> I need to admit, I never tested myself this layer, also I told many
>>> times that the step to put security layer functionality into 
>>> nl802154 is
>>> a necessary step. For that reason I declare the security layer as 
>>> broken.
>>>
>>> Several months ago I started to put these functionality into wpan-tools
>>> and nl802154. It's just parsing a file at the moment and putting the 
>>> all
>>> relevant entries for key, device, seclevel tables in cfg802154. Nothing
>>> more. These tables are handled like an ACL in 802.15.4 (so far I know)
>>> and necessary to do the "key lookup" procedure, on receiving decrypted
>>> frames.
>>>
>>> At weekend I will try to provide my stuff which I already have done and
>>> will try to explain what the idea for the next necessary steps are. 
>>> It's
>>> just to start a discussion "How do deal with accessing llsec over
>>> nl802154/cfg802154".
>>>
>>> After we can accessing the sec layer over nl802154, we can hopefully 
>>> remove
>>> the old interface stuff.
>>>
>>> Does this sounds like a plan?
>>
>> I think this is a good idea and I would gladly gve this some testing 
>> next week. I bet Simon would do as well as he is currently looking 
>> into it.
> Yes it would nice to tidy this all up and get a stable interface. I 
> currently have some time to look at this and do some testing.

You have by any chance some small example code you used for testing the 
llc stuff? It would be handy to start with something small and easy.

regards
Stefan Schmidt

Re: The 802.15.4 Security Layer

[Alexander Aring]

On Thu, Jun 18, 2015 at 02:31:54PM +0200, Alexander Aring wrote:
...
> At weekend I will try to provide my stuff which I already have done and
> will try to explain what the idea for the next necessary steps are. It's
> just to start a discussion "How do deal with accessing llsec over 
> nl802154/cfg802154".

In my timezone it's still weekend and will provide some more information
about to handling security 802.15.4 in nl802154.

What's the problem?

1. There exist no nl802154 commands/attributes for providing security,
   but this is a small problem. Adding new enums in nl802154 and putting
   logic into nl802154.c

2. The big problem and the question "How to deal with that now" is for
   me the storage of current security configurations. Since the nl802154
   we providing the MIB/PIB structure in ieee802154 layer and not
   mac802154.

   
   What are the difference between these layers?

   The ieee802154 is for the netlink/socket/above layers, the
   underlaying layers are mac802154 (in case of SoftMAC) or driver layer
   (in case of HardMAC layer). HardMAC drivers doesn't exists right now
   and I think we need to move some other code from mac802154 into ieee802154
   layer to providing HardMAC drivers (or they do it in driver layer).

   The current situation of security related MIB stuff:

   Currently everything is stored in internal mac802154 structs and the upper
   layer have some set/del/get callbacks in mlme_ops to access them.
   See [0]. At [0] you see "struct mac802154_llsec sec;" which stores
   the complete security MIB stuff.

   Now, the security related MIB stuff should be stored inside
   ieee802154 and not mac802154. Like other MIB values this is stored
   now inside the wpan_dev structure which extends the netdev structure
   which 802.15.4 related informations. See [1].


What's the problem to doing that?

We need to detect which information is necessary to store the MIB
security related information and which should still be in mac802154 for
handling internal llsec mechanism.

The wpan_dev MIB should represents the current information of security
layer only. In general this looks like:


                       .------------.
             .-------- |  nl802154  | ----------.
             |         '------------'           |
    set(del) |                ^                 |  set(del)      
             v                | get             v
      .------------.          |          .------------.
      | cfg802154  | .----------------.  | cfg802154  |
      '------------' | MIB (wpan_dev) |  '------------'
             |       '----------------'         |
   set(del)  |              ^    ^              | set(del)      
             |              |    |              |            ieee802154
      =================================================================
             |              |    |              |      mac80215/HardMAC
             v              |    |              |
      .------------.        |    |              |
      | mac802154  |        |    |              v
      | .-------.  |        |    |       .------------.
      | | llsec |  |<-------'    ------->|  HardMAC   |
      | '-------'  |     set(del)/get    '------------'
      '------------'


What are the boxes?

nl802154: netlink layer.

cfg802154: the in our case the identically mlme_ops callback structure.

mac802154: the SoftMAC layer.

HardMAC: possible HardMAC layer.

The big "...===..." symbols the layers which things are accessible in
ieee802154 layer and the below layer.

I also mark some get/set at the arrows to see which have "manipulate"
access and which have some "read" access.


Note: The difference in mlme_ops and cfg802154 are no getters are
required. The nl802154 should simple dump the current settings from
wpan_dev structure which stores the actual security MIB.

This is the basic architecture which how it should work by storing
security MIB information.


The big question now (for me currently):

The mac802154 security MIB storage, see [0]. Contains very performance
related datastructures and I agree do doing that, because on each
receiving frame we need to lookup the key by some attributes like
addresses etc. The current solution for that is doing a hash and then
lookup them in some hash tables. That's perfect, we currently do that
also by finding the right fragment inside the 6LoWPAN fragmentation stuff.


In my opinion, this perfomance stuff should _not_ go into the wpan_dev
MIB security configuration and we leave it inside the llsec
implementation. Why, I think that? Because handling hashes there are too
overkill for just representing the current configuration inside
nl802154. Later the HardMAC drivers should not deal with hashes for just
representing the current security configuration.


How we should deal with that then:

Simple using some list stuff which representing the configuration inside
the MIB of wpan_dev. On the cfg802154 (setter) callbacks, we know the
configuration what the wpan MIB should hold. The llsec (security related
tables, the hashes) _and_ MIB wpan_dev (security related tables, simple
some list stuff) should be representing the same stuff.

So llsec is just simple a very performance related security layer
implementation of mac802154, similar what a HardMAC driver has on the
HardMAC related firmware which doing security stuff.


The question is now: Should we go that way or really hold hashes stuff
into wpan_dev?

I told that I began to programming the MIB handling stuff into nl802154
and wpan-tools. I will show later code, it's based on the idea to simple
don't moving the llsec (performance datastructures) into wpan_dev MIB,
instead doing list stuff there and fill the llsec MIB by the cfg802154
setters which should be the same inside the MIB wpan_dev structure.

I rebased my nl802154 and wpan-tools stuff which I did and figured out
that I need to do something for making setting and dumping available. I
will show code when it's works.

If this works, then the next step would be that the cfg802154_ops which
have the setter/delete callbacks for security MIB settings should fill
then the llsec MIB.

I hope it's understandable what I tried to explain here and we can
clarify now "How to handle the storage of MIB values". What we need to
do for sure is the move of these datastructures into ieee802154 layer.

- Alex

[0] http://lxr.free-electrons.com/source/net/mac802154/ieee802154_i.h#L96
[1] http://lxr.free-electrons.com/source/include/net/cfg802154.h#L106
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in

Re: The 802.15.4 Security Layer

[Phoebe Buckheister]

Hi,

On Sun, 21 Jun 2015 23:12:29 +0200
Alexander Aring <alex.aring@gmail.com> wrote:

> On Thu, Jun 18, 2015 at 02:31:54PM +0200, Alexander Aring wrote:
> […]
> 
> The big question now (for me currently):
> 
> The mac802154 security MIB storage, see [0]. Contains very performance
> related datastructures and I agree do doing that, because on each
> receiving frame we need to lookup the key by some attributes like
> addresses etc. The current solution for that is doing a hash and then
> lookup them in some hash tables. That's perfect, we currently do that
> also by finding the right fragment inside the 6LoWPAN fragmentation
> stuff.

The hash lookups there are not actually perfect in any sense. With many
security-aware nodes, the 2**6 buckets that are statically configured
right now may very slow down a lot due to hash collisions.

> In my opinion, this perfomance stuff should _not_ go into the wpan_dev
> MIB security configuration and we leave it inside the llsec
> implementation. Why, I think that? Because handling hashes there are
> too overkill for just representing the current configuration inside
> nl802154. Later the HardMAC drivers should not deal with hashes for
> just representing the current security configuration.

Agreed. Each driver framework (SoftMAC, HardMAC) Must be free to choose
its own "ideal" representation (whatever that means).

> How we should deal with that then:
> 
> Simple using some list stuff which representing the configuration
> inside the MIB of wpan_dev. On the cfg802154 (setter) callbacks, we
> know the configuration what the wpan MIB should hold. The llsec
> (security related tables, the hashes) _and_ MIB wpan_dev (security
> related tables, simple some list stuff) should be representing the
> same stuff.

That will not be entirely possible with HardMAC, at least not without
some work. If a HardMAC implements llsec and you instruct it to use the
DEVKEY_RECORD mode, you will have to periodically poll the MAC (or
receive interrupts) when a new new key has been recorded.The frame
counters per key may also change wildly at the worst possible times, so
mirroring them is entirely impossible. When your network has
encrypted/authenticated traffic, you can at best mirror an old subset of
the actual state in wpan_dev without generating way too much management
traffic.

> So llsec is just simple a very performance related security layer
> implementation of mac802154, similar what a HardMAC driver has on the
> HardMAC related firmware which doing security stuff.
> 
> 
> The question is now: Should we go that way or really hold hashes stuff
> into wpan_dev?
> 
> I told that I began to programming the MIB handling stuff into
> nl802154 and wpan-tools. I will show later code, it's based on the
> idea to simple don't moving the llsec (performance datastructures)
> into wpan_dev MIB, instead doing list stuff there and fill the llsec
> MIB by the cfg802154 setters which should be the same inside the MIB
> wpan_dev structure.

That is probably not a good idea due to the variability of the actual
MIB at runtime. For each llsec MIB query, you might have to dump a
large part of the actual driver MIB to resync your lists with what the
driver actually knows about the network. It's not as painful as it
could be since you'd only have to sync in one direction, but that's
still one sync too many for my comfort.

If a HardMAC was too slow to respond to such queries in a timely
manner, that might be wholly different story. You can reliably mirror
some parts of the MIB (security levels and key descriptors), but those
are only a fraction of the actual MIB size.

> I rebased my nl802154 and wpan-tools stuff which I did and figured out
> that I need to do something for making setting and dumping available.
> I will show code when it's works.
> 
> If this works, then the next step would be that the cfg802154_ops
> which have the setter/delete callbacks for security MIB settings
> should fill then the llsec MIB.
> 
> I hope it's understandable what I tried to explain here and we can
> clarify now "How to handle the storage of MIB values". What we need to
> do for sure is the move of these datastructures into ieee802154 layer.

I'd much rather move the interface to those structures to the
ieee802154 layer, and let the actual driver framework implement those
interface as it wishes. Duplication will not serve us well here, just
as it has bitten someone already in llsec_params.

> - Alex
> 
> [0]
> http://lxr.free-electrons.com/source/net/mac802154/ieee802154_i.h#L96
> [1] http://lxr.free-electrons.com/source/include/net/cfg802154.h#L106
> -- To unsubscribe from this list: send the line "unsubscribe
> linux-wpan" in

--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in

Re: The 802.15.4 Security Layer

[Alexander Aring]

Hi,

On Mon, Jun 22, 2015 at 02:33:28PM +0200, Phoebe Buckheister wrote:
> Hi,
> 
> On Sun, 21 Jun 2015 23:12:29 +0200
> Alexander Aring <alex.aring@gmail.com> wrote:
> 
> > On Thu, Jun 18, 2015 at 02:31:54PM +0200, Alexander Aring wrote:
> > […]
> > 
> > The big question now (for me currently):
> > 
> > The mac802154 security MIB storage, see [0]. Contains very performance
> > related datastructures and I agree do doing that, because on each
> > receiving frame we need to lookup the key by some attributes like
> > addresses etc. The current solution for that is doing a hash and then
> > lookup them in some hash tables. That's perfect, we currently do that
> > also by finding the right fragment inside the 6LoWPAN fragmentation
> > stuff.
> 
> The hash lookups there are not actually perfect in any sense. With many
> security-aware nodes, the 2**6 buckets that are statically configured
> right now may very slow down a lot due to hash collisions.
> 

ok. Maybe we should look into the rhashtable datastructure [0]. It's
"Resizable, Scalable, Concurrent Hash Table" [0].

Anyway, I am fine with the current implementation that's better than
using list implementations, anyway. Thanks for pointing this issue of
statically configuration. We can try to change it later, after doing the
crypto nl802154 stuff.

> > In my opinion, this perfomance stuff should _not_ go into the wpan_dev
> > MIB security configuration and we leave it inside the llsec
> > implementation. Why, I think that? Because handling hashes there are
> > too overkill for just representing the current configuration inside
> > nl802154. Later the HardMAC drivers should not deal with hashes for
> > just representing the current security configuration.
> 
> Agreed. Each driver framework (SoftMAC, HardMAC) Must be free to choose
> its own "ideal" representation (whatever that means).
> 

ok.

> > How we should deal with that then:
> > 
> > Simple using some list stuff which representing the configuration
> > inside the MIB of wpan_dev. On the cfg802154 (setter) callbacks, we
> > know the configuration what the wpan MIB should hold. The llsec
> > (security related tables, the hashes) _and_ MIB wpan_dev (security
> > related tables, simple some list stuff) should be representing the
> > same stuff.
> 
> That will not be entirely possible with HardMAC, at least not without
> some work. If a HardMAC implements llsec and you instruct it to use the
> DEVKEY_RECORD mode, you will have to periodically poll the MAC (or
> receive interrupts) when a new new key has been recorded.The frame
> counters per key may also change wildly at the worst possible times, so
> mirroring them is entirely impossible. When your network has
> encrypted/authenticated traffic, you can at best mirror an old subset of
> the actual state in wpan_dev without generating way too much management
> traffic.
> 

For your example the frame counter:

I agree this sounds crazy to always ask what's the current frame counter
is, that's one example for a MIB attribute that we should not put into
ieee802154 layer.

What I think is to put in ieee802154 a security MIB only for
configuration the necessary "ACL" stuff for key management.

These MIB security settings should the only one which are read/writeable
from userspace over nl802154.

On userspace side there should then no difference between accessing a
SoftMAC or HardMAC transceiver.

> > So llsec is just simple a very performance related security layer
> > implementation of mac802154, similar what a HardMAC driver has on the
> > HardMAC related firmware which doing security stuff.
> > 
> > 
> > The question is now: Should we go that way or really hold hashes stuff
> > into wpan_dev?
> > 
> > I told that I began to programming the MIB handling stuff into
> > nl802154 and wpan-tools. I will show later code, it's based on the
> > idea to simple don't moving the llsec (performance datastructures)
> > into wpan_dev MIB, instead doing list stuff there and fill the llsec
> > MIB by the cfg802154 setters which should be the same inside the MIB
> > wpan_dev structure.
> 
> That is probably not a good idea due to the variability of the actual
> MIB at runtime. For each llsec MIB query, you might have to dump a
> large part of the actual driver MIB to resync your lists with what the
> driver actually knows about the network. It's not as painful as it
> could be since you'd only have to sync in one direction, but that's
> still one sync too many for my comfort.
> 
> If a HardMAC was too slow to respond to such queries in a timely
> manner, that might be wholly different story. You can reliably mirror
> some parts of the MIB (security levels and key descriptors), but those
> are only a fraction of the actual MIB size.
> 

Ok, then what's about to move the "userspace configurable" stuff to
ieee802154?

When a set/add call was successful then simple the ieee802154 mib stuff
will be updated. I know the "device descriptor" contains the frame
counter stuff which is hard to sync with the above layer, but then
simple don't allow to dumping it.

> > I rebased my nl802154 and wpan-tools stuff which I did and figured out
> > that I need to do something for making setting and dumping available.
> > I will show code when it's works.
> > 
> > If this works, then the next step would be that the cfg802154_ops
> > which have the setter/delete callbacks for security MIB settings
> > should fill then the llsec MIB.
> > 
> > I hope it's understandable what I tried to explain here and we can
> > clarify now "How to handle the storage of MIB values". What we need to
> > do for sure is the move of these datastructures into ieee802154 layer.
> 
> I'd much rather move the interface to those structures to the
> ieee802154 layer, and let the actual driver framework implement those
> interface as it wishes. Duplication will not serve us well here, just
> as it has bitten someone already in llsec_params.
> 

Okay, then we do it like the old interface. We should care about that
the security interface is not depending on transceiver setup. The
userspace interface (nl802154) to setup the security stuff should be
always the same.

Moving the "configuration" stuff into the above layer just forbid to
allow different stuff for SoftMAC/HardMAC.

I propose the following plan:

1. Make it like the old interface.

2. Then look what we can add/(moving) into the ieee802154 layer for
   create the somewhat "generic secuiryt configuration layer".


We look at the 2. thing when 1. is done. Is that the way we could go?

- Alex

[0] http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/tree/lib/rhashtable.c

Re: The 802.15.4 Security Layer

[Phoebe Buckheister]

On Tue, 23 Jun 2015 13:03:21 +0200
Alexander Aring <alex.aring@gmail.com> wrote:

> Hi,
> 
> On Mon, Jun 22, 2015 at 02:33:28PM +0200, Phoebe Buckheister wrote:
> > Hi,
> > 
> > On Sun, 21 Jun 2015 23:12:29 +0200
> > Alexander Aring <alex.aring@gmail.com> wrote:
> > 
> > > On Thu, Jun 18, 2015 at 02:31:54PM +0200, Alexander Aring wrote:
> > > […]
> > > 
> > > The big question now (for me currently):
> > > 
> > > The mac802154 security MIB storage, see [0]. Contains very
> > > performance related datastructures and I agree do doing that,
> > > because on each receiving frame we need to lookup the key by some
> > > attributes like addresses etc. The current solution for that is
> > > doing a hash and then lookup them in some hash tables. That's
> > > perfect, we currently do that also by finding the right fragment
> > > inside the 6LoWPAN fragmentation stuff.
> > 
> > The hash lookups there are not actually perfect in any sense. With
> > many security-aware nodes, the 2**6 buckets that are statically
> > configured right now may very slow down a lot due to hash
> > collisions.
> > 
> 
> ok. Maybe we should look into the rhashtable datastructure [0]. It's
> "Resizable, Scalable, Concurrent Hash Table" [0].

That's a good idea. I remember reading about those on LWN a while back,
but when I wrote the llsec code, rhashtables didn't exist yet. We
should certainly switch to those some time.

> Anyway, I am fine with the current implementation that's better than
> using list implementations, anyway. Thanks for pointing this issue of
> statically configuration. We can try to change it later, after doing
> the crypto nl802154 stuff.
> 
> > > In my opinion, this perfomance stuff should _not_ go into the
> > > wpan_dev MIB security configuration and we leave it inside the
> > > llsec implementation. Why, I think that? Because handling hashes
> > > there are too overkill for just representing the current
> > > configuration inside nl802154. Later the HardMAC drivers should
> > > not deal with hashes for just representing the current security
> > > configuration.
> > 
> > Agreed. Each driver framework (SoftMAC, HardMAC) Must be free to
> > choose its own "ideal" representation (whatever that means).
> > 
> 
> ok.
> 
> > > How we should deal with that then:
> > > 
> > > Simple using some list stuff which representing the configuration
> > > inside the MIB of wpan_dev. On the cfg802154 (setter) callbacks,
> > > we know the configuration what the wpan MIB should hold. The llsec
> > > (security related tables, the hashes) _and_ MIB wpan_dev (security
> > > related tables, simple some list stuff) should be representing the
> > > same stuff.
> > 
> > That will not be entirely possible with HardMAC, at least not
> > without some work. If a HardMAC implements llsec and you instruct
> > it to use the DEVKEY_RECORD mode, you will have to periodically
> > poll the MAC (or receive interrupts) when a new new key has been
> > recorded.The frame counters per key may also change wildly at the
> > worst possible times, so mirroring them is entirely impossible.
> > When your network has encrypted/authenticated traffic, you can at
> > best mirror an old subset of the actual state in wpan_dev without
> > generating way too much management traffic.
> > 
> 
> For your example the frame counter:
> 
> I agree this sounds crazy to always ask what's the current frame
> counter is, that's one example for a MIB attribute that we should not
> put into ieee802154 layer.

No, access to that attribute is essential. If node reboots, you
absolutely have to restore frame counters to at least their last known
value.

> What I think is to put in ieee802154 a security MIB only for
> configuration the necessary "ACL" stuff for key management.

That would be possible, but the "ACLs" are not necessarily static. Most
parts are, if you exclude frame counters from your discussion. The
remaining thing is which keys are used with which frame counters by
which device. The standard only specifies a single frame counter per
peer, which would make the configuration per device static. But we
actually support that, we support multiple counters per device with
restriction to configured keys for that device, and we support multiple
frame counters per device without restriction (allowing all keys known
to the receiving node).

Why have I implemented two unspecified modes? Because secure key
rollover with the IEEE-specified single frame counter is pretty much
impossible.

If you think ieee802154 should not support such extensions, then your
approach is entirely feasible. But access to those extensions (and the
frame counters!) must still be possible.

> These MIB security settings should the only one which are
> read/writeable from userspace over nl802154.
> 
> On userspace side there should then no difference between accessing a
> SoftMAC or HardMAC transceiver.

Ideally, yes. Different transceivers will always have different
features though, so we will need another feature negotiation mechanism
for llsec no matter what.

> > > So llsec is just simple a very performance related security layer
> > > implementation of mac802154, similar what a HardMAC driver has on
> > > the HardMAC related firmware which doing security stuff.
> > > 
> > > 
> > > The question is now: Should we go that way or really hold hashes
> > > stuff into wpan_dev?
> > > 
> > > I told that I began to programming the MIB handling stuff into
> > > nl802154 and wpan-tools. I will show later code, it's based on the
> > > idea to simple don't moving the llsec (performance datastructures)
> > > into wpan_dev MIB, instead doing list stuff there and fill the
> > > llsec MIB by the cfg802154 setters which should be the same
> > > inside the MIB wpan_dev structure.
> > 
> > That is probably not a good idea due to the variability of the
> > actual MIB at runtime. For each llsec MIB query, you might have to
> > dump a large part of the actual driver MIB to resync your lists
> > with what the driver actually knows about the network. It's not as
> > painful as it could be since you'd only have to sync in one
> > direction, but that's still one sync too many for my comfort.
> > 
> > If a HardMAC was too slow to respond to such queries in a timely
> > manner, that might be wholly different story. You can reliably
> > mirror some parts of the MIB (security levels and key descriptors),
> > but those are only a fraction of the actual MIB size.
> > 
> 
> Ok, then what's about to move the "userspace configurable" stuff to
> ieee802154?
> 
> When a set/add call was successful then simple the ieee802154 mib
> stuff will be updated. I know the "device descriptor" contains the
> frame counter stuff which is hard to sync with the above layer, but
> then simple don't allow to dumping it.

As mentioned, not dumping the frame counter is decisively not an
option. Duplicating structures also just seems like a bad idea to me,
and I would rater avoid it wherever possible.

We could just not duplicate anything for the moment, but once an actual
HardMAC transceiver comes along, add a small caching layer. Coupled
with an option to not dump frame counters and other values that change
rather quickly, that would give us the best of both worlds: no
duplication for SoftMAC, and HardMAC isn't pummeled for every single
security MIB query unless it absolutely has to be.

> > > I rebased my nl802154 and wpan-tools stuff which I did and
> > > figured out that I need to do something for making setting and
> > > dumping available. I will show code when it's works.
> > > 
> > > If this works, then the next step would be that the cfg802154_ops
> > > which have the setter/delete callbacks for security MIB settings
> > > should fill then the llsec MIB.
> > > 
> > > I hope it's understandable what I tried to explain here and we can
> > > clarify now "How to handle the storage of MIB values". What we
> > > need to do for sure is the move of these datastructures into
> > > ieee802154 layer.
> > 
> > I'd much rather move the interface to those structures to the
> > ieee802154 layer, and let the actual driver framework implement
> > those interface as it wishes. Duplication will not serve us well
> > here, just as it has bitten someone already in llsec_params.
> > 
> 
> Okay, then we do it like the old interface. We should care about that
> the security interface is not depending on transceiver setup. The
> userspace interface (nl802154) to setup the security stuff should be
> always the same.

Most agreed.

> Moving the "configuration" stuff into the above layer just forbid to
> allow different stuff for SoftMAC/HardMAC.
> 
> I propose the following plan:
> 
> 1. Make it like the old interface.
> 
> 2. Then look what we can add/(moving) into the ieee802154 layer for
>    create the somewhat "generic secuiryt configuration layer".
> 
> 
> We look at the 2. thing when 1. is done. Is that the way we could go?

We could do that, but we should always keep in mind the end goal. If
the current protocol is generic enough to allow for all kinds of
transceivers, that's certainly a good idea.

> - Alex
> 
> [0]
> http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/tree/lib/rhashtable.c

Re: The 802.15.4 Security Layer

[Simon Vincent]

Hi Alex,

Do you have your security/nl802154 work available anywhere I can have a 
look?
I am in the process of getting 802.15.4 security working on our devices. 
I don't want to implement it using the old interface as I will then have 
to recode our application when llsec moves over to nl802154.
I have some spare time at the moment to develop/review/test the security 
layer.

Simon

On 18/06/15 20:43, Stefan Schmidt wrote:
> Hello.
>
> On 18/06/15 17:58, Simon Vincent wrote:
>> Hi,
>>
>> On 18/06/15 16:42, Stefan Schmidt wrote:
>>> Hello.
>>>
>>> On 18/06/15 14:31, Alexander Aring wrote:
>>>> Hi all,
>>>>
>>>> I saw the latest discussion about the security layer and wants to 
>>>> open a
>>>> new thread about discussion for access this layer over nl802154 and
>>>> putting a "very easy to use" functionality into iwpan.
>>>>
>>>> I need to admit, I never tested myself this layer, also I told many
>>>> times that the step to put security layer functionality into 
>>>> nl802154 is
>>>> a necessary step. For that reason I declare the security layer as 
>>>> broken.
>>>>
>>>> Several months ago I started to put these functionality into 
>>>> wpan-tools
>>>> and nl802154. It's just parsing a file at the moment and putting 
>>>> the all
>>>> relevant entries for key, device, seclevel tables in cfg802154. 
>>>> Nothing
>>>> more. These tables are handled like an ACL in 802.15.4 (so far I know)
>>>> and necessary to do the "key lookup" procedure, on receiving decrypted
>>>> frames.
>>>>
>>>> At weekend I will try to provide my stuff which I already have done 
>>>> and
>>>> will try to explain what the idea for the next necessary steps are. 
>>>> It's
>>>> just to start a discussion "How do deal with accessing llsec over
>>>> nl802154/cfg802154".
>>>>
>>>> After we can accessing the sec layer over nl802154, we can 
>>>> hopefully remove
>>>> the old interface stuff.
>>>>
>>>> Does this sounds like a plan?
>>>
>>> I think this is a good idea and I would gladly gve this some testing 
>>> next week. I bet Simon would do as well as he is currently looking 
>>> into it.
>> Yes it would nice to tidy this all up and get a stable interface. I 
>> currently have some time to look at this and do some testing.
>
> You have by any chance some small example code you used for testing 
> the llc stuff? It would be handy to start with something small and easy.
>
> regards
> Stefan Schmidt
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: The 802.15.4 Security Layer

[Simon Vincent]

Hi Alex,

You can ignore the previous email! I have just seen your email from 
Sunday explaining what you have done.
I somehow became unsubscribed from this mailing list over the weekend so 
didn't get the emails...

Simon

On 23/06/15 16:34, Simon Vincent wrote:
> Hi Alex,
>
> Do you have your security/nl802154 work available anywhere I can have 
> a look?
> I am in the process of getting 802.15.4 security working on our 
> devices. I don't want to implement it using the old interface as I 
> will then have to recode our application when llsec moves over to 
> nl802154.
> I have some spare time at the moment to develop/review/test the 
> security layer.
>
> Simon
>
> On 18/06/15 20:43, Stefan Schmidt wrote:
>> Hello.
>>
>> On 18/06/15 17:58, Simon Vincent wrote:
>>> Hi,
>>>
>>> On 18/06/15 16:42, Stefan Schmidt wrote:
>>>> Hello.
>>>>
>>>> On 18/06/15 14:31, Alexander Aring wrote:
>>>>> Hi all,
>>>>>
>>>>> I saw the latest discussion about the security layer and wants to 
>>>>> open a
>>>>> new thread about discussion for access this layer over nl802154 and
>>>>> putting a "very easy to use" functionality into iwpan.
>>>>>
>>>>> I need to admit, I never tested myself this layer, also I told many
>>>>> times that the step to put security layer functionality into 
>>>>> nl802154 is
>>>>> a necessary step. For that reason I declare the security layer as 
>>>>> broken.
>>>>>
>>>>> Several months ago I started to put these functionality into 
>>>>> wpan-tools
>>>>> and nl802154. It's just parsing a file at the moment and putting 
>>>>> the all
>>>>> relevant entries for key, device, seclevel tables in cfg802154. 
>>>>> Nothing
>>>>> more. These tables are handled like an ACL in 802.15.4 (so far I 
>>>>> know)
>>>>> and necessary to do the "key lookup" procedure, on receiving 
>>>>> decrypted
>>>>> frames.
>>>>>
>>>>> At weekend I will try to provide my stuff which I already have 
>>>>> done and
>>>>> will try to explain what the idea for the next necessary steps 
>>>>> are. It's
>>>>> just to start a discussion "How do deal with accessing llsec over
>>>>> nl802154/cfg802154".
>>>>>
>>>>> After we can accessing the sec layer over nl802154, we can 
>>>>> hopefully remove
>>>>> the old interface stuff.
>>>>>
>>>>> Does this sounds like a plan?
>>>>
>>>> I think this is a good idea and I would gladly gve this some 
>>>> testing next week. I bet Simon would do as well as he is currently 
>>>> looking into it.
>>> Yes it would nice to tidy this all up and get a stable interface. I 
>>> currently have some time to look at this and do some testing.
>>
>> You have by any chance some small example code you used for testing 
>> the llc stuff? It would be handy to start with something small and easy.
>>
>> regards
>> Stefan Schmidt
>>
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>

Re: The 802.15.4 Security Layer

[Alexander Aring]

Hi,

On Tue, Jun 23, 2015 at 04:34:42PM +0100, Simon Vincent wrote:
> Hi Alex,
> 
> Do you have your security/nl802154 work available anywhere I can have a
> look?
> I am in the process of getting 802.15.4 security working on our devices. I
> don't want to implement it using the old interface as I will then have to
> recode our application when llsec moves over to nl802154.

I think what we do at first is a 1:1 implementation of the old interface
and the new interface and then look what we can change afterwards if
needed.

We introduce then some CONFIG_NL802154_EXPERIMENTAL to change the enum
definition (with security and without). I think then we are somehow
safe to still change the netlink interface, inside kernelspace, afterwards.

> I have some spare time at the moment to develop/review/test the security
> layer.
> 

Too bad I have at the moment really nothing which you can test/review
maybe we can do some split working of development tasks, but I don't have
the overview at the moment to split anything.

For general I would say somebody can do the userspace side and another one
can do the kernelspace side. At the end we trying to fit anything together.

For me it's _very_ important that the userspace side should not have
some big mechanism to setup the kernelspace stuff. We should provide
some config file to setup the most part, instead doing iwpan calls over
command line.

Phoebe also reported that we need to save the current dump of the whole
security information in case of a reboot and restore them afterwards
again. (e.g. the frame counter attribute). This all smells more like a
daemon which running in the background and deals with some configfiles
and states (dumping security tables in case of reboot).

- Alex

Re: The 802.15.4 Security Layer

[Alexander Aring]

On Wed, Jun 24, 2015 at 12:00:14PM +0200, Alexander Aring wrote:
> Hi,
> 
> On Tue, Jun 23, 2015 at 04:34:42PM +0100, Simon Vincent wrote:
> > Hi Alex,
> > 
> > Do you have your security/nl802154 work available anywhere I can have a
> > look?
> > I am in the process of getting 802.15.4 security working on our devices. I
> > don't want to implement it using the old interface as I will then have to
> > recode our application when llsec moves over to nl802154.
> 
> I think what we do at first is a 1:1 implementation of the old interface
> and the new interface and then look what we can change afterwards if
> needed.
> 
> We introduce then some CONFIG_NL802154_EXPERIMENTAL to change the enum
> definition (with security and without). I think then we are somehow
> safe to still change the netlink interface, inside kernelspace, afterwards.
> 

What I meant here is something like [0]. We simple let the config add
the end of all declaration, if we add something to mainline then we put
it out of the #ifdef foo. (Above the comments) If we do that then the
CONFIG_NL802154_EXPERIMENTAL will be broken afterwards and the userspace
tool need to be updated. Without CONFIG_NL802154_EXPERIMENTAL it should
always be the same. Just the NL802154_CMD_MAX and NL802154_ATTR_MAX
will be a lesser value than without CONFIG_NL802154_EXPERIMENTAL. The
internal nl802154 framework should not react on these definitions then,
if somebody tries to use CMD's/ATTR's which are inside
CONFIG_NL802154_EXPERIMENTAL.


With CONFIG_NL802154_EXPERIMENTAL then the user need to care about to user
the right userspace nl802154 header in their application.

- Alex

[0] https://github.com/linux-wpan/linux-wpan-next/commit/4522252b9964227d1a3ce0b09c1aa0a6d95c3ba1

Re: The 802.15.4 Security Layer

[Simon Vincent]

Ok yes this makes sense.

Let me know if there is any bits I can help on.

Simon

On 24/06/15 15:01, Alexander Aring wrote:
> On Wed, Jun 24, 2015 at 12:00:14PM +0200, Alexander Aring wrote:
>> Hi,
>>
>> On Tue, Jun 23, 2015 at 04:34:42PM +0100, Simon Vincent wrote:
>>> Hi Alex,
>>>
>>> Do you have your security/nl802154 work available anywhere I can have a
>>> look?
>>> I am in the process of getting 802.15.4 security working on our devices. I
>>> don't want to implement it using the old interface as I will then have to
>>> recode our application when llsec moves over to nl802154.
>> I think what we do at first is a 1:1 implementation of the old interface
>> and the new interface and then look what we can change afterwards if
>> needed.
>>
>> We introduce then some CONFIG_NL802154_EXPERIMENTAL to change the enum
>> definition (with security and without). I think then we are somehow
>> safe to still change the netlink interface, inside kernelspace, afterwards.
>>
> What I meant here is something like [0]. We simple let the config add
> the end of all declaration, if we add something to mainline then we put
> it out of the #ifdef foo. (Above the comments) If we do that then the
> CONFIG_NL802154_EXPERIMENTAL will be broken afterwards and the userspace
> tool need to be updated. Without CONFIG_NL802154_EXPERIMENTAL it should
> always be the same. Just the NL802154_CMD_MAX and NL802154_ATTR_MAX
> will be a lesser value than without CONFIG_NL802154_EXPERIMENTAL. The
> internal nl802154 framework should not react on these definitions then,
> if somebody tries to use CMD's/ATTR's which are inside
> CONFIG_NL802154_EXPERIMENTAL.
>
>
> With CONFIG_NL802154_EXPERIMENTAL then the user need to care about to user
> the right userspace nl802154 header in their application.
>
> - Alex
>
> [0] https://github.com/linux-wpan/linux-wpan-next/commit/4522252b9964227d1a3ce0b09c1aa0a6d95c3ba1

Re: The 802.15.4 Security Layer

[Alexander Aring]

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.

- Alex

[0] https://github.com/linux-wpan/linux-wpan-next/tree/nl802154_llsec

Re: The 802.15.4 Security Layer

[Stefan Schmidt]

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.

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.

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.

regards
Stefan Schmidt

Re: The 802.15.4 Security Layer

[Alexander Aring]

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

Re: The 802.15.4 Security Layer

[Stefan Schmidt]

Hello.

On 26/06/15 11:58, Alexander Aring wrote:
> 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.
>

Thanks for clarifying this. I understood it differently. Having the 
safe/restore way at fist only make sebse and is totally fine with me. I 
just thought it was the only planned way.

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

Not sure I get what you mean here. Maybe we should start with what data 
we want to store and what inter deps they have.

The ini format is pretty simple. Basically categories and key value 
pairs. If we want more we might need something else.

regards
Stefan Schmidt

Re: The 802.15.4 Security Layer

[Alexander Aring]

On Fri, Jun 26, 2015 at 12:14:29PM +0200, Stefan Schmidt wrote:
...
> 
> Not sure I get what you mean here. Maybe we should start with what data we
> want to store and what inter deps they have.
> 

ehm yes, maybe we should start with that. :-)

- Alex

> The ini format is pretty simple. Basically categories and key value pairs.
> If we want more we might need something else.
> 

ok. Sounds good.

- Alex

Re: The 802.15.4 Security Layer

[Alexander Aring]

status update:

Phoebe meant do 1:1 what iptables does, this means:

1. Implement all interface cmds to iwpan.
2. The config file are only per line separated arguments of iwpan.
3. we implement a store/restore for that fileformat.

Okay this is much easier to implement and we should do that for the
first. I think that the order is important for setup such setting, so we
have internal dependencies which need to be setup at first. Then we need
to care about that.

At first a new file format is not necessary, later we can think about to
introduce such file format _maybe_ for a better handling.

This is just "Keep it simple and stupid" and (short, safe, whatever).

- Alex