Subject: [pcp] base #32 (new): Interference between 2 clients on same host

From: "pcp issue tracker" <[email-masked]>
Date: Tue, 21 Dec 2010 07:02:10 -0000

#32: Interference between 2 clients on same host

 (1) How to prevent PCP Client_1 deletes the mappings of PCP Client_2?
 (2) During failure scenarios, if a synchronisation procedure is needed to
 retrieve the states from the PCP Server, how to disambiguate the state of
 each PCP Client?
 etc.

-- 
--------------------------------------------------+-------------------------
 Reporter:  mohamed.boucadair@…                   |       Owner:     
     Type:  defect                                |      Status:  new
 Priority:  major                                 |   Milestone:     
Component:  base                                  |     Version:     
 Severity:  Active WG Document                    |    Keywords:     
--------------------------------------------------+-------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/32>
pcp <http://tools.ietf.org/pcp/>

---

From: Francis Dupont <[email-masked]>
Date: Tue, 21 Dec 2010 11:57:22 +0100

A new 'per-application ID' option.
Points to solve:
 - get a good name (not 'client ID' as client is not a free term)
 - mandatory or not (IMHO it must be mandatory or it will be unusable)
 - fixed length (32 bits seem enough) / maximum length (yes!)

Regards

[email-masked]

PS: when I say 'mandatory' it is mandatory to process and
also mandatory to support (as HONOR_EXTERNAL_PORT), i.e.,
a not-optional option (:-).

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 21 Dec 2010 18:32:58 -0800

There is already 48-bit application ID, comprised of the source IP address
and source port.  Is that insufficient?  Does that not work?

-d

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francis Dupont
> Sent: Tuesday, December 21, 2010 2:57 AM
> To: pcp issue tracker
> Cc: [email-masked]
> Subject: Re: [pcp] base #32 (new): Interference between 2 clients on
> same host
> 
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Francis Dupont <[email-masked]>
Date: Wed, 22 Dec 2010 09:40:54 +0100

In your previous mail you wrote:

=> it doesn't work because of proxies (which will change them) and
because an application can open more than one socket to talk PCP.
And as the 'delete all' shows, the use of an application ID has to be
explicit.
If you want to avoid application IDs you must require one PCP
point of control per host but we already agreed we didn't want
such a contraint.

Regards

PS: the internal address can be considered as a part of the application ID,
i.e., the same ID with different internal addresses at the same time
identifies different applications (of course on different hosts).

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 22 Dec 2010 11:16:37 -0800

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, December 22, 2010 12:41 AM
> To: Dan Wing
> Cc: [email-masked]

I don't see how PCP can meet two conflicting requirements, namely

(1) a requirement that two applications not interfere with each 
    others port mappings
and
(2) a requirement to support 'delete all'.

-d

---

From: Francis Dupont <[email-masked]>
Date: Wed, 22 Dec 2010 22:10:19 +0100

=> use an optional per-application ID.

Regards

PS: optional means it is in an option and a 'delete all' can be sent
with or without it, it doesn't mean it does the same thing.
I.e., to enforce the (1) when there can be more than one client
on a host, all requests, including of course 'delete all's, MUST
be sent with a per-application ID.
PPS: we already discussed about this...

---

From: GangChen <[email-masked]>
Date: Tue, 28 Dec 2010 18:19:27 +0800

> => use an optional per-application ID.

Does REMOTE_PEER can't help to identify "per-application ID"?

Many thanks

Gang

---

From: Francis Dupont <[email-masked]>
Date: Tue, 28 Dec 2010 15:42:54 +0100

=> not at all (the per-application is about the source, remote peer
the destination, for traffic to the Internet).

Regards

---

From: <[email-masked]>
Date: Tue, 28 Dec 2010 16:42:39 +0100

Hi Francis,

Agree that client-id is not a good name. 

Application-ID is ok with me.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : mardi 21 décembre 2010 11:57
À : pcp issue tracker
Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Objet : Re: [pcp] base #32 (new): Interference between 2 clients on same host 

Regards

*********************************
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: <[email-masked]>
Date: Tue, 28 Dec 2010 16:45:19 +0100

Hi Dan,

The source IP address/port used by the PCP Client are not "stored" by the PCP Server. This does not solve the issue encountered when several PCP Clients are co-located on the same host. This application-ID is required to avoid a PCP Client deleting the mapping instantiated by another active PCP Client.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dan Wing
Envoyé : mercredi 22 décembre 2010 03:33
À : 'Francis Dupont'
Cc : [email-masked]
Objet : Re: [pcp] base #32 (new): Interference between 2 clients on same host

-d

---

From: GangChen <[email-masked]>
Date: Wed, 29 Dec 2010 11:16:18 +0800

> the destination, for traffic to the Internet).

For source, we have source address and port.
For destination, we have REMOTE_PEER.
I can't see what else we need for this "per-application ID".

BRs

Gang

---

From: <[email-masked]>
Date: Wed, 29 Dec 2010 07:38:22 +0100

Dear Gang,

In case several PCP Clients are embedded in the same host, how can you prevent a PCP Client to delete the mappings instantiated by another PCP Client?

Another utility of the application-ID is it allow to retrieve its mapping table from the PCP Server during a failure of the PCP Client for instance.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de GangChen
Envoyé : mercredi 29 décembre 2010 04:16
À : Francis Dupont
Cc : [email-masked]
Objet : Re: [pcp] base #32 (new): Interference between 2 clients on same host

BRs

Gang

---

From: GangChen <[email-masked]>
Date: Wed, 29 Dec 2010 15:45:38 +0800

In your previous mail you wrote:
>
> In case several PCP Clients are embedded in the same host, how can you
> prevent a PCP Client to delete the mappings instantiated by another PCP
> Client?

The PCP request sent by different PCP Clients would carry their
distinct REMOTE_PEER. This could help to prevent.

> Another utility of the application-ID is it allow to retrieve its mapping
> table from the PCP Server during a failure of the PCP Client for instance.

What you need is unique id. REMOTE_PEER+ Source IP/Port could guarantee.

Many Thanks

BRs

Gang

---

From: Francis Dupont <[email-masked]>
Date: Wed, 29 Dec 2010 18:34:52 +0100

=> it is not enough because it is related to the client,
not to the origin of the request. And this information is kept by the server
only the time to send the response.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 29 Dec 2010 18:52:47 +0100

=> this is not the purpose of REMOTE_PEER. And I'd like to know
how a REMOTE_PEER of any address/any port can identify something.

Regards

---

From: GangChen <[email-masked]>
Date: Thu, 30 Dec 2010 11:27:28 +0800

> how a REMOTE_PEER of any address/any port can identify something.

If I understood correctly, the flow like that.
We have two PCP clients A and B, which have been assigned the same
source address and port (X:x) by the host kernel. Otherwise, we could
use source address and port to differentiate.
Let's say, PCP client A will initiate TCP session A to Y:y; PCP client
B will initiate TCP session B to Z:z.

Afterwards, PCP clients A could send a PCP request like:
Internal=X:x;
External=0:0;
REMOTE_PEER=Y:y;

PCP clients B could send a PCP request like
Internal=X:x;
External=0:0;
REMOTE_PEER=Z:z;

If there is wrong, please correct me.

Many thanks

BRs

Gang

---

From: Francis Dupont <[email-masked]>
Date: Thu, 30 Dec 2010 10:05:00 +0100

If I understood correctly, the flow like that.
   We have two PCP clients A and B, which have been assigned the same
   source address and port (X:x) by the host kernel.

=> I can see the confusion: the issue is: you have two PCP clients
which share the same source/internal address but use different ports
(BTW it is impossible to share addresses, ports and protocol (UDP)
for two PCP clients on the same host talking to the same PCP server).
When PCP client A sends a host 'delete all' (i.e., port=any), client B
pinholes are deleted too even only client A pinholes are expected to
be deleted.
The obvious solution is to define (and require if it is possible to run
more than one PCP client on a host) a per application ID. And this
application ID can't be the client source port for the same reason
I write application ID and not client ID.

Regards

---

From: Simon Perreault <[email-masked]>
Date: Thu, 30 Dec 2010 11:23:03 -0500

> I write application ID and not client ID.

Why not use the PCP client's source address+port as identification, like
every other client/server protocol does?

Why would you want to allow two PCP client sockets to interfere with
each other?

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Simon Perreault <[email-masked]>
Date: Thu, 30 Dec 2010 11:29:29 -0500

> every other client/server protocol does?

(Answering my own question...)

Because the source address+port may change in the event that there is a
NAT between the PCP client and server. Since the PCP sessions are
long-lived and packets are far between, it is very likely that the UDP
session in that NAT would time out, and PCP requests coming from the
same source on the client could be allocated a different source by the NAT.

So the next question is: Why do we need a "delete all" operation?

Simon

---

From: Francis Dupont <[email-masked]>
Date: Thu, 30 Dec 2010 18:31:19 +0100

=> because it is not a pure client/server protocol as you have IWF/relays/etc

=> We want them to not interfere in an expected way.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 30 Dec 2010 18:34:47 +0100

=> note the issue is the same with a "get all" procedure.
The answer is it is the only way to recover from state lost
at the client side.

Regards

PS: IWF UPnP IGD has an incremental get and NAT-PMP a delete all,
so this feature is required for interworking too.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 30 Dec 2010 12:37:10 -0500

> The answer is it is the only way to recover from state lost

If the client loses state and then wants to issue a "get/delete all",
how will it know the application ID that it needs to use?

> so this feature is required for interworking too.

Got it.

Thanks,
Simon

---

From: Francis Dupont <[email-masked]>
Date: Fri, 31 Dec 2010 09:53:29 +0100

=> this is a good question. The solution could be in the choice of
the application ID...

Regards

PS: note the problem is the same with a per-host PCP agent: it has to
recognize applications to do the correct thing. BTW as passive open/serving
application can't share a port there should not be two instances of
the same application of this kind at the same time.