Subject: [6tisch] Tagging join traffic

From: Mališa Vučinić <[email-masked]>
Date: Fri, 3 Nov 2017 16:33:10 +0100

At the interim today, we discussed the need of tagging join traffic at the Join Proxy (JP). The problem is that JP forwards into the network traffic that originates from untrusted pledges, which can cause the exchange of 6P commands at intermediate nodes on the path from JP to 6LBR. 

A malicious pledge is therefore able to affect scheduling of intermediate nodes in the network which could potentially result in resource exhaustion. A bandwidth cap at JP, that is currently recommended in minimal-security draft, limits but doesn’t completely solve the problem. An attacker with access to multiple JPs could inject enough traffic to disturb the network.

Pascal proposed using ToS bits in the IPv6 header to tag join traffic. As part of the JP behavior in minimal-security draft, we would specify that each forwarded packet must be tagged. Then, it would be up to individual SFs to determine what to do with this traffic.

Thoughts?

Mališa

---

From: Michael Richardson <[email-masked]>
Date: Mon, 06 Nov 2017 11:46:37 -0500

Mališa Vučinić <[email-masked]> wrote:
    > At the interim today, we discussed the need of tagging join traffic at
    > the Join Proxy (JP). The problem is that JP forwards into the network
    > traffic that originates from untrusted pledges, which can cause the
    > exchange of 6P commands at intermediate nodes on the path from JP to
    > 6LBR.

    > A malicious pledge is therefore able to affect scheduling of
    > intermediate nodes in the network which could potentially result in
    > resource exhaustion. A bandwidth cap at JP, that is currently
    > recommended in minimal-security draft, limits but doesn’t completely
    > solve the problem. An attacker with access to multiple JPs could inject
    > enough traffic to disturb the network.

    > Pascal proposed using ToS bits in the IPv6 header to tag join
    > traffic. As part of the JP behavior in minimal-security draft, we would
    > specify that each forwarded packet must be tagged. Then, it would be up
    > to individual SFs to determine what to do with this traffic.

To be specific, I think that the JP should set the DSCP bits in the packet
as per rfc2597 section 6, we want AF43 (0b100110).

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

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 8 Nov 2017 11:24:29 +0100

Malisa,
I there no way for a forwarding node to recognize joining traffic from the
6tisch.arpa Uri-Host option? I assume that's encrypted end-to-end?
Trying to see whether there is anything, in the current spec, which allows
a forwarding node to identify join traffic...
Thanks,
Thomas

On Mon, Nov 6, 2017 at 5:46 PM, Michael Richardson <[email-masked]>
wrote:

> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 8 Nov 2017 11:25:01 +0100

PS: I assume we only need to identify traffic going from the pledge to the
JRC, not the join response?

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: Mališa Vučinić <[email-masked]>
Date: Wed, 8 Nov 2017 12:20:54 +0100

Uri-Host with 6tisch.arpa is only present on the first hop, from pledge to the JP. JP removes it when it forwards the join request to the JRC. JP does add a Stateless-Proxy option to the forwarded join request. Identifying join request based on Stateless-Proxy would require CoAP+option parsing as part of SF processing. Doing that is one option while the ToS option requires the modification of existing APIs such that JP’s CoAP component can mark the ToS bits in the IP header. SF would still need to examine those bits for each frame/packet. What do you think?

Error behavior in minimal-security-04 ensures that response is sent only to legitimate pledges i.e. there is no traffic from JRC to pledge if the join request doesn’t pass security processing. Thus, as per minimal-security-04 I don’t think we need to identify join response, although Stateless-Proxy allows us to do so (present also in the response). 

If we further want to support certificate-based enrollment down the road, as part of the zero-touch document, then a key establishment phase will precede join request/join response exchange. Assuming we will reuse the Stateless-Proxy option + CoAP to carry these key establishment packets between the pledge and the JRC, Stateless-Proxy could indeed be used to identify join traffic in both directions.

Mališa

> On 8 Nov 2017, at 11:25, Thomas Watteyne <[email-masked]> wrote:
> 
> PS: I assume we only need to identify traffic going from the pledge to the JRC, not the join response?
> 
> On Wed, Nov 8, 2017 at 11:24 AM, Thomas Watteyne <[email-masked] <mailto:[email-masked]>> wrote:
> Malisa,
> I there no way for a forwarding node to recognize joining traffic from the 6tisch.arpa Uri-Host option? I assume that's encrypted end-to-end?
> Trying to see whether there is anything, in the current spec, which allows a forwarding node to identify join traffic...
> Thanks,
> Thomas
> 
> On Mon, Nov 6, 2017 at 5:46 PM, Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Mališa Vučinić <[email-masked] <mailto:[email-masked]>> wrote:
> Michael Richardson <[email-masked] <mailto:[email-masked]>>, Sandelman Software Works
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>
> 
> 
> 
> 
> -- 
> www.thomaswatteyne.com <http://www.thomaswatteyne.com/>
> www.thomaswatteyne.com <http://www.thomaswatteyne.com/>

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 8 Nov 2017 14:27:50 +0100

IIUC, you are describing two options:

option 1: we don't change the format of the packet, and ask forwarding
nodes to (deep) inspect the packets, looking for the CoAP Stateless-Proxy
option.
option 2: we change the packet format, and introduce semantics in the
traffic class bits in the IPv6 header

Correct? can you list pros/cons?

On Wed, Nov 8, 2017 at 12:20 PM, Mališa Vučinić <[email-masked]>
wrote:

> Uri-Host with 6tisch.arpa is only present on the first hop, from pledge to
> the JP. JP removes it when it forwards the join request to the JRC. JP does
> add a Stateless-Proxy option to the forwarded join request. Identifying
> join request based on Stateless-Proxy would require CoAP+option parsing as
> part of SF processing. Doing that is one option while the ToS option
> requires the modification of existing APIs such that JP’s CoAP component
> can mark the ToS bits in the IP header. SF would still need to examine
> those bits for each frame/packet. What do you think?
>
> Error behavior in minimal-security-04 ensures that response is sent only
> to legitimate pledges i.e. there is no traffic from JRC to pledge if the
> join request doesn’t pass security processing. Thus, as per
> minimal-security-04 I don’t think we need to identify join response,
> although Stateless-Proxy allows us to do so (present also in the response).
>
> If we further want to support certificate-based enrollment down the road,
> as part of the zero-touch document, then a key establishment phase will
> precede join request/join response exchange. Assuming we will reuse the
> Stateless-Proxy option + CoAP to carry these key establishment packets
> between the pledge and the JRC, Stateless-Proxy could indeed be used to
> identify join traffic in both directions.
>
> Mališa
>
> On Wed, Nov 8, 2017 at 11:24 AM, Thomas Watteyne <[email-masked]
> > wrote:
>
>> Malisa,
>> I there no way for a forwarding node to recognize joining traffic from
>> the 6tisch.arpa Uri-Host option? I assume that's encrypted end-to-end?
>> Trying to see whether there is anything, in the current spec, which
>> allows a forwarding node to identify join traffic...
>> Thanks,
>> Thomas
>>
>> On Mon, Nov 6, 2017 at 5:46 PM, Michael Richardson <[email-masked]
>> > wrote:
>>
>>>

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Nov 2017 14:08:41 -0500

Thomas Watteyne <[email-masked]> wrote:
    > Malisa, I there no way for a forwarding node to recognize joining
    > traffic from the 6tisch.arpa Uri-Host option? I assume that's encrypted
    > end-to-end?  Trying to see whether there is anything, in the current
    > spec, which allows a forwarding node to identify join traffic...

Even if it wasn't encrypted end to end (it's not in CoAP+OSCOAP), you don't
really want to be doing deep packet inspection in the middle, and there
is no guarantee that attackers will put that value in for you.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Nov 2017 14:12:28 -0500

Thomas Watteyne <[email-masked]> wrote:
    > nodes to (deep) inspect the packets, looking for the CoAP
    > Stateless-Proxy option.

It's specific to this join process, and is expensive to do.

    > option 2: we change the packet format, and
    > introduce semantics in the traffic class bits in the IPv6 header

It's general to many things.

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 8 Nov 2017 23:41:53 +0100

Thanks Michael.

Does everyone agree with Michael's comments?

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 9 Nov 2017 08:31:49 +0000

I do

Digging in the packet even with nice names like DPI is a layer violation. It breaks the e2e principle so that if we add something to the end points the join message may become unreadable by the dpi. The art of the IETF translates upper layer semantics in lower layer abstraction and in this case we have the TOS bits. RFC 6282 allows to express those in a concise fashion. 6LoRH does not and if IP in IP is used the TOS bits of the inner packet must be used....

Regards,

Pascal

Le 8 nov. 2017 à 23:42, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> a écrit :

Thanks Michael.

On Wed, Nov 8, 2017 at 8:12 PM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

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

Thomas Watteyne, PhD

www.thomaswatteyne.com<http://www.thomaswatteyne.com>
_______________________________________
_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Thomas Watteyne <[email-masked]>
Date: Sun, 12 Nov 2017 08:32:47 +0100

Pascal,

Thanks for the input. Trying to evaluate the overhead of using the traffic
class bits. I assume we want to have one dedicated traffic class for the
join request/reply, which tells nodes NOT to take that traffic into account
for deciding whether to add cells.

- what must be standardized, if anything?
- what would a join request now look like, and what's the hit in terms of
byte count?

Thomas

On Thu, Nov 9, 2017 at 9:31 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> I do
>
> Digging in the packet even with nice names like DPI is a layer violation.
> It breaks the e2e principle so that if we add something to the end points
> the join message may become unreadable by the dpi. The art of the IETF
> translates upper layer semantics in lower layer abstraction and in this
> case we have the TOS bits. RFC 6282 allows to express those in a concise
> fashion. 6LoRH does not and if IP in IP is used the TOS bits of the inner
> packet must be used....
>
>
> Regards,
>
> Pascal
>
> Le 8 nov. 2017 à 23:42, Thomas Watteyne <[email-masked]> a
> écrit :
>
> Thanks Michael.
>

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 12 Nov 2017 07:54:10 +0000

Hello Thomas

For what I see:
We need to specify that with 6LoRH IP in IP, the TOS bits are in the inner (RFC6282) packet.
It will cost one octet in RFC 6282 encoding https://tools.ietf.org/html/rfc6282#section-3.2.1
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |ECN|   DSCP    |
     +-+-+-+-+-+-+-+-+

             Figure 6: TF = 10: Traffic Class carried in-line

We need to specify (ranges of) traffic classes and how they are used by mSF, which are ignored (e.g. CSx in https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml), which are taken seriously or over seriously.
We have to specify which traffic class we use in the join (e.g. CS1), and it must match mSF spec ignored.

Make sense?

Pascal

From: Thomas Watteyne [mailto:[email-masked]]
Sent: dimanche 12 novembre 2017 08:33
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Michael Richardson <[email-masked]>; 6tisch <[email-masked]>; Mališa Vučinić <[email-masked]>
Subject: Re: [6tisch] Tagging join traffic

Pascal,

Thanks for the input. Trying to evaluate the overhead of using the traffic class bits. I assume we want to have one dedicated traffic class for the join request/reply, which tells nodes NOT to take that traffic into account for deciding whether to add cells.

- what must be standardized, if anything?
- what would a join request now look like, and what's the hit in terms of byte count?

Thomas

On Thu, Nov 9, 2017 at 9:31 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
I do

Regards,

Pascal

Thomas Watteyne, PhD

Thomas Watteyne, PhD

---

From: Thomas Watteyne <[email-masked]>
Date: Sun, 12 Nov 2017 09:34:35 +0100

Pascal,

Makes sense.

I'm taking as an example the DAO from 3->2 from
https://tools.ietf.org/html/draft-munoz-6tisch-examples-02#page-15.
The Join Request will have the same header format for IEEE802.15.4 and
6LoWPAN.
Here is a before/after comparison of adding the traffic class bits by hand,
diff in *red*.
Can you confirm that's the right format?

>From https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml, I
get that the 6b DSCP space is mapped to:
- class service (CS) 1-7
- assured forwarding (AF) 11-43
- expedited forwarding (EF)
- VOICE-ADMIT

Our job at 6TiSCH would then to map join request/response traffic to a CS
which we define as "forward, but don't take into account for
adding/deleting cells".
We would also map other traffic to another CS, leaving space for future
extensions (SFs) which would use high CS number to guarantee latencies.

Thoughts welcome,
Thomas

*BEFORE* (no traffic class)

IEEE 802.15.4 Data, Dst: 14:15:92:cc:00:00:00:02,
                     Src: 14:15:92:cc:00:00:00:03
     Frame Control Field: 0xec21, Frame Type: Data
         .... .... .... .001 = Frame Type: Data (0x0001)
         .... .... .... 0... = Security Enabled: False
         .... .... ...0 .... = Frame Pending: False
         .... .... ..1. .... = Acknowledge Request: True
         .... .... .0.. .... = Intra-PAN: False
         .... ...0 .... .... = Sequence Number Suppression: False
         .... ..0. .... .... = Information Elements present: False
         .... 11.. .... .... = Destination Addressing Mode:
                               Long/64-bit (0x0003)
         ..10 .... .... .... = Frame Version: 2
         11.. .... .... .... = Source Addressing Mode:
                               Long/64-bit (0x0003)
     Sequence Number: 5
     Destination PAN: 0xcafe
     Destination: 14:15:92:cc:00:00:00:02 (14:15:92:cc:00:00:00:02)
     Extended Source: 14:15:92:cc:00:00:00:03 (14:15:92:cc:00:00:00:03)
     FCS: 0x1640 (Correct)
 6LoWPAN
     .... 0001 = Page Number: 1
     6LoRH: Routing Protocol Information
         100. .... = Routing Header 6lo: Critical Routing Header (0x04)
         ...0 .... .... .... = Packet direction:
                               UP false, DOWN true: False
         .... 0... .... .... = Error detected: False
         .... .0.. .... .... = No link to destination: False
         .... ..1. .... .... = Context identifier extension: True
         .... ...1 .... .... = Context identifier extension: True
         .... .... 0000 0101 = 6loRH Type: Routing Protocol Information
         RPL Instance: 0x00
         Sender Rank: 0x21
     IPHC Header
         011. .... = Pattern: IP header compression (0x03)
         ...1 1... .... .... = Traffic class and flow label: Version,
                               traffic class, and flow label
                               compressed (0x0003)
         .... .0.. .... .... = Next header: Inline
         .... ..10 .... .... = Hop limit: 64 (0x0002)
         .... .... 0... .... = Context identifier extension: False
         .... .... .0.. .... = Source address compression: Stateless
         .... .... ..01 .... = Source address mode: 64-bits inline(0x01)
         .... .... .... 0... = Multicast address compression: False
         .... .... .... .0.. = Dest address compression: Stateless
         .... .... .... ..01 = Dest address mode: 64-bits inline (0x01)
         [Source context: fe80::]
         [Destination context: fe80::]
     Next header: ICMPv6 (0x3a)
     Source: fe80::1415:92cc:0:3
     Destination: fe80::1415:92cc:0:1
 Internet Protocol Version 6, Src: fe80::1415:92cc:0:3,
                              Dst: fe80::1415:92cc:0:1
     0110 .... = Version: 6
     .... 0000 0000 .... .... .... .... .... = Traffic class:
                                        0x00 (DSCP: CS0, ECN: Not-ECT)
         .... 0000 00.. .... .... .... .... .... = Differentiated
                                        Services Codepoint: Default (0)
         .... .... ..00 .... .... .... .... .... = Explicit Congestion
                            Notification: Not ECN-Capable Transport (0)
     .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
     Payload length: 46
     Next header: ICMPv6 (58)
     Hop limit: 64
     Source: fe80::1415:92cc:0:3
     Destination: fe80::1415:92cc:0:1
 Internet Control Message Protocol v6
     Type: RPL Control (155)
     Code: 2 (Destination Advertisement Object)
     Checksum: 0xd31a [incorrect, should be 0x4d90]
     RPLInstanceID: 0
     Flags: 0x40
         0... .... = DAO-ACK Request (K): False
         .1.. .... = DODAGID Present (D): True
         ..00 0000 = Reserved: 0
     Reserved: 00
     DAO Sequence: 0
     DODAGID: bbbb::1415:92cc:0:1
     ICMPv6 RPL Option (Transit Information bbbb::1415:92cc:0:2)
         Type: Transit Information (6)
         Length: 20
         Flags: 0x00
             0... .... = External: Not set
             .000 0000 = Reserved: 0
         Path Control: 0
         Path Sequence: 0
         Path Lifetime: 170
         Parent Address: bbbb::1415:92cc:0:2

*AFTER* (with traffic class)

IEEE 802.15.4 Data, Dst: 14:15:92:cc:00:00:00:02,
                     Src: 14:15:92:cc:00:00:00:03
     Frame Control Field: 0xec21, Frame Type: Data
         .... .... .... .001 = Frame Type: Data (0x0001)
         .... .... .... 0... = Security Enabled: False
         .... .... ...0 .... = Frame Pending: False
         .... .... ..1. .... = Acknowledge Request: True
         .... .... .0.. .... = Intra-PAN: False
         .... ...0 .... .... = Sequence Number Suppression: False
         .... ..0. .... .... = Information Elements present: False
         .... 11.. .... .... = Destination Addressing Mode:
                               Long/64-bit (0x0003)
         ..10 .... .... .... = Frame Version: 2
         11.. .... .... .... = Source Addressing Mode:
                               Long/64-bit (0x0003)
     Sequence Number: 5
     Destination PAN: 0xcafe
     Destination: 14:15:92:cc:00:00:00:02 (14:15:92:cc:00:00:00:02)
     Extended Source: 14:15:92:cc:00:00:00:03 (14:15:92:cc:00:00:00:03)
     FCS: 0x1640 (Correct)
 6LoWPAN
     .... 0001 = Page Number: 1
     6LoRH: Routing Protocol Information
         100. .... = Routing Header 6lo: Critical Routing Header (0x04)
         ...0 .... .... .... = Packet direction:
                               UP false, DOWN true: False
         .... 0... .... .... = Error detected: False
         .... .0.. .... .... = No link to destination: False
         .... ..1. .... .... = Context identifier extension: True
         .... ...1 .... .... = Context identifier extension: True
         .... .... 0000 0101 = 6loRH Type: Routing Protocol Information
         RPL Instance: 0x00
         Sender Rank: 0x21
     IPHC Header
         011. .... = Pattern: IP header compression (0x03)
*         ...1 0... .... .... = ECN + DSCP (1 byte), Flow Label is elided.*
         .... .0.. .... .... = Next header: Inline
         .... ..10 .... .... = Hop limit: 64 (0x0002)
         .... .... 0... .... = Context identifier extension: False
         .... .... .0.. .... = Source address compression: Stateless
         .... .... ..01 .... = Source address mode: 64-bits inline(0x01)
         .... .... .... 0... = Multicast address compression: False
         .... .... .... .0.. = Dest address compression: Stateless
         .... .... .... ..01 = Dest address mode: 64-bits inline (0x01)
         [Source context: fe80::]
         [Destination context: fe80::]
*     Traffic Class: TBD (0x??) [1 byte]*
     Next header: ICMPv6 (0x3a)
     Source: fe80::1415:92cc:0:3
     Destination: fe80::1415:92cc:0:1
 Internet Protocol Version 6, Src: fe80::1415:92cc:0:3,
                              Dst: fe80::1415:92cc:0:1
     0110 .... = Version: 6
     .... 0000 0000 .... .... .... .... .... = Traffic class:
                                        0x00 (DSCP: CS0, ECN: Not-ECT)
         .... 0000 00.. .... .... .... .... .... = Differentiated
                                        Services Codepoint: Default (0)
         .... .... ..00 .... .... .... .... .... = Explicit Congestion
                            Notification: Not ECN-Capable Transport (0)
     .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
     Payload length: 46
     Next header: ICMPv6 (58)
     Hop limit: 64
     Source: fe80::1415:92cc:0:3
     Destination: fe80::1415:92cc:0:1
 Internet Control Message Protocol v6
     Type: RPL Control (155)
     Code: 2 (Destination Advertisement Object)
     Checksum: 0xd31a [incorrect, should be 0x4d90]
     RPLInstanceID: 0
     Flags: 0x40
         0... .... = DAO-ACK Request (K): False
         .1.. .... = DODAGID Present (D): True
         ..00 0000 = Reserved: 0
     Reserved: 00
     DAO Sequence: 0
     DODAGID: bbbb::1415:92cc:0:1
     ICMPv6 RPL Option (Transit Information bbbb::1415:92cc:0:2)
         Type: Transit Information (6)
         Length: 20
         Flags: 0x00
             0... .... = External: Not set
             .000 0000 = Reserved: 0
         Path Control: 0
         Path Sequence: 0
         Path Lifetime: 170
         Parent Address: bbbb::1415:92cc:0:2

On Sun, Nov 12, 2017 at 8:54 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> We need to specify (ranges of) traffic classes and how they are used by
> mSF, which are ignored (e.g. CSx in https://www.iana.org/
> assignments/dscp-registry/dscp-registry.xhtml), which are taken seriously
> or over seriously.
>
> *From:* Thomas Watteyne [mailto:[email-masked]]
> *Sent:* dimanche 12 novembre 2017 08:33
> *To:* Pascal Thubert (pthubert) <[email-masked]>
> *Cc:* Michael Richardson <[email-masked]>; 6tisch <[email-masked]>;
> Mališa Vučinić <[email-masked]>
> *Subject:* Re: [6tisch] Tagging join traffic
>
>
>
> Pascal,
>
>
>

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Nov 2017 22:28:16 -0500

Thomas Watteyne <[email-masked]> wrote:
    > Thanks for the input. Trying to evaluate the overhead of using the
    > traffic class bits. I assume we want to have one dedicated traffic
    > class for the join request/reply, which tells nodes NOT to take that
    > traffic into account for deciding whether to add cells.

I think that you got it right... we we should have an "available bandwidth
only" class, which is not the same as "best effort".

(We can also use a different instanceID if that reuses code paths better.
 WAY BACK, I suggested this, but it has other issues)

We might also want to define what "best effort" means in a 6tisch network.

    > - what would a join request now look like, and what's the hit in terms

I think it's one byte at the 6lowRH level to send the bits which were
otherwise zero and compressed out.

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 14 Nov 2017 07:40:22 +0100

agreed

On Tue, Nov 14, 2017 at 4:28 AM, Michael Richardson <[email-masked]>
wrote:

>     > - what would a join request now look like, and what's the hit in
> terms
>     > of byte count?
>

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: Michael Richardson <[email-masked]>
Date: Tue, 28 Nov 2017 20:29:10 -0500

> as per rfc2597 section 6, we want AF43 (0b100110).

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/pull-requests/4/join-traffic-marking/diff

The specific text is below.  Maybe it should be 5.2 rather than 5.1.1?

5.1.1.  Identification of Join Request Traffic

   The Join traffic that is proxied by the Join Traffic comes from
   unauthenticated nodes, and there may be an arbitrary amount of it.
   In particular an attacker may send fraudulent traffic in attempt to
   overwhelm the network.

   When operating as part of a [RFC8180] 6tisch minimal network using
   reasonable scheduling algorithms, the join traffic present may cause
   intermediate nodes to request additional bandwidth.  An attacker
   could use this property to cause the network to overcommit bandwidth
   (and energy) to the join process.

   The Join Proxy is aware of what traffic is join traffic as it
   received it on an insecured interface, and so can avoid allocating
   additional bandwidth itself.  Join Proxies SHOULD implement a
   bandwidth cap on join traffic.  This cap will not protect
   intermediate nodes as they can not tell join traffic from regular
   traffic.  Despite the bandwidth cap implemented seperately on each
   Join Proxy, the aggregate join traffic from many Join Proxies may
   cause intermediate nodes to decode to allocate additional cells.  It
   is undesirable to to do in response to the Join Request traffic.  In
   order to permit the intermediate nodes to avoid this the traffic
   needs to be tagged in some way.

   [RFC2597] defines a set of Per-Hop Behaviours that may be encoded
   into the Diffserv Code Points.  The code point AF43 ([RFC2597]
   section 6) of 0b100110 has the right properties.  The Join Proxy
   SHOULD set the DCSP of packets that produces as part of the relay
   process.

   Join Proxy that do not set the DCSP on traffic forwarded should set
   it to zero so that it will be compressed out.

   Intermediate nodes SHOULD NOT allocate additional cells as a result
   of traffic with code point AF43.

5.1.2.  Identification of Join Response Traffic

   Join Response traffic from the JRC to the proxy (and hence to the
   pledge) MAY be marked with a DCSP code AF43.

   When the JRC is not co-located with the DODAG root (6LBR), then the
   code point provides a clear indication to the 6LBR that this is join
   traffic.  There are other mechanisms that the 6LBR could use, in
   particular it could use an ACL to recognize the join traffic.

   Due to the tree structure of the DODAG, the cells immediately below
   the 6LBR are often the most congested, and from that point down there
   is progressively less (or equal) congestion.  If the 6LBR paces
   itself when sending join response traffic then it ought to never
   exceed the bandwidth allocated to the best effort traffic cells.  If
   the 6LBR has the capacity (if it is not constrained) then it should
   therefore provide some buffers in order to satisfy the Assured
   Forwarding behaviour.  Note that too many buffers are considered
   dangerous, see [RFC7567].

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 29 Nov 2017 06:04:23 +0000

Hello Michael :

I’m quite happy with most of your proposal.

Yet not sure the MAY on the return path is a good idea. Either make it a SHOULD or a no no. Otherwise we do not know what to expect in a given network with mixed implementations.

I think that it is actually an important traffic now that security checks were done. More so than some data from a sensor. It is probably still a good idea to tag this packet and the rest of the join but not with AF43. We want to favor it over data else the network will never come up...

Makes sense?

Pascal

Le 29 nov. 2017 à 02:29, Michael Richardson <[email-masked]<mailto:[email-masked]>> a écrit :

Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:
To be specific, I think that the JP should set the DSCP bits in the packet
as per rfc2597 section 6, we want AF43 (0b100110).

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 Nov 2017 10:36:50 -0500

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > Yet not sure the MAY on the return path is a good idea. Either make it
    > a SHOULD or a no no. Otherwise we do not know what to expect in a given
    > network with mixed implementations.

I can live with SHOULD.
SHOULD means that a co-located JRC which has access to the scheduling APIs
can do the right thing and not have to spend a byte on DSCP.
As I say, the 6LBR can also have an ACL to recognize the join responses.

    > I think that it is actually an important traffic now that security
    > checks were done. More so than some data from a sensor. It is probably
    > still a good idea to tag this packet and the rest of the join but not
    > with AF43. We want to favor it over data else the network will never
    > come up...

yes, I agree with the argument, and I was thinking it myself.  S
Should be be AF42 then?  Something higher?
Or do you propose some other treatment?

Please realize that the tagging that we do for 6tisch-minimal-security will
also be identically used for 6tisch-zerotouch-join, and that traffic might be
larger, and it will take some additional round trips before we know that the
node is legitimate.  (many RTTs if we have to use DTLS, two if we can have EDHOC)

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 Nov 2017 13:19:50 -0500

> As I say, the 6LBR can also have an ACL to recognize the join

okay, here is the new version of Join response tagging:

5.3.  Identification of Join Response Traffic

   Join Response traffic from the JRC to the proxy (and hence to the
   pledge) SHOULD be marked with a DCSP code AF42.  AF42 has lower drop
   probability than AF43: if the JRC will respond at all, then dropping
   the response traffic would cause the pledge to have to retransmit,
   using even more bandwidth.

   When the JRC is not co-located with the DODAG root (6LBR), then the
   code point provides a clear indication to the 6LBR that this is join
   response traffic.  (There are other mechanisms that the 6LBR could
   use, in particular it could use an ACL to recognize the join traffic)

   Due to the converging nature of the DODAG, the cells immediately
   below the 6LBR are often the most congested, and from that point down
   there is progressively less (or equal) congestion.  If the 6LBR paces
   itself when sending join response traffic then it ought to never
   exceed the bandwidth allocated to the best effort traffic cells.  If
   the 6LBR has the capacity (if it is not constrained) then it should
   therefore provide some buffers in order to satisfy the Assured
   Forwarding behaviour.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 29 Nov 2017 20:42:09 +0000

Works for me Michael.

Take care,

Pascal

Le 29 nov. 2017 à 19:19, Michael Richardson <[email-masked]<mailto:[email-masked]>> a écrit :

Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Yet not sure the MAY on the return path is a good idea. Either make it
a SHOULD or a no no. Otherwise we do not know what to expect in a given
network with mixed implementations.

I can live with SHOULD.
SHOULD means that a co-located JRC which has access to the scheduling APIs
can do the right thing and not have to spend a byte on DSCP.
As I say, the 6LBR can also have an ACL to recognize the join
responses.

Please realize that the tagging that we do for 6tisch-minimal-security will
also be identically used for 6tisch-zerotouch-join, and that traffic might be
larger, and it will take some additional round trips before we know that the
node is legitimate.  (many RTTs if we have to use DTLS, two if we can
have EDHOC)

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Nov 2017 11:35:48 -0500

> 5.3. Identification of Join Response Traffic

A question on Monday's call was whether setting the DSCP was an easy thing
From a JRC host point of view.
RFC3542  calls what we want "The traffic class"

IPV6_RECVTCLASS lets you get this value.
IPV6_TCLASS lets you set it.

https://tools.ietf.org/html/rfc3542#section-6.5