Subject: [pcp] draft-ietf-pcp-base-13 posted

From: "Dan Wing" <[email-masked]>
Date: Tue, 5 Jul 2011 20:19:40 -0700

draft-ietf-pcp-base-13 was just posted.  Changes are in
http://tools.ietf.org/html/draft-ietf-pcp-base-13#appendix-B.1, and copied
below.

Side-by-side diffs between -12 and -13 are at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcp-base-13.txt

This should resolve all comments from -12's WGLC.

-d

   o  All addresses are 128 bits.  IPv4 addresses are represented by
      IPv4-mapped IPv6 addresses (::FFFF/96)

   o  PCP request header now includes PCP client's port (in addition to
      the client's IP address, which was in -12).

   o  new ADDRESS_MISMATCH error.

   o  removed PROCESSING_ERROR error, which was too similar to
      MALFORMED_REQUEST.

   o  Tweaked text describing how PCP client deals with multiple PCP
      server addresses (Section 6.1)

   o  clarified that when overloaded, the server can send
      SERVER_OVERLOADED (and drop requests) or simply drop requests.

   o  Clarified how PCP client chooses MAP4 or MAP6, depending on the
      presence of its own IPv6 or IPv4 interfaces (Section 7).

   o  compliant PCP server MUST support MAPx and PEERx, SHOULD support
      ability to disable support.

   o  clarified that MAP-created mappings have no filtering, and PEER-
      created mappings have whatever filtering and mapping behavior is
      normal for that particular NAT / firewall.

   o  Integrated WGLC feedback (small changes to abstract, definitions,
      and small edits throughout the document)

   o  allow new Options to be defined with a specification (rather than
      standards action)

---

From: Alain Durand <[email-masked]>
Date: Wed, 6 Jul 2011 05:33:31 -0700

draft-ietf-pcp-base-13 has been published to address the comments received during wg last call on the -12 revision. We would like to start a 1-week working group last call on this new revision.

The PCP wg chairs, Alain & Dave.

Sent from my iPad

On Jul 5, 2011, at 11:19 PM, "Dan Wing" <[email-masked]> wrote:

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

---

From: Francis Dupont <[email-masked]>
Date: Tue, 12 Jul 2011 16:16:38 +0200

In your previous mail you wrote:

=> I have a different opinion but I'll simply restate all
my unresolved comments at the last call...

=> no, PROCESSING_ERROR was (quoting base 12):
   6  PROCESSING_ERROR, server encountered an error after parsing while
      attempting to process a request.
so it was for "after parsing" when MALFORMED_REQUEST is about parsing.
The result is now there is *no* error code for errors after parsing...

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Tue, 12 Jul 2011 17:45:36 +0200

I reread the base 13 document and it is IMHO far to be ready:

 - the document must state as soon as the terms are defined that:
   * MAP is about explicit dynamic mapping management
   * PEER is about implicit dynamic mapping management
  (I have a point later for static mappings)

 - it is impossible to write an IWF because of some missing features:
   * there is no *standard* way to get the external address
    without a side effect (BTW I stress standard because there are
    many but this should not be fully left to implementor choice)
   * the recommended maximum lifetime is 24 hours and is incompatible
    with the IGD v2 one, so if an IWF grants a mapping with a long
    (i.e., more than 24 hours or the PCP server maximum) lifetime
    it can't handle a PCP error response to a PCP renew request...

 - there is still an unaddressed major security issue
  (no further comment about this, we'll see if it is a great idea
   at the IETF last call :-)

 - there is no decision about the DS-Lite integration
  (i.e., plain mode vs encapsulation mode).

Detailed comments about the text (in the text order):

 - 3 page 7 "Mapping Types":
      For example, a PCP MAP request to create a
      mapping that already exists as a static mapping will return a
      successful result, confirming that the requested mapping exists.

=> this is both underspecified and misleading:
 * MAP is about explicit dynamic mappings so it should not deal with
  a static mapping as it is an explicit dynamic mapping. BTW this is
  IMHO a direct consequence of the underspecification.
 * I suggest to add a reference to the MAP request processing section
  and to add in this section:
  - what means "already exists": IMHO this means same protocol,
   internal address and port (other cases can be solved)
  - a colliding static mapping must not be downgraded to an explicit
   dynamic mapping (BTW the document already follows this for deletion)
   so it is a special condition which must be signaled in a standard way
   (a new error code or a response with an infinite (i.e., (unsigned) -1)
    lifetime, etc, anyway something standard and easy to recognize by
    the client)
BTW the similar collision case with an already existing implicit dynamic
mapping is still unresolved and currently there is no reasonable error
code for NAT implementations which don't support upgrading of
an implicit dynamic mapping to an explicit dynamic one.

 - 5.1 page 10: the "PCP Client's IP Address" is not very clear
  (it led to different interpretations so there is a real issue here).
  In particular:
   * what to put in DS-Lite plain mode: is it the IPv4 address of the
    initial client or the IPv6 address of the B4?
   * what to do for tunneled requests: is the reference IP header
    external or most internal one?
   * what to do with multiple proxies?
  Note this is about a strict or not intepretation of the "Client" term
  and the third party option, and some well chosen examples should be
  enough for clarification.

 - 5.3 page 13: I am not convinced the choice for the option length
  unit (currently 32 bits) is the right one: if the option length
  unit is changed to octets:
   * padding will be easier to recognize, for instance an option
    will be able to carry directly an octect string
   * at the opposite the maximum option data size will become 256 octets
    (but is it really a disavantage? :-)

 - 5.4 page 15: we need a generic 'after parsing' processing error code!

 - 6.1 page 16: perhaps it should be useful to suggest to jitter
  retransmission timeouts?

 - 6.2 page 17: the minimum length of 4 for requests is not compatible
  with NAT-PMP which uses 2 octet requests... In general PCP and NAT-PMP
  are not compatible even they share the same port: I strongly suggest
  to either revisit the whole document to fix this or to come back
  to different ports.

 - 6.2 page 17: check against version 0 aka legacy NAT-PMP should be
  done as soon as possible.

 - 6.6 pages 19 and 20: not compatible with legacy NAT-PMP...

 - 8.1 page 31: Assigned External IP Address:
      On error responses, the
      value from Suggested External IP Address is used.
  I strongly disagree with this idea: it makes error responses useless
 for anything else than epoch and error report without any benefit:
 the corresponding request can be matched with the external port in
 all cases, including multiple requests with the prefer failure option
 on the same client socket.
 I suggest to copy only the external port and to put in the external
 address field the real value if it is available, or zero if not
 available.

 - 8.5 page 35: in:
     On an error
   response, the assigned external address and assigned external port
   can also be used to match the responses (which is useful if several
   requests with the PREFER_FAILURE Option are outstanding).
  Please remove 'the assigned external address and' as the other
  fields are enough.

 - 8.6 page 36: please remove this useless case:
   o  If the internal port is non-zero (port!=0) and the protocol is
      zero (protocol==0), it indicates a request to delete all mappings
      for this Internal Address for the given port for all transport
      protocols.

 - 8.6 page 36: please delete this:
    If the PCP client attempts to delete an implicit dynamic
   mapping, the PCP server deletes the mapping and filtering and
   responds with the SUCCESS result code.

  The idea is MAP is about explicit dynamic mappings *only* so
  should not delete static mappings (as the document specifies
  correctly) nor implicit dynamic mappings.
  Now if we want a way to delete implicit dynamic mappings IMHO
  it is far better to promote the PEER with lifetime=0 to this role.

 - 9 page 38:
    PEER4=3:   Create an explicit dynamic mapping, or set or query an
               implicit dynamic mapping to a remote peer's IPv4 address
               and port.
  same for PEER6:
  the PEER requests can't *at the same time* provide the 3 create, set
  and query features. Depending on the server implementation they
  provides either create and set, or create and query. So this introduction
  is misleading and BTW from a client perspective the PEER stuff is
  pretty hard to use without a priori knowledge of the server behavior
  (but please don't change the server behavior :-).

 - 9.1 page 39:
      Note that, depending on the implementation
      of the PCP-controlled device, it may not be possible to reduce the
      lifetime of a mapping (or delete it, with requested lifetime=0)
      using PEER.
  This illustrates my previous point: if the PCP server can reduce the
  lifetime of a mapping it is not possible for the client to query it
  (query == without side effect).
  About the deletion IMHO this should be provided by all implementations
  (this is not a change in the behavior as it was specified for MAP).

 - 9.1 page 42: External Port:
  Please add Assigned and in general copy the text from the MAP response

 - 9.1 page 42: External IP Address:
  Please add Assigned and in general copy the text from the MAP response
  *with* the fix I required for the error case (i.e., don't copy
  the suggested one).

 - 10: this section is supposed to include options shared by MAP and PEER
  but it is only the case for the THIRD PARTY one: PREFER FAILURE and
  FILTER are MAP only...

 - 13 page 52: unsound wording:
   When PEER is used to create, query or extend an
   existing mapping
 ('create' is incompatible with 'existing')

 - 13.2 page 53: the section 12.1 page 52 shares the same title!

 - 13.3 page 54: in
   Since the
   B4 device is itself the DS-Lite IPv6 tunnel endpoint, it is in a
   position to guard against spoof packets being injected into that
   tunnel using the B4 device's IPv4 source address, so the DS-Lite PCP
   server can trust that packets received over the DS-Lite IPv6 tunnel
   with the B4 device's source IPv4 address did in fact originate from
   the B4 device.
 This text implies the encapsulation mode, as far as I know the WG did no
 choice between the plain and the encapsulation modes...

 - 14.3 page 55 (Result Codes):
   The values 0 and 255 are reserved.
=> in fact the value 0 (SUCCESS) is *not* reserved?

Regards

---

From: Paul Selkirk <[email-masked]>
Date: Tue, 12 Jul 2011 18:41:08 +0000

This draft does not address several key points that I brought up during
the previous last call:

1. In section 6.6.  Version Negotiation

   When sending a response containing the UNSUPP_VERSION result code,
   the PCP message MUST be 12 octets long.

i.e. It does not include the PCP Client's IP Address or Opcode section -
Is this really what you meant, or was this not updated when PCP Client's
IP Address was added?

I think this restriction is a mistake, and the response should follow
normal guidelines, e.g. copy the whole request into the response.
This restriction was added in -08 with no explanation in the change log.

2. Since PEER can create mappings, it should be brought more in line
with MAP.  (This is the flip side of #54 - since the consensus seems to
be to keep it, let's take it to its logical conclusion.)

2a. If PEER can create mappings, it can delete them.  Currently PEER
with lifetime=0 is undefined, or implementation-specific.  Currently you
could use MAP with lifetime=0 to delete a PEER-created implicit mapping.

2b. PEER should support the PREFER_FAILURE Option, for the scenario of
restoring lost implicit mappings.  If I'm trying to restore a mapping
for an established TCP connection, and I can't get the same external
port, then the connection is broken, and I don't want a different port.

2c. Most of the error conditions that apply to MAP also apply to PEER.
I added general language to that effect, but specific errors are
mentioned in the MAP section, that should be ported to the PEER
section, e.g. USER_EX_QUOTA.

3. UNAUTH_THIRD_PARTY_INTERNAL_ADDRESS should be removed, and replaced
with NOT_AUTHORIZED.  In fact, section 8.4 says
   If the
   internal IP address in the PCP request is not authorized to make
   mappings on behalf of the indicated internal IP address, an error
   response MUST be generated with result code NOT_AUTHORIZED.

4. In section 14.3 (IANA Result Code registry), we need to set aside a
private range for result codes, to support private OpCodes and Options.

				paul

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 13 Jul 2011 11:19:26 -0400

Comments/General questions on -13 for WGLC:

1 - Is PEER+EIF = MAP? Assuming Remote peer IP is zero?

2 - Although PEER can be EIM/EIF/EDM/etc there is nothing in the message
that allows the PCP Client to specify which type of mapping it wants.

In the case the NAT supports all mapping types, certainly the PCP Client is
the one that knows best which type of mapping and security it needs.

"  Note that mappings created or managed using PCP PEER requests may be
   Endpoint Independent Mappings or Endpoint Dependent Mappings, with
   Endpoint Independent Filtering or Endpoint Dependent Filtering,
   consistent with the existing behavior of the NAT gateway or firewall
   in question for implicit mappings it creates automatically as a
   result of observing outgoing traffic from Internal Hosts."

Thanks,

Reinaldo

On 7/6/11 5:33 AM, "Alain Durand" <[email-masked]> wrote:

> draft-ietf-pcp-base-13 has been published to address the comments received
> during wg last call on the -12 revision. We would like to start a 1-week
> working group last call on this new revision.
>