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

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

Just an update on this.

1) I missed a couple of inconsistencies below, noted in line.
2) I updated the GRASP prototype to support the previously
missing features used below. I update my demo ASAs for the
pledge, proxy and registrar roles. They work.

I need to do quite a bit more testing before pushing the
updated code to GitHub, but basically I think the GRASP
aspect of BRSKI is good to go.

On 18/10/2017 16:19, Brian E Carpenter wrote:
> 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]

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

 registrar-objective = ["AN_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.

   Brian