[pcp] comments about draft-wing-pcp-design-considerations-00.txt

[Francis Dupont <[e-mail]>]

(note: I already sent privately this to authors)

=> I have a concern about terminology: we have many involved entities,
terminals, servers, agents, etc. For instance the term client where
it is not defined can be very ambiguous.
BTW relay/proxy/IWF is an integral part of the protocol as for instance
B4s are required in the DS-Lite scenario.

2.1.  Add IPv6 Support

   Needs to support NAT44, NAPT44, stateless and stateful NAT64, NAT46,
   and IPv6 firewall.

=> forgot DS-Lite

2.2.  Open Pinhole for Another Host

   Provide ability for another device, within same home, to open ports
   on behalf of another.  This functionality also intended to be used by
   the operator of the NAT itself (e.g., the ISP) which is accessed by
   their technical support staff or is accessed by the end user.

=> I agree with the first sentence but not with the second: if PCP
can be used by the ISP it is fine but it must not be a goal, i.e.,
PCP must not be made more complex just for this.

   Use 0 as internal IP address to indicate 'this IP SRC address'.

=> I deeply disagree: this saves nothing and can introduce ambiguities.

2.3.  Interworking with UPnP IGD

   In UPnP IGD, a 'control point' can request a specific port or can
   request a wildcard port, and there is no concept of a mapping
   lifetime.  This model does not work well with NATs, especially large
   scale NATs.

=> it is in the charter so a minimal effort should be done (even IMHO
it won't work in the real world, i.e., UPnP IGD 1.0 is essentially
broken for this use...).

2.3.1.  Creating a mapping

   The Madatory bit, from draft-wing-softwire-port-control-protocol is
         ^ n
   not necessary, and will not be used in PCP.

=> no, please put again the mandatory bit.
(update: what I want is the function, not the bit itself, i.e., I am fine
with the idea to make not-zero requested values (external port and address)
'mandatory')

   The primary benefit
   of this bit is to ease interworking between UPnP IGD and PCP.

=> this is not true, the mandatory bit is very useful for the renew
operation too.
(update: for renew the requested external address is critical too)

   Thus, to interwork from UPnP IGD to PCP, our recommendation is that
   every UPnP request be forwarded to the PCP server.  This works if the
   UPnP control point is incrementing the source port number, and also
   works if the UPnP control point is randomly choosing the source port
   number, and also works if it chooses 'any'.  The UPnP IGD/PCP
   interworking function would request very short leases (e.g., 5
   seconds) in order to avoid the chatter of a DELETE message
   (lifetime=0).  Once a port can be allocated, its lifetime is
   extended.  When interworking with UPnP IGD, the in-home CPE limits
   itself to sending one PCP message a second, which ensures there are
   only 5 outstanding PCP reserverations at a time; this avoids
   consuming all of that subscriber's NAT mappings while trying to find
   an available port via the UPnP IGD->PCP interworking function).

=> simply ridiculous...

      Note: for this to work successfully, the PCP server (large NAT)
      make an attempt to honor the requested-external-port field in the
    ^ missing word here
      PCP request.

=> it is the purpose of this field, isn't it?

                  Message flow would be similar to this:

=> what is the internal port? 80, 81, ...?

2.3.2.  Lifetime Maintenance

   UPnP IGD does not provide a lifetime, so the UPnP IGD/PCP
   interworking function is responsible for extending the lifetime of
   mappings that are still interesting to the UPnP IGD device.  We
   recommend the UPnP IGD/PCP function request a port mapping lifetime
   equal to the client's remaining DHCP lifetime.

=> I agree with the principle (the IWF hides the finite lifetime by
renews) but not with the introduction of DHCP here. And BTW on home
networks DHCP is not used to manage a sparse resource, it is used only
for address management so a client should always get the same address
(some kind of implicit infinite renew), so this doesn't make sense too.

2.4.  Protocol support

   Only TCP and UDP will be supported.  Additional protocols can be
   defined later, using the protocol field.

=> please note an 'all protocols' is needed for delete.

2.5.  Delete all mappings for a host

   PCP will allow deleting all mappings for a host.  (This is already
   present in NAT-PMP.)

=> I agree but it is not in NAT-PMP which requires two requests.

2.6.  Delete all mappings for all hosts in a home

   PCP will allow deleting all mappings for all hosts behind an in-home
   CPE, such as DS-Lite's "B4" element.  This is to allow flushing PCP
   mappings when a subscriber is assigned an IP address belonging to a
   previous subscriber.

=> fine (so we have three levels of 'all': protocol, client, B4).

2.7.  No Reservation of Ports in other protocol

   When a port reservation is made, NAT-PMP currently reserves the same
   port in the other transport protocol for the same host.  That is, if
   a mapping is made for TCP/12345, the port UDP/12345 will be reserved
   for a future mapping.  This functionality will be removed from PCP.

=> I strongly agree!

   If a protocol requires the same mapping for UDP and TCP, it will need
   to issue separate requests (with short lifetimes) until it is
   assigned the same ports.

=> this doesn't work, just stay with the first paragraph only.
(update: it seems there is a consensus for the second part, i.e.,
keep only the first paragraph which stays the functionality should be
removed).

2.8.  Consolidate IP request and port request messages

   NAT-PMP currently uses a separate message to obtain the public IP
   address and to obtain the port.  In PCP, this will be consolidated
   into one message so that every port response includes the external
   address and lifetime.  Once a host has an active PCP-created mapping
   on one port, it will get the same external address for all subsequent
   port requests.

=> fine (this with the common request/response layout are real progresses
in the design).

2.9.  NAT Changing Public Mapping

   Currently, NAT-PMP has a feature where the NAT can alert hosts on the
   local LAN if the NAT's public address changed or the NAT rebooted.
   This functionality will not be available in the initial functionality
   of PCP, but can be provided in a future document.

=> fine (I agree there is no realistic/scalable way to do this).

2.10.  Epoch

   As in NAT-PMP, all NATs will implement epoch.  NATs which retain
   their state will simply increase the epoch.  This reduces
   implementation burden to deal with NATs-that-retain-state and NATs-
   which-lose-state, and also allows ISPs to renumber the public side of
   the NAT (and force epoch back to zero).

=> I'd *really* like to get a SHOULD for 'retain state'.

2.12.  Port number

   Re-use the same port as NAT-PMP (5351).

=> fine (I've found the way to chain a PCP dissector to the NAT-PMP one
in wireshark).

3.  Security Considerations

   TBD.

=> you mean MBD (Must Be Done). Some ideas:
there are two cases: the easy one (DS-Lite for instance) where the topology
control makes external attacks impossible (in DS-Lite this means ingress
filtering to prove the request/response flow can only be between B4 and AFTR).
And the hard one where any messages can be injected/replayed/etc, for this
I think something like DTLS could be a good solution (BTW don't invent
a new way to provide security inside the protocol).
(update: the DTLS idea is not intended for real world production, the goal
is only to cut the way to silly 'security improvements' to PCP :-)

5.1.  Normative References

   [I-D.cheshire-nat-pmp]
              Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",
              draft-cheshire-nat-pmp-03 (work in progress), April 2008.

=> note this is more than expired so a pointer to one of the many
places where it can be found should help.

Thanks

Francis Dupont <[e-mail]>