On 20/10/2016 08:59, Michael Richardson wrote: > > 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.
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 > 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. > > 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) 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 _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
