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" ?
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
