Subject: Re: [Anima] I-D Action: draft-liu-anima-grasp-distribution-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Oct 2015 16:56:16 +1300

Just a few comments and questions. I'm sure I will have more comments later.

I am reasonably convinced that we need to tackle this problem. At the moment
GRASP can handle two cases that are mentioned:

> 2.1.  Whole Domain Distribution

That's the GRASP flooding synchronization mode.

> 2.3.  Incremental Distribution
> 
>    The distribution only goes to the nodes that newly get online.

Assuming that nodes request synchronization when they go on line
(including after a sleep to save battery), this will be taken care of
by the GRASP unicast synchronization mode.

So the problem that remains is selective distribution. There are at least
two ways to model this:

(a) select all nodes that meet certain criteria (e.g. all nodes that support
objectives A, B or C). Flood the information to them.

(b) require nodes to subscribe to information X, Y or Z. Flood the information
to subscribers (a so-called pub-sub architecture).

Which model do we want? My guess is (a), because we need to be sure that Intent
for objective A reaches all nodes that support A, and so on. I think that's
what the manifest/mandate model in draft-peloso-anima-autonomic-function
would need, too.

I also think that (a) would be natural to implement in GRASP. We already have to
cache the locators of all the ASAs that support a given objective, as part
of the discovery mechanism. So we have that cache available to control
the selective distribution. Or if you actually prefer a pub-sub model, consider
that every node that responds to discovery for objective A is automatically
subscribed for distribution of all information relevant to objective A.

> 3.1.1.  Autonomic Domain Boundary
...
>    [Editor's Notes] It is a practical issue that how an autonomic node
>    recognizes itself as a domain boundary device.  It is not in the
>    scope of this document.

This actually won't be an issue with an ACP in place: only systems within
the domain will be addressable in the ACP.

> 3.1.3.  Arbitrary Injecting Point (Optional)
> 
>    The distributed object SHOULD be injected at any autonomic node
>    within the domain (or within a specific group [TBD]).

This is the same authorization problem that we have in general. Either
we accept that anything inside the domain is trusted, or we need to
build an authorization mechanism, and distribution will just be a
particular "atom" of authorization.

> 5.  Security Considerations
...
>    o  Inner layer authentication: the GRASP communication might not be
>       within a protected channel, then there should be embedded
>       protection in distribution itself.  Public key infrastructure
>       might be involved in this case.

We've already said that GRASP must run inside TLS if there is no ACP.
But I must say that whenever I think about this, it gets messy. Life would
be much simpler if we changed the policy to make the ACP mandatory.

      Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 29 Oct 2015 07:24:21 +0000

Hi Brian,

Thanks for your comments. Please find responses inline.

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Brian E
> Carpenter
> Sent: Tuesday, October 27, 2015 11:56 AM
> To: Anima WG
> Subject: Re: [Anima] I-D Action: draft-liu-anima-grasp-distribution-00.txt
> 
> I am reasonably convinced that we need to tackle this problem. At the
> moment GRASP can handle two cases that are mentioned:
> 
[Bing] Yes, it is achieved by overloading the Response message (which is Unsolicited Response). In technical aspect, I think this message overloading is sufficient to achieve the flooding goal. 
However, I'm still wondering whether it worth to make a new message type to handle the distribution. (The draft also lists this as an Open Question) 

> Assuming that nodes request synchronization when they go on line (including
> after a sleep to save battery), this will be taken care of by the GRASP unicast
> synchronization mode.
[Bing] Yes, indeed.

> So the problem that remains is selective distribution. There are at least two
> ways to model this:
> 
> Which model do we want? My guess is (a), because we need to be sure that
> Intent for objective A reaches all nodes that support A, and so on. 

> I think
> that's what the manifest/mandate model in
> draft-peloso-anima-autonomic-function
> would need, too.
> 
> I also think that (a) would be natural to implement in GRASP. We already
> have to cache the locators of all the ASAs that support a given objective, as
> part of the discovery mechanism. So we have that cache available to control

[Bing] I'm also in favor of (a). A sub/pub model might be too complex for GRASP. 
Besides, the sub/pub might only be able to do selective distribution according to objectives. But I don't think we should have such limitation. I'll include some text of a possible way to achieve (a) in the next version.

> This actually won't be an issue with an ACP in place: only systems within the
> domain will be addressable in the ACP.

[Bing] Yes. I'll explicitly call it out in the next version.

> This is the same authorization problem that we have in general. Either we
> accept that anything inside the domain is trusted, or we need to build an
> authorization mechanism, 
[Bing] I think it's reasonable to consider 3.1.3 essentially as an authorization problem, I'll reflex it in the next version.
> and distribution will just be a particular "atom" of
> authorization.
[Bing] I guess you specifically meant the arbitrary injecting in this section, not the whole distribution behavior as an atom of authorization?

> We've already said that GRASP must run inside TLS if there is no ACP.
[Bing] I'll reference the GRASP text more explicitly in the next version.
> But I must say that whenever I think about this, it gets messy. Life would be
> much simpler if we changed the policy to make the ACP mandatory.
[Bing] I don't have a strong opinion on this. But my shallow understanding is that maybe it's more flexible for GRASP to run outside an ACP. IIRC, we used to discuss there might need the signaling before the ACP is up.

Best regards,
Bing

>       Brian
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Oct 2015 08:43:23 +1300

Hi Bing,

Just clarifying one point:

On 29/10/2015 20:24, Liubing (Leo) wrote:
...
> [Bing] I guess you specifically meant the arbitrary injecting in this section, not the whole distribution behavior as an atom of authorization?

Exactly. If we have to add an authorization mechanism, I think we'll need
to define roles (a concept we discussed earlier) and then authorize individual
agents for various roles.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Oct 2015 08:48:46 +1300

Changing the subject for this point:

> [Bing] I don't have a strong opinion on this. But my shallow understanding is that maybe it's more flexible for GRASP to run outside an ACP. IIRC, we used to discuss there might need the signaling…

Yes, certainly there needs to be some GRASP traffic before the ACP is up,
but that might only be insecure discovery messages.

For more general use without the ACP, we have to solve several problems:
node ID, domain ID, certificates, domain boundary detection,...

It will just be easier if we always let the ACP do all that work!

   Brian