Subject: [Anima] GRASP issue 55: Could discovery be performed over TCP?

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Oct 2016 09:02:48 +1300

55: Could discovery be performed over TCP?

Michael is concerned by the use of insecure link-local multicast.

MR: I wonder if we shouldn't just send discovery messages on
always-up TCP connections from GRASP_LISTEN_PORT<->GRASP_LISTEN_PORT.

BC: Yes, if the ACP could give me an API call for that. But at the moment
all we can rely on is standard sockets, and in the 'no ACP mode'
that's what we have anyway. I believe GRASP has to assume standard
socket calls by design; if we want to fix this it's a problem for
the ACP.

Regards
   Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Oct 2016 15:59:35 -0400

> Michael is concerned by the use of insecure link-local multicast.

No. That's not my concern, actually.

My original concern was that, when doing discovery outside of the ACP,
the client doing the discovery has to open a TCP port that anyone who can see
multicast (i.e. everyone on the link) can beat on.

If for some reason, the client already knows a GRASP speaker, it could
initiate a TCP connection to GRASP_LISTEN_PORT, and receive the answer there.

    > MR: I wonder if we shouldn't just send discovery messages on always-up
    > TCP connections from GRASP_LISTEN_PORT<->GRASP_LISTEN_PORT.

    > BC: Yes, if the ACP could give me an API call for that. But at the
    > moment all we can rely on is standard sockets, and in the 'no ACP mode'
    > socket calls by design; if we want to fix this it's a problem for the
    > ACP.

I don't understand the problem here.

The ACP essentially a VPN.  The ability to bind a socket such that it hears
only traffic from within the ACP, while not IETF/POSIX standard, is commonly
available.  (We tried in the IPSP WG to make it standard. We really tried hard)

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Oct 2016 12:42:45 +1300

> multicast (i.e. everyone on the link) can beat on.

It's true. Malicious on-link neighbors can DoS you anyway, though. I'm not
convinced there's a new risk here.

> 
> If for some reason, the client already knows a GRASP speaker,

The only way it could find the *first* one is by multicast, though.
Can't avoid that.

> it could

That relies on the peer already knowing the answer (in its own discovery cache)
or relaying the discovery message and replying later. At the moment, nothing
tells the recipient of a Discovery message to relay it to on-link neighbors.
Are you saying the if I receive a unicast Discover message, I MUST relay it
unicast to all on-link neighbors? Otherwise I don't see how this would work
at all.

> available.  (We tried in the IPSP WG to make it standard. We really tried hard)

Yes, *iff* the ACP VPN is implemented to look like an interface that supports LL
multicast. That's all I'm asking for - if that was stated in the ACP spec I'd
be quite happy.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Oct 2016 21:58:54 -0400

Brian E Carpenter <[email-masked]> wrote:

    >> Brian E Carpenter <[email-masked]> wrote: > Michael is
    >> concerned by the use of insecure link-local multicast.
    >>
    >> the client doing the discovery has to open a TCP port that anyone who
    >> can see multicast (i.e. everyone on the link) can beat on.

    > It's true. Malicious on-link neighbors can DoS you anyway, though. I'm
    > not convinced there's a new risk here.

A direct TCP connection from client to server would require that the attacker
race (or actively MITM) the process.  With the multicast followed by TCP to
client, the attacker doesn't have to be an active attacker: they just have to
see the multicast and then send traffic.

    >> it could initiate a TCP connection to GRASP_LISTEN_PORT, and receive
    >> the answer there.

    > That relies on the peer already knowing the answer (in its own
    > discovery cache) or relaying the discovery message and replying
    > later. At the moment, nothing tells the recipient of a Discovery
    > message to relay it to on-link neighbors.  Are you saying the if I
    > receive a unicast Discover message, I MUST relay it unicast to all
    > on-link neighbors? Otherwise I don't see how this would work at all.

I think I've lost too much context to answer properly to your conjecture.

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.

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.

    >> The ACP essentially a VPN.  The ability to bind a socket such that it
    >> hears only traffic from within the ACP, while not IETF/POSIX standard,
    >> is commonly available.  (We tried in the IPSP WG to make it
    >> standard. We really tried hard)

    > Yes, *iff* the ACP VPN is implemented to look like an interface that
    > supports LL multicast. That's all I'm asking for - if that was stated
    > in the ACP spec I'd be quite happy.

I don't think we have a choice. It has to look like that.
If the ACP spec doesn't say this, then it's because it's too obvious to
state, which naturally means it really really needs to be stated.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Oct 2016 15:39:55 +1300

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

> (the router at the top of the tree) will have GRASP_LISTEN_PORT open.

Yes, you have topology knowledge in that case.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Oct 2016 08:56:57 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> GRASP_LISTEN_PORT, and I connect to it, and unicast a DISCOVERY, that
    >> I should receive my answer on that connection.

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

This clearly fails if A has a LL address only.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Oct 2016 08:10:34 +1300

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

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

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Sat, 22 Oct 2016 15:37:56 -0400

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

    > However, I'm not convinced that we should document this (unicast discovery).

When?  I feel that this is important behaviour that needs to be defined for
the GRASP core system.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 23 Oct 2016 10:05:26 +1300

On 23/10/2016 08:37, Michael Richardson wrote:
> also response forwarding.

Yes. And if that isn't clear from the text, we (authors) have blown it. Let me
look...

... https://tools.ietf.org/html/draft-ietf-anima-grasp-07#page-20

"The discovery results received by the relaying device MUST in
 turn be sent as a Discovery Response message to the Discovery
 message that caused the relay action."

(which is intentionally recursive, but safe because of the loop suppression
rules.)

> So does B reply to C (to be relayed to A), or is

Well, I don't really know when I would use it, but I have no problem with adding
that an initiator MAY send unicast discovery and the recipient will respond
accordingly (i.e. treat it just the same as a multicast discovery).

    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 31 Oct 2016 00:54:24 +0100

MichaelR:

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. 

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.

Do you see some IoT context where you would use insecure GRASP instead of DNS-SD/mDNS,
eg: in some IoT context ? 

Cheers
    Toerless

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[email-masked]