Re: [Last-Call] [Anima] Opsdir last call review of draft-ietf-anima-constrained-join-proxy-09

[Peter van der Stok <[e-mail]>]

  Hi Jurgen,

- Concerning the discussion on one or two options:
I just want to add that there are manufacturerer organizations l(e.g. 
OCF and Thread) that specify which parts of IETF RFCs need to be present 
in the devices deployed in an installation. Manufacturers respond to 
these specs by implementing all those specs which are relevant to their 
market.

Unless there are other arguments against one of the two options I like 
to keep them both in the draft.

- Concerning a better understanding of the mesh network:
A reference to RFC 4944 will be added to  explain the term mesh network

- Concerning a better understanding of the operational conditions: I 
liked the explanation provided by Brian. The following text is proposed 
at the end of section 4.

NEW
When a mesh network is set up, it consists of a Registrar and a set of 
connected pledges. No constrained Join Proxies are present. The wanted 
end-state is a network with a Registrar and a set of enrolled devices. 
Some of these enrolled devices can act as constrained Join Proxies. 
Pledges can only employ link-local communication untill they are 
enrolled. A pledge will regularly try to discover a constrained Join 
Proxy or a Registrar with link-local discovery requests. The pledges 
which are neigbors of the Registrar will discover the Registrar and be 
enrolled following the BRSKI protocol. An enrolled device can act as 
constrained Join Proxy. The pledges which are not a neighbor of the 
Registrar will eventually discover a constrained Join Proxy and follow 
the BRSKI protocol to be enrolled. While this goes on, more and more 
constrained Join Proxies with a larger hop distance to the Registrar 
will emerge. The network should be configured such that at the end of 
the enrollment process, all pledges have discovered a neigboring 
constrained Join Proxy or the Registrar, and all "legal" pledges are 
enrolled.

- Concerning the security apsects:
Do you want the explanation by Michael inserted in the security section?

Greetings,

Peter

Jürgen Schönwälder schreef op 2022-04-05 10:36:

> Reactions inline...
> 
> On Tue, Apr 05, 2022 at 10:05:16AM +0200, Peter van der Stok wrote:
> 
>> Hi Jurgen,
>> 
>> Thanks for the review. I sympathize with your confusion issues. Many 
>> times I
>> shared the same confusion on other IETF documents that I thought 
>> relevant
>> for my work. IETF documents are not encouraged to rephrase parts of 
>> other
>> RFCs or provide large operational HOWTO considerations. Actually, in 
>> other
>> documents that I co-authored people were not happy about the large 
>> number of
>> examples we provided. In my view the document should state the problem 
>> that
>> is being solved, and the standard that proposes to remove the problem. 
>> I
>> tried to do that in this document.
>> 
>> See below for my comments,
>> 
>> much useful text is added in response.
>> 
>> Greetings,
>> 
>> Peter
>> 
>> _____________________________________________________________________
>> 
>> 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.
>> 
>> Pvds ==>
>> 
>> We could add normative language for one option only. We prefer that 
>> based on
>> use cases, an installation engineer could choose one option over the 
>> other.
>> The simplest option is stateful which is common in today's translation
>> devices, but again other use cases may not want to implement that and 
>> just
>> do stateless. I think it is hard for us to choose between these two 
>> options.
> 
> Not sure what an installation engineer does but if you have 5
> different IoT devices that all implement different incompatible
> feature sets and all of them claim compliance to RFC XXXX, then
> clearly there is a problem. Well, the IoT space may be used to this
> and perhaps this is why there are 'installation engineers'. ;-)
> 
>> * 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.
>> 
>> Pvds==>
>> 
>> Now I am confused. I expected you to require more text here.
>> 
>> Something seems to be missing in the description of the base line 
>> scenario,
>> and I need more info to understand what the missing pieces are.
> 
> I think it is rather obvious for people familiar with IPv6 that (i) if
> you don't have the Registrar's address you can't talk to it and (ii)
> if the Registrar is multiple hops away, you can't talk to it. Things
> that are less obvious are the assumptions made about how devices are
> connected. Apparently (if I understand your response) we are not
> talking about devices joining a regular wireless LAN, i.e., a shared
> link. This is where I got lost, i.e., in which scenario such a Join
> Proxy is applicable. It is not about more or less text, but text that
> helps me to figure out whether this is applicable to my networks or
> not.
> 
>> ==>
>> 
>> 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?
>> 
>> Pvds==>
>> 
>> Yes, figure 5 states the discoverable port in the Registrar
> 
> So are both modes required (mandatory) to implement?
> 
>> ==>
>> 
>> 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.
>> 
>> Pvds==>
>> 
>> Only DTLS connections are allowed on the BRSKI mesh network. 
>> Certificates
>> which are signed by the Registrar are used to set up the DTLS 
>> connections.
>> Non protected messages may be routed but will never be accepted by the
>> recipient.
> 
> I am still confused how this is enforced, special link-layer
> properties, configuration of something, ...? Which kind of mesh
> network is required for this to be applicable? I think this is the bit
> of information I am missing, to which deployments this is applicable.
> 
>> ==>
>> 
>> 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.
>> 
>> Pvds==>
>> 
>> No discussion is given, not knowing all operational conditions.
>> 
>> Installation engineers are given the choice.
> 
> Perhaps the goal is job security for installation engineers. ;-)
> 
>> ==>
>> 
>> 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?
>> 
>> Pvds==>
>> 
>> Bob Wilton also commented on this aspect; that has been changed in the
>> latest version
>> 
>> ==>
>> 
>> 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).
>> 
>> Pvds==>
>> 
>> Not sure about "normative for use" or "normative to implement"; Does
>> "normative for use" imply "normative to implement"?
> 
> Normative to use? I though the installation engineer is the one to
> decide. In general, the IETF can be expected to define what is
> normative to implement (a baseline to ensure interoperability). I am
> not sure the IETF can be expected to define what is normative to use.
> Was the intention to say that one option is a normative part of an
> ANIMA compliant solution? Obviously, options that are not implemented
> are difficult to use, hence my question for a normative to implement
> baseline (to make the life of the installation engineer easier).
> 
>> ==>
>> 
>> * 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?
>> 
>> pvds==>
>> 
>> Good Point. In my understanding only DTLS connections are accepted by 
>> the
>> destination. Refusing to route non DTLS traffic may be a bit 
>> prohibitive.
>> The suggestions is to add the following text after the first 
>> paragraph.
>> 
>> NEW
>> 
>> A malicious constrained Join Proxy has a number of routing 
>> possibilities:
>> 
>> * It sends the message on to a malicious Registrar. This is the same 
>> case
>> as the presence of a malicious Registrar discussed in RFC 8995.
>> * It does not send on the request or does not return the response from 
>> the
>> Registrar. This is the case of the not responding or crashing 
>> Registrar
>> discussed in RFC 8995.
>> * It uses the returned response of the Registrar to enroll itself in 
>> the
>> network. With very low probability it can decrypt the response. 
>> Successful
>> enrollment is deemed too unlikely.
>> * It uses the request from the pledge to appropriate the pledge
>> certificate, but then it still needs to acquire the private key of the
>> pledge. Also this is assumed to be highly unlikely.
>> 
>> A malicious node can construct an invalid Join Proxy message. Suppose, 
>> the
>> destination port is the coaps port. In that case, a Join Proxy can 
>> accept
>> the message and add the routing addresses without checking the 
>> payload. The
>> Join Proxy then routes it to the Registrar. In all cases, the 
>> Registrar
>> needs to receive the message at the join-port, checks that the message
>> consists of two parts and uses the DTLS payload to start the BRSKI
>> procedure. It is highly unlikely that this malicious payload will lead 
>> to
>> node acceptance.
>> 
>> A malicious node can sniff the messages routed by the constrained Join
>> Proxy. It is very unlikely that the malicious node can decrypt the 
>> DTLS
>> payload. A malicious node can read the header field of the message 
>> sent by
>> the stateless Join Proxy. This ability does not yield much more 
>> information
>> than the visible addresses transported in the network packets.
>> 
>> ==>
>> 
>> The stateless proxy seems to allow outside attackers to send
>> arbitrary packets to any link-local address inside.
>> 
>> Pvds==>
>> 
>> Like any node that can send link-local broadcast and unicast; I don't 
>> think
>> this is specific to the constrained Join Proxy.
>> 
>> ==>
>> 
>> 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?
>> 
>> Pvds==>
>> 
>> No; only DTLS packets can be sent to Registrars. The latter decides in
>> combination with manufacturer's MASA if a node can be accepted in the
>> network.
> 
> What stops an attacker to send fake messages via the Join Proxy to
> devices on the mesh network? Are you saying that the Join Proxy has to
> verify that the payload is a valid DTLS message and hence the effects
> of this are restricted to unexpected DTLS messages? I am not sure I am
> convinced by that argument, there may also be simple attempts to
> prevent communication or to consume resources. Note, if the Join Proxy
> encrypts the forwarding state, then the format of the forwarding state
> can be entirely implementation specific. From a security and an
> operational perspective, it seems the stateful solution is much easier
> to deal with. Perhaps the security directorate reviewers will chime in
> on the properties of the stateless solution.
> 
> /js