Re: [pcp] Comparison of PCP authentication

> -----Original Message-----
> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of
> james woodyatt
> Sent: Monday, August 06, 2012 4:03 PM
> To: pcp@ietf.org
> Subject: Re: [pcp] Comparison of PCP authentication
> 
> On Aug 6, 2012, at 13:02 , Margaret Wasserman <mrw@lilacglade.org>
> wrote:
> >
> > Do you know what existing PANA implementations will do if the
> "Reserved" field at the start of the packet is non-zero?
> 
> A related question might be what existing NAT-PMP implementations will
> do if they receive a message containing a PANA packet. 

That is important to consider.  However, the message flows I have seen
show:

  PCP client                           PCP server
      |                                    |    
1.    |------PCP MAP request-------------->|
2.    |<---error, need authentication------|
      |                                    |
3.    |-(several authentication messages)->|
4.    |<-(several authentication messages)-|

If the PCP client is really communicating with a NAT-PMP server, it
would look like this,

  PCP client                           NAT-PMP server
      |                                    |    
1.    |------PCP MAP request-------------->|
2.    |<---error, wrong version------------|
      |                                    |    
3.    |------NAT-PMP request-------------->|
4.    |<---ok------------------------------|
      |                                    |    

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

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.

-d

> Assuming they
> comply with I-D.cheshire-nat-pmp-03, they will interpret the first two
> octets of a PANA message as an announcement request, and they will
> reply with the announcement response message shown below.
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Vers = 0      | OP = 128 + 0  | Result Code                   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Seconds Since Start of Epoch                                  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | External IP Address (a.b.c.d)                                 |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> If a PCP server needs to implement NAT-PMP too, then it can easily
> distinguish a NAT-PMP announcement request from a PANA message, but one
> wonders if a PANA client expecting to authenticate to such a server can
> deal with replies from a NAT-PMP server that knows nothing about either
> PCP or NAT-PMP.
> 
> 
> --
> james woodyatt <jhw@apple.com>
> member of technical staff, core os networking
> 
> 
> 
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp