Hi Rob,
We just had another meeting of the design team and feel it is necessary to do some
move of text about discovery from join-proxy to constrained-voucher (including
change of announcements) to make it more correct. I also have an even larger WG-last
call review i have been working on i need to send out still (sorry, got interrupted).
In general: constrained proxy and constrained voucher are heavily interlinked
and i specifically would like to make sure we do not end up with one of the two
(lets call it A) is going to sit locked down in RFC-editor queue and then we recognize
that to fix a problem in B, we need to also do a fix in B.
Cheers
Toerless
On Thu, Jun 09, 2022 at 04:59:19PM +0200, Peter van der Stok wrote:
> Hi Rob,
>
> We will need more time for the document.
> Toerless may send more info on the subject.
>
> Thanks for your interest,
>
> Greetings,
>
> Peter
> Rob Wilton (rwilton) schreef op 2022-06-07 15:58:
>
> > Thanks Peter. If you can upload before the end of this week, i.e.,
> > before the end of Friday, then that should ensure that all ADs are
> > reviewing the latest version.
> >
> > Alternatively, if you find out, say on Thursday, that you think that you
> > will need more time, then please let me know and I can push it back to
> > the next telechat (probably in 3 weeks time).
> >
> > Thanks,
> >
> > Rob
> >
> > From: Peter van der Stok <stokcons@xxxxxxxxxx>
> > Sent: 07 June 2022 14:43
> > To: Rob Wilton (rwilton) <rwilton@xxxxxxxxx>
> > Cc: last-call@xxxxxxxx; ops-dir@xxxxxxxx;
> > draft-ietf-anima-constrained-join-proxy.all@xxxxxxxx; anima@xxxxxxxx;
> > Jürgen Schönwälder <j.schoenwaelder@xxxxxxxxxxxxxxxxxxxx>
> > Subject: Re: [Anima] Opsdir last call review of
> > draft-ietf-anima-constrained-join-proxy-09
> >
> > HI Rob,
> >
> > thanks for the quest for clarifications.
> > I want to discuss with my co-authors first, before committing to some
> > text.
> > Once the new text is ready, a new version will be uploaded.
> >
> > greetings,
> >
> > Peter
> >
> > Rob Wilton (rwilton) schreef op 2022-06-06 19:13:
> >
> > Hi Peter, authors,
> >
> > Sorry for the delay in this document, but I wanted to check that
> > Juergen's concerns have been addressed, and I'm not sure if I ever saw a
> > final reply from him to confirm, and with that in mind I have lightly
> > rereviewed some of the document based on his comments.
> >
> > My gist from Juergen's comments is that one of his main concerns is that
> > this document seems to present a lot of different choices and doesn't
> > seem to give much guidance about which choices apply meaning that
> > interoperability is reduced if everyone implements different things.
> >
> > Hence, I have some specific recommendations/questions:
> >
> > * It is possible to make one of Stateful or Stateless modes RECOMMENDED?
> > E.g., it seems to me that if the Join Proxy has sufficient memory that
> > the statement mode is superior in that it has no concerns over network
> > MTU/fragmentation and doesn't require the Registrar to understand the
> > new JPY messages. Or, if that is not possible, would it be possible to
> > say that Registrars SHOULD support JPY messages, and perhaps limit the
> > size of pledge messages to avoid potential fragmentation issues at the
> > join proxy?
> >
> > * I agree with Juergen that "This section is normative for uses with an
> > ANIMA ACP" is perhaps not particularly clear. Would it be better to
> > write this as "GRASP based discovery MUST be supported by networks using
> > ANIMA ACP" (if that is what is meant)?
> >
> > * I also think that it would be helpful to recommend one of the
> > discovery mechanisms as SHOULD be implemented by pledges and registrar?
> >
> > If (1) and (3) really don't make sense that perhaps having an
> > applicability paragraph or subsection to the introduction to make it
> > clear that the choice of join-proxy mode and discovery mechanism is
> > entirely deployment dependent and hence the document cannot recommend
> > any particular approach over any other might be helpful to set the
> > context. Although, I still have a concern that you may still get push
> > back from other ADs for a PS level document ... since it still feels
> > like there are 6 possible ways that this can work, pick one and hope
> > that other end and join-proxy have all chosen the same one!
> >
> > A couple of nits:
> >
> > s/mesh newtork/mesh network/
> >
> > s//as Join Proxy/as a Join Proxy/
> >
> > I'll schedule this document for the next telechat in 10 days time, with
> > the assumption that the authors will update it by Friday if you choose
> > to do so.
> >
> > Thanks,
> >
> > Rob
> >
> > From: Peter van der Stok <stokcons@xxxxxxxxxx>
> > Sent: 06 April 2022 08:38
> > To: Peter van der Stok <stokcons@xxxxxxxxxx>
> > Cc: last-call@xxxxxxxx; ops-dir@xxxxxxxx;
> > draft-ietf-anima-constrained-join-proxy.all@xxxxxxxx; anima@xxxxxxxx
> > Subject: Re: [Anima] Opsdir last call review of
> > draft-ietf-anima-constrained-join-proxy-09
> >
> > 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
>
> _______________________________________________
> Anima mailing list
> Anima@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/anima
> _______________________________________________
> Anima mailing list
> Anima@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/anima
--
---
tte@xxxxxxxxx
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
