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 <ka...@mit.edu> 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.
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
