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

["Reinaldo Penno (repenno)" <[e-mail]>]

-----Original Message-----
From: Alper Yegin <[e-mail]>
Date: Wed, 19 Sep 2012 10:57:37 +0300
To: Margaret Wasserman <[e-mail]>
Cc: Reinaldo Penno <[e-mail]>, "Henderickx, Wim (Wim)"
<[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Side-by-side or nested protocols (was Re: [pcp] PANA
implementatinos to consider)

>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.


I do not think it is clear. The devices implementing PCP Server (routers,
FW, CGNs, CPEs, etc) will most likely not be able to reuse source code
from Zigbee. There are threading considerations, 64 vs. 32 bit, memory
management, configuration, events. The list goes on and on. My experience
with protocol code reuse between such different platforms is not very rosy.


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


Like getting PANA binary from Zigbee and running on a CGN, CPE/High end
Firewall running on a different NPU type without rewriting almost from
scratch, recompilation, integration with CLI, debug, etc ? Please excuse
my skepticism when I doubt this. But to be fair, please point me to your
best candidate for this reuse and I will see if we can look into it if WG
thinks it will help the process.


>
>
>> [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
>> 
>> 
>