On Mon, Oct 31, 2016 at 01:23:36PM +1300, Brian E Carpenter wrote:
> > 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.
Right. I guess we've now posted all drafts we can before the deadline, so
let me change this mail threads subject to get the discussion started.
Current state:
a) The bootstrap design team mayority did conclude that mDNS is the best option
for discovery of bootstrap proxy by the pledge (link-local). I'll still have
to read in more detail through the document to see how well the text
discusses
all the reasons why.
b) I have just posted ACP draft -04 in which i have reversed the choice of mDNS
for
ACP discovery by neighbors from the -03 text which had mDNS. So -04 defines
to
use (DULL) GRASP for ACP discovery with more details.
I had put mDNS into -03 because of my thinking that all the reasons that
that bootstrap
had for mDNS would a) also apply to ACP discovery, and that b) it would make
life easier
to have fewer discovery protocols. a) was not well thought through on my
side.
Pls check out the text on discover in -04, i hope it justifies use of GRASP
for neighbor discovery.
> > 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.
I am not sure i understand the documentation ask. The ACP has a bunch of
(virtual) interfaces. In
the most simple implementation option, each ACP channel to an ACP neighbor is
its own
(p2p) L3 interface in the ACP. And thats all the interfaces the ACP has.
All packets, unicast or multicast that are sent into or
received from those interfaces are protected/encrypted by the fact that they
are transmitted
encrypted by the seleted ACP channel encryption protocol.
> > 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.
Ues, i am mostly interested in use-case explanations Michael has in mind.
The other piece was that Michael was trying to figure out how to avoid using LL
multicast
and instead use unicast:
-> Within the ACP this question is somewhat irrelevant because its secured.
-> Given how ACP interfaces are p2p secured interfaces to neigbhors, you
could know upfront the LL IPv6 address of the neighbor on the interface,
but there is really no framework in IETF protocols that leverages this
optimization for p2p links, so i don't think we should bother doing it.
Its work without RoI.
-> Outside the ACP i am not sure about the use-case. To be options proof: GRASP
should permit sending and receiving of LL UNICAST instead of LL multicast
for
those messages where GRASP specifies LL multicast, so that if some
deployment
figures out that there is some optimization possible with the use of LL
unicast,
then it can simply do that instead of asking for a GRASP spec modification.
The big security risk though is GLOBAL UNICAST MUST NOT BE PERMITTED
as a replacement for LL multicast. Thats an attack vector. And typical
socket software code is usually victim to that. Aka: you open a socket,
you bind it to a link-local multicast group and you go away. Alas: this
socket will receive not only link-local multicast, but also LL unicast
(good)
and global unicast (bad). So the application code usually would need to
check
the destination address the packet was sent to and drop those packets
sent to the global unicast address - if the protocol was really only
designed for LL multicast - and therefore assuming security properties
of LL multicast (logical vicinity of sender).
A good exampe for replacing multicast with unicast is WiFI where luckily
hosts do accept multicast packets as L2 unicast instead of L2 multicast.
And thats done to get the benefit of L2 retransmissions, that do not exist
for L2 multicast.
Cheers
Toerless
>
> Regards,
> Brian
>
> > 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
