Subject: [pcp] Comments on draft-ietf-pcp-base-13

From: Margaret Wasserman <[email-masked]>
Date: Mon, 25 Jul 2011 23:50:57 -0400

I just completed a review of draft-ietf-pcp-base-13.  The document is looking pretty good at this point, but I found a few issues that I'd like to see addressed before publication.  I have included a list of my issues below, broken into separate categories for substantive issues (4 of them), comments (2 of them) and editorial nits (4).  Please let me know if you would like me to submit these issues in some other form.

I also continue to think that we need to improve the Security Considerations section before publication (as discussed in an older open issue, #52).  I am working on some text for an improved Security Considerations section, and I will send it in a separate message as soon as I complete that work...  Hopefully before the meeting tomorrow.

Please let me know if you have any questions about my issues below.

Thanks,
Margaret

-----

SUBSTANTIVE ISSUES:

ISSUE #1, In Section 6.1:

The following section doesn't seem correct to me:

   When attempting to contact a PCP server, the PCP client initializes a
   timer to 2 seconds.  The PCP client sends a PCP message to the first
   server in its list of PCP servers.  If no response is received before
   the timer expires, the timer is doubled (to 4 seconds) and the
   request is re-transmitted.  If no response is received before the
   timer expires, the timer is doubled again (to 8 seconds) and the
   request is re-transmitted.

As far as I can tell, the above paragraph never indicates that a PCP Client will attempt to reach the second, or any subsequent, servers in the PCP server list.

   Once a PCP client has successfully received a response from a PCP
   server on that interface, it sends subsequent PCP requests to that

On what interface?  No specific interface has been mentioned.

   same server, with a retransmission timer of 2 seconds.  If, after 2
   seconds, a response is not received from that PCP server, the same
   back-off algorithm described above is performed.

Is there any attempt to use other PCP servers in the PCP server list if this fails?

ISSUE #2, in section 7:

I am having trouble understanding what is meant by this text:

   If the PCP client has both an IPv4 and IPv6 address,
   and only wants an IPv4 listener, it sends one MAP request from its
   IPv4 interface (if the PCP server supports NAT44 or IPv4 firewall) or
   one MAP request from its IPv6 interface (if the PCP server supports
   NAT64)).  The PCP client can simply request the desired mapping to
   determine if the PCP server supports the desired mapping.

Is there a particular order in which a PCP client should try these requests to get the  most desirable result?  Can you explain how the client would determine which of NAT44/IPv4 Firewall and/or NAT64 is supported by sending requests?

ISSUE #3, In section 7.2:

It seems very unlikely that applications will be willing to comply with the text in this section f the draft:

Discussion: In general, a PCP client doesn't know in advance if it
      is behind a NAT or firewall.  It can attempt to request a mapping
      using PCP, and if that succeeds then the client knows it has
      successfully created a mapping.  If after multiple retries it has
      received no PCP response, then either the client is *not* behind a
      NAT or firewall and has unfettered connectivity,

If I am reading this correctly, an application will need to wait through at least two (multiple) retries before it can begin client operations, even when it has no reason to believe that a PCP-equipped NAT is present.  That reqquires a delay of at least 14 seconds (to know the second
retry has failed)  before client activity can start.  

Do we have reason to believe that clients will actually do this?  Is there really no better way
to resolve the issue described that would have less client/user impact?

Issue #4, Throughout Document:

Now that you are using 128-bit addresses for all of the addresses, and it is possible to tell an IPv4 "all zeros" address from an IPv6 "all zeros" address, is it actually necessary to have separate MAP4/PEER4 and MAP6/PEER6 opcodes?  

COMMENTS/SUGGESTIONS

COMMENT #1, In section 8.4:

The following section could also apply to NPTv6 devices (formerly known as NAT66 devices), since there is now an RFC available for them (RFC 6296):

  If the PCP-controlled device is stateless (that is, it does not
   establish any per-flow state, and simply rewrites the address and/or
   port in a purely algorithmic fashion), the PCP server simply returns
   an answer indicating the external IP address and port yielded by this
   stateless algorithmic translation.  This allows the PCP client to
   learn its external IP address and port as seen by remote peers.
   Examples of stateless translators include stateless NAT64 and 1:1
   NAT44, both of which modify addresses but not port numbers.

COMMENT #2, Also in section 8.4:

It seems to me that the following text leaves out the most common failure case, the case where the external address requested is not assigned to the external interface of the PCP server:

   Cases where a
   NAT gateway cannot allocate the Suggested External Address and Port
   include:

   o  Where the Suggested External Address and Port is already allocated
      to another existing explicit, implicit, or static mapping (i.e.,
      is already forwarding traffic to some other internal address and
      port; or

   o  Where the Suggested External Address and Port is already used by
      the NAT gateway for one of its own services (e.g., port 80 for the
      NAT gateway's own configuration pages); or

   o  When the Suggested External Address and Port is otherwise
      prohibited by the PCP server's policy.

EDITORIAL NITS:

NIT #1, In section 6.1:

OLD:
   2.  the default router list (for IPv4 and IPv6) is used as the of PCP 
        Server(s).

NEW:
   2.  the default router list (for IPv4 and IPv6) is used as the list of 
        PCP Server(s).

NIT #2, Also in section 6.1:

OLD:
   To assist with detecting an on-path NAT, he PCP header includes the

NEW:
   To assist with detecting an on-path NAT, the PCP header includes the

NIT #3, In section 6.2:

OLD:
   A PCP server MUST only accept normal (non-THIRD_PARTY) PCP requests
   from a client on the same interface it would normally receive packets
   from that client, and silently ignores PCP requests arriving on any
   other interface.

NEW:
   A PCP server MUST only accept normal (non-THIRD_PARTY) PCP requests
   from a client on the same interface it would normally receive packets
   from that client, and silently ignore PCP requests arriving on any
   other interface.

NIT #4, In section 7:

OLD:
   The PCP client also knows if it has an IPv4 address on
   itself or an IPv6 interface on itself. It takes the union of this
   knowledge to decide which of its PCP servers to send the request

NEW:
   The PCP client also knows if it has an IPv4 address on
   itself or an IPv6 address on itself. It takes the union of this
   knowledge to decide to which of its PCP servers to send the 
   request

(Perhaps also changed "on itself" to "configured on one of its interfaces"?)

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 26 Jul 2011 09:53:08 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Margaret Wasserman
> Sent: Monday, July 25, 2011 11:51 PM
> To: [email-masked]
> Subject: [pcp] Comments on draft-ietf-pcp-base-13
> 
> I just completed a review of draft-ietf-pcp-base-13.  The document is
> looking pretty good at this point, but I found a few issues that I'd
> like to see addressed before publication.  I have included a list of my
> issues below, broken into separate categories for substantive issues (4
> of them), comments (2 of them) and editorial nits (4).  Please let me
> know if you would like me to submit these issues in some other form.
> 
> I also continue to think that we need to improve the Security
> Considerations section before publication (as discussed in an older
> open issue, #52).  I am working on some text for an improved Security
> Considerations section, and I will send it in a separate message as
> soon as I complete that work...  Hopefully before the meeting tomorrow.
> 
> As far as I can tell, the above paragraph never indicates that a PCP
> Client will attempt to reach the second, or any subsequent, servers in
> the PCP server list.
>

No.  

We punted on how the client contacts other PCP servers
to a subsequent document.  For DNS, as a similar protocol where the
client talks to a server that is responding, finding a working server
is handled differently on different OSs, and sometimes pretty 
aggressively (e.g., Windows is pretty aggressive if it can't 
get a DNS response).

Multiple PCP servers are not in any of our initial scenarios, so
we want to defer this to a later document.

> Is there a particular order in which a PCP client should try these
> requests to get the  most desirable result? 

No particular order.

> Can you explain how the
> client would determine which of NAT44/IPv4 Firewall and/or NAT64 is
> supported by sending requests?

It sends a request.  If there is a positive response, that means
the upstream PCP server (and NAT/firewall) supports it.

I honestly don't know what other text to add.

> If I am reading this correctly, an application will need to wait
> through at least two (multiple) retries before it can begin client
> operations, even when it has no reason to believe that a PCP-equipped
> NAT is present.  That reqquires a delay of at least 14 seconds (to know
> the second

The application can determine if it's behind a NAT (or firewall)
when it detects the host has connected to a network.  It doesn't
need to do PCP detection at the beginning of a VoIP call.

> Now that you are using 128-bit addresses for all of the addresses, and
> it is possible to tell an IPv4 "all zeros" address from an IPv6 "all
> zeros" address, is it actually necessary to have separate MAP4/PEER4
> and MAP6/PEER6 opcodes?

Yes, MAP and PEER need to remain separate.  I'll have a slide on that
in the session later today.

They need to remain separate because they are still semantically
different:  they are doing different things.  And it would not 
ease reading of the document, nor ease implementations, to
substitute PEER for "MAP request with an all-zeros remote peer
address".

> The following section could also apply to NPTv6 devices (formerly known
> as NAT66 devices), since there is now an RFC available for them (RFC
> 6296):
> 

Thanks.  Added.

> It seems to me that the following text leaves out the most common
> failure case, the case where the external address requested is not
> assigned to the external interface of the PCP server:
> 
>    Cases where a

Fixed.

> EDITORIAL NITS:

Adopted all nits, thanks.

-d

> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp