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

Toerless Eckert <> Mon, 12 August 2019 22:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B9B881214D0; Mon, 12 Aug 2019 15:40:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.95
X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PzVLm2vBHtZE; Mon, 12 Aug 2019 15:40:07 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2F98D12231C; Mon, 12 Aug 2019 12:10:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BB2EC548014; Mon, 12 Aug 2019 21:10:17 +0200 (CEST)
Received: by (Postfix, from userid 10463) id A6588440041; Mon, 12 Aug 2019 21:10:17 +0200 (CEST)
Date: Mon, 12 Aug 2019 21:10:17 +0200
From: Toerless Eckert <>
To: Brian E Carpenter <>
Cc:, "" <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <>
Subject: Re: [Anima] comments on draft-ietf-anima-grasp-api
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Aug 2019 22:40:16 -0000

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, 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 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 and contains 4 lines
> of code.

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.


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