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

From: Michael Richardson <[email-masked]>
Date: Fri, 01 Jun 2018 14:10:27 -0400

Toerless Eckert <[email-masked]> 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  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 1 Jun 2018 21:04:36 +0200

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

> 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', 180000,
         [ ["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', 180000,
         [ ["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 these
locators separately via two GRASP AN_Join_register objectives because
that is not only bad style, but also ambiguous. A GASP objective with
locator1 would by itself not allow for proxies to know whether it is meant
to support curcit-proxy operations AND/OR IPinIP operations. And a Registrar
might support both curcuit-proxy Pledges AND IPinIP pleges but not on the
same TCP port, but potentially on different ports.

So, threefore i concluded, that the AN_Join_registrar GRASP objective needs
to have an encoding where all he necessary locators can be included in
a way that it is unambiguously differentiated from an AN_Join_registrar
announcement indicating support for circuit proxies.

So, what i proposed was that the locator-option field indicates the
primary locator for the supported proxy model. Aka: for "native" TCP/TLS
or UDP, its the locators with proto 6 or 17. For IPinIP its proto 41.

Then only the announcement for IPinIP will need to have one or more additional
locators, which indicate the proxy method and ports supported inside of
IPinIP. And the text proposed to encode those into the objective-value
field of the GRASP objective:

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

The first AN_join_registrar objective indicates this registrar supports circuit-proxies,
aka: native TLS connections across the ACP on TCP port 443.

The second AN_join objective indicates it support IPinIP. The two additional
locators in this objective indicate that TCP/TLS on port 4443 is supported
across IPinIP and the second one that probably CoAP/UDP is supported across
port 5683 (i have seen no explanation in BRSKI-14 what/how UDP would be used,
so i assume its for CoAP. Probably CoAP/dTLS/UDP ?).

Does this explains it better ?

Cheers
    Toerless

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 2 Jun 2018 09:54:53 +1200

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:
>>
>>     > 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.
> 
> 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.
>    
>        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.
> 
>         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. 
> 
>       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:
>      
>       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
> 
>> --

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 2 Jun 2018 00:13:00 +0200

On Sat, Jun 02, 2018 at 09:54:53AM +1200, Brian E Carpenter wrote:
> allows rubbish values).

Ok, but just permitting rubbish value does not mean anyone needs to use
rubbish values. And the pro argument is that it gives you for free all
the non-rubbish values that have been registered by IANA completely for free.

The only thing this says is that if you want to allocate a new value thats
not been registered by IANA and its ONLY needed for GRAASP locators and no
other locators, then you can use e.g.: the range 256...1024, and we
just need to find the right document to override the 0..255 sapce with 0..1024.

> I don't see why BRSKI can't just define the extra

Whats your logic for that conclusion ? My logic for thinking that it is
an extension is that we're defining something which is not a subset of what
GRASP did define. So for example even if i do define all possible
crazy structures for "objective-value", i still define a subset, because
GRASP defined it as "any".

> but I don't see the rush.

Right.

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

[...]

> syntax for this particular case. Which is fine, but just note it

Exactly. Of course not the only one. The whole syntax is full of
restriction.  "AN_Proxy" in the objective-name field is syntactically also a restriction.

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 2 Jun 2018 11:15:49 +1200

On 02/06/2018 10:13, Toerless Eckert wrote:

...

GRASP did define.

Yes, it's an extension, but does a simple extension require "Updates:"?
That is a question that is often asked and never definitively answered.
I think the answer can be "no", because a GRASP implementer really shouldn't
care about this. My GRASP code certainly doesn't; my toy BRSKI code does.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 2 Jun 2018 11:17:39 +1200

(Sorry, the quoting went wrong on the previous version of this message.)

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Jun 2018 15:24:16 -0400

> Ok. *sigh*. I guess i didn't quite get that. So, if we want to make
    > GRASP in BRSKI work correctly for IPinIP instead of just making it
    > sugestive, there are a bunch of fixes necessary.

I just don't see them.
I can't see any protocol changes necessary, and I can't understand how
the GRASP definition can change unless you want to re-open GRASP and create
an IANA registry on transport-proto.

    > You didn't like the idea of using
    > objective-value strings

As far as I understood, you seem to be asking us to invent a new protocol
that is not GRASP M_FLOOD, but looks almost, but not quite like it because
the CDDL syntax differs slightly.

    > the following extension to the syntax of [GRASP]:

We are removing Appendix C.
The document will go forward with NAT66 being the only described protocol for
the Join Proxy.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 22 Jun 2018 22:51:57 +0200

> an IANA registry on transport-proto.

I did send a detailled suggestion for changes in my original mail about this
issues. It would be easier if yo could reply inline to that email and comment
on the suggstion. I spent a good amount of effort there to explain how the
GRASp announcement needs to carry all the information so that we get the
right auto-discovery needed for IPinIP and proposed how it can easily be
encoded into the GRASP objective value.

None of this requires changing the GRASP RFC. This was all just the
objective-value. Thats the field that GRASP defines to cary the objective
specific information in. Aka: the mayority of any GRASP application
signaling wold be in the GRASP objective. In the GRSP RFC it's
defined to be "any", therefore obviously no update needed.

> the CDDL syntax differs slightly.

No, in my reply email i brought up multiple issue. The discussion about
expanding GRASP RFC only came up because the GRASP RFC didn't define
the transport field value in the header to be "ANY" or at least a large
enough numerical value, but only allowed an explicit set of numerical
values via their macros, and for IPinIP another value was needed. We
did lay that argument to rest so far by both Brian and you arguing that
the fact that anynumeric value is allowed in that wild should be deduced
fromt the comment.

So forget about GRAp RFC/header changes. This discus is only about the
IMHO necessary information in the objective-vale so GRASP for IPinIP
signals all the necessary information so the proxy can auto-configure itself
for IPinIP and also signl out the right GRASP info to the Pledge.

> The document will go forward with NAT66 being the only described protocol for

I think we should then be fine with BRSKI, but the discuss for how to
signal in GRASP for IPinIP would would come up when you do post a new
draft for IPinIP, which i hope does happen, because as i told you ,
i think those IPinIP proxies could actually be quite useful even beyond
bootstrap given how they are not state-limited as the NAT66 proxies.

Let me check if there was anything left with this decision to remove,
else i'll declare my comments done, and then i could put into IESG
shepherd writeup that we just need to get another rev with IPinIP and
related GRASP stuff removed (for followup work).o

Ok ?

Cheers
    Toerless