Hi Robert, If we view the unprotected and protected paths as logically separate stacks, then I don't think the concept of "layer violation" even applies. The two stacks just happen to share a lot of the concepts and encodings. I agree that using UDP/IPv6 makes it possible to share code, but it's important to ensure that implementations enforce the proper isolation. My only worry would be that it encourages poor implementation choices, such as using a single UDP/IPv6/6LoWPAN stack without proper isolation between the protected and unprotected channels at every layer.
Again, I think it can be made to work technically, we just have to make it obvious that it requires more than just passing a secured/unsecured option between the application and link layers - the transport, network, and adaptation layers needs to have appropriate isolation as well. Large scale deployment will only help identify any pitfalls in both specification and implementation that exist. It's good that we will soon be able to accumulate soak time on real-word deployments that are beyond pilot stage. -- Jonathan Hui On Wed, Nov 11, 2015 at 9:21 AM, Robert Cragie <[email protected]> wrote: > Hi Jonathan, > > The side stack concept also applies to MLE as well as PANA, in > implementations which use it and I agree the general isolation between the > side stack used for control plane traffic and data plane traffic is > important. However, the sharing of components is indeed an important > feature. Using UDP over 6LoWPAN over 802.15.4 over one hop for e.g. PANA is > really quite efficient and the libraries used in the data plane can also be > used in the control plane. As mentioned before this is control plane, so > with regard to "layer violation", I would say "get over it" - cross layer > interaction happens all the time in the control plane. > > With regard to your second point on robust solutions: There is a > difference between a specified solution and a subsequent implementation of > that solution. An implementation may be weak but that does not imply the > solution it is implementing is weak. Of course large scale deployment can > build confidence but it can also build lack of confidence if a large number > of those deployments are based on weak implementations. One key requirement > for ZigBee IP was to use existing solutions as much as possible, hence EAP > and EAP-TLS as a starting point (already tried and tested). Whilst PANA was > acknowledged to be not as tried and tested as EAP and EAP-TLS, it was > chosed for the reason in the paragraph above and the relay and encryption > additions were specified for mesh networks. Even then, as the EAP > transport, PANA is a relatively small (but important) part of the network > access solution. > > Robert > > On 10 November 2015 at 17:24, Jonathan Hui <[email protected]> wrote: > >> I agree with Robert that PANA needs to be viewed as a side stack. It >> involves more than just restricted forwarding rules and hooks for the upper >> layers. It also involves resource isolation at the lower layers to help >> ensure that unauthorized traffic cannot interfere with authorized traffic. >> Logically they need to be separate, isolated stacks. Although, an >> implementation may choose to share a bunch of components. >> >> Also, I'd caution that specification and basic functional testing alone >> does not prove a robust solution. How much security or penetration testing >> has been done on existing implementations? I would argue large-scale >> deployment certainly helps build confidence beyond what specification and >> basic functional testing can do. >> >> -- >> Jonathan Hui >> >> >> On Tue, Nov 10, 2015 at 3:00 AM, Robert Cragie < >> [email protected]> wrote: >> >>> Alper - I completely agree with what you say and did note earlier that, >>> given the 7 independent implementations for ZigBee IP, it clearly isn't a >>> serious obstacle. However, it is useful to understand potential issues with >>> any given solution; any solution will have certain issues which have to be >>> addresses. >>> >>> Robert >>> >>> On 8 November 2015 at 23:28, Alper Yegin <[email protected]> wrote: >>> >>>> Robert, >>>> >>>> Right. Even though PANA is a UDP-based protocol, one cannot assume it >>>> shall be implementable just like any "UDP-based user-land application". >>>> Like you said it's a control plane traffic/application, and it needs some >>>> hooks from the stack. This is very much similar to other UDP-based >>>> protocols like Mobile IPv4 and DHCP. They also need hooks with lower >>>> layers. >>>> >>>> Alper >>>> >>>> >>>> >>>> On Nov 9, 2015, at 1:01 AM, Robert Cragie wrote: >>>> >>>> Hi Alper, >>>> >>>> PANA is UDP traffic, which is typically sent using sockets. There is no >>>> defined socket option (in e.g Linux socket API) to specify options for >>>> sending the packet when it is processed 2 layers down at the MAC layer. So >>>> some might say that specifying a layer 2 concept at layer 4 is layer >>>> violation. Also, the unprotected PANA only goes one hop and should not be >>>> routed, therefore it is treated differently from other IP packets. This is >>>> in addition to the enforcement point policing for unprotected MAC traffic. >>>> Hence thinking about it like a "side stack". >>>> >>>> Other comments inline. >>>> >>>> Robert >>>> >>>> >>>> On 7 November 2015 at 21:26, Alper Yegin <[email protected]> wrote: >>>> >>>>> Hi Robert, >>>>> >>>>> The MAC has the ability to carry both encrypted traffic and also >>>>> unencrypted traffic, right? >>>>> If so, it's just about telling the MAC which traffic uses encrypted >>>>> path and which does not. >>>>> I don't see anything to do with layer violation here. >>>>> >>>>> I'd not call it a "side stack" either. It's just demultiplexing. Same >>>>> stack, different code path executed depending on the characteristic of the >>>>> traffic, which is explicitly conveyed by the upper layer to the lower >>>>> layer. >>>>> >>>> >>>> <RCC>Some stacks don't work like that though. Sure, if you have control >>>> over the stack, it is easy enough to implement and as you say, it is simply >>>> demultiplexing and conceptually quite easy to understand but there are >>>> certain points in the layer traversal that do have to be treated >>>> differently</RCC> >>>> >>>> >>>>> Btw, this has to be done for any above-MAC solution. >>>>> >>>>> Alper >>>>> >>>>> >>>>> >>>>> Given that the MAC can support transporting IP (with whatever payload >>>>> it carries, be it PANA/UDP, or anything else), it should be able to carry >>>>> both encrypted traffic and unencrypted traffic. >>>>> >>>>> On Nov 7, 2015, at 7:42 PM, Robert Cragie wrote: >>>>> >>>>> Hi Alper, >>>>> >>>>> The perceived issue is that, in ZigBee IP, the authentication traffic >>>>> over PANA on the single hop between the unauthenticated joiner and the >>>>> relay (or authenticator) has to be sent at the MAC layer without any >>>>> protection. This is because MAC layer protection is used for all >>>>> authenticated nodes sending and receiving traffic in the mesh and the key >>>>> used is delivered at the end of the authentication process over the >>>>> established secure session. Note there is no particular issue with having >>>>> no MAC layer protection as the only traffic carried is for authentication >>>>> purposes and thus does not carry any confidential information and is >>>>> checked using verify exchanges at the end. >>>>> >>>>> This means there is effectively a "side stack" alongside the normal >>>>> stack, which is used to handle the PANA traffic on an enforcement point. >>>>> On >>>>> one hand, some perceive the necessity for this side stack as layer >>>>> violation, although I view this more as control plane traffic, where >>>>> cross-layer interactions are not uncommon (look at what they are doing in >>>>> anima with the ASAs, for example). It is also perceived as complicating >>>>> the >>>>> use of a typical IP stack, which is normally used for data plane traffic. >>>>> Specifically, having to provide an extra parameter at the socket layer to >>>>> indicate whether it should be transmitted unprotected or protected (and >>>>> similar for receive) is viewed as problematic. >>>>> >>>>> In practice, given the fact that the 7 platform implementers managed >>>>> to successfully implement PANA-based authentication, I am not sure >>>>> actually >>>>> how much of an issue it really is. >>>>> >>>>> Robert >>>>> >>>>> >>>>> >>>>> On 7 November 2015 at 11:00, Alper Yegin <[email protected]> >>>>> wrote: >>>>> >>>>>> Hello Robert, >>>>>> >>>>>> Thanks for this detailed insight. >>>>>> One question below: >>>>>> >>>>>> On Nov 6, 2015, at 5:43 PM, Robert Cragie wrote: >>>>>> >>>>>> Some comments on some of the items raised in the thread so far: >>>>>> >>>>>> * It is not about messages, it is more about how many flights occur >>>>>> between initiator and responder. For example, with (D)TLS, it is normal >>>>>> to >>>>>> incorporate a number of records in a single flight. >>>>>> >>>>>> * The concept of an initial phase of PANA (PCI, PAR) is often needed >>>>>> for DoS and rate-limiting purposes. If DTLS were used, you would still >>>>>> want >>>>>> to use HelloVerifyRequest for the reasons it was developed for DTLS, >>>>>> there >>>>>> is no overhead using PANA in this case. >>>>>> >>>>>> * Whilst it seems straightforward to use DTLS, it may not be the case >>>>>> where a JA is involved and it is likely that the DTLS records will need >>>>>> to >>>>>> be relayed via the JA. The only IP address which can be effectively >>>>>> autoconfigured at this stage is a link local address and therefore it can >>>>>> only go one hop to the JA (or possibly JCE direct). >>>>>> >>>>>> * Note that autoconfiguration of a link local address is pretty much >>>>>> zero cost as it is simply forming an IID from the L2 address and >>>>>> prepending >>>>>> fe80::/64. There may be some concerns about the privacy aspects but I >>>>>> think >>>>>> privacy concerns are much more significant for global addresses and if L2 >>>>>> addresses have some sort of treatment for privacy, that it probably >>>>>> adequate for link local addresses. >>>>>> >>>>>> * Conceptually, all these mechanisms are fundamentally the same and >>>>>> when it comes down to it, there is often little to choose between them. >>>>>> The >>>>>> weight of the exchanges is based on the credentials and underlying crypto >>>>>> used for authentication. >>>>>> >>>>>> * Agree with the comment re. 1.C and 1.D - it is not just EAP-PSK. >>>>>> EAP by definition requires and EAP transport and an EAP method. An EAP >>>>>> transport can be PANA, 802.15.9 (i.e. IEs). EAPOL, RADIUS etc. and there >>>>>> are numerous EAP methods (EAP-TLS, EAP-PSK, EAP-AKA, EAP-IKEV2). >>>>>> Therefore, >>>>>> I would focus on those three layers as that is fundamentally what it >>>>>> comes >>>>>> down to: >>>>>> >>>>>> 1. Transport >>>>>> 2. Protocol >>>>>> 3. Crypto >>>>>> >>>>>> To summarise the two authentication schemes I am familiar with: >>>>>> >>>>>> ZigBee IP: >>>>>> Transport: PANA/PANA relay >>>>>> Protocol: EAP/EAP-TLS >>>>>> Crypto: ECDHE-ECDSA, PSK >>>>>> >>>>>> Thread: >>>>>> Transport: Direct/CoAP relay >>>>>> Protocol: DTLS >>>>>> Crypto: ECJPAKE >>>>>> >>>>>> One might ask why a different approach was taken for Thread. The main >>>>>> reasons are that DTLS is considered a key protocol for Thread >>>>>> applications >>>>>> (which will likely use CoAP) and thus reuse of DTLS was considered >>>>>> paramount. Also, the Commissioner model is substantially different to the >>>>>> Authenticator model for ZigBee IP and it was considered more appropriate >>>>>> to >>>>>> use protocols a phone/tablet app. would be more familiar with, i.e. CoAP >>>>>> and DTLS as opposed to PANA/EAP/EAP-TLS. I would imagine the 6tisch >>>>>> architecture is closer to ZigBee IP than Thread. >>>>>> >>>>>> * The simplicity of PSK is offset by the need to manage confidential >>>>>> information across the devices. It is always IMHO worth including PSK as >>>>>> a >>>>>> minimal level, as it is very useful for testing purposes if nothing else >>>>>> >>>>>> * In my experience, using EAP-TLS as an EAP method in conjunction >>>>>> with PANA and EAP (i.e. ZigBee IP approach) allows for reuse of TLS >>>>>> library >>>>>> with application layer, thus potentially saving code. >>>>>> >>>>>> * EAP-TLS has a lot of functionality that DTLS has so one could >>>>>> consider using DTLS in conjunction with an appropriate transport. That >>>>>> transport could be PANA, CoAP or a combination of L2/L3 based. >>>>>> >>>>>> * Whatever solution is proposed for transport MUST take into >>>>>> consideration the JN-JA-JCE architecture, i.e. need to consider a >>>>>> point-to-point communication between JN and JA (unauthenticated network) >>>>>> and normal communication between JN and JCE. >>>>>> >>>>>> * If CoAP is used as a transport, it must be distinguishable from >>>>>> other CoAP traffic. This could either be through port or URI. >>>>>> >>>>>> * Whilst PANA is an additional protocol, it is pretty lightweight and >>>>>> is purely an authentication transport. The main issue I heard regarding >>>>>> PANA is the fact it uses UDP and this can cause issues for stacks >>>>>> (especially Linux-based stacks) >>>>>> >>>>>> >>>>>> What exactly is the issue there? >>>>>> >>>>>> * Using PANA in 802.15.9 is a case of transporting the data in IEs. >>>>>> We took a different (IMHO simpler) approach in ZigBee IP and transported >>>>>> the PANA UDP datagrams using 6LoWPAN over unsecured 802.15.4 packets. >>>>>> However, note comment above re. use of UDP. >>>>>> >>>>>> * One bonus of using PANA is the resultant PANA session, which is >>>>>> basically a secure session between PAC and PAA, where the PAC (PANA >>>>>> client) >>>>>> is the device requiring network access. This can be used for securely >>>>>> configuring network parameters on the device, for example, in ZigBee IP >>>>>> it >>>>>> was used to securely deliver the network key. There was an idea for it to >>>>>> deliver other parameters as well but this was considered "treading on the >>>>>> toes" of 6LowPAN ND's address registration and DHCP, although in both >>>>>> those >>>>>> cases, there is no way to provide the secure session with which to >>>>>> transport the data. So I think Tero has this wrong - PANA definitely can >>>>>> be >>>>>> used to distribute keys and be used for rekeying, however I mean this >>>>>> independent of the pairwise key established as part of the authentication >>>>>> between JN and JCE. >>>>>> >>>>>> * I agree with Rafa's point that the JCE and JN should mutually >>>>>> authenticate each other. >>>>>> >>>>>> >>>>>> Alper >>>>>> >>>>>> Robert >>>>>> >>>>>> On 5 November 2015 at 00:06, Malisa Vucinic <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> > On 05 Nov 2015, at 00:18, Michael Richardson < >>>>>>> [email protected]> wrote: >>>>>>> > >>>>>>> > >>>>>>> > It seems to me that we need to write a document that explains the >>>>>>> join >>>>>>> > *environment* in terms of radio and energy considerations. >>>>>>> > Some of this discussion happened orally in security design team >>>>>>> discussions, >>>>>>> > but was perhaps assumed to be well known, or was simply assumed. >>>>>>> >>>>>>> Some of the information is available in the introduction section of >>>>>>> minimal, but I definitely agree that it would be useful to spell out >>>>>>> somewhere the repercussions this has on the energy consumption during >>>>>>> the >>>>>>> join. >>>>>>> >>>>>>> > One goal of this document is to define the simplest set of rules >>>>>>> for >>>>>>> > building a TSCH-compliant network, at the necessary price of >>>>>>> lesser >>>>>>> > efficiency. Yet, this minimal mode of operation MAY also be >>>>>>> used >>>>>>> > during network bootstrap before any schedule is installed into >>>>>>> the >>>>>>> > network so nodes can self-organize and the management and >>>>>>> > configuration information be distributed. In addition, the >>>>>>> minimal >>>>>>> > configuration MAY be used as a fall-back mode of operation, >>>>>>> ensuring >>>>>>> > connectivity of nodes in case that dynamic scheduling >>>>>>> mechanisms fail >>>>>>> > or are not available. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 6tisch mailing list >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/6tisch >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 6tisch mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/6tisch >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 6tisch mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/6tisch >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> 6tisch mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/6tisch >>>> >>>> >>>> >>>> _______________________________________________ >>>> 6tisch mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/6tisch >>>> >>>> >>> >>> _______________________________________________ >>> 6tisch mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/6tisch >>> >>> >> >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
