Brian E Carpenter <[email protected]> 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.
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.
>> 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.
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.
--
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
