Subject: [pcp] notes from yesterday meeting

From: Francis Dupont <[email-masked]>
Date: Wed, 27 Jul 2011 16:41:56 +0200

I follow the history so mainly the base I-D 13 (changes) slides at
http://www.ietf.org/proceedings/81/slides/pcp-1.pdf

 * report public address:

  - I asked the external address to be provided in all responses when
   available, after some discuss the proposal ended by:
   * if one external address is available then it is copied to the response
    (at SHOULD level), either the external address field is set to zero
    (at MAY level).
    Note: the "one" is important for the case where the external
    address is from a pool without a stable choice, i.e., no state for
    this client.
    Note: this should replace the current wording for MAP and PEER,
    only the external port is copied from the request

  - there is still no standardized way to get the external address
   for IWFs but if we agreed it won't be in the base spec it is an
   item to solve so proposals are wellcome.
   Note: I am ready to accept any proposal but please don't leave
   this point without a standardized solution: for me it is a blocking
   point!

 * exclusive use of port

  - the MAP is subset of mapping is only a wish: it is plain
   wrong in most of current NAT implementations.

  - this is a nice thing but the PCP client stub has no way to check
   if it was properly enforced and anyway this only makes the
   corrresponding error case at the server side for implementations
   which can't promote implicit dynamic mappings to explicit less
   likely, i.e., the error case remains so an error code is needed
    (including PROCESSING_ERROR from I-D 12)

 * PREFER_FAILURE in PEER

  - the error needs to be specified, i.e., the specs should not say
   "raise an error" but say "raise an error with code XXX"

  - this has a consequence which was not noticed Yesterday: the creation
   of an implicit dynamic mapping by PEER is the same than by a TCP SYN
   IN PARTICULAR for the security aspects so a port randomization
   implementation should always return an error. Note this is consistent
   with the intended use of the feature so it is not really an issue.
   Note: I am ready to explain the reasoning behind this conclusion.

 * clarify: implicit/explicit/static

  - the first change, no reduction by PEER, is wellcome

  - there was a discuss about implicit deletes, so current proposal is:
   * if we decide to provide implicit dynamic mapping deletion, it will be
    by a PEER with lifetime zero
   * at this time we don't know a use case for this feature

  - about static mappings I proposed for matching MAP requests with any
   lifetime (i.e., including delete) to return the static mapping in
   the response (so fill external address and port) with the C99
   UINT32_MAX value as the lifetime. Clients should be prepared to
   receive such responses.
   Note: this enforces the "read only" on static mappings

Extra base items not in slides:

  - Margaret presented her proposal for security considerations.
   Note: I am not convinced the EIM/EIF vs what the implementation
   provides (which is at 70% not EIM/EIF :-) is properly handled,
   BTW IMHO this has no real impact on the final security, this is
   more about the arguments.
   Note: at the opposite I am still convinced the security issues
   specific to CGNs are dramatically underestimated. In the current
   situation I believe we should advise to use static mappings for
   any service where the security matters, PCP could be reduce to
   the read (only) of these mappings, i.e., surely not we want.

  - I asked for an example of the client source address as the strict
   interpretation of the term "client" was not so clear.
   Note: it should be fine to have this example for DS-Lite plain mode.

  - I asked to get back the PROCESSING_ERROR with the draft 12 definition
   so if an error occurs during the request processing (i.e., after parsing)
   the server can return something.
   Note: Stuart dislikes this because it can make a syntacticly correct
   request to fail, unfortunately removing an error code doesn't remove
   the error case...

  - Paul Selkirk requested a clarification about the two "not authorized"
   error code

DHCP: agreement to put the Fully Qualified Domain Name of the PCP server
as a host name from RFC 1123 2.1 in an ASCII string option.
Note: no DNS name DHCP format, nor Unicode/UTF8/etc
Note: host names are in a subset of ASCII but IMHO it is not intented
to enforce these restrictions ("_" for instance is illegal in host names :-)

DS-Lite: still no choice between plain and encapulation modes, a document
should be written...
Note: I am still in favor of plain mode:
 - on the server side encapsulation mode requires a PCP ALG
  (Paul wrote one for our AFTR so I can confirm it is a requirement :-)
 - on the B4 side the encapsulation mode is not really simple: if
  local policy has to be enforced there should be enforced locally,
  i.e., by a PCP-proxy so PCP requests won't be freely encapsulated
For the second argument I have no strong idea whether the common user
wants local policy or not. I know I want but I am not a common user,
and most software performing this kind of function provide the local
policy feature...

UPnP IWF: I presented slides written by Mohammed Boucadair at the last
meeting (i.e., end of March) slightly updated by Xiaohong Deng.
Of course the last time I read them was 4 months ago, and BTW
the slides are not in the materials (Chairs?)...

It seems the main point where I disagree with many people is the
level of reliability (bound to security for me) the IWF should
provide to UPnP IGD (version 2 because version 1 is definitely
broken and is being replaced by version 2 since it was published
last year).
UPnP IGD 2 was designed to handle essentially Home Gateways with
the UPnP server co-located with the NAT (i.e., both run on a 50 USD
box with a 2 year lifetime, no reliable stable memory, at most
some days between reboots, etc).
To use an IWF for UPnP IGD to control a CGN makes things very different:
 - no longer likely fate sharing so you can get unsynchronized states
  between the IWF and the PCP server
 - addresses and ports are shared between subscribers at the CGN so
  the existence of stale mappings really matters
 - no, to delete all mappings and reinstall them is as reasonable as
  using a tree to stop your car
 - the fact a CGN has many subscribers (by the CGN definition) raises
  the mapping theft issue so the details become critical for a secure
  use of explicit dynamic mappings:
  * the hold down phase after explicit mappings expiry/deletion (i.e.,
   there should be a MUST for this phase and a MUST for previous holder
   and only the previous holder reuse)
  * explicit dynamic mappings (and of course static mappings) MUST be
   saved into a stable storage, BTW including during the hold down phase.
I agree this should make UPnP IGD more reliable than it was designed
or what its specs required but the other solution is to wait for the
PCP deployment on clients before putting the first CGN in production...

Regards

[email-masked]