There are very large TSCH/RPL/LoWPAN PANA deployments in the market as well…it’s well past the experimental stage.
R. > On Nov 5, 2015, at 10:23 AM, Paul Duffy <[email protected]> wrote: > > Re: PANA traction in the market. > > AFAIK Zigbee IP has no deployed footprint and none are pending. > > Wi-SUN consists of several profiles. EchoNet and Field Area Network being > prominent. FAN is using 802.1X / EAP-TLS. > > > On 11/3/2015 2:52 AM, Alper Yegin wrote: >> Hi Malisa, >> >> On Oct 31, 2015, at 11:10 PM, Malisa Vucinic wrote: >> >>> Thanks for the clarification. We are trying to maximize code reuse >> Then please note that PANA is RFC, has multiple implementations, adopted by >> other standards (Zigbee and Wi-Sun), and already getting deployed (Wi-Sun). >> >> >>> and minimize number of exchanges. In Q17 I see that Client Initiation >>> message is omitted if network can detect on its own the presence of JN, >>> which is not the case in 6tisch. >> OK. >> Note that, though, any solution you'd have would need to have the equivalent >> of that one message where the client says "hello, let's start auth". >> >> >>> I suppose that we are then left with EAP overhead plus an extra discovery >>> message. >>> >> I see the EAP overhead is being debated already. >> But like I said above, discovery message needs to be supported by any other >> solution as well, hence I don't think it's extra for "EAP/PANA" >> >> Alper >> >> >> >> >>> Regards, >>> Mališa >>> >>> >>>> On 31 Oct 2015, at 22:43, Alper Yegin <[email protected]> wrote: >>>> >>>> Hello, >>>> >>>> I've read the thread. I see there are some PANA-related questions. Let me >>>> clarify them. >>>> >>>> Like Rafa said, PANA is already adopted and fully defined by Zigbee IP. >>>> Hence I'd expect it's ready to be used for 6tisch as well. Are there >>>> anything special here in 6tisch that'd make a difference with respect to >>>> network access authentication and key management? >>>> >>>> >>>> PANA assumes the JN has an IP address. That IP address can be a link-local >>>> IP address. >>>> (Not sure if this work really needs a solution that operates before *any* >>>> IP address is configured on the JN. But if it does, then here's an expired >>>> work on that front: >>>> https://tools.ietf.org/html/draft-yegin-pana-unspecified-addr-06) >>>> >>>>> - Traffic load: minimum 4 messages for PANA + [ 5 messages for EAP-AKA, >>>>> 15+ messages for EAP-TLS ] + 1 packet to provision K2 >>>> Not sure where that "4 messages" come from. It can be "0". See Q16 and Q17 >>>> in http://www.panasec.org/docs/PANA-FAQ.txt. >>>> Also that last 1 packet is not needed either. The last packet sent from >>>> the authenticator can deliver that payload. >>>> >>>> I don't think a separate KMP is needed when we use PANA. >>>> Because: >>>> - EAP/PANA authentication generates PANA SA between the JCE and JN. Which >>>> can used for further key derivation. Given the PANA is extensible thru >>>> AVPs, additional parameters can be delivered between the end-points if >>>> necessary. >>>> - RFC 6786 defines how PANA can carry encrypted payloads, which can be >>>> used for delivering keys. >>>> >>>> I hope these help. >>>> >>>> Alper >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you. _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
