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

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

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:
> On Sat, Aug 10, 2019 at 11:23:20AM +1200, Brian E Carpenter wrote:
>> Hi Toerless,
>>
>> 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.
> 
> 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.
> 
>> 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.
> 
> 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.
> 
>> 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.
> 
> 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.
> 
>> 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.
> 
> 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,

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

In fact I delegated all the TCP to the core as well, but that was
an implementation choice not a necessity.
> 
>> ** 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.
> 
> 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
> 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
> 
>> 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
>>>
>