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

[Radia Perlman <[e-mail]>]

Re Dean's question to me:

>>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?

I wish a protocol could be all in one document.  I assume in some cases
that's impractical because it would be too long.  But at any rate, I'd
prefer either the rationale should be in a few paragraphs, repeated in each
document for which it's relevant (in this case, all the documents
pertaining to the peer-to-peer variant), or the rationale be in one of the
documents, and all the others have a sentence saying "the rationale for why
in some cases the peer-to-peer variant is desirable is in XXX".

Back to wishing a protocol could all be in one document...if it can't be,
I'd love a single roadmap document that points to all the pieces needed for
understanding the protocol (and rationale, and proofs it works, and
terminology, and anything else relevant), with an explanation about what is
in each one (rather than just saying "here are 17 other documents you
should read).

I'm not quite sure why documents wind up in so many pieces.  I suppose in
some cases something is added after the fact (like "how to run this over
X"), and it's easier to come out with a tiny new simple document just for
that, rather than editing it into the main document.  But as a reader
catching up on a new technology, I'd find it easier to just read one,
well-organized, complete document.

Radia



On Thu, Mar 10, 2016 at 11:28 AM, Dean Willis <[e-mail]>
wrote:

> 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
>
> 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] 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
>
>
>
>