Subject: [6tisch] tagging join traffic wih DSCP: why inside IP header?

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

Pascal,

During the WG meeting yesterday, we discussed using DSCP bits as a way to
identify join request/reply messages. We talked about mapping, in the
minimal-security spec, the different DSCP values to scheduling behavior.

But you indicated the DSCP bits would be in the inside IPv6 header. That
doesn't make sense to me, can you please provide more info? The outside
IPv6 header looks to me like the right place to put the bits.

Thomas

-- 
_______________________________________

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: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 14 Nov 2017 07:27:46 +0000

Hello Thomas :

I agree it is non-obvious. Here’s why I ended up with that recommendation:

1)      The IP in IP 6LoRH in RFC8138 was designed for the minimal encapsulation as opposed to a generic one, basically a place holder for the outer addresses to be added and removed easily, and meltdown avoidance with a hop limit; everything else is defaulted. This was just an artifact to pass the 6MAN logo. Seems that since then, the law has been bended but that’s another story. Its format is as follows:

     0                   1                   2
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-       ...      -+
    |1|0|1| Length  | 6LoRH Type 6  |  Hop Limit    | Encaps. Address  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-       ...      -+

                       Figure 14: The IP-in-IP-6LoRH

As you see, there is not provision to transport traffic class in that encoding. To transport the TC in outer IP in IP, we’d need to specify a new 6LoRH type for richer IP in IP. Can be done, but quite a bit of hassle. When you asked, I translated “with a minimum changes in mind” and answered accordingly.

2)      In the particular case of the join packet from the join proxy upwards, there is probably no IP in IP, unless an extra encapsulator finds a reason to do so (https://datatracker.ietf.org/doc/html/draft-ietf-roll-useofrplinfo-19#page-17); in the general case of IP in IP, the encapsulator may or may not be the source of the packet; for an encapsulated join, it would not be. So for the generic case of a packet that has to be encapsulated, we’d have to set rules on whether the encapsulator echoes the inned TC in the outer TC. Again, hassle, hassle. Not having an outer TC gives back the control to the source, the JP in our case. At the expense of extra complexity in a node that care whether there is a TC, and which has to dig down to IPHC. Not that hard though.

Makes sense?

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: mardi 14 novembre 2017 14:44
To: [email-masked]
Subject: [6tisch] tagging join traffic wih DSCP: why inside IP header?

Pascal,

During the WG meeting yesterday, we discussed using DSCP bits as a way to identify join request/reply messages. We talked about mapping, in the minimal-security spec, the different DSCP values to scheduling behavior.

But you indicated the DSCP bits would be in the inside IPv6 header. That doesn't make sense to me, can you please provide more info? The outside IPv6 header looks to me like the right place to put the bits.

Thomas

Thomas Watteyne, PhD

www.thomaswatteyne.com<http://www.thomaswatteyne.com>
_______________________________________

---

From: Michael Richardson <[email-masked]>
Date: Tue, 14 Nov 2017 11:48:23 -0500

Thomas Watteyne <[email-masked]> wrote:
    > During the WG meeting yesterday, we discussed using DSCP bits as a way
    > to identify join request/reply messages. We talked about mapping, in
    > the minimal-security spec, the different DSCP values to scheduling
    > behavior.

    > But you indicated the DSCP bits would be in the inside IPv6 header.
    > That doesn't make sense to me, can you please provide more info? The
    > outside IPv6 header looks to me like the right place to put the bits.

I thought it was a typo, and I passed it by.

Why in this non-storing, RPL-aware situation is there even an IPIP outer
header for traffic from the proxy to the DODAG root?

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 14 Nov 2017 14:29:09 -0500

> header for traffic from the proxy to the DODAG root?

Since I re-read Pascal's answer (in the light of my "day"), I now see why it
can not go into to the outer IP header, because we didn't not plan for it.
I thought that in 8138, that if we didn't need an outer IPIP, that we just
used 6loHC (rfc6282... https://tools.ietf.org/html/rfc6282#section-3.2.1)

If we can agree that this is the way, then I think we also need to agree that
certain AFxx would be assigned to available bandwidth, and not cause 6top to
allocate any additional bandwidth.  This does not really fit "AF" Diffserv in
some ways (which in some ways to buffer/delay rather than drop...).

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 15 Nov 2017 01:37:38 +0000

Hello Michael:

> I thought that in 8138, that if we didn't need an outer IPIP, that we just used 6loHC (rfc6282... https://tools.ietf.org/html/rfc6282#section-3.2.1)

This is correct. The RPL artifact for the join request is only the RPI, and the packet (going up) looks as follows in both storing and non-storing, assuming the join is a UDP/CoAP packet.

  The format in Figure 16 is logically equivalent to the uncompressed

   format illustrated in Figure 17:

   +-+-+-+- ... -+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

   |  IPv6 Header  | Hop-by-Hop |  RPI in       |  ICMP message ...

   |  NH = 58      | Header     |  RPL Option   |

   +-+-+-+- ... -+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

               Figure 17: Uncompressed ICMP Packet with RPI

   For a UDP packet, the transport header can be compressed with 6LoWPAN

   HC [RFC6282<https://tools.ietf.org/html/rfc6282>] as illustrated in Figure 18:

   +-+ ... -+-+-...-+-+- ... -+-+-+-+ ... -+-+-+ ... -+-+-+-+-+...

   |11110001| RPI-  | NH=1        |11110CPP| Compressed | UDP

   |Page 1  | 6LoRH | LOWPAN_IPHC | UDP    | UDP header | Payload

   +-+ ... -+-+-...-+-+- ... -+-+-+-+ ... -+-+-+ ... -+-+-+-+-+...

                     <-         RFC 6282<https://tools.ietf.org/html/rfc6282>              ->

                                No RPL artifact

               Figure 18: Uncompressed ICMP Packet with RPI

RFC 8138 places the artifact in front so it is easy to manipulate. After that, you find the IPHC, which encodes the traffic class. Nothing really complex.

A simpler side question is whether the rest of the join flow (response etc...) should trigger allocation of timeslots by the SF or not. If the response only comes for valid requests then I supposed it should.

Take care,

Pascal

-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: mercredi 15 novembre 2017 03:29
To: [email-masked]
Subject: Re: [6tisch] tagging join traffic wih DSCP: why inside IP header?

    > header for traffic from the proxy to the DODAG root?

Since I re-read Pascal's answer (in the light of my "day"), I now see why it can not go into to the outer IP header, because we didn't not plan for it.

I thought that in 8138, that if we didn't need an outer IPIP, that we just used 6loHC (rfc6282... https://tools.ietf.org/html/rfc6282#section-3.2.1)

If we can agree that this is the way, then I think we also need to agree that certain AFxx would be assigned to available bandwidth, and not cause 6top to allocate any additional bandwidth.  This does not really fit "AF" Diffserv in some ways (which in some ways to buffer/delay rather than drop...).

--

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

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 15 Nov 2017 09:55:29 +0100

Pascal, Michael,

If there is no IPIP, then everything is easy. But, AFAICT, we want the JRC
to be able to live on the Internet, i.e. not per se co-located with the
DAGroot. In that case, the Join Request looks like any data packet sent by
the JP to an IPv6 address outside the mesh, which triggers IPIP because the
outer IP header contains the RPI.

So AFAICT, IPIP is needed unless we mandate that JRC and DAGroot are
collocated.

So with IPIP, if we want to play by the rules, forwarding routers (nodes in
the mesh) only look at the outer IP header, and treat the inner IP header
as opaque. So if we use RFC6282 for that header with TF=b10 so ECN+DSCP are
carried inline, it doesn't matter. AFAICT, you recommend to "dig down to
IPHC". Looks more and more like my initial recommendation of using DPI
wasn't that far off :-)

Thomas

On Wed, Nov 15, 2017 at 2:37 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Hello Michael:
>
>
>
> > I thought that in 8138, that if we didn't need an outer IPIP, that we
> just used 6loHC (rfc6282... https://tools.ietf.org/html/
> rfc6282#section-3.2.1)
>
>
>
> This is correct. The RPL artifact for the join request is only the RPI,
> and the packet (going up) looks as follows in both storing and non-storing,
> assuming the join is a UDP/CoAP packet.
>
>
>
>    HC [RFC6282 <https://tools.ietf.org/html/rfc6282>] as illustrated in Figure 18:
>
>
>
>                      <-         RFC 6282 <https://tools.ietf.org/html/rfc6282>              ->
>
>                                 No RPL artifact
>
>
>
> RFC 8138 places the artifact in front so it is easy to manipulate. After
> that, you find the IPHC, which encodes the traffic class. Nothing really
> complex.
>
>
>
> A simpler side question is whether the rest of the join flow (response
> etc…) should trigger allocation of timeslots by the SF or not. If the
> response only comes for valid requests then I supposed it should.
>
>
>
> Take care,
>
>
>
> Pascal
>
>
>
>
>
> Since I re-read Pascal's answer (in the light of my "day"), I now see why
> it can not go into to the outer IP header, because we didn't not plan for
> it.
>
> If we can agree that this is the way, then I think we also need to agree
> that certain AFxx would be assigned to available bandwidth, and not cause
> 6top to allocate any additional bandwidth.  This does not really fit "AF"
> Diffserv in some ways (which in some ways to buffer/delay rather than
> drop...).
>
>
>
> --
>
> Michael Richardson <[email-masked]>, Sandelman Software Works  -=
> IPv6 IoT consulting =-
>
>
>
>
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

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

Hey, not so Thomas.

The 6MAN rules have been bended in more than one way since the times when the IP in IP discussions took place.

1)      RFC8200 allows routers to ignore HbH options so sending the RPI outside the RPL domain is OK. We actually made it ignorable in https://datatracker.ietf.org/doc/html/draft-ietf-roll-useofrplinfo-19#section-3.2

2)      Header insertion is not as Tabu as it was, with segment routing inserting them anyway. So I expect that removing the RPI is OK. Good news, with 6LoRH, it just means ignore the 6LoRH headers, start by decompressing the IPHC and forward just that. It was a design goal for 6LoRH to make the header insertion/deletion, the routing header operations easy to code and debug. The packet starting at the IPHC is exactly what should be decompressed and forwarded, and there is no RPL artifact to it.

DPI means a layer violation. Looking at the IPHC is not. So conceptually, yes that was very far off ☺

Take care,

Pascal

From: Thomas Watteyne [mailto:[email-masked]]
Sent: mercredi 15 novembre 2017 16:55
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: [6tisch] tagging join traffic wih DSCP: why inside IP header?

Pascal, Michael,

If there is no IPIP, then everything is easy. But, AFAICT, we want the JRC to be able to live on the Internet, i.e. not per se co-located with the DAGroot. In that case, the Join Request looks like any data packet sent by the JP to an IPv6 address outside the mesh, which triggers IPIP because the outer IP header contains the RPI.

So AFAICT, IPIP is needed unless we mandate that JRC and DAGroot are collocated.

So with IPIP, if we want to play by the rules, forwarding routers (nodes in the mesh) only look at the outer IP header, and treat the inner IP header as opaque. So if we use RFC6282 for that header with TF=b10 so ECN+DSCP are carried inline, it doesn't matter. AFAICT, you recommend to "dig down to IPHC". Looks more and more like my initial recommendation of using DPI wasn't that far off :-)

Thomas

On Wed, Nov 15, 2017 at 2:37 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

                                No RPL artifact

A simpler side question is whether the rest of the join flow (response etc…) should trigger allocation of timeslots by the SF or not. If the response only comes for valid requests then I supposed it should.

Take care,

Pascal

-----Original Message-----
From: 6tisch [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Michael Richardson
Sent: mercredi 15 novembre 2017 03:29
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] tagging join traffic wih DSCP: why inside IP header?

I thought that in 8138, that if we didn't need an outer IPIP, that we just used 6loHC (rfc6282... <https://tools.ietf.org/html/rfc6282#section-3.2.1>    )

--

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

Thomas Watteyne, PhD

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 15 Nov 2017 11:36:28 +0100

Pascal,

You're saying that I can be exchanging data between motes in the mesh and
hosts on the Internet, while inserting/deleting RPI and RPL routing headers
en-route, i.e. without IPIP?

Thomas

On Wed, Nov 15, 2017 at 10:42 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> 1)      RFC8200 allows routers to ignore HbH options so sending the RPI
> outside the RPL domain is OK. We actually made it ignorable in
> https://datatracker.ietf.org/doc/html/draft-ietf-roll-
> useofrplinfo-19#section-3.2
>
>
>
> 2)      Header insertion is not as Tabu as it was, with segment routing
> inserting them anyway. So I expect that removing the RPI is OK. Good news,
> with 6LoRH, it just means ignore the 6LoRH headers, start by decompressing
> the IPHC and forward just that. It was a design goal for 6LoRH to make the
> header insertion/deletion, the routing header operations easy to code and
> debug. The packet starting at the IPHC is exactly what should be
> decompressed and forwarded, and there is no RPL artifact to it.
>
>
>
> DPI means a layer violation. Looking at the IPHC is not. So conceptually,
> yes that was very far off J
>
>
>
> Take care,
>
>
>
> Pascal
>
>
>
> *From:* Thomas Watteyne [mailto:[email-masked]]
> *Sent:* mercredi 15 novembre 2017 16:55
> *To:* Pascal Thubert (pthubert) <[email-masked]>
> *Cc:* Michael Richardson <[email-masked]>; [email-masked]
>
> *Subject:* Re: [6tisch] tagging join traffic wih DSCP: why inside IP
> header?
>
>
>
> Pascal, Michael,
>
>
>
> So with IPIP, if we want to play by the rules, forwarding routers (nodes
> in the mesh) only look at the outer IP header, and treat the inner IP
> header as opaque. So if we use RFC6282 for that header with TF=b10 so
> ECN+DSCP are carried inline, it doesn't matter. AFAICT, you recommend to
> "dig down to IPHC". Looks more and more like my initial recommendation of
> using DPI wasn't that far off :-)
>
>
>
> Thomas
>
>
>
> used 6loHC (rfc6282... <https://tools.ietf.org/html/rfc6282#section-3.2.1>
> )
>
>
>

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Nov 2017 15:49:59 -0500

Thomas Watteyne <[email-masked]> wrote:
    > You're saying that I can be exchanging data between motes in the mesh
    > and hosts on the Internet, while inserting/deleting RPI and RPL routing
    > headers en-route, i.e. without IPIP?

We did not say that in useofrplinfo!

Pascal is, I think, overstating the compromise/ambiguous text in RFC8200.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 16 Nov 2017 00:04:43 +0000

Hello Michael:

Could we leverage the use of RPL information draft to indicate that the RPL info can be safely removed on RPL packets outgoing the domain ? I think that would pass.

We can also indicate that insertion in allowed on incoming packets and see what pushback we get now.

This would avoid having too many flag days as the rules become more realistic. The times they are a-changing..,

Pascal

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

Thomas Watteyne <[email-masked]<mailto:[email-masked]>> wrote:
You're saying that I can be exchanging data between motes in the mesh
and hosts on the Internet, while inserting/deleting RPI and RPL routing
headers en-route, i.e. without IPIP?

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 16 Nov 2017 13:10:39 -0500

Thomas Watteyne <[email-masked]> wrote:
    > If there is no IPIP, then everything is easy. But, AFAICT, we want the
    > JRC to be able to live on the Internet, i.e. not per se co-located with
    > the DAGroot. In that case, the Join Request looks like any data packet
    > sent by the JP to an IPv6 address outside the mesh, which triggers IPIP
    > because the outer IP header contains the RPI.

    > So AFAICT, IPIP is needed unless we mandate that JRC and DAGroot are

BTW: another alternative is that the DAGroot can actually run a second Join Proxy
pointing at the JRC, or being much more resourceful node, even a stateful proxy.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 16 Nov 2017 15:39:52 -0500

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > Could we leverage the use of RPL information draft to indicate that the
    > RPL info can be safely removed on RPL packets outgoing the domain ?  I
    > think that would pass.

I don't think that would work... but feel free to suggest that during the
WGLC for the document :-)

I suggest that we should get the rules as they are past IESG, and then if we
want to do better that we can do that.

    > This would avoid having too many flag days as the rules become more
    > realistic. The times they are a-changing..,

Aside from 0x63->0x23, there are no other flag days that I forsee.

If one decides to insert/remove headers at the DODAG root, then I think
that this is a unilateral decision.   If one has a network that is intolerant
of the 0x63 RPI option, and updating the LLN is not feasible, then either
fixing that in the DODAG root or removing the header at the DODAG seems like
something a product might just do.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 17 Nov 2017 01:39:50 +0000

Looks like a great idea Michael.

In an ideal world the Root would become a filtering Join Relay (think DHCP relay here).

This way we save complexity (no need for the JR to know who the JRV is), state in the network(no compression context needed), and bytes in the packet if IP in IP is used (with 6LoRH IP in IP the root is implicit, and we may define an implicit context for it in IPHC).

Like in RFC 3048, this also means extra information for the relayed packets, so the JR can point on its local state of the pledge on the way back (if the root is JR it needs the addresses of the JP or a locally significant pointer to it).

Are there security implications that do not foresee, like which of the JP and JR has an SA with the JRC vs end to end protection of the join response?

Pascal

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Nov 2017 09:27:16 -0500

> In an ideal world the Root would become a filtering Join Relay (think

Yes.... although once the traffic has reached the root, the network has
already paid for it, so filtering it is less interesting, I think.

Can 6p allocate bandwidth in the reverse direction? i.e. could the DAGroot,
seeing a lot of legitimate join traffic from some branch allocate more
bandwidth towards itself (the DAGroot)?  I think that this is planned, but
beyond minimal, right?

    > Like in RFC 3048, this also means extra information for the relayed

RFC3048: Reliable Multicast Transport Building Blocks for One-to-Many
         Bulk-Data Transfer

I think this might be a typo, but I tried 3408 and 3084, and neither made
sense either.

    > packets, so the JR can point on its local state of the pledge on the
    > way back (if the root is JR it needs the addresses of the JP or a
    > locally significant pointer to it).

The DAGroot can encapsulate the traffic entirely (VXLAN, GRE, IPsec), or
could terminate the CoAP/UDP traffic into a NAT64 if it wants.  Anything is
possible, but it's all out of scope.
Having said this, I believe that proxies SHOULD support a JRC address which
is not the DAGroot.  In addition to the off-LLN situation, there is also the
case where there are multiple possible DAGroots, but only one of them intends
to be the JRC, yet the other DAGroot is for whatever reason the active one.

    > Are there security implications that do not foresee, like which of the
    > JP and JR has an SA with the JRC vs end to end protection of the join
    > response?

You write "JR" and "JRC" in the same sentence, and I thought above that JR
was just short for JRC.   Whether it's DTLS or OSCORE or ???, the SA is
always between the pledge and the JRC, and the rest are just helpful plumbing.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Nov 2017 09:31:31 -0500

So far nobody has agreed or disagreed with my proposal at:
   https://www.ietf.org/mail-archive/web/6tisch/current/msg05628.html

>   JP should set the DSCP bits in the packet
>   as per rfc2597 section 6, we want AF43 (0b100110).

What, if anything, should the JRC set for the returning traffic?
I'd like to say the same, because I don't think that we should allocate more
bandwidth at the top of the mesh for join traffic going down.   The JRC may
need to pace it's replies so that none get dropped due to congestion.

If the JRC is in the DAGroot, then the most congested link is the one leaving
the DAGroot, and so if the JRC employs even a simple BQL on the outgoing AF43
queue is should work well.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 17 Nov 2017 15:59:18 +0000

That’s RFC 3046 sorry for the typo 😊

Small phone fat fingers...

Pascal

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

Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Looks like a great idea Michael.

In an ideal world the Root would become a filtering Join Relay (think
DHCP relay here).