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

[Toerless Eckert <[e-mail]>]

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