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

[Yoshihiro Ohba <[e-mail]>]

(2012/09/19 21:03), Reinaldo Penno (repenno) wrote:
(snip)
>>
>> 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.

I suggest taking a look at the open source implementations that I
pointed and Sam analyzed, and send comments to this list as Sam did.
You would have some points, and your comments will be valuable to
improve the quality of the open source implementations,

Yoshihiro Ohba

> 
> 
>>
>>
>>> [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
>>>
>>>
>>
> 
> _______________________________________________
> pcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pcp
>