Re: [pcp] Comparison of PCP authentication

> -----Original Message-----
> From: Zhangdacheng (Dacheng) [mailto:zhangdacheng@huawei.com]
> Sent: Wednesday, August 08, 2012 6:57 PM
> To: Dan Wing; 'Margaret Wasserman'; hartmans@painless-security.com
> Cc: pcp@ietf.org
> Subject: RE: [pcp] Comparison of PCP authentication
> 
> Slide 5 only illustrates a scenario where the pcp server initiates the
> authentication procedure. But in our draft, it is also described that
> the client can initiate authentication proactively. In my opinion, this
> approach seems even more preferable.  ^_^

Depends on if we want to optimize for the case where PCP authentication
is necessary or is unnecessary.

Doing PANA first is a good optimization only if the PCP client knows 
that PCP authentication will be required by the PCP server on that 
particular network.  If PCP authentication is not needed on a particular 
network, requesting PCP authentication incurs an extra round trip.

If the PCP server doesn't want authentication, I believe we can always 
rely on a PCP error response if for PANA messages and for 
PCP-encapsulated (tunneled) PANA messages (which I believe are the two
proposals being considered) -- thus, we won't have timeouts due to
requesting authentication, which is good.

-d

> > -----Original Message-----
> > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of
> Dan
> > Wing
> > Sent: Thursday, August 09, 2012 1:57 AM
> > To: 'Margaret Wasserman'; hartmans@painless-security.com
> > Cc: pcp@ietf.org
> > Subject: Re: [pcp] Comparison of PCP authentication
> >
> > > -----Original Message-----
> > > From: Margaret Wasserman [mailto:mrw@lilacglade.org]
> > > Sent: Wednesday, August 08, 2012 10:07 AM
> > > To: Dan Wing
> > > Cc: 'james woodyatt'; pcp@ietf.org
> > > Subject: Re: [pcp] Comparison of PCP authentication
> > >
> > >
> > > On Aug 8, 2012, at 1:02 PM, Dan Wing wrote:
> > > > So, I think we are okay -- assuming we keep the idea that the PCP
> > > > client tries to first send a PCP request (and not to first send
> > > > a PANA request).
> > >
> > > Actually, we don't keep this, even now.  There is certainly a
> notion
> > > that a client could be configured to use authentication for all (or
> > > some) PCP exchanges, and that the authentication would come first.
> >
> > But slide 5 of your deck,
> > http://tools.ietf.org/agenda/84/slides/slides-84-pcp-10.pdf,
> > shows the PCP client doing an initial PCP request and getting an
> > AUTH_REQUIRED
> > error.  That is the basis of my (lovely) ASCII artistry.
> >
> > > > However, I do worry that implementations may optimize themselves
> > > > to send a PANA request first, which would cause the problem you
> > > > describe if they send the PANA request to a NAT-PMP server.  That
> > > > is, this would be a problem:
> > > >
> > > >  PCP client                           NAT-PMP server
> > > >      |                                    |
> > > > 1.    |-------(authentication message)---->|
> > > > 2.    |<--NAT-PMP error--------------------|
> > > >      |                                    |
> > > >
> > > > But the PCP client doesn't speak NAT-PMP, so there isn't a way
> > > > for it to handle that case, anyway (no matter if we had PCP
> > > > authentication or not).
> > > >
> > > > In summary, I think we can skate around problems with talking
> > > > to a NAT-PMP server.
> > >
> > > Makes sense.
> >
> >
> > Sam Hartman wrote:
> >
> > > It's not just that implementations may optimize sending an
> > > authentication request.
> > >
> > > An implementation MAY require authentication.
> > > I.E. it is unwilling to send the request unless it has an
> authenticated
> > > channel.
> > > For firewall control this makes a lot of sense.
> >
> > I believe we are okay -- the PCP client trying to do authentication
> will
> > have to expect it will occasionally see a NAT-PMP error message.
> That
> > will occur if it is communicating with a NAT-PMP server (which shares
> the
> > same port as PCP).  If the PCP client receives a NAT-PMP error, it
> needs
> > to abort trying to do PCP and abort trying to do PANA (because
> neither
> > will work); in the (unlikely) event the PCP client also implements
> > NAT-PMP, it can then downgrade to using NAT-PMP.
> >
> > A sentence or three in draft-ietf-pcp-authentication will be needed
> > to explain that a NAT-PMP error might be received.
> >
> > -d
> >
> >
> > _______________________________________________
> > pcp mailing list
> > pcp@ietf.org
> > https://www.ietf.org/mailman/listinfo/pcp