Subject: Re: [Anima] comments on draft-ietf-anima-grasp-api

From: Toerless Eckert <[email-masked]>
Date: Fri, 9 Aug 2019 21:43:28 +0200

Hi Brian, *

I have right now primarily a high level comment:

The problem i have with the three layers of GRASP is that there
is no good justification why they exist and why the API document
needs to bother about them. The doc really only talks about the
library of the GRASP Library.

This is not to say that i do not like the idea to talk about the
modularity of a GRASP implementation, its just not well motivated
and executed i feel.

So, one way to solve this is to also talk about the other APIs.

For the extended function module, one could for example say
any extensions to GRASP that are CAN BE implemented on top the
GRASP API defined in this document SHOULD be implemented as
a GRASP Function Module. And examples could be the functions
suggested in my DNS drafts, or ther drafts you have that fit.
So, thats the simple part.

More interestingly, i would be a great fan of talking about the
API between library and core, to justify why we want to think about
this modularity.

This is where the outline could be something like the following:

Any peer-to-peer GRASP connection could and should be implemented
in the context of the ASA, such as in a library compiled into the
application. The reason is that this allows for greater 
confidentiality and mutual authentication then if it went through
the  GRASP core. Aka: any unicast message can ultimately have
an originator authentication if the security and transport substrate
used supports this. Which ACP does (TLS for ACP GRASP unicsast).

On the other hand, all the multicast messages and the hop-by
hop flooded unicast replies will have to be seen by each intervening
nodes non-ASA specific GRASP core code and hence needs to be implemented
in a common component called he GRASP core. For examplanation, the
terms "system level" or "daemon" could be used.

So as far as GRASP messages are concerned:
 ASA(GRASP-library)<->GRASP_core -link- GRASP-core -link- ... ASA
    M_FLOOD: hop-by-hop 'multicast'
    M_DISCOVERY: (constrained) hop-by-hop multicast
    M_RESPONSE:  hop-by-hop unicast

 ASA(GRASP-library)<-...(TLS)...->ASA(GRASP-library)
    all unicasted messages except M_RESPONSE sent in
    reply to a multicast received M_DISCOVERY.

So, there is a bit of work to do to go through the remainder
of the document and figure out what to say about how each of
the proposed API calls would operate at the GRASP API layer and
at the GRASP_CORE layer. The way i imagine it, the API would
be the same for both GRASP Core and GRASP Library except that
i think we need to check which of the API calls need another
(optional) locator parameter, because the whole goal of the exercise
is that the GRASP library would create its own unicast GRASP socket(s)
(e.g.: TLS) and that socket locator would need to be passed on via the
API calls to the GRASP core where needed.

And when that locator option is not given on the according API
calls, then the unicast would go across unicast sockets created and
kept only inside the GRASP Core . Which means that the GRASP
libary would also be  optional, but if an ASA runs directly
on top of GRASP core only, then it would expose all
potentially confidential objective value stuff to that
shared GRASP core code.

Also: When an ASA runs in an environment where it has cached
its relevant peers locators, then it can operate without
relying on the discovery service parts of GRASP and hence also
without any GRASP cores involved, arguably making a service
built on such ASA more resilient and maybe less prone to attacks.

So, let me know if we can get this IMHO important high level aspect
into the doc. If not, and if also can not find another reason to
talk about a standardized API to the GRASP core then that text
should better be moved to a non-specification section (informative
only, appendix, etc. pp.)

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Aug 2019 11:23:20 +1200

Hi Toerless,

> API between library and core, to justify why we want to think about

If there was only one operating system in the world, I guess we could
describe this. The challenge I see is that the way to solve this may
be drastically different in different o/s environments, depending on
what sort of IPC is available between contexts. So apart from saying
that an implementation needs to do this, I'm not sure how much we can say.

I did try to build an IPC interface into my Python implementation,
but the only way I could see that produced portable code was to
use a standard socket as the IPC mechanism. That works, but it's
pretty clumsy and seems very inefficient for production use.

However, it did show me that you are correct. There are some GRASP
functions that really need to be in a daemon** because they run on
their own even if there's no ASA in the node, and others that need
to be callable from multiple ASAs. The API as currently defined
only concerns those callable functions. You're actually asking for
the scope of the API draft to be expanded.

2nd level however: The daemon and the callable functions need to share
some common stateful data structures, which I suppose are somewhat
implementation-dependent, but the ones I found necessary are:

_asa_registry – where ASAs are registered
_obj_registry – where objectives are registered
_discovery_cache – where locators for discovered objectives are cached
_session_id_cache – where GRASP sesssion ids and ASA nonces are cached.
_flood_cache – where flooded objectives and their values are cached.

** In fact I needed to provide a way to activate such a daemon, because
Michael and Bill discovered that they needed to do so by hand during
the hackathon last month. It's called gremlin.py and contains 4 lines
of code.

Thanks
   Brian

P.S. We'll wait for Guangpeng's promised review before we revise the
draft.

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 12 Aug 2019 21:10:17 +0200

> that an implementation needs to do this, I'm not sure how much we can say.

The transport of the API is of course always system specific. But thats
not unique to the API between core and library, it equally extends
to the API between library and ASA. So threre is IMHO no need to
consider the library/core API to be any more proprietary than the
ASA/library API.

> pretty clumsy and seems very inefficient for production use.

None of the currently popular OSs seems to have OS mechanisms that
would make API calls into a daemon as easy as they are into the
OS kernel. Nevertheless, more and more services code gets built
as daemons for flexiblity and modularily reasons. Just got to
suck up the overhead and live with it. Not a GRASP specific issue.

> the scope of the API draft to be expanded.

I gave two options: Either eliminate the distinction between library
and core or introduce better text to justify that distinction, and
i think the strongest way to do that is to define the API between
them. Which i think is not much different from the one ASA/library.

> _asa_registry ??? where ASAs are registered
> _obj_registry ??? where objectives are registered
> _discovery_cache ??? where locators for discovered objectives are cached
> _session_id_cache ??? where GRASP sesssion ids and ASA nonces are cached.
> _flood_cache ??? where flooded objectives and their values are cached.

I don't think you need to elaborate on that level of detail.
Just think of the library as something that provides on its
northbound the API you specified, and on its southbound to the
core it uses almost the same API, and the only thing that the
library can really do by itself is to directly build those
TLS unicast connections to remote GRASP peers. So its really
a demultiplexer between passing calls from/to the core and its
own maintained TLS connections.

> the hackathon last month. It's called gremlin.py and contains 4 lines

IMHO, it should be started when system comes up. In a reasonable secure
envirnment, a normal ASA shouldn't have permission to provide
system level services, because ASA IMHO are more like user provided
applications and each of them should be able to be less trustworthy
than a system level function like GRASP discovery.

One could say this is an implementation detail, but i think it would
add one reason to talking about separarte library/core: Distinction
between "ASA user" and system context.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Aug 2019 16:09:51 +1200

Hi Toerless,

Yes, I think your model is correct. Three more comments below, then I will
leave this alone until we revise the draft:

On 13-Aug-19 07:10, Toerless Eckert wrote:
> core it uses almost the same API,

Yes, that's essentially what my version with an IPC interface does,
but I didn't release that to GitHub because it really is cobbled
together and very Python-specific. 

> and the only thing that the

In fact I delegated all the TCP to the core as well, but that was
an implementation choice not a necessity.
> IMHO, it should be started when system comes up. 

Yes. Just for fun, it does now come up when my laptop boots, but there
doesn't seem to be any other GRASP traffic on my home LAN :-(.

   Brian

> In a reasonable secure