Re: [pcp] Comparison of PCP authentication

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

If a client has been configured to support PANA, then it is more likely to stay in an environment where authentication is required, is it? ^_^ However, if this assumption is broken, then two approaches do not make big differences. 


> From: Dan Wing [mailto:[e-mail]]
> Sent: Thursday, August 09, 2012 10:29 AM
> To: Zhangdacheng (Dacheng); 'Margaret Wasserman';
> [e-mail]
> Cc: [e-mail]
> Subject: RE: [pcp] Comparison of PCP authentication
> 
> > -----Original Message-----
> > From: Zhangdacheng (Dacheng) [mailto:[e-mail]]
> > Sent: Wednesday, August 08, 2012 6:57 PM
> > To: Dan Wing; 'Margaret Wasserman'; [e-mail]
> > Cc: [e-mail]
> > 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: [e-mail] [mailto:[e-mail]] On Behalf Of
> > Dan
> > > Wing
> > > Sent: Thursday, August 09, 2012 1:57 AM
> > > To: 'Margaret Wasserman'; [e-mail]
> > > Cc: [e-mail]
> > > Subject: Re: [pcp] Comparison of PCP authentication
> > >
> > > > -----Original Message-----
> > > > From: Margaret Wasserman [mailto:[e-mail]]
> > > > Sent: Wednesday, August 08, 2012 10:07 AM
> > > > To: Dan Wing
> > > > Cc: 'james woodyatt'; [e-mail]
> > > > 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/pcp