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 protected]<mailto:[email protected]>> a écrit : Michael Richardson <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>>, Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ 6tisch mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
