Subject: Re: [Anima-bootstrap] Anima bootstrap: discover protocol multicast notes

From: Michael Richardson <[email-masked]>
Date: Sun, 12 Feb 2017 16:58:49 -0500

Toerless Eckert <[email-masked]> wrote:

    > Oh, and just read mDNS RFC and found the place where it prohibits
    > periodic unsolicited announcements, so added that at the end.

    > Michael: Would be great if you
    > can figure out what you see in your network. Worst case we'll have
    > to ask Stewart...

I haven't had time to do this.
I wonder if Peter van der Stok can help here?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Sun, 12 Feb 2017 17:02:49 -0500

Brian E Carpenter <[email-masked]> wrote:
    >> This information is typically ignored in existing network protocol
    >> stacks
    >> and is also typically unavailable on the socket-API. This IMHO makes
    >> it highly beneficial to
    >> use a very lightweight protocol (like the subset of GRASP dedicate to
    >> this) that can specifically
    >> be implemented to do this security check.

    > Presumably you have to use a raw socket. I don't see any other way to get the
    > destination address out of the packet.

With recvmsg(), you can can as for IPV6_RECVPKTINFO in the auxiliary
messages in IPV6_PKTINFO.  You get the destination IPv6 address as well as
the ifindex.  (ifindex is pretty essential if you are receiving multicast messages)

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Feb 2017 11:20:44 +1300

> the ifindex.  (ifindex is pretty essential if you are receiving multicast messages)

Yes, for multicast I now see that I do pick up the destination address and ifindex
from recvfrom(). I haven't needed to look at that code for many months. For TCP
I seem to pick it up from accept().

     Brian

---

From: peter van der Stok <[email-masked]>
Date: Mon, 13 Feb 2017 09:56:48 +0100

Hi all,

We just did our own mDNS (students did years ago) and have no experience 
with existing code.
What was the precise question?

Peter

Michael Richardson schreef op 2017-02-12 22:58:
> _______________________________________________
> Anima-bootstrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap

---

From: Michael Richardson <[email-masked]>
Date: Tue, 14 Feb 2017 13:13:07 -0500

peter van der Stok <[email-masked]> wrote:
    > We just did our own mDNS (students did years ago) and have no
    > experience with
    > existing code.

It's a good question. What *IS* the question :-)

We have had the discussion about use of GRASP M_FLOOD vs mDNS for discovery
of the Join Proxy by the pledge.   We have had some indirect feedback
("heresay") from implementers to the effect thta the M_FLOOD stuff
"is IETF ivory tower nonsense, and we should stop inventing new vanity
protocols."

(paraphrased, and unattributed.  Sorry Brian: not my words, and I'm relaying
them third or fourth-hand, and I sure wish that said people would communicate
directly, but I think corporate reporting structures get in the way of some
of that)

There are some esthetic reasons to prefer use of M_FLOOD. This has to do with
ANIMA being a self-contained system.

There is also a claim that mDNS is already present in many small
devices. RFC6763 even says that some ethernet chips can autonomously answer
mDNS queries when the device in question is in low-power mode!

But there are some real technical claims about why mDNS does not suit:

The specific claim is that we can't do unsolicited announcements using
mDNS.  https://tools.ietf.org/html/rfc6762#section-8, section 8.2 says:

   A Multicast DNS responder MUST NOT send announcements in the absence
   of information that its network connectivity may have changed in some
   relevant way.  In particular, a Multicast DNS responder MUST NOT send
   regular periodic announcements as a matter of course.

The rfc6763 DNS-SD process makes it pretty clear that discovery involves a
query and a reply, and that responses may be multicast such that they are
easily cached.  6762 says a lot about TTL and how often things are cached.

I myself do not quite understand the entire interaction.  I observe that
on networks I am part of that, my mDNS daemon (avahi), always has a list of
seldom (even never!) used services in it's cache.

For instance:
knothole-[~](2.1.5) mcr 10002 %avahi-browse -vat | wc -l
174

knothole-[~](2.1.5) mcr 10003 %avahi-browse -vat | grep -i Mumble
+ credil IPv6 lapeche                      Mumble Server local
+ credil IPv4 lapeche                      Mumble Server local

I'm sure that NOBODY has ever asked the network if there was a Mumble
server around.  Clearly, when it first started, it had a reason to announce
itself, but that value should have a TTL that after the several hundred days
of uptime for the "lapeche" machine must have expired.  So I'm unclear how
reconcile what I read in the specifications ("MUST NOT send regular priodic
announcements") with what I see in practice.

It might be that in the end we don't care about the anonimity of the pledge.
If the pledge can ask the network about Join Proxy, then there is nothing
to stop us from using mDNS here.

On the other hand, M_FLOOD is as certainly useable, and is rather simple.
I had very little problem implementing it myself.  I also think that every
Join Proxy is also an ACP node, and so it will want to M_FLOOD about it's
ACPness, and so I see little downside here.

I do not have horse in this race:  I just don't want to be ignored by
developers... who granted, have not come to this conversation.

(I hear lots of anti-IETF rhetoric from Linux kernel developers, most of whom
have never posted any question to an IETF list, ever!)

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Feb 2017 08:40:32 +1300

> directly, but I think corporate reporting structures get in the way of some

Can't hear them due to fingers stuck in ears :-)

Seriously - why do you think I invested considerable personal time in
a prototype? Because I was afraid that we were designing something unrealistic.
But we're not, and I've never found a way that mDNS or DNS-SD could do what
we want.

> seldom (even never!) used services in it's cache.

Yes, the GRASP model will cache too of course, but non-relay nodes
will only cache (a) what they discovered personally and (b) whatever
was flooded. They will not cache the results of 3rd party discoveries.

Anyway, the GRASP model doesn't just support services. Objectives aren't
services, although they could represent services.

And once again: outside the ACP, there is no need to force GRASP
into every pledge. I would expect COAP or mDNS to be the way a
non-autonomic pledge finds its nearest proxy.

> I had very little problem implementing it myself.

Got any code I could run (on Linux)? At least I could check if my GRASP
can receive those floods correctly. No need to wait for Chicago.

> I also think that every

Running code is the best answer to that.

> have never posted any question to an IETF list, ever!)

Want to hear some anti-Linux-kernel-developer rhetoric? :-)

But actually, do we care? We don't need anything new in the kernel
to make GRASP/ACP work, I don't think. And do we need anything
for BRSKI?

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 14 Feb 2017 17:32:06 -0500

Brian E Carpenter <[email-masked]> wrote:
    >> On the other hand, M_FLOOD is as certainly useable, and is rather
    >> simple.  I had very little problem implementing it myself.

    > can receive those floods correctly. No need to wait for Chicago.

Actually, I lied. I have M_DISCOVERY/M_RESPONSE code in C and Ruby,
but it's supposed to be replaced with M_FLOOD.  I will point to it as soon as
possible.

---

From: peter van der Stok <[email-masked]>
Date: Wed, 15 Feb 2017 10:06:07 +0100

Hi Michael,

I saw Brian's response.
Just a four additional remarks by me, just to show my point of view.
See below.

> mDNS queries when the device in question is in low-power mode!

<pvds>
As said before, discovery is a "popular" subject with everybody coming 
up with its preferred solution.

I can imagine that within the anima context specific discovery functions 
are wanted or omitted;I have no opinion.
However, the bootstrapping process is an interesting one and deserves 
attention outside anima.
For those other operational environments, different discovery functions 
may be used.
I like to point out mDNS due to its long-standing existence.
If bootstrapping is taken over by other SDOs, I expect them to often 
choose something different from GRASP or mDNS. (fact of life).
</pvds>
>    regular periodic announcements as a matter of course.
<pvds>
The beginning of section 8 says:
"
    Whenever a Multicast DNS responder starts up, wakes up from sleep,
    receives an indication of a network interface "Link Change" event, or
    has any other reason to believe that its network connectivity may
    have changed in some relevant way, it MUST perform the two startup
    steps below: Probing (Section 8.1) and Announcing (Section 8.3).
"
Much of the text of rfc6762 is about suppressing superfluous traffic.
The method relies on repetitive querying and reactive responding, with a 
response at responder re-activation (see above).
There is a lot of operational experience here, and deserves attention.
</pvds>
> It might be that in the end we don't care about the anonimity of the 
<pvds>
Did we? IMO, almost impossible in an unsecured bootstrapping network.
Once keys are distributed, pledge looses it identity and starts afresh 
(I reckoned)
</pvds>
> to stop us from using mDNS here.
<pvds>
Or anything else dependent on the operational environment of the SDO 
using the bootstrapping protocol.
</pvds>
> simple.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Feb 2017 10:59:34 -0500

peter van der Stok <[email-masked]> wrote:
    > discovery functions may be used.  I like to point out mDNS due to its
    > long-standing existence.

okay.  I also prefer not to re-invent everything.

    > <pvds> The beginning of section 8 says: " Whenever a Multicast DNS
    > responder starts up, wakes up from sleep, receives an indication of a
    > network interface "Link Change" event, or has any other reason to
    > believe that its network connectivity may have changed in some
    > relevant way, it MUST perform the two startup steps below: Probing
    > (Section 8.1) and Announcing (Section 8.3).  " Much of the text of

Yes, that's the case on the first interval.  Once it's none that, it's not
supposed to be proactively announce itself again, from what I understand.
It's a service, so it doesn't to defend it's name.

    > rfc6762 is about suppressing superfluous traffic.  The method relies
    > on repetitive querying and reactive responding, with a response at
    > responder re-activation (see above).  There is a lot of operational
    > experience here, and deserves attention.  </pvds>

Okay, but would this be a valid implementation:
      unsigned char stuff[]={ 0x01,0x02, /* encoded DNS-SD reply */
      while(true) {
                  sleep(60);
                  sendmsg(stuff, multicast-address, port-5353);
      }

?

    > <pvds> Did we? IMO, almost impossible in an unsecured bootstrapping
    > network.  Once keys are distributed, pledge looses it identity and
    > starts afresh (I reckoned) </pvds>

Okay, *DO YOU* care about anonimity of the pledge?
Do *YOU* care if the pledge must solicit a Join Proxy by multicasting a query?

    >> If the pledge can ask the network about Join Proxy, then there is
    >> nothing to stop us from using mDNS here.

    > <pvds> Or anything else dependent on the operational environment of
    > the SDO using the bootstrapping protocol.  </pvds>

Agreed.
What would you like to chose here?  Tell us your opinion.
Don't be shy.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Feb 2017 13:57:02 +1300

> okay.  I also prefer not to re-invent everything.

To repeat myself: we have always expected that non-autonomic pledges
would *not* use GRASP to discover their join assistant. A join assistant
would support multiple discovery methods if necessary.

Nothing prevents a tiny subset of GRASP running in a non-autonomic
pledge, just for the purpose of receiving M_FLOODs. But we have no
particular reason to push for that.

    Brian

---

From: peter van der Stok <[email-masked]>
Date: Thu, 16 Feb 2017 09:36:19 +0100

> would support multiple discovery methods if necessary.

GREAT, I had not understood that that is the consensus; and of course I 
agree.
My be put text like that in the intro of keyinfra?

Peter

---

From: peter van der Stok <[email-masked]>
Date: Thu, 16 Feb 2017 09:49:42 +0100

>                   sendmsg(stuff, multicast-address, port-5353);
This looks like a caricature of the mDNS text regarding the sleep.
I don't think the text is intended for lots of sleepy sensors.
 From an inter-operability point of view it looks OK.  One can argue 
about the load generated on the network.
> ?
> 
>     >> It might be that in the end we don't care about the anonimity of 
> the
>     >> pledge.
> 
*I* don't. preferably link-local though.
> What would you like to chose here?  Tell us your opinion.
personally I would use CoAP discovery; we talk about CoAP here.
And specify a join-proxy resource-type in the coap registry.
> Don't be shy.
Try to be bold.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 16 Feb 2017 09:29:11 -0500

peter van der Stok <[email-masked]> wrote:
    >> Okay, *DO YOU* care about anonimity of the pledge?  Do *YOU* care if
    >> the pledge must solicit a Join Proxy by multicasting a query?

    > *I* don't. preferably link-local though.

okay.

    >> Agreed.  What would you like to chose here?  Tell us your opinion.

    > personally I would use CoAP discovery; we talk about CoAP here.  And
    > specify a join-proxy resource-type in the coap registry.

I'm not sure what is CoAP discovery... tell me about it!

And we are talking about non-802.15.4 (like) networks, because I think 15.4
networks can be handled differently.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: peter van der Stok <[email-masked]>
Date: Thu, 16 Feb 2017 16:14:44 +0100

> And

Below the text to appear in the est-coaps draft.
I hope it is clear; otherwise I can send text from the resource 
directory draft where the subject is more exhaustively treated.
_________________________________________________________________
The presence and location of (path to) the EST-coaps resources are
    discovered by multicasting a GET request to "/.well-known/core" 
including
    a resource type (RT) parameter with the value "core.est" [RFC6690].
    Upon success, the return payload will contain the root resource of
    the EST resources.  It is up to the implementation to choose its root
    resource, but it is recommended that the value "/est" is used, where
    possible.  The example below shows the discovery of the presence and
    location of management data.

      REQ: GET /.well-known/core?rt=core.est

      RES: 2.05 Content </est>; rt="core.est"
_____________________________________________________________
cheerio,
Peter

---

From: Michael Richardson <[email-masked]>
Date: Thu, 16 Feb 2017 14:02:07 -0500

peter van der Stok <[email-masked]> wrote:
    >> And we are talking about non-802.15.4 (like) networks, because I think
    >> 15.4 networks can be handled differently.

    > Below the text to appear in the est-coaps draft.  I hope it is clear;
    > otherwise I can send text from the resource directory draft where the
    > subject is more exhaustively treated.
    > _________________________________________________________________ The
    > presence and location of (path to) the EST-coaps resources are
    > including a resource type (RT) parameter with the value "core.est"

Ah, I see.