Subject: [pcp] Comment on REQ-9A of LSN requirements (PCP)

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 21 Aug 2012 02:24:48 +0000

"A.  It MUST NOT permit the lifetime of a mapping to be
               reduced beyond its current life or be set to zero
               (deleted)."

In the case of renumbering how a CPE that gets a new address can delete
stale mappings of the previous user of that IP address? Given some of the
requirements, it can not.

Before mapping 'nonce' CPE/host could just send a delete all and we would
rely on ingress filtering to make sure things are okay. But now with the
mapping nonce the new owner of an IP address has no way of deleting the
stale mappings because it does not know the nonce.

If renumbering happens frequently (as in some networks as short as 30
minutes) and there are many PCP MAP mappings from each CPE/host, then soon
depending on the Lifetime there will be no more resources on
CGN/AFTR/Firewall due to stale mappings

A possible solution would be for DHCP Server or other provisioning server
to send a PCP message with THIRD_PARTY to delete all MAP mappings. But
again, it does not know the nonce. Not to mention that coupling
provisioning and PCP becomes a barrier for adoption. Reducing the
'lifetime' defeats the purpose of having PCP.

Not sure of any solution given all requirements in place.

Thanks,

Reinaldo

---

From: <[email-masked]>
Date: Tue, 21 Aug 2012 07:57:03 +0200

Hi Reinaldo,

Stale mapping is a real issue which may consume per-user quota. The issue, exacerbated with the use of nonce, is discussed in detail in http://tools.ietf.org/html/draft-boucadair-pcp-failure-04 which proposes also a mechanism to recover the mapping nonce. Below some excerpts from the draft:

Section 2.2 of the failure draft reads:

   If the same port number is used but a distinct mapping nonce is
   generated, the request will be rejected with a NOT_AUTHORIZED error
   with the Lifetime of the error indicating duration of that existing
   mapping.  This issue can be solved if the PCP Client uses GET OpCode
   (Section 4) to recover the mapping nonce used when instantiating the
   mapping.

Section 2.3 of the failure draft reads:

   If the PCP Client does not store the explicit dynamic mappings and
   new mapping nonces are assigned, the PCP Server will reject to
   refresh these mappings.  This issue can be solved if the PCP Client
   uses GET OpCode (Section 4) to recover the mapping nonces used when
   instantiating the mappings.

Section 2.6 of the failure draft reads:

   On the reboot of the IWF, if no mapping table is maintained in a
   permanent storage, "stale" mappings will be maintained by the PCP
   Server and per-user quota will be consumed.  This is even exacerbated
   if new mapping nonces are assigned by the IWF.  This issue can be
   soften by synchronizing the mapping table owing to the invocation of
   the GET OpCode defined in Section 4.

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la 
>part de Reinaldo Penno (repenno)
>Envoyé : mardi 21 août 2012 04:25
>À : [email-masked]
>Cc : [email-masked]
>Objet : [pcp] Comment on REQ-9A of LSN requirements (PCP)
>
>_______________________________________________
>pcp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcp
>

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 21 Aug 2012 10:16:14 +0000

-----Original Message-----
From: <[email-masked]>
Date: Tue, 21 Aug 2012 07:57:03 +0200
To: Reinaldo Penno <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: Comment on REQ-9A of LSN requirements (PCP)

>Hi Reinaldo,
>
>Stale mapping is a real issue which may consume per-user quota. The
>issue, exacerbated with the use of nonce, is discussed in detail in
>http://tools.ietf.org/html/draft-boucadair-pcp-failure-04 which proposes
>also a mechanism to recover the mapping nonce. Below some excerpts from
>the draft:
>

That's a good idea but unless the PCP Client recovers all nonces by trying
to map to all internal
ports the problem would still exist, right? I mean, only those mappings
that resulted in collisions would be recovered.

Alos, wouldn't this opcode allow an attacker to recover opcodes belonging
to others. But anyway, the problem we are facing is due to base spec which
is at WGLC. If something, we need to solve there.