Re: [pcp] WG status on PCP authentication

[Yoshihiro Ohba <[e-mail]>]

Hi Dacheng,

A good question.  Actually both approaches has some impact on RFC 5191
to allow PANA to run over a non-PANA port (which would require
updating RFC 5191).  This made me think that the need for updating RFC
5191 to use the Reserved field in the demultiplexing approach is not
considered as a cons.

Regards,
Yoshihiro Ohba

(2012/09/14 17:30), Zhangdacheng (Dacheng) wrote:
> Hi, Yoshihiro:
> 
> I remember that in one of your previous emails you mentioned that a con of the de-multiplexing approach is its Impact on PANA specification (an Update of RFC 5191 is needed on the use of "Reserved" field.). But you didn't mentioned it here. Maybe I have missed some important discussion. Could you please tell me whether you have find some way to avoid it?
> 
> Cheers
> 
> Dacheng
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Yoshihiro Ohba
>> Sent: Friday, September 14, 2012 2:52 PM
>> To: [e-mail]
>> Subject: Re: [pcp] WG status on PCP authentication
>>
>> 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
>>>
>>
>> _______________________________________________
>> pcp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pcp
>