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

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:apps-discuss-
> [e-mail]] On Behalf Of Vijay K. Gurbani
> Sent: Friday, February 10, 2012 1:58 PM
> To: [e-mail]; [e-mail]
> Subject: [apps-discuss] APPSDIR rdraft-ietf-pcp-base-22
> 
> 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. 

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

Done.  Will appear in -24.

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

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


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

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.

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

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.


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

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?


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

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.


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

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


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

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.


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

Done, will appear in -24.


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

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


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

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


> 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} / [e-mail]
> Web:   http://ect.bell-labs.com/who/vkg/
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss