Subject: [Anima-signaling] Draft message on proposed change to GRASP

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Apr 2016 08:50:46 +1200

Hi,

Design team, and Joel,

Some of us have been discussing a GRASP design issue raised by Toerless.
There was quite a long off-list thread (nothing secret, so if people are
interested we could make it available). But here is a draft of a proposal
to the WG. Please comment - especially, does the text make sense? The actual
decision belongs to the WG, of course.

Short version:

We propose that when an ASA listens for negotiation or synchronization requests,
it should do so on its own port number rather than sharing the generic GRASP
port number as currently defined. The consequence for the protocol is that
discovery responses must include a complete transport address (locator+port)
instead of just the locator.

Long version:

We want ASAs to run as separate modules in user address space, as applications,
rather than being bundled with the GRASP engine in kernel space. To achieve this
with all ASAs listening on the same port number would require quite complicated
inter-process communication between the GRASP kernel and the indvidual ASAs.
The details of this would be different in every operating system. If we
allow each ASA to have its own port this can be avoided, and each ASA can have
its own copy of the GRASP API library if required. This will make the systems
engineering of portable ASAs much easier, and will make the adaptation of
the GRASP API library and the GRASP kernel to various operating systems easier
too.

We propose to redefine the locator returned by GRASP discovery accordingly. For
the IPv6 case that would give:

locator-option /= [ipv6-locator-option, port-number]
ipv6-locator-option = bytes .size 16
port-number = 0..65535

We did consider making this optional, but that would raise interoperability
issues. If an implementation does choose to use the GRASP_LISTEN_PORT
for all ASAs, that could simply be returned as the port-number.
(Alternatively, we could define that port-number==0 means GRASP_LISTEN_PORT,
but that seems like optimisation of a corner case.)

Implementation note:

An ASA will obtain an ephemeral port number when it starts up and that
will be used in discovery responses. If more than one transport protocol
is to be used, it will need to secure the same port number for each protocol.
For example, if it gets port X when binding to a TCP socket, it must then
bind to port X on a UDP socket.

Note:

Toerless Eckert brought up this problem and outlined the proposed solution.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 22 Apr 2016 08:37:24 -0400

> ipv6-locator-option = bytes .size 16

This is a good thing.
Also consider that the ACP addressing document can provide a multitude
(a /96 was suggested) of IPv6 addresses to each node.

Is equality of the ipv6-locator-option important anywhere for saying that two
conversations involve the same speakers?  or is there another identifier
available?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Apr 2016 08:29:00 +1200

>     > ipv6-locator-option = bytes .size 16

OK, I'll wait a day or two for other opinions. Also I think there is
a case for including the protocol (TCP, UDP or theoretically some other
transport). If an ASA supports both TCP and UDP it could return two
discovery responses.

> conversations involve the same speakers?  or is there another identifier

That's a complicated question. I don't think it affects the current protocol
design, which discovers and caches addresses per objective anyway. A node could
contain numerous ASAs and they each could support several Objectives, and if they
each had a different IP address, GRASP wouldn't care. But it gets back to trust.
At the moment we're assuming that if a node is trusted, all the ASAs in it are
equally trusted, so we don't seem to need an additional identifier. If that
changed, I think we'd have to re-invent the former Device Identity Option in
GRASP in a slightly different form.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Apr 2016 12:24:10 +1200

> transport). If an ASA supports both TCP and UDP it could return two

The more I thought about it, the better it seemed to take that approach.
So then I thought about how that would affect message syntax, and this is
the CDDL that I came up with:

locator-option /= [O_IPv4_LOCATOR, ipv4-address, transport-proto, port-number]
ipv4-address = bytes .size 4
locator-option /= [O_IPv6_LOCATOR, ipv6-address, transport-proto, port-number]
ipv6-address = bytes .size 16
locator-option /= [O_FQDN_LOCATOR, text, transport-proto, port-number]
transport-proto = IPPROTO_TCP / IPPROTO_UDP
IPPROTO_TCP = 6
IPPROTO_UDP = 17
port-number = 0..65535
locator-option /= [O_URI_LOCATOR, text]

To allow somewhat regular parsing, I had to include O_IPv4_LOCATOR
and O_IPv6_LOCATOR option codes. I didn't include protocol and port for
URIs because that would be redundant.

Is this implementable? Yes, I changed my code yesterday and it works.
In fact, with this fix, I can run two copies of GRASP in the same
machine and they can negotiate with each other. I ran my ASA Briggs
and ASA Gray modules in one machine and they happily negotiated
for half an hour, until I got bored watching.

(However, I haven't restructured the code to clearly separate the part
that could be in userland from the part that must be in kernel space.)

So, are we good to propose this to the WG?

Regards
    Brian