Subject: [P2PSIP] An overlay resource leak scenario

From: "Michael Chen" <[email-masked]>
Date: Thu, 04 Jul 2013 10:56:17 -0700

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

---

From: 邓灵莉/Lingli Deng <[email-masked]>
Date: Fri, 5 Jul 2013 06:57:57 +0800

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.

BR

Lingli

发件人: [email-masked] [mailto:[email-masked]] 代表 Michael Chen
发送时间: 2013年7月5日 1:56
收件人: [email-masked]
主题: [P2PSIP] An overlay resource leak scenario

Hi,

Background

==========

P2PSIP Draft

===========

Implementation

=============

Usage Scenario

=============

Resource Leak

=============

Possible Remedy 1

================

Possible Remedy 2

================

Do I have a case?

Thanks

--Michael

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 05 Jul 2013 10:46:42 -0700

> Otherwise, it is easy to exploit this to launch a DoS attack against ES,

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
> 
> 
> 
> *发件人:[email-masked] [mailto:[email-masked]] *代表
> *Michael Chen *发送时间:*2013年7月5日1:56 *收件人:[email-masked] *主题:*[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
> 
> ===========
> 
> *SHOULD* maintain a mapping of users to Node-IDs and if the same
> 
> 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 
> [email-masked] https://www.ietf.org/mailman/listinfo/p2psip
> 

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: "Michael Chen" <[email-masked]>
Date: Sun, 07 Jul 2013 08:51:11 -0700

Hi Lingli,
 
A secure system cannot rely on "well-behaved" client. What if this is an attack? A peer does nothing but register and store the new certificate.
 
The enrollment server side limit mentioned by Marc is another possible counter measure, but I think Remedy #1 is better. If you're going to keep the state information for the limit, why not just keep the expiration date of the certificate already issued. The server resource cause will be the same.
 
EKR's suggestion will also work, if there is no security risk with known user_name to Node-ID mapping.
 
This topic needs more discussions. Please add it to the Berlin agendas if none of the principal authors are able to respond before then.

Thanks
 
--Michael
--------- Original Message --------- Subject: 答复: [P2PSIP] An overlay resource leak scenario
From: "邓灵莉/Lingli Deng" <[email-masked]>
Date: 7/4/13 3:57 pm
To: "'Michael Chen'" <[email-masked]>, [email-masked]

  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.
  
 BR
 Lingli

---

From: 邓灵莉/Lingli Deng <[email-masked]>
Date: Mon, 8 Jul 2013 10:17:23 +0800

[dll] Agreed. It would be better if the problem is briefly discussed in the security considerations part of the base?

[dll] It is an smart design. I think it would work for most cases. Where did you put it?
But since there is no collision-free hash function theoretically (i.e. the possibility from two user names mapping to a single Node-ID is small but not zero), it doesn’t wipe out the case that a peer's Node-ID could change after a certificate renewal.

BR
Lingli

-----邮件原件-----
发件人: Marc Petit-Huguenin [mailto:[email-masked]] 
发送时间: 2013年7月6日 1:47
收件人: 邓灵莉/Lingli Deng
抄送: 'Michael Chen'; [email-masked]
主题: Re: [P2PSIP] 答复: An overlay resource leak scenario

- -- 
Marc Petit-Huguenin

---

From: 邓灵莉/Lingli Deng <[email-masked]>
Date: Mon, 8 Jul 2013 11:14:50 +0800

I agree that we should have more discussion on this.

发件人: Michael Chen [mailto:[email-masked]] 
发送时间: 2013年7月7日 23:51
收件人: 邓灵莉/Lingli Deng; [email-masked]
主题: RE: [P2PSIP] An overlay resource leak scenario

Hi Lingli,

Thanks

--Michael

--------- Original Message --------- 

Subject: 答复: [P2PSIP] An overlay resource leak scenario
From: "邓灵莉/Lingli Deng" <[email-masked]>
Date: 7/4/13 3:57 pm
To: "'Michael Chen'" <[email-masked]>, [email-masked]

Hi Michael,

BR

Lingli