Well, I guess we can argue about what we mean by "proven" here. I agree that the ultimate test of the worthiness of a solution is a successful and significant field deployment. However, achieving that level of interoperability certainly proves the solution with regard to the original requirements.
Robert On 11 November 2015 at 22:34, Paul Duffy <[email protected]> wrote: > On 11/7/2015 10:40 AM, Robert Cragie wrote: > > Paul, > > Whatever the state of ZigBee IP, it doesn't alter the fact that it > successfully completed after an extensive specification, implementation and > test program, demonstrating interoperability across 7 independent > platforms, > > > Agreed. > > so the solution is certainly proven. > > > There is no way I would designate a solution as proven w/o a significant > field deployment. > > > Robert > On 5 Nov 2015 16:23, "Paul Duffy" < <[email protected]>[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]> >>>>> [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 >> > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
