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
