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

[Brian E Carpenter <[e-mail]>]

Hi Toerless,

Jus to focus on what to me is a key point:

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

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.

On 10-Aug-19 07:43, Toerless Eckert wrote:
> 
> 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
>