Jürgen Schönwälder <j.schoenwaelder@xxxxxxxxxxxxxxxxxxxx> wrote:
>> Jürgen Schönwälder via Datatracker wrote:
>> > I am still struggling with the fact that the constrained Join
>> > Proxy does allow attackers to send packets to arbitrary link-local
>> > endpoints. The new security considerations text gives this advice:
>>
>> Yes, attackers who are already inside the network.
>> They can send to arbitrary destinations on the insecure side of the network.
>>
>> This is not a drive-by attack from an outsider, but an attack of an outside
>> by an insider. So there is definitely some kind of exfiltration channel
>> here. But, if it's an LLN network of low-power radios, then any device can
>> also just send unencrypted traffic on arbitrary channels at arbitrary times.
>>
>> Having a different node (the Join Proxy) send the traffic allows for a
>> certain amount of diversion of origin, and perhaps there is a power savings
>> to the malevolent insider.
> My understanding is that a constrained join proxy is needed to
> communication is not directly possible. If so, the join proxy may be
> abused to send traffic to destinations not directly reachable
> otherwise.
The communication that we are trying to support it from the unauthenticated
pledge to the Registrar, and then from the Registrar back to the pledge.
Since the communication is stateless, you have observed that any node on the
network can impersonate the Registrar, send what appears to be reply traffic
towards a join proxy (from the secured/authenticated side of the network),
and the traffic will get sent to the unauthenticated/insecure side of the network.
We are considering changing the JPY encoding to make encrypting/authenticated
the stateless cookie easier. It would work out to be much closer to what is
in https://www.rfc-editor.org/rfc/rfc9031#name-statelessness-of-the-jp I think.
>> If one is running RPL, with RH3 headers, then the attackers can *already*
>> do this kind of thing.
> This sounds a bit like "other protocols have weak security so we do
> not have to do better than that". It could be that my expectations are
> a bit over the top, but that is a decision others have to take. My job
> was to review the document, which I have done.
Thank you!
--
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
