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.  ^_^

> -----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