Re: [homenet] Securing HNCP - comments?

[Michael Richardson <[e-mail]>]

Juliusz Chroboczek <[e-mail]> wrote:
    >> just use e.g. IPsec with manual keying

    > Vulnerable to replay if done naively.  Not sure about the configuration
    > protocol, but definitely an issue for a routing protocol -- just capture
    > a default route announcement with a low metric, and you've won.

If one goes with 64-bit replay counters, and enable the replay protection,
and we have a relatively low data rate, we can get some protection, but we
have to plan that we eventually rekey.

    >> [S4-3] HNCP-level PSK shared among all routers. Same bootstrap issues as
    >> [S4-2], may be able to get rid of manually keyed IPsec dependency.

    > It appears that you are only looking at hop-to-hop security.

    > I'm speaking off the top of my head here, so I'm probably saying something
    > stupid.  What about end-to-end solutions, where only routers with
    > a trusted key can originate configuration information?  This could perhaps
    > be combined with a leap-of-faith model (a la ssh).

Yes, it's a very good idea, if you use authentication mode only.

There are two points:
      1) 4301 and previous did not say what to do with an AH header with an
      unrecognized SPI.  This is why SEND doesn't use it.
      If we can say that the correct answer is to skip the AH, and pretend
      it wasn't there at all, then new routers can join as leafs, insecurely,
      and then join the group (symmetric) key.

      2) and/or we can define an assymetric method for AH.

    >> Looking at Babel, the routing protocol spec is 45 pages, and draft
    >> specification of HMAC security scheme for it is 55 pages.

    > Yeah, wouldn't it be nice if we had a common layer 3 security protocol?
    > (We would make sure that it's actually usable before standardisation, of
    > course.)

I think that we could use IPsec, and yes, even manually keyed, and maybe even
insist on sane definition of unknown AH SPI, given that the set of devices
that we are dealing with does not need to interop with anything already
deployed, and that these are custom function devices.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-