Re: [pcp] Side-by-side or nested protocols (was Re: PANA implementatinos to consider)

[Alper Yegin <[e-mail]>]

Hi Margaret,
> 
> On Sep 18, 2012, at 3:30 AM, Alper Yegin wrote:
>> But more interestingly, you said you are not aware of any PANA implementations in production.
>> As we said before, PANA is adopted into Zigbee Smart Energy Profile 2.0
>> And it passed several interop events, with 10 implementations.
> 
> Do you actually think that any nodes that implement SEP 2.0 will implement PCP?
> 

First, let's recognize different types of "re-use":
- spec re-use
- source code re-use
- binary re-use

Your question is specifically about the last one.  I think the answer to the first two are clear, and that by itself goes a long way.

Even binary re-use is a possibility, like Yoshi explained, and also considering the possibility of integrated gateways.


> [For those unfamiliar with Zigbee SEP 2.0, it is one of the standards (the only IP-based one, I think) proposed for use in the Smart Grid, specifically for appliances, sensors and other embedded devices to integrate with a home energy management system (EMS) and/or electric meter (Smart Meter) on the in-home side of the Smart Energy universe.  Implementations of SEP 2.0 are most often provided in ASICs, for integration into embedded devices with very limited system requirements.  These devices run on a dedicated Zigbee networks within the home, and do not generally communicate outside the home, at all.]
> 
>> Yes, it could be tricky, if we had a funky relationship between the two protocols. But in this case, it's a clean separation. PCP needs keys to run, it triggers PANA to generate the keys, PANA does its job and gives back the keys, PCP runs with the keys. This is how separate "key management" works. Natural fit.
> 
> The success case in the side-by-side approach appears to work very smoothly, it is the error cases that I am more concerned about.  

Which specific error cases? You raised one about auth capability mismatch and I already responded to that.


> Also, you haven't explained how you would deal with all of the things you list below...  If PCP has a simple request/response API with PANA, how are things like "asynchronous requests" handled in that model?  What is an "asynchronous request" in this context and when/why would it happen, BTW?  I understand that, in PANA, it is possible for network access to be renegotiated, or for Ip addresses to be reallocated.  There is no equivalent notion in PCP, though.
> 

EAP re-authentication can be initiated by either party at any time. We need to support that.

>> But, if we embed one protocol inside the other, then you have to combine the state machines. And that combining is not a simple jump back and forth like in the above case. More specifically, within the PCP state machine, now you have to account for server-side retransmissions, server-side asynchronous requests, etc.
> 
> You keep claiming that there will be problems with "combining the state machines" of PCP and PANA in the encapsulation case that aren't there in the side-by-side case, but I'm still not sure what you mean by this.  Could you give a concrete example?

Please see my email with EAP-over-PCP subject line. As you see, the state machines and flows of PCP and EAP-over-PCP are not compatible. If you try to fit the latter into the former, it won't work -- incompatible. Exact same issue with EAP-over-DHCP. I (naively?) assumed you'd not want to impact the PCP design hence this compatibility issue is a problem. 


> 
>>> PCP is capable of sending unsolicited messages (both multicast and
>>> unicast). So, we are good here.
>> 
>> You are referring to "announcements" right?
>> They are one-way notifications.
>> What you need is a server-initiated, multi-round-trip req/rsp exchanges -- to have a working EAP lower-layer.
> 
> How do we get this in a model that you have described as:  "PCP needs keys to run, it triggers PANA to generate the keys, PANA does its job and gives back the keys, PCP runs with the keys. "  Won't this notion (of server-initiated messages) need to be integrated into the API between PCP and PANA somehow?  When would these messages ever happen in the PCP context?
> 

Whether the client-side or the server-side initiated the re-auth, EAP/PANA is executed and new security association is generated. The new parameters are stored in the data structures where the PCP client picks them up next time it needs to send a request. 

Alper





> Margaret
> 
>