In line... On 02/11/2016 11:42, Max Pritikin (pritikin) wrote: > >> On Oct 31, 2016, at 6:59 PM, Brian E Carpenter <[email protected]> >> wrote: >> >> Hi Toerless, >> On 01/11/2016 11:18, Toerless Eckert wrote: >>> 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. >> >> I responded to that under a different subject header. >> >>> >>> 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. >> >> I will read that carefully, but for me that doesn't need justification, >> because >> we need the ANI to be self-contained, so depending on mDNS seems wrong. (In >> fact, why wouldn't configuring mDNS/DNS-SD/DNS be an autonomic function >> itself?) > > Taken to the extreme one could argue that we need ANI to be self-contined so > depending on IP seems wrong. There is a point where ANI needs to depend and > integrate with existing systems. > > My position is that the demarcation point is bootstrapping of the keying > infrastructure. Prior to bootstrapping we depend on generic mechanisms and > behaviors that any device might experience on a modern network. Post keying > we have sufficient methods to differentiate between ANI and all that other > stuff. > > Another way of stating my position “we need bootstrapping to be as well > contained as possible, so depending on GRASP seems wrong”. In truth of course > the Proxy to Registrar communication benefits from GRASP so it is suggested > there for ANI devices. This compromise integrates bootstrapping with ANI in a > way that provides value when ANI exists but doesn’t depend on it for > situations where it doesn’t exist.
I think we completely agree on that goal. It's just a matter of arranging the mandatory mechanisms in the best relationship to achieve that goal. I suggested in https://www.ietf.org/mail-archive/web/anima/current/msg02198.html how I would achieve this. Brian > - max > >> >>> >>>>> 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. >> >> And that's the problem. GRASP discovery and flooding need sockets that >> supports link-local multicast sending and receiving for each physical >> interface. >> >> Currently the GRASP code finds out how many physical interfaces it has >> and for each one creates a multicast sending socket. It also has a socket >> that listens for incoming link-local multicasts on all physical interfaces. >> I don't see how to do that using the ACP interfaces that you describe. >> >>> 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. >> >> Yes, and I'd like the LL multicast traffic to be protected too. >> But as far as I can see that needs explicit support in the ACP >> to emulate LL multicast sockets. The ideal would be that the ACP >> simply emulates LL interfaces, so that GRASP could treat them exactly >> like physical interfaces. >> >> If you want, I can point you the exact Python code that handles this >> in the prototype. >> >>> >>>>> 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. >> >> Sure. That was my conclusion (for discovery; it makes no sense for flooding). >> >>> 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). >> >> GRASP discovery and flood are specified as link-local, so yes, that check >> is needed. >> >>> 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. >> >> Ack. >> Brian >> >> _______________________________________________ >> Anima mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
