Subject: [Anima] [draft-ietf-anima-grasp-12 review] feedback notes 1

From: Toerless Eckert <[email-masked]>
Date: Fri, 2 Jun 2017 15:22:21 +0200

Dear authors:

some comments/questions/suggestions for GRASP:

P1: 3.8.4:
" In a more complex implementation, the GRASP discovery mechanism will find, 
  for each interface, a dynamic port that it can bind to for both UDP and TCP
  before initiating any discovery. "

AFAIK currently, there is no definition of an originator port in
the discovery message (initiator = ipv* address), so i can not see
how the above mentioned "more complex implementation" could work. How
would the responder know the dynamically assigned TCP or UDP port of the
initiator ? How would it know whether to respond via TCP or UDP ?

P2:

 In draft-ietf-anima-prefix-management, two GRASP objective-names(s) are
PrefixManager and PrefixManager.Params. Looks as if its useful to think of the
objective-name space as hierarchical. But i do not find any text to that end
in the GRASP draft. I would love to see GRASP objective-names to have at
least for the purpose of IANA registration at least one level of hierarchy,
which is <word1>(.<wordI>)* and that IANA registrations are only for word1.
Otherwise we would end up with a lot more "surplus"? IANA registrations that
really only are details of a particular ASA/autonomic-function.

P3: 3.8.11 Flood Synchronization Message

It would be good to add some text explaining in more detail how to use the M_FLOOD
objective. Here is some text explaining how _i_ think it works. I hope i even get
it right:

As outlined in the overview section, Flood Synchronization messages are used as an efficient
mechanism to announce objectives and their parameters (synchronization data) when
the objective is needed on many ASA in the network. Instead of creating an ongoing
amount of flooded Request messages from every client of the objective, these clients
can listen passively for flooded announcements of the objective. 

GRASP has no mechanism to flush long lived objectives whose announcer has died.
ASA that use M_FLOOD objectives should primarily rely on transport layer mechanisms
to determine the aliveness of a specific locator of such an objective: determine
that an objective locator has become inoperatble due to "unreachable" signaling
(eg: ICMP) or timeouts in attempts to establish a connection. Announcers of M_FLOOD
objectives should carefully consider the time-to-live for such objectives to avoid
that stale entries clog up caches and force a large number of clients to probe
(unsuccessfully) a failed objective locator. For an objective with few locators
in the network, a periodicity of 30 seconds and time-to-live of 90 seconds may be
a good compromise (Supporting loss of as much as 3 out of three M_FLOOD messages).
be lost. Note that every periodic announcement needs to have a new session-id to
ensure that he new periodic messages is not ignored by GRASPs duplicate elimination
mechanism.

P4:

 " If a subsequent Flood Synchronization message carrying the same objective
 arrives with a different tag, a new cached entry MUST be created"

I think this should not say "objective", but "objective-name". Eg: consider
that any of the parameters of the objective have changed, then the new entry should
also overwrite the old entry (for the same locator).

More fundamentally: The orinator of M_FLOOD objectives would periodically
send the M_FLOOD and the content of the new M_FLOOD would simply overwrite/refresh
the cache content for what was cached with the same tag. Aka: that explanation
should be rewritten. One could argue that it gets overwritten because the new
M_FLOOD with its fresh time-to-live will have a longer lifetime than the cache
entry, but event hat is IMHO to complex. The rule should simply be to update 
cache entries with fresh M_FLOOD information received (and just ignore duplicates
with sesion-id).

P5:

 6.  CDDL Specification of GRASP
    "objective-name = text ;see specification for uniqueness rules"
                            ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^
Which specification (i thought this is the specification),
 which uniqueness rules ? (uniqueness does not otherwise occur in the doc).

P6: The handling of locators in GRASP is somewhat confusing: Except when using the
URI locator, there seems to be no consistent encoding in GRASP what protocol to
use on top of a O_IPv6/v6_LOCATOR. Instead, the protocol to use is randonly
encoded in the *any part of an objective.  And i could not even find text that
describes this. Not sure where, but maybe add an explanation like the following:

GRASP does maintain the notion of locators only to the extend necessary to ensure
that different ASA can be implemented as different application (processes). In the
context of typical operating systems, different application processes require
different transport sockets, eg: (address,proto,port) sockets (as in O_IPV4_LOCATOR,
O_IPv6_LOCATOR and indirectly O_FQDN_LOCATOR). GRASP does not standardize declarations
 about what protocols an ASA expects to be used across these locators. If ASA
need to indicate/negotiate a specific protocol across such a locator then that
protocol would need to be specified as part of the objective specific parameters.

section 3.9.5: "GRASP is not intended to work across disjoint addressing or naming realms".

a) It would be helpful to have corollary text such as this:

 When GRASP is run in the ACP context,
this means that all locators indicate an ACP IPv6 address (O_IPV6_LOCATOR). Using
O_FQDN_LOCATOR or O_URI_LOCATOR in the ACP context is safest if all
IPv6 addresses of the domain name indicated are ACP addresses. ASA might also be
able to identify IPv6 addresses to be part of the ACP because of their prefix,
but that would be additional processing complexity not necessary when simply
sticking to O_IPV6_LOCATORS of only ACP addresses.

b) Another corollary that IMHO would be highly useful:

The fact that GRASP is not intended to work across disjoint addressing spaces
does not prohibit it to be used to signal and negotiate different address spaces:
Consider a flood-message (M_FLOOD) in the context of running GRASP across the ACP:
 The objective independent locator option indicates a locator for the objective
in the ACP. If there are locators for the objective outside of the ACP, then 
that locator would have to be encoded into the objective parameters - and it would
be a problem for the involved ASAs to ensure that the receiving ASA will know
what addressing/naming realm is indicated - and most likely that those ASA have
connectivity to that addressing/naming realm.

c) It would be nice if the CDDL for "objective" would not only say 'any', but
would be given a name that we can use to refer to it, eg: 'objective-parameters'
or 'objective-data' or the like. I like objective-parameters.

Cheers
    toerlss

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 3 Jun 2017 13:28:03 +1200

On 03/06/2017 01:22, Toerless Eckert wrote:
> initiator ? 

It's available in the socket API, returned with the message by recvfrom().

> How would it know whether to respond via TCP or UDP ?

It's specified as always TCP. The phrasing is confusing though; we need to
find a port that is available for *sending* UDP and *listening* for TCP.
Will rephrase.

> really only are details of a particular ASA/autonomic-function.

Personal opinion: You may be right, but I'm not sure yet. Can we leave
this for an update? It seems quite easy to retro-fit this to the registry
when we have experience. For now, it will just give the IESG something
else to DISCUSS.

> GRASP has no mechanism to flush long lived objectives whose announcer has died.

True, but that's a feature. If we've announced (say) the URL for Intent and the
announcer dies, it doesn't mean the Intent is dead.

> ensure that he new periodic messages is not ignored by GRASPs duplicate elimination

That's about right I think, but do we want to say this in the protocol spec?
I don't think we want to give the IESG any new text to chew on right now.
I'll take it as good input to draft-carpenter-anima-asa-guidelines

> also overwrite the old entry (for the same locator).

Yes, that's the intention. If the name and tag are the same, it overwrites.
We can make it clearer. To me, "same objective" means "objectve with the
same name" but I can see it might be unclear.

> cache entries with fresh M_FLOOD information received (and just ignore duplicates

Iy seems to me that the previous sentence ending "the corresponding cached copy
of the objective MUST be overwritten" says this quite clearly.
 
>     "objective-name = text ;see specification for uniqueness rules"

Section <mumble>. It's impossible to include an <xref> in CDATA text.
Will find a way to fix this.

> encoded in the *any part of an objective.  

No. When you discover an objective, the discovered locator is [address, protocol, port].
Then there's an option on a flood to tag the flooded objective with [address, protocol, port].
I just don't see the problem.

> And i could not even find text that

That's wrong, sorry. Of course you could put anything you like in the objective value,
but GRASP already supplies the locator 3tuple.

> a) It would be helpful to have corollary text such as this>

Look, I'm not very interested in adding yet more text to confuse the IESG
further. I think both of your comments are true but do you really want another
month of discussion?

> or 'objective-data' or the like. I like objective-parameters.

But then we'd have a rule objective-parameters = any. Is that really
an improvement?

Regards
   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 4 Jun 2017 16:54:54 +0200

> find a port that is available for *sending* UDP and *listening* for TCP.

So, in the first place, the question is why anyone would want to have
"a more complex implementation". The text does not answer this question but
should answer it. 

I guess the reason would go back to what we discussed long ago wrt. how much GRASP
an ASA wants to do itself vs. how much some shared GRASP daemon/ASA needs to do.
With what you write about a complex implementation, it _might_ be possible to
do more GRASP in the client ASA and minimize code in a shared GRASP daemon:

1. Responder ANI device has 5 ASA. Each ASA is its own process, binds to it's
own TCP port. That same port number must also be available as a free UDP port.

2. Responder ASA1 registers an objective with the GRASP ASA/Daemon.
GRASP ASA/Daemon is the one listening to GRASP Discovery messages on the
GRASP multicast address and GRASP port. This is the "shared daemon" requirement
because we can't be certain all OS's support replicating received multicast
messages to multiple sockets from different processes.

3. Now Initiator ASA on a different device wants to discover that responder ASA1
objective and wants to make sure that the TCP connection built can be directly from
the responder ASA1 to the initiator ASA - without the need to pass traffic of
that GRASP TCP connecetion via the GRASP daemons:

4. So, initiator ASA tries to find a port that it can bind to for both TCP and
UDP. Once it has found that port, it will send a UDP multicast GRASP discovery
to the GRASP destination port and with the source port being its own bound UDP port.

5. Now the responder ANI devices GRASP daemon receives that discover message.
because that objective was registered by ASA1, the GRASP daemon passes the discovery
request to ASA1 including the UDP source port from the received discovery message.

6. Now the ASA1 on the responder can build a TCP connetion back to the initiator
using the same TCP port as UDP port.

http://www.staples.com/Staples-Easy-Button/product_606396
(highly recommended product when dealing with obfuscated technology !)

So... IMHO that problem of dealing with multicast and socket API issues is already
difficult enough without having to deal with the problem of having to be able to bind
to the same port number for UDP and TCP:

IMHO, the discover multicast message needs to have another message element which is the
port number to reply to. Thats assuming the reply is always TCP. If you feel UDP
should also be an option then the discovery message should indicate the desired
reply mode UDP/TCP and port number.

Now, both approaches have a normal socket API security issue: when the responder
receives the discovery message and in return builds a TCP connection, there is
no guarantee that the actual TCP port on the initiator is owned by te same
process as the UDP port in the discovery - whether its in the UDP source port
field of the discovery message or in a GRASP message element.

So, if we want to secure this UDP multicast discovery -> TCP reply in the context
of existing socket APIs, then i think the mechanism could be further refined:

In the context of standard socket APIs, a responder can not know for certain that
the initiator TCP port is owned by the process that initiated the discovery
request. The only mitigation is to 
a) trust the GRASP daemon on the remote side.
b) The remote GRASP daemon has bound to the GRASP UDP port, so discovery 
   multicast packets whose source UDP port is also the gRASP port (the
   destination port must be the GRASP port) are trusted to have come from the
   remote GRASP daemon. And then the TCP port number in the discover message
   is trusted.
c) GRASP daemons can use local mechanisms to ensure that the TCP port indicated
   by an ASA is also owned by the ASA (aka: the interface between an ASA daemon
   and a GRASP daemon can use a POSIX standard UNIX socket and the gRASP daemon
   creates that socket and passes it back to the ASA). That way the GRASP daemon
   knows the TCP socket port number reliably.

This is all convoluted. If you are not a big fan of concoluted explanatory text
like what i wrote up above, i can understand it. But i am not a big fan of
suggestive incomplete text that you have on the draft right now...

The text optimized version of this is: a) add the (TCP) port parameter into the
discovery message and remove text about "complex implementations" ;-)
(and put the discussion into the guidelines document as you suggested below).

> when we have experience. For now, it will just give the IESG something

Sure. If that ever requires  a one page follow-on RFC to change registry semantic
from name to name-prefix, count me in as an author ;-P

> > P3: 3.8.11 Flood Synchronization Message
[...]
> announcer dies, it doesn't mean the Intent is dead.

Right, but if we are a registrar and die then the proxies can not use us anymore.
Which can be solved by failing connections etc. pp..
> I'll take it as good input to draft-carpenter-anima-asa-guidelines

Sure. Do you mind an informational forward pointer to that doc in the GRASP spec
so as to leave that breadcrumb ? 

> same name" but I can see it might be unclear.

I have started to use the names as they are defined in CDDL ;-)

> of the objective MUST be overwritten" says this quite clearly.

If it wold say objective-name, yes. My implied question was if he method
of "dying-gasp" should work: eg: a graceful removed objective could announce
itself with M_FLOOD of time-to-live = 1 sec and therefore overwrite any further
longer-lived ttl. I think it should work, but given how terse the text is,
i wonder if implementations would do the right thing (yeah, i k ow 78 pages and 
still this toerless guy calls it terse ;-)

I like the guidelines draft option of outsourcing additional explanatory text.

> Will find a way to fix this.

Yes, i stumbled across that problem in the bootstrap draft as well. Maybe
just refer to the section with the picture.

> I just don't see the problem.

I am talking about the protocol inside of the UDP/TCP locator.

> but GRASP already supplies the locator 3tuple.

See your own example for BRSKI with GRASP in the ani recommendation draft.
What you call method = BRSKI-TLS is what i call the protocol

> further. I think both of your comments are true but do you really want another

see below.
> But then we'd have a rule objective-parameters = any. Is that really

Without that line we do not have a normative word for the parameters of GRASP
objectives.

For example, the whole discussion about name spaces could be one simple corollary:

All locators used outside of grasp-parameters MUST be from the namespace GRASP is
running in.

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 5 Jun 2017 10:56:07 +1200

> "a more complex implementation". The text does not answer this question but

The reason we really need this that if you want two separate instances
of GRASP to run in the same node at the same time, you must have a
separate port for each instance. They can't both listen to unicasts
on GRASP_LISTEN_PORT. We should state that in the text, rather than
the obscure "more complex" phrase. Your model below is really a case
of that, since each ASA would contain its own instance of discovery.
(Personally I don't recommend that: we should hide as much as
possible from the ASA programmer. But that's off topic in the
protocol spec.)

> to the same port number for UDP and TCP
Yes, it is a bit messy because the socket API is so primitive, but because of
the above mentioned problem that you can't share a TCP port between instances,
I see no alternative.

> reply mode UDP/TCP and port number.

We could have designed it that way but we didn't, and I don't want to make such
a change in the middle of IESG discussion (unless of course we find a bug).

> a) trust the GRASP daemon on the remote side.

In the ACP, we can do that.

>    remote GRASP daemon. And then the TCP port number in the discover message

Yes, in the single-instance case. But that isn't the general case.

>    knows the TCP socket port number reliably.

If the discovery is executed entirely by the GRASP core, the ASA never knows
anything about the socket. That's my preferred implementation but it
isn't required by the protocol spec, obviously.

> suggestive incomplete text that you have on the draft right now...

Sure. And changing to to be specific that this is needed for mutiple instances
in one node is a good idea (and is IMHO a complete explanation of why it's needed).

> (and put the discussion into the guidelines document as you suggested below).

As above: IMHO this is not the time to change the protocol spec. (If the current
spec wasn't implementable I would have suggested a change a long time ago.)

> Which can be solved by failing connections etc. pp..

Yes. Every single bit of code in autonomics must handle exceptions. 
> so as to leave that breadcrumb ?

Yes, I will look for a good place to plant that.

> I am talking about the protocol inside of the UDP/TCP locator.

Yes, that's really the same point that Adam Roach caught. I think
the next text will be clearer (in the description of "Locator IPv6
address option", although it also applies to IPv4).

> What you call method = BRSKI-TLS is what i call the protocol

Sure, but that's relative to a very specialised infrastructure objective.
I regard that as an almost pathological case that needs a separate spec
(inside BRSKI, but I havn't had time to look at the latest BRSKI).
> Without that line we do not have a normative word for the parameters of GRASP

Well, OK, but for overall consistency I think it has to be objective-value.

> All locators used outside of grasp-parameters MUST be from the namespace GRASP is

That's more or less what the note in "Locator Options" says. I can make it more
explicit. I'm not convinced it needs a MUST though. Who can guess what people
will invent in future?

Hmm. I have a lot of changes stacked up in the XML. I'm quite keen to
post the draft.

    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 6 Jun 2017 18:09:04 +0200

> a change in the middle of IESG discussion (unless of course we find a bug).

I have not seen yet a protocol requirement that an instance needs to find
a dynamic port that it can bind to both via UDP and via TCP. Especially
given how this requirement can be avoided by adding a simple signaling element
to the GRASP header of multicast discovery messages.

The main issue is also that unlike a lot of other features in GRASP, 
this would be hard to introduce in a backward compatible fashion later:

Just for curiosity: Lets assume the messaging was changed later to:

  discovery-message = [M_DISCOVERY, session-id, initiator, ?tcp-reply-port, objective]
  tcp-reply-port = port-number

a) I hope/guess that "old" GRASP implementations would skip/ignore this element
   because CBOR is self-identifying and the implementation wouldn't know
   this signaling element. Right ?

b) Even if a) is true, an old receiver of M_FLOOD would not be able to
   respond.

Wrt to IESG: You have more experience with IESG review. If they have no concern with
this, i leave it up to you authors how to handle this.

> Yes, in the single-instance case. But that isn't the general case.

I am always talking about multi-instance. The difference is just
which process (ASA or GRASP) is sending the M_DISCOVERY. The TCP GRASP
connection would always be handled only by ASA processes.

> in one node is a good idea (and is IMHO a complete explanation of why it's needed).

If we try to find a good place outside the main GRASP spec for this type of
explanatory text, which draft could that be ? the ASA guideline draft looked
a bit more higher layer. grasp-api draft ?

> address option", although it also applies to IPv4).

Thanks. I am really looking for textual clarity on two points:

a) when i look at a locator, what context will it be in ?
   IMHO: its in the context of GRASP (aka "ACP" for ANI deployments), unless
   it is in the objective-value, in which case its an objective local definition.

b) How do i figure out what protocol is being run on top of of a locator ?
   ...It's convoluted. semantic of the objective determines it, so if the objective
   has multiple protocol options, then the objective-value has to have some element to define
   it. But there is no standard attribute for this in CDDL defined so far;-(

   Aka: if we would define a standard CDDL elemnt "locator-method" that we would 
   also use in BRSKI (string) that defines the different possible options for the
   protocol of the locator... that would help.

> (inside BRSKI, but I havn't had time to look at the latest BRSKI).

I don't think it's pathological. Whenever an autonomic function is (also) using some non-GRASP
protocol between its ASA, and uses GRASP to negotiate such a protocol, then we have this
case.

> Well, OK, but for overall consistency I think it has to be objective-value.

Ok.

> explicit. I'm not convinced it needs a MUST though. Who can guess what people

Anything outside the objective-value is part of the GRASP spec, right ?
SO if someone invents a case for such a locator to be in a different namespace, then
that would have to be defined in an extension/revision to GRASP, right ?
== should be correct and safe to make the statement in the GRASP spec now.

> Hmm. I have a lot of changes stacked up in the XML. I'm quite keen to

Great.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Jun 2017 13:06:24 +1200

Just on one rather general point:

> explanatory text, which draft could that be ?

I think we may need a GRASP implementer's guide. Whether it should
be an RFC or a wiki page is a separate question.

I also guess we will need a GRASPbis document after a year or
two. That's life.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Jun 2017 14:25:42 +1200

>    this signaling element. Right ?

Unexpected optional parameters in the middle are awkward to parse,
so although it would be ugly, I'd tend to put it at the end.

<pause minutes="35"/>

OK, I implemented 
discovery-message = [M_DISCOVERY, session-id, initiator, objective, ?tcp-reply-port]
About ten lines of code affected. I have dummy ASAs running that can mix
and match with or without this field in the message.

Well, feedback please? Do we want to make a protocol change at this
late stage, or leave things as they are with the option to add
this later? Now I know how little coding is involved, I am 100%
open minded on this question.

   Brian