Re: [pcp] WG status on PCP authentication

[Yoshihiro Ohba <[e-mail]>]

Last month I posted a rough comparison on the two PANA approaches to
the PCP ML.  I would like to update the comparison after working in
detail on the demultiplexing approach as follows:

Encapsulation/tunneling approach:
- Pros: ???
- Cons:
 -- Encapsulation overhead
 -- Tight coupling of PCP and PANA is needed.  One issue is that some
workaround is needed to carry a PCI (PANA-Client-Initiation) message
which does not fit PCP's request-response type messaging.
Another issue is that double integrity protection can happen after
establishing a PCP SA, where a PANA message carried in the PCP message
is protected by a PANA AUTH AVP and the PCP message itself is
protected by a PCP Authentication Tag.  Double integrity protection
can be considered as overhead.

Demultiplexing/port-sharing approach:
- Pros:
 -- No encapsulation overhead
 -- Loose coupling of PCP and PANA

- Cons: ???

Yoshihiro Ohba


(2012/09/13 20:06), Margaret Wasserman wrote:
> 
> 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]>[mailto:[e-mail]]*On 
>>> Behalf Of*Alper Yegin
>>> *Sent:*Friday, August 17, 2012 1:09 AM
>>> *To:*Margaret Wasserman
>>> *Cc:*[e-mail] <mailto:[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]>[mailto:[e-mail]] 
>>> <mailto:[mailto:[e-mail]]>*On Behalf Of*Margaret Wasserman
>>> *Sent:*Friday, August 10, 2012 3:21 AM
>>> *To:*Dan Wing
>>> *Cc:*[e-mail] <mailto:[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] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/pcp
>>> _______________________________________________
>>> pcp mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/pcp
>>
>> _______________________________________________
>> pcp mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/pcp
> 
> 
> 
> _______________________________________________
> pcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pcp
>