Subject: [pcp] draft-ietf-pcp-port-set-03.txt

From: Peter Koch <[email-masked]>
Date: Mon, 11 Nov 2013 18:39:38 +0100

This is a review of draft-ietf-pcp-port-set-03.txt, which I know
has passed WG last call.  Following the discussion in Vancouver I would
like to raise two issues that might benefit from being addressed:

1) The "NOTE TO IANA" in section 4 is inconsistent with the remark in
   the IANA considerations section:

      NOTE TO IANA (to be removed prior to publication as an RFC): The
      number is to be assigned by IANA in the range 128-191 (i.e.,
      optional to process and created via Standards Action).

   vs.

     IANA shall allocate a code in the range 1-63 for the new PCP option
     defined in Section 4.

   The note given in section 4 is what should go into the IANA considerations
   section, exactly identifying the IANA registry
   "PCP options" as per section 19.4 of RFC 6887.

   The draft does not explicitly state whether PORT_SET is optional
   or mandatory, although section 4.1 seems to suggest it's optional:

     If the PORT_SET option is not supported by the server, the PCP client
     will receive a response with no PORT_SET option, which is the
     operation of a PCP server that does not support PORT_SET.

   It would help the reader to understand what the choice is and the
   reasoning behind it.

2) The use cases in section 1 as well as the reasoning in section 3
   suggest that the PORT_SET is a method of convenience that, among other
   features, reduces latency compared to multiple subsequent
   single port requests.  The document does not mention whether a
   MAP/PORT_SET option is an atomic transaction, even though to the
   client it appears as such, since it will receive all-or-nothing.

   However, the fallback strategy outlined in section 3 ...

      Therefore, while it is functionally possible to obtain the same
      results using plain MAP, the extension proposed in this document

   and section 4.1

      If the PORT_SET option is not supported by the server, the PCP client
      will receive a response with no PORT_SET option, which is the
      operation of a PCP server that does not support PORT_SET.  That
      response will map one port.  To map its other desired ports, the PCP
      client will then have to issue individual MAP requests with no
      PORT_SET option to achieve similar functionality.

   made me think of potential resource contention issues (a.k.a.
   Dijkstra's 'dining philosophers'), expecially when asking for larger
   port ranges.  This would not follow from the new option, but originates
   from within the application. Still, I think the suggested fallback
   should be accompanied by an appropriate warning.

   The example given in 5.1 as well as the discussion in Vancouver
   mentioned mapping requests that would only be partly satisfied and
   often enough deemed "good enough".  Given that port diversity is
   sometimes used as a security measure (RFC 5452, RFC 6056), I'd
   like to suggest to add a remark to the security considerations
   section respectively.

As a minor one, I'd suggest to add an informational reference to RFC 4787
for a definition of 'port parity'.

-Peter

---

From: Simon Perreault <[email-masked]>
Date: Mon, 11 Nov 2013 14:17:43 -0500

Peter,

Thanks a lot for your review.

The next revision will be adjusted according to your comments.

Thanks,
Simon

Le 2013-11-11 12:39, Peter Koch a écrit :
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp
>

-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca