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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 20 Aug 2019 16:20:35 +0000

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 20 Aug 2019 15:58:41 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > I'm looking for a consensus on how to address the following review
    > comment on the 6TiSCH Architecture by Benjamin:

a) I don't think that any details about the Join Proxy belongs in the
   architecture document.
   Any text in the architecture document that says too much should be
   deferring to minimal security.

b) It's not an HTTP PROXY with a CONNECT, and GET HTTP://.. support.
   It's not really an COAP PROXY (RFC7252 section 5.7).
   We describe it in section 4.3.2 as an application layer proxy.
   It can only send traffic to the JRC, and no other place.
   The description of it in section 7 of minimal-security as
   a RFC7252 forward-proxy does imply that it provides any kind
   of HTTP-proxy-like functionality.

    >> implemented in an especially robust manner.

The CoJP has no business looking into any of the packets, and should
not be looking at any MASA entities, because in 6tisch-minimal there is no
MASA.
It forward packets to a single destination at a time, and that's it.

    > 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?

I think that the architecture document is out of control, and I said that in
my review a few months ago :-)

It says way too much, anticipates way too much incomplete work,
and therefore has too many informative references, and thus we get into
the trouble we are here.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Tue, 20 Aug 2019 16:14:24 -0400

The description of it in section 7 of minimal-security as
a RFC7252 forward-proxy does **not** imply that it provides any kind
of HTTP-proxy-like functionality.  Even HTTP forward-proxies are not
proxies that can be abused, they are typically load balancers.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 22 Aug 2019 12:12:11 +0200

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) <[email-masked]> wrote:
> 
> Dear all:
>  
> I’m looking for a consensus on how to address the following review comment on the 6TiSCH Architecture by Benjamin:
>  
> 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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 22 Aug 2019 11:34:28 +0000

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ć <[email-masked]<mailto:[email-masked]>> a écrit :

Hello Pascal,

Mališa

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

Dear all:

What do you think?

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Thu, 22 Aug 2019 17:00:39 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > 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.

No, the pledge intentionally has no way to signal alternate destinations.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 22 Aug 2019 18:49:16 -0500

> No, the pledge intentionally has no way to signal alternate destinations.

Cool; I think I had missed that or confused myself.
Combined with the defenses in minimal-security that Mališa pointed out, it
sounds like we're in pretty good shape.  Now Pascal just has to figure out
how to point to the text in minimal-security without bloating -architecture
too much!

Thanks,

Ben

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 23 Aug 2019 07:39:11 +0000

: )

I used the heavy weaponry in -25;  madi minimal a normative reference and added:

"
6.7.  Deeper Considerations

   The reader is encouraged to review the security section of
   [I-D.ietf-6tisch-minimal-security], which discusses 6TiSCH security
   issues in more details.

"

Works?

Pascal

> -----Original Message-----
> From: Benjamin Kaduk <[email-masked]>
> Sent: vendredi 23 août 2019 01:49
> To: Michael Richardson <[email-masked]>
> Cc: Pascal Thubert (pthubert) <[email-masked]>; =?utf-
> 8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <[email-masked]>; Tero Kivinen
> <[email-masked]>; [email-masked]
> Subject: Re: Intelligent JP / validating the MASA
> 
> sounds like we're in pretty good shape.  Now Pascal just has to figure out how
> to point to the text in minimal-security without bloating -architecture too
> much!
> 
> Thanks,
> 
> Ben