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

From: Michael Richardson <[email-masked]>
Date: Sat, 12 Nov 2016 11:52:03 +0900

Toerless Eckert <[email-masked]> wrote:
    >> 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.

...

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

Cool.  I think that this is the right way.  I am just not certain that we
need a TCP reply to the M_DISCOVERY... the simple fact of receiving the
multicast M_DISCOVERY tells one about the peer.
That would be some new mode of GRASP, I think though.

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

Ditto.

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

It wasn't so much that I want to avoid the "LL" multicast, so much as that
it's kinda redundant, as the ACP is a p2p system.  Both ends know where the
other end is, might as well just leave a TCP connection up between them.
It's basically the same as a BGP4 in many ways...

    BC> Given how ACP interfaces are p2p secured interfaces to neigbhors, you
    BC>     could know upfront the LL IPv6 address of the neighbor on the
    BC> interface, but there is really no framework in IETF protocols that
    BC> leverages this optimization for p2p links, so i don't think we should
    BC> bother doing it.  Its work without RoI.

I see it as simplying myself.

    >     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

Agreed.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Nov 2016 16:17:05 +1300

> It's basically the same as a BGP4 in many ways...

I don't care how it's implemented inside the ACP. The GRASP engine has to
send its discovery and floood messages to all on-link neighbours, and no off-link
neighbours, so it needs to *look like* a LL multicast socket, whatever the ACP VRF
does internally.

>     BC> bother doing it.  Its work without RoI.

That wasn't BC.

>     > vector. And typical socket software code is usually victim to

Sure. Who ever suggested that?

   Brian