Re: [6tisch] Tagging join traffic

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 <mcr+ietf@sandelman.ca<mailto:mcr+ietf@sandelman.ca>> a écrit :

Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr+ietf@sandelman.ca>> 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).

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

--
Michael Richardson <mcr+IETF@sandelman.ca<mailto:mcr+IETF@sandelman.ca>>, Sandelman Software Works
-= IPv6 IoT consulting =-

_______________________________________________
6tisch mailing list
6tisch@ietf.org<mailto:6tisch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tisch