On 31/10/2016 13:03, Toerless Eckert wrote:
> 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.
Which, I have to point out, is not a consensus position; design teams propose,
they don't decide. I'm waiting to see the next draft before I raise this issue
on
the WG list.
> 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.
I'm still waiting to see a clear explanation of how the ACP will secure
LL multicast, however.
> Do you see some IoT context where you would use insecure GRASP instead of
> DNS-SD/mDNS,
> eg: in some IoT context ?
Michael can answer that for himself, but the reason we noted the *possibility*
of doing this in grasp-08 is because it seems clearly harmless. So from the
GRASP spec point of view, I consider the issue closed.
Regards,
Brian
> Cheers
> Toerless
>
> On Sat, Oct 22, 2016 at 03:37:56PM -0400, Michael Richardson wrote:
>>
>> Brian E Carpenter <[email protected]> wrote:
>> > On 21/10/2016 01:56, Michael Richardson wrote:
>> >>
>> >> Brian E Carpenter <[email protected]> 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 <[email protected]>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>>
>>
>>
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
