P2PSIP session at IETF 74, San Francisco CA, USA
1300-1515, Friday 27 March, 2009
Continental 4 Meeting Room

Notes by Richard Barnes and Dean Willis

New version of IETF note well presented.

Chairs Intro
-- No agenda changes
-- No comments on document status


Topic: RELOAD status and presentation
Presenter: Eric Rescorla (Ekr)

Adding a new quasi-flood mechanism for configuration changes to propagate. Model assumes there is one entity that provides configuration
files.
  -- Henning Schulzrinne: Suggests a more open model.
  -- Vidya Narayanan: I made some comments. Can we address these?
  -- Ekr: I have slides on those later

Signed config messages, custom signed data format. 

Updated mechanisms for adding new data types in response to Vidya, and discussion on access control.
  -- Vidya: Wasn't asking for the ability to do updates without RFC
  -- Vidya: Need to be separation between the entities that control config and data types. There may be a need to support a kind definition apart from the configuration/enrollment server. Suggests
disaggregating the kind document from the configuration.
  -- Ekr: It's reasonable to decouple config docs and type defs
Defines a basic access control policy language
  -- David Bryan (from floor mic): How do you deal with nodes that anyone can write to?
  -- Ekr: USER-MATCH-WITH-ANONYMOUS-CREATE does most of that. Unwise to allow arbitrary changes to nodes
  -- David: Might want to do that, e.g., for floor control
  -- Cullen Jennings: Kind IDs have a big namespace for other/private uses. This is what Vidya and I wanted
  -- Henning: Take a more systematic approach to permissions?
  -- Ekr: That's a fine idea, structure is not clear
Open issue: This requires a centralized config server
  -- Vidya/Ekr: Need to separate mgmt of kinds and data
Storage security goals: Integrity, access control, resource contraint
  -- Henning: These may not be the right axioms
  -- Mary Barnes: Really mean authentication+integrity
Distributed quota
  -- [missed comment]
  -- Henning: The real goal is mainly node-local protection
  -- Ekr: But if you handle it locally, I can eat up resources    
  -- Cullen: There are lots of models possible here
  -- Vidya: The resource ID needs to be bound to owner and node
  -- Ekr: Imperative that existing kinds have default strong access control policies
  -- Vidya: Not suggesting we change those rules, but introduce another rule
Issue: Defined Access Control Policies
Open Question: If there is a place for user-defined resources, how do we keep other people from overwriting them? How about allowing them to overwrite? How about specific groups?
Open Question: Is there a more general matrix that encompasses the set of permissions cases we currently have in a more logical manner? 
Slide: Open Issues with Approach. Noted that permissions to generate kinds are separate from right to delegate access permissions to resources.
Slide: Reload Storage Security Goals. Noted that here is a difference between preventing A from overwriting B's data and preventing A from overwriting B's data without B's permission.

Distributed quota.
Noted that math presented mixes average and totals.
Issue: Does allowing users to select security model at the store
impact the operability of the quota.
[??? comment in notes: We seem to have consensus on a new authorization model. But no hum called?]

Removing REMOVE: To remove, store a value of "nonexistent"

Transport: Quasi-reliable transport over UDP
  -- Henning: Is it worth inventing a new transport?
  -- Philip Matthews: There are other ideas in this space: Teredo, TCP over UDP
  -- Ekr: TCP/UDP will work, but it's awful
  -- Cullen: Made a presentation to TSVWG and it was 100% in opposition to that. (offers to do some more liaison with TSV area)
  -- Henning: Why is a pseudo-TCP better than TCP/UDP?
  -- [??? Philip?]: Suggested that ICE/TCP needs work, and if P2PSIP could contribute resources to finish it, then we might be able to use it.

David (as chair): Show of hands for how many people have an implementation? : 5-10 hands
How many plan to in the next few months?: 2-3 more hands
David (as chair): Would like to find 2-3 reviewers.  Volunteers? (David also offered to review)
  -- Vidya, Saumitra Das, Melody Song

Open discussion/issues not in presentation
  -- Vidya: Will send text relating to authorization delegation.
  -- Vidya: Would like to resolve big issues before small ones, e.g. solution for delegating authorization. How shall we proceed with the work?
  -- David (as chair): Let's try to get all the issues on the table
  -- Henning: Issue tracker on the tools page?
  -- David: Chairs will work on that. Seems the time may have come for that.
  -- Fran¨ois Audet: Are we inventing our own reliable transport?
  -- Ekr: That's what the current draft does
  -- Fran¨ois: Do the TSV understand that that's the alternative?
  -- Henning: Happy to send mail to TSV mailing list. In the interim, we can proceed with design on an assumption of a reliable transport protocol.
  -- Philip: TCP/UDP seems like the best option
  -- Rˇmy (Lastname?): Wouldn't call ICE mature, something like Teredo could be better
  -- Bruce Lowekamp: No inherent objection from TSV to new transport, but unclear whether there is a simple enough protocol that works. Suggested that room read RFC 5405.


Topic: P2PSIP Diagnostics
Presenter: Haibin (Melody) Song

Proposal to add richer error information
  -- David (as chair): How many have read the draft?: ~5 hands
  -- Henning: Not clear that we want to continue using old error codes. Suggest we look at some recent protocol designs that have made choices different from the classic HTTP models. He will send
references.
  -- Steve Norreys: Hard to decide error formats until you know how they the error information be used. For example, do we want to use the same code for network out as for node out? We might, or not.

Possible DDoS arising from Echo method
  -- DBryan (as chair): Could you explain briefly how the echo method works?
  -- Ekr: Not clear signing messages fixes things b/c of repay attacks. Also, with direct return routing, can attack outside network
  -- Cullen: Congestion control issues here as well. Suggested that we might do better with a source directed walk of the network. This might not work in the case of a broken route, which the mechanism is actually testing for. In the event of a transport without congestion control, this also raises the possibility of a congestion collapse.
  -- Roni: Could also do a traceroute-style thing, spreads things out and does not have the amplifier effects of the proposed technique
  -- DBryan (as chair): This is a WG item, please review
  -- Ekr: Earlier stuff was modeled as a usage, this may not be. Should this be new methods or a usage?
  -- DBryan (as chair): For now, we'll continue down this path. Please read the draft!


Topic: RELOAD extension to support direct response and relay
Presenter: Roni Even

  -- Cullen: Noted that TURN could be extended in its permissions models to allow an outside peer to reach the TURN client.
  -- Vidya: Some confusion over what we agreed to at last meeting. Thought we said direct routing was part of RELOAD
  -- Cullen: Don't recall that, like the way it is now
  -- DBryan (as chair): From the Minneapolis minutes: Hum taken on "whether or not we include direct routing as an option in the protocol, not worrying about what draft". Doesn't specify (in fact explicitly does not specify) base or extension
  -- [???]: This makes sense as a separate extension
  -- Vidya: There are some obvious scenarios where direct routing will work (e.g., cellular), so it makes sense to have it in the base
  -- Brian Rosen (as chair): Should every implementation have to do it?
  -- Ekr: No.
  -- Vidya: Don't know.
  -- Adam Roach: My phone has a 10/8 address, there are NATs
  -- Cullen: iPhone has 10/8 address
** CALL FOR HUM by DBryan: Shall direct routing be placed in the base draft or extension?
** Chairs call strong consensus for placing this work in an extension
  -- David (as chair): Need to make sure base draft doesn't preclude
  -- Roni: Let's figure out on list how to move this draft forward
  -- Saumitra Das: Detectable vs. Undetectable
  -- Roni: Not addressed in this draft


Topic: Self-tuning DHT for P2PSIP
Presenter: Jouni Maenpaa

DHTs assume properties of the network. If these change, performance is sub-optimal
  -- Norreys: This seems like it could cause instability b/c of hysteresis. Noted that there is a possibility of a hysteresis between the tuning and changing network status. 
  -- Jouni: There are some stabilization techniques in there. The intent of the work is to increase stability in the event of structural or size changes.
  -- Rosen: This is very cool.
  -- Cullen: This is very cool, but would be good to have some more data. Also, it's pretty close to the base draft. Could we add a little to the base draft to make this easier?
  -- Vidya: Interesting idea.  Also consider load balancing / replication. That would make the next plugin better-suited to the real world.
  -- Gonzolo Camarillo: N that this raises a meta-question about plug-in architecture.
  -- Henning: Makes a good base case to text extensibility of base protocol.
  -- Lowekamp: The base draft has a section discussing reactive/periodic and the issue that it needs to work in small-scale overlays.
  -- Saumitra: It would be helpful if you could quantify how bad it is in small overlays
  -- GCamarillo: We're starting to see problems scaling up after ~1000 nodes. Would like an approach/algo rather than empirical data.
  -- Lowekamp: Not specifically designed for small nets, but needs to work
  -- Jouni: Running experiments in PlanetLab up to 2knodes
  -- Ning Zong: Scale of overlays is not that great. How do you tolerate churn
  -- Jouni: Seems to handle it well in practice
  -- Gonzalo: We want to know if this is in parallel with base
  -- Henning: This is a good test case for extensibility
  -- Lowekamp: Is this a separate DHT, or a reconfig of base protocol
** CALL FOR HUM by DBryan: Is this interesting?
** Chairs report strong consensus in favor, none against
** CALL FOR HUM: Should this work go ahead in parallel with base work?
** Chairs report weak in favor, none against (very few responses)
  -- Gonzalo: We'll keep working, and diff with base


Topic: Load balancing for P2PSIP
Presenter: Saumitra Das

Limited time left. Presentation was curtailed.
  -- [???]:Noted that this approach may be much more useful where you have a relatively small number of keys on a node than for a very large number of keys.
  -- Ekr: Problem is node density, can't you control this with node IDs?
  -- Vidya: Part of the point is that you can do this without changing the enrollment server
  -- Henning: This seems like a low priority for this WG