draft-ietf-p2psip-base-08 Cullen Jennings Bruce Lowekamp Eric Rescorla Salman Baset Henning Schulzrinne March 25, 2010

draft-ietf-p2psip-base-082 Feedback from WGLC Many comments on major and minor issues. -07 and -08 updates have addressed almost all issues. The author group tried to address major issues on mailing list. Comments on other issues/nits were made in: This presentation will focus on major issues and trying to reach consensus on open issues.

Outline of Significant Issues Transport/ICE Direct Return Response Overlay Algorithm updates TLS mandatory Node-ID length March 25, 2010draft-ietf-p2psip-base-083

Various non-Nit changes handling incorrect storage_time define certificate data model RECOMMEND O(log(N)) neighbors Simplify finger table maintenance Switch from well-known port to application-id codepoint March 25, 2010draft-ietf-p2psip-base-084

Configuration File Added several new tuning/options parameters to draft. Significant discussion on list about syntax of configuration document Belief is that the current version should parse as valid XML and contains important options. Please review! March 25, 2010draft-ietf-p2psip-base-085

Transport/ICE Problems: ICE-TCP MTI, but unsure of completion Stream transports need framing for timeouts UDP Congestion/Flow control (AIMD) -Lite removal/compatibility with non-Lite No indication of framing/congestion in ICE March 25, 2010draft-ietf-p2psip-base-086

Framing Header Supports unreliable links Allows timeout for “reliable” links Unified header for all current protocols Data: seq# and msg ACK: ack# and received bitmask March 25, 2010draft-ietf-p2psip-base-087

Overlay Link Protocols Introduce “Overlay Link” specification Encoding, transport, and framing Needed to use ICE to negotiate compatible connection DTLS/UDP with SR TLS/TCP with FH, no ICE DTLS/UDP with SR, no ICE March 25, 2010draft-ietf-p2psip-base-088

Dealing with TCP TCP/ICE-TCP solutions: Remove ICE-TCP MTI and clarify that future extensions to ICE can be used with new codepoints Specify that FH is used to calculate RTO per RFC2988 to detect link failure AttachReqAns must list either only ICE or only No-ICE candidates March 25, 2010draft-ietf-p2psip-base-089

Selecting TCP Role All initial offers with TLS/TCP No-ICE MUST include a passive candidate The initial offeror will do the Active open in all cases except when the Answerer does not have a passive candidate (presumably because it’s behind a NAT) March 25, 2010draft-ietf-p2psip-base-0810 OfferorAnswererTCP Active ICENo-ICEOfferor No-ICEICEAnswerer No-ICE Offeror

Future Overlay Link Protocols AIMD proposal removed Added Message-Oriented (DCCP, SCTP) Added Tunneled DCCP/SCTP RECOMMENDED ICE priority 1.Message-Oriented with Congestion Control (SCTP, DCCP, etc) 2.Established Stream-Oriented (TCP) 3.Datagram-Oriented with simple congestion control (UDP with SR) March 25, 2010draft-ietf-p2psip-base-0811

Direct Return Response Section of -08 sketches out a proposal for DRR for RELOAD Multiple comments in WGLC that this is necessary Goal to ensure capability in base draft while allowing extensions to specify more detail of how/why or more advanced routing options. Essentially encodes an AttachReqAns with FORWARD_CRITICAL & DEST_CRITICAL flags Needs WG input before being fully fleshed out! Need to clarify what on-path peers can do. Need to resolve TCP interop March 25, 2010draft-ietf-p2psip-base-0812

Overlay Algorithm Need a new name! (chord-reload?) UPDATE messages: Now sent to all entries in Connection Table on Responsible ID change  required for client connected to responsible peer But: may be an issue with churn Options:  Leave as is, relatively minor (only on pred/succ change)  Add flag to Attach to request Update on resp change March 25, 2010draft-ietf-p2psip-base-0813

TLS Mandatory Current specification is TLS/DTLS MTI Want to move to allow future options. Will add text at beginning to say that TLS/DTLS are current specified option and future drafts may specify new options, but remaining text in draft will not change. New techniques must provide Authentication of nodes Integrity Confidentiality Specify how to format Signature in messages Will review draft to try to verify that TLS is not integral part of operations. March 25, 2010draft-ietf-p2psip-base-0814

Node-ID Length Currently 128 bits Advantages: Long enough for reasonable randomness Can simply truncate any uniformly random ID “same” implemenation could implement as primitive type Disadvantages: Not generally standard in the literature Harder to re-use other DHT implementations Might be some algorithms that use IDs differently Options Leave fixed at 128 Specify per overlay, maximum of 160 March 25, 2010draft-ietf-p2psip-base-0815