Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-msf-12: (with DISCUSS and COMMENT)

[Mališa Vučinić <[e-mail]>]

Hi Ben,

There has been an extensive discussion on this issue in the WG. As Tengfei stated, since MSF operates exclusively at L2, reading DSCP values from the IPv6 header would constitute a layer violation. It was decided that MSF would implement the recommendation from draft-ietf-6tisch-minimal-security by recommending the rate limit on DSCP-tagged traffic, at IPv6 layer as outlined in Security Considerations. That said, other scheduling functions that may operate higher up in the stack, e.g. to establish end-to-end tracks between nodes in a mesh, may adhere to this requirement from minimal-security. Therefore, for the sake of future scheduling functions that may get standardized, it was deemed appropriate to leave the recommendation in minimal-security as-is.

Hope that clarifies.

Mališa

> On 24 Mar 2020, at 20:25, Benjamin Kaduk <[e-mail]> wrote:
> 
>>     There seems to be some "passing the buck" going on with respect to
>>     rate-limiting unauthenticated (join) traffic:
>>     draft-ietf-6tisch-minimal-security (Section 6.1.1) says that the SF
>>     "SHOULD NOT allocate additional cells as a result of traffic with code
>>     point AF43"; this document is implementing a SF, and yet we try to avoid
>>     the issue, saying that "[t]he at IPv6 layer SHOULD ensure that this join
>>     traffic is rate-limited before it is passed to 6top sublayer where MSF
>>     can observe it".  I think we need a clear and consistent story about
>>     where this rate-limiting is supposed to happen.
>> 
>>> Thanks for the comments! This has been discussed in some  previous
>>   revision of MSF.
>>> It is not "passing the buck" but a decision based on the scheduling
>>   function and security context.
>>> In the point of avoiding layer violation, the upper layer information
>>   suppose NOT see-able for linker layer where 6P and MSF are.
> 
> If we assume strict layiner so that IP information is not visible to the
> link layer where the scheduling function lives, then isn't that a flaw in
> draft-ietf-6tisch-minimal-security to say that the scheduling function
> should do [something relying on IP-layer information]?
> 
>>> But regarding to security, it seems it is not avoidable.
>>> IMO, the scheduling function is aiming to provide algorithm to
>>   add/remove cell according to traffic.
>>> The traffic could contains unauthenticated  join request from both
>>   normal devices and malicious devices.
>>> The function does NOT have enough information to differentiate them.
>>> We are assuming some other entity out side of MSF needs to resolve this
>>   issue.
> 
> Nonetheless, we're currently not fulfilling a requirement that a SF should
> meet.  If that requirement is unattainable, the requirement should be
> modified or removed; if not, we should attain the requirement.