Re: [pcp] WG status on PCP authentication

[Margaret Wasserman <[e-mail]>]

Hi Alper,

I understand that you and Yoshi have done some analysis amongst yourselves and come to a conclusion, but my understanding of the direction from IETF 84 was that the WG wanted to go through this analysis together and come to a conclusion about which approach was preferred.

Could you share your reasoning with the rest of us, instead of just your conclusions?  What do you see as the points in favor of the side-by-side (demultiplexing) approach vs. the tunneled PANA (AKA encapsulation) approach?  Are there weaknesses to the encapsulation approach that make the demultiplexing approach more desirable?

Thanks,
Margaret


On Sep 13, 2012, at 5:13 AM, Alper Yegin wrote:

> Hi Dave,
> 
> Thank you for the summary.
> 
>> The main comparison point we know about
>> is between Tunneled PANA vs Side-by-side PANA/PCP.
> 
> 
> 
> Yoshi and I had an offline discussion and concluded that the so-called side-by-side PANA/PCP (or, running PANA over PCP port) is simple and straightforward, compared to tunneled PANA (carrying PANA header and payloads as PCP options -- more like PANA over PCP). So, we diverted our energy to the former and produced http://tools.ietf.org/html/draft-ohba-pcp-pana-02. 
> 
> I don't see problems with PANA over PCP port, or benefits with PANA over PCP to motivate me to work the details of PANA over PCP. 
> Does anyone see? 
> If not, then we'd only have PANA over PCP port to show people in the call.
> 
> 
> Alper
> 
> 
> 
> 
> 
> 
> 
> On Sep 13, 2012, at 1:48 AM, Dave Thaler wrote:
> 
>> Just to circle back on this now that the minutes are posted.
>>  
>> Relevant snippets from the minutes:
>> > Francis Dupont: How does this compare to just running PCP over DTLS?
>> > 
>> > Margaret Wasserman: There is currently no draft written to specify how it
>> >    would work.  You can't "just run" anything over DTLS. It's not that simple.
>>  
>> Summary: we have not explicitly called a question about DTLS.   Mainly
>> because there’s no proposal on the table.   Lacking one with real support,
>> the WG will go ahead with a proposal that has energy/interest behind it.
>>  
>> > Alain Durand called for show of hands:
>> > For single port: 23
>> > For two separate ports: 0
>>  
>> Clear consensus within the room, and I’ve seen no indication on the list that this
>> consensus can’t be considered confirmed based on the list discussion thus far.
>>  
>> > Alain Durand called for show of hands:
>> > PCP-specific messages (PCP-specific encoding of authentication information): 5
>> > Tunneled PANA (embed PANA data within PCP options): 6/7
>> > Side-by-side (multiplex raw PANA packets and PCP packets over same port): 5/6
>> > Don't care: 15
>>  
>> Room was basically evenly split between the approaches above, so no
>> consensus yet, but only about half the WG cares.
>>  
>> > Alain Durand called for show of hands:
>> > PCP-specific encoding of authentication information: 5
>> > Some kind of PANA encapsulation: 10 or 11
>>  
>> In my view there was a rough consensus of the room, and so far the list discussion
>> hasn’t changed this ratio in my view.
>>  
>> > Dan Wing: request an interim meeting to discuss solutions, once they've been
>> >    fleshed out a little
>>  
>> And that’s the step we’re doing next.   The main comparison point we know about
>> is between Tunneled PANA vs Side-by-side PANA/PCP.   We can also compare
>> PCP-specific though it appears to already be in the minority.  If there are other new
>> proposals to consider (DTLS or whatever) by then, we can, but so far the inertia
>> seems to be primarily between the PANA variants.   There does seem to be
>> uncertainty about how they would actually work, so it’s important that they be
>> fleshed out in enough detail that we can have informed discussion at the interim
>> meeting.
>>  
>> -Dave
>>  
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Alper Yegin
>> Sent: Friday, August 17, 2012 1:09 AM
>> To: Margaret Wasserman
>> Cc: [e-mail]
>> Subject: Re: [pcp] Comparison of PCP authentication
>>  
>>  
>> On Aug 16, 2012, at 2:38 PM, Margaret Wasserman wrote:
>> 
>> 
>>  
>>  
>> Hi Dacheng,
>>  
>> The conclusion from the meeting was that we will document all three approaches in our document:
>>  
>>  
>> Could the chairs please declare what the meeting conclusions and next steps are.
>>  
>> Thanks.
>>  
>> Alper
>>  
>>  
>>  
>> 
>> 
>> - PCP Specific
>> - PANA Encapsulated in PCP
>> - PANA Demultiplexed with PCP on the same port
>>  
>> Then, we will have an interim PCP conference call to discuss the trade-offs and hopefully decide between them.
>>  
>> Margaret
>>  
>>  
>>  
>> On Aug 15, 2012, at 10:47 PM, Zhangdacheng (Dacheng) wrote:
>> 
>> 
>> Have we got any conclusions on two approaches?  Or we can just support the two options in the draft for the moment and briefly compare their pros and cons, can we?
>>  
>> Cheers
>>  
>> Dcheng
>>  
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Margaret Wasserman
>> Sent: Friday, August 10, 2012 3:21 AM
>> To: Dan Wing
>> Cc: [e-mail]
>> Subject: Re: [pcp] Comparison of PCP authentication
>>  
>>  
>> On Aug 9, 2012, at 2:32 PM, Dan Wing wrote:
>>  
>> If I'm updating security policy on a firewall I want to be able to
>> audit whether that actually happened.  That requires authentication.
>> 
>> You are saying a PCP client would only want to update firewall policies 
>> if the PCP server supports authentication, otherwise it would tell the
>> user that it cannot enable the webcam, Internet-connected NAS, 
>> Internet-connected printer, etc.?
>>  
>> I wont presume to guess what Sam is thinking...
>>  
>> However, I am thinking that there will be some clients  that are configured to perform authentication for every request.  For example, there is no reason for a PCP proxy, running in an environment where authentication is required to do a THIRD-PARTY request, to perform a useless round-trip for every THIRD-PARTY request it issues.  
>>  
>> Margaret
>>  
>>  
>>  
>> _______________________________________________
>> pcp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pcp
>>  
>> _______________________________________________
>> pcp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pcp
> 
> _______________________________________________
> pcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pcp