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

["Reinaldo Penno (repenno)" <[e-mail]>]

-----Original Message-----
From: <[e-mail]>
Date: Tue, 21 Aug 2012 07:57:03 +0200
To: Reinaldo Penno <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
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:
>
>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.


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.




 

>
>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 : [e-mail] [mailto:[e-mail]] De la
>>part de Reinaldo Penno (repenno)
>>Envoyé : mardi 21 août 2012 04:25
>>À : [e-mail]
>>Cc : [e-mail]
>>Objet : [pcp] Comment on REQ-9A of LSN requirements (PCP)
>>
>>"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
>>
>>
>>
>>
>>
>>
>>_______________________________________________
>>pcp mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/pcp