Let me start with a disclaimer: I am not familiar with BRSKI and ANIMA and hence I have been reading this I-D as a confused outsider and some of my concerns may not be valid or the result of me not understanding the relevant technologies. That said, my conclusion after reading that document is that it is not ready. At a high level, my concerns are: - First, it seems to me that there are many options and there is no clear mandatory to implement baseline. Hence, there I am concerned that this specification will not necessarily lead to interoperable implementations. - Second, it feels like more attention needs to be payed to security concerns. Some of the options may actually be weak from a security point of view and hence narrowing options down may also be desirable to deal with security concerns. I do not think it is sufficient to state that some security issues may be solved by future work. - Third, as an ops-dir reviewer, I am lacking information how this will be operationally deployed, i.e., how a shared link will be properly configured that may have multiple mechanisms to bootstrap routable IP addresses. How do I force pledges to go through this procedure before I hand out or let them discover a routable IP address? I also wonder whether alternatives been considered. Is it really necessary to introduce proxies that rewrite IP addresses? Could it be easier to let Pledges discover special temporary addresses that can be used to reach (without going through a Join Proxy) the Registrar and once a Pledge gets enrolled, it can pick up a more general address? Or is the stateful solution not simply the more robust solution? How many enrollments do we expect a Join Proxy to handle concurrently? What are the bulk enrollment scenarios where a stateless solution would be desirable? I skimmed through draft-richardson-anima-state-for-joinrouter-03, which has more alternatives. While properties of various solutions are discussed, no clear conclusions are drawn. Back to this document, perhaps I am missing also an applicability statement for the Join Proxy solution. * Abstract I find the abstract difficult to understand for people not familiar with the context of this work. You have to read until the 2nd paragraph to get a clue that this has something to do with BRSKI, I think this should be said right away in the first sentence so that people know that what follows is about BRSKI specific concepts. And ideally the abstract would be understandable to people not deeply familiar with BRSKI terminology and concepts. After reading This document extends the work of Bootstrapping Remote Secure Key Infrastructures (BRSKI) by replacing the Circuit-proxy between Pledge and Registrar by a stateless/stateful constrained Join Proxy. It relays join traffic from the Pledge to the Registrar. I had little clue what this document is about. Perhaps explaining things in simpler terms can help, e.g., something like this: This document extends the work of Bootstrapping Remote Secure Key Infrastructures (BRSKI) by specifying how a Join Proxy can relay a DTLS session originating from a Pledge with only link-local addresses to a Registrar not directly reachable on the link to which the Pledge is connected. The title and the abstract both use the term "constrained Join Proxy" but later almost always the term "Join Proxy" is used. So why is it a "constrained Join Proxy" and not just a "Join Proxy", or is there a difference between a "Join Proxy" and a "constrained Join Proxy"? The captions of Fig. 2 and Fig. 3 state that they show a constrained joining message flow. Can there be others or is this technology for some reason only applicable for some sort of constrained devices? * Join Proxy functionality I found the text a bit confusing. It talks about why packets to establish a DTLS connection with a Registrar won't be delivered and then afterwards it says that the Pledge is not even able to discover the IP address of the Registrar. Perhaps this text can be simplified and streamlined. It is rather obvious that if a Pledge has only a link-local address, it won't talk with a Registrar multiple IP hops away. Are both modes required to be implemented? The stateless approach seems to require support by the Registrar while the stateful approach seems to be transparent from the Registrar's perspective. This apparently makes a big difference for the deployment options. To deploy the stateless Join Proxy somewhere in a big network, you need to update the Registrar to support it, right? IP_P:p_P = Link-local IP address and port of the Pledge IP_R:p_Ra = Routable IP address and join-port of Registrar IP_Jl:p_Jl = Link-local IP address and join-port of Join Proxy IP_Jr:p_Jr = Routable IP address and port of Join Proxy I was wondering why this is p_Ra, i.e., what the 'a' stands for. Or why is this not: IP_Pl:p_Pl = Link-local IP address and port of the Pledge IP_Rr:p_Rr = Routable IP address and join-port of Registrar IP_Jl:p_Jl = Link-local IP address and join-port of Join Proxy IP_Jr:p_Jr = Routable IP address and port of Join Proxy Well, how things are labeled may not be really important. I wondered: How does this all interact with SLAC and/or DHCP on a shared link? You seem to assume that SLAC and/or DHCP are disabled as long as a Pledge is not yet enrolled, right? In some networks, you will have also 802.X for enabling layer 2 ports. How do all these things fit operationally together? What are operationally meaningful setups? In a shared network scenario, how do I effectively prevent a Pledge from using router advertisements to generate a routable address? Or is in such a deployment a Join Proxy simply not necessary? Perhaps these questions go beyond this document and they just show my lack of background. Are there any message size issues since the stateless solution encapsulates the DTLS payload in another header? I see that this is mentioned in the table at the end as a property of the stateless mode, there is no discussion of any consequences this may have. There are three different discovery options. Are all three mandatory to implement? Is having many options to start with desirable from an interoperability point of view? I tried to figure out how in 6.1.1 the Registrar is found. I followed several references, discovered several options, ended up in GRASP as one of them. Once I have the registrar's address, I can query the Registrar for more details. Then we have 6.1.2 which details how GRASP can be used directly to provide all relevant information. This section says it is "normative for uses with ANIMA ACP". Not sure what that means, did they authors mean that it is mandatory to implement for ANIMA ACP or that it is mandatory to use for ANIMA ACP? Normative feels like the wrong word, or is the other text not normative or what is conditionally normative in which contexts? As a newcomer, I only found section 6.3.1 reasonably clear (there is a link-local coap multicast, I can see how that works). * Security Considerations There may be more security relevant questions. How robust is this design against attacks? Can this be exploited for attacks? How does a join proxy decide which (DTLs) traffic should be forwarded and which should not be forwarded, or is the idea that any traffic is forwarded? Is the Join Proxy required to verify that the forwarded traffic is actually (valid) DTLS traffic? The stateless proxy seems to allow outside attackers to send arbitrary packets to any link-local address inside. This looks like a new reflection service that must be kept operationally under control, in particular since enrolled Pledges may later act as well as Join Proxies. The security considerations text indicates that future work may address this issue by encrypting the CBOR array. Is this sufficient, do we really want to standardize a new reflection service that we then fix in the future? I am also not sure why level 2 protection (what is 'level 2'? layer 2? link-layer protection?) will actually resolve the problem, once I can route IP packets to a Join Proxy, I can let it forward traffic to arbitrary link-local addresses, no? Is there anything that prevents an attacker from creating a packet with a stack of JPY_messages, effectively source routing messages through a chain of Join Proxies? How will I debug such things if they happen?