> On 1 Dec 2017, at 16:10, Pascal Thubert (pthubert) <[email protected]> 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 than one join in a
> relatively short period of time. This covers for network startup and limited
> restart after a outage.
Yes, that sounds reasonable.
Mališa
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
