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