Re: [pcp] Review of draft-ietf-pcp-upnp-igd-interworking

[<[e-mail]>]

Hi Reddy,

Thanks for the review.

Please see inline.

Cheers,
Med

________________________________
De : Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
Envoyé : mercredi 12 septembre 2012 16:07
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : [e-mail]
Objet : Review of draft-ietf-pcp-upnp-igd-interworking

Hi Med -

[1] Section 5.8
   If the port is not in use, the mapping will be
   created by the PCP Server and a positive response will be sent back
   to the IGD-PCP IWF.  Once received by the IGD-PCP IWF, it MUST relay
   a negative message to the UPnP Control Point indicating
   NoSuchEntryInArray as error code.

Comment> Should the IGD-PCP IWF delete the MAP binding after this operation ?
[Med] No. the IGD CP is supposed to issue AddPortMapping() for that specific mapping. The request will be honored by the PCP server (after being relayed by the IWF). The behaviour of the IGD CP is out of scope. There is a note about this in the draft:

      Note: According to some experiments, some UPnP 1.0
      implementations, e.g., uTorrent, simply try the same external port
      X times (usually 4 times) and then fail.  Also note that some
      applications uses GetSpecificPortMapping() to check whether a
      mapping exists.

Do you think the note need be updated?

[2] Section 5.9
  A PCP MAP delete response is sent back if the removal of the corresponding
  entry was successful; if not, a PCP Error is sent back to the IGD-PCP
  Interworking Function including the corresponding error cause (See
  Section 4.3).

comment > you may want to conclude that the corresponding success/error codes will be returned to the UPnP Control Point.
[Med]  The behaviour of the iwf is already captured in "and notifies the UPnP Control Point about the result of the
   removal operation.".

[3]Section 5.9

      It is unlikely to encounter a problem in the PCP leg
      because the IWF has verified authorization rights and also the
      presence of the mapping in the local table.

Comment> Just a corner case, What if the PCP server crashes or loses its state after only processing the first request ?
[Med] In that case, the server will return SUCCESS as the mapping does not exist.

[4]Section 5.10

   In case an error is encountered during mapping renewal, the IGD-PCP
   Interworking Function has no means to inform the UPnP CP.

Comment > why not set PortMappingLeaseDuration to the lifetime value returned by the PCP server ?
[Med] this variable state must have the same value as the one included in addportmapping() action issued by the CP.

[5] For Security considerations - If the UPnP supports PCP interworking function then it should block internal hosts from sending PCP requests to the PCP server directly.
[Med] Do you mean the UPnP CP?

Generic error cases :

[6] What if NAT2 just supports or permits PEER and not MAP request ?
[Med] the IWF will fail to open mappings. I can add a sentence like "This specification assumes the PCP Server is configured to accept MAP OpCode". Do we need to say more?

[7] what will IGD-PCP do if it receives ANNOUNCE from NAT2 ?
[Med]  The question can be extended to other failure cases. We have some texts spread in several I-Ds:
http://tools.ietf.org/html/draft-boucadair-pcp-failure-04#section-2.6
or adapt the text from http://tools.ietf.org/html/draft-boucadair-pcp-failure-04#section-2.7.6.2<http://tools.ietf.org/html/draft-ietf-pcp-proxy-01#section-9>

We have two options:
(1) mention ANNOUNCE handling is out of scope and cover this in detail in the failure draft
(2) add a section to specify the behaviour in the draft.

Which option do you prefer?


--Tiru.