IIUC, you are describing two options: option 1: we don't change the format of the packet, and ask forwarding nodes to (deep) inspect the packets, looking for the CoAP Stateless-Proxy option. option 2: we change the packet format, and introduce semantics in the traffic class bits in the IPv6 header
Correct? can you list pros/cons? On Wed, Nov 8, 2017 at 12:20 PM, Mališa Vučinić <[email protected]> wrote: > 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] > > 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] >> > wrote: >> >>> >>> Mališa Vučinić <[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]>, Sandelman Software Works >>> -= IPv6 IoT consulting =- >>> >>> >>> >>> >>> _______________________________________________ >>> 6tisch mailing list >>> [email protected] >>> 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 >> _______________________________________ >> > > > > -- > _______________________________________ > > 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 > _______________________________________ > > > -- _______________________________________ 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 _______________________________________
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
