Re: [secdir] Secdir review of draft-ietf-p2psip-concepts-08

[Dean Willis <[e-mail]>]

Thanks, Radia. Good catch on “the the typo.”

RFC 6940 has most of the security considerations for RELOAD (the protocol that came out of this work), using the terminology from this document. In short, it boils down to the single-cert problem; the typical RELOAD overlay has a simple PKI understructure, using a singular authority (the enrollment server) that has a public key used to sign the credentials for each enrollee.

RFC 5765 is, in its entirety, security considerations for P2P.

You actually ask a very good question here about motivation, one that we spent a lot of time TALKING about, but apparently didn’t spend much time WRITING about. There were “scenarios” drafts that covered motivations, but they didn’t get conserved into a publication-ready state. An example is https://tools.ietf.org/html/draft-jiang-p2psip-peer-protocol-requirement-01 <https://tools.ietf.org/html/draft-jiang-p2psip-peer-protocol-requirement-01>

The short answer to your concern is that the “enrollment” process happens on the order of N times, where N is the number of nodes participating in the overlay (multiplied some relatively low expiry rate). But registration and resolution (aka, rendezvous) operations are vastly more frequent, happening (at the least) every time the IP address of a node changes (or in SIP, every 30 seconds, just in case),  and every time one node needs to contact another (which scales with the link-density of the network, typically an exponential). 

Practically speaking, an enrollment server can run on a typical LAMP stack with one box (or perhaps a redundant pair) supporting millions of users. But the rendezvous problem is more like trying to run the Internet on dynamic DNS servers — it gets gnarly quickly.

Further, if enrollment breaks, no new nodes can be added, but existing nodes continue to work. But if rendezvous breaks, the whole system grinds to a halt. 

Rendezvous, therefore, benefits from a high level of distribution — both from a load scaling and a resilience perspective. 

Yet another issue is that the traditional SIP proxy/registrar represents a very rich target for interception of communications metadata. If every movement of a user  and every communications between any two users  is mediated by a single box, that box becomes a very high priority target. The attack surface is narrow, but the payoff is huge. The P2P routing model, on the other hand, stores relatively little information at any given node, producing a broader attack surface, but requiring vastly more nodes to be compromised before overall opsec is diminished. This is particularly significant in the scenario of a nation-state actor, who must penetrate not just the local proxy-registrar but potentially millions of foreign nodes in order to tap the metadata.

So, here’s the question: Where should such motivations be documented? Do they belong in the terminology document? I can see making this into a terminology-and-rationale document. Do they belong in the protocol specifications?

—
Dean



> On Mar 10, 2016, at 11:57, Radia Perlman <[e-mail]> wrote:
> 
> (Sorry...I'm resending because I mistyped and sent to [e-mail] <mailto:[e-mail]> the first time)
> 
> I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.
> 
> This document is titled "Concepts and Terminology for Peer to Peer SIP", and as such would have no security considerations, as noted in the document.
> 
> However, this document describes how to discover which host a client is at, instead of using a SIP proxy, by using a peer-to-peer network and DHT.
> 
> I'd have liked a motivation for why this would be a preferable mechanism.  It seems like it would be less secure, in that more things will need to be trusted.  And furthermore, as this document says in section 5.4:
> 
> "The P2PSIP WG does not impose a particular mechanism for how the
>  peer-ID and the credentials are obtained, but the RELOAD protocol
>  does specify the format for the configuration information."
> 
> I'd think the hard problems would be things like who to get a credential from for joining the peer-to-peer group of proxies, and how that entity would decide whether you should be trusted to join the peer-to-peer group.  And if there is such a trusted entity (a central administration), why wouldn't the whole discovery process be more centralized?
> 
> Also, with a peer-to-peer DHT, it seems like there are more things that need to be trusted.  Any of them acting maliciously can cause incorrect answers.
> 
> Admittedly, I didn't read all the background documents.
> 
> There's a minor typo in section 2.2, clearly a cut and paste error:
> 
> "A special peer may be a member of the in the P2PSIP overlay"
> 
> Radia
> 
>