Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-06.txt

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Jun 2017 15:11:02 +1200

Hi,

About the GRASP usage in BRSKI:

> 3.1.1.  Proxy Discovery Protocol Details
> 
>    The proxy uses the GRASP M_FLOOD mechanism to announce itself.  This
>    announcement is done with the same message as the ACP announcement
>    detailed in [I-D.ietf-anima-autonomic-control-plane].

Can we make it:

  This announcement SHOULD be done with the same message...

That's only an optimisation, really. 

> 
>     proxy-objective = ["Proxy", [ O_IPv6_LOCATOR, ipv6-address,
>     transport-proto, port-number ] ]
> 
>     ipv6-address       - the v6 LL of the proxy
>     transport-proto    - 6, for TCP 17 for UDP
>     port-number        - the TCP or UDP port number to find the proxy

1. We need to agree on the objective name; at the moment the draft is
inconsistent. What's wrong with "AN_Proxy"? It also needs to go in the
IANA Considerations since it needs to be registered.

2. It would be better to make normative references for the items that
are taken directly from the GRASP spec:

ipv6-address: as defined in [I-D.ietf-anima-grasp] but REQUIRED to be link-local
transport-proto: as defined in [I-D.ietf-anima-grasp]
port-number: as defined in [I-D.ietf-anima-grasp]

> 3.1.2.  Registrar Discovery Protocol Details
> 
>    A Registrar is typically configured manually.  When the Registrar
>    joins an Autonomic Control Plane
>    ([I-D.ietf-anima-autonomic-control-plane]) it MUST respond to GRASP
>    ([I-D.ietf-anima-grasp]) M_NEG_SYN message.

That's kind of jumping into the middle. Perhaps start by saying
...it MUST support the GRASP objective "AN_registrar" for discovery
and synchronization.

>    The registrar responds to discovery messages from the proxy (or GRASP
>    caches between them) as follows: (XXX changed from M_DISCOVERY)
> 
>     objective         = ["AN_registrar", F_DISC, 255 ]
>     discovery-message = [M_NEG_SYN, session-id, initiator, objective]

No, that isn't a discovery message. In fact, it isn't a GRASP message
type at all. Now we need to decide whether you want to support GRASP
rapid mode. If not, there needs to be an M_DISCOVERY, followed
by an M_RESPONSE, followed by an M_REQ_SYN, followed by an M_SYNCH.
But you don't need to specify *any* of that, if you specify a GRASP
synchronization objective. It's just bog standard GRASP.

Similarly if you want to support rapid mode. Really, all you need to
specify is the format of the objective, the fact that it supports
synchronization, and whether it supports rapid mode.
>    Figure 6: Registrar Discovery
> 
>    The response from the registrar (or cache) will be a M_RESPONSE with
>    the following parameters:
>
>     response-message = [M_RESPONSE, session-id, initiator, ttl,
>     (+locator-option // divert-option), ?objective)]
>     initiator = ACP address of Registrar
>     locator1  = [O_IPv6_LOCATOR, fd45:1345::6789, 6,  443]
>     locator2  = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683]
>     locator3  = [O_IPv6_LOCATOR, fe80::1234, 41, nil]

So now I'm lost. Using  M_FLOOD gives you the option of attaching
arbitrary locators, but here you seem to be attaching arbitrary
locators to a response message. 

1) The initiator field in M_RESPONSE echoes the initiator
field in the M_DISCOVERY. That's non-negotiable because it's
required for matching responses to the correct discoverer.

2) The locators in M_RESPONSE are supposed to be GRASP locators
for starting a GRASP M_REQ_* session. It's kind of weird to use
them for communicationg the BRSKI locators. I can't see a big
reason why it won't work, but it needs to be called out explicitly.

(After the discussion back in Berlin, we added a feature to
M_FLOOD to allow arbitrary locators to be attached to a given
flood message. I thought that was what the BRSKI team wanted
at that time. Seems not.)

What I had assumed is that you'd return the BRKSI information as
the *value* of the "AN_registrar" objective. That would give
100% freedom, independent of GRASP inner workings. That's what
you have done in the "AN_proxy" objective. It would be simpler
to do the same here.

Also, 41 is not a protocol type defined in GRASP
today. And does protocol 6 actually mean TLS in this case?

Let me know your thoughts. I'm very willing to write text (and
Python demo code) but I need to know what you want that's consistent
with GRASP.

Regards
    Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Jun 2017 11:38:52 -0400

{note subject line change}

    >> detailed in [I-D.ietf-anima-autonomic-control-plane].

    bc> Can we make it:

    bc> This announcement SHOULD be done with the same message...
    bc> That's only an optimisation, really.

Agreed.  I think we all agree that the announcement of the proxy
(and the search for ACP peers) is something that M_FLOOD is good for.

    bc> (After the discussion back in Berlin, we added a feature to
    bc> M_FLOOD to allow arbitrary locators to be attached to a given
    bc> flood message. I thought that was what the BRSKI team wanted
    bc> at that time. Seems not.)

yes, we asked for two locators to be attached to a flood message so that we
could announce ACP and Proxy in the same message.  Given the experience
with rate limiting that you experienced, this seems doubly prudent since
this M_FLOOD will occur outside any ACP, and will have to traverse any
number of layer-2 devices.

(This will be worse at the beginning of ANIMA deployment, as the layer-2
devices will not be ACP aware, but will get better as more devices get with
the program...)

So, let's leave this part, which is
    https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-06#section-3.1.1

As there is no dispute about it, I think.
If it should be named AN_PROXY, that's fine.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Jun 2017 17:12:18 +1200

> If it should be named AN_PROXY, that's fine.

I think it does need some work on the way it's described, but I agree,
we are fine in principle on this point.

    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 17 Jun 2017 02:01:02 +0200

On Mon, Jun 12, 2017 at 11:38:52AM -0400, Michael Richardson wrote:
[reordering]
>     https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-06#section-3.1.1

1. I think those sections are incorrect wrt to the GRASP format. Here is whats in BRSKI -06:

The definition of M_FLOOD from grasp-13 is:

  flood-message =  [M_FLOOD, session-id, initiator, ttl,
                  +[objective, (locator-option / [])]]

  objective = [objective-name, objective-flags, loop-count, ?objective-value]
  objective-name = text ;see section "Format of Objective Options"
  objective-value = any

This means that we do not need to have a locator in the proxy objective because
the flood message already has the locator element outside the objective.

The second problem with -06 is that we need to be able to indicate different protocol
stacks, eg: TLS or (later) CoAP. 

In draft-carpenter-anima-ani-objectives, the proposal for the proxy-objective was therefore:

    assistant-objective = ["AN_join_assistant", F_SYNCH, 1, method]

    eg:
                          ["AN_join_assistant", F_SYNCH, 1, "BRSKI-TLS"]

Aka: The objective needs F_SYNCH, that standard objective parameter, the second parameter
is also mandatory loop-count (must be 1 for DULL)  and then "BRSKI-TLS" would be the value of
the proposed "method" parameter.

This is what i did put into the proposed -07 diffs that we are reviewing.

> devices will not be ACP aware, but will get better as more devices get with

2. If we send the M_FLOOD for BRSKI and ACP periodicially once every 30 seconds,
i don't think that we should be worried about sending one instead of two packets.

>From grasp-13 it seems that i can only put a single grasp-message into a single
UDP packets. And i can only put a single objective into a single grasp-message.

I don't think i want a single objective to announce both ACP and BRSKI. Those
are features of two different ASA. How would i implement this.

> If it should be named AN_PROXY, that's fine.

i have no strong opinion about the term, you pick ;-).

Cheers
    Toerless

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

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 17 Jun 2017 13:01:38 +1200

If the BRSKI team agree that you want a flood (i.e. unsolicited announcement)
for pledge<->proxy and discovery+synchronization request (i.e. solicited
announcement) for proxy<->registrar, I will suggest complete text for these,
and implement a Python demo version.

So, BRSKIsts please confirm what you want.

Regards
   Brian

---

From: Michael Richardson <[email-masked]>
Date: Sat, 17 Jun 2017 14:05:46 -0400

> and implement a Python demo version.

We want (LL) M_FLOOD for pledge<->proxy, and M_DISCOVERY for
proxy<->registrar.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 18 Jun 2017 12:58:53 -0400

> UDP packets. And i can only put a single objective into a single grasp-message.

Because we can announce multiple objectives.

    > are features of two different ASA. How would i implement this.

It would be a feature of the single, unpriviledged DULL instance.
That instance would be configured by some larger intent.

If a node doesn't want to announce itself as a proxy, it would omit that
objective.

As for implementation, I've done it. It's a question of about a page of C
code (given a cbor library), or about ten lines of ruby. Probably a similar
number of lines of python.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 19 Jun 2017 07:53:17 +1200

> number of lines of python.

I'm thinking that if we want to make a tiny extension to GRASP syntax for
this special purpose, we can do so in the BRSKI document. That's yet another
benefit of using CBOR.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 19 Jun 2017 09:36:04 -0400

> this special purpose, we can do so in the BRSKI document. That's yet
    > another benefit of using CBOR.

You added the +[] there so that we can announce multiple objectives.
I don't think that there is anything more to do in GRASP.

All we need to do is define the AN_Proxy objective, and ACP has to
define the AN_ACP objective.  I just don't see any problem here.