Hi Rob,
I just added the following text
>>NEW
A Join Proxy can operate in two modes:
* Stateful mode
* Stateless mode
A Join Proxy MUST implement both. A Registrar MUST implement the stateful mode and SHOULD implement the Stateless mode.
>>
We hope that solves the interoperability problem.
Nits are removed. thanks.
Concerning the redistribution of text, nothing is known yet.
Greetings,
Peter
Rob Wilton (rwilton) schreef op 2022-06-09 17:48:
Hi Toerless, Peter, Thanks for letting me know. I've pulled the doc off next week's IESG telechat agenda for the moment whilst this issue gets worked out, but from what you have said below it sounds like I may need to give the document back to the WG. Anyway, let me know once you have more certainty on what needs to change. Thanks, Rob
-----Original Message-----
From: Toerless Eckert <tte@xxxxxxxxx>
Sent: 09 June 2022 16:05
To: Peter van der Stok <stokcons@xxxxxxxxxx>
Cc: Rob Wilton (rwilton) <rwilton@xxxxxxxxx>; 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,
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
_______________________________________________ Anima mailing list Anima@xxxxxxxxhttps://www.ietf.org/mailman/listinfo/anima
|
