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

From: "Dan Wing" <[email-masked]>
Date: Mon, 3 Jan 2011 17:34:15 -0800

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, December 28, 2010 7:45 AM
> To: Dan Wing; 'Francis Dupont'
> Cc: [email-masked]
> Subject: RE: [pcp] base #32 (new): Interference between 2 clients on
> same host
> 
> 
> Hi Dan,
> 
> The source IP address/port used by the PCP Client are not "stored" by
> the PCP Server.

Agreed.

However, it stores the internal IP address and internal port, as
those are part of the mapping.  That's the 48 bits I was referring 
to, and is where the application is listening for incoming
traffic.
 
> 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.

1. is there really a problem where one application removes mappings
   for another application?  Or is this something that the market 
   will resolve?
  
2. if we add this functionality, how does a host freshly connecting
   to the network delete all previous PCP-created mappings?  Afterall,
   the freshly-connecting host won't know the application IDs used
   by the previous host that used the same internal IP address.  
   This ability to delete all pinholes is currently a feature of PCP:

       "A client can request the explicit deletion of all its UDP 
        or TCP mappings by sending a PCP request with a PIN OpCode 
        with external port, internal port, and lifetime set to 0. 
        A client MAY choose to do this when it first acquires a 
        new IP address in order to protect itself from port 
        mappings that were performed by a previous owner of the 
        IP address."

We could remove that functionality, I suppose -- afterall, hosts
do *not* get this sort of "ingress filtering" functionality today 
when they are assigned an IP address.

-d

> 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
> 
> 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
> >
> > 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 (:-).
> > _______________________________________________
> > pcp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/pcp
> 
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp
> 
> *********************************
> 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: Tue, 04 Jan 2011 09:47:31 +0100

Agreed.

=> and protocol

   
      for another application?

=> it is not a security problem but it is surely an operational one.

      Or is this something that the market will resolve?

=> or the market could decide PCP is not applicable...

   2. if we add this functionality, how does a host freshly connecting
      to the network delete all previous PCP-created mappings?

=> by not using an application ID in its 'delete all' request.

           ..."

=> even if I am not fully satisfied by the term 'client' (it should be
'host', BTW 'client' alone should be avoided or replaced by 'PCP client'),
this functionality is fine.

=> I never proposed to remove this 'delete all', just to add a new level
of freedom in 'delete all' and similar operations.

Regards

---

From: <[email-masked]>
Date: Tue, 4 Jan 2011 11:04:54 +0100

Hi Dan,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mardi 4 janvier 2011 02:34
À : BOUCADAIR Mohamed NCPI/NAD/TIP; 'Francis Dupont'
Cc : [email-masked]
Objet : RE: [pcp] base #32 (new): Interference between 2 clients on same host

Agreed.

Med: There is an issue since service degradation may be experienced due to such behaviour. An application may think it has opened the pinholes in the PCP-controlled device but no traffic is received...because this pinhole has been removed by another PCP Client of the same subscriber. 

Med: IMHO, we need to understand the scenarios we have on the table and then decide on how to mitigate them and to make priorities if there is conflict(s). The ability to remove mappings is required for various reasons: avoid service degradation due to unwanted mappings/stale mappings which consume the per-subscriber port quota, etc. But, issuing delete all mappings for all internal IP addresses should not be recommended. FYI, we are editing an I-D about PCP failure scenarios. We hope this ID helps to understand some of the scenarios. 

*********************************
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: Alain Durand <[email-masked]>
Date: Tue, 4 Jan 2011 06:43:44 -0800

>   for another application?  Or is this something that the market 

We already solved this issue. In the interim meeting, we agreed to allow
for connect then signal, in practice allowing any app on a host to take
over the signaling of another app session.

   - Alain.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 04 Jan 2011 16:53:29 +0100

> 1. is there really a problem where one application removes mappings

=> it is implicitly by accident/not an expected effect.

=> the question is not to allow or not, it is to avoid it when it is not
intented.

Regards

PS: it would be easier to understand with the pcp-failure document
(unfortunatly I have the write lock on it, oops).

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 4 Jan 2011 08:10:36 -0800

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, January 04, 2011 12:48 AM
> To: Dan Wing
> Cc: [email-masked]; [email-masked]

I don't understand.  UPnP IGD does not have such functionality,
neither does NAT-PMP.  

> => by not using an application ID in its 'delete all' request.

Yes, that's right.

What prevents-or-discourages an application from doing that when it
initializes?  That is, if we add this functionality, will it help
the underlying problem of preventing Application A from stepping
on Application B's mappings>

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 4 Jan 2011 08:14:07 -0800

...
> Med: IMHO, we need to understand the scenarios we have on the table and
> then decide on how to mitigate them and to make priorities if there is
> conflict(s). The ability to remove mappings is required for various
> reasons: avoid service degradation due to unwanted mappings/stale
> mappings which consume the per-subscriber port quota, etc. But, issuing
> delete all mappings for all internal IP addresses should not be
> recommended.

That is exactly my point.  Let's say we make that recommendation -- 
it is a reasonable recommendation afterall.  With that recommendation,
and with the ability to delete all mappings, I do not see the purpose
of an Application ID.  Because, if we add an Application ID, a rogue
application can still delete all mappings, and if we do not add an
Application ID, a rogue application can still behave appropriately
and not remove mappings for other applications.  

> FYI, we are editing an I-D about PCP failure scenarios. We
> hope this ID helps to understand some of the scenarios.

Ok.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 4 Jan 2011 08:44:46 -0800

> From: Alain Durand [mailto:[email-masked]]
> Sent: Tuesday, January 04, 2011 6:44 AM
> To: Dan Wing
> Cc: [email-masked]; Francis Dupont; [email-masked]

Great, thanks.  I marked issue #32 as 'wontfix', which closes it.

http://trac.tools.ietf.org/wg/pcp/trac/ticket/32

-d

---

From: Francis Dupont <[email-masked]>
Date: Tue, 04 Jan 2011 19:18:55 +0100

=> it is true for NAT-PMP but not for UPnP IGD: it is one of the use
of the PortMappingDescription.

=> as I explained before: if we provide this functionality it should
be required for applications which may run not alone on a host, i.e.,
either there is a PCP agent on the host and applications work with it,
or each application runs its own PCP client and must use an application ID
(if possible easy to recognize by other instances of the same application).

BTW even a central per-host PCP agent has an use of application IDs, or IWFs.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 04 Jan 2011 19:25:26 +0100

=> you are talking about security: the application ID is not
a security feature (there is simply no PCP specific security between
applications) but an operational one.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 04 Jan 2011 19:30:24 +0100

=> so now we have the choice between unclose it or to create
a similar one with a verb less ambiguous than 'prevent'.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 4 Jan 2011 11:11:09 -0800

> of the PortMappingDescription.

UPnP IGD 1.0, it says:

  2.2.20. PortMappingDescription
    This is a string representation of a port mapping and is
    applicable for static and dynamic port mappings. The format
    of the description string is not specified and is application
    dependent. If specified, the description string can be
    displayed to a user via the UI of a control point, enabling
    easier management of port mappings. The description string
    for a port mapping (or a set of related port mappings) may or
    may not be unique across multiple instantiations of an
    application on multiple nodes in the residential LAN.

it doesn't say UPnP IGD control points have to use this information to
restrict which ports they delete.

I agree they _could_ use the information that way.

> BTW even a central per-host PCP agent has an use of application IDs, or

I propose this be deferred to a separate document, and done as an
Option.  The Option can work like this:  include the Option and
its value (e.g., "for the webcam") in the request and, if the PCP 
server understands it and likes it, the server will positively 
acknowledge its understanding of that Option in the response.  A 
later attempt to delete the mapping (lifetime=0) will require
the Option and same Option value to be included in the request.

Would that work?

-d

---

From: Francis Dupont <[email-masked]>
Date: Tue, 04 Jan 2011 23:46:39 +0100

=> I didn't say that too: I meant they can.

=> a control point operated by a human will use the information that way
(my main issue with port forwarding entries is I never remember some
months later what they were for when it is not very obvious.
Unfortunately the CPE I use doesn't provide a description field in
its interface...)

   Option.

=> of course this should be an option!

   The Option can work like this:  include the Option and
   its value (e.g., "for the webcam") in the request and, if the PCP 
   server understands it and likes it, the server will positively 
   acknowledge its understanding of that Option in the response.
 
=> fine

   A later attempt to delete the mapping (lifetime=0) will require the
   Option and same Option value to be included in the request.
   
=> the constraint on the delete is a bit too high and won't work
with a delete all. My idea is a delete with the Option will require
the same Option value to be included in the request.
BTW this means the wildcard for the Option is to not include
the Option. (Remember the addressed issue is operational, not a
security one).

Thanks

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 4 Jan 2011 16:40:48 -0800

> Sent: Tuesday, January 04, 2011 2:47 PM
> To: Dan Wing

Agreed that an application could obtain the list of UPnP IGD mappings 
and then only delete those with a PortMappingDescription that matches 
what the application (might have) previously created.

> Unfortunately the CPE I use doesn't provide a description field in

With PCP, something -- somewhere -- is refreshing the port 
forwarding entries.  They don't last forever.  That same thing
that refreshes the PCP entries could maintain the text hint for 
a user.  

(Or, in the case of the CPE you're using at the moment, it probably
wouldn't do that).

> the Option.

I added what you wrote in the paragraph above to

and set it to "open, enhancement" so it can be retrieved later 
easily.

-d

> (Remember the addressed issue is operational, not a
> security one).
> 
> Thanks
>

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 Jan 2011 15:13:00 +0100

=> this implies the PCP client stores its state in stable storage
so I have a real concern about how to implement this on a B4 IWF
for instance.

=> my CPE has no stable storage: this is why config changes are applied
on after a reboot which includes a download on the new config.
Another proof that the point about stable storage is really critical.

Thanks

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 5 Jan 2011 11:02:44 -0800

> Sent: Wednesday, January 05, 2011 6:13 AM
> To: Dan Wing

If I understand correctly, your concern is a UPnP IGD -> PCP
interworking device.  

Today, when a UPnP IGD device is told to map a port, it is allowed
to forget a port mapping upon reboot:

http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf says:
  Note that static port mappings do not necessarily mean persistence 
  of these mappings across device resets or reboots.  It is up to 
  a gateway vendor to implement persistence as appropriate for their
  IGD device.

http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf says:
   NOTE: Port mappings are NOT REQUIRED to be persistent across 
   device resets or reboots. It is up to the control points to 
   recreate their port mappings when needed.

I don't believe a UPnP IGD -> PCP interworking device has to
meet a stricter requirement.

> Another proof that the point about stable storage is really critical.

Yes.  I know that a lot of low-end CPE are like that because of 
the limited write cycles of the non-volatile memory they use.

I don't see a problem with PCP, though.

-d

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 Jan 2011 23:15:03 +0100

******************************************************************
Can we wait for the publication of draft-boucadair-pcp-failure-00?
******************************************************************

   
=> yes, I have a UPnP IGD 1.0+ / NAT-PMP / PCP -> PCP IWF on a B4
and I miss some stuff to get something operationally sound and
reasonably secure.

=> I know this text but IMHO it is the worst thing you can write.
And it doesn't help for an IWF because the state is not likely
lost on the PCP server of the CGN: this switches from an unsolvable
persistence problem on the CPE to a PCP client/server synchronization
issue (solvable but not with the current PCP).

=> this text is better for a pure UPnP deployment. For an IWF it just
squeezes it between UPnP clients (aka control points) and the PCP server
of the CGN.   
   
Regards

PS: the failure document has some arguments about the application ID too.