Last Call Review of draft-ietf-anima-constrained-join-proxy-09
review-ietf-anima-constrained-join-proxy-09-opsdir-lc-schoenwaelder-2022-04-01-00

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?