Hi Ekr, Thanks! Haibin
>-----Original Message----- >From: Eric Rescorla [mailto:[email protected]] >Sent: Wednesday, July 01, 2009 11:16 AM >To: Song Haibin >Cc: 'Eric Rescorla'; 'P2PSIP WG' >Subject: Re: [P2PSIP] P2PSIP Security Requirements Taken Out >From draft-matuszewski-p2psip-security-requirements-04 > >At Wed, 01 Jul 2009 11:01:34 +0800, >Song Haibin wrote: >> >Which of the requirements in this document do you believe fit that >> >description? >> >> What about system security requirement 6, 11 and 12? > >For those of you who can't read Word, these are: > >> Req. 6: The system must be able to identify repeat and delay attacks > >Well, these are both normal functions of a best-effort >network, so I'm not sure how one would determine whether a >node was misbehaving. > > >> Req. 11: An owner of P2PSIP resource (user) record MAY >indicate which >> users or network entities can retrieve, modify, and delete >data stored >> in their P2PSIP resource (user) records. > >I actually think this is a bad idea. Previous experiences with >trying to design access control systems (see WebDAV ACLs) have >turned out to be really overcomplicated. As far as I can tell, >this isn't necessary for the SIP use cases. > As RELOAD is designed to support various usages. Other usages may have this requirement. For example, we can image group communication scenarios, only members of a group can retrieve and modify the files belonging to this group. I think ACL might work. Could you tell me what causes the WebDAV ACLs overcomplicated? > >> Req. 12: It SHOULD be possible to limit the impact of badly behaving >> P2PSIP nodes on the overall system security. There SHOULD be an >> option to identify malfunctioning or badly behaving nodes, >and exclude >> or reject them from the P2PSIP system. > >Hmm... It seems to me that this is already possible at least >in some sense: you use short-lived certificates and then >refuse to reissue their certificates. Did you have something >else in mind? CRLs? > I'm not sure about the solution here. I think it may be hard to determine the TTL for such kind shor-lived certificates. Misbehaving nodes still function in the overlay until its certificate expires. Too short TTL may overload the CA anyway. I don't know how CRLs work in the overlay, in a p2p fashion or in a c/s fashion. -Haibin >-Ekr > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
