Brian E Carpenter <[email protected]> wrote: > 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'
> 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.
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 protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
