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

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Tue, 1 Nov 2016 22:42:32 +0000

> On Oct 31, 2016, at 6:59 PM, Brian E Carpenter <[email-masked]> 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-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 Nov 2016 12:01:59 +1300

In line...
> 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 f…

I think we completely agree on that goal. It's just a matter of arranging the
mandatory mechanisms in the best relationship to achieve that goal.
I suggested in https://www.ietf.org/mail-archive/web/anima/current/msg02198.html
how I would achieve this.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Nov 2016 10:34:39 -0400

Toerless Eckert <[email-masked]> wrote:
    te> b) I have just posted ACP draft -04 in which i have reversed the choice
    te> of mDNS for ACP discovery by neighbors from the -03 text which had
    te> mDNS. So -04 defines to use (DULL) GRASP for ACP discovery with more
    te> details.

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.  

Why not simply respond to the ACP discovery with a key management initiation
to the sender of the multicast?  

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.

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.

    te>    Pls check out the text on discover in -04, i hope it justifies use
    te> of GRASP for neighbor discovery.
   
    brian> When GRASP is run securely in its two forms for the ACP, it is
    brian> always protected/ encrypted by the ACP, so i think your security
    brian> concern would then not be valid.
    brian> 
    brian> I'm still waiting to see a clear explanation of how the ACP will
    brian> secure LL multicast, however.

    te> I am not sure i understand the documentation ask. The ACP has a bunch
    te> of (virtual) interfaces. In the most simple implementation option, each
    te> ACP channel to an ACP neighbor is its own (p2p) L3 interface in the
    te> ACP. And thats all the interfaces the ACP has.

Your quoting style makes it hard for me to understand the flow.
I think that I requoted it correctly?

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

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

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

    > The other piece was that Michael was trying to figure out how to avoid
    > using LL multicast and instead use 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.  

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

but, also because L2 multicast must be sent at the data rate/power-level of
the weakest receiver, so L2-multicasts can eat hundreds of unicast TxOps.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Nov 2016 10:37:05 -0400

Brian E Carpenter <[email-masked]> wrote:
    > 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.

if (if_name ~= /^acp.*/):
   secure = true

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

This is a nil operation.
I think the problem is that you don't have any ACP code at this point.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Nov 2016 08:31:11 +1300

> if (if_name ~= /^acp.*/):

Strangely enough my Python code currently says

 _tls_required = not(acp.status())

(That would lead to a dead end in the code, since I haven't actually
implemented TLS wrapping, but we seem to be thinking the same way.)

>     > interfaces, so that GRASP could treat them exactly like physical

I don't understand that statement. I do understand that the adjacency table
contains enough information to make it possible for the ACP to do the right
thing, but I don't see anywhere in the ACP spec that says that it will do
the right thing.

> I think the problem is that you don't have any ACP code at this point.

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.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Nov 2016 08:51:56 +1300

In line...

> things. Call it uGRASP if you like.

I was trying to think of a reason why this wouldn't work, and can't really
find one. It could be sent as a GRASP discovery with a very short timeout,
so from the GRASP point of view it would fail promptly, but the IKE message
would arrive as if by magic.

Alternatively we could turn it round and use a GRASP flood (also LL multicast),
which never gets a TCP reply anyway.

> b) inside of the ACP LL multicast, which is really just p2p traffic.

Well, yes, all ACP is p2p traffic at the physical layer, but

> just use that channel for future communication.

Can MPL support LL scope?

Using LL multicast is more than convenience. If GRASP sends an LL multicast,
it must be sent from a designated physical interface and must not travel more
than one hop. Otherwise it defeats the point. The fact that it's being
encapsulated and secured and replicated is kind of irrelevant to GRASP.

> insecure link.  The killer is the TCP reply, which implies a TCP stack, which

Yes, but then GRASP's scope is between autonomic nodes, not between all Things.
I expect that most Things will be managed by an ASA in a bigger autonomic node.

> the weakest receiver, so L2-multicasts can eat hundreds of unicast TxOps.

Indeed, but I don't in general see that as being in AN scope. (It may well
be in BRSKI scope.)

    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 4 Nov 2016 01:35:42 +0100

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

> I don't see how to do that using the ACP interfaces that you describe.

GRASP should have a separate socket for each interface - but use that
socket both for sending and receiving. No shared socket for reception.

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

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

> If you want, I can point you the exact Python code that handles this

Please do. Just not sure when i'll find time.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 4 Nov 2016 01:45:32 +0100

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 4 Nov 2016 20:33:43 +1300

On 04/11/2016 13:35, Toerless Eckert 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.

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

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

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

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

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

> Please do. Just not sure when i'll find time.

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

Rgds
   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 4 Nov 2016 16:02:50 +0100

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

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

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

> numbers, not the names, and they should be system-wide unique.

Have to look at your code..

> the ACP draft, I assure you.

Can you propose text ?

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 4 Nov 2016 20:54:53 +0000

> On Nov 3, 2016, at 6:45 PM, Toerless Eckert <[email-masked]> wrote:
> 
> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 5 Nov 2016 10:09:17 +1300

On 05/11/2016 09:54, Max Pritikin (pritikin) wrote:
> 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

---

From: Michael Richardson <[email-masked]>
Date: Sat, 12 Nov 2016 11:56:48 +0900

Brian E Carpenter <[email-masked]> wrote:
    >> I wonder about the utility of the GRASP unicast TCP response to the
    >> ACP discovery.
    >>
    >> Why not simply respond to the ACP discovery with a key management
    >> initiation to the sender of the multicast?
    >>
    >> 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.
    >>
    >> 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.

    > I was trying to think of a reason why this wouldn't work, and can't
    > really find one. It could be sent as a GRASP discovery with a very
    > short timeout, so from the GRASP point of view it would fail promptly,
    > but the IKE message would arrive as if by magic.

    > Alternatively we could turn it round and use a GRASP flood (also LL
    > multicast), which never gets a TCP reply anyway.

This seems like the right answer to me.
I hadn't understood it's purpose.

Could an M_FLOOD announce a node as an ACP peer, and also indicate if it
could be a Join Assistant? (in a single message)?

    >> We discussed it before, but it might be worth discussing it again to
    >> be sure we went down the right path.  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.

    > Can MPL support LL scope?

You don't need MPL for LL scope :-)
MPL is to permit scope > 2 multicast to propogate across the RPL mesh the
same way that a network that is entirely onlink would get multicast.

    >> insecure link.  The killer is the TCP reply, which implies a TCP
    >> stack, which most which to avoid.

    > Yes, but then GRASP's scope is between autonomic nodes, not between all
    > Things.  I expect that most Things will be managed by an ASA in a
    > bigger autonomic node.

agreed.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 12 Nov 2016 11:57:03 +0900

Brian E Carpenter <[email-masked]> wrote:
    > 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.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Nov 2016 16:34:50 +1300

> could be a Join Assistant? (in a single message)?

Certainly. We have no limits on the content of an objective, and actually M_FLOOD
is defined to carry more than one objective if required. This seems like
a good approach to me.

> same way that a network that is entirely onlink would get multicast.

Duh.

>     > Things.  I expect that most Things will be managed by an ASA in a

Good!
    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Nov 2016 16:38:26 +1300

> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Nov 2016 16:41:06 +1300

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.) I'm not joking, either. I've been very happy checking GRASP concepts
by writing prototype code, and I think we need to do the same for all components
of the ANI.

Also a virtual ACP that we could extend between sites across the Internet
would be great for testing. I don't see any reason why a hackathon needs to
be held in one room.

   Brian

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Nov 2016 14:17:18 +1300

I put this aside just before the IETF:

> In an implementation of ACP that i could imagine.

Yes, that makes sense.

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

Fair enough. 40 is a bit scary (the most my prototype has ever seen is
2, but actually the code should work with 40). I think we should
RECOMMEND that the L2 switches support the ACP.

>    enforce that via filtering when you receive messages.

Not sure it's an issue, but certainly I don't see a problem in doing
that - but again, better with 4 interfaces than 40.

>   via what the API doc calls the "scope ID" (which really is a zone ID).

Yes, Zone ID is the correct IPv6 terminology, but in any case it's
much cleaner to use interface numbers IMHO. My code figures that out
on both Windows and Linux, but they are quite different. In this area
Winsock seems to be superior to POSIX, even when viewed through
the Python library.

>   would then send and receive IPv6 LL multicast only on that interface.

Yes, you must do IPV6_JOIN_GROUP for each interface separately,
with the right mreq structure. If I can inflict more Python on you,
this is how I join the group on all interfaces with the same socket
(slightly simplified):

for i in _ll_zone_ids:
    mreq = ALL_GRASP_NEIGHBOR_6.packed + struct.pack('@I', i)
    mcrsock.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_JOIN_GROUP, mreq)

so it would be easy to do that with separate sockets. You'd need a
thread per socket, however. With a single socket, you don't need
that.

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

No, it's correct for both POSIX and Winsock.

>>> it's easy to enumerate the interfaces of eg: the ACP being one VRF.

VRFs on Linux may turn out to be a dark art; a quick Google didn't
help much. I didn't get much out of
https://www.kernel.org/doc/Documentation/networking/vrf.txt

>> the ACP draft, I assure you.

Not sure I can. But something along the lines of:

The ACP will appear to its users as a VRF instance that supports
various network interfaces which in turn support standard TCP/IP
sockets. These sockets can support link-local or global-scope
IPv6 addresses. Multicast support SHOULD be limited to link-local
operations. The way in which a program using the ACP detects that
the ACP is present and attaches itself to the VRF instance is
implementation-dependent.

IMHO you should also recommend an API for the detection/attachment
and for accessing the adjacency table, but like the GRASP API
that should be a separate document.

Regards
    Brian