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
On Sat, Oct 22, 2016 at 03:37:56PM -0400, Michael Richardson wrote:
>
> Brian E Carpenter <brian.e.carpen...@gmail.com> wrote:
> > On 21/10/2016 01:56, Michael Richardson wrote:
> >>
> >> Brian E Carpenter <brian.e.carpen...@gmail.com> wrote:
> >> >> 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.
> >>
> >> 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.
>
> > 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.
>
> 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?
>
>
> >> >> 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.
> >>
> >> Do you agree that a discovery("C") sent to C over TCP should be
> answered
> >> 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.
>
> When? I feel that this is important behaviour that needs to be defined for
> the GRASP core system.
>
>
> --
> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
--
---
t...@cs.fau.de
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
