Reviewer: Jürgen Schönwälder
Review result: Serious Issues
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?
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
