Re: [Anima] GRASP details - WGLC draft-ietf-anima-bootstrapping-keyinfra-15

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

Comments on three points in line:

On 01/06/2018 18:23, Toerless Eckert wrote:
> Ok, lets separate out the threads here.
> 
> On Thu, May 31, 2018 at 03:35:31PM -0400, Michael Richardson wrote:
>>
>> Toerless Eckert <[e-mail]> wrote:
>>     > 1. The GRASP specification of 4.1.1 should only describe what is required
>>     > and valid for the standard of GRASP objective, which is the TCP proxy.
>>
>>     > Appendix C proxy option is not full/formally worked out, thats why
>>     > its in an appendix. If the authors want to propose a formal GRASP
>>
>> It's not mandatory to implement, which is why it got pushed to the appendix.
>> If it wasn't worked out, then it would be removed.
> 
> Ok. *sigh*. I guess i didn't quite get that. So, if we want to make GRASP in BRSKI
> fwork correctly for IPinIP instead of just making it sugestive, there are a bunch
> of fixes necessary. Some of them where part of the shepherd review suggestion
> you dismissed as bikeshed. You didn't like the idea of using objective-value strings
> to identify the proxy method. But the fix i suggested also fixed other GRASP
> details.
> 
> Anyhow. let me just list what i think is necessary to fi up the GRASP so it works
> for both TLS and IPinIP.
> 
> let me know if/how i can best help to get this done,I'd be happy to write up a
> diff if we can finally get through this.
> 
> Proposed changes to 4.1.1:
> 
>    Note: This 4.1.1 text fixes are not complete wrt. to the IPinIP port
>    constraints you seem to want to have according to the 4.2 text. See below
>    for the 4.2 text discus, and if thats fine with you, then of course, we would
>    also need to incude the locator-options for permitted TCP/UDP ports of the IPinIP
>    proxy into the 4.1.1 AN_Proxy objective, because otherwise the Pledge wouldn't
>    know which TCP or UDP (address)/port numbers to use across the IPinIP proxy (i think).
> 
>    a) Insert after:
>       | A proxy uses the DULL GRASP M_FLOOD mechanism to announce itself.
>       | This announcement can be within the same message as the ACP
>       | announcement detailed in [I-D.ietf-anima-autonomic-control-plane].
> 
>       The optional IPinIP proxy as described in Appendix C requires
>       the following extension to the syntax of [GRASP]:
> 
>       transport-proto /= IPPROTO_IPINIP
>       IPPROTO_IPV6 = 41  ; [RFC2473]
> 
>       Figure xx: GRASP syntax extensions for BRSKI
> 
>       Note: Process wise we might need to declare BRSKI RFC to be an update to
>       GRASP RFC because of these two lines, but i would just wait until this gets
>       discussed with IANA and then suggest that we change instead GRASP before
>       it becomes RFC to: 
> 
>        transport-proto = 0..255

I'm really reluctant to do that for the reason I gave yesterday (it
allows rubbish values). I don't see why BRSKI can't just define the extra
value that it needs. That doesn't really require an "Updates:" IMHO.

I do want to revisit this later, very likely by adding an IANA registry,
but I don't see the rush.

> 
>       Aka: that way we can define IPPROTO_IPV6 perfectly in BRSKI without
>       extending GRASP (IMHO). We can still later on expend it beyond 255 when we need to,
>       but thats not a BRSKI RFC problem then anymore.

Yes, I think that's true in any case.

    Brian
> 
>    b) Change:
>       | The M_FLOOD is formatted as follows:
> 
>       To:
>       An example of M_FLOOD (without ACP) is as follows:
> 
>       (aka: "is formatted as" is not the correct lead in for an example).
> 
>    c) Fix up example picture:
> 
>       [M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
>           [ ["AN_Proxy", 4, 1 ],
>             [O_IPv6_LOCATOR,
>              h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]],
>           [ ["AN_Proxy", 4, 1 ],
>             [O_IPv6_LOCATOR,
>              h'fe800000000000000000000000000001', IPPROTO_IPV6, 0]] ]
>       
>       Figure 6b: AN_Proxy Example
> 
>       This is actually multiple fixes
>        - Better title for picture (match AN_Proxy with following
>          CDDL picture title and 'example')
>        - the objective-value is not used, so "" for objective-value
>          is not really correct IMHO, the field is just not encoded:
>           ["AN_Proxy", 4, 1, "" ] -> ["AN_Proxy", 4, 1 ] 
>        - I think it helps a lot to understand how to announce
>          multiple proxy options, so i highly suggest to have the
>          above example include the TCP circuit proxy and IPinIP options.
>        - Whether or not you use one or two objective announcements,
>          you always need one more structure level around objective
>          and locator-option according to GRASP syntax,
>          aka:
>          changed:    ["AN_Proxy", 4, 1 ], ... 4443]
>          to:       [ ["AN_Proxy", 4, 1 ], ... 4443] ]

Yes. I thought that had already been caught.
      
>    c) Fix syntax:
>        from: flood-message = [M_FLOOD, session-id, initiator, ttl,
>                            +[objective, (locator-option / [])]]
> 
>        to:  flood-message = [M_FLOOD, session-id, initiator, ttl,
>                            +[objective, locator-option ]]
>        
>        Aka: for this objective, locator-option is not optional,
>        but mandatory, because it indicates the proxy-type via the
>        transport-type which is part of the locator-option.

That isn't a fix to the GRASP syntax, it's a *restriction* of the
syntax for this particular case. Which is fine, but just note it
as a restriction.


> 
>     d) from: locator         = [ O_IPv6_LOCATOR, ipv6-address,
>        to:   locator-option  = [ O_IPv6_LOCATOR, ipv6-address,
> 
>        textual consistency with prior use of locator-option and GRASP RFC.
>    
>     e) Add at end of 4.1.1 suggested text:
>        
>        The transport-proto of the locator-option indicates the mechanism(s)
>        supported by the proxy to the pledge. IPPROTO_TCP indicates the
>        mandatory ANI TLS circuit proxy. IPPROTO_IPV6 indicates the optional
>        IPinIP proxy, see Appendix C. IPPROTO_UDP would indicate a future
>        CoAP mechanism, see Section 4.2. For IPPROTO_IPV6, proto-number
>        MUST be 0.
>       
>        The above example shows a proxy supporting both ANI TLS circuit proxy
>        and IP in IP proxy.
> 
>        Notes:
> 
>        I hope i understand the IP in IP proxy correctly, but given that
>        there is no port number in IPinIP, and given that port-number is
>        mandatory in GRASP syntax in this case, 0 seems to be the logical
>        number to use for port-number in this case.
> 
>        I am just guessing you want IPPROTO_UDP to indicate CoAP in the
>        future. If so, then it would be prudent to notice this here,
>        otherwise describe what IPPROTO_UDP should mean, and if there is
>        no predefined meaning, just remove it from the CDDL syntax.
> 
>    f) If you do not fancy to include the IP in IP example and text in
>       4.1.1, then i would strongly suggest to remove ALL indications of
>       IP in IP, including the mentioning of IPPROTO_IPv6 from 4.1.1
>       (also the extension to the GRASP syntax) - and instead put that
>       all into appendix C. Your choice. I think the text is more succinct
>       if all the grasp stuff is clearly in 4.1.1.
>       
> 2) Changes for 4.3
> 
>    a) The objective-value "EST-TLS" serves no purpose and is wrong.
>       Please remove it from the syntax, ak: no objective-value, like
>       also no objective-value in 4.1.1
>       - Its unnecessary, because if its used for all possible methods
>         (TLS, IPinIP, ..) then it doesn't provide additional information
>         and is redundant.
>       - It is wrong, because the protocol would not just be EST, but BRSKI.
>       - It is wrong, because for CoAP there would be no TLS.
> 
>    b) Please consider improving the example as above for 4.1.1:
>       - lead in text for example
>       - example title
>       - [ [ objective, locator-option ] ] structure fix
>       - Ideally also include both TLS and IPinIP options in example
> 
>       Also:
>       - I find the use of port 80 in the example highly confusing given how
>         the TCP connection MUST use TLS. Please change to AB80 (anything but 80).
> 
>    c) The CDDL syntax should be more consistent with 4.1.1:
>       - locator-option not optional
>       - locator, ipv6-address, transport-proto, port-number could
>         be included in syntax.
>     
>    d)  "network administrator policy (EST server configuration)"
> 
>        You where making during ACP review the point that BRSKI Registrar (for enrollment)
>        would not necessarily be the same as the EST server for cert renewal,
>        therefore the mentioning of "EST server" is confusing. would be
>        less confusing if the term (BRSKI) Registrar was used everywhere,
>        and "EST server" only when there is a real reason. 
> 
>    e)  "A protocol of 41 indicates that packets may be IPIP proxy'ed"
> 
>        So, unless we get back to my shepherd review "bikeshed" of introducing
>        different objective value strings for different proxy methods,
>        the "transport-proto" is the only way for the proxy to identify the
>        method, so this sentence needs to say "will be" instead of "may be".
> 
>        Also: Delete following "In the case of that IPIP proxying is used, then".
> 
>        Also: "MUST be advertised on the" -> "MUST be advertised by the Proxy on the".
>    
>    f) the mechanism you are describing with locator1, locator2 and locator3
>       would be highly obfuscated:
> 
>       In GRASP, every objective can have only one locator as seen from the syntax.
>       What you are proposing would mean that you are announcing three separate
>       AN_join_registrar objectives (of course, they can all be together in a single 
>       M_Flood), but then effectively you're saying that those three objectives
>       do really describe a single IPinIP mechanism. 
> 
>       So, your full example locators with objectives would be:
> 
>        [["AN_join_registrar", 4, 255], [O_IPv6_LOCATOR, fd45:1345::6789, 6,  443]] ]
>        [["AN_join_registrar", 4, 255], [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683] ]
>        [["AN_join_registrar", 4, 255], [O_IPv6_LOCATOR, fe80::1234, 41, 0] ]
> 
>       Is this join registrar supporting ANI TLS proxy ?
>       Aka: i can't distinguish for the TCP locator whether it just indicates
>       a permitted TCP port for the IPinIP proxy or whether it indicates
>       the TCP port supported for IPinIP. And even if the proxy supports both,
>       its not clear to me that the TCP ports for "native" would be the same as
>       for IPinIP. Maybe its different code-paths == different ports.
> 
>       Likewise UDP port could be CoAP proxy or again a parameter for IPinIP.
> 
>       I would suggest to only use a single objective for IPinIP, aka: the line with
>       41, 0, and encode the TCP/UDP locators to use inside of the IPinIP proxy
>       mechanisms as the objective-value when using the IPinIPi method:
> 
>       objective-value = *( [ ipv6-locator-option ] ) ; only for IPinIP proxy
>       
>       Then we could show an example like this:
>      
>       [M_FLOOD, 12340815, h'fda379a6f6ee00000200000064000001', 180000,
>         [ ["AN_join_registrar", 4, 255 ],
>           [O_IPv6_LOCATOR, h'fda379a6f6ee0::200000064000001', 6, 443]
>         ],
>         [ ["AN_join_registrar", 4, 255,
>             [[O_IPv6_LOCATOR, h'fda379a6f6ee0::200000064000001', 6, 4443],
>              [O_IPv6_LOCATOR, h'fda379a6f6ee0::200000064000001',17, 5683]]
>           ],
>           [O_IPv6_LOCATOR, fe80::1234, 41, 0]
>         ]
>       ]
> 
>       That would include your two constraining locators for the IPinIP proxy
>       and separately the "native" circuit proxy.  And as mentioned in the
>       intro for 4.1.1, the same structure of information for the IPinIP proxy
>       would be necessary for AN_Proxy.
> 
> 
> I'll stop here. Let me know what you think. I'll be happy to help apply the
> fixes / send diff if this is ok. with you.
> 
> Cheers
>     Toerless
> 
>> -- 
>> ]               Never tell me the odds!                 | ipv6 mesh networks [ 
>> ]   Michael Richardson, Sandelman Software Works        | network architect  [ 
>> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [ 
>> 	
> 
> 
> 
>> _______________________________________________
>> Anima mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/anima
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima
>