On 05/11/2016 09:54, Max Pritikin (pritikin) wrote: > > >> On Nov 3, 2016, at 6:45 PM, Toerless Eckert <[email protected]> wrote: >> >> On Tue, Nov 01, 2016 at 10:42:32PM +0000, Max Pritikin (pritikin) wrote: >>> Taken to the extreme one could argue that we need ANI to be self-contined >>> so depending on IP seems wrong. >> >> Can you explain where you think ANI depends on IP in a fashion you >> ae calling "wrong” ? > > Sigh. Too much snark — not enough information. > > My point is that ANI will, of course, depend on things. It isn’t a self > contained re-envisionment of the entire concept of networking. > > Where those things are themselves reasonably bounded I don’t see the problem > with using them. For example I could see an argument against discussing > DNS-SD because it is intended to span links and therefore ‘depends’ on the > DNS infrastructure. One could argue secure GRASP provides that role within an > ANI network and does so better (ie securely). > > But mDNS is not dependent on that infrastructure. Instead it is a relatively > self contained mechanism that doesn’t “step on the toes” or duplicate things > in the ANI infrastructure and it exists and is used already.
Yes. Which is why having non-autonomic nodes discover their BRSKI proxy by mDNS is a good idea. It isn't necessarily a good idea for ever, maybe a cheaper discovery method will come along, but it's the best we have for now. > So creating too many options in that space is simply adding confusion. Just > like it’d be silly to suggest that ANI devices shouldn’t use IP. ...or shouldn't use GRASP discovery :-) Brian > > - max > >> >> Cheers >> Toerless >> >>> 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
