Re: [6tisch] Intelligent JP / validating the MASA

["Pascal Thubert (pthubert)" <[e-mail]>]

Many thanks Malisa

I agree but I’m not sure it’s just that.

I’m reading a question of possibility multiple JRC whereby the pledge would indicate which JRC to use and possibly leverage that for an attack on anyone outside.

For all I know the knowledge of the JRC is in the root, and it’s not provided by the pledge. So that problem does not exist.

The network is so slow that it can hardly be used to DoS the outside. The mechanism you describe is mostly there to protect the network itself starting with the JP.

I tend to agree with Michael that we have enough text in the Architecture and that a normative Reference to minimal security and a pointer to its security section have us covered.

Regards,

Pascal

Le 22 août 2019 à 12:12, Mališa Vučinić <[e-mail]<mailto:[e-mail]>> a écrit :

Hello Pascal,

The issue that Ben outlines was solved through two separate mechanisms that are detailed in draft-ietf-6tisch-minimal-security:

1) The traffic that JP redirects into the network on behalf of unauthenticated pledges is tagged using IPv6 DSCP such that it can be distinguished from the legitimate network traffic. This allows e.g. the 6tisch scheduling function to explicitly ignore the unauthenticated traffic when adapting link resources to traffic requirements. This is detailed in Section 6.1 of draft-ietf-6tisch-minimal-security.

2) The use of the CoJP “join_rate” parameter that allows the JRC to set the rate at which each JP in the network forwards the unauthenticated traffic. This mechanism serves as the bandwidth cap for the unauthenticated traffic before it is being forwarded into the network. The details are in Section 8.4.2 of draft-ietf-6tisch-minimal-security, and there is also a paragraph in the Security Considerations detailing the issue.

Mališa

On 20 Aug 2019, at 18:20, Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>> wrote:

Dear all:

I’m looking for a consensus on how to address the following review comment on the 6TiSCH Architecture by Benjamin:

> I'd like to see some discussion somewhere that the Join Proxy needs to take care
> to not be an open redirector by which an unauthenticated pledge can attack
> arbitrary network elements (whether within the LLN or on the broader
> network), e.g., by performing some validation on the claimed MASA identifier.
> Similarly, that the JRC will be exposed to lots of untrusted input and needs to be
> implemented in an especially robust manner.

Then again I’d like to discuss the split of what goes in the architecture and what goes in Minimal security or elsewhere.

What do you think?

Pascal