Subject: [pcp] base 16 review (2)

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Oct 2011 14:44:04 +0200

Second part of my editorial (*) review comments,
up to 11.3 / page 56.
(*) I have two concerns I am discussing internally which are clearly
not editorial at all.

(from 7.3 page 21 excluded)

 - 7.5 page 22: please choose between '1' and 'one', as I prefer
  the work this gives:

   by 1 every second -> by one every second

 - 7.5 page 23: I liked the one hour max drift rule, using the
  same style it gives an additional member of the if 'or':
  or 3600 < abs(server_delta - client_delta)

 - 7.6 page 24: perhaps from an older edit?

  these first two octets -> this first octet

 - 8 page 27: the paragraph:

   Note that PCP requests containing the MAP or PEER Opcodes cannot
   delete or shorten the lifetime of an existing implicit mapping for
   the indicated internal address and port.  Conceptually implicit and
   explicit mappings are different "layers" in the NAT forwarding state
   database.

  is in contradiction with the implementation-dependent text in
  the PEER opcode description. Note IMHO that text is wrong so I cite
  this paragraph only for the case the WG decision will be reversed.

 - 9 page 35: I suggest to move the text about ICMP from 9.5 to here:

   their MAP request, to ensure that no other clients on the same
   machine are also listening on the same Internal Port.
 
 moved text

   As a side-effect of creating a mapping, ICMP messages associated with
   the mapping MUST be forwarded (and also translated, if appropriate)
   for the duration of the mapping's lifetime.  This is done to ensure
   that ICMP messages can still be used by hosts, without application
   programmers or PCP client implementations needing to signal PCP
   separately to create ICMP mappings for those flows.

 resuming

   The operation of the MAP Opcode is described in this section.

 - 9.3 page 38: in fact

   ... If
   the requested Lifetime is non-zero, the Internal Port is zero, and
   the Protocol is non-zero, it indicates a request to map all incoming
   traffic for that entire Protocol.

  is valid only for protocols which don't use 16-bit port numbers.
  I don't know if it is a problem, i.e., if the text should be changed.
  IMHO the 9.1 definition of the internal port is clear enough.

 - 9.3 page 39: I suggest to swap the two paragraphs, i.e.:

   If the PCP-controlled device is stateless (that is, it does not
   establish any per-flow state, and simply rewrites the address and/or
   port in a purely algorithmic fashion), the PCP server simply returns
   an answer indicating the external IP address and port yielded by this
   stateless algorithmic translation.  This allows the PCP client to
   learn its external IP address and port as seen by remote peers.
   Examples of stateless translators include stateless NAT64, 1:1 NAT44,
   and NPTv6 [RFC6296], all of which modify addresses but not port
   numbers.

   If an Option with value less than 128 exists (i.e., mandatory to
   process) but that Option does not make sense (e.g., the
   PREFER_FAILURE Option is included in a request with lifetime=0), the
   request is invalid and generates a MALFORMED_OPTION error.

 ->

   If an Option with value less than 128 exists (i.e., mandatory to
   process) but that Option does not make sense (e.g., the
   PREFER_FAILURE Option is included in a request with lifetime=0), the
   request is invalid and generates a MALFORMED_OPTION error.

   If the PCP-controlled device is stateless (that is, it does not
   establish any per-flow state, and simply rewrites the address and/or
   port in a purely algorithmic fashion), the PCP server simply returns
   an answer indicating the external IP address and port yielded by this
   stateless algorithmic translation.  This allows the PCP client to
   learn its external IP address and port as seen by remote peers.
   Examples of stateless translators include stateless NAT64, 1:1 NAT44,
   and NPTv6 [RFC6296], all of which modify addresses but not port
   numbers.

 - 9.3 page 40: I still don't like the last paragraph, I propose:

   If all of the preceding operations were successful (did not generate
   an error response), then the requested mapping is created or
   refreshed as described in the request and a SUCCESS response is
   built.  This SUCCESS response contains the same Opcode as the
   request, but with the "R" bit set.

 ->

   If all of the preceding operations were successful (did not generate
   an error response), then the requested mapping is created or
   refreshed as described in the request and a SUCCESS response is
   built.  All responses, including this SUCCESS response contains
   the same Opcode as the request, but with the "R" bit set.

 - 9.4 page 41: I have a problem with this MUST:

   The PCP client MUST also set a timer or otherwise schedule an event
   to renew the mapping before its lifetime expires.

  due to the (poor) wording this can be read as infinite renewal is
  mandatory. Of course the issue is not in the requirement level,
  I strongly suggest to add a condition like:
 
   When renewal is desired, the PCP client MUST also...

 - 9.5 page 42: the all subscriber mapping delete is not in the list
  (but is in 11.1 page 51 about THIRD_PARTY). IMHO we should add
  a reference to it at the end of:

   o  If both the internal port and protocol are zero, it indicates a
      request to delete all mappings for this Internal Address for all
      transport protocols.  This is useful when a host reboots or joins
      a new network, to clear out prior stale state from the NAT gateway
      before beginning to install new mappings.

  BTW this could fix the missing fact the all subscriber mapping
  requires zero internal port and protocol.

 - 9.5 page 43: as written before about 9, this text has a better place:

   As a side-effect of creating a mapping, ICMP messages associated with
   the mapping MUST be forwarded (and also translated, if appropriate)
   for the duration of the mapping's lifetime.  This is done to ensure
   that ICMP messages can still be used by hosts, without application
   programmers or PCP client implementations needing to signal PCP
   separately to create ICMP mappings for those flows.

 - 9.7 page 44: I have still a concern about:

   Address for cosmetic purposes can achieve that by requesting a short-
   lived mapping and then displaying the resulting External IP Address.
   However, once that mapping expires a subsequent implicit or explicit
   dynamic mapping might be mapped to a different external IP address.

  as it is both pejorative and useless. I strongly suggest to remove it
  (and to keep the rest of 9.7).

 - 10 page 44: I can't see why the v4 is here and BTW it contradicts
  the NAT64 Figure 6 entry where the remote peer is IPv6, so I strongly
  suggest:

   a remote peer's IPv4 -> a remote peer's IP

 - 10 page 44: from the PEER4 and PEER6 time:

   The use of these Opcodes -> The use of this Opcode

 - 10.1 page 45 (Requested Lifetime): I note this as I have a concern
  I am discussing.

 - 10.1 page 46 (twice): the word 'preference' in the two Suggested
  and even the word 'Suggested' itself don't match the implicit
  PREFER_FAILURE semantic.

 - 10.1 page 46 (Remote Peer IP Address): add or replace the trailing

      ... and an IPv4 address is
      represented using the IPv4-mapped address syntax (80 bits of
      zeros, 16 bits of ones, and 32 bits of the IPv4 address).
 
   by a reference to Section 5?

 - 10.2 page 48: IMHO the 'If sent before' and 'If sent after'
  paragraphs should not get a particular indent.

 - 10.2 page 48: please change

  ... will respond with a PCP error.

 ->

  ... will respond with a CANNOT_PROVIDE_EXTERNAL_PORT error.

 - 10.3 page 49: again I note this as I have a concern about it
  I am discussing.

   The PEER Opcode MAY reduce the lifetime of an existing implicit
   dynamic mapping created by PEER; this is implementation-dependent.

  same for:

   Some transport protocols signal the end of a connection (e.g., TCP
   FIN, TCP RST, SCTP SHUTDOWN).  After a successful PEER response is
   sent, the receipt of such a transport-specific message MUST NOT cause
   the mapping to be destroyed.  Rather, the mapping is maintained until
   the PEER-signaled lifetime expires.  If the PCP client wishes to
   terminate the mapping prior to this, it will send a PEER request with
   Lifetime set to 0, which MAY be honored by the PCP server; as stated
   earlier, that is implementation-dependent.

  which BTW says the opposite of the previous paragraph.

 - 10.4 page 50: I suggest:

   inside->outside -> from inside to outside

 - 11.1 page 51: I suggest to consolidate this with 9.5:

      ... If the
      Option Length is zero, there is no Internal IP address for this
      mapping and this indicates "all Internal IPv4 and IPv6 Addresses
      for which this client is authorized" which is used to delete all
      pre-existing mappings with the MAP Opcode.

  and page 52:

   A PCP client can delete all PCP-created explicit dynamic mappings
   (i.e., those created by PCP MAP requests) that it is authorized to
   delete by sending a PCP MAP request including a zero-length
   THIRD_PARTY Option.

  BTW I suggest to add the internal port and protocol MUST be zero
  in this case.

 - 11.2 page 53: at one exception, the text is still about
  an 'external port only' (vs. 'external address and port') version
  of the PREFER_FAILURE option: it clearly needs to be updated!

 - 11.2 pages 53 and 54: again I note this as I have a concern
  I am discussing:

   This Option exists solely for use by UPnP IGD interworking
   ...
   adopt PCP natively and the need for UPnP IGD interworking declines.

 - 11.3 page 54 (remark only): some implementations also filter out
  incoming (i.e., received on the not public-facing interface) packets
  as it doesn't make sense to drop only the traffic one way.
  (BTW the text is correct as the from the Internet way is
   the critical one for the filtering).

 - 11.3 page 55: this text could be improved to take into account
  a possible error response with an UNPROCESSED added option:

      Maximum occurrences: as many as fit within maximum PCP message
      size

 - 11.3 page 55: I have another MALFORMED_OPTION case where the
  address has one bit after its prefix length, i.e., something
  like 192.168.0.0/8. IMHO these cases don't have to be exhaustive
  so it is not a request to add such a thing.

Regards

[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 27 Oct 2011 17:03:16 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francis Dupont
> Sent: Wednesday, October 26, 2011 5:44 AM
> To: [email-masked]
> Subject: [pcp] base 16 review (2)
> 

Fixed.

>   or 3600 < abs(server_delta - client_delta)

I don't understand.

>   these first two octets -> this first octet

fixed.

>   this paragraph only for the case the WG decision will be reversed.

Let's bring this up in a separate thread, solely about this issue.

>    The operation of the MAP Opcode is described in this section.

Moved.

>   IMHO the 9.1 definition of the internal port is clear enough.

Will leave as-is.

>    and NPTv6 [RFC6296], all of which modify addresses but not port

Swapped.

>    the same Opcode as the request, but with the "R" bit set.

I see what you're getting at.  Such text really belongs in the
general PCP processing section, as we want this to apply to 
any and all PCP messages (not just MAP messages).  So, I added:

        All responses (both error and success) contain the same OpCode
        as the request, but with the "R" bit set.</t>

to the bottom of the general PCP processing section (7.2), and 
removed the discussion of the "R" bit from the MAP-specific 
section (9.3).

>    When renewal is desired, the PCP client MUST also...

Adjusted.

>   requires zero internal port and protocol.

But we don't want a host to remove mappings for another host, unless
THIRD_PARTY is used.  Maybe I don't understand what you're proposing.
Please bring this up in its own thread.

>    separately to create ICMP mappings for those flows.

Yes, it was moved.

>   (and to keep the rest of 9.7).

Noted.  But this question comes up often, and it seems useful and necessary 
to have in the document.  Will keep it as-is.

>    a remote peer's IPv4 -> a remote peer's IP

Fixed.

>    The use of these Opcodes -> The use of this Opcode

Fixed.

>   and even the word 'Suggested' itself don't match the implicit

I don't understand what change you're wanting to the document.

>    by a reference to Section 5?

Done.

>   ... will respond with a CANNOT_PROVIDE_EXTERNAL_PORT error.

Done.

>   which BTW says the opposite of the previous paragraph.

Let's discuss in a separate thread.

>    inside->outside -> from inside to outside

Fixed.

>   BTW I suggest to add the internal port and protocol MUST be zero

Done.

>   of the PREFER_FAILURE option: it clearly needs to be updated!

Done.

>    adopt PCP natively and the need for UPnP IGD interworking declines.

Noted.

>       Maximum occurrences: as many as fit within maximum PCP message

There is already sufficient admonishment in the general PCP 
section about message length.

>   so it is not a request to add such a thing.

-d

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

---

From: Francis Dupont <[email-masked]>
Date: Fri, 28 Oct 2011 16:36:00 +0200

I don't understand.
   
=> I'd like to translate this taken from base 15:

   ... or is more than 3660 seconds
   (one hour) above or below the expected Epoch value, the PCP client
   concludes that the PCP server lost state.

fixed and translated to base 16 terms it means the difference
between the two delta's must be less than 3600 seconds / one hour
or the epoch is invalid.
BTW if you don't want the abs() from the math library it can be
written with unsigned delta as:

   or client_delta+3600 < server_delta
   or server_delta+3600 < client_delta

so the last item (*) of the list gives for invalid epoch:

         +  If client_delta+2 < server_delta - server_delta/8
            or server_delta+2 < client_delta - client_delta/8
            then the client treats the Epoch time value as invalid,
            else the client treats the Epoch time value as valid

  ->

         +  If client_delta+2 < server_delta - server_delta/8
            or server_delta+2 < client_delta - client_delta/8
            or client_delta+3600 < server_delta
            or server_delta+3600 < client_delta
            then the client treats the Epoch time value as invalid,
            else the client treats the Epoch time value as valid

(*) there are in fact two other cases written in text:
server_delta must be positive and client_delta is positive by
construction, but I agree to keep them in text as it makes
the pseudo code still valid with unsigned delta's.
To summary I propose (only) this change.
   
Regards

---

From: Francis Dupont <[email-masked]>
Date: Fri, 28 Oct 2011 16:38:51 +0200

=> agreed: we have an issue about PEER semantics we should discuss
by itself (and it is one of the two items I am discussing internally
as I explained in the 3rd part of my review).
   
Regards

---

From: Francis Dupont <[email-masked]>
Date: Fri, 28 Oct 2011 16:59:46 +0200

=> it is misunderstandarding: my comment is the all subscriber mapping
delete (named all client mapping delete) should be referenced here,
and of course it requires a specific (i.e., "empty") THIRD_PARTY option.
   
   >   (and to keep the rest of 9.7).
   
   Noted.  But this question comes up often,

=> it comes often for *not cosmetic* purposes!

   and it seems useful and necessary to have in the document.  Will
   keep it as-is.
   
=> we have 3 choices:
 -1- think that the text in 9.7 up to but not including the "cosmetic" stuff
  is enough to implement the function (get external address) for not
  cosmetic purpose
 -2- the current text
 -3- standardize a way to provide the function for not cosmetic purpose
IMHO -1- or -3- are fine, -1- is easier as it supposes it will be done
in the documents requiring a not cosmetic purpose, this is why I support -1-.
-2- is bad because it implicitly assumes all purposes are cosmetic,
so it doesn't solve any real problems, it just makes people unhappy.

   
=> the PEER Suggested external address and Suggested external port
are in fact Requested external address and Requested external port
as the PEER request will fail if they can't be fulfilled.
And they are requested values, not preferences: the text was copied
from MAP but IMHO the wording is no longer appropriate.
(now it is only a wording problem).

   
=> I note to add this case in my test suite (MAP request with FILTER
options, including a bad one, and an padding option up to 1020 octets).
As I am looking for interesting cases to add (:-)...

Regards

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 28 Oct 2011 14:08:24 -0700

>   (and to keep the rest of 9.7).

No, it's accurate and informative.

After years of NAT-PMP experience, we have found *no* non-cosmetic  
purpose for getting the external IP address without a mapping to go  
with it.

People have frequently made the mistake of thinking it's useful;  
hence we have this text to point out that it is not.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 28 Oct 2011 14:12:13 -0700

> between the two delta's must be less than 3600 seconds / one hour

There is no basis for this arbitrary 3600-second value.

All thresholds need to be expressed as a function of the time since  
the last packet from the server and the acceptable clock drift rates.  
Any fixed constant cannot meet that requirement.

(And indeed, if the inter-packet interval is less than 8 hours, the  
test is *already* stricter than your fixed 3600 seconds, so *also*  
checking for 3600 seconds is a pointless waste of CPU cycles.)

---

From: Francis Dupont <[email-masked]>
Date: Sat, 29 Oct 2011 01:58:28 +0200

=> hum, it seems the only thing we could agree about is we disagree.
There is a procedure to resolve this kind of things, just apply it?

=> I found a non-cosmetic purpose with UPnP IGD IWF and even with
NAT-PMP IWF when the NAT-PMP client is not a code provided by Apple.

=> you have your opinion, I have mine: they are different.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 29 Oct 2011 02:12:28 +0200

=> for the value itself I agree, and I leave this point to the
person who added it in base 14.

=> I disagree: a fixed threshold can catch insane cummulate drifts,
or clock jumps.

=> I consider you forgot the smiley here...

Regards

PS: SEND (RFC 3971) has a delta, a drift and a fuzz. Even if SEND
is a bit different (security device using absolute clocks) there is
no reason to not look at it. This is why I was happy to get the
fixed threshold and less happy to lose it...

---

From: james woodyatt <[email-masked]>
Date: Fri, 28 Oct 2011 17:45:32 -0700

> NAT-PMP IWF when the NAT-PMP client is not a code provided by Apple.

I'm sure there is a truly marvelous demonstration of that proposition, which the margins of a standard Internet message are, alas and alack, too narrow to contain.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Francis Dupont <[email-masked]>
Date: Sat, 29 Oct 2011 18:05:59 +0200

> NAT-PMP IWF when the NAT-PMP client is not a code provided by Apple.
   
  I'm sure there is a truly marvelous demonstration of that
  proposition, which the margins of a standard Internet message are,
  alas and alack, too narrow to contain.
   
=> I believe you want a proof of the second (about NAT-PMP), so I can
put the URL in this message:

http://miniupnp.free.fr/files/download.php?file=libnatpmp-20110808.tar.gz

Regards

PS: the details for interested people:

the sample client (and all the applications using this NAT-PMP client
library, for instance the transmission Torrent client) loops sending
public address requests and gives up after a reasonnable amount of
retries:

$ ./natpmpc-static 
initnatpmp() returned 0 (SUCCESS)
using gateway : 192.168.0.254
sendpublicaddressrequest returned 2 (SUCCESS)
readnatpmpresponseorretry returned -100 (TRY AGAIN)
readnatpmpresponseorretry returned -100 (TRY AGAIN)
readnatpmpresponseorretry returned -100 (TRY AGAIN)
readnatpmpresponseorretry returned -100 (TRY AGAIN)
readnatpmpresponseorretry returned -100 (TRY AGAIN)
readnatpmpresponseorretry returned -100 (TRY AGAIN)
readnatpmpresponseorretry returned -100 (TRY AGAIN)
readnatpmpresponseorretry returned -100 (TRY AGAIN)
readnatpmpresponseorretry returned -7 (FAILED)
readnatpmpresponseorretry() failed : the gateway does not support nat-pmp
  errno=11 'Resource temporarily unavailable'

And the tshark (wireshark output doesn't fit in this text message):

# tshark udp port 5351
no register file /usr/local/lib/wireshark/python/1.4.7/register-dissector.py
Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
  0.000000 192.168.0.40 -> 192.168.0.254 NAT-PMP External Address Request
  0.250394 192.168.0.40 -> 192.168.0.254 NAT-PMP External Address Request
  0.750576 192.168.0.40 -> 192.168.0.254 NAT-PMP External Address Request
  1.751072 192.168.0.40 -> 192.168.0.254 NAT-PMP External Address Request
  3.752074 192.168.0.40 -> 192.168.0.254 NAT-PMP External Address Request
  7.754071 192.168.0.40 -> 192.168.0.254 NAT-PMP External Address Request
 15.750151 192.168.0.40 -> 192.168.0.254 NAT-PMP External Address Request
 31.766072 192.168.0.40 -> 192.168.0.254 NAT-PMP External Address Request
 63.782091 192.168.0.40 -> 192.168.0.254 NAT-PMP External Address Request

---

From: Stuart Cheshire <[email-masked]>
Date: Sat, 29 Oct 2011 10:56:21 -0700

> NAT-PMP IWF when the NAT-PMP client is not a code provided by Apple.

Are you going to tell us, or is it a secret?

NAT-PMP has an opcode to request the external address.

The reason PCP does *not* have such an opcode is that it was agreed  
on the list to have no useful purpose.

While I've argued that PCP generally ought to be a superset of NAT- 
PMP, this is one area where I conceded that this aspect of NAT-PMP  
turned out to not be necessary.

I'm surprised to hear you, Francis, arguing for feature parity with  
NAT-PMP, when the NAT-PMP authors themselves accept that an opcode to  
request the external address was a mistake. (What does it even mean  
for a CGN with a large pool of external addresses?)

---

From: Stuart Cheshire <[email-masked]>
Date: Sat, 29 Oct 2011 11:16:02 -0700

> person who added it in base 14.

The text was added by Dan Wing, at Reinaldo's request, and  
subsequently refined to something a little more rigorous by me, at  
Dan Wing's request (since I was the designer of the NAT-PMP Epoch  
time mechanism).

> => I disagree: a fixed threshold can catch insane cummulate drifts,  

The definition of "insane" depends on (i) the time since the last  
packet from the server and (ii) the acceptable clock drift rates.

> => I consider you forgot the smiley here...

This is a technical discussion, not amateur comedy night. You of all  
people should know that language and cultural differences mean that  
attempted jokes are not productive.

If you have a point to make, please make it directly, instead of  
hinting at it and hoping other people will manage to guess what  
you're trying to say.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 29 Oct 2011 21:42:35 +0200

=> I sent to James and the list the details for NAT-PMP (even I
already explained it, but it seems repetition is required :-).

   
=> written yes, agreed I don't know: they are some sharing your opinion,
some sharing mine, and as usual the large majority who don't matter.

   NAT-PMP,

=> no, I don't want feature parity, I just want to make IWFs feasible.
Note here it is a matter of taste as it is enough for the IWF to
maintain a mapping.

   when the NAT-PMP authors themselves accept that an opcode to  
   request the external address was a mistake. (What does it even mean  
   for a CGN with a large pool of external addresses?)
   
=> this doesn't mean the external address should be arbitrary,
highly and per mapping. It seems than both we already had this
discussion and the current base spec required to use the same
address for all implicit and explicit dynamic mappings.
Now you can thinl it is too much or not enough.

Regards

PS: IMHO it was a bug mistake to not put the IWF in the charter as
it is required for the early deployment.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 29 Oct 2011 21:57:57 +0200

The text was added by Dan Wing, at Reinaldo's request

=> so I leave the defense of the 3600 value to Reinaldo:
I just support the idea to have a fixed threshold.

   
=> no, insane here refers to a fixed threshold so is not related to
(i) or (ii).

   > => I consider you forgot the smiley here...
   
   This is a technical discussion, not amateur comedy night.

=> I just tried to remain calm... but I still shan't reply to
your provocation.

Regards

PS: to make the point: I think a fixed threshold is a good idea,
I don't care about the value even the proposed 3600 value seems
right, and I consider to argue about the value until the principle
is adopted.