Re: [Anima] GRASP details - WGLC draft-ietf-anima-bootstrapping-keyinfra-15
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 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'fe81', 18, > [ ["AN_Proxy", 4, 1 ], > [O_IPv6_LOCATOR, > h'fe81', IPPROTO_TCP, 4443]], > [ ["AN_Proxy", 4, 1 ], > [O_IPv6_LOCATOR, > h'fe81', 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,
Re: [Anima] GRASP details - WGLC draft-ietf-anima-bootstrapping-keyinfra-15
On Fri, Jun 01, 2018 at 02:10:27PM -0400, Michael Richardson wrote: > > Toerless Eckert wrote: > > Anyhow. let me just list what i think is necessary to fi up the GRASP > so it works > > for both TLS and IPinIP. > > You seem to write TLS in a few places where TCP is actually called for. > To be more precise, it's static 1:1 destination NAT66, aka "port-forward" Hmm. I had only written TCP and then i saw your text using the term "ANI TLS circuit proxy", so then i was changing my proposed text to be compliant with that. > > 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. > > This would seem to be the only needed text to me. > > > 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). > > okay. > > > 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. > > I'm sorry, I don't even understand the problem. > Maybe someone else can translate for me. Ok, i think was also confused yesterday, but thats all because of the bloody IPPROTO_IPV6 in 4.1.1. So, if i understand it correctly after a fresh coffee, we should completely eliminate IPPROTO_IPV6 from 4.1.1, but we still need it for 4.3: So, the Pledge would never need to know anything about IPinIP, it would always only see the same type of Proxy announcement for AN_Proxy with BRSKI-TLS, or in the future BRSKI with UDP for use with CoAP. the only distinguishable difference would be the LL address the proxy announces: So, this would be an example GRASP message from a circuit proxy. The LL address in the locator is typically its "own" native link-local address, ike the one from which it originates this DULL GRASP message: a) [M_FLOOD, 7234567, h'fe80::1', 18, [ ["AN_Proxy", 4, 255 ], [O_IPv6_LOCATOR, fe80::1, 6, 443] ] ] Now instead, the proxy operates as an IPinIP proxy and the announcement might look like this: b) [M_FLOOD, 7234567, h'fe800::1', 18, [ ["AN_Proxy", 4, 255 ], [O_IPv6_LOCATOR, fe80::1234, 41, 4443] ] ] For the Pledge, no difference in its own behavior. But: 4.1.1 says right now, that the port-number is allocated by the Proxy. And the same is actually true for the LL address in the locator. But: If the Proxy is operating as LL proxy, then it is not the proxy allocating the LL address and the port-number, but instead it is the Registrar, the Proxy is just taking the information from the registrar GRASP announcement and copies it into its b) announcement to the Pledge - and of course set up locally the appropriate state: listen to fe80::1234 and forward packets received for it including filtering for only TCP packets to port 4443. Which still begs the question how the Proxy learned about the registrar to be able to create both the b) announcement to the Pledge and its own state. 4.3 argues seemingly that IPinIP proxy would need to receive the following two locators to get this information: locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 4443] locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil] Locator3 would tell the eProxy that the registrar supports IPinIP, and locator1 tells the Proxy that the IPinIP registrar support TLS BRSKI over port 4443 across IPinIP. And i said that in the way BRSKI-14 is written, individual GRASP AN_Join_registrar objecties do not have a way to encode these two locators together into a single objective. And also that i think you can not simply announce
Re: [Anima] GRASP details - WGLC draft-ietf-anima-bootstrapping-keyinfra-15
Toerless Eckert wrote: > Anyhow. let me just list what i think is necessary to fi up the GRASP so it works > for both TLS and IPinIP. You seem to write TLS in a few places where TCP is actually called for. To be more precise, it's static 1:1 destination NAT66, aka "port-forward" > 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. This would seem to be the only needed text to me. > 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). okay. > 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. I'm sorry, I don't even understand the problem. Maybe someone else can translate for me. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] naming of constrained voucher YANG model
what is wrong with going simple: “constrained voucher request” ?
- max
> On Jun 1, 2018, at 9:10 AM, Michael Richardson wrote:
>
>
> Michael Richardson wrote:
>> Also, a related question is whether ietf-cwt-voucher-request to inherit
>> from BRSKI's ietf-voucher-request, or from ietf-voucher... It's not
>> clear to me that it's a 100% subclass yet.
>
> So, the name started at "cwt-voucher-request", because it was originally
> thought that it would use CWT directly (RFC8392), using the Claim keys from
> there.
>
> Then after some distraction, the process is now a COSE signed SID generated
> YANG, which isn't exactly CWT at all.
>
> The name "cwt-voucher"{,-request} is no longer appropriate.
> Some constraction of "constrained" is probably now appropriate, looking for
> suggestions.
>
> It's also reasonable to say that we use CWT concepts when they map, and
> introduce new key ids via the YANG/SID mechanism. That's a significant
> design change, but it's not that huge.
>
> --
> ] Never tell me the odds! | ipv6 mesh networks
> [
> ] Michael Richardson, Sandelman Software Works| network architect
> [
> ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails
> [
>
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
