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

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

Hi,

Unfortunately this is still a little broken around both GRASP objectives,
in a way that needs to be fixed:

> 4.1.1.  Proxy Grasp announcements
> 
>    A proxy uses the GRASP M_FLOOD mechanism to announce itself.  The
>    pledge SHOULD listen for messages of these form.  This announcement
>    can be within the same message as the ACP announcement detailed in
>    [I-D.ietf-anima-autonomic-control-plane].
> 
> 
>     proxy-objective = ["AN_Proxy", [ O_IPv6_LOCATOR, ipv6-address,
>     transport-proto, port-number ] ]

That's not valid syntax for an objective. Also, in the Flood message you
have the option of associating a locator directly with the flooded
objective, as part of the basic message format. My suggestion:

The objective is defined in fragmentary CDDL as:

 registrar-objective = ["AN_Proxy", objective-flags, loop-count, null]

 objective-flags = ; as in the GRASP specification
 loop-count =  1   ; restricted to link-local use

 The objective-flags field is set to indicate synchronization.

 The loop-count is set to 1 to limit the scope of flooding
 to the local link.

 The value field is set to a null value.

In the GRASP Flood message, an IPv6 locator option is
associated with the objective as described in Section 2.8.11
of [I-D.ietf-anima-grasp]. The locator format is
 [O_IPv6_LOCATOR, ipv6-address, transport-proto, port-number]
where
>     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

Then there are more problems with this:

> 4.4.  Proxy discovery of Registrar
> 
>    The Registrar SHOULD announce itself so that proxies can find it and
>    determine what kind of connections can be terminated.
> 
>    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.

There is no such thing as M_NEG_SYN. Anyway this is a backwards
way of describing things. I think you should start with something
like:

When the Registrar joins an Autonomic Control Plane
[I-D.ietf-anima-autonomic-control-plane] it MUST be
ready to support the GRASP [I-D.ietf-anima-grasp]
object "AN_registrar" defined below. This is an
objective that supports only discovery; it does not
support synchronization or negotiation. When a proxy
sends a GRASP Discovery (M_DISCOVERY) message seeking
this objective, the Registrar SHOULD respond with a
GRASP Discovery Response (M_RESPONSE) message including
relevant locators as described below.

The objective is defined in fragmentary CDDL as:

 registrar-objective = ["AN_join_registrar", objective-flags,
                            loop-count, null]

 objective-flags = ; as in the GRASP specification
 loop-count =      ; as in the GRASP specification


 The objective-flags field is set to indicate discovery.

 The loop-count is set to a suitable value to limit the scope of
 discovery.  A suggested default value is 6.

 The value field is set to a null value.

>    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 ]

Why 255? Do you expect networks to be that big? Discovery
loops will be detected anyway, but I think a much more conservative
value is appropriate.

>     discovery-message = [M_NEG_SYN, session-id, initiator, objective]

Nope. M_DISCOVERY is needed. But anyway, what is the point of
replicating bog-standard GRASP here? Possibly in an appendix, but not
main text.

>    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)]

Here an example is more helpful than more cut-and-paste from
GRASP.

>     initiator = ACP address of Registrar

Wrong, another argument against redundancy.
See https://tools.ietf.org/html/draft-ietf-anima-grasp-15#section-2.8.5

>     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]

OK. This is fine in terms of GRASP syntax, although it's
a slightly special case of implying semantics within the
locators. The only problem is mine: my prototype code can't
do this without enhancement. I'd suggest giving the example
a bit more precisely, something like:

An example M_RESPONSE packet, following the GRASP syntax,
could be as follows:

 [M_RESPONSE, session-id, initiator, ttl,
 [O_IPv6_LOCATOR, fd45:1345::6789, 6,  443],
 [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683],
 [O_IPv6_LOCATOR, fe80::1234, 41, null]]

Also, technically, using proto = 41 extends the formal GRASP syntax.
We could let that slide, holding it in reserve for GRASP 2.0, or
we could at least note that it's an extension.
  
Regards
   Brian