Uri-Host with 6tisch.arpa is only present on the first hop, from pledge to the JP. JP removes it when it forwards the join request to the JRC. JP does add a Stateless-Proxy option to the forwarded join request. Identifying join request based on Stateless-Proxy would require CoAP+option parsing as part of SF processing. Doing that is one option while the ToS option requires the modification of existing APIs such that JP’s CoAP component can mark the ToS bits in the IP header. SF would still need to examine those bits for each frame/packet. What do you think?
Error behavior in minimal-security-04 ensures that response is sent only to legitimate pledges i.e. there is no traffic from JRC to pledge if the join request doesn’t pass security processing. Thus, as per minimal-security-04 I don’t think we need to identify join response, although Stateless-Proxy allows us to do so (present also in the response). If we further want to support certificate-based enrollment down the road, as part of the zero-touch document, then a key establishment phase will precede join request/join response exchange. Assuming we will reuse the Stateless-Proxy option + CoAP to carry these key establishment packets between the pledge and the JRC, Stateless-Proxy could indeed be used to identify join traffic in both directions. Mališa > On 8 Nov 2017, at 11:25, Thomas Watteyne <[email protected]> wrote: > > PS: I assume we only need to identify traffic going from the pledge to the > JRC, not the join response? > > On Wed, Nov 8, 2017 at 11:24 AM, Thomas Watteyne <[email protected] > <mailto:[email protected]>> wrote: > Malisa, > I there no way for a forwarding node to recognize joining traffic from the > 6tisch.arpa Uri-Host option? I assume that's encrypted end-to-end? > Trying to see whether there is anything, in the current spec, which allows a > forwarding node to identify join traffic... > Thanks, > Thomas > > On Mon, Nov 6, 2017 at 5:46 PM, Michael Richardson <[email protected] > <mailto:[email protected]>> wrote: > > Mališa Vučinić <[email protected] <mailto:[email protected]>> > wrote: > > At the interim today, we discussed the need of tagging join traffic at > > the Join Proxy (JP). The problem is that JP forwards into the network > > traffic that originates from untrusted pledges, which can cause the > > exchange of 6P commands at intermediate nodes on the path from JP to > > 6LBR. > > > A malicious pledge is therefore able to affect scheduling of > > intermediate nodes in the network which could potentially result in > > resource exhaustion. A bandwidth cap at JP, that is currently > > recommended in minimal-security draft, limits but doesn’t completely > > solve the problem. An attacker with access to multiple JPs could inject > > enough traffic to disturb the network. > > > Pascal proposed using ToS bits in the IPv6 header to tag join > > traffic. As part of the JP behavior in minimal-security draft, we would > > specify that each forwarded packet must be tagged. Then, it would be up > > to individual SFs to determine what to do with this traffic. > > 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). > > > -- > Michael Richardson <[email protected] <mailto:mcr%[email protected]>>, > Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > 6tisch mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/6tisch > <https://www.ietf.org/mailman/listinfo/6tisch> > > > > > -- > _______________________________________ > > Thomas Watteyne, PhD > Research Scientist & Innovator, Inria > Sr Networking Design Eng, Linear Tech > Founder & co-lead, UC Berkeley OpenWSN > Co-chair, IETF 6TiSCH > > www.thomaswatteyne.com <http://www.thomaswatteyne.com/> > _______________________________________ > > > > -- > _______________________________________ > > Thomas Watteyne, PhD > Research Scientist & Innovator, Inria > Sr Networking Design Eng, Linear Tech > Founder & co-lead, UC Berkeley OpenWSN > Co-chair, IETF 6TiSCH > > www.thomaswatteyne.com <http://www.thomaswatteyne.com/> > _______________________________________
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
