Spencer Dawkins' Notes from IETF 66 Ad-hoc Meeting on Peer-to-peer SIP

IETF 66 Ad-hoc Meeting on Peer-to-peer SIP

Friday, July 14, 2006, 1230-1500
Montreal, Quebec
Chairs: Mary Barnes and Gonzalo Camarillo
Notes by: Spencer Dawkins

Discussion Leader Topic My Notes
Gonzalo and Mary
Agenda Bash Is an official meeting of the SIPPING working group, Note Well applies.

No agenda bashing.

Goal is to BOF in San Diego and form a working group afterwards.
Dean Willis
Concepts and Terminology draft-willis-p2psip-concepts-00.txt

BOF in Dallas, crashed and burned in flames.

David, Eunsoo, Phillip, Henning, Cullen, Dean on 80 hours of conference calls plus side calls.

Doing P2P-SIP, not P2P-DNS, etc.

Dean described P2P-SIP overlays from the draft.

We drop "network" from the discussion because we're only talking about overlays.

P2P-SIP Peer may forward SIP requests to other entities.

We drop "supernode" from the discussion because it's not helpful.

Clients use the overlay without providing storage and retrieval services.

Brian - how do you address the client without a unique identifer? You don't, you address the user of the client.

Per-SIP User Agent is coupled to a P2P-SIP Peer or Client.

P2P-SIP User does have a unique identifier within the overlay that is the moral equivalent of an AOR.

P2P-SIP Node Roles - there are quite a lot of them.

Scott Brim - Client "uses but do not participant" - seems inconsistent with slide - point is that clients don't contribute resources that are used by other elements - needs to be clarified. Client does not participate in DHT, for example.

Keith - first few slides are general rendezvous protocol requirements - are we going there again?  Dean thinks this is a great idea for another BOF but not P2P-SIP. Although it is fair to say that at least half the problem is solving the rendezvous problem.

"Enrollment vs insertion" - Enrollment gives you ability (ID and credentials) to participate in the overlay.

Won't specify mechanism for enrollment here, but will specify the results of enrollment.

David - difference is that enrollment happens once/ever, insertion is anytime you turn a UA on.

EKR - only peers can serve? May still have contact association for a user, etc.

"Adding routing information" or "adding information"?

What about a network where enrollment is not necessary? Ad hoc with no credentials? Would be an open question.

"Working Diagram" is an eye chart, but it's easier to read in the slides than in the draft.

Philip cares about peers behind NATs.

Philip - outbound got deleted from our document.

Assume that we do ICE, TURN, etc... like anything else.

Scott - treating peer and client as exclusive functions, and they aren't - don't make them look so exclusive. Philip - there's a superset of functionality.

Eunsoo - confusion because we forgot to say peers have the client functionality as well.
David Bryan
Discussion of charter
Big top-level questions that have surfaced in debate.

What gets standardized?

Two protocols - an overlay client protocol and an overlay peer protocol. Could be the same protocol, but don't know that yet. At least one could be vanilla SIP, but don't know that yet, either.

Greg - SIP part of P2P-SIP is when you know location and can send INVITEs, etc.

Humm on this?

Cullen - need to focus on building the charter - for the BOF?  Cullen would like to do another BOF for RAI reasons, but we're working on a charter for the working group.

EKR says BOF again would be good.

Humm on "What are we standardizing?" lots of hands are OK, 80 percent. Disagree? none in this room.

Are topologies with NATs in scope? 3 subquestions - at all? locating media relays for NAT traversal? reuse existing IETF work?

Keith - what's the baseline? will work through as many as we can. there are at least 15 levels of NATs out there at various levels of evil.

Cullen - we're not talking about BEHAVE-compliant NATs, because ICE would work

Spencer - rant on whether you need to answer this question in order to have a working group chartered

Greg - our customers ask about NATs immediately.

Philip - we need to do this from the start.

Spencer - but how much do we need to say about NATs in order to charter the working group?

Henning - TURN and ICE, or more interesting non-IETF NAT traversal? Would be a lot more controversial.

Cullen - you're right, putting this over signaling wasn't the key thing, it was over TCP over HTTPS over a media relay. ICE went there. Pick well-defined bars. Don't worry that we're missing a lot here. Our NAT-virginity is long gone here.

Henry - developers and customers care exactly about this chart, exactly as it is. Take a vote.

Eunsoo - we're not overlapping with any other NAT traversal work.

Humm - "yes" before we asked the question - wording in the charter on reusing ICE, etc. Almost unanimous on the chart. Disagree?

Keith - will pass requirements for changes to other protocols to appropriate groups.

Can we limit the scope to name lookups? Proposed answer: Yes. Very analogous to SIP registrar functionality.

Dean - how does this play with "find the media relay"? As long as the media relay has a name.

Alan - this isn't about SIP registrar, it's about location service.

Gonzalo and Dean had a short clarifying chat. "Provide search functionality" - out of scope for this discussion. Not path-optimal, just has to work.

Greg - if we have a predictable name for a resource, that would be easier than searching across the entire network. Not trying to match something that's ephemeral - just like looking up a SIP URI now.

David - have to be able to find by name, even if the name is predicted.

Dan Petrie - could just look in an LDAP server and bootstrap the search that way.

Henning - this is about DNS-style lookups (in scope) vs LDAP-style lookups (out of scope). Three levels of looking, like NTP-style, hard part is smallest angle of a triangle is out of scope.

David - not tied to P2P, either - also useful to CS.

Philip - looking up a user, could be at multiple locations. Media relay could work the same way if you have multiple relays.

Greg - if you can get a canonical URL, you could look up anything in DHT.

Not saying what is verboten, only what is in scope for the chartered working group.

EKR - focus on the bottom layer first.

Philip - previous version of charter had two types of "out of scope" - this is stuff that would come in scope in a later version.

All yeses for limiting scope to name lookup.

Anonymization service?

SIP needs this but no answer today. Do it here? Could be complicated.

Spencer - is this required for the very early work? David is asking the same question.

Greg - very important service, bad idea to tackle this now. Contain complexity now. Personally think that it won't take much.

Hannes - this is complicated today because we don't know what that is.

Keith - thought RFC 3323 defined this - what's going beyond this?

EKR - incredibly hard to do this, protocols leak information like crazy, need to think about this up front rather than add this in later.

Dan Petrie - don't think an anonymization service is ever a requirement. Don't add early complexity for something we might do later. People who need this should pay price for complexity. We can add this to the charter later.

John Elwell - anonymization is difficult to achieve - security?

Philip - not interested in this personally, there are things we've put out of scope because know how to add them later. Who is interested? Between now and BOF, think about how to add this later on?

Jon - with a system like this, building security is a war against anonymization. You won't be adding things, you'll be taking things away. Don't understand "this adds complexity", as part of this discussion.

Cullen as individual - have gotten requests from IEPREP chairs about standard SIP with anonymization - don't reveal where you are when you make an emergency call. You guys don't deserve to have this problem dumped on you, but you're the only likely stuckees.

Greg - I am most opposed to this because there hasn't been sufficient discussion about how/to what end anonymization would be achieved. Process objection - don't distract people from getting core work done.

Eunsoo - would like to have this from beginning but don't know how to solve it now.

Dean - is very important, but delivery could be handled separately - "nothing that precludes" would be sufficient. Don't put in initial charter.

Jon - good plan for "get a charter and a WG", but if you don't understand anonymous, you won't understand security, either - opposite sides of same coin.

Philip - between now and San Diego, someone could put a draft out on this?

Hannes - don't understand but do work in this environment - it's not black and white, there are lots of possibilities. Look at MIP, they have same problems now. More precise is helpful.

EKR - agree and would be willing to sit down with someone and help.

Interested at all? 15 against, 30 for.

Exclude completely? 8 for.

Dean's compromise? 40 for.

Include in charter? none for.

Keith - this is fundamentally bound up in SIP, can't fix without changing SIP.

Gonzalo - this will go through SIP change process.

Hannes - Don't want 50 milestones, start with threat analysis, etc. and discover what needs to be done (after chartering).

Gonzalo - don't focus beyond a successful BOF in San Diego - can always add later.

Henning - trust admission control, or worry about rogue elements? Start with trusting the enrollment process.

Dean - assume rogue elements, at least some. SIPSEC thread about changing SIP so proxies don't see everything. Fine for CS-SIP, but much scarier here.

Henning - not saying we trust proxies, saying supernodes won't randomly disrupt the DHT.

Dean - "a" node doing bad things is easy to worry about - 50 percent is harder.

EKR - as we move to threat analysis... malicious can be disrupting DHT, rerouting calls, etc. State of the art is "somewhat resilient to damage".

David - make sure we have strong security metrics in place. Security and identity more entangled in P2P deployments. Centralized certificate authorities, but not for every scenario.

Cullen - charter with explicit security tradeoffs, don't extend the state of the art (this is the IETF), but think about what tradeoff looks like.

Greg - threat model as milestone would be reasonable to include in the proposed charter.

Philip - we have an hour left - can you get agreement on a charter proposal here?

David - don't do that, talk about what we agree on?

Philip - we have two versions of draft text, not wordsmithing and not from scratch.

Eunsoo - would like to charter ASAP, but we made progress today, go to mailing list and talk to people who couldn't be here.


Michael - we had two near-unanimous votes, let's get things done.

Cullen - let's declare success and go peer-to-peer.

Adjourned.... at about 2 PM.
Back to the IETF Work Section
Back to the IETF 66 Ad-Hoc Page

Page maintained by David A. Bryan (dbryan at p2psip dot org) and Tiffany Broadbent (tbroadbent at p2psip dot org).
Thanks to the many people who have contributed links to this site.
Last modified: 3 July, 2009