Jürgen Schönwälder wrote:
>>
>> 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'. ;-)
Juergen, the different join proxy mechanisms are designed to look identical
to the devices. There is a discovery, then an IPv6-LL communication with a
proxy, and the payloads are transported to the Registrar. The pledge never
(needs to) knows the IP address of the Registrar, only the proxy does.
The nature of the discovery differs a bit based upon radio standards.
For instance, in TSCH networks, we expect the Enhanced Beacon extension in RFC9032.
That's discussed in draft-ietf-anima-constrained-voucher section 10.
I think that the Introduction to draft-ietf-anima-constrained-join-proxy does
a reasonable job of introducing this architecture.
But, since it isn't clear to you, how can we improve the Introduction?
>> 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?
For a Registrar that expects to support both kinds of proxy, yes.
For the pledge, there is no distinction.
For the proxy, it will implement one or the other, or even none if it does
not intend to be a proxy.
>> 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?
It's a forced reverse proxy: all traffic goes to the capable Registrar, so only it
can be attacked.
> 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.
Yes, that's true.
> 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.
The stateful solution is subject to having the attacker consume all available
state memory in the join proxy.
On the other hand, it may protect the mesh from unwanted traffic (and
exhaustion of batteries). Since the pledge sees the same interface
(a UDP port on an IPv6 LL address), either may be switched in/out by the
network operator aka "installation engineer"
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] mcr@xxxxxxxxxxxx http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
Attachment:
signature.asc
Description: PGP signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
