Re: [P2PSIP] 答复: An overlay resource leak scenario

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/04/2013 03:57 PM, 邓灵莉/Lingli Deng wrote:
> Hi Michael,
> 
> 
> 
> I don’t quite follow the case you described.
> 
> 
> 
> Shouldn’t a well-behaved rejoining peer be using the still valid
> certificate in the first place?
> 
> Otherwise, it is easy to exploit this to launch a DoS attack against ES,
> which must be protected.

Yes, and a well written enrollment server would certainly rate limit the
number of certificates granted per user.

Another solution that was proposed during the meeting in Vancouver by EKR is
that the enrollment server generates a Node-ID using a hash (e.g. on the user
name) so the same Node-IDs are always allocated to the same user, which solves
the problem of certificate renewal and also helps RELOAD clients that cannot
persistently store their certificate.

> 
> 
> 
> BR
> 
> Lingli
> 
> 
> 
> *发件人:*p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] *代表
> *Michael Chen *发送时间:*2013年7月5日1:56 *收件人:*p2psip@ietf.org *主题:*[P2PSIP] An
> overlay resource leak scenario
> 
> 
> 
> Hi,
> 
> 
> 
> Background
> 
> ==========
> 
> In a SIP usage of RELOAD, a peer can store its AoR and certificate in a
> single RELOAD Store Request with a SIP Registration kind and a Certificate
> By User kind. The data model for the SIP Registration is dictionary with
> its Node-ID as key, and Certificate By User is array.
> 
> 
> 
> P2PSIP Draft
> 
> ===========
> 
> In pspsip-base-26, section 11.3, bullet #5 says:
> 
> o  One or more Node-IDs ...
> 
> ...  The enrollment server
> 
> *SHOULD* maintain a mapping of users to Node-IDs and if the same
> 
> user returns (e.g., to have their certificate re-issued) return
> 
> the same Node-IDs, thus avoiding the need for implementations to re-store
> all their data when their certificates expire.
> 
> 
> 
> Implementation
> 
> =============
> 
> The enrollment server always returns a new Node-ID or keeps the above
> mapping for a short period compared to the expiration time of the
> certificate.
> 
> 
> 
> Usage Scenario
> 
> =============
> 
> A device goes in and out of the range of WiFi as it moves or sleeps then
> awakes. Each time it loses the WiFi, RELOAD does not get the chance to
> properly Leave the overlay. Each time it gets the WiFi back, it rejoins the
> overlay and receives a new Node-ID and thus a new certificate.
> 
> 
> 
> Resource Leak
> 
> =============
> 
> Due to the data model (dictionary key off Node-ID) and array (Store by 
> appending), the overlay holds on to more and more useless SIP Registration
> and Certificate By User at the Resource-ID (hash of the device's AoR).
> 
> 
> 
> Possible Remedy 1
> 
> ================
> 
> (p2psip-base) The enrollment server MUST maintain the same AoR to Node-ID 
> mapping as long as the corresponding certificate is still valid. Con:
> expensive enrollment server storage.
> 
> 
> 
> Possible Remedy 2
> 
> ================
> 
> (p2psip-sip and p2psip-base?) The joining peer MUST fetch and remove
> existing SIP Registration and Certificate By User at the Resource-ID before
> storing its current one. Con: peer-join complexity.
> 
> 
> 
> Do I have a case?
> 
> 
> 
> Thanks
> 
> 
> 
> --Michael
> 
> 
> 
> _______________________________________________ P2PSIP mailing list 
> P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip
> 

- -- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJR1wZ1AAoJECnERZXWan7EgokQALFLjNJPZUkGeqvZ+X+VeoS2
jjDtASWCsHPTc0Z8qDQBAHSLETvgQmVx/lmMBOmiIEiGOrAttvJ8jVnEpC+a+6tc
/gRdZ15oY08Exgdqw6E+9CJOgRGaQpyHqGAbfXhB1z/1jtBWdeF/k25JOr3lCv99
Z8vkG85PPDtF86W32QawcG0CB/foFTD7otfhsj54jlYY+oXrHFyN/L9SITx8/XRW
m3nxE20q6jI3KmxM95NflXOgbObFrbQOnX/+0hbmwES0NNmZi3Q8KLiCUVezXk3D
yqNd9K5cpgTNHXLFYjQZjuvPeIMK0NG6fyDS+CwaMNiTJ+Wxn8crppASUWGFP3Oh
p8qPMI0+8nLwWcmazoC4+3MeVCl8/Gfn87VGFmhGLs+5F8UQmNeZWB59BPD5Ny9m
wnh90TAuNTHy4CorDbN1xo1be0LL1Yw2tKTa2M/luFEUeZvpPMFCGCPdc1nzIEOL
KJRDTX6hKn+wamEibwQnJTkJKvs5LnYZhQq6M/aXYzik32o/H70X/TdaA5BlHQVk
9bO7VDTD7K8S67dskFBUDO/oKjsfjUKAbrmSAlux2GuunYQE2KI38b4wmZSpb8/5
+LIOmPnQNN9Zt3+gaUDXB4vNVOapyEbNkGN8yYBU+kClJUZCI7PyF9pVC3JcnLY2
vkPWQMqSH9B60mrIOZie
=aEB6
-----END PGP SIGNATURE-----