Subject: [pcp] Resolving contentious issue #3

From: Alain Durand <[email-masked]>
Date: Tue, 2 Nov 2010 16:29:17 -0700

The issue is: do we need a mandatory bit in the packet format?

It has been argued that a mandatory bit would simplify the UPnP/PCP inter-networking function.
So, the first question to resolve is:

3a: Is there a need for a mandatory bit for the pure PCP case? (ie outside the UPnP relay case)?
I have not heard any argument in that direction so far, so if there is a need there, now is the time to articulate it.

The second question to resolve is:
3b: for the UPnP intern-etworking function, a mandatory bit would simplify the server side implementation
because there will be less state to keep. Does this outweigh the added complexity in the protocol?
It has been argued that UPnP apps would go away and be replaced by PCP apps, so we can envision
a not too far future where the UPnP relay is not needed, so if the answer to 3a) is no, then PCP would
be better off long term by not having a mandatory bit.

I would like to open a 48 hour discussion window until Nov 4th, 5pm pacific time.

   - Alain.

---

From: Paul Selkirk <[email-masked]>
Date: Wed, 3 Nov 2010 04:38:57 +0000 (UTC)

> 3b: for the UPnP intern-etworking function, a mandatory bit would
> simplify the server side implementation because there will be less
> state to keep. Does this outweigh the added complexity in the
> protocol?

It's absolutely essential for the UPnP IWF.  The proposed mechanism in
draft-wing-pcp-design-considerations-00.txt, section 2.3.1, is
entirely unworkable and unrealistic.

It can be argued that UPnP apps that iterate through a small range of
ports are broken even today, and will be irrevocably broken by CGN.
But if we're going to support this behavior at all, there's no reason
to subject the PCP server to the thrash of multiple (unneeded and
unwanted) short-lived port mappings.  And the app won't wait around if
(as suggested) requests are throttled to one per second.

If the purpose is to break UPnP apps, then we can save a lot of time
and effort, and not define a UPnP IWF.

OTOH, if the purpose it to support UPnP apps to the extent possible,
then we need to respect the UPnP semantic that says "give me this port
or don't, but don't give me something else".

The "added complexity" argument is fallacious; this is dead simple to
understand, describe, and implement.

> It has been argued that UPnP apps would go away and be replaced by
> PCP apps, so we can envision a not too far future where the UPnP
> relay is not needed, so if the answer to 3a) is no, then PCP would

It has been argued that IPv4 would go away and be replaced by IPv6,
but here we are.

				paul

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 3 Nov 2010 00:52:58 -0400

On 11/2/10 4:29 PM, "Alain Durand" <[email-masked]> wrote:

> a not too far future where the UPnP relay is not needed,

Just like IPv4 replaced IPv6 ten years ago...Ohh, wait (;-) Applications
that use UPnP will be around for some quite some time. It will also be quite
some time until PCP reaches the level of support that UPnP has today. I do
not really care much about mandatory bit but I think we need another
argument to make it go away.

Unless, of course, Microsoft and others remove the UPnP APIs. If they are
still there, people will use them and apps will be around.

> so if the answer to
> 3a) is no, then PCP would
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Tue, 2 Nov 2010 22:15:02 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alain Durand
Sent: Tuesday, November 02, 2010 7:29 PM
To: [email-masked]
Cc: Dave Thaler
Subject: [pcp] Resolving contentious issue #3

It has been argued that a mandatory bit would simplify the UPnP/PCP
inter-networking function.
So, the first question to resolve is:

3a: Is there a need for a mandatory bit for the pure PCP case? (ie
outside the UPnP relay case)?
I have not heard any argument in that direction so far, so if there is a
need there, now is the time to articulate it.

[Senthil] Yes. This greatly simplifies the processing needed on the
server - no need to allocate a port when the asked port is unavailable
when this bit is specified and no need to run the 5 second timers and no
need to have the unnecessary processing associated to remove the unused
port. I am strongly in favor of having a mandatory bit. 

The second question to resolve is:
3b: for the UPnP intern-etworking function, a mandatory bit would
simplify the server side implementation because there will be less state
to keep. Does this outweigh the added complexity in the protocol?
It has been argued that UPnP apps would go away and be replaced by PCP
apps, so we can envision a not too far future where the UPnP relay is
not needed, so if the answer to 3a) is no, then PCP would be better off
long term by not having a mandatory bit.

I would like to open a 48 hour discussion window until Nov 4th, 5pm
pacific time.

   - Alain.

---

From: <[email-masked]>
Date: Wed, 3 Nov 2010 07:53:59 +0100

Dear all,

   In some cases the PCP Server should be instructed it must honour
   a request received from the PCP Client.  Examples of such cases is
   DSCP re-marking policies or returning the external perceived IP
   Address/port to detect the presence of the NAT.

   For illustration purposes, let focus on the DSCP marking case, the
   PCP Client should have means to assess whether

   1.  The PCP Server is able to enforce DSCP (re-)marking policies; in
       other words the PCP Server must support DSCP IE.

   2.  Its requested DSCP markings policies (direction: IN, OUT or both)
       has been successfully enforced by the PCP Server.  If the PCP Server
       fails to satisfy the DSCP marking policy as requested by the PCP
       Client, an error should be returned back to the PCP Client.

   A solution is to define a dedicated IE to instruct the PCP Server it
   MUST honour the request received from a PCP Client. The format of this
   IE is as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   IE Code     | Reserved      |             0x00              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Mandatory IE

   1.  This IE can be included as the only IE in a request.  In such
       case, it is like the M-bit.

   2.  It can be included together with other IEs such as DSCP IE: The
       PCP Server must support those IEs and must satisfy the request,
       otherwise an error should be returned.

   The UPnP IGD-PCP IWF can be designed without a M-bit (see for
   instance http://tools.ietf.org/html/draft-bpw-pcp-upnp-igd-interworking-00#section-5.7.2.1) or with a
   M-bit as described in http://tools.ietf.org/html/draft-bpw-pcp-upnp-igd-interworking-00#section-5.7.2.2.  There are
   tradeoffs between the two alternatives.  Having the Mandatory-IE
   described above allows to design an UPnP IGD-PCP IWF in both modes.

   Cheers,

   Med

PS: The idea of the Mandatory-IE came in a discussion I had with Alain.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Alain Durand
Envoyé : mercredi 3 novembre 2010 00:29
À : [email-masked]
Cc : Dave Thaler
Objet : [pcp] Resolving contentious issue #3

   - Alain.

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Francis Dupont <[email-masked]>
Date: Wed, 03 Nov 2010 15:32:36 +0100

In your previous mail you wrote:

   

=> there is no need now but this doesn't mean a mandatory bit is useless
(see below) or there will be no need for ever.

A mandatory bit is useful in renewals: in a renewal the requested
external port and address are the same than for the renewed PF,
so to receive in the response something else is a fatal error condition.
BTW most NATs don't support to have two PFs with the same internal
port and address so this error is in the 'should never happer' class.

   The second question to resolve is:
   3b: for the UPnP internetworking function, a mandatory bit would
   simplify the server side implementation because there will be less
   state to keep. Does this outweigh the added complexity in the
   protocol?

=> clearly yes and in the real world alternate procedures which delete
spurious PFs created with a not-requested port don't work on a CGN:
a CGN implements per subscriber quotas and PFs in hold down are
counted in these quotas (both because a held down PF may not be
re-allocated to another subscriber and to avoid PF consumption DoS
attacks), so if the quota is small it will be exhausted with no
benefit).

   It has been argued that UPnP apps would go away and be replaced by
   PCP apps, so we can envision a not too far future where the UPnP IGD
   relay is not needed, so if the answer to 3a) is no, then PCP would
   be better off long term by not having a mandatory bit.
   
=> the IETF can't enforce any rule so this is only a wish
(remember the IPsec support is mandatory for IPv6: its effect
was only to show the lack of power of the IETF).

Regards

[email-masked]

PS: we need to know on which fields the mandatory bit has an effect.
It seems it is the external port and address when they are not set
to zero/any. It is less an issue for IEs because it can be put
in IE specs.

---

From: Alain Durand <[email-masked]>
Date: Wed, 3 Nov 2010 08:28:59 -0700

Med:

It seems that the DSCP remarking would be done in a dedicated IE, right?
Then, it would seem that what you need is a Mandatory bit semantic **within** that IE,
not a global M bit... Am I missing something?

  - Alain.

---

From: <[email-masked]>
Date: Thu, 4 Nov 2010 08:15:45 +0100

Hi Alain,

Yes, DSCP marking policy can be instructed using a dedicated IE. 
Yes, an M-bit can be defined at the level of the IE to indicate a mandatory-to-be-honored-IE.
My point is that we may need to have an indication at the level of the request as a whole: mandatory-to-be-honored-request.
This mandatory-to-be-honored-request feature may be required if the same OpCode is used for both creating a pinhole and refreshing it (I would personally prefer having a dedicated OpCode for map refresh).

I think we should keep the initial spirit of PCP untouched: A PCP Client MAY provide a preferred external port as a "hint" to the PCP Server but it is always up to the Server to decide and return an available port. 

If an application (including the IWF) must be assigned the port it is asking for by the PCP Server, it should be treated as an optional feature of PCP; hence my proposal below. The mandatory-to-be-honored-request indication can be defined such a way it covers the external port, external IP address and any enclosed IE (e.g., DSCP).

Cheers,
Med

-----Message d'origine-----
De : Alain Durand [mailto:[email-masked]] 
Envoyé : mercredi 3 novembre 2010 16:29
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : [email-masked]; Dave Thaler
Objet : Re: Resolving contentious issue #3

Med:

  - Alain.