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

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

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