Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?)

[Brian E Carpenter]

On 12/11/2016 15:57, Michael Richardson wrote:
> 
> Brian E Carpenter  wrote:
> > True, and I don't have a clear definition of what that code will do.
> > If it will actually support LL multicast send and receive sockets
> > exactly like physical LL interfaces do, I will be happy. But there's no
> > indication of that in the ACP spec.
> 
> So, it's clear that we have to fix this doc bug with some running code.

Yes. I'd love if someone could send me an ACP module to install on my Linux
box. One for my Windows box would be nice too. (Both with a Python interface
please.)

   Brian

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?)

[Brian E Carpenter]

On 05/11/2016 09:54, Max Pritikin (pritikin) wrote:
> 
> 
>> On Nov 3, 2016, at 6:45 PM, Toerless Eckert  wrote:
>>
>> On Tue, Nov 01, 2016 at 10:42:32PM +, 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 

Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?)

[Max Pritikin (pritikin)]

> On Nov 3, 2016, at 6:45 PM, Toerless Eckert  wrote:
> 
> On Tue, Nov 01, 2016 at 10:42:32PM +, 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 

Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?)

[Toerless Eckert]

On Fri, Nov 04, 2016 at 08:33:43PM +1300, Brian E Carpenter wrote:
> > GRASP should have a separate socket for each interface 
> 
> How many interfaces do you mean? With no ACP, GRASP knows a reasonably
> small number of physical interfaces, and has to open a socket for each of
> the to send LL multicasts, and it has to listen for LL multicast from
> all of them, which as far as I know requires a separate socket that is bound
> to the relevant multicast address.

If each physcial interface connects to one ACP neighbor, the number
of logical ACP interfaces would be the same as the number of physical
interfaces. If an interface is a LAN connecting to N ACP neighbors,
you would have N ACP virtual interfaces, one for each such neighbor.
In an implementation of ACP that i could imagine.

Of course, on a LAN with N ACP neighbors, those would be eg: routers
interconnected via a switch, so if that switch was autonomic itself, then
you should only see one ACP neighbor, the switch. That the point of the
discussion about GRASP instead of mDNS for ACP discovery, and of course,
on the switch, we'd need to figure out how to intercept the ACP messages
to make that work.

> In addition it has to open unicast sockets as and when needed, which may
> be bound to any kind of address. (In the limited instances they will
> be restricted to link-local unicast, but that's a special case.)
> 
> I am still missing enough detail about the interfaces and socket options
> that the ACP will provide to know how this will change when the ACP
> is there. If there are, e.g., 400 autonomic nodes in the ACP and my node
> has 4 physical interfaces, each of which has 10 link-local neighbors,
> how many interfaces will the ACP offer me? 4, 40, 400?

Never 400. 4 if the L2 switches on the LANs are ACP capable, 40
otherwise.

> > - but use that
> > socket both for sending and receiving. No shared socket for reception.
> 
> Why not? There's no problem identifying the source interface for a multicast,
> it comes right back in recvfrom() (at least on Windows or Linux).

I probably should not have used "should" when i was recommending
a separate socket per interface but instead:

-> To me the logic of dealing with multiple interfaces wold be most
   easy if an implementation could have a separate socket for each
   interface, physcial and ACP-channel (aka: per ACP neighbor).
   With that approach, its clear at the socket level, which sockets
   belong to which security domain, and you do not have to
   enforce that via filtering when you receive messages.

Socket API is a lot of confusing complexity. I haven't played with LL
IP6 myself on linux, so i can only guess:

- Lets assume you bind your socket to the LL IPv6 address of an interface
  via what the API doc calls the "scope ID" (which really is a zone ID).
  You should then be able to send/receive only from/to that interface.
- I am not sure what impact this has on multicast. I was hoping that you
  could still do the setsockopt to add the GRASP LL IPv6 multicasr group,
  and in that API call you'd equally indicate your LL IPv6 addr and
  would then send and receive IPv6 LL multicast only on that interface.

I have not tested this, so this is right now just conjecture.

> > GARSP only needs to figure out which interface is physcial and which
> > is ACP. On router-OSs, each interface would be assigned to a VRF, so 
> > it's easy to enumerate the interfaces of eg: the ACP being one VRF.
> 
> I would assume that the adjacency table would provide that sort of clue.
> To make my code agnostic about Winsock vs POSIX, I just use the interface
> numbers, not the names, and they should be system-wide unique.

Have to look at your code..

> > Right. But this is not a new ACP thing. Any existing IETF protocol
> > implementation that uses link-local addresses and runs on any type of
> > any form of physical or virtual interface needs some form of interface
> > representation at the API level to send/receive LL packets. Thats why
> > i am somewhat hesitant to add explanatory text for this to the ACP
> > draft. It's supposed to be implied by the IPv6 addressing model and
> > common practice in IETF documents that its not regurgitated too much.
> 
> No, it doesn't need much text but it really isn't obvious at all from
> the ACP draft, I assure you.

Can you propose text ?

Cheers
Toerless

> >> If you want, I can point you the exact Python code that handles this
> >> in the prototype.
> > 
> > Please do. Just not sure when i'll find time.
> 
> Let me do that when I'm back from my short vacation.
> 
> Rgds
>Brian
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
t...@cs.fau.de

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?)

[Brian E Carpenter]

On 04/11/2016 13:35, Toerless Eckert wrote:
> On Tue, Nov 01, 2016 at 01:59:17PM +1300, Brian E Carpenter wrote:
>> 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?)
> 
> Just justification why to use GRASP instead of CDP/LDP/mDNS based on
> the rule "ANIMA should reuse first, and invent only when reuse is not
> a sufficient solution to meet requirements".
> 
> For example: for GRASP inside ACP we didn't need to put in justification 
> because
> nobody ever claimed that there are equivalent prior IETF solutions.
> 
>> 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.
> 
> GRASP should have a separate socket for each interface 

How many interfaces do you mean? With no ACP, GRASP knows a reasonably
small number of physical interfaces, and has to open a socket for each of
the to send LL multicasts, and it has to listen for LL multicast from
all of them, which as far as I know requires a separate socket that is bound
to the relevant multicast address.

In addition it has to open unicast sockets as and when needed, which may
be bound to any kind of address. (In the limited instances they will
be restricted to link-local unicast, but that's a special case.)

I am still missing enough detail about the interfaces and socket options
that the ACP will provide to know how this will change when the ACP
is there. If there are, e.g., 400 autonomic nodes in the ACP and my node
has 4 physical interfaces, each of which has 10 link-local neighbors,
how many interfaces will the ACP offer me? 4, 40, 400?

> - but use that
> socket both for sending and receiving. No shared socket for reception.

Why not? There's no problem identifying the source interface for a multicast,
it comes right back in recvfrom() (at least on Windows or Linux).

> GARSP only needs to figure out which interface is physcial and which
> is ACP. On router-OSs, each interface would be assigned to a VRF, so 
> it's easy to enumerate the interfaces of eg: the ACP being one VRF.

I would assume that the adjacency table would provide that sort of clue.
To make my code agnostic about Winsock vs POSIX, I just use the interface
numbers, not the names, and they should be system-wide unique.

> In Linux the closest equivalent are network contexts. ACP could be one
> network context. Compared to router-OS, linux is more secure/constrained:
> Processes only have access to one network context. So you'd have to run
> separate GRASP processes. Which may be a good thing.

Yes. Actually I run multiple GRASP kernels all the time for my testing
scenarios; it works nicely.

> 
>>> 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.
> 
> Right. But this is not a new ACP thing. Any existing IETF protocol
> implementation that uses link-local addresses and runs on any type of
> any form of physical or virtual interface needs some form of interface
> representation at the API level to send/receive LL packets. Thats why
> i am somewhat hesitant to add explanatory text for this to the ACP
> draft. It's supposed to be implied by the IPv6 addressing model and
> common practice in IETF documents that its not regurgitated too much.

No, it doesn't need much text but it really isn't obvious at all from
the ACP draft, I assure you.

> 
>> If you want, I can point you the exact Python code that handles this
>> in the prototype.
> 
> Please do. Just not sure when i'll find time.

Let me do that when I'm back from my short vacation.

Rgds
   Brian

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?)

[Brian E Carpenter]

On 04/11/2016 11:55, Toerless Eckert wrote:
> On Wed, Nov 02, 2016 at 10:34:39AM -0400, Michael Richardson wrote:
>> I have no problem with the use of a GRASP multicast discovery here.
>>
>> I wonder about the utility of the GRASP unicast TCP response to the ACP
>> discovery.  
> 
> See my last email to Brian et.al. on the signaling list, aka:
> 
> GRASP-08: A responder MAY send a Discovery Response message
> I also think that should be a MUST NOT or SHOULD NOT.

I assume you mean that in the restricted contex of bootstrap, because
in any other case of course the unicast response is needed. It's a MAY
because an ASA might want to hide for some reason.

> 
>> Why not simply respond to the ACP discovery with a key management initiation
>> to the sender of the multicast?  
> 
> Right. Thats what would happen if there is no response at the GRASP level.
> either IPsec session setup or eg: TLS with gRASP inside to negotiate
> the ACP channel protocol.
> 
>> My reasoning is as follows:
>>1) four TCP packets across the insecure ("public") LAN just to say "okay"
>>2) insecure GRASP instance must open TCP port on insecure LAN, and accept
>>   connections from anything. (See discussion about possible CBOR encoding
>>   attacks).
>>3) discovery of ACP peers is meaningless outside of the the local-link.
>>4) IKEv2 (whether used for IPsec keying, or MACsec keying [%]) already
>>   provides all the negotiation we need, and does it with higher privacy
>>   and security than GRASP could.
> 
> Right. The GRASP responses serve no requirement that i know in the
> case of DULL GRASP instances. I think they where kept in the spec so far
> because the original signaling exchange was discovery, discovery response,
> and then synchronization. Which was the sequence Brian implemented
> before the unsolicited "flood-sync" which wraps it all up into one
> message. Aka: What i want is the "flood-sync" that minimizes signaling and
> IMHO makes responses unnecessary.
> 
>> Yes, I realize that this is an "exception" case for GRASP, but I also claim
>> that all insecure instances of GRASP will be extremely minimal, purpose built
>> things. Call it uGRASP if you like.
> 
> Right. Logically it could be one implementation with multiple
> objectives (ACP, BRSKY,...), but technically its very good that
> each of these services could run it's own uGRASP instance without
> collision: As long as the sockets are opened with SO_REUSEADDR ;-)
> 
>> There are two LL multicast involved:
>> a) outside of ACP LL multicast on the underlying link.
>> b) inside of the ACP LL multicast, which is really just p2p traffic.
>>
>> Brian, RPL has an associated multicast routing protocol called "MPL".
>> We discussed it before, but it might be worth discussing it again to be sure
>> we went down the right path.
> 
> Maybe we should open a separate thread about that. Its certainly
> attractive to conside RPL as a carrier for additional flooded messages,
> but i have seen a long history of doing that in a variety of IGP, and
> it has always lead to a lot of frustrations when there where multiple
> coices of IGPs So i'd for now stick by a rule that the IGP should only
> flood info that only the IGP needs, the rest would be flooded by
> a mandatory soulution specific protocol approach. eg: GRASP in our case.
> 
>> We decided that GRASP would do application
>> layer multicasting -- as such, there will be hardly any actual layer-2
>> multicast, as all the ACP links are p2p.  Using multicast destinations here
>> is a convenience to not knowing what the peer's address is, except that once
>> we have the first response via TCP, we do know the peer, and we might as well
>> just use that channel for future communication.
> 
> By specifying the use of LL multicast for GRASP discovery, we 
> make it most easily reuseable in arbitrary contexts: There is no
> dependency against "ACP", but only against "some underlying security".
> For example, i could build IOT networks without ACP and still use
> GRASP as long as i am sure all my links have eg: 802.1x or the like.
> A lot of IoT wireless networks will come with link-security.
> 
> I am also not sure where/how we would actually make anything simpler
> by not using LL multicast: For the ACP, all interfaces are p2p ACP
> secure channels, whether i send LL multicast or LL unicast doesn't make
> a difference. Except that i'd need to learn the LL unicast.
> 
>> I see no places in IoT where we would want to use insecure GRASP on an
>> insecure link.  The killer is the TCP reply, which implies a TCP stack, which
>> most which to avoid.  
> 
> Another good point for optimizing the insecure GRASP the way we
> seem to agree upon (only LL multicast announcements).
> 
> Ok, but that has IMHO two separate conclusions:
> 
> -> For DULL GRASP we only need LL multicast announcements, no replies

If that is so, definitely use Flood not Discover. It's designed to have
no reply.

> 
> -> If we want to proliferate 

Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?)

[Toerless Eckert]

On Tue, Nov 01, 2016 at 10:42:32PM +, 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