Re: [pcp] WG status on PCP authentication

["Zhangdacheng (Dacheng)" <[e-mail]>]

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