P2PSIP IETF73 Wednesday November 19, 2008 Session Notes

Brian Rosen & David Bryan chairs

Note Well Reviewed

Agenda reviewed and accepted

Bruce Lowekamp reviewed draft-ietf-p2psip-base-00.txt draft

Split into several categories:

Easy changes since Dublin

splitting base and sip usage

removing http-base error codes

split Ping into Ping and Probe

routing discussion moved to appendix

added discussion of periodic vs. reactive recovery

minor change to finger stabilization

updated IANA consideration

Medium issues from the list:

no tunnel uses case given, so it will be removed from the base

decouple overlay description from enrollment server; change accepted

relaxed wording on finger table entry selection to allow other topology awareness; this has been

made possible but no more complicated mechanisms will be required.

Hard issues:

Architecture issue: clarifying how routing layer and forwarding layer are described.

Unable to identify "standard" terminology--link vs. transport (architecture vs. implementer). A suggestion was given to standardize these, but Bruce cannot find a trulycommon set of terms. Discussion over the terms resulted in an agreement that the current document's terminology and diagram is acceptable, if not perfect

Stat was introduced; it is like fetch, but retrieves meta-data (length, storage time, lifetime).

mDNS was removed because it was not likely to be done soon; it is now close to done. Shall it go back in? Hum was yes; James Woodyatt has agreed to review text in this section when it is restored.

TCP-Test. Proposal to add an unsecured test transport for early development and interop. This would enable certain kinds of interop testing and sniffing. This does not work if TLS is the only way to do this. Proposals: do nothing, or make TLS requirement an overlay policy issue. The group discussed this, with major arguments discussing whether there were specific non-test requirements and whether the loss of security in authentication will create long term problems. The chairs called for consensus; consensus for retaining TLS as the only mechanism. It will be confirmed on list.

Large Messages. The current document needs to be revised to handle end-to-end transport. Options: support large messages as part of base protocol; provide infrastructure (e.g. error codes & overlay policy), but not specify details; others? The group discussed the options. There seemed to be agreement to provide support for error codes, but leave further work for later.

AttachLite: previous consensus was to remove ICE, making ICE-lite required. This didn't work when the authors tried it. Instead they created an AttachLite method that establishes connection using only raw transport; this can be used in overlays known not to have NATs. Public nodes can implement regular Attach without candidate gathering and interopate with NATed nodes. Review requested, and feedback on potential replacement ideas.

Support: agnostic security for unknown kind ideas. We will have to decide requirements on the list. Vidya says that this is a general issue: the store semantics says you must support all the kinds of methods in order to accept data. Is there a more modular approach? Also, what happens to heterogeneous usage in the overlay. She feels we should separate overlay primitives from usages. Overlay layer versus usage layer discussion will be taken to the list.

The group them moved to discuss NodeFetch

Motivation includes diagnostics, administration, and service discovery and placement. They discussed the existing storefetch being reused with this in mind; another option is to do a probe, followed by Request to Node-ID, but this fails when the overlay is unstable. Bruce then reviewed the NodeFetch operation (NodeFetch, NodeStore, NodeRemove). There were several comments in the room on the complexity here, and further discussion is expected on the list.

The group then heard Jiang XingFeng discuss the direct response and relay peer draft. He first goes through the discussion of history; originally proposed in SEP, then mentioned at the Dublin IETF. This is a revision and clarification of those discussions. This is an optional enhancement to enable optimization when overlays have high churn or transaction with large hop counts. The sending peer decides which routing mode

is used first. The decision can be made based on probes or past experiences.

NAT Behavior Discovery; this includes a new message rm_test, with a destination possibly determined by intermediate nodes. Is this text that gets added to base draft? Discussion of follow-on focused on the question of whether the work would go forward, with the discussion of how many documents to do it being deferred. First hum: whether or not we include direct routing as an option in the protocol (not worrying about what draft): result was consensus for including it in the protocol. Second question: do we know enough yet to make the other decisions (e.g. relay peers and discovery)? There seemed to be no objection to continuing list discussion, rather than deciding today.

Dan York then presented the p2psip security draft.

Early conversations with potential concerns from customers; this current draft is merger of two previous documents. The work planned for the document: synchronize with the RELOAD updates; improve readability, add a section on interconnecting P2PSIP networks to other networks.

Open Issue #1: Should this be a separate draft? Should it be merged it into the base? Partially merge it into the base? Split out the requirements, with a BCP flavor?

One follow-up question to that was: what pieces are we really missing here?

For those not addressed in reload, there are some aspects that would need to be addressed. Vidya asked that the draft include a threat analysis. Discussion on document and structure and needed elements resulted in agreement that the authors will re-spin the document to include the threat analysis and security considerations as one item; the chairs will work with all authors to determine the number the document. The second piece will be a general background information and analysis--it will either be a separate informational document or put into an existing document (e.g. concepts). The discussion of which document is deferred.

Roni Even then presented the p2psip diagnostics document on behalf of the authors. First reviewed the changes, then discussed the diagnostic scenarios. Some are in the routing protocol; some monitor the overall health of the network; and lastly diagnostics for a single node.

Open issues: Should we extend Ping? Should we extend Route_Query?

Concerns with making Ping arbitrarily extensible, and some preferences expressed for introducing one or more new methods for this. Hum for creating a working group item: no opposition, and consensus for adoption.