Subject: [Anima] WGLC for draft-ietf-anima-constrained-join-proxy-04, ends October 14th 2021

From: Sheng Jiang <[email-masked]>
Date: Fri, 1 Oct 2021 10:03:27 +0000

Hi all,

This message starts the two-week ANIMA Working Group Last Call to advance draft-ietf-anima-constrained-join-proxy-04, Constrained Join Proxy for Bootstrapping Protocols. This document's intended status is Standards Track. At present, there is no IPR file against this document. This document has been ANIMA WG document since September, 2018 and have received a few good review. The authors have addressed all known comments and think the document is ready for WGLC.

Please send your comments by October 14th, 2021. If you do not feel this document should advance, please state your reasons why.

Sheng JIANG is the assigned document shepherd.

Regards,

Sheng

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 3 Oct 2021 17:01:00 +1300

Hi,

I've looked at this from the GRASP point of view and it all seems fine.
It's perhaps worth noting that GRASP DULL discovery is quite independent
of both CoAP and DTLS. As far as I know, DTLS still can't protect
multicast, so there is no alternative to DULL.

(Something the WG should perhaps consider at some point is GRASP over
CoAP, but that is a very separate discussion.)

Nits:

There are multiple occurrences of "Autonomous Network". In ANIMA, we're
using "Autonomic Network".

Regards
   Brian Carpenter

On 01-Oct-21 23:03, Sheng Jiang wrote:
> Hi all,
> 
>  
> 
> This message starts the two-week ANIMA Working Group Last Call to advance draft-ietf-anima-constrained-join-proxy-04,Constrained Join Proxy for Bootstrapping Protocols. This document's intended status is Standards Track. At present, there is no IPR file against this document. This document 
has been ANIMA WG document since September, 2018 and have received a few good review. The authors have addressed all known comments and think the document is ready for WGLC.
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Esko Dijk <[email-masked]>
Date: Mon, 11 Oct 2021 10:08:13 +0000

Dear WG, authors, Sheng,

Below my review comments for the draft. Based on this it looks to me not yet ready for publication. Also, the document has had little review from the WG so far I could see.
But it has clearly improved since my last review and it looks like it could be ready on the next iteration.

Regards
Esko

*** Entire document

- Terminology should be made consistent: "Join Proxy", "Join-Proxy", "Join_Proxy" - with same capitalization also.
- And also if possible make consistent the wording '"join" port' vs 'join port' vs '"Join" port'.
- "cbor" -> "CBOR"

*** Sections 1-6
Nit "togther"
-> together

"The content fields are DTLS encrypted."
-> there is only one content field; make this singular.

Figure 5: "it includes additional IP-addresses" -> rephrase, "additional data fields" or so. There's only one ip address inside.

" In particular this section replaces section 4.1 of [RFC8995]."
-> does this mean it formally updates RFC 8995? If so we have to mark this draft as "updates RFC 8995" in the header. If not, why not? (Maybe someone in the WG can explain this well)

*** Section 7

the 2 steps are both numbered "1."  Step 1. should have a descriptive short title also, now it is just called "Two alternatives".
It could be clarified how the Pledge would choose between the two alternatives. For example, it typically doesn't know whether case 1a or case 1b applies.  So will the Pledge first try 1a? Or first 1b? And if the first attempt fails, try the other (1a/1b) ?
Maybe we can say this is left to implementation.  I have a suggestion in Section 9.1 (see below) to make this simpler: the Pledge will only discover for rt=brski and will find either a true Registrar or a Join Proxy that "appears" to be a Registrar even though it isn't itself.
This will make the procedure simpler and is even correct in the rt sense (see below 9.1 comments).

In step 2, " Once enrolled, the Join Proxy discovers the join port of the Registrar." I'm a bit confused about what "Once enrolled" means here. Once the Pledge is enrolled?  Or do we mean once the Join Proxy is enrolled? (Given that a Pledge could become Join Proxy after its enrollment.)
I would clarify this to "The Join Proxy discovers the join port of the Registrar. The Join Proxy may do this at the moment it needs to relay a DTLS message to the Registrar, or it may do this discovery already in advance."

" threa" -> "three"

7.2.1 " The Pledge MUST listen for GRASP M_FLOOD [RFC8990] announcements" -> this MUST requirement is only for a Pledge that uses GRASP / ACP. 
We could formulate that in a similar way as in RFC 8995, e.g. "This section is normative for uses with an ANIMA ACP."

Nit: I would keep the order of the 3 technologies the same in Section 7.1.* and 7.2.* . For example always do the subsections in the order as announced in 7.2: " coap discovery, 6tisch discovery and GRASP discovery".

7.2.3: text says " Not applicable."   Why would a 6tisch Pledge have no need to discovery the Join Proxy? Surely there is something, maybe only sending a 802.15.4 beacon request or so to get a response from a neighbor Join Proxy?
Maybe briefly explain why not applicable. E.g. in that case how does the Pledge know which of multiple networks/Join Proxies to contact.

7.3: title of section seems wrong? In Section 7 we announce the following 3 cases: 
   Three discovery cases are discussed: Join_proxy discovers Registrar,
   Pledge discovers Registrar, and Pledge discovers Join-proxy.

So I would suggest we have these titles approximately, and set in the right order as announced:
    7.1 Join proxy discovers Registrar
    7.2 Pledge discovers Registrar
    7.3 Pledge discovers Join Proxy

7.3.1: "The discoverable port numbers are usually returned for Join Proxy
   resources in the <href> of the payload (see section 5.1 of
   [I-D.ietf-ace-coap-est])."
-> I don't see href mentioned in Section 5.1. So this statement isn't clear enough.  Note that the part between angle brackets, if you mean this, is called URI-Reference in Core Link Format. That contains the port number. We can also mention
that the string "join-port" in the example above will be the port number.

*** Section 8
" communication is between the Proxy and a known registrar are over the
   already secured portion of the network, so are not visible to
   eavesdropping systems"
-> should be a little bit more specific: only the L2 encryption of the (mesh) network protects this traffic, usually with a shared key that has a rather wide distribution over many nodes.  There's no DTLS or other one-to-one protection. On-network eavesdroppers and attackers can access this header information.

Typo " communicatione" 

" If the communicatione between Join-Proxy and Registrar passed over an
   unsecure network, then an attacker could change the cbor array,
   causing the Pledge to send traffic to another node."
-> true, if the mesh is not L2-secured then an off-mesh attacker could sniff it and possibly modify it.
We have to consider also that the attacker could be on-mesh; and then a similar consideration applies. 

*** Section 9
This section seems incomplete! The CBOR map elements registry should be given its own subsection 9.x. And it should be clearly explained what the Registry defines including initial values.
I'm also missing here the registration of the "JPY protocol" in the "Service Name and Transport Protocol Port Number Registry" since it really is a new protocol with own particular format.

9.1: the registered resource types (rt) would typically use some hierarchy in naming with dots to denote hierarchy. See the current entries in the registry: https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#rt-link-target-att-value
For constrained-BRSKI we have defined "brski", "brski.vs", "brski.rv", etc.

So to stay with existing conventions we could use such names.  One observation is that the Join Proxy in fact offers *all* BRSKI functions that the Registrar offers, but then proxied.
Such a case can be readily advertised using the "brski" resource type (rt). This type is defined in draft-ietf-anima-constrained-voucher . There's no need to differentiate the name here from "brski" because it just advertises generic BRSKI functionality and that is what the Join Proxy offers, simply put.
So that means the Join Proxy makes it appear as if BRSKI functions are being offered on its Join Port, so it appears to be itself the Registry offering all these functions. The Pledge may be completely unaware whether it's talking to a Join Proxy or to a real Registrar, and it wouldn't even care.

In case this loss of transparency (not knowing whether we have a case of real-Registrar vs proxy-to-Registrar) is a problem (if so I would be glad to find out why!), we can adapt the naming to say "brski.jp" or "brski.proxy" to denote a Join Proxy that is offering generic BRSKI functionality by relaying to a Registrar.
Furthermore, on the Registrar side (Stateless "Join" port for receiving JPY protocol messages)  we can have "brski.rjp" or so (rjp = "Registrar Join Port") or "brski.jpy".

-----Original Message-----
From: Anima <[email-masked]> On Behalf Of Brian E Carpenter
Sent: Sunday, October 3, 2021 06:01
To: Sheng Jiang <[email-masked]>; Anima WG <[email-masked]>
Cc: [email-masked]
Subject: Re: [Anima] WGLC for draft-ietf-anima-constrained-join-proxy-04, ends October 14th 2021

Hi,

Nits:

Regards
   Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Oct 2021 08:37:56 +1300

Esko,

> Also, the document has had little review from the WG so far I could see.

True. Maybe we should also ask for an early review by the Security Area? This is a rather specialised topic, and I'm not sure this WG has many people with the skills needed for an independent review.

Regards
   Brian Carpenter

---

From: Esko Dijk <[email-masked]>
Date: Tue, 12 Oct 2021 06:50:43 +0000

Yes that could certainly be useful! I feel we should ask it after (most of) the current review comments are addressed: currently some parts are confusing to a reader, and some content is still missing in Sections 8 and 9.

Best regards
Esko

-----Original Message-----
From: Brian E Carpenter <[email-masked]> 
Sent: Monday, October 11, 2021 21:38
To: Esko Dijk <[email-masked]>; Anima WG <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Anima] WGLC for draft-ietf-anima-constrained-join-proxy-04, ends October 14th 2021

Esko,

Regards
   Brian Carpenter

---

From: Peter van der Stok <[email-masked]>
Date: Wed, 13 Oct 2021 09:35:15 +0200

HI Brian,

thanks,
autonomous -> autonomic it is now.

cheerio,

Peter
Brian E Carpenter schreef op 2021-10-03 06:01:

>> This message starts the two-week ANIMA Working Group Last Call to 
>> advance draft-ietf-anima-constrained-join-proxy-04,Constrained Join 
>> Proxy for Bootstrapping Protocols. This document's intended status is 
>> Standards Track. At present, there is no IPR file against this 
>> document. This document
> has been ANIMA WG document since September, 2018 and have received a 
> few good review. The authors have addressed all known comments and 
> think the document is ready for WGLC.
> 
>> Please send your comments by October 14th, 2021. If you do not feel 
>> this document should advance, please state your reasons why.
>>

---

From: Peter van der Stok <[email-masked]>
Date: Wed, 13 Oct 2021 14:30:45 +0200

HI Esko,

thanks for this review.
Glad to read that you think it is moving in the rigth direction.
A new version is available on github.

reactions below.

cheerio,

Peter
Esko Dijk schreef op 2021-10-11 12:08:

> Dear WG, authors, Sheng,
> 
> Below my review comments for the draft. Based on this it looks to me 
> not yet ready for publication. Also, the document has had little review 
> from the WG so far I could see.
> - Terminology should be made consistent: "Join Proxy", "Join-Proxy", 
> "Join_Proxy" - with same capitalization also.
> ->PvdS  DONE!
> -> Pvds Done.
> ->PvdS adapted.
> Figure 5: "it includes additional IP-addresses" -> rephrase, 
> "additional data fields" or so. There's only one ip address inside.
> 
> ->PvdS adapted
> 
> -> does this mean it formally updates RFC 8995? If so we have to mark 
> this draft as "updates RFC 8995" in the header. If not, why not? (Maybe 
> someone in the WG can explain this well)
> 
> -Pvds adapted; an extension is meant.
> 
> *** Section 7
> 
> the 2 steps are both numbered "1."  Step 1. should have a descriptive 
> short title also, now it is just called "Two alternatives".
> It could be clarified how the Pledge would choose between the two 
> alternatives. For example, it typically doesn't know whether case 1a or 
> case 1b applies.  So will the Pledge first try 1a? Or first 1b? And if 
> the first attempt fails, try the other (1a/1b) ?
> Maybe we can say this is left to implementation.  I have a suggestion 
> in Section 9.1 (see below) to make this simpler: the Pledge will only 
> discover for rt=brski and will find either a true Registrar or a Join 
> Proxy that "appears" to be a Registrar even though it isn't itself.
> In step 2, " Once enrolled, the Join Proxy discovers the join port of 
> the Registrar." I'm a bit confused about what "Once enrolled" means 
> here. Once the Pledge is enrolled?  Or do we mean once the Join Proxy 
> is enrolled? (Given that a Pledge could become Join Proxy after its 
> enrollment.)
> I would clarify this to "The Join Proxy discovers the join port of the 
> Registrar. The Join Proxy may do this at the moment it needs to relay a 
> DTLS message to the Registrar, or it may do this discovery already in 
> advance."
> 
> ->PvdS Restructured the text and lay-out
> 
> " threa" -> "three"
> 
> ->PvdS Done.
> 
> 7.2.1 " The Pledge MUST listen for GRASP M_FLOOD [RFC8990] 
> announcements" -> this MUST requirement is only for a Pledge that uses 
> GRASP / ACP.
> We could formulate that in a similar way as in RFC 8995, e.g. "This 
> section is normative for uses with an ANIMA ACP."
> 
> ->PvdS added three times.
> 
> Nit: I would keep the order of the 3 technologies the same in Section 
> 7.1.* and 7.2.* . For example always do the subsections in the order as 
> announced in 7.2: " coap discovery, 6tisch discovery and GRASP 
> discovery".
> 
> 7.2.3: text says " Not applicable."   Why would a 6tisch Pledge have no 
> need to discovery the Join Proxy? Surely there is something, maybe only 
> sending a 802.15.4 beacon request or so to get a response from a 
> neighbor Join Proxy?
> Maybe briefly explain why not applicable. E.g. in that case how does 
> the Pledge know which of multiple networks/Join Proxies to contact.
> 
> -> I don't see href mentioned in Section 5.1. So this statement isn't 
> clear enough.  Note that the part between angle brackets, if you mean 
> this, is called URI-Reference in Core Link Format. That contains the 
> port number. We can also mention
> -> Pvds Section 7 is a bit of a mess.; section 7 is restructured and 
> rephrased
> 
> *** Section 8
> -> should be a little bit more specific: only the L2 encryption of the 
> (mesh) network protects this traffic, usually with a shared key that 
> has a rather wide distribution over many nodes.  There's no DTLS or 
> other one-to-one protection. On-network eavesdroppers and attackers can 
> access this header information.
> 
> Typo " communicatione"
> 
> -->PvdS  done
> 
> -> PvdS clarified this section
> 
> *** Section 9
> ->PvdS  Your section 9 comments are a bit difficult to follow for me.
> 
> This section seems incomplete! The CBOR map elements registry should be 
> given its own subsection 9.x. And it should be clearly explained what 
> the Registry defines including initial values.
> 
> ->PvdS What CBOR map? Do you mean the CBOR array sent between J-P and 
> R? Completely at a loss here.
> 
> I'm also missing here the registration of the "JPY protocol" in the 
> "Service Name and Transport Protocol Port Number Registry" since it 
> really is a new protocol with own particular format.
> 
> ->PvdS I really don't see why we need the additional complexity of 
> registering the protocol.
> - We do not propose it to be used for new specifications
> - We do not need it to protect magic numbers. RT values are registered, 
> ports are discovered.
> 
> 9.1: the registered resource types (rt) would typically use some 
> hierarchy in naming with dots to denote hierarchy. See the current 
> entries in the registry: 
> https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#rt-link-target-att-value
> So to stay with existing conventions we could use such names.  One 
> observation is that the Join Proxy in fact offers *all* BRSKI functions 
> that the Registrar offers, but then proxied.
> 
> -> PvdS Here follows my rant.
> There is no such thing as a convention for rt values. I have asked two 
> or three times on core ML if people are interested to author or 
> co-author such a document. I even approached people individually, but 
> no one sees the necessity.
> So, there is no convention to adhere to.
> 
> Such a case can be readily advertised using the "brski" resource type 
> (rt). This type is defined in draft-ietf-anima-constrained-voucher . 
> There's no need to differentiate the name here from "brski" because it 
> just advertises generic BRSKI functionality and that is what the Join 
> Proxy offers, simply put.
> So that means the Join Proxy makes it appear as if BRSKI functions are 
> being offered on its Join Port, so it appears to be itself the Registry 
> offering all these functions. The Pledge may be completely unaware 
> whether it's talking to a Join Proxy or to a real Registrar, and it 
> wouldn't even care.
> 
> In case this loss of transparency (not knowing whether we have a case 
> of real-Registrar vs proxy-to-Registrar) is a problem (if so I would be 
> glad to find out why!), we can adapt the naming to say "brski.jp" or 
> "brski.proxy" to denote a Join Proxy that is offering generic BRSKI 
> functionality by relaying to a Registrar.
> Furthermore, on the Registrar side (Stateless "Join" port for receiving 
> JPY protocol messages)  we can have "brski.rjp" or so (rjp = "Registrar 
> Join Port") or "brski.jpy".
> 
> -> PvdS I am completely lost by the text above. Apologies. My view:
> The Join-Proxy is a standard coap server with the additional service to 
> propagate messages to the Registrar without any connection to a 
> resource.
> The registrar can receive messages from Join-Proxy on its join-proxy 
> port, but these are not coap messages as you have pointed out; 
> Resources come into play after removing the header.
> 
> Many thanks ,
> 
> Peter
> 
> Subject: Re: [Anima] WGLC for 
> draft-ietf-anima-constrained-join-proxy-04, ends October 14th 2021
> 
> Hi,
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Oct 2021 15:32:30 -0400

> True. Maybe we should also ask for an early review by the Security
    > Area? This is a rather specialised topic, and I'm not sure this WG has
    > many people with the skills needed for an independent review.

SecArea review without being informed of IoT issues won't be that useful in
my opinion.  

I'd like to get a review from for instance:
    Dave Thaler,
    Hannes Tschofenig,
    Malisa Vučinić,
    Henk Birkholz

Maybe the IOT-Directorate can help us here.

-- 
]               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: Peter van der Stok <[email-masked]>
Date: Thu, 14 Oct 2021 10:04:38 +0200

why not ask a security review from iot directorate directly by anima WG?

Peter