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 <[email protected]> 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
>> [
>> ] [email protected] http://www.sandelman.ca/ | ruby on rails
>> [
>>
>
>
>
>> _______________________________________________
>> Anima mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/anima
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
