Re: [Anima-signaling] GRASP issue 51: Flooded objectives

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

Thanks Toerless, this is a very useful discussion in terms of detecting
unspoken assumptions, so I have to continue with more questions:
On 09/08/2016 02:03, Toerless Eckert wrote:
> Inline
> 
> On Sat, Aug 06, 2016 at 02:39:35PM +1200, Brian E Carpenter wrote:
>> Hi Toerless, just drilling down on two points (I have not ignored the rest,
>> but these condition other aspects):
>>
>> On 05/08/2016 20:34, Toerless Eckert wrote:
>>
>> ...
>>>> 1. We specify that the source address is cached with the flooded objective, and that
>>>> multiple copies are kept if there are multiple sources.
>>>
>>> Yes, but "source" really must be the ASA transport address, aka: 
>>>    source = {ACP-ULA-IPv6-address, proto=TCP, ASA-GRASP-TCP-port}
>>
>> Here I have a little problem. Unless you plan to use GRASP messages for
>> the entire process, it isn't GRASP's business what protocol and dynamic
>> port are to be used.
> 
> I do not parse that sentence. Can you rephrase ?

How can the GRASP library and code know what protocol and port the ASA intends
to use for non-GRASP messages? It doesn't create the sockets for that, only
the ASA can do so. So in this case, if the ASA wants to talk over CoAP or HTTPS,
GRASP doesn't know anything about it. (I'm looking at
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-03#section-3.2)

>> So I think the protocol and the port need to be
>> fields in the flooded objective itself, not derived automatically by
>> GRASP. Does that make sense?
> 
> We need to be able to distinguish in the caches announcements for the same
> objective from two different ASA on the same autonomic node.

Now here's another hidden assumption. The GRASP spec currently says (in the
security considerations):

   - Authorization and Roles

      The GRASP protocol is agnostic about the role of individual ASAs
      and about which objectives a particular ASA is authorized to
      support.  It SHOULD apply obvious precautions such as allowing
      only one ASA in a given node to modify a given objective, but
      otherwise authorization is out of scope.

I have been working on the assumption that only one ASA is allowed to
register itself to manage a given objective in a single GRASP instance.
'Manage' means being a source of synchronization or flooding or being
a negotiation responder. Why? Because otherwise, other nodes will see
inconsistent behaviour by the node in question.

I don't understand an application scenario where it's useful to have two
ASAs managing the same objective in the same node. Why would you allow
two Registrars in the same node, for example?

But in fact, as far as I can see, GRASP discovery could work in such a
case, returning two different discovery responses from the same node, with
different GRASP-managed ports. (I suspect my code would already support that.)
That would allow synchronization or negotiation independently with either of
the ASAs. Hence the SHOULD in the above extract.

However, if we also allow two different ASAs in the same node to flood the
same objective, that does require some extra tagging, as you say below.
So I want to be very clear about it. Why do we want to do that?

Since it would be a protocol change, we would need to present it to the whole WG.

> Therefore the
> "source" needs to have another distinguisher beside the IPv6 address of the
> autonomic node. This is not an issue that the individual ASA can solve becaue
> the cache is kept by GRASP.
> 
> The distinguisher can be any ID, but i proposed to use the ASA's TCP port number
> through which it runs GRASP becaude this ID does already exist and is unique.
> So no new ID-allocation code to write.
> 
> This TCP port number will NOT be used to construct the transport port of any
> service connection!
> 
> Example:
> 
>     Registrar ASA objective announcement:
>         source = { ACP-ULA-IPv6-address, proto=TCP, Registrar-GRASP-TCP-Port }
>         ....
>         Payload:
>         EST-adress: { proto=TCP, port=<Registrar-EST-port> }
> 
> Registrar ASA starts, it gets a TCP port for its GRASP unicast messages
> GRASP puts that <Registrar-GRASP-TCP-Port> into the source of all Objectives from this ASA.
> 
> Then the Registrar ASA opens a TCP server port for the EST protocol. Then it
> announces the objective.
> 
> The Bootstrap-Proxy constructs the transport address of the EST connection
> by combining the TCP port from the payload EST-address with the IPv6 address
> of the source. The TCP port of the source is only used to send/receive GRASP
> messages from/to that ASA - which happens by the GRASP library. 
> 
> And of course, this could be a TCP or UDP port number. I personally think TCP
> is easier even if there is more overhead because i don't need to bother about
> fragmentation (for GRASP).

Fully agree about TCP. I haven't even coded the UDP option ;-)

> 
>> ...
>>>
>>> If the announcer of a flood sync announce dies, how would its cache entries
>>> ever be deleted ? On nodes that have an ASA interested in the objective,
>>> the ASA can look at expiry time and tell GRASP to expire the entries. But
>>> how about nodes without such ASA ?
>>
>> Is it a problem? The useless flooded objective would sit there until the
>> cache overflows and it gets deleted by the LRU algorithm.
> 
> Normally, U) means "used",

Right. It needs to be deleted by a Least Recently Updated algorithm!

> and i think we can not do this:
> Check my algorithm for a bootstrap proxy finding the best registrar. It will retrieve
> from GRASP all those registrar cache entries, so you can't figure out which one
> it "Uses" without additional API. The only thing the currently planned APIs
> would give you is an indication when the client ASA tries to use an objective
> and it's broken. But it will try only what it thinks are the best. Not the others,
> so they won't get good LRU treatment.
> 
> We need to have a fairly high frequency of periodic flood-sync messages anyhow.
> Else a newly rebooted device will not learn them well. Or we need to make
> the protocol more complex by generating additional triggered flood syncs for newly
> booted devices. Aka: one flood sync every 30 seconds . Then it makes a lot of sense
> to also time them out.
> 
>>> Aka: expiry_time looks to me like a logical GRASP header parameter so that
>>> we can GRASP without ASA expire flood sync cache entries.
>>
>> We can do that. It's a choice: extra bytes in every flood message versus
>> no default expiry mechanism, just LRU cache expiry.

The alternative is a fixed lifetime but I don't like that for flooded
objectives, because some of them (e.g. Intent) might have infinite validity.

> 
> I'll vote for extra bytes.

If we're happy that flooding is relatively rare, that seems OK. Of course that's
another protocol change to be discussed with the whole WG.

Rgds
   Brian

> 
> Cheers
>     Toerless
> 
>> I'll review all your points after we clear these ones up.
>>
>> Thanks
>>     Brian
>