Subject: Re: [6tisch] Tagging join traffic

From: Mališa Vučinić <[email-masked]>
Date: Fri, 1 Dec 2017 12:12:04 +0100

Pascal, Michael,

Since data traffic in the network is treated as DSCP class 000, i.e. best effort, it will necessarily have lower priority over all other classes, including class 100 that we decided to use for join with specific AF43 and AF42 codepoints. This means that both AF43 (join request) packets and AF42  (join response) packets have precedence over best-effort traffic. We just define the rule that this particular traffic class should not influence SF decisions on cell allocation.

The only benefit of differentiating between join request and join response (using AF43 and AF42) is then in case an intermediate router happens to have both packet types in its buffer, in which case it would more likely drop join request than the join response. I am questioning the need for this given that the 6tisch router is a constrained device and will likely have a common buffer for both best-effort and 100 class, and will therefore first drop best-effort traffic. To me, the advantage of differentiating between join request and join response seems marginal, yet it introduces the code complexity of handling an additional case. Plus, we won't be able to reuse the exact same mechanism for zero-touch, as in that case downstream join traffic is still untrusted.

My proposal would be to use AF42 for both upstream and downstream join traffic.

Mališa

> On 29 Nov 2017, at 19:19, Michael Richardson <[email-masked]> wrote:
> 
> 
> Michael Richardson <[email-masked]> wrote:
> 
>> 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.
> 
> 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.
> 
> 
> 
> 
>> 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)
> 
> 
> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 1 Dec 2017 12:18:43 +0000

Hello Mališa

Note that we are overloading the meaning of a TC by making it a tool for the SF to make cell allocations. If we need the ToS field for real QoS purpose then we can define which classes we use or use new ones.
Tagging the way back may help completing the join in the face of data. Using TC as QoS better than best effort, a router will drop a lesser packet to make room for  the join response, so we have not gone through the hassle of the first half of the join to be destroyed in the way back.

Makes sense?

Pascal
-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Mališa Vucinic
Sent: vendredi 1 décembre 2017 12:12
To: Michael Richardson <[email-masked]>
Cc: 6tisch <[email-masked]>
Subject: Re: [6tisch] Tagging join traffic

Pascal, Michael,

Mališa

>>> 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.
>> 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: Mališa Vučinić <[email-masked]>
Date: Fri, 1 Dec 2017 14:13:17 +0100

Pascal,

Yes, it also makes sense from the point of view of an SF, as join is one-shot traffic and we don’t want to allocate cells in response to that, even though the response in the particular case of minimal-security can be trusted.

I am arguing that for this particular behavior to be achieved, we do not need separate codepoints for upstream and downstream. Do you agree with that?

Mališa

> On 1 Dec 2017, at 13:18, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Mališa
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 1 Dec 2017 13:32:43 +0000

Certainly Mališa. The reason for a different TC is to treat them differently. 
The join response represents an investment of resources in the network and an acceptance by the JRC (so it's not an attack, is it?). 
Seems a good idea to protect it. Do I have that wrong?

Pascal

-----Original Message-----
From: Mališa Vučinić [mailto:[email-masked]] 
Sent: vendredi 1 décembre 2017 14:13
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Michael Richardson <[email-masked]>; 6tisch <[email-masked]>
Subject: Re: [6tisch] Tagging join traffic

Pascal,

Mališa

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

---

From: Mališa Vučinić <[email-masked]>
Date: Fri, 1 Dec 2017 14:58:38 +0100

Pascal,

See inline.

Mališa

> On 1 Dec 2017, at 14:32, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 

You are right, in case of minimal-security, downstream join traffic (i.e. join response) cannot be used as part of an attack. In case of zero-touch, we will have downstream traffic that *could* have been induced by an attack because we will need multiple round trips before the pledge is authenticated and authorized to join by the JRC.

SF is oblivious of whether join traffic is upstream or downstream — it shouldn’t allocate new cells in either case. 

> Seems a good idea to protect it. Do I have that wrong?

By ‘protect it’, do you mean give downstream join traffic higher priority in the buffers over data traffic? If so, that’s already taken care of just by using a non-zero TC. And the same holds for upstream join traffic, since it uses a non-zero TC.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 1 Dec 2017 15:10:47 +0000

[Pascal] >> Seems a good idea to protect it. Do I have that wrong?

> By ‘protect it’, do you mean give downstream join traffic higher priority in the buffers over data traffic? If so, that’s already taken care of just by using a non-zero TC. And the same holds for u…

[Pascal] I'm not sure that the join and the response should have the same precedence. In a forming network there may be a bunch of both and the responses should win in case of a collision in a node's buffer.  Conversely I'm not too sure that the initial join is better than a data packet. It may be a DoS attack. Intuitively I'd say that a join message on the way out of the network is below best effort and that a response back is above best effort.  Do you mind consuming 2 TC values? 

Note that both values could be used for other packets with shared characteristics. Note also that instead of not adding slots, an intelligent SF may allocate some shorter-lived ones if it sees more than one join in a relatively short period of time. This covers for network startup and limited restart after a outage.

Take care,

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Fri, 01 Dec 2017 13:07:49 -0500

Mališa Vučinić <[email-masked]> wrote:
    > Since data traffic in the network is treated as DSCP class 000,
    > i.e. best effort, it will necessarily have lower priority over all
    > other classes, including class 100 that we decided to use for join with
    > specific AF43 and AF42 codepoints. This means that both AF43 (join
    > request) packets and AF42  (join response) packets have precedence over
    > best-effort traffic. We just define the rule that this particular
    > traffic class should not influence SF decisions on cell allocation.

There were many debates in diffserv about trying to define a traffic class
that was lower than best effort.  It was repeatedly pointed out that this was
a contradiction.

In the end what most people really wanted was to map traffic class 000
(untagged) to a level of service which was actually above "best effort".
Any ISP or home user who uses PIE or *FQ*CODEL is in fact doing this
already.

I'm not sure what class 100 is, I'm guessing it might be typo?

    > The only benefit of differentiating between join request and join
    > response (using AF43 and AF42) is then in case an intermediate router
    > happens to have both packet types in its buffer, in which case it would
    > more likely drop join request than the join response.

    > I am questioning
    > the need for this given that the 6tisch router is a constrained device
    > and will likely have a common buffer for both best-effort and 100
    > class, and will therefore first drop best-effort traffic.

I take your point about the buffers.  That could change over time.

The advantage of tagging response traffic with AF42 now is that we might want
to permit join response traffic to allocate cells.

    > To me, the
    > advantage of differentiating between join request and join response
    > seems marginal, yet it introduces the code complexity of handling an
    > additional case. Plus, we won't be able to reuse the exact same
    > mechanism for zero-touch, as in that case downstream join traffic is
    > still untrusted.

It depends on many things.  Perhaps we could mark some of the response
traffic AF43, and then switch to AF42.

    > My proposal would be to use AF42 for both upstream and downstream join traffic.

AF42? or AF43?

---

From: Mališa Vučinić <[email-masked]>
Date: Mon, 4 Dec 2017 14:59:40 +0100

> On 1 Dec 2017, at 16:10, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> [Pascal] I'm not sure that the join and the response should have the same precedence. In a forming network there may be a bunch of both and the responses should win in case of a collision in a node's buffer.  Conversely I'm not too sure that the initial join is better than a data packet. It may be a DoS attack.
> Intuitively I'd say that a join message on the way out of the network is below best effort and that a response back is above best effort.  

I do agree that initial join (join request) should ideally have higher drop precedence over best-effort data packets. To have that standardized and compliant with RFC2597, we would need to tag each *data* packet with its own DSCP value and use higher drop precedence code within the same class for the join request. That would consume 1 byte in every data packet which we don’t want to do IMO.

> Do you mind consuming 2 TC values? 

By using a single code for upstream and downstream, my intent was (1) to provide a generic tagging mechanism that could be re-used by zero-touch and its multi round trip authentication; (2) simplify code.

I don’t think implementing additional codepoint within the same class is particularly complex so I am ok with it. For (1), we can:

Option 1: keep Michael’s PR mandating AF42 for join response as is, and then complement the tagging mechanism as part of zero-touch document.
Option 2: add a ‘hook’ in minimal-security stating that the downward traffic may be either AF43 or AF42, with AF42 being recommended because in the particular case of minimal-security downward traffic cannot be induced by an attacker.

In both cases, some text on this in zero-touch document seems necessary. Thus, I am not sure then if there is added value with Option 2 over Option 1. What do you think?

> Note that both values could be used for other packets with shared characteristics. Note also that instead of not adding slots, an intelligent SF may allocate some shorter-lived ones if it sees more…

Yes, that sounds reasonable.

Mališa

---

From: Mališa Vučinić <[email-masked]>
Date: Mon, 4 Dec 2017 16:00:41 +0100

Michael,

With class 100, I was referring to the (common) 3 most significant bits in AF43, AF42 (and AF41) values.

If I can summarize, by tagging join request with AF43 and join response with AF42, we achieve that:
(1) join requests do not trigger cell allocation
(2) join responses may trigger cell allocation
(3) join responses have priority in nodes’ buffers over join requests

(2) would be achieved by simply not tagging join responses. (3) can only be achieved with join requests and join responses being tagged within the same class, but different codepoints, in order to be compliant with RFC2597.

The advantage of having a separate codepoint for join response is therefore (3). Since the most implementation effort goes to implementing a class, adding a codepoint within shouldn’t be a big deal, so I am ok with it.

A couple of questions:
- Any particular reason why you chose class 100 i.e. (AF43 and AF42) and not any other class from RFC2597?
- What should the zero-touch traffic be tagged with? Zero-touch traffic refers to *all* packets exchanged *before* minimal-security is executed. Having (3) for zero-touch does not seem to make much sense since both upwards and downwards packets could be induced by an attack. With that, I don’t see the need of differentiating between upward and downward. Should it all be tagged with AF43?

Mališa

> On 1 Dec 2017, at 19:07, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Dec 2017 20:05:17 -0500

> in AF43, AF42 (and AF41) values.

Ah, okay. Got it.
I think you studied RFC2597 harder than I did :-)

    > (3) join responses have priority in nodes’ buffers over join requests

I agree with your summary.

    > and not any other class from RFC2597?

I believed at the time that AF1x would have priority over AF2x, etc.
but that's not the correct.

    > - What should the zero-touch traffic be tagged with? Zero-touch traffic
    > refers to *all* packets exchanged *before* minimal-security is
    > executed. Having (3) for zero-touch does not seem to make much sense
    > since both upwards and downwards packets could be induced by an
    > attack. With that, I don’t see the need of differentiating between
    > upward and downward. Should it all be tagged with AF43?

So, some of the zero-touch response traffic can be induced by an attacker,
but there is a point where the JRC knows that the node is legitimate, and it
can switch from AF43 to AF42.  That point is just prior to the transfer of
the voucher, which is a ~100 byte object from JRC to pledge.

---

From: Mališa Vučinić <[email-masked]>
Date: Mon, 11 Dec 2017 10:40:39 +0100

So should we stick to AF4x or switch to a lower value?

Mališa

> On 5 Dec 2017, at 02:05, Michael Richardson <[email-masked]> wrote:
> 
>>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 11 Dec 2017 08:11:25 -0500

> So should we stick to AF4x or switch to a lower value?

I think that it's arbitrary.

    > - Any particular reason why you chose class 100 i.e. (AF43 and
    > AF42)
    > and not any other class from RFC2597?