Hello Pascal, The issue that Ben outlines was solved through two separate mechanisms that are detailed in draft-ietf-6tisch-minimal-security:
1) The traffic that JP redirects into the network on behalf of unauthenticated pledges is tagged using IPv6 DSCP such that it can be distinguished from the legitimate network traffic. This allows e.g. the 6tisch scheduling function to explicitly ignore the unauthenticated traffic when adapting link resources to traffic requirements. This is detailed in Section 6.1 of draft-ietf-6tisch-minimal-security. 2) The use of the CoJP “join_rate” parameter that allows the JRC to set the rate at which each JP in the network forwards the unauthenticated traffic. This mechanism serves as the bandwidth cap for the unauthenticated traffic before it is being forwarded into the network. The details are in Section 8.4.2 of draft-ietf-6tisch-minimal-security, and there is also a paragraph in the Security Considerations detailing the issue. Mališa > On 20 Aug 2019, at 18:20, Pascal Thubert (pthubert) <pthub...@cisco.com> > wrote: > > Dear all: > > I’m looking for a consensus on how to address the following review comment on > the 6TiSCH Architecture by Benjamin: > > > I'd like to see some discussion somewhere that the Join Proxy needs to take > > care > > to not be an open redirector by which an unauthenticated pledge can attack > > arbitrary network elements (whether within the LLN or on the broader > > network), e.g., by performing some validation on the claimed MASA > > identifier. > > Similarly, that the JRC will be exposed to lots of untrusted input and > > needs to be > > implemented in an especially robust manner. > > Then again I’d like to discuss the split of what goes in the architecture and > what goes in Minimal security or elsewhere. > > What do you think? > > Pascal
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
