> 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. - 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
