Re: [pcp] PCP failure scenarios & PCP state synchronization procedure

[<[e-mail]>]

Re-,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[e-mail]] 
Envoyé : mercredi 19 janvier 2011 18:32
À : BOUCADAIR Mohamed OLNC/NAD/TIP; [e-mail]
Objet : RE: [pcp] PCP failure scenarios & PCP state synchronization procedure

> >   "   [Ed.  Note: Do we need to support means to clear stale mappings
> >       first?  This may have an impact if the quota is exceed due to
> the
> >       presence of stale mappings.]
> >
> >    A PCP Client may be used to manage pinholes on behalf of a third
> >    party (i.e., the PCP Client and the third party are not co-located
> > on
> >    the same host).  If a new internal IP address is assigned to that
> >    third party (e.g., webcam), the PCP Client SHOULD be instructed to
> >    delete the old mapping(s) and create new one(s) using the new
> >    assigned internal IP address."
> >
> > (As you know,) PCP currently has a mechanism that supports doing
> > that - a PCP client can clear mappings for another host within the
> > subscriber's network.  I believe you're asking if we want to
> > encourage doing that.
> >
> > Med: The question is not this one but how to remove the stale
> mappings
> > associated with the "old" used internal IP address.
> 
> You're referring to the problem of detecting that a host's IP address
> changed?  I agree that is hard.  I say don't worry about it.
> 
> Med: This is a sensitive point for the CGN: port quota need to be
> carefully taken into account; otherwise the service will be impacted
> because of stale mappings.

Ok, I added the following to -03's security considerations:


   Because of the state created in a NAPT or firewall, it is anticipated
   that port forwarding (PIN OpCodes) will have a quota applied to each
   subscriber.  If the quota is small and the maximum lifetime is large,
   a faulty or disconnected PCP client could cause a denial of service
   for other PCP clients belonging to that same subscriber.  To prevent
   this problem, if a PCP server is configured for a small per-subscriber 
   quota (e.g., less than 15 ports) then it is RECOMMENDED it also be be
   configured for a short maximum lifetime (e.g., 5 minutes).

Med: This is one of the mitigation actions we can recommend; a more concrete one is to allow the PCP Client to audit the mappings it instantiated in the PCP Server.

...
> > I am worried about supporting such deletes
> > at all.  Let's take as an example that my IP address is 192.168.1.1
> > while I'm at home and then I visit a friend's house, were I get
> > a different address.  With a naïve implementation, I would simply
> > clear mappings for 192.168.1.1, which is my friend's webcam.
> > Oops.
> >
> > Med: Me too I'm in favour of having means to avoid such behaviour,
> this
> > is why I have proposed in the past the PCP Identifier
> > (http://www.ietf.org/mail-archive/web/pcp/current/msg00055.html)
> 
> That solves a slew of other problems, though.  And creates some new
> problems.
> 
> Med: imho, we need to analyse further the options we have on the table
> including the ideas you list below.
> 
> To solve the problem of accidental deletes, here are two other
> ideas:
> 
>   * a 3rd party mapping could cause an opaque identifier to be
>     included in the PIN response, and require subsequent PIN*
>     requests that reduce the lifetime to include that identifier.
>     A problem with that idea might be loss of the first response,
>     though.
>   * Another idea which doesn't change PCP is that the server,
>     on noticing a 3rd party mapping, only allows that same IP
>     address to reduce the lifetime of the mapping.
> 
> Med: Which information the PCP Server will use assess 3rd party
> mapping? Compare the internal IP address vs. source IP address?

Correct.

> > A smarter implementation would notice that my SSID is
> > different from my friend's SSID (SSID is something an OS-
> > embedded PCP client could know) but SSIDs can collide (all
> > the Starbucks use the same SSID) and Ethernet doesn't have a
> > handy SSID.
> >
> > The second paragraph I quoted above says that a PCP client
> > that created a pinhole for another device needs to refresh
> > the pinhole if the other device's IP address changes.  In
> > a PC, I don't see how that could be implemented.  It could
> > be implemented in a CPE, if that CPE is also running DHCP
> > and interfaces DHCP leases with PCP.
> >
> > Med: Yes, and especially for an IWF co-located with the local DHCP
> > server. Otherwise, we can recommend the use of static internal IP
> > addresses if PCP is used to configure third-party pinholes.
> 
> That's the only safe thing to recommend.
> 
> Med: This can be added to the I-D.
> 
>   Today, changing the
> IP address on a server is an involved process (reduce DNS TTL,
> bring it up on the new address and keep the old address active,
> change DNS, wait until TTL*some_safety_multiplier, decommission
> old address).  None of that is described in an RFC, it's just
> common practice (documented elsewhere).  I don't see a need to
> get into deep levels of education about changing client IP
> addresses and making that work nicely with PCP.
> 
> Med: Ok.
> 
> Besides, client
> IP addresses don't change that often or, if they are being changed,
> it's by a malicious ISP that is trying to interfere with their
> subscribers running a server -- exactly the sort of ISP that
> won't be much interested in PCP.
> 
> Med: See your point but this section is more about the change of the
> internal IP address.
> 
> ...
> > It should also be noted in Section 2.5 that, on today's Internet
> > without CGN and without PCP, subscriber WAN addresses change.
> > And if the subscriber installed their own NAT, the hosts behind
> > the NAT are likewise completely unaware of the CPE's WAN
> > address change.  NAT-PMP includes a mechanism to alert the
> > hosts of this change, which uses multicast.  We might consider
> > if PCP could benefit from a mechanism that allows alerting
> > hosts in some fashion [multicast or unicast].  UPnP IGD does
> > not include such a mechanism, to my knowledge.
> >
> > Med: I suggest you add an issue into the tracker to record it.
> 
> http://trac.tools.ietf.org/wg/pcp/trac/ticket/34, as an enhancement.
> 
> Med: Thanks.
> 
> >    2.6.2. Clear PCP Mappings
> >
> >    When a command line or a configuration change is enforced to clear
> >    all or a subset of PCP mappings maintained by the PCP Server, the
> > PCP
> >    Server MUST reset its Epoch to zero value.
> >
> > Does the PCP server need to maintain only one Epoch value, or an
> Epoch
> > value for each subscriber?  If one Epoch value, and only one
> > subscriber's
> > mappings are changed, it will cause all PCP clients to refresh their
> > pinholes -- unnecessarily.  So this means the base specification
> needs
> > to encouarge per-subscriber Epoch values.
> >
> > Med: FWIW, the logic of setting the Epoch value when enforcing CLI is
> > described in: http://www.ietf.org/mail-
> > archive/web/pcp/current/msg00091.html
> > I'm not sure Epoch is the more efficient per-subscriber hint to audit
> > the mappings; COUNT of the mappings can be considered too.
> 
> A count of the number of mappings only works if:
> 
>   1. there is one PCP client per host, which requires the PCP
>      client be part of the OS rather than part of the application.
>   2. there is some sort of application-id stored on the PCP server,
>      and counts are returned only for matching application-id.
> 
> Med: I agree.
> 
> If there is an application-id maintained for every PCP mapping,
> we might as well have separate Epoch for every subscriber for
> this case, as separate Epoch is fewer bytes on the server than
> an application-id for every mapping.
> 
> 
> > Then, to the main point of the draft:
> >
> > The two cases where GET/GETNEXT are useful are when an application
> > crashes and forgets its mappings (Section 2.2) and when the PCP
> > client crashes and forgets its mappings (Section 2.3).
> >
> > If we require PCP clients (implemented by applications or embedded in
> > an OS) to store their mappings in permanent storage, do we need
> > GET/GETNEXT?
> >
> > Are there PCP clients which cannot store their mappings in
> > permanent storage?  If so, let's discuss them.
> >
> > Med: Yes: some CPEs embedding a PCP Client/IWF.
> 
> Please say more.
> 
> Med: See http://www.ietf.org/mail-archive/web/pcp/current/msg00626.html
> ;-)	

If the interworking function has no stable storage, I don't see how
it can function as a UPnP IGD device at all.

Med: Dan, as a reminder we have wrote this in http://tools.ietf.org/html/draft-bpw-pcp-upnp-igd-interworking-01; 

"5.4. Port Mapping Tables

   IGD-PCP Interworking Function MUST store locally all the mappings
   instantiated by internal UPnP Control Points in the PCP Server.  Port
   Forwarding mappings SHOULD be stored in a permanent storage.  If not,
   upon reset or reboot, the IGD-PCP Interworking Function MUST
   synchronise its states as specified in Section 5.10."

We converged to this text instead of mandating permanent storage which is not met by low-end CPEs.

Reinaldo raised at that time "This is an extremely difficult requirement. Today most (if not all) CPEs only store in permanent storage manual configured mappings."




*********************************
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.
********************************