Mary Barnes, Jon Peterson, Cullen Jennings Chairs RAI Area Meeting @ IETF 65 -------------------------- Agenda bashing (3 min) Get a scribe (Tom Taylor) Blue Sheets Welcome, Introduction, & Status (chairs 10 min) Slides at http://www3.ietf.org/proceedings/06mar/slides/raiarea-0.ppt --------------- Jon Peterson delivered a tribute to Allison Mankin's work of the last 4 to 5 years. Cullen delivered a gift of appreciation. -------------- Noted that the agenda places securing RTP to end to allow msec people to attend. --------------- Reviewed composition of new Area. Noted that Megaco is closed. -------------- BoFs of interest and other adhocs (chairs 2 min) P2P SIP will be in Cortez. ------------- Distributed Multimodal Synchronization Protocol (Chris Cross 15 min) draft-engelsma-dmsp-01.txt Charts. Chris Cross presewnting. IBM-Motorola R&D project. Displayed example of multimodal application implemented with a browser. Voice activated electronic program guide. Search for shows starring John Wayne, then direction to record a specific program. Subject of I-D is protocol to distribute all of the modalities. Request from audience to define "modality". Means multiple ways of interacting with a set of programs e.g. in the example, voice and GUI. Rephrased: coordination of multiple user interfaces. Next chart: justification for distributed implementation: limitations in client resources. Quick view of protocol architecture. Four building blocks. Modalities: e.g., pen, GUI, speech. Can have per-modality browsers, or browsers for combined input. Four4 abstract interfaces, each defining a set of methods and related data structures. Command, response, event, signal Summary chart lists a number of facets of the design. Mary: should this be chartered in Applications or RAI. Answer: discussed with Allison, promising for RAI. Eric Burger -- like lots of stuff, crosses boundaries. ---------------------- Divide and Conquer (Dean Willis) (20 min) What options do we have to get work done faster? What would these look like in practice? What ones can we do now? What ones should we be thinking about for later? Charts. Complaints. Short stuff takes too long. People work in bursts. Hard to get enough review. Authors slow to update. Unclear wavering priorities. Suggestions. Modify the Chairs. Have more interim meetings. Exclude more work. set pr4iorities. Make a directorate. Redivide the problem space. History: statistics. Procedural experiments -- failed to thrive in IETF environment. New work keeps showing up. Observations: Two SIP + two SIPPING sessions per IETF per year. Output seems to depend on how hard the Chairs and AD work. Reviewer cycles limited, but management is the bottleneck resource. Current open charter has worked because Dean has held things together. PROTO moves work from ADs to WG Chairs. Dean was too busy to schedule a desirable interim. Proposals: split both SIP and SIPPING. -- 4 new more-narrowly chartered groups -- 8 total chairs -- manage more aggressively Directorate? Yes. Provided specific proposals for new charters. (Long line at microphone) Jon: other WGs also have problems of overload. SIMPLE example. Want to look across RAI. Hannes: PROBLEM OF PEOPLE STICKING TO THEIR NARROW INTERESTS. (Damn caps lock!) Dean: yes, need to incubate new ideas, build participation Rohan: loading almost equal load between Chairs and editors. Will quickly run into new bottlenecks. Also challenge to recruit new Chairs with enough time. Key response is to set strong priorities. Dean gloss: won't get linear scaling of output from chairs. Robert Sparks: not true that people need direction from chairs to decide what to do. Dean: if chair doesn't direct people, they work on other stuff. Robert: real issue is improving focus. Further point: siignificant overlap between heavy contributors and potential chairs. Aki: good editors not necessarily good managers. James Polk: likes breakout of functions. Nurturing/gestating new work a tough job. Six years two weeks to get Resource-Priority RFC. Problem getting comments. Cutting down flow of ideas won';t get the job done. Spencer: interim meetings -- participants feel like these are really effective. Disturbing -- IETF process as a whole in question. 25% more effect from four more chairs may be not worth it. xxxx: cOMMENTS a bottleneck. Lots of people giving 150%, no time. Can they advance anyway? Threat of other organizations doing their own thing. Eric: takes at least a year for someone to be able to review a document. Two years to be capable of editorship. Recruitment an essential task. Note that passionate editors find their own reviewers. xxxx: WGs can change editors. Do it when contributor overloaded. Dean: lose a person if you do this to them too often. Adam: occasionally chair intervention persuades a person to change priorities, work on IETF stuff. If no interest to review, maybe draft should not have priotity. Gonzalo: bottlenecks are 1. editors 2. reviewers 3. ... Focus effort on grooming editors to start with. Dean: Mary: reviewing -- GEN-art features names publicly assigned to draft. Strong motivator. Hannes: for many documents, the problem is cross-WG implications that result in churn because they effectively have multiple editors tossing the document over the wall. Example: common policy. Mary: GEN-art model helps to tie things together Paul: split can mean loss of efficiency because load doesn't split evenly. Reviewing: seems like things pile on to meetings more tightly than they used to -- no time to cover everything. Spread the work (like GEN-art). Jean-Francois Mule: try splitting SIPPING to start with. Likes directorate. Milestones between meetings. Regular conference calls often work -- design team, not lurkers. Dean: not done, lack of leadership push. John Elwell: draft cutoff date a strong incentive. Interim meetings would double that. ...: Need more implementers here. Reciprocation on deraft reviews. ........... Jon summarizing: pointed at different bottlenecks. Agrees both with leadership and contributor views. Need concrete proposals on how to increase rate of production. Cullen: sometimes design teams, interim meetings work, sometimes they fail. ADs have to analyze differences. Richard Shockey: RAI WG Chairs list? -------- Discussion: Do we have all the options defined? (15 min) -------- Proposal for Way Forward (Jon/Cullen) (10 min) --------------------------------- Key negotiations for secure RTP with SIP (Dan Wing) (25 min) There are many proposal discussing keying for RTP when used with SIP. These issues cross SIPPING, MMUSIC, AVT, and MSEC. What are the common underling requirements driving these proposals? At the high level what are the various architectures? What cross WG architectural level question do we need to answer? Can we come to consensus on high level approaches we would like to investigate? RFC 3830 (MIKEY) RFC 3711 (SRTP) draft-ietf-msec-mikey-rsa-r-02 draft-ietf-mmusic-sdescriptions-12 draft-ietf-mmusic-kmgmt-ext-15 draft-wing-mmusic-sdes-early-media-00 draft-mcgrew-srtp-ekt-00 draft-baugher-mmusic-sdp-dh-00 draft-zimmerman-avt-zrtp-00 draft-tschofenig-avt-rtp-dtls-00 draft-fischl-sipping-media-dtls-0 draft-fischl-mmusic-sdp-dtls-00 draft-rescorla-tls-partial-00 draft-modadugu-dtls-short-00 draft-fries-msec-mikey-applicability-00 draft-ietf-msec-mikey-dhhmac-11 draft-lehtovirta-srtp-rcc-01 draft-saito-mmusic-ipsec-negotiation-req-02 Charts. Trying to get agreement that there is a problem. Bonus would be to figureout a way forward. Trapezoid. Point: signalling path longer than media path. Forking makes life really messy for securing RTP. Forked-to parties learn media key, even though only one gets the call in the end. Clipping -- delayed establishment of media session. Variant: SDP answer doesn't come back soon enough to decipher earliest-arriving media. Conferencing architectures: be nice to limit keys to save on transcoding resources. Brian Rosen: limit to applicability of architecture illustrated. Proxy-based bid-down attacks. Secure RTP: channel security well-understood-- RFC 3711. Problem is association management -- key establishment, peer authentication, algorithm selection. Too many solutions, dependent on where proposers come from. None works well. Review of overall design choices: MIKEY, security descriptions. Both have problems with SIP forking, media arriving before SDP answer arrives. New ideas: handshake in media channel. Review of specifics: various MIKEY modes RFC 3830 -- pre-shared key. Jonathan: how about ICE? (Not treated) ICE interaction important. Dan: no written proposal on how to tie ICE together with media security. Jonathan: MUST get back answer before anything will work anyway, if NATs in the way. MIKEY Diffie-Hellman RFC xxxx -- dependency on PKI MIKEY Diffie-Hellman HMAC: pre-shared key. Clarifications on why Diffie-Hellman doesn't work for forking -- digital signature part depends on non-mandatory procedure. MIKEY RSA-R works for forking, missing something else SDESCRIPTIONS: TLS implying per-hop security, or S/MIME with its problems. Forking is insecure. Need answer before understanding media. SDES early media -- draft expired. Encrypted key transport w/ SDES: RTCP control channel used. SDP DH mode ZRTP -- everything in media path, proxy bypassed. Rohan: likely some government would block SRTP in that case. DTLS/RTP Ended up with a summary table. Problem with choosing best fit to your reqts is that the other end may have made a different choice. Hence message is to use table to find common denominator bearing in mind reqts for SIP and SRTP. Flemming question: is Point-to-point SIP the key priority? Cullen: that's what he asked Dan to focus on. xxxx: could other criteria such as latencyand resource consumption be added? Dan: of lesser importance. Architectural decisions: ------------------------ signalling path (already standardized but problems as described earlier) vs. media path (I-Ds only) How to authenticate the assoication Discussion: (20 min) Dan presented points of discussion. Jon suggested key thing is to reduce number of approaches. In what Area and WG should the work take place? Francois: agrees essential to tackle. Term 'forking" was used loosely, often the problem is retargeting -- should clearly distinguish. Some peculiarities to SIP responses mean SIP-specific solutions would be an acceptable outcome rather than more general one. John Elwell: additional challenge calls from the PSTN. Voice paths may be different. How to secure call ending on answering machine at PSTN. Dan: was a topic of recent discussion -- some solutions. Degree of forking a significant variable. Jonathan: need a document to encapsulate the design evaluation, attempt to make a choice. Not strong views of where to do work. Forking issues a red herring -- NAT makes SDP answer essential to understanding of media. (Technical quibble whether this is the "answer" per RFC 3264). Flemming: yes, problems, need to agree on what the problem is. One is negotiation, another is..., unicast vs. multicast. Forking. Need to focus. Alan Johnson: good understanding of issues, standardize in-band negotiation. Also, opportunistic encryption method. Magnus: have had problems with sufficient cross-area consideration. Russ: security area has interest. Cullen: obvious no decision without security ad buy-in xxx: keep focus on SIP. xxx: take time -- decisions will be hard to undo. xxx: MIKEY -- not enough connection with rest of IETF. Annoyed that all the work they did in msec apparently wasted. MUST get the right mix of people. (Start by not scheduling overlap) xxx: be nice to set up protocol so server arrangements don't matter (think of peer-to-peer) xx: reqts should be same Rohan: chair will be biassed unless you choose a pure process man. ------- Jon: Dan, thanks. (applause) Please turn into document. Will take some time to sort out. Beauty contest experience has not been fun, BOF a probable next step. Cullen: need more feedback on approaches (e.g. opportunistic encryption), importance of criteria. Get in touch with Cullen if you want to help set up an interest list.