On Mar 8, 2019, at 7:48 AM, Juliusz Chroboczek <j...@irif.fr
<mailto:j...@irif.fr>> wrote:
>> (a) work on simple naming
>
> I think that this work should be stalled until we have an implementation
> to play with and make some in vivo experiments. (Experience shows that
> the best way to break a protocol is to give an implementation to Dave.)
We have a working dnssd discovery proxy and client. What we don’t have is
those things connected via hncpd. That is one of the things I would like to
work on at the hackathon, if there is interest.
>> (We also have a chartered work item [4] on security that has seen no
>> progress but you can comment on that as item (c) if you like;-)
>
> Some pointers for the rare people who don't spend most of their leisure
> time reading Internet-Drafts:
>
> - HNCP is based on DNCP, which includes a security mechanism designed to
> provide authenticity, integrity and confidentiality of the HNCP data:
>
> RFC 7525 Section 8
>
> I believe that this is implemented in hnetd. (Yeah, Markus and
> Stephen did some remarkable work.)
I had indeed missed this—thanks for pointing it out. However, I have no idea
how to configure it with existing software. This is also something I’d like
to work on at the hackathon: can we actually use this mechanism? Can we come
up with a way to set it up in OpenWRT that people who are not networking grad
students can deploy?
> - Babel has two security mechanisms:
>
> https://tools.ietf.org/html/draft-ietf-babel-hmac
> <https://tools.ietf.org/html/draft-ietf-babel-hmac>
> https://tools.ietf.org/html/draft-ietf-babel-dtls
> <https://tools.ietf.org/html/draft-ietf-babel-dtls>
>
> There appear to be no standards-track key distribution and rotation
> protocols for either of OSPF, IS-IS, BGP or BFD (static keying seems
> to be the norm), so a natural question is whether HNCP could serve
> this purpose, or whether it would be better to use a dedicated key
> distribution and rotation mechanism.
>
> - RFC 3971 Section 6 says the following:
>
> To protect Router Discovery, SEND requires that routers be
> authorized to act as routers. This authorization is provisioned in
> both routers and hosts.
>
> Since hosts don't participate in HNCP, it is not clear if HNCP can be
> used as a SEND trust anchor. I believe there's the same issue with
> securing access the DNS stub resolver (DNSCrypt, DNS over TLS, etc.).
HNCP can’t be used by hosts to establish trust, as currently specified. We
don’t really have an answer to the host enrollment problem at present,
unfortunately.
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
