Subject: [apps-discuss] APPSDIR rdraft-ietf-pcp-base-22

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 10 Feb 2012 15:57:57 -0600

Document: draft-ietf-pcp-base-22
Title: Port Control Protocol (PCP)
Reviewer: Vijay K. Gurbani
Review Date: Feb-10-2012
IETF Last Call Date: Not known
IESG Telechat Date: Not known

Summary: This draft is almost ready for publication as a Proposed
Standard but has a few issues that should be fixed before publication.

Major issues: 0
Minor issues: 11
Major issues: 0

Issues listed below are in document order.

- S5, the all zeroes IPv4 address as defined by the draft is a
  contribution of the draft itself, right?  That is, at least I am not
  aware whether ::ffff:0:0 is generally used as the all-zero IPv4-mapped
  IPv6 address.  It may well be, in which case this comment can be
  ignored.  But if it is not a general use address and is intended to be
  defined by this draft, I wonder if rfc2119 MUST is appropriate here (as
  in "The all-zeroes IPv4 address MUST be expressed as: 80 bits of
  zeros, 16 bits of ones, and 32 bits of zeros (::ffff:0:0).").

- S6.1, the "Opcode-specific information" block of Figure 2 is not
  discussed at all in the text following Figure 2.

- S6.1, the "PCP Options" block of Figure 2 is not discussed at all in
  the text following Figure 2.  You do provide a Section 6.3 that
  discusses options; perhaps it is sufficient to say the following at
  the end of the text following Figure 2: "PCP Options: Please see
  Section 6.3".

- Ditto for S6.2 and Figure 3's use of "Opcode-specific response data"
  and "Options" block.

- S7.1, second-to-last paragraph: I suspect that if more than one server
  was specified in the server list, the client will cycle through and
  try the next server.  I also note that this document only considers
  one server, so exact guidance is not provided on what to do when a PCP
  client has more than one server.

  But I think it possible that the default router list (mentioned earlier
  in the section) creates a list of two servers: an IPv4- and
  IPv6-server.   Would it be prudent to try the IPv6 server if the IPv4
  server --- and vice-versa --- did not result in any response within
  the maximum retransmission interval of 15m?

- S7.3, the third paragraph from the end of the section ("For both ...
  is RECOMMENDED."): Here you say that "A limit of 24 hours for success
  responses and 30 minutes for error responses is RECOMMENDED."

  However, in S6.4 you said that, "It is RECOMMENDED that short
  lifetime errors use a 30 second lifetime and long lifetime errors
  use a 30 minute lifetime." So --- is S7.3 treating *all* error
  responses as long lifetime errors?

- S9.1: The algorithm provided is excellent, but can only be used
  when writing new servers (since it requires sending and receiving
  PCP messages).  This should be made clear before the algorithm.  (I
  believe that this stands to reason, but being explicit does not
  hurt.) Existing servers that need to be reachable from the outside, but
  ones whose source code cannot be modified, will need to arrange for
  an explicit static mapping to happen before they are started.

- I believe that the above issue is true for S9.{2,3} as well.

- S16.1.1: I am not sure how to interpret the listed attacks
  in this section.  Is it the case that these attacks can happen
  even if PCP servers comply with the Simple Threat Model?  Or is
  it the case that the Simple Threat Model mitigates these attacks?

- S16.2: To protect against Advanced Threat Model attacks, the
  draft assumes a PCP security mechanism that provides channel
  authentication and encryption.  However, no further information
  is provided for such a mechanism.  Will it help to provide
  any candidates for such a mechanism (TLS?  S/MIME?) or is there
  something entirely different in mind?

- S16.3.1: As far as I can see, there is no mitigation for Denial
  of Service attack mounted by an attacker on the path between the
  PCP client and PCP server, yes?  If so, it will be nice to
  explicitly state this.

Nit:

- S3, while discussing Internal Host: The term "PCP MAP" request is used
  here without further context, like a short definition.  Clearly, the
  PCP MAP request arranges for a mapping to occur in the NAT ... the
  reader can tell that much.  But all the same, for the sake of
  completeness, it will be good to provide a quick definition when the
  term is first used.

- S3, while discussing Explicit static mappings: any reason why a GUI
  (distinct from a web-based UI) is omitted?  I suspect the answer is
  just plain oversight, but just the same, I think it will not hurt to
  include it in, or simply take out the text in the brackets.

- S16.2: s/mechanism which provides/mechanism that provides

That's it.  Thanks!

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 13 Feb 2012 17:07:04 -0800

> -----Original Message-----
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Vijay K. Gurbani
> Sent: Friday, February 10, 2012 1:58 PM
> To: [email-masked]; [email-masked]
> Subject: [apps-discuss] APPSDIR rdraft-ietf-pcp-base-22
> 
>   ignored. 

I attempted to search for the phrase, and for ::ffff:0:0 and :ffff:0.0.0.0,
and found no existing RFC using either notation to indicate "all-zeros
address".  So, this is the first.

> But if it is not a general use address and is intended to
> be

Done.  Will appear in -24.

> - Ditto for S6.2 and Figure 3's use of "Opcode-specific response data"

Added all of three points those described above.  Will appear in -24.

>   client has more than one server.

We are purposefully silent on multiple servers, because we expect that
to be described in a later document.  There are a lot of nuances and
details related to multiple servers, including a multi-homed network
(where you purposefully want to talk to one server, or both servers,
for different reasons).  Such a network is purposefully out of scope.

However, we wanted the text to allow a list of servers to be returned,
so that we could do something with that list in the future.

>   the maximum retransmission interval of 15m?

The IPv6 server might do different things than the IPv4 server.  For
example, the IPv6 server might solely provide IPv6 firewall functionality
while the IPv4 server provides IPv4-only NAT functionality.  So, the
IPv6 server can only deal with IPv6 addresses, and the IPv4 server
can only deal with IPv4 addresses.

Also, the PCP server's security model expects the requests for a mapping
to an address to come from that same address.  (There is an exception
for THIRD_PARTY, but that is unnecessary in normal PCP deployments and
not expected to be implemented.)  The reason for that security model
is that there is no easy way to know that a certain IPv4 address and
a certain IPv6 address are really the same host -- and because of that,
the PCP server can't decide to allow a PCP request sent over IPv6 
transport to open a mapping to an internal IPv4 address.

>   responses as long lifetime errors?

No, it's trying to set an upper limit, so if the server returns a
lifetime of 5 years for an error, the client treats it as if it was
a 30 minute error.

I adjusted the sentence so it now reads:

        The PCP client SHOULD impose
        an upper limit on this returned value (to protect against
        absurdly large values, e.g., 5 years), and the suggested values
        are 24 hours for success responses and 30 minutes for error 
        responses.

which should be clearer?

>   an explicit static mapping to happen before they are started.

There was an idea to have a host's IP stack automatically notify 
firewalls (when authorized by the user) of an application listening 
on a port.  This idea was originally brought up in 
http://tools.ietf.org/html/draft-woodyatt-ald for the ALD protocol,
and could also be done using PCP.  I don't see a need to prevent / 
discourage it in the document.

> - I believe that the above issue is true for S9.{2,3} as well.

Yes, to get the features of the new protocol, client applications 
will have to change.  I don't think that is unique to PCP, though.

>   it the case that the Simple Threat Model mitigates these attacks?

Section 16.1.1 enumerates the threats that are considered in 
the rest of 16.1.

>   something entirely different in mind?

The candidate at this time is draft-wasserman-pcp-authentication, 
which uses EAP.  However, it is not yet a working group document
and it seemed premature to cite it.

>   PCP client and PCP server, yes?  If so, it will be nice to

Done, will appear in -24.

>   completeness, it will be good to provide a quick definition when the

Good catch; both PEER and MAP can create a new mapping, so I changed
it from 
  ... incoming traffic resulting from a PCP MAP request ...
to
  ... incoming traffic resulting from a PCP mapping request ...

>   include it in, or simply take out the text in the brackets.

Dropped "web-based", so it now reads

     (e.g., via command-line interface or other user interface)

> - S16.2: s/mechanism which provides/mechanism that provides

Thanks for your review!

-d

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

---

From: S Moonesamy <[email-masked]>
Date: Mon, 13 Feb 2012 19:18:43 -0800

Hi Dan,
>address".  So, this is the first.

Would RFC 5952 be of help?

Regards,
S. Moonesamy

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 24 Feb 2012 15:32:31 -0600

Dan: Sorry for the delay in responding.  Day job gets in the
way.

Please see inline for residual comments.  I am skipping all
those that we agreed on for brevity.  Thanks for attending to
these!

On 02/13/2012 07:07 PM, Dan Wing wrote:
>> - S7.1, second-to-last paragraph: I suspect that if more than one
>> server was specified in the server list, the client will cycle
>> through and try the next server.  I also note that this document
>> only considers one server, so exact guidance is not provided on
>> what to do when a PCP client has more than one server.
>

Sure; maybe a small indented note will help the reader that you allow
a list of servers for future extensibility but in this draft you are
only considering the case where this list has a singleton element.  (I
know I would have found such a note helpful as an implementer).

>          are 24 hours for success responses and 30 minutes for error

Perfect.  Thanks!

> and it seemed premature to cite it.

... even as an Informational Reference?

> Thanks for your review!

No problem; thank you for paying attention to my comments!

- vijay