Subject: [pcp] On the need of a PCP identifier (a.k.a., PCP Client-ID)

From: <[email-masked]>
Date: Mon, 11 Oct 2010 13:32:05 +0200

Dear all,

   In some scenarios, an additional identifier than the internal IP
   address may be required to identify the mappings in the PCP Server.  In
   the lack of this identifier, a PCP Server can not identify stale
   mappings when a new IP address is used by a PCP Client.  Furthermore,
   when a new IP address is assigned to the PCP Client, this latter is
   unable to update its mappings in the PCP Server.  If a quota for port
   forwarding entries is configured, PCP requests may be rejected and
   unwanted traffic may be sent to other hosts.  

   Below is provided a proposal for an identifier to be enclosed in all
   PCP messages.  Some use cases of this identifier are also listed.
   (We prepared this text during the edition of the 02 of
   draft-wing-softwire-port-control-protocol, but we didn't published
   it).

   I send this e-mail to see if there is an interest to have such
   identifier part of the mandatory part of the PCP specification or
   not.

Comments and suggestions are more than welcome.

========================
= Client-ID Definition =
========================

  PCP Client-ID is a token randomly [RFC4086] generated by the PCP
   Client.  This IE MUST be present in all PCP messages except where PCP
   PING/PCP PONG (Section 9.8) messages are used to assess the
   availability of the PCP Server.  Only one Client-ID IE MUST be
   present in a PCP message.  The PCP Client and PCP Server MUST store
   the value included in this IE in a PCP Map Create Request.

   o  The Client-ID MUST be generated by the PCP Client and not the PCP
      Server;

   o  Upon change of the IP address of the PCP Client (or a third party
      on behalf of which a mapping has been created), the Client-ID is
      used to update related mappings (e.g., PCP Map Delete Request and
      PCP Map Create Request);

   o  The same Client-ID MUST be used for all requested mappings, unless
      a new Client-ID is generated by the PCP Client (e.g., reboot, OS
      crash, etc.);

   o  The Client-ID is stored by the PCP Server for all mappings
      (persistent storage);

   o  Upon the change of the Client-ID, the PCP Client MUST update
      existing mappings (i.e., delete all existing mappings and request
      new ones with the new Client-ID value).

   The format of the Client-ID IE is shown in Figure 5.

                         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        |      TBA      |    Length     |
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        |            Client-ID          |
                        :                               :
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 5: Client-ID IE

   The length of the Client-ID is encoded in the Length field in bytes.
   The length of the Client-ID MUST be at least 4 bytes and MUST NOT
   exceed 16 bytes.  The RECOMMENDED value is 16 bytes so as to have a
   robust random Client-ID.  If a Client-ID longer than 16 bytes or
   shorter than 4 bytes is received, the PCP Server MUST issue a PCP
   Error message with an error cause equal to "Invalid Client-ID".

   [[Discussion Note: It was tempting to define a variable length,
   without limiting the maximum length to 16 bytes, of the Client-ID
   field to allow for including "sophisticated" (e.g., security digest)
   token in this field.  Nevertheless, this may have an impact on the
   memory dimensioning of the CGN.  We may revisit this design choice if
   valid use cases are identified.]]

   For sanity checks, a PCP Server maintains the same Client-ID value
   (which is used in the latest PCP request) for a given PCP
   Client.  Upon change of the
   Client-ID, the PCP Client MUST update its instructed mappings with
   the new generated Client-ID.  The PCP Server SHOULD clear invalid
   mapping entries.  These checks avoid to receive unwanted traffic
   because of a mapping that has been installed by the previous owner of
   the IP address, etc.

=====================================
= Examples of usage of the Client-ID=
=====================================

X.1.  Unwanted Deleting/Modification of Mappings

   Removing or modifying an existing mapping in a PCP-controlled device
   would disturb and affect the successful delivery of wanted traffic to
   a legitimate subscriber.  For this reason, it is RECOMMENDED to use
   robust PCP Client-IDs (e.g., generate a random 16 bytes PCP
   Client-ID) when instructing the PCP Server for the instantiation of a
   mapping.  Doing so protects against deleting or modifying an existing
   mapping by a malicious third party.  Indeed, when a robust Client-ID
   is used, it will be hard for the attacker to guess the Client-ID
   value used by the legitimate PCP Client.  The PCP Server will reject
   all requests with invalid Client-ID value.  Furthermore, as specified
   in Section 9.4, a PCP Server SHOULD silently ignore subsequent PCP
   messages trying to delete the same mapping entry.

X.2.  Stale Mappings

   Due to a change of IP address, a host may receive an unwanted traffic
   because the previous owner of that address has instructed some
   mappings in the PCP and didn't deleted them in a proper manner.  As a
   reminder, on today's Internet without an ISP-operated NAT,
   subscribers occasionally have their IPv4 addresses changed due to
   renumbering or because a service provider wants to interfere with the
   subscriber operating a server.  In those instances, traffic from the
   Internet is still sent to the previous address (e.g., due to DNS
   entries pointing to the previous address).  In the presence of PCP
   and a NAT, it is possible that subscribers behind a NAT would also
   have their IPv4 addresses changed, and also receive traffic from the
   Internet because the NAT is unaware that the subscriber's IPv4
   address has changed.

   PCP supports several features that can mitigate these troubles:

   o  If no action is undertaken, stale mapping will be removed by the
      PCP Server upon the expiry of their lifetime.  For this reason, it
      is not RECOMMENDED to install infinite mappings;

   o  PCP operations rely on the Client-ID.  The same Client-ID MUST be
      used for all mappings belonging to a client.  A dedicated
      procedure is defined to clean invalid entries when the PCP Server
      detects that a new Client-ID is used by a given PCP Client (See
      Section 7.2.1);

X.3.  Update Internal IP Address

   When a new IP address is assigned to a host which has port forwarding
   entries in the PCP Server, these entries MUST be updated with the new
   IP address.  A PCP Map Refresh Request MUST be sent by the PCP Client
   to the PCP Server including the Client-ID and the new IP Internal address.

   Upon receipt of the PCP Map Refresh Request by the PCP Server, it
   checks if it maintains mappings associated with the Client-ID
   conveyed in the Client-ID IE:

   o  If no mapping is found, a PCP Error message MUST be sent by the
      PCP Server to PCP Client indicating the cause error set to
      "Invalid Client-ID";

   o  If a mapping is found, the PCP Server updates the Internal IP
      Address information with the new value as included in the request.
      If no error has been encountered when
      updated corresponding mappings, a PCP Map Refresh Response MUST be
      sent to the PCP Client.  

Cheers,
Med

*********************************
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: guodayong 57775 <[email-masked]>
Date: Tue, 12 Oct 2010 09:53:01 +0800

Agree.  It can improve identifying the subscriber and PCP' security.

> o  The Client-ID MUST be generated by the PCP Client and not the PCP Server
I think it is the same value if the Client-ID may be generated by the Client OR the Server.

---

From: <[email-masked]>
Date: Tue, 12 Oct 2010 07:15:24 +0200

Dear Dayong,

The point with generating the Client-ID at the PCP Client side is to have a lightweight PCP Server. Moreover, if this key is to be generated by the PCP Server, a "registration"-like operation will be needed for any PCP Client to retrieve such "security" key.

Does that make sense to you?

Cheers,
Med

---

From: Francis Dupont <[email-masked]>
Date: Tue, 12 Oct 2010 13:25:20 +0200

In your previous mail you wrote:

   > o The Client-ID MUST be generated by the PCP Client and not the

   I think it is the same value if the Client-ID may be generated by
   the Client OR the Server.
   
=> IMHO it doesn't make sense to get the Client-ID generated by the
server (according to its purpose).

[email-masked]

PS: I have some comments about the client-ID idea.

---

From: guodayong 57775 <[email-masked]>
Date: Tue, 12 Oct 2010 21:33:50 +0800

Hi, Med

> 
> The point with generating the Client-ID at the PCP Client side is 
> to have a lightweight PCP Server. Moreover, if this key is to be 
> generated by the PCP Server, a "registration"-like operation will 
> be needed for any PCP Client to retrieve such "security" key.
> 

One can choose lightweight PCP Server or a simple Client.
The Optional "registration"-like operation can protect PCP server from attacking of faked source IP address.

---

From: <[email-masked]>
Date: Tue, 12 Oct 2010 16:04:36 +0200

Dear Dayong,

We have considered this option of PCP registration phase (as indicated in the http://tools.ietf.org/html/draft-wing-softwire-port-control-protocol-01)

"[[Note-4:  should we add challange/response to protocol.  The main
   motivation for such feature is to prevent that third parties
   installs/deletes NAT entries.  A registration procedure can be
   envisaged at the bootstrapping of the PCP client/proxy and the PCP
   server to retrieve such security key to be used in subsequent PCP
   requests.  This feature can be configurable and not part of the
   mandatory features of the protocol.]]"

One of the drawbacks of this registration procedure is that during massive reboot of PCP Clients (e.g., due to power outage), the PCP Sever can be overloaded.

For the anti-spoofing function, we can rely on the mechanisms already in place in the context of NAT64 and DS-Lite.

Cheers,
Med 

-----Message d'origine-----
De : guodayong 57775 [mailto:[email-masked]] 
Envoyé : mardi 12 octobre 2010 15:34
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : [email-masked]
Objet : 回复:RE: 回复:[pcp] On the need of a PCP identifier (a.k.a., PCP Client-ID)

Hi, Med

---

From: Francis Dupont <[email-masked]>
Date: Tue, 12 Oct 2010 17:56:37 +0200

First you invoke RFC 4086 so I believe there is a security part in
the proposal I'll deal with at the end.

About the operational concerns addressed by the proposal, there are many
parts:
 - stale PF entries, i.e., PF entries for a previous instance of the
  client using a different (internal) address. There is nothing which
  can be done by the client other than waiting for expiry.
  In particular to identify the client by its client-ID only clearly
  raises a security concern.
 - stale PF entries from another client using previously the same
  (internal) address. This can be easily solved by recommending to
  delete all PFs associated to a new assigned address (note this
  relies on the address as the way to trust a client)
 - update PF entries after an address change. The delete part is
  in the first item, the request new PFs part is not an issue
  if different external ports are acceptable.

About the security, the client-ID is in clear so doesn't provide
a strong protection. My opinion is if we want strong security
the only reasonable way is to use mutual authentication.

Random comments:
 - stale reference to PING/PONG (which is a known todo design point)

 - not only the client-ID must be generated by the client but
  the client must keep it in stable storage

 - I have a security concern about identifying clients by their IDs

 - there is no memory dimensioning issue IMHO

 - the update by the server doesn't make sense in the security point
  of view (if the client is identified by its ID it may not change it
  and still be recognized). IMHO the problem is with the wording:
  IMHO the idea is to detect address reuse by client-ID changes.
  But this opens a way for a DoS attack too...

 - there is no infinite (lifetime) PFs.

To conclude I can't see an operational need and from the security
point of view the proposal raises new concerns when it solves some
about an out-of-path attacker.

Regards