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 <alper.ye...@yegin.org> 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 <alper.ye...@yegin.org> 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 <alper.ye...@yegin.org> 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 <malisa.vuci...@imag.fr> >>> wrote: >>> >>>> >>>> > On 05 Nov 2015, at 00:18, Michael Richardson <mcr+i...@sandelman.ca> >>>> 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 >>>> 6tisch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6tisch >>>> >>> >>> _______________________________________________ >>> 6tisch mailing list >>> 6tisch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tisch >>> >>> >>> >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> >> >> > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > >
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
