Subject: Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?)

From: Toerless Eckert <[email-masked]>
Date: Mon, 31 Oct 2016 23:18:55 +0100

On Mon, Oct 31, 2016 at 01:23:36PM +1300, Brian E Carpenter wrote:
> > I am confused about the reason for this discussion. It seems you are trying
> > to figure out how to minimize the impact of the insecure multicast piece of GRASP,
> > but in the context of ANIMA this question would be irrelevant, because we are
> > not doing any insecure GRASP in BRSKY or ACP with current draft - the use of
> > insecure GRASP was removed in those drafts before Berlin because of the majority
> > of the bootstrap teams choice for DNS-SD/mDNS. 
> 
> Which, I have to point out, is not a consensus position; design teams propose,
> they don't decide. I'm waiting to see the next draft before I raise this issue on
> the WG list.

Right. I guess we've now posted all drafts we can before the deadline, so
let me change this mail threads subject to get the discussion started.

Current state:

a) The bootstrap design team mayority did conclude that mDNS is the best option
   for discovery of bootstrap proxy by the pledge (link-local). I'll still have
   to read in more detail through the document to see how well the text discusses
   all the reasons why.

b) I have just posted ACP draft -04 in which i have reversed the choice of mDNS for
   ACP discovery by neighbors from the -03 text which had mDNS. So -04 defines to
   use (DULL) GRASP for ACP discovery with more details.
   
   I had put mDNS into -03 because of my thinking that all the reasons that that bootstrap
   had for mDNS would a) also apply to ACP discovery, and that b) it would make life easier
   to have fewer discovery protocols. a) was not well thought through on my side.

   Pls check out the text on discover in -04, i hope it justifies use of GRASP
   for neighbor discovery.
   
> > When GRASP is run securely in its two forms for the ACP, it is always protected/
> > encrypted by the ACP, so i think your security concern would then not be valid.
> 
> I'm still waiting to see a clear explanation of how the ACP will secure
> LL multicast, however.

I am not sure i understand the documentation ask. The ACP has a bunch of (virtual) interfaces. In
the most simple implementation option, each ACP channel to an ACP neighbor is its own
(p2p) L3 interface in the ACP. And thats all the interfaces the ACP has.

All packets, unicast or multicast that are sent into or 
received from those interfaces are protected/encrypted by the fact that they are transmitted
encrypted by the seleted ACP channel encryption protocol.

> > Do you see some IoT context where you would use insecure GRASP instead of DNS-SD/mDNS,
> > eg: in some IoT context ?
> 
> Michael can answer that for himself, but the reason we noted the *possibility*
> of doing this in grasp-08 is because it seems clearly harmless. So from the
> GRASP spec point of view, I consider the issue closed.

Ues, i am mostly interested in use-case explanations Michael has in mind.

The other piece was that Michael was trying to figure out how to avoid using LL multicast
and instead use unicast:

 -> Within the ACP this question is somewhat irrelevant because its secured.

 -> Given how ACP interfaces are p2p secured interfaces to neigbhors, you
    could know upfront the LL IPv6 address of the neighbor on the interface,
    but there is really no framework in IETF protocols that leverages this
    optimization for p2p links, so i don't think we should bother doing it.
    Its work without RoI.
 
 -> Outside the ACP i am not sure about the use-case. To be options proof: GRASP
    should permit sending and receiving of LL UNICAST instead of LL multicast for
    those messages where GRASP specifies LL multicast, so that if some deployment
    figures out that there is some optimization possible with the use of LL unicast, 
    then it can simply do that instead of asking for a GRASP spec modification.

    The big security risk though is GLOBAL UNICAST MUST NOT BE PERMITTED 
    as a replacement for LL multicast. Thats an attack vector. And typical
    socket software code is usually victim to that. Aka: you open a socket,
    you bind it to a link-local multicast group and you go away. Alas: this
    socket will receive not only link-local multicast, but also LL unicast (good)
    and global unicast (bad). So the application code usually would need to check
    the destination address the packet was sent to and drop those packets 
    sent to the global unicast address - if the protocol was really only
    designed for LL multicast - and therefore assuming security properties
    of LL multicast (logical vicinity of sender).

    A good exampe for replacing multicast with unicast is WiFI where luckily
    hosts do accept multicast packets as L2 unicast instead of L2 multicast.
    And thats done to get the benefit of L2 retransmissions, that do not exist
    for L2 multicast.

Cheers
    Toerless

> 
> Regards,
>      Brian
> 
> > Cheers
> >     Toerless
> > 
> > On Sat, Oct 22, 2016 at 03:37:56PM -0400, Michael Richardson wrote:
> >>
> >> Brian E Carpenter <[email-masked]> wrote:
> >>     > On 21/10/2016 01:56, Michael Richardson wrote:
> >>     >>
> >>     >> Brian E Carpenter <[email-masked]> wrote:
> >>     >> >> What I was saying was, *IF* I know how to find a machine with an open
> >>     >> >> GRASP_LISTEN_PORT, and I connect to it, and unicast a DISCOVERY, that
> >>     >> >> I should receive my answer on that connection.
> >>     >>
> >>     >> > A says discover("B") to C, but C doesn't know where B is. So there will
> >>     >> > be no answer, unless C does extra stuff.
> >>     >>
> >>     >> So, C would forward the discover("B"), and then when it gets to B,
> >>     >> it would connect directly to A, and introduce itself?  This is obvious now
> >>     >> that you give this example, but not from the document.  I might also think
> >>     >> that B would connect to C, and then C would tell A.
> >>
> >>     > But it couldn't do that unless it had already discovered C previously, in which
> >>     > case it could simply reply to A with its cached locator for C.
> >>
> >>     >> This clearly fails if A has a LL address only.
> >>
> >>     > Yes, but that's why we have discovery relaying.
> >>
> >> Still, I'm more confused now.
> >>
> >> When A has a LL only, we would have to have, not only discovery relaying, but
> >> also response forwarding.   So does B reply to C (to be relayed to A), or is
> >> it a fail as B tries to connect to A's LL address, and does not connect?
> >>
> >>
> >>     >> >> In the 6tisch case doing multicast is either expensive or unsupported.
> >>     >> >> On the other hand, we can quite easily declare that the 6LBR /
> >>     >> >> DODAG-root (the router at the top of the tree) will have
> >>     >> >> GRASP_LISTEN_PORT open.
> >>     >>
> >>     >> > Yes, you have topology knowledge in that case.
> >>     >>
> >>     >> Do you agree that a discovery("C") sent to C over TCP should be answered
> >>     >> over that TCP connection?
> >>
> >>     > Oh yes, and that is what should happen under the covers in any case, if discovery
> >>     > is running over the ACP.
> >>
> >>     > However, I'm not convinced that we should document this (unicast discovery).
> >>     > At least not yet.
> >>
> >> When?  I feel that this is important behaviour that needs to be defined for
> >> the GRASP core system.
> >>
> >>
> >> --
> >> Michael Richardson <[email-masked]>, Sandelman Software Works
> >>  -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 1 Nov 2016 13:59:17 +1300

Hi Toerless,
>    to read in more detail through the document to see how well the text discusses

I responded to that under a different subject header.

>    Pls check out the text on discover in -04, i hope it justifies use of GRASP

I will read that carefully, but for me that doesn't need justification, because
we need the ANI to be self-contained, so depending on mDNS seems wrong. (In
fact, why wouldn't configuring mDNS/DNS-SD/DNS be an autonomic function itself?)

> (p2p) L3 interface in the ACP. And thats all the interfaces the ACP has.

And that's the problem. GRASP discovery and flooding need sockets that
supports link-local multicast sending and receiving for each physical
interface.

Currently the GRASP code finds out how many physical interfaces it has
and for each one creates a multicast sending socket. It also has a socket
that listens for incoming link-local multicasts on all physical interfaces.
I don't see how to do that using the ACP interfaces that you describe.

> encrypted by the seleted ACP channel encryption protocol.

Yes, and I'd like the LL multicast traffic to be protected too.
But as far as I can see that needs explicit support in the ACP
to emulate LL multicast sockets. The ideal would be that the ACP
simply emulates LL interfaces, so that GRASP could treat them exactly
like physical interfaces.

If you want, I can point you the exact Python code that handles this
in the prototype.

>     then it can simply do that instead of asking for a GRASP spec modification.

Sure. That was my conclusion (for discovery; it makes no sense for flooding).

>     of LL multicast (logical vicinity of sender).

GRASP discovery and flood are specified as link-local, so yes, that check
is needed.

>     And thats done to get the benefit of L2 retransmissions, that do not exist

Ack.
   Brian