On 20/10/2016 14:58, Michael Richardson wrote:
>
> 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.
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.
> 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.
Yes, you have topology knowledge in that case.
Brian
>
> >> 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 =-
>
>
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
