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

[<[e-mail]>]

Re-,

I updated the draft with the point agreed so far.

For the two remaining points:

* IWF to block internal host to send PCP requests directly to the PCP server: the IWF behave as a PCP client and not a PCP server. If the IWF is co-located with a PCP proxy, PCP requests from internal hosts will be relayed otherwise this will be silently dropped. IMHO, this is out of scope of the IWF spec.

* For the discussion on failure: I added an informative ref to the failure draft.

Cheers,
Med

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

Hi Med -

Please see inline [Tiru]

From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, September 12, 2012 8:38 PM
To: Tirumaleswar Reddy (tireddy)
Cc: [e-mail]
Subject: RE: Review of draft-ietf-pcp-upnp-igd-interworking

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:

 [Tiru]  For failure case of PCP cannot allocate  external port, PCP will return error code CANNOT_PROVIDE_EXTERNAL, and IGD-PCP IWF is supposed to return negative message NoSuchEntryInArray.
Probably you may want to say "Once CANNOT_PROVIDE_EXTERNAL is received by the IGD-PCP IWF..."


      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?
[Tiru] No

[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.".
[Tiru] ok

[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.
[Tiru] ok

[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.
[Tiru] ok

[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?
[Tiru] yes

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?
[Tiru] This is fine.

[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

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] If you are planning to address it in failure draft, I am fine with both options.

--Tiru.